AltME groups: search

a little shortcomming of the actual function implementation. (which 
I hope will be addressed in R3 )

Jerry, if you're not aware, just a word of caution about line by 
line entry in the console; the console will attempt to mold the result. 
That means rebol will use at least the same amount of memory again 
just to create the molded string.

even if I do a to-block on [bogus-word] I get no errors.

I did a RAMBO on it... I understand the effects on current code, 
maybe it should be revised for R3?

Max, the reason behind repend there is that join "a" something and 
join "a" [something something-else] should produce similar results.

if you don't want the reduce, just use append copy "a" [something].

I use rejoin a lot to.

but not having to wrap everything in a block when you really just 
want to append a value to a copy is easy to read.

To Gregg,

I tried what you said. But there was a weird situation for the Windows 
Registry in my computer.

If I export these 5 HKEY_??? into 5 files, respectively, the sum 
of their size is 568 MB.

If I export all of them into 1 file. the file size is 316 MB, which 
is much smaller than 568 MB. I don't know why.

So the 5-file version of Registry-Diff in REBOL might use more memory 
if the GC doesn't work well.

I would like to know ...


1. How to use the OPEN function with the /SEEK refinement to replace 
the 1,000,000th byte with the 2,000,000th byte in a file.


2. How to truncate a huge file to its helf size, and keep the head 
helf only. 

Thanks.

My answer to your first question (from reading http://www.rebol.net/article/0199.html
)


>> write %testdata "123456789A123456789B"    ;; A simple test file

>> fp: open/seek %testdata                                   ;; Open 
the file in seek mode

>> fp: skip fp 19                                                
      ;; Move to 20th character

>> newval: copy fp                                               
  ;; Copy the 20th character
== "B"

>> fp: head fp                                                   
       ;; Position at start of file

>> change at fp 10 newval                                      ;; 
Overwrite 10th character

>> copy head fp                                                  
     ;; Check change made
== "123456789B123456789B"
>> close fp
>> fp: open %testdata

>> copy fp                                                       
             ;; Check file was changed
== "123456789B123456789B"

And loading the registry into a REBOL block is not a problem so far. 
I simply READ the registry-dump file as a string, then PARSE the 
long string into block:

parse-reg: func [ file /local str blk ] [
    str: read file
    blk: copy []
    parse str [ 
        to "[HKEY_" 
        some [
            copy txt thru "]" (append blk txt)
            skip

            copy txt [ to "[HKEY_" | to end ] (append blk trim txt)
        ]
    ]
    str: none
    blk
]

anyone got a function that converts rebol colours to html colour 
codes ?

Quick question. Assuming I have a script with the following in it:

	...
	either system/script/args [
	...

and the following in another script:

	do/args %my-script.r 42


what do I need to get it working remote. Tried the following without 
success:

	do/args http://www.my-site.com/my-script.r42
	do-thru/args http://www.my-site.com/my-script.r42

Any ideas?

By the way I usually do this in the script to ensure the args are 
always a block:
	args: compose [(system/script/args)]

what is the easiest/most direct way to convert an integer value into 
a 4 byte binary (equivalent to to a 4 byte unsigned LONG) ?


for some reason, this kind of thing is not 'simple in REBOL I expected 
this to work. but didn't even get a one byte binary.

>> to-binary 100
== #{313030}


100 is a numerical value, not a string, I would have expected (in 
base 16 which is default) :
#{64}

REBOL, being targeted at higher level use, hasn't made bit twiddling 
terribly easy in the past, to be sure, but if you're doing a lot 
of it, write a dialect. :-)

BrianH, launching them in different processes is my second choice, 
How do i do that? By using the LAUNCH native function, right? I've 
never used it before. I will give it a try.

I have noticed some REBOL experts designing their own protocols, 
which, by the way, are very cool. By "protocol," I mean the protocol 
part of an url, it doesn't have to have anything to do with networking. 
I would like to design my own protocol, too. So I can write:

