World: r3wp

For fun this next example is totally equivalent.

name: "black"
red-ctx: context [name: "red"]
green-ctx: context [name: "green"]
blue-ctx: context [name: "blue"]
names: reduce [
	name
	in red-ctx 'name
	in green-ctx 'name
	in blue-ctx 'name
]


; Names is now a block that contains four words of different colour 
(context binding)
probe reduce names

Except of course for that fact that red-ctx does not have a field 
green-ctx!

Ammon. On your point 3 above. "If the word exists in that context 
then it is set there, if not then it grabs that context's parent 
until it has made it to the global or top level."  No, it doesn't 
work this way. There does not need to be runtime searching.

It is more like this...

Look at my nested context example, and focus just on the 'name words.

(1) When the first context function is encounted during evaluation, 
it has a single argument a block - which happens to contain 5 values. 
A set-word, a string, a set-word a word and a block.

(2) Now when this first context function is evaluated it creates 
a new context, and binds to this context the all 'name words it can 
find in the block and nested blocks. To visualise this imagine all 
the 'name words including within the nested blocks have just changed 
Red.

(3) After this colouring of the words, the block is evaluated (as 
in DO) so that at some point the second reference to the Context 
function is evaluated.

(4) Like the first, it colours the name words in its block and nested 
blocks - let's say to green.
(5) The final level is blue of course.

(6) By the time all evaluation is finished the 'name words have the 
appropriate bindings (colours). Conceptually, maybe even actually, 
the innermost 'name word has had its binding (colour) changed three 
times, the second level one twice, and the highest once.


In this way there does not need to be any runtime searching for "parent" 
contexts, because the words themselves maintain the references to 
the appropriate contexts. The Set function does not need to search 
it can see the binding (colour) already.

Heh, I guess I'm hard to understand. ;~>

This particular subject has come up a number of times since I started 
playing with REBOL in 2000 but for some reason I can't seem to make 
the point that I am attempting to make everytime it comes up.  I 
think I'll leave it alone now...

lol - the context of our understanding keeps changing ;-)

Something like that. ;-)

Ammon: "1. It has to be happening during runtime there is no compiling."
load-time and loop-time then? ;)

ammon: "3. If you use a set-word in a context then that word becomes 
part of that context.  If you use SET then it reverts to the context's 
 "parent context" or the context in which the context itself is defined."

Thats the important point: there is no reverting :) and so there 
is no need to keep track of parent-contexts.which is quite clever 
:)

What is the quickest way to transform this :
	[ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
into this :
	[ "a" 11 #toto "b" 28 #titi "c" 3 #pim ]
???

Fastest, I don;t know.  But this works:
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
loop length? xx  [append xx xx/1 remove xx]
 head xx
== ["a" 11 #toto "b" 28 #titi "c" 3 #pim]

Close to being fastest:
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
x: copy []
loop length? xx [insert tail x xx/1 xx: next xx]
x

A time function to measure the speed of code:

time: func [:f /local t0] [t0: now/time/precise do f now/time/precise 
- t0]

Now you can do e.g.:
time [loop 40000 [
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
x: copy []
loop length? xx [insert tail x xx/1 xx: next xx]
]]

foreach b  [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ] [append 
 [] b ]

If you want faster execution you should initialize the block [] outside 
the loop

Has onyone manged to use Core with an iSeries (AS400) FTP server.

I have had no success at work .... it trying to read a folder in 
the IFS (Integrat File System) but the server returns a FTP error 
250.

(I dont have all the details on me at home).  Now looking at the 
FTP error numbers 250 is a normal return code, so I dont understand 
why I am not getting any information back.

I am using core 2.6 under winXP .... and connecting to a Linux server 
is working OK.

Didec, i should do: parse b [any [h: set x skip (h: change/part h 
x 1) :h]]

Philb, try my ftp client

On your website Romano?

yes

i it does not work, try the nlist flag

Thanks all

nlist flag?

I will give your handler a try tommorow ... thanks Romano

Is there a load path for the 'do function?

You mean like a PATH variable in a dos or unix shell environment 
?

As far as I know, do only looks in the current directory (as returned 
by WHAT-DIR) for relative files.

okay, that's what I thought. I was hoping that I'd just missed something.

It would be easy to roll my own "include" function. I might try that 
as a little project.

Yes, it's relatively easy. Just don' t think it's going to be quick 
:)

heh. I'll bear that in mind.

Actually, I don't know what you have in mind exactly so I shouldn't 
comment. But I and a few others have systems of our own, so feel 
free to ask how they work.

Isn't what slim does ? Holding paths for code library (scripts) and 
allowing to just slim/load %script-name.r where the file is in one 
of the folder in slim path !!

I mean Maxim's Slim !

quick newbie question .. how does one convert binary to string ?

no matter .. dehex

Note the subtle difference between dehex and to-string

And, if using a beta with AS-STRING, it's kind of a raw cast that's 
fast.

Nice, missed that one.

what is the difference anyway between 'dehex and 'to-string  and 
'as-string ?

>> A: [%23%67%68%69]
== [%23ghi]
>> dehex A

** Script Error: dehex expected value argument of type: any-string
** Near: dehex A               ;dehex doesn't work with blocks
>> to-string A

== "23ghi"                ;to-string converted it to a string and 
de-hex only some of the characters.
>> A: {%23%67%68%69}
== "%23%67%68%69"
>> dehex A
== "#ghi"              ;dehex works on all parts of the string

No idea about as-string, dun have that beta.

er whoops nevermind the first part of it - didn't realize it dehexed 
part right away lol

Hey that looks like a bug - it won't auto-dehex the first part of 
a block, but works on the rest no problem:
>> A: [%70%70]
== [%70p]

I think it's because rebol think its a file! due to the first percent 
sign

> A: [%70%70]
== [%70p]
>> type? a/1
== file!

>> A: [%%70%70]
== [%pp]

That's interesting... I wouldn't have thought that.. Thanks!

anyone got a parse rule that tells me whether the text constitutes 
a fully qualified domain?

Does REBOL/Core (or any other version) support the IMAP protocol?

yes .. limited