[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