World: r3wp

If anyone has hex-edit.r and could post to library...or link...it 
would be appreciated.  I didn't plan to have my computers down.  
It is IOS/Developer/Users/Ryan-Cole/Utilities ... IIRC

Have you tried this?

append System/ports/serial 'ttyc0

port: open serial://port3/9600/8/none/1

This way you don't need to modify the binary et all.

Hi Jerry, "I know that we can use the JOIN function, but a + operator 
for string would be nice too. Why doesn't REBOL do so?"


Do you think it would be nice because it's more readable, or because 
it's familiar to people coming from languages that have it?


I came to REBOL with a long BASIC history, and it didn't take me 
long before I didn't miss + for concatenation at all. + is really 
a math op; I like REBOL's consistency, and I like the way REBOL concat 
code reads.

Jaime...thanks, but I get the same error ... Access Error:  cannot 
open ttyc0

ttyc0 is actually there, and ttyC0 is not (in the /dev directory) 
and I have tried root  and normal passwords.

but I am running AltME on ubuntu now.

did you try with ttyc1 etc as well? ttys0?

Why won't you just copy ttyc0 to ttyC0 so you will have both versions?

Never mind. That doesn't seem to work.

Try this:

system/ports/serial: [ttyS1]

port: open serial://port1/9600

Steve, Regarding "access error" are you sure you have enough user 
rights?

I tried logged on as root and as normal user, both give the same 
error.

Edgar...that WORKED!...yahoo!

still need to test with the devices...(so how did you ever figure 
that out?

Search the net for normal C-serial port access.

Linux uses ttySx and Cygwin uses comx.

now the whole controller can be done in REBOL.

Are you from Italy?

No, I am from LA.

you city's name can be juggled to "Legs On Sale"

I was experimenting with CoLinux. Got tired of DualBoot.

Actually my City is Norwalk but LA is more known.

well, thank you very much...this is very exciting.  I had tried ttys0 
but never thought to try ttyS0, since in /dev it is ttys0

Hi, I need some help with BIND (I think that's what I need to use): 
I have a storage context, that has a bunch of function to handle 
the storage of other contexts. That those storage functions can work, 
they need to have access to the other context. I could do:
storage/save-record context-to-save ...

but I would like to do: context-to-save/save-record.

and avoid dubplicating the storage code in every context, or write 
stub-functions that reference the storage stuff.

Is it possible to bind the storage functions dynamically to the context 
that should be saved and switch this binding in the app depending 
on which context should be stored?

In other languages this is called delegates (IIRC).

Example:
context A [a: 1 b: 2 c:3 list-words: none]
context storage [list-words: does [probe first self]]

How can I execute storage/list-words in the context of A? So that 
I get back [a b c list-words]

I think I need to switch the way it works:
	do bind [first object] storage

Is this the correct way?

no it isn't...

>> c1: context [a: b: none]
>> c2: context [a: b: none]
>> do bind [a: 1 b: 2] c1
== 2
>> probe c1
make object! [
    a: 1
    b: 2
]
>> do bind [a: 100 b: 200] c2
== 200
>> probe c2
make object! [
    a: 100
    b: 200
]

Oh sorry, you specifically want to bind a function's body to the 
context.
Let's see, I think this will work:
	bind second get in storage 'list-words A
	storage/list-words

What's this SECOND about?

Just getting the function body.

>> A: context [a: 1 b: 2 c: 3]
>> storage: context [list-words: does [probe first self]]
>> storage/list-words
[self list-words]
== [self list-words]
>> bind second get in storage 'list-words A
== [probe first self]
>> storage/list-words
[self a b c]
== [self a b c]

read as: "bind the body of list-words to A"

Ok... now I think I got it. I was always trying to bind the WHOLE 
function, not only the body...

Yes, bind needs a block! value, not a function!

A function! is a more complex value, which contains a spec and a 
body.

You wouldn't want to bind the whole function, which would probably 
imply binding its spec block as well, since that would unlink the 
argument spec block relative to the body block.

Although, now that I think about it, that *could* be useful in some 
circumstance, maybe.... Many functions with similar argument lists 
could share a context.

ok. Thanks a lot.