>> print read DICT://English/English/Cheyenne
Cheyenne
-noun, plural -ennes, (especially collectively) -enne for 1. 

1. a member of a North American Indian people of the western plains, 
formerly in central Minnesota and North and South Dakota, and now 
divided between Montana and Oklahoma.  

2. an Algonquian language, the language of the Cheyenne Indians. 
 
3. a city in and the capital of Wyoming, in the S part. 47,283.  
>>


Is there any document I can read about this. Thank you for your help.

(I think I hit this problem already a long time ago..)

Hmm.. can't be a simple as that. I think READ determines the file's 
host platform somehow and translates accordingly.

I'm using it myself for http operations on a server.  and it works 
flawlessly.

if you have a potential for receiving Mac Files... (I was just about 
to give you this when you posted about mac ;-)

for a more unified conversion you could do this:


data: replace/all replace/all to-string data "^M^/" "^/" "^M" "^/"


this way if its CRLF it will strip them and if its only CR it will 
convert them.

that's a good thing.

Compared 10000 iterations on a 67k script.

This version corrects a bug in the above parse rule:

if you are doing to string! instead of as-string, then a copy version 
could be faster, when there are characters to remove.

alternatively you could create a dummy port handler to let the native 
code do the job for you.

anyone built a function to find duplicate elements in a block and 
return them in a separate block?

blk: [a b b c b a]
head foreach e unique blk [alter blk e]
== [b b a]

Henrik.   

Andrew created Tally.r    It wasn't exactly what you asked but maybe 
there's some value there "Tallies up the values in a series,  producing 
a block of [Value Count] pairs"

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=tally.r

you got me into a spin, I rarely do this kind of fun , here is my 
best and shortest solution:

(its also 3 times faster than Geomol's, using his block data ;-)

duplicates: func [serie /local word][

 remove-each word copy serie [same? find serie word find/last serie 
 word] 
]

>> duplicates [a b b c b a]
== [a b b b a]

you can add the 'unique call to clean up the block if you like 
>> unique duplicates  [1 1 2 2 3 4 5 5 6 7 8]
== [1 2 5]

This one does what you want, I think:
>> blk: [a b b c b a]
>> unique head foreach e unique blk [alter copy blk e]
== [a b]
blk is untouched.

And as a function:

find-dups: func [blk] [unique head foreach e unique blk [alter copy 
blk e]]

hehe... but I know he is addicted to it  ;-)  I had found my solution 
when I saw yours...  so I just did a benchmark for the fun of it.

Funny how the same thing can be done in so different ways with REBOL. 
I think, it's good. Choose the way, you like. Not many languages 
are like that. Again REBOL is much like a spoken language. You can 
say the same thing in lots of ways. Some say it with many words, 
some is short and precise, etc.

on a small block the speed is almost the same (mine a little bit 
faster)

i wonder if counting each value would be faster, probably not. sort 
being native helps a lot :)

Gabriele, your solution does not support words! 
duplicates [ a b c ] 
** Script Error: Invalid argument: a
** Where: duplicates

I don't know exactly, but I remember reading that its not a real 
encryption system.

No, /direct just allows control of rebol's memory buffer. Rebol goes 
out to the host filesystem via host OS API calls. The host filesystem 
may still not actually write the data to disk immediately. To be 
sure of an immediate write, you would flush the disk cache, using 
a mechanism provided by the host OS and filesystem. (eg. in WinXP, 
if you disable one of the harddisks, it flushes the cache, then spins 
the disk down. There must be another way to flush the disk, but I 
never learned that.)

in principle, there should be little difference. since write always 
creates a new file, and immediately closes the file port, they should 
basically be the same. I also assume that /append implies /direct 
in some way.

It appears to be a problem with the +-50 year window around the current 
year which Rebol uses to assign the century to two-digit years:

