Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: REBOL/Contrib

From: petr:krenzelok:trz:cz at: 23-Nov-2000 16:20

nop wrote:
> Hello, folks: > > If I may, I'd like to mention a thing or two about the contrib system: > > o As the contrib web page says, all submittal code goes to > [contrib--rebol--com] and all the paperwork HAS to be sent along as well > for the code to be considered. It's just a business reality. > > o We can't promise anything, to anybody. We're likely to turn > down much, and that's because REBOL has a ridiculously high > standard.:) > > o We also can't promise to be fast. But if you do send in code to > contrib we do promise to give it our attention. > > o Volume of submissions has been low. Why??
Because of level of advancement? Can we advance REBOL by contributing source codes? I like every kind of advancement, everybody does :-) But to be honest, I think most ppl are expecting advancements in the rebol technology itself, but can we help it? RT representatives read all the mls so you folks surely know what bothers us. RT says they hear our voices, but nothing is being done about it (or we just don't know something is being done), and other things (REBOL/Express) seem to have higher priorities ... Let's face it: - Apache based upon /Core. You are on Apache ml Jeff, so you surely remember our complaints about it - no database access .... result: beta product development: postponed - /View - I try to use /View for last few weeks as much as time permits, and I have to say - you guys deserve medal. It's a great concept. But: result: beta product, some bugs, RT was already asked for full release development: slowed down, last few months updated mainly at /Core level - /Command - I last used beta version, but - for the capabilities it offers, comparing it to other systems - still overpriced, and unfeatured .... conclusion: As you can see, I don't use 'result and 'development item for description here, as I think current /Command model is wrong. We really need dynamic components, and because we don't have it we suffer in following way: - without component model, we have to wait for RT to produce "endless" variations of products ... RT was already asked for Apache/ODBC/Database combination, /Command/View combination, I also expressed the need for /Core/Shell combination etc. There should be only one rebol/core. Not few incompatible versions thru various products. - rebol community can't do anything about the state of things. At least I am glad RT marketing ppl agree that dynamic component model is good way to follow, as it allows to raise/lover prices (e.g. why to sell /Oracle component for few bucks, if someone who has already paid for such big db as Oracle is, can afford to spend much more money for the component ...) Other possible advancements: - parser advancements were submitted more than year ago? parsing to/thru first match from several (e.g. to [op1 | op2 | op3]), 'replace in parse level, parsing upon opened ports) - /dir and /files refinement to 'load to prevent us from manually sorting block of dir items, and could possibly speed up file-requestors upon larger directories - find/flat, or find/deep - would perform the search in a series, regardles of structure - would return series in the point of where the value is foud. Imagine deeply nested XML parser resulting block: ->> block: ["a" ["B" "C"] ["E" ["F"]]] ->> pos: find/deep "F" [3 2 1] ->> tmp: block == ["a" ["B" "C"] ["E" ["F"]]] ->> for i 1 (length? pos) 1 [print tmp tmp: pick tmp pos/:i] a B C E F E F F == "F" Hmm, I am not sure it makes sense :-))) - some slight improvements to View (hiding mouse - then we can come up with own faces for mouse), maybe even Allen's suggestion for native menus and slidebars to windows ... good for some fast prototyping of production apps with native OS look... - native matrice operations to produce faster effects upon images, but usefull for other stuff too ... - would it be possible to define some kind of API to allow working upon REBOL datatypes from external environment? E.g. calling library function, sending it rebol loaded image (which is stored in block), and manipulating the data in the library level ... - modules proposal Carl introduced some half year(?) ago to ally list members - more direct link to external environments? It's a shame REBOL Toolkit was cancelled. (well, it was mentioned only in one very early /Command announcement), but there would be interest in such product ... As long as some ppl will think e-commerce saves the world, as long we will loose .... :-)) Carl asked us for help. OK, yesterday I finished article for our premiere programmer's mag. I am just scared that after the readers will look at rebol from the same perspective I expressed above, they will leave us soon, and will not come back. We can't spread rebol, if we are contraproductive (e.g. Apache situation), and yes, I tried it with several very good friends. Although they listened carefully, REBOL lacked important features at the area given (database connectivity) ... I thought we want to become universal glue for various environments, but we are not there ... not yet, not yet, but we surely will, but you know - when ? :-) Cheers, -pekr-