World: r3wp

while waiting on port without system/options/quiet

Ah, thanks.

Never heard about this.

http://www.rebol.com/docs/core23/rebolcore-18.html#section-4

And never read about it ;-)

http://www.hmkdesign.dk/rebol/files/category--macosx.html<-- perhaps 
this is relevant for OSX Tiger users regarding the spinning cursor.

Robert: the -q argument should squash it too...

REBOL used to have a graphical network indicator ... pity that is 
not controllable in this way too.

Anyone know of good ways to setup an email header so that spam scores 
are as low as possible? This is for legit emails I am sending via 
rebol. Perhaps you've never noticed it before but one I sent yesterday 
to myself ended up in the "junk" box. Anyway, you guys are smart.

dont sort by name to don't try to be efficent and send to multiple 
names in the same domain as the same time  don't send spamy content

Yeah, these are separate emails only sent to one person at a time. 
And the content is just simple words (these are tests) and no symbols.

I thought select/skip to be faster than select, it isn't, why so?

btw,I'm using a hash! , is there a faster way?

ok, looks like using 2 blocks, one for keys, one for values and using 
"pick values index? find keys key" is more than 20% faster

forget comment above, bed testing on my part, select on hash! is 
faster, but still, why is select/skip so slow on hash! ?

c: make hash! []
  repeat n 10000 [append c reduce [n "abc"]]
  timer[loop 1000000 [select c 4000]]            
;   0:00:00.350739
  timer[loop 1000000 [select/skip c 4000 2]]     
;   0:00:04.675077

whar are you storing as key in your hash! ?

integers like in your example ?

What is the easiest way to convert larger numbers so that they are 
stored as integers in binary.  Such that they can be read directly 
and converted such as:

to-integer #{3030ABCD1020}


I keep getting the wrong result of that operation and I know it is 
because the binary information contains the wrong data.

I'm hoping to avoid converting to string first which I know would 
then be easy.

to-hex <-> to-integer, except that's issue, not binary : (

Hmmm..  seems not an easy way to do that?

for example the actual binary representaton for the number 256 is 
#{0100}  But I can't get that output by doing:

>> to-binary [256]
== #{00}


See that  result is incorrect.  I'm assuming there is an easier way 
to do this.

i do this:
debase/base to-hex 256 16

== #{00000100}

>>to integer! #{00000100}
== 256

yeah but you get that extra bits  I would have to go back and trim 
off the first two bytes.

But that would work - thanks Steeve.

You could shorten it with parse?

ah you want a 16 bit integer ?

How is that different to converting to string?

hoping to avoid converting to string

yeah true Chris.

debase uses string data

>> debase/base skip  to-hex 256 4 16
== #{0100}

think that will be more overhead than just storing the string representation?

you mean time consumming ?

performance wise - yes

i'm using a preconstructed struct! [] to do the conversion (i don't 
use debase) , it's fast enough.

Give me an example.

bin: make struct! [int [integer!]] [0]

>> bin/int: 256
>>third bin
== #{00010000}

then , the reverse:
>> change third bin #{00010000}
>>bin/int
== 256

Yeah I'm going to have to make a function it seems.

just to know that with struct! the integer is stored in little endian 
format (reverse order)

so you can do that too:
>> to integer! reverse #{00010000}
== 256

my issue is a bit more complicated.

I'll come up with a solution - thanks Steeve, you still may have 
helped me out.

No all Rebol platforms store integers in little endian format.

Steeve thanks  for the help, I think I can get bye with the debase/base 
to-hex 256 16

Peter, no one says the opposite