Hi Gabriele
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> > Well, rebol talks about simple databases and "better xml".
> > how can i use it if a occasianal "rebol" can crash the data?
>
> I think you are a bit exaggerating the problem here. Actually, you
> have a problem only if there is a line that starts with the word
> "REBOL" followed by a block; this is a situation that may be
> impossible for most data files. If you think it could happen in
> some data file you use, then you just have to use save/header
> instead of save, and the problem magically disappears.
>
yes, but i am writing rebol-scripts and on this list,
using own stuff.
i tried Bo's Messenger once and he does emails in a nice way:
he simply starts a email with a header [ to: .. from: .. ]
i thought "clever" and implemented my parser similar,
i have such a block at the start and after it the text.
parsing is cool: with load/next i get the block and the text
in one step, a bit making and i have an email ready.
with all options i wish simply typed in, without more parse-code.
nearly perfect, but then i wrote some mail with a script in.
imagine what happened?
parsing rebol-scripts with a similar method crasht regulary with one
file, the parser itself. it had some parse-rules for the header in it,
which began with "rebol["..
then, thinking about it, i can imagine some store-and-search-engine with
using save, and, if data is rebol-related, there can be a "rebol" in it.
And this is, as you say, a very very rare case, which means, it
can occour pretty late after release, because all carefull testing will
not trap it. So i have to know about it, allways extra analysing,
for this little feature. bad, i think
> > BTW i also dislike the [a: ""] trapp. i programm the usual way,
>
> This is a design issue of REBOL, and once you understand WHY that
> gives "strange results" it is no more strange.
>
i meant not strange. i mean, i edited some code, a [copy ""] loosed
its [copy], all looked pretty well as before because i looked only
at the start of the data, while at the end there was the
accumulating-feature working.
i think the ridiculous mail is somewhere at this list..
This may be the most common error in beginners code in this list,
and needs deep understanding or hints, and then caution a while.
a trap in my opinion, and not necessary?
> > I suggest inline-strings and blocks should be read-only,
>
> This might be an idea, but then you have more problems when you
> save and then load strings... No, I don't think this would be a
> good solution.
>
this was not related to saving-storing, but the hidden accumulation
which makes the first call looks pretty and the second giving surprise,
forcing me to test the function twice consecutively.
an interesting, but very rare need in programming-languages.
they will call this side-effect and say ugly things about it, rebol or not.
making it read-only would force to write out [copy""] at the first run,
but having the feature of short read-only-strings for meaningfull printing.
this is the way a good rebol-programm is coded already?
it would help a bit with learning and temporary low concentration.
What's your reservation with load and save? I have no idea yet.
(and later) a write-protected saved string is changeable after
load? or loaded blocks are then write-protected? hm. thinking..
as mentioned above, no problems in a good-style copy-using programm?
save can be seen as a kind of [copy], load is write-enabled.
you will have allways such problems in a type-free language?
but they should be intuitive, and - is there someone who really expected
the collection-feature here? starting i wrote [a: ""] to say
"hey, rebol, put me an empty string in a".
i dislike telling a new fan ("two hours and i got it!!!")
"wait..".
but, the error should be mentioned at the declaration, not somewhere
when using, so a automatic copy and a [a: static ""] should be better?
without read-only. a internal "copy on first write" maybe?
but {i write {reset to "hello"}}, {i read {reset to "hello"}},
{i get #$@%!!?=} ?!?
Is there a really great feature with the current behavior?
> > Then there must be a timeout if rebol runs serious remote (cgi..).
>
> Perhaps this should be a server issue --- the server should have
> timeouts for CGI, because if your CGI is not working correctly you
> cannot expect it to timeout correctly (I'm talking generally here,
> a CGI might be any kind of executable...)
>
looking at the web-servers and wikis in rebol.org and thinking
to allow wild contributed code on it, Gabriele, man, ILOVEYOU ;-)
but, no please!
making a sandbox with a context-trick you have shown month before.
but someone will hang the wiki for fun.
for local use there is a "timeout", the escape-key. with some need,
i think. for remote, things change?
timeout is kind of "escape without the key".
maybe some open/delete-on-close for lockfiles needed too, but more?
and you may set the timeout from the command-line, or
make some seconds the default allways (add to the secure-feature).
if the cgi does wrong, makes it problems bigger when rebol givs up then?
it must not break accurate, expecting seconds one may allow hours,
but need to reboot as mentioned here (NT is a plattform? ;-) ?
this could be triggered by the same code as the escape-key.
well, yes, the viking will hang us with [mold],
but this needs a fix too.. why doesn't it poll escape ?!
timeout should be cheap to implement and a mighty protector?
On unix there are os-calls to restrict runtime AFAIK?
> > And a warning about contexts/bind while this crashes so reliable.
>
> I don't know why the GC hasn't been fixed yet. This is surely a
> major defect in REBOL currently.
>
maybe fixing is really very difficult.
Or, they change code often (in c!)
and have to track all gc-relations by hand,
they may wish to fix it in a final step?
or, dreaming:
maybe rebol wish to improve bind and wish to economize recoding?
there is some need for namespaces (moduls) instead of objects, i think.
look at your cid-utils: you replace the old cid-object with
your extended object, which i think is clever.
but if one have bound some stuff from side in the old object,
you get problems:
lets say, one have a member 'a in it : some old code bound from the
side will use the old 'a, while member-functions refer to the new 'a?
there should be some way to extend an object in-place.
this may introduce other problems ('a may be outside object before
and inside object after), and perhaps they work on a better concept
for that? then a gc-patch is trash in the next version.
or they think block-parsing is a better way, or other reasons.
raw bind dying?
and they need a concept for functions? currently local variables
keeps bound to its contends, may hold lots of memory used.
no big problems in cgi-scripts, but if there are
hours-running db-guis this may be a problem.
you may have to use [a: b: c: none] at end of function to release
memory.
or there are threads comming with need for a new thread-safe gc?
A jump from 2.2 to 3.0 on the horizon, with complete internal changes? :)
Was Carl collecting possibilities, or saying "too much" some time ago? :)
if the guys at rebol.com would use binding very often, they would
have focused on this bugs much earlier?
So it may be kind of "bad style" in its current stage.
They may think "ok, no one is using it today,
no one will use it tomorrow morning, and after that we have a
complete better solution"?
Yust guessing.
> Regards,
> Gabriele.
> --
> Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer
> Amiga Group Italia sez. L'Aquila --- http://www.amyresource.it/AGI
>
Volker
