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

[BUG?] read-io & write-io or Wait or is TCL better?

 [1/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


Hello All / RT, Im encoutering a strange behaviour using read-io / write-io. linux core & view (any release) I build a "tunnel" application in Rebol over tcp ports and use read-io write-io to transport the data over the ports. telnet, web, ftp everything runs fine over the tunnel except for SSH!!! Ssh drops me out with the error "Bad packet length"... Now i have checked the bug reports at openssh and indeed there are some issues related to this, but its NOT the SSH i found out finaly, it looks like it is the behaviour of the lowlevel read-io and write-io, but DONT ask me what it is, i cant find it. Why i think its a rebol bug? I have build a tool under TCL and it does exaclty the same as the rebol tool, expect the TCL one works with NO errors?! (dammmm :) Although TCL uses Fileevents and I use a rebol 'wait. Also the TCL code uses the same port configuration as rebol port: Non blocking and Non buffering and Binary. Why does TCL work and REBOL not? The only thing i could find basicly is the difference between porthandling the DATA. Tcl has the ability to manipulate data as is receives or sents (UTF8 etc...) (thats off in my tcl application) And tcl uses fileevents, while rebol uses wait. (not quiet the same though) Question #2: Somewhere during the transmition of the data and the receiption of the data the data is mixed!! (not deliverd in the right order!!!) because when i count pachages the sent and receive are always the same. (cant check the content thought!!) Also ssh uses 3des and or blowfish, so the session is cripted. PS: (Please dont advice me to look at ssh bugreport My tcl application works fine!) Ooo yes some code... I use read-io write-io like this while [ positive? size: read-io INCOMING buffer bufsize ] [ write-io OUTGOING size ] The selection on ports is done by a "wait [ 0 one two ]" But the above work alll fine with ftp telnet web..anything... Ooo yes.. i changed several times the bufsize but no effect... ?? Lowlevel Big-endian perhpas??? Hope someone has an idea??? (R)egards, Norman -- Conversation/lunch: "How do you Eat your Rebol in the Morning?"

 [2/32] from: andrew::martin::colenso::school::nz at: 7-Aug-2003 8:47


Norman wrote:
> I use read-io write-io like this > while [ positive? size: read-io INCOMING buffer bufsize ] [ > write-io OUTGOING size > ]
For 'read-io, the buffer size must be larger than the size of the data coming in! For example, in my Wiki (and Mesh) scripts, I use this: Query_String: make string! 2 + Length: to integer! Rebol/options/cgi/content-length read-io Rebol/ports/input Query_String Length I'd suggest you use something like: buffer: make string! 2 + bufsize while [ positive? size: read-io INCOMING buffer bufsize ] [ write-io OUTGOING size ] And that should cure your problems! :) Andrew J Martin Attendance Officer & Information Systems Trouble Shooter Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]

 [3/32] from: petr:krenzelok:trz:cz at: 6-Aug-2003 23:15


Andrew Martin wrote:
>Norman wrote: >>I use read-io write-io like this
<<quoted lines omitted: 17>>
>] >And that should cure your problems! :)
Andrew, either you are able to explain it, or it should be regarded bug imo! That is not the only issue with rebol handling packets, I e.g. found difference between using open/direct/no-wait and open/direct/no-wait/binary ... simply talking to our device, if I don't use /binary refinement, exactly the same loop is quit and rebol refuses to wait .... I even watched packets and from the device pov everything was just exactly the same in our case .... -pekr-

 [4/32] from: andrew:martin:colenso:school at: 7-Aug-2003 9:26


