World: r3wp
[Core] Discuss core issues
older newer | first last |
Terry 2-Nov-2007 [8839] | just thinking that if you encrypt an object, it probably starts the same for all. |
Rebolek 2-Nov-2007 [8840] | I need to sort some French words but REBOL's SORT puts accented characters on the end (sorts just by ASCII). Has anybody got some enhanced SORT for French? |
Gabriele 2-Nov-2007 [8841] | terry: it depends a lot on the crypt algorithm used and the length of the key. it surely helps to know any part of the plain text. however, just compression would reduce that a lot (since the result depends on the whole string); also good algorithms are usually smart enough to resist a simple attack like this. |
Sunanda 2-Nov-2007 [8842] | Sorting: you may be able to adapt this hungarian code: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMWWJ |
Rebolek 2-Nov-2007 [8843] | thanks Sunanda |
Henrik 3-Nov-2007 [8844x2] | a: make object [ b: make block! [] c: b ] same? a/b a/c == true ; OK d: make a [] same? d/b d/c == false ; how do I get this to be TRUE? |
apparently I need to do it in the spec block, though i had hoped this could be done inside the object to encapsulate that entirely. cleaner code. | |
[unknown: 5] 4-Nov-2007 [8846] | if your just looking for evaluating the value then use equal? instead. |
Ladislav 4-Nov-2007 [8847x2] | Henrik: this may not be what you want, but it works: d: make a [c: b] |
(your problem is, that cloning does not use much "intelligence", in the case of d: make a [], the cloning code just copies both a/b and a/c and therefore it is obvious, that two copies aren't the same block | |
Henrik 4-Nov-2007 [8849x2] | ladislav, yes, that's what I had to come up with. |
paul, d/b and d/c must be the same block, so equal? is not enough. | |
Oldes 8-Nov-2007 [8851] | Is there any script for LZW decompression? |
Allen 8-Nov-2007 [8852] | Oldes. These might help? http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=gunzip.r http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebzip.r |
Oldes 9-Nov-2007 [8853] | No.. these are based on zlib compression... I was interested in LZW. Here is just a compression http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=converter.r ... never mind... I don't need it . It was just for fun. |
Graham 10-Nov-2007 [8854x5] | this is puzzling me ... it's a little loop to remove old files |
foreach f read %./ [ if f <> %. [ inf: info? f probe d: inf/date if all [ inf/type = 'file (difference now d) > 1:00:00 ][ attempt [ delete f ] ] ] ] | |
** Script Error: difference expected set1 argument of type: series bitset ** Where: do-boot ** Near: difference now d | |
using 2.5.0.10.1 | |
ok, fixed. updated to latest Rebol for Solaris sparq. | |
Robert 11-Nov-2007 [8859x3] | Is this consistent? I don't think so: >> a: make hash! [] == make hash! [] >> b: make block! [] == [] >> a == make hash! [] >> b == [] >> |
The hash! property shouldn't be returned, instead just an internal flag. | |
I can use hash? to check for it. | |
Henrik 11-Nov-2007 [8862] | well, I think returning the type in the console can be quite useful. if anything, it's block! that's being inconsistent. |
Robert 11-Nov-2007 [8863x2] | In the console yes, but this longer stuff will be returned in code as well. And this makes parsing a bit complex. |
>> reduce [a] == [make hash! []] >> reduce [b] == [[]] >> | |
Henrik 11-Nov-2007 [8865x3] | how? parsing will immediately return whether it's a hash! or a block!. if you need to keep that information, the block of hash! blocks should be serialized first. |
>> type? first reduce [a] == hash! >> type? first reduce [b] == block! | |
>> c: mold/all reduce [a b] == "[#[hash![]] []]" >> load c == [make hash! [] []] >> first load c == make hash! [] >> type? first load c == hash! No information loss. | |
Robert 11-Nov-2007 [8868] | I mean if you provide a reduce [...] to some parse rules and you have a "make hash!..." in the block you need to parse this. Hence, the parse rules change if you use block or hash. |
Henrik 11-Nov-2007 [8869x2] | I'm not sure I understand. If you have "make hash!..." as words, then your block is not properly serialized. |
which would indeed make the parsing a bit more complex. | |
Ingo 11-Nov-2007 [8871] | Hi Robert, can you give us a an example, where you have this problem? I can't see it. >> h: make hash! [3 4 5] == make hash! [3 4 5] >> b: [1 2 3] == [1 2 3] >> parse reduce [b] [into [some [set i integer! (print i)]]] 1 2 3 == true >> parse reduce [h] [into [some [set i integer! (print i)]]] 3 4 5 == true |
Robert 12-Nov-2007 [8872x2] | 'key-word set key-word [block! | word!] (... |
So, not when parsing for the content but for the block as is. | |
Gabriele 12-Nov-2007 [8874] | Robert, what you see at the console is the output of MOLD. there is no 'make and no 'hash! there. if you are *saving* the hash in a file or sending thru tcp and so on, use MOLD/ALL (or SAVE/ALL) so that hash! can be loaded properly afterwards. |
DanielSz 12-Nov-2007 [8875] | Is there a built-in function that returns the platform we're running on (Windows or Linux or Mac or whatever)? |
Sunanda 12-Nov-2007 [8876] | it's encoded in system/version this script decodes it for you: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r |
DanielSz 12-Nov-2007 [8877] | Thanks, Sunanda, much appreciated. |
Steeve 12-Nov-2007 [8878x2] | http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r |
arg !!! too slow | |
DanielSz 12-Nov-2007 [8880] | :) Thanks to you, Steeve. |
Ingo 12-Nov-2007 [8881] | Hi Robert, do you mean, this? >> b: [a b c] == [a b c] >> h: make hash! [a b c] == make hash! [a b c] >> parse reduce [b][block!] == true >> parse reduce [h][block!] == false because a hash!, is a hash! and not a block? >> parse reduce [h][hash!] == true Then you should use any-block! >> parse reduce [h][any-block!] == true >> parse reduce [b][any-block!] == true |
DanielSz 14-Nov-2007 [8882x3] | There is a nice script that encodes strings to utf-8. It is by Romano Paolo & Oldes. I'd like the reverse: decoding utf-8 strings. I found a script by Jan Skibinski proposing to do that, but the script doesn't load in rebol, exiting with an error ('map has no value). What's next? |
Ok, I think I got what I need. Jan's script can be salvaged, if only part of it. | |
BTW, I noticed that rebol.org serves pages in utf-8 encoding, but the scripts themselves are latin-1. This is not a problem for the code, but it is a problem for the comments, which may contain accented characters. For example, names of authors (hint: Robert Müench), and they consequently appear garbled. I'm not saying pages should be served as latin-1, on the contrary, I am an utf-8 enthusiast, I think rebol scripts themselves should be encoded as utf-8, (it is possible with python, for example). I hope Rebol3 will be an all encompassing utf-8 system (am I dreaming?). | |
btiffin 14-Nov-2007 [8885] | UTF-8 is being discussed as part of R3 Unicode support. All encompassing? Dunno. Well thought out and robust? I'd bet on that one. |
DanielSz 14-Nov-2007 [8886x3] | Well, on that same note of optimism, allow me to declare in forthcoming R3 syntactic style, rebol: "vive la rébolution" |
And why not even rébol: "rébolution"? | |
That is to say, not only should there be utf-8 string datatype, but words themselves should be utf-8 compliant. | |
older newer | first last |