>> date-of-birth: 28-dec-1923
== 28-Dec-1923
>> age: func [dob [Date!] /local cutoff] [
[    cutoff: now
[    cutoff/year: cutoff/year - 50
[    either dob < cutoff [
[        return (now - cutoff) + ((cutoff - 1) - dob)][
[        return now - dob]
[    ]
>> age date-of-birth
== 30262

When I did a date-to-epoch func, I used ATTEMPT with DIFFERENCE and, 
if that failed, used subtraction to get the number of days, then 
multiplied by 86400.0.

I think the minimum time unit is milliseconds - thousandths of a 
second.

time really is quantized depending on the OS. XP SP 2 has got a bigger 
quantum than XP SP 1, which was 10 milliseconds IIRC

not just more digits, it has got a "lower basic quantum" too

Max, what I mean is that this isn't a showstopper. Adding 64-bit 
ints for this case doesn't seem worth it. There are other, more important, 
reasons to go there; I just don't think this issue is that important.

this is a very dangerous bug for any dialect writer... beware!

so we must not allow different type! representation of a value be 
considered different through the most basic type converting natives.

its an issue when you load data and make a dialect loader.  It just 
fucked up a week's work ... now I have to completely change the way 
I handle Integers...  had this broken early on, it would not even 
have slown me down.

I can work around it (obviously).. but its just a core REBOL consistency 
issue.


its semantically unacceptable for a function called  to-INTEGER  
 to return anything else than an integer.  imagine if to-string decided 
to return words sometimes... its the same dangerous issue.

many places this can be a total fuck up
imagine this:

as-integer: func [value][
	any [
		attempt [to-integer value]
		0
	]
]


here we end up with a broken logic and impending doom...not of our 
fault.

hehe  load also returns a decimal... I guess THAT is where the to-integer 
reaction is comming from deep inside.

but LOAD's reaction would be open to subjective debate.  to-integer 
cannot return anything else than an integer... it just makes no sense. 
 the primary goal of the function is to have as a return value a 
specific type.

AH HA!  I have a fix !

>> to-integer #a
== 10

the question is, would there not also be a performance hit if you 
need to check for wrapping inside your rebol code?

OTOH, the safest solution is to either yield a meaningful value when 
appropriate, or cause an error

moreover, "yielding a meaningful value" is faster than "causing an 
error"

but a meaningfull value is subjective.  what is meaningfull in one 
context can be your worst ennemy in another.

if we don't know that input data is invalid within REBOL (like an 
integer specification which does not fit inside an integer) then 
I don't see why REBOL should try to cope.  its plain logic to me. 
 this decimal issue can drag around a LONG time before you realise 
what is going on and by that time... its a hard thing to fix.

Max, this isn't necessarily "something screwy". It's entirely possible 
that you know how REBOL works, and you expect it to behave that way, 
so you're not surprised. REBOL *can't* know anything about how it's 
being used, so all it can do is behave a certain way, and the onus 
is on us to deal with it. The important thing is knowing how it works, 
so we know what to expect. 


REBOL is pragmatic. How many times have you seen this particular 
discussion, or issue, debated since REBOL was released? Obviously, 
not too many people have been hurt by it enough to make much noise. 
That said, I'm all for more consistency. WRT divide-by-zero, there 
are some langs that have a NAN (not a number) vals to represent infinity 
and things like that; again, it's just choices.

but do you agree that make integer! returning a decimal is a bug, 
whatever the reason?

I will shut up now!!  (hehe, seems I'm getting beaten by a few sticks 
this week.  Though I like the discussion, I feel I am going to be 
tagged as a troll, by those who might not like the noise a few threads 
are generating compared to the whole .   ;-)

I am just a bit concerned that some functions should be too pure 
to return alternate values when input is not "perfect".

this is like to-integer and as-integer.  the later could ALWAYS return 
an error, even when the input is obviously wrong and return 0.  but 
to-integer should either return an integer, raise an error, or maybe 
none instead... which is gradually being accepted as a softer error 
value... llike the switch to first/second... etc.

I understand your arguments. But let's take a look at the following 
example:

    abs -2147483648


The -2147483648 is a result in the C language (using wrapping). Python 
uses a "larger" datatype and raising an error is yet another option. 
All three variants are "reasonable" in a sense, but we may pick only 
one of them.

I must say that I "don't like" -2147483648, because it violates the 
fundamental mathematical principle, that ABS cannot yield a negative 
value.

indeed within mathematical operations, there is acceptible leniency 
in a "pragmatic" language like REBOL, and I agree completely.

but as you say about abs, there, the return value is the result of 
a mathematical expression.  so it is consistent throughout REBOL 
maths, that some equations return decimals, when values go out of 
range of integers.... just like power 2 32

actually, power 2 0 yields a decimal!, even though it might return 
integer! (but this is more efficient when comparing code size)

people who code in C are programmers.  there is no doubt about it. 
 and indeed, if they choose C, there are reasons, and they expect 
a harsh and unforgiving environment.

so for maths, I'd rather have a function which does not go haywire 
like the wrapping which can occur, which you describe, even if its 
slower... simply because its completely out of the reach of the reason 
of why I use REBOL to have to understand this.

its a bit like the law, there is the letter of the law, and the meaning 
of the law.

we are at a crossroad (R3) where we can pick the best direction, 
that is why it is time to ask these questions

do you agree about a panel at devcon 2007 for some of the more pointy 
issues?

I would hope R3 beta/alpha would last a while for such issues to 
be compared empirically.

this might also raise REBOL's case about it not being a totally closed 
source effort.

My big issue with stuff like this is how people will use these kinds 
of examples to show how "stupid" REBOL is, and make them reasons 
not to use it, and to drive others from using it. e.g. "if it can't 
even return a positive value from ABS...". Doc'ing the behavior, 
even pointing out that it's more akin to how C might work, will go 
a long way toward that, but maybe not all the way.

I don't understand - there is no ideal way. The best possible way 
is to use one general principle. Such principle may be to let the 
arithmetic work like the C language arithmetic does (use wrapping 
for integer arithmetic). Another principle is to use the "Python 
principle" - use a "more general datatype", if the original datatype 
is unable to represent the result. And the third alternative is to 
cause an error if the original datatype cannot represent the result. 
I think, that the slowest is the "error causing principle". The most 
unsafe is the "wrapping principle". The "more general datatype" looks 
like the most comfortable.

I agree, we must not think in terms of how C does it, this would 
be a step backwards.  REBOL is more natural than that...

BUT as I said earlier, this must not contradict the first principle 
of an expression's meaning.  if abs means "return a positive VALUE" 
then that's what it should first and foremost.

on a completely other note, I'd really like for rebol to adopt IM 
protocols.  did you know that a recent survey here showed that only 
30% of teens use e-mail?

if we could actually code IM apps as easily as we can send mail, 
then REBOL would Definitely attract attention to a younger crowd.

(this is a suggestion for R3)

I've forgotten .. how to restore a url encoded string ?

errr.. perhaps there isn't a native function to do this ?

It looks Rebol's lexical parser detects #"<" without space at the 
end as a tag!

>> load [< ]
== [<]
>> load [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) load [<]
>> load [<a ]
** Syntax Error: Invalid tag -- <a
** Near: (line 1) load [<a ]
>>

it seems so ... but wouldn't we expect a block?

so it looks like a bug to me. There should be added a condition where 
the '< is at the end of loaded block imo.

Yes, a bug probably

Ok, Rebolek and anyone else, Syntax errors should not be called "crashes". 
A crash is something more serious which takes down the interpreter.

lexical parser should give precedence to ] followed by a space, as 
it is a closure to initiated block, no? :-)

Hmm.... I think "medium".  It's good to also note in your bug report 
why it was a problem for you (the space was sucked out of the block).

I have a little question regarding extern library useage...

I am supplying a string! to a function, which is supposed to be used 
as a buffer.

cause If I send a string filled up with 100 spaces, I actually get 
some chars overwritten and a 0 char where it should...