REBOL/Contrib

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-

Too few time, too much to do...

I'd like to do some enhanchements to the HTTP protocol, but dunno when/if I'll have enough time (cannot just do a quick hack, can I?). I'd like to ask, would /View contribs be taken into consideration? Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

:-) Such is the state of life . . .

Whatever you think it is worth going through the trouble to fill out the paperwork for.. :-) So, maybe a bundle of little hacks? Of course, the more submitted, the better the odds of something we might include.

Of course! -jeff

Hi Jeff, What happened to the $50 weekly best contributed script prize that was going a while ago :-) Also, I note that no new user scripts have been published on rebol.com for a long while now. -- Graham Chiu

It was US$100, and it was only for a limited time. :)

Work on REBOL/Express has really been our overriding concern lately. -jeff

How about starting it again :-)

I meant user contributed vs. Rebol staff written scripts. Unless of course you meant you guys are too busy to vet scripts as well :-( -- Graham Chiu

Yup. :-)

:-)

Great! I've got something then (a couple of things I'm using in a /View application I'm writing and which could be useful to others as well). Now I need just some time to "fill out the paperwork". ;-) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/