r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Graham
26-Mar-2006
[1650]
Do all these crc functions require the whole file to be read into 
memory?
Vincent
26-Mar-2006
[1651x2]
Yes - both the native 'checksum and the published 'crc-32 works on 
a string! or a binary!, not a port! . For crc-32, the crc must be 
initialized at start, and complement'ed (bitwise 'not) at end.
- I have an internal function in crc32.r who allows working with 
big files and stream, but it isn't fully documented.
Graham
26-Mar-2006
[1653]
does it work though ?  :)
Vincent
26-Mar-2006
[1654]
well, I hope so - it's the fundamental brick ;) but it's not intuitive, 
usage exemple (depends of port access mode...): 

crc: -1 while [not empty? data] [ctx-crc-32/update-crc data crc data: 
copy/part source length] crc: crc xor -1
Graham
26-Mar-2006
[1655]
so, it has minimal memory use with gigabyte size files?
Vincent
26-Mar-2006
[1656]
crc-32.r with gigabytes files: [don't do it] - it works, the memory 
used isn't size relative - but on a 1GHz PIII, the speed is < 300 
kbytes/s! 
rebcode version is a lot faster (>2Mbytes/s), but 
1) rebcode isn't part of official releases 
2) the rebcode version of 'crc-32 needs whole file in memory.

so, back to RAMBO: #3650 - I vote for 'crc32 as another 'checksum/method, 

and maybe a RAMBO ticket for a port aware version of 'checksum would 
be a good idea.
Oldes
6-Apr-2006
[1657x3]
I think this is a bug:
>> read http://www.paseka.cz/obalky%5C80-7185-652-5.jpg

** User Error: URL error: http://www.paseka.cz/obalky\80-7185-652-5.jpg
** Near: read http://www.paseka.cz/obalky\80-7185-652-5.jpg
What can I do?
I don't want to translate the url encoded chars:(
>>  http://www.paseka.cz/obalky%5C80-7185-652-5.jpg
== http://www.paseka.cz/obalky\80-7185-652-5.jpg
Anton
6-Apr-2006
[1660x2]
This works:

>> net-utils/url-parser/parse-url port: make port! [scheme: 'http] 
"http://www.paseka.cz/obalky%5C80-7185-652-5.jpg"
>> port/target
== "obalky%5C80-7185-652-5.jpg"
>> port: open port
connecting to: www.paseka.cz
>> close port
>> port: open/binary port
connecting to: www.paseka.cz
>> bin: copy port
== #{
FFD8FFE000104A46494600010100000100010000FFDB00430008060607060508
0707070909080A0C140D0C0B0B0C1912130F141D1A1F1E1D1A1C1C20242E...
>> close port
>> image: load bin
== make image! [200x280 #{
968662958665918168584B3A2A1D15281E1C241B1C1D1717211D1C211D1A
1F1E1A1F1E1A1F1D1E1F1D20211C23211C23211C202...
(Oops! Obviously you can remove the first open & close port in text 
mode. Not necessary.)
Oldes
6-Apr-2006
[1662]
I understand, thanks. Anyway, I submited it into Rambo.
Anton
6-Apr-2006
[1663]
Ahh.. of course you do! (I thought it was strange me helping Oldes.)
Gabriele
6-Apr-2006
[1664x2]
encode the % as %25
ie. use http://www.paseka.cz/obalky%255C80-7185-652-5.jpg
Cyphre
7-Apr-2006
[1666x4]
what about this?
read to-url "http://www.paseka.cz/obalky%5C80-7185-652-5.jpg"
or more correct in this case:

pic: load read/binary to-url "http://www.paseka.cz/obalky%5C80-7185-652-5.jpg"
sorry, this is correct:

 pic: load to-url "http://www.paseka.cz/obalky%5C80-7185-652-5.jpg"
Ladislav
19-Apr-2006
[1670]
I am having a serious problem:

    parse [*] ['*] ; == true

but

>> parse [/] ['/]
** Syntax Error: Invalid word-lit -- '
** Near: (line 1) parse [/] ['/]


The same problem exists for '// . Is there a way how to circumvent 
it?
Rebolek
19-Apr-2006
[1671]
I'm afraid there isn't. This is same as the "comma bug"

>> parse [.]['.]
== true
>> parse [,][',]
** Syntax Error: Invalid word -- ,
** Near: (line 1) parse [,][',]
Pekr
19-Apr-2006
[1672]
it seems 'parse needs some overhaul?
Ladislav
19-Apr-2006
[1673x9]
this is the way: parse [/] [set w word! (nx: unless w = first [/] 
[[end skip]]) nx]
the same way can be used for [.]
(but is is not very elegant, I admit)
hmm, the situation with comma *can* be handled this way too, but 
comma normally isn't a REBOL word
yet another word of this kind: '<>
and '<
and '>=
another "problem":
>> first [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) first [<]
>> first [< ]
== <
PeterWood
19-Apr-2006
[1682x2]
I reported that the interpreter doesn't accept get-wrods startting 
with < (#3641)
get-words !!
Gregg
19-Apr-2006
[1684]
>> lit-slash: to lit-word! "/"
== '/
>> parse [/] [lit-slash]
== true
Chris
19-Apr-2006
[1685x2]
>> first [< ]
== <
Sorry, I came across this recently too...
Ladislav
19-Apr-2006
[1687]
thanks, Gregg, that looks more readable
Gabriele
20-Apr-2006
[1688]
I use to lit-word! "/" too, it's the best way.
JaimeVargas
20-Apr-2006
[1689x2]
I guess there is a problem with rebol loader, because it needs quoting 
of some "special" chars.
The rebol parser should understand '/ and not required to-litword! 
"/", specially when the latter is a valid expression.
eFishAnt
29-Apr-2006
[1691]
Gab or some RAMBO editor, can you update RAMBO ticket #4087

there is a workaround from Edgar which is to so system/ports/serial: 
[ttyS0 ttyS1] to patch the ubuntu port of REBOL.  I suspect that 
can be done in a future release for ubuntu, but at least for now 
I have a workaround.
Gabriele
30-Apr-2006
[1692]
done.
Anton
2-May-2006
[1693x2]
I've got an interesting bug:  If you enable the outer detect, the 
inner detect receives a face object to its EVENT argument. Weird.
view layout [
	face with [ 
		init: [
			size: 600x400

			pane: layout [
				my-list: list 600x400 [
					my-text: text 600 feel [
						detect: func [face event][
							print ["inner -" mold type? event]
							event
						]
					]
				] data [["hello"]["there"]]
			] 

		] 

		feel: make face/feel [
			detect: func [face event][
				print ["outer -" mold type? event]
				event
			]
		]
	]
]
Gabriele
2-May-2006
[1695]
happens only with iteration?
Anton
2-May-2006
[1696x4]
I have to spend some more time stripping it down, removing layouts 
and list etc.. but can anyone see anything wrong ?
I think so.
Oh, by the way, you need to put your mouse over the text for any 
events to be sent to the inner text face, in order to see the bug.
(I spent six hours isolating this from my enormous scroll-table style, 
so don't be mad at me for too much code right now.)