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

[REBOL] Bug in the parse functionality ???

 [1/12] from: marc::meurrens::org at: 21-May-2003 23:20


--=====================_26218019==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hello Graham, Thanks for your answer. Do you mean the rebol precompiler coming with this SDK (producing a very large ,not indented file...) or the more or less equivalent prebol.r and prerebol.r ??? With these programs, I clean my source... but removing the comments and adding binary and other stuff to make the script standalone. What I was looking for was a script to prepare my code in order to be published and given to others... What tool do YOU use ? Or if you use one the PRE-things, with which parameters ? Anyway, my main concern is not so much producing pretty code My worry today is about the existence of such bug. Carl already promised me to work on this very soon. Cordially </marc> At 08:33 22/05/2003 +1200, you wrote:
>Hi, > >Off list...as I haven't received your message in my email yet. > >Can you try this first. Use prebol instead of clean-script on the >8kb file. > >clean-script has long been abandoned, and prebol has the same >functionality and more. > >Graham
Marc Meurrens TEL: +32 (0)2 537 2812 FAX: +32 (0)2 537 7645 GSM: +32 (0)475 46 2812 EMAIL: [marc--meurrens--org] URL: http://www.meurrens.org/ PGPKEY: http://www.meurrens.org/pgp/ Evitez les fichiers attach=E9s au couriel, utilisez plut=F4t mon 'exchange area' : Please don't mail me attached files, instead, use my 'exchange area' : EXCHANGE AREA: http://www.meurrens.org/exchange/ (HTTP/FTP upload/download of temporary/persistent files) --=====================_26218019==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <body> Hello Graham,<br><br> Thanks for your answer.<br><br> Do you mean the rebol precompiler coming with this SDK<br> (producing a very large ,not indented file...)<br> or the more or less equivalent prebol.r and prerebol.r<br> ???<br><br> With these programs, I clean my source...<br> but removing the comments<br> and adding binary and other stuff to make the script standalone.<br><br> What I was looking for was a script to prepare my code <br> in order to be published<br> and given to others...<br> What tool do YOU use ?<br> Or if you use one the PRE-things, with which parameters ?<br><br> Anyway, my main concern is not so much producing pretty code<br> My worry today is about the existence of such bug.<br> Carl already promised me to work on this very soon.<br><br> Cordially<br><br> </marc><br><br> <br> At 08:33 22/05/2003 +1200, you wrote:<br> <blockquote type=cite class=cite cite><font face="arial" size=2>Hi,</font><br> &nbsp;<br> <font face="arial" size=2>Off list...as I haven't received your message in my email yet.</font><br> &nbsp;<br> <font face="arial" size=2>Can you try this first.&nbsp; Use prebol instead of clean-script on the >8kb file.</font><br> &nbsp;<br> <font face="arial" size=2>clean-script has long been abandoned, and prebol has the same functionality and more.</font><br> &nbsp;<br> <font face="arial" size=2>Graham</font></blockquote> <x-sigsep><p></x-sigsep> Marc Meurrens<br> TEL: +32 (0)2 537 2812<br> FAX: +32 (0)2 537 7645<br> GSM: +32 (0)475 46 2812<br> EMAIL: [marc--meurrens--org]<br> URL: <a href="http://www.meurrens.org/" eudora="autourl">http://www.meurrens.org/</a><br> PGPKEY: <a href="http://www.meurrens.org/pgp/" eudora="autourl">http://www.meurrens.org/pgp/</a><br> Evitez les fichiers attach=E9s au couriel, utilisez plut=F4t mon 'exchange area' :<br> Please don't mail me attached files, instead, use my 'exchange area' :<br> EXCHANGE AREA: <a href="http://www.meurrens.org/exchange/" eudora="autourl">http://www.meurrens.org/exchange/</a><br> (HTTP/FTP upload/download of temporary/persistent files)<br><br> &nbsp;<br> </body> </html> --=====================_26218019==.ALT--

 [2/12] from: rebol:meurrens at: 21-May-2003 21:39


