World: r3wp

Macros make a lot more sense in compiled languages like Red, Topaz 
(to JS) and World (to bytecode) than they do in interpreted code-is-data-at-runtime 
languages like R3, where most functions are like macros.

One thing you might have to consider with your refinement suggestion 
is that you would have to put a lot of parentheses around function 
calls, because otherwise your syntax would make it ambiguous which 
function the refinement applies to. This is similar to the situation 
with Smalltalk and Objective-C.

R3 operations that would be slower than R2:

- Bulk string handling, because strings are twice as big (Unicode).

- Word dereferencing for function-context words, because they are 
stack-relative, adding an indirection.

- The fixed overhead of LOAD (like header handling) because it does 
a lot more.
Any others?

(This is continued from #World, where it was a little off-topic)

I haven't compared operator evaluation yet, which was another major 
change between R2 and R3. Overall, R3 looks a little worse for C-like 
code than R2, though neither are really appropriate for that kind 
of thing. And yet in my tests (which I don't have the results of 
handy, so take that with a grain of salt) idiomatic R3 is faster 
than idiomatic R2 for REBOL-like tasks, and the R3 idioms are less 
awkward to write than the R2 idioms. How have the rest of you found 
the differences to be in your work?

AFAIK, R3 always has been faster or equal in the early tests I made, 
that's why I don't understand the current situation.

I tested the loop example given by Geomol.
Same speed more or less.in R2 and R3

It should be if you are doing the loop directly from the console 
or otherwise using a object/module/script/closure context rather 
than in a function.

console

Under OS X:
Using R2:
>> time [n: 1000000 while [0 < n: n - 1][]]
== 0:00:00.219887
Using R3:
>> dt [n: 1000'000 while [0 < n: n - 1][]] 
== 0:00:00.339793

My R2 time is:

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

R2:
>> system/version
== 2.7.7.2.5
R3:
>> system/version
== 2.100.111.2.5

Well, that isn't affected by any of the standard slowdowns. I wonder 
if it's an issue with the difference in C compilers between the two 
versions.

There are a lot of problems with R3 on OSX, and different problems 
with R2. Annoying.

Using gcc, I experience up to 33% changes in some tests from compilation 
to compilation, so that could be.

I guess, it has something to do with, how lucky the compiler is maybe 
to get data on 64bit boundaries and make code parts/data fit in cache 
and such technical things.

Seems that could be tweaked with pragmas, right?

Could be. I need pragmas in a few places, but I haven't dug deeply 
into that area of compilation. It's boring, I think. :) And I haven't 
had time to look at things like LLVM, but that would probably solve 
some problems and speed things up even more.

R3 is typically about a third faster than R2 in my tests on Linux, 
even with my CMS that mostly does text processing

Neither R2 nor R3 considers it to be a problem making this directory 
in WinXP:

make-dir %.../


but the directory is never made, as far as I can tell. Doing it from 
a command prompt returns that the directory already exists.

Do you think this is a bug?

When I try to make three dot dir under Vista, it returns an error, 
and hence R3 hould return an error too imo. Ditto for invalid chars, 
not allowed being a part of the dir names ...

When I trace it, it "sees" the error but returns the path:
...
Trace:  return (word)
Trace:  path (word)
Result: (error)
Result: (error)
Result: (error)
Result: %.../ (file)

There is a cross-platform bug in R3 where it won't see any file or 
directory that starts with two periods, not just . and .. - the ticket: 
http://issue.cc/r3/1899

This may be unrelated though.

It is possible to make this directory under OSX, as far as I can 
see.

The particular error triggered in the Windows console when you try 
to make a directory with only periods in its name is that the directory 
already exists; this is probably a bad error. However, when you try 
to MAKE-DIR directories that already exist in REBOL, it's a noop, 
not an error. That is probably why it's not triggering an error here.

wish for R3 / Topaz / Red / World:

callback! datatype so you can "really" use a lot of nice shared libraries.

Do you have a simple example?

display: make callback! [...] [...]
glutDisplayFunc :display

Red/System has native callbacks already. I'm using them in most library 
bindings

Right. Red/System seems vary nice.

I am waiting for floats to be implemented in Red/System. Is there 
a "math" library that could be used intead?

I've bound the standard C math library already, but it's waiting 
for the floats

With R3 you can just callback functions if you want a synchronous 
call, or callback through an event if you want to go asynchronous.

Still, a generator of marshalling wrapper functions would be nice, 
especially since REBOL and C don't have similar data models.

But R3 can't deal very good with multi-threaded libs. You need to 
trick it: Use async with non or integer value to trigger a sync call 
on Rebol side.

Any info about the algorithms used to construct and perform lookup 
on symbol's tables in R3 ?
People gave some hints back in the day.
But I can't remember who.

Wondering if there is an analogy of

    query/clear system/words

Now that you mention it, I'm wondering that too. There isn't any 
tracking of state changes for R3 objects that I'm aware of, and there's 
nothing like system/words.

Well, it is not a big "disaster" for me, since it is not too hard 
for me to adjust the function I am writing for R3 with just a slight 
modification of the behaviour...

Ladislav, I think you already wrote something like that for R3?

newly-defined?: func [
	{do the given BLOCK and find the newly-defined words}
	block [block!]
	/local old
] [
	old: append append
		defined? system/contexts/lib
		defined? system/contexts/sys
		defined? system/contexts/user
	do block
	exclude defined? system/contexts/user old
]

Cyphre, it's not a good approach in R3

To track newly defined words in a context you can check the source 
of the function INTERN.

I may be completely missing the point, Steeve. How exactly can the 
source of the INTERN function help with detection?

Its tracking newly "created" words in the user context after a binding. 
It's maybe not what you're trying to do but it was in response to 
Cyphre.

What I (essentially) want is described in the help string:

    {do the given BLOCK and find the newly-defined words}

Can the source of INTERN cannot help me with that?

typo: "Can the source of INTERN help me with that?

I probably mistaken the words "newly-defined" for "newly-created"

I originally pointed out how implemented the functionality in R2 
(using the 

    query/clear system/words

expression.

You want to track the "modified" words, right ?

ok