World: r3wp

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

Anyone got a robust dialect for dealing with command line, or other 
parameters passed by dropping ?

Is there a way that I can constrain a listening port to only accept 
connection from localhost? Using:
	open tcp://:40000

opens a listening port on port 40000 for all connections. Something 
like: open tcp://:127.0.0.1:44000

you can check on incoming adress, no?

Robert - look at port/remote-ip item ...

Does this work or is it your assumption?

Why shouldn't it work? IIRC IOS worked that way too, or it was some 
other script I saw. The simplest "firewall", by IP address ....

Opening local tcp listening port, waiting for connection. Then opening 
second console, connecting to first one:

local-ip: 127.0.0.1
remote-ip: 127.0.0.1
local-port: 8008
remote-port: 61532

Robert, look at Maarten's Rugby source. He allows IP filtering, which 
may be all you need, or at least the clue.

Graham, I started an experimental command line dialect long ago, 
but it wasn't targeted specifically at file drops.

Is it around still?

Need to look for the public location, if there was one, or just look 
at what I have here. 


Are you dropping on a desktop icon, or using the system port to file 
drop on a console window? (I assume the former)

mainly passing thru command line