Hello all, I found something that looks like a serious bug. I have of course reported this morning (morning... in Europe) to Carl. But I'll like to know if somebody already encountered the bug and/or found a work-around and/or know more precisely where the problem stays. The bug can be demonstrated using %clean-string.r This script it-self is not very important but my concern is more general: if there is bug (or a limit ???) in the parse functionality, it must, at least, be known, and, of course, corrected... When using the well known and very standard %clean-string.r script (Carl's demo script to produce pretty indented source code) on a small file/string, it works fine. When the file exceeds approx. 8 kb, REBOL enters in an erratic behaviour. Looks like a memory problem (?) Even if we may eventually accept a documented limit to some functions, or even receive error messages, etc, we cannot live with an erratic behaviour... The bug was reproduced under all my versions under Win32 and Linux. I don't know for other OS. May be some of you can try on their own configs. I have some difficulties to imagine that I am the first reboller using %clean-string.r on a script larger than 8 kb. { Ok, REBOL is compact :-) ... } and thus the first to meet the bug ??? Also, if the bug appears within %clean-string.r it may also appear elsewhere ??? The bug is fully documented at URL http://rebol.mksa.net/cleanScriptBug/ where the bug is reproduced "on-the-fly." Everything is on this page and you can download Carl's original script (in fact, probably already on your disks...) and the two (otherwise unsignificant) source files used for demo. Hope this helps (and that some of you may give me some lights on this bug...) Regards, </marc> Prof. Ir Marc Meurrens, Brussels (be) TEL: +32 (0)2 537 2812 FAX: +32 (0)2 537 7645 EMAIL: [marc--meurrens--org] URL: http://www.meurrens.org/ REB: http://rebol.mksa.net/ PGPKEY: http://www.meurrens.org/pgp/ Please don't mail me attached files, instead, use my 'exchange area' : EXCHANGE AREA: http://www.meurrens.org/exchange/ (HTTP/FTP upload/download of temporary/persistent files)

 [3/12] from: rotenca:telvia:it at: 22-May-2003 0:56


Hi Marc, I think that the script reaches the recursion limits of parse. Indeed the recursion is not a need, so you can change it. I made to the script some other small changes to make it faster. REBOL [ Title: "REBOL Script Cleaner" Author: "Carl Sassenrath" File: %clean-script.r Date: 22/05/03 Email: [carl--rebol--com] Purpose: { Cleans REBOL scripts by parsing the REBOL code and supplying standard indentation and spacing. } Note: { This script produces STANDARD script indentation and spacing. No doubt you will want to modify it to use your own rules. Send your enhancements and I will consider adding them to the distribution... but keep this header intact and keep the code clean. No hacks. } Category: [script util text 3] History: [ "Romano Paolo Tenca" 1.0.1 22/05/03 "removed recursion, changed append with insert tail, added value local word, others small changes" "Carl Sassenrath" 1.0.0 27-May-2000 "Original program." ] ] script-cleaner: make object! [ out: none ; output text spaced: off ; add extra bracket spacing indent: make string! 50 ; holds indentation tabs emit-line: func [] [insert tail out newline] emit-space: func [pos] [ insert tail out either newline = last out [indent] [ pick [#" " ""] found? any [ spaced not any [find "[(" last out find ")]" first pos] ] ] ] emit: func [from to] [emit-space from insert tail out copy/part from to] set 'clean-script func [ "Returns new script text with standard spacing." script "Original Script text" /spacey "Optional spaces near brackets and parens" /local str new value ] [ spaced: found? spacey insert out: make script length? script newline parse script [ some [ str: newline (emit-line) | #";" [thru newline | to end] new: (emit str new) | [#"[" | #"("] (emit str 1 insert tail indent tab) | [#"]" | #")"] (remove indent emit str 1) | skip ( set [value new] load/next str emit str new ) :new ] ] remove out ; remove first char ] ] --- Ciao Romano

 [4/12] from: brett:codeconscious at: 22-May-2003 9:26


Hi Marc, I don't understand what you mean by REBOL having somewhat erratic behaviour, but there is a known problem in clean-script.r. I don't know why the old version has persisted so long because the problem was fixed a long time ago by Volker (I believe). Within the clean-script function find the block "blk-rule" and change the SOME to an ANY. See how that goes. Also the standard way to report errors to REBOL Technologies is to email [feedback--rebol--com] Regards, Brett. ----- Original Message ----- From: "Marc Meurrens" <[rebol--meurrens--org]> To: <[rebol-list--rebol--com]> Cc: <[carl--s--rebol--com]>; <[cindy--rebol--com]>; <[miguel--cgsa--net]>; <[olivier--auverlot--free--fr]>

 [5/12] from: gchiu:compkarori at: 22-May-2003 17:02


On Thu, 22 May 2003 09:26:19 +1000 "Brett Handley" <[brett--codeconscious--com]> wrote:
>Also the standard way to report errors to REBOL >Technologies is to email > > [feedback--rebol--com] >
That method has been deprecated in favour of the form at: http://www.rebol.com/feedback.html -- Graham Chiu http://www.compkarori.com/cerebrus/

 [6/12] from: greggirwin:mindspring at: 21-May-2003 22:37


Hi Marc, MM> I found something that looks like a serious bug. I can duplicate the problem here, seeing doubled brackets in places on large scripts, but I haven't tried to track it down. Hopefully Carl will respond with info about it. I think I only tried clean-script a few times when I started with REBOL, and when my scripts were very small. I don't think I ever tried it on a large script. It's easy to forget all the handy little tools that are out there. Too bad this one's bugged. :) Good catch though! -- Gregg

 [7/12] from: g:santilli:tiscalinet:it at: 22-May-2003 10:14


Hi Marc, On Wednesday, May 21, 2003, 9:39:45 PM, you wrote: MM> I have some difficulties to imagine that I am the first reboller MM> using %clean-string.r on a script larger than 8 kb. Indeed, the strange behavior was noticed (and reported, at least on this list, but I think to feedback too) soon after clean-string.r was published. I don't know if the problem is in PARSE or in clean-string itself. Ladislav and Romano have reported bugs in PARSE in the past, so maybe they know. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [8/12] from: g:santilli:tiscalinet:it at: 22-May-2003 10:16


Hi Brett, On Thursday, May 22, 2003, 1:26:19 AM, you wrote: BH> Also the standard way to report errors to REBOL Technologies is to email BH> [feedback--rebol--com] Actually, RT discourages the use of email, and suggests using the web form at http://www.rebol.com/feedback.html . At least AFAIK. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [9/12] from: carl:s:rebol at: 22-May-2003 17:40


Clean-Script has 2 bugs: 1. It does not reset the INDENT. The main func needs the line: clear indent at the top. 2. It does not BREAK from the BLK-RULE on a closing ] or ). This causes deep PARSE rule recursion, which overflows something internally (not sure what, but I will find out!) Fix is: [#"]" | #")"] (remove indent emit str 1) break | (add the BREAK). This seems to cleanup the Clean-Script script nicely. I will check these changes into the REBOL library. Update colorizer too if needed. -Carl MM> I have some difficulties to imagine that I am the first reboller MM> using %clean-string.r on a script larger than 8 kb. Indeed, the strange behavior was noticed (and reported, at least on this list, but I think to feedback too) soon after clean-string.r was published. I don't know if the problem is in PARSE or in clean-string itself. Ladislav and Romano have reported bugs in PARSE in the past, so maybe they know.

 [10/12] from: rotenca:telvia:it at: 23-May-2003 14:48


Hi Carl,
> 2. It does not BREAK from the BLK-RULE on a closing ] or ). > This causes deep PARSE rule recursion, which overflows something > internally (not sure what, but I will find out!) Fix is:
I think that parse finds its recursion limits like in this example: n: 0 parse "" x: [(n: n + 1) x] n; == 201 I think that parse should fire an error when this happen. Now the rule fails and parse continue with the next command. I think that recursion is not needed at all in clean-script. With or without a correct recursion the same thing happens. Here it is the rule without any reccursion. Is it wrong? parse script [ some [ str: newline (emit-line) | #";" [thru newline | to end] new: (emit str new) | [#"[" | #"("] (emit str 1 insert tail indent tab) | [#"]" | #")"] (remove indent emit str 1) | skip (set [value new] load/next str emit str new) :new ] ] --- Ciao Romano

 [11/12] from: rotenca:telvia:it at: 23-May-2003 15:00


About parse recursion limits:
>> n: 0 parse "" x: [(n: n + 1) x] n
== 201
>> n: 0 parse "" x: [(n: n + 1) some [x]] n
== 101
>> n: 0 parse "" x: [(n: n + 1) some [some [x]]] n
== 67
>> n: 0 parse "" x: [(n: n + 1) some [some [some [x]]]] n
== 51
>> n: 0 parse "" x: [(n: n + 1) some [some [some [some [x]]]]] n
== 41 Every nested block make the limit to become more near. Clean-script, for example, fails at the 67 boundary. --- Ciao Romano

 [12/12] from: lmecir:mbox:vol:cz at: 23-May-2003 22:30


Hi Romano,
> Every nested block make the limit to become more near. > > Clean-script, for example, fails at the 67 boundary. > > --- > Ciao > Romano
one more example showing how parse behaves:
>> n: 0 parse "a" x: [(n: n + 1) x | (prin "n: " print n) #"a"]
n: 201 == true Ciao -L