Pekr wrote:
> Andrew, either you are able to explain it, or it should be regarded
bug I'm sure there's a note explaining it on http://www.rebol.com/ perhaps in the dictionary? It's to do with the buffer size. Andrew J Martin Attendance Officer & Information Systems Trouble Shooter Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]

 [5/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


Quoting Andrew Martin <[andrew--martin--colenso--school--nz]>: Hello Andrew, Thanks for the tip but thats not the problem/solution, otherwise the other sessions like telnet etc would have had problems too...also its binary data i transport to keep it as clean as possible... I realy dont have any clue what it can be, it realy looks like a bit/byte mixup somwhere on the read-io or write-io... Im not missing bytes!! (i cheched it) But it could be mixed around somewhere in the io-session... Also im using open/binary/direct/no-wait on the ports, So what Petr tells could be a clue?? I realy am speachless right now... I just changed the port to open/direct/no-wait but then im realy having problems because the port will be string based, which should not be, so thats not working either..(also different errors occeur logicaly)... Hope more clue's come in the mailinglist... Thanks, (R)egards, Norman. -> -> For 'read-io, the buffer size must be larger than the size of the data -> coming in! -> -> For example, in my Wiki (and Mesh) scripts, I use this: -> Query_String: make string! 2 + -> Length: to integer! Rebol/options/cgi/content-length -> read-io Rebol/ports/input Query_String Length -> -> I'd suggest you use something like: -> -> buffer: make string! 2 + bufsize -> while [ positive? size: read-io INCOMING buffer bufsize ] [ -> write-io OUTGOING size

 [6/32] from: andrew:martin:colenso:school at: 7-Aug-2003 10:03


Hi, Norman. Everything you're describing sounds exactly like the problem that the solution I posted fixes! Why not give it a try and see if it does solve your problem? Andrew J Martin Attendance Officer & Information Systems Trouble Shooter Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/

 [7/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


-- Conversation/lunch: "How do you Eat your Rebol in the Morning?" Quoting Andrew Martin Hello Andrew, I did ;-) but no effect... BUT.... I just found someting amazingly strange in the rebol buffering: bufsize: 8192 * 10 ;; for testing make it bigger buffer: make binary! bufsize after the while [ positive? size: read-io ...... I found that the Buffer is: 20479 bytes (length? buffer) the data received: 17331 bytes (read-io) data transmitted: 17331 bytes (write-io) AND now the odd thing --> The buffer should have been 17331 and not 20479 i assume. (The ssh session crashed here too) Because the read-io always returns the size of read bytes or extracts the byte-size too big to fit in the buffer from the size (which is not the fact here) Concluding: there is a some enthousiastic overrun here, interacting read-io & write-io using a buffer, the above caused the SSH the crash while the data entered my SSH client (ssh <-- Rebol tunnel --> sshd ) = NOK (ssh <-- TCL tunnel --> sshd ) = OK (telnet <-- Rebol tunnel --> telnetd ) = OK (http <-- Rebol tunnel --> httpd ) = OK (ftp <-- Rebol tunnel --> ftpd ) OK Mmmmm oddyyy.. Can someone confirm this perhpas? (R)egards, Norman.

 [8/32] from: andrew:martin:colenso:school at: 7-Aug-2003 10:40


Norman wrote:
> bufsize: 8192 * 10 ;; for testing make it bigger > buffer: make binary! bufsize > after the while [ positive? size: read-io ...... > I found that the Buffer is: 20479 bytes (length? buffer) > the data received: 17331 bytes (read-io) > data transmitted: 17331 bytes (write-io)
Sounds like there's something wrong in the code?! Can we see more of it, please? Andrew J Martin Attendance Officer & Information Systems Trouble Shooter Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]

 [9/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


Hello Andrew, The packet mismatch comes from a previous packet-size inside the buffer and is added to the next buffer (so the buffer is not cleared correctly!!) i.e. bufsize: 8192 * 10 buffer: make binary! bufsize -- packet #99 B: 1024 ;; length? buffer R: 1024 ;; size: read-io T: 1024 ;; write-io -- packet #100 B: 5120 ;; length? buffer R: 4096 ;; size: read-io T: 4096 ;; write-io <<crash>> This is a part my code for the IO, and is works fine with > 30 MB of Binary/ascii FTP data... This function runs every xx millisecond so i can emagine the make binary! bufsize is not quick enough???? sio: func [ IN OUT [port!] name [string!] ][ bufsize: 8192 * 10 buffer: make binary! bufsize while [ positive? size: read-io IN buffer bufsize ][ prin name prin [ " B:[ " length? buffer " ]" ] prin [ " R:[ " size " ] " ] write-io OUT buffer size print [ " T:[ " size " ] " ] print [ to-binary buffer ] ] ] Here is my (very older) TCL code ;-) http://aspn.activestate.com/ASPN/Cookbook/Tcl/Recipe/164989/index_txt (R)egards, Norman.

 [10/32] from: ptretter:charter at: 6-Aug-2003 18:59


I remember it being said that readio and writeio were lower level functions for handling port data. Not sure what the distinction is between those and copy port, append port are. Can anyone provide more information on those differences. Paul Tretter

 [11/32] from: petr:krenzelok:trz:cz at: 7-Aug-2003 9:23


Rebolinth wrote:
>Hello Andrew, >The packet mismatch comes from a previous packet-size inside the buffer
<<quoted lines omitted: 27>>
> ] >]
If I remember correctly, I got such odd behavior if I did not CLEAR buffer each time - so, try to put "clear buffer" right after you write-io your data, it may help. We just should decide, if it is a bug or not, as other non-binary data do work (according to what you say), but I remember someone (Holger?) explained it in a reasonable way in the past ... but I can be wrong ... Cheers, -pekr-

 [12/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


Quoting Petr Krenzelok Hello Petr, I think i could try that, although the "buffer: make binary! bufsize" clears also every time the function is called... Now I also got another idea... I will create 2x BUFFERS 1 for read and 1 for write..pehaps the speed of the function calls interfers with the buffer clearance..Ill report back ;-) (R)egards, Norman. -> If I remember correctly, I got such odd behavior if I did not CLEAR -> buffer each time - so, try to put "clear buffer" right after you -> write-io your data, it may help. We just should decide, if it is a bug -> or not, as other non-binary data do work (according to what you say), -> but I remember someone (Holger?) explained it in a reasonable way in the -> past ... but I can be wrong ...

 [13/32] from: petr:krenzelok:trz:cz at: 7-Aug-2003 10:09


Rebolinth wrote:
>Quoting Petr Krenzelok > >Hello Petr, > >I think i could try that, although the "buffer: make binary! bufsize" >clears also every time the function is called... >
No, I don't speak of functiona call - watch your 'while loop! You have to clear the buffer each time you pass while loop! Try that ... and let me know, ok? ;-) -pekr-

 [14/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 10:28


Hi Norman, On Thursday, August 7, 2003, 12:26:23 AM, you wrote: R> The buffer should have been 17331 and not 20479 i assume. Are you clearing the buffer after each read/write cycle? your-loop ... [ ... read-io buffer ... ... write-io buffer ... clear buffer ] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [15/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 10:29


Hi Norman, On Thursday, August 7, 2003, 1:01:05 AM, you wrote: R> while [ positive? size: read-io IN buffer bufsize ][ R> prin name R> prin [ " B:[ " length? buffer " ]" ] R> prin [ " R:[ " size " ] " ] R> write-io OUT buffer size R> print [ " T:[ " size " ] " ] R> print [ to-binary buffer ] clear buffer R> ] R> ] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [16/32] from: AJMartin:orcon at: 7-Aug-2003 20:36


Pekr wrote:
> >I think i could try that, although the "buffer: make binary! bufsize" > >clears also every time the function is called... > > > No, I don't speak of functiona call - watch your 'while loop! You have > to clear the buffer each time you pass while loop! Try that ... and let > me know, ok? ;-)
All those 'prin words may be problem as well? Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [17/32] from: petr:krenzelok:trz:cz at: 7-Aug-2003 10:41


Gabriele Santilli wrote:
>Hi Norman, >On Thursday, August 7, 2003, 1:01:05 AM, you wrote:
<<quoted lines omitted: 10>>
>Regards, > Gabriele.
Hello Gabriele, I know I struggled really badly with exactly the same problem in the past. Although it may be reasonalble explainable that Rebol simply enlarges buffer, I think that we should think of submitting a bug request. And why? Because docs don't state that in the case of read-io we should clear the buffer. If it would lead only to buffer size increase, then OK, but it leads into completly broken communication with unexpected results ... What do other think? Should write-io clear the buffer after succesfull write automatically? -pekr-

 [18/32] from: Rebolinth:nodep:dds:nl at: 24-Dec-2003 22:30


-- Conversation/lunch: "How do you Eat your Rebol in the Morning?" Quoting ALL Hello All, Although a "clear buffer" sounds logical it should not be necesary, the :size in "size: read-io..." should always return the length of read-io bytes so even if the buffer is filled with old bytes the :size is leading here... (I expect the buffer-end is an <EOF>) As 'clear does a clear from the index upto the tail, it doesnt sound logical to use. But perhpas the speed of the function call could intefer with the :size enventualy.. But ill try it right away.. Ill get back with the result... (R)egards, Norman. -> I know I struggled really badly with exactly the same problem in the -> past. Although it may be reasonalble explainable that Rebol simply -> enlarges buffer, I think that we should think of submitting a bug -> request. And why? Because docs don't state that in the case of read-io -> we should clear the buffer. If it would lead only to buffer size -> increase, then OK, but it leads into completly broken communication with -> unexpected results ... -> -> What do other think? Should write-io clear the buffer after succesfull -> write automatically?

 [19/32] from: dockimbel:free at: 24-Dec-2003 22:30


Selon Rebolinth <[Rebolinth--nodep--dds--nl]>: [...]
> Although a "clear buffer" sounds logical it should not be necesary, > the :size in "size: read-io..." should always return the length
<<quoted lines omitted: 3>>
> it doesnt sound logical to use. But perhpas the speed of > the function call could intefer with the :size enventualy..
Read-io *appends* data in the buffer, it doesn't clear the old data. That's why you have to do a [clear buffer] in your read/write loop. -DocKimbel

 [20/32] from: dockimbel:free at: 24-Dec-2003 22:30


Selon Petr Krenzelok <[petr--krenzelok--trz--cz]>: [...]
> I know I struggled really badly with exactly the same problem in the > past. Although it may be reasonalble explainable that Rebol simply
<<quoted lines omitted: 5>>
> What do other think? Should write-io clear the buffer after succesfull > write automatically?
Read-io and write-io are low-level natives that behave more like their C counterparts than like normal REBOL natives (no auto-expansion). I guess that RT needed them to be able to accurately control low-level ports stuff, but since 'set/get-mode natives appeared, low-level I/O natives shouldn't be used anymore, as stated by Holger here (a year ago ?). I found them still usefull in a few cases to optimize memory usage. So, to answer your question, I think that low-level natives should remain low- level. If you need automatic buffer expansion, you should use 'copy/insert instead, with appropriate 'set-mode calls if necessary. -DocKimbel

 [21/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 12:38


Hi Norman, On Thursday, August 7, 2003, 11:00:45 AM, you wrote: R> Although a "clear buffer" sounds logical it should not be necesary, R> the :size in "size: read-io..." should always return the length R> of read-io bytes so even if the buffer is filled with old bytes R> the :size is leading here... (I expect the buffer-end is an <EOF>) As I said to Petr, READ-IO does *NOT* overwrite your buffer. If you have data in it, it will append to it. So you either have to skip the initial data when writing (but then you could end up filling your buffer!) or clear it each time. (Notice that CLEAR is O(1) so this does not add any performance problems.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [22/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 12:35


Hi Petr, On Thursday, August 7, 2003, 10:41:04 AM, you wrote: PK> request. And why? Because docs don't state that in the case of read-io PK> we should clear the buffer. If it would lead only to buffer size PK> increase, then OK, but it leads into completly broken communication with PK> unexpected results ... Actually, you're wrong. First of all, READ-IO and WRITE-IO are lowlevel functions; you should use COPY and INSERT whenever possible if you don't want to bother with these kind of details. READ-IO and WRITE-IO *DON'T* enlarge the buffer. You have to provide a large enough buffer for them, and a correct length value too. Furthermore, READ-IO *DOESN'T* overwrite the buffer you provide, but instead it appends to it if there is already some data (this is a useful feature and not a bug). For this reason, if you don't want it do behave this way you have to provide it an empty buffer. If the docs are not clear about this then this is a bug in the docs, not in REBOL (Carl is using READ-IO and WRITE-IO this way so I'm pretty sure it's not a bug ;-). What was happening to Norman is that he was resending the first packet every time. His proxy worked for other services because, by chance, they didn't happen to send two packets at once. SSH did, and his code instead of resending the two packets sent the first two times. PK> What do other think? Should write-io clear the buffer after succesfull PK> write automatically? I don't think this would be a great idea, as the buffer could be needed for something else after the write. For example I may want to send the data in smaller pieces instead of all at once, so I don't want the buffer to be cleared as I only send a small part of it each time. (If you look at the source for async:// you'll see I'm doing exactly this.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [23/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 12:41


Hi Nenad, On Thursday, August 7, 2003, 12:00:21 PM, you wrote: dff> So, to answer your question, I think that low-level natives should remain low- dff> level. If you need automatic buffer expansion, you should use 'copy/insert dff> instead, with appropriate 'set-mode calls if necessary. Exactly. READ-IO and WRITE-IO are only needed in async I/O because INSERT and COPY do not seem to work as expected in this case. This is probably due to the "experimental" state of the async code in REBOL. Once this gets fixed, probably we'll be able to avoid these functions at all. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [24/32] from: petr:krenzelok:trz:cz at: 7-Aug-2003 13:19


Gabriele Santilli wrote:
>Hi Petr, >On Thursday, August 7, 2003, 10:41:04 AM, you wrote:
<<quoted lines omitted: 4>>
>Actually, you're wrong. First of all, READ-IO and WRITE-IO are >lowlevel functions;
OK, that is just presumption. Novice user will not know that ... we are here far too long and that is why we remember Holger stating that. But you can bet novice user will do exactly the same bug - will not clear the buffer.
> you should use COPY and INSERT whenever >possible if you don't want to bother with these kind of details. >
I know ;-) Look - I don't have such problems anymore and that is why I also told about the need of buffer clearance to Norman. My aproach is just a bit different - if I can see, that there is some area in which we can see repeated buggy aproach of programmers, we should try to avoid that - either putting it in the doc, or to change behavior. See below ...
>READ-IO and WRITE-IO *DON'T* enlarge the buffer. You have to >provide a large enough buffer for them, and a correct length value >too. Furthermore, READ-IO *DOESN'T* overwrite the buffer you >provide, but instead it appends to it if there is already some >data (this is a useful feature and not a bug). >
Why should read-io "append" to buffer? Would anyone mind if it would simply use preallocated buffer as a storage and used it each time from the head of a series? (kind of a reference word - pointer - to where read-io puts its data). If read-io is said to be low-level, I would expect it more than appending to existing buffer, because, otoh, it does not expand the series and truncates the result, if the buffer is too small - http://www.rebol.com/docs/words/wread-io.html
> For this reason, if >you don't want it do behave this way you have to provide it an >empty buffer. If the docs are not clear about this then this is a >bug in the docs, not in REBOL (Carl is using READ-IO and WRITE-IO >this way so I'm pretty sure it's not a bug ;-). >
I give up ... so we will see new users frustrated each time. They will loose hours of struggling with the code, no matter what me or you think is the correct aproach ...
>What was happening to Norman is that he was resending the first >packet every time. His proxy worked for other services because, by
<<quoted lines omitted: 9>>
>it each time. (If you look at the source for async:// you'll see >I'm doing exactly this.)
You could use another series for its further storage ... :-) -pekr-

 [25/32] from: g:santilli:tiscalinet:it at: 7-Aug-2003 15:39


Hi Petr, On Thursday, August 7, 2003, 1:19:54 PM, you wrote: PK> OK, that is just presumption. Novice user will not know that ... we are They should. I think it is clearly stated in the docs that they are lowlevel. If it isn't, then this is a bug. PK> can see repeated buggy aproach of programmers, we should try to avoid PK> that - either putting it in the doc, or to change behavior. See below ... In this case, is the documentation that needs to explain clearly what the purpose of these functions is. I don't see why they would need to be changed, considering that they are not even meant to be used by a "novice user" as you say. :) (They should be avoided by the expert user too, because REBOL offers a better way to do the same thing. You have to have a very good reason to use them.. :) PK> Why should read-io "append" to buffer? Because that could be exactly what you need. And while this behavior does not cause any problem to someone that does not need it (you just provide an empty buffer), the contrary is not true: if you wanted it to append (because the first packet is not enough for you to process, for example) and it cleared the buffer you would be forced to work around it (and at least you'd need to copy your data, which could be undesirable if you have to copy it again later while or after parsing). PK> I give up ... so we will see new users frustrated each time. They will PK> loose hours of struggling with the code, no matter what me or you think PK> is the correct aproach ... New users just need correct documentation. Or, better, to avoid this kind of "unrebolish" functions. ;-) PK> You could use another series for its further storage ... :-) REBOL is fast because you can write efficient programs with it. Let's not break this rule. ;-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [26/32] from: lmecir:mbox:vol:cz at: 7-Aug-2003 16:06


> >Actually, you're wrong. First of all, READ-IO and WRITE-IO are > >lowlevel functions;
<<quoted lines omitted: 3>>
> you can bet novice user will do exactly the same bug - will not clear > the buffer.
Even a novice user has to know, it is documented: USAGE: READ-IO port buffer length DESCRIPTION: Low level read from a port. I never used low level functions without a good reason and never complained, because I knew, that the bug was between the keyboard and the chair I was sitting on. Instead of writing things like: "Don't use your owen for animal drying!", I see the warning (low level) and the "lack of beginner documentation" in this case as sufficient. Everyone who ignores that has to be prepared for the consequences. Besides, it is highly probable, that the behaviour of low level stuff may change between implementations.
> I give up ... so we will see new users frustrated each time. They will > loose hours of struggling with the code, no matter what me or you think > is the correct aproach ...
A novice user has got a choice. (S)he can either use well documented high level functions or prepare for trouble. If the low-level stuff is useful, we don't have any right to change it, because it is just that - a low-level stuff.
> >PK> What do other think? Should write-io clear the buffer after succesfull > >PK> write automatically?
Why should a low-level function behave the way every beginner could use it? Then it wouldn't be a low-level function any more. Just my 0.10 CZK (Czech koruna). Ladislav

 [27/32] from: petr:krenzelok:trz:cz at: 7-Aug-2003 16:33


Ladislav Mecir wrote:
>>>Actually, you're wrong. First of all, READ-IO and WRITE-IO are >>>lowlevel functions;
<<quoted lines omitted: 15>>
>Instead of writing things like: "Don't use your owen for animal drying!", I see the warning (low level) and the "lack of beginner documentation" in this case as sufficient. >Everyone who ignores that has to be prepared for the consequences. Besides, it is highly probable, that the behaviour of low level stuff may change between implementations.
The problem lays in "low-level" word - I never cared about what does it exactly mean - once you try to find a solution, you just use what is available. It may be called ignorance, but for "novices", it simply works - the function is available, so why not to use it - kind of aproach. Unless I see NOTE: or STAY-AWAY kind of things in docs, a little "low-level" word means just nothing to me - I still expect things to work somehow magically :-) As I said - no matter what we think about it, Norman was just one of those ppl, who faced the problem, was not first, will not be the last, and that is the reality, not some this-is-low-level-you-should-know-what-it-means kind of theory suggestions. I was suprised that dictionary description of read-io is already very nice and informal. Maybe a small note as - beware - it is a good practise to clear your buffer in your while loop ... etc. would be sufficient to save wasted hours of testing for those who reach read-io function ignoring what the "low-level" actually means ... ;-) -pekr-

 [28/32] from: maximo:meteorstudios at: 7-Aug-2003 11:28


> I was suprised that dictionary description of read-io is already very > nice and informal. Maybe a small note as - beware - it is a good > practise to clear your buffer in your while loop ... etc. would be > sufficient to save wasted hours of testing for those who > reach read-io > function ignoring what the "low-level" actually means ... ;-)
I agree, no one can guess such a detail. and many such details are CAPITAL in rebol? (like who could guess that "insert tail" is faster than "append"!). just take the topic of binding and context or parsing. It easily takes a year for a novice to realise the true potential and power of being able to USE this to their advantage. Its usually tought of as a bug when you start having such issues.... you struggle and then pow! you get like a flash... and your programming mentality completely changes... I'm sure many of you understand what I just explained. that's usually at about the same time you start being able to understand whenever Ladislav shares a code snippet. LOL ;-) ;-) ;-) really, when I started, I remember reading a 10 line script of his and finching my eyes for hours on end trying to "get it". I still do, sometimes. ;-) ;-) Eventually, we all get to a state, where its hard to illustrate with code because what we write gets so advanced, or is written with to many invisible facets (WRT novice eyes) without us realizing it. do you all realise the number of words core and view now have? its really a huge list. Its easy to miss many of them. I've taken to reading the dictionnary every two weeks, just to keep the whole list in my head... I just discovered the "has" word 2 months ago and I've been using rebol/core since v1.3 WE ALL agree that there are some details missing in the docs. There are so many answers on this list which get forgotten.... I really wish RT added a search engine in their docs page which referrenced, tutorials, dictionnary, the user guide all the how-to's, and of course, the web view of the list. They should make it obvious. An official wiki would also be cool. whenever I have a problem in python I go to the doc search page and I type one word or two words and I usually get several good answers, usualy by links right in the docs or through known forums and lists. this is an essential tool which REALLY makes python an easier language to approach than rebol (but it doesn't make it any easier to use ;-), sorry it sounds bad but its my 0.02 (in canadian $ ;-) -MAx

 [29/32] from: joel:neely:fedex at: 7-Aug-2003 11:13


Hi, Max, Maxim Olivier-Adlhoch wrote:
> I agree, no one can guess such a detail. and many such details are > CAPITAL in rebol? (like who could guess that "insert tail" is faster > than "append"!). >
Anyone who typed:
>> ?? append
append: func [ {Appends a value to the tail of a series and returns the series head.} series [series! port!] value /only "Appends a block value as a block" ][ head either only [ insert/only tail series :value ] [ insert tail series :value ] ] I'm not trying to be a smart-alek here, but just observing something that took me a LOOOONG time to learn myself; poking around under the hood is at this point the best way to understand some things (which is not a comforting answer for those of use without the luxury of lots of wander-around-and-explore time!) Until the eScribe subscription was broken, it was one of my main sources of research, as one could search the archive of emails at that site and find all sorts of juicy tidbits from past discussions! -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Counting lines of code is to software development as counting bricks is to urban development.

 [30/32] from: brett:codeconscious at: 8-Aug-2003 16:32


> I was suprised that dictionary description of read-io is already very > nice and informal. Maybe a small note as - beware - it is a good > practise to clear your buffer in your while loop ... etc. would be > sufficient to save wasted hours of testing for those who reach read-io > function ignoring what the "low-level" actually means ... ;-) >
Wow, never knew that you had to clear your buffer (seriously). Always good to learn something. :^) I was under the impression that read-io etc was necessary in some circumstances, but I cannot remember what. Any enlightenment by anyone? (please) Regards, Brett.

 [31/32] from: g:santilli:tiscalinet:it at: 8-Aug-2003 10:47


Hi Brett, On Friday, August 8, 2003, 8:32:37 AM, you wrote: BH> I was under the impression that read-io etc was necessary in some BH> circumstances, but I cannot remember what. Any enlightenment by anyone? BH> (please) Currently, READ-IO and WRITE-IO are only necessary for async ports, because they don't work as they should with INSERT and COPY. They could also be needed if you really need to achieve the maximum possible performance for whatever reasons, as beign lowlevel they could allow you to write more efficient code in some cases. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [32/32] from: brett:codeconscious at: 10-Aug-2003 15:33


Thanks for that Gabriele. Gabriel wrote:.....

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted