r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

BrianH
26-Nov-2011
[9821]
There's no easy way to add an MP3 type yet, because there's no audio 
type concept in R3 yet. But .jpg is supported already.
Marco
26-Nov-2011
[9822]
wish for R3 / Topaz / Red / World:
Add common charsets and parsing rules to system object:
system/parse: context [
	digit: charset [#"0" - #"9"]
	upper: charset [#"A" - #"Z"]
	lower: charset [#"a" - #"z"]
	alpha: union upper lower
	hexdigit: union digit charset "abcdefABCDEF"
	bindigit: charset "01"
	space: charset " ^-^/"
	digits: [some digit]
	decimal: [opt digits "." digits | digits "." ]
	exponent: [ [ "e" | "E" ] opt ["+" | "-"] digits]
	float: [opt "-" [decimal | digits] opt exponent]
	email:...
	...etc.
]
BrianH
26-Nov-2011
[9823x2]
No need to add them to the system opject in R3, just export them 
from a module and they'll be available. They should be made read-only 
for security, but this is a good idea.
R3 PARSE rules can reference charsets and rules from path references, 
so they don't even have to be exported as raw words.
Marco
26-Nov-2011
[9825]
The Rebol system object is a very nice thing. I would pack it with 
all sort of things, especially those that can be "global" to a program 
or even "global" to many Rebol programs.
BrianH
26-Nov-2011
[9826x3]
Modules extend the system object, in particular system/contexts/lib 
(aka lib), and the per-task (as planned) context system/contexts/user 
gets its values from there. The system object is actually going to 
be per-task, referencing global objects through system/contexts/*.
The main global contexts are system/contexts/lib, system/contexts/lib 
and the module contexts. All non-private modules are just as global 
as lib and sys.
sorry, that second system/contexts/lib was supposed to be system/contexts/sys.
Marco
26-Nov-2011
[9829]
wish for R3 / Topaz / Red / World:

I wish that refinements would be totally reworked (not R2 compatible 
:( ).

Current situation with some examples:

view/new/title/offset/options win "Dialog" 20x20 'resize

remove_last: func [{remove last (n) element(s) of a series}
	serie [series!] /n num [integer!]
	][
	num: any [num 1]
	remove/part skip tail serie negate num num
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /only
	][
    head either only [
        insert/only tail series :value
    ] [
        insert tail series :value
    ]
]

New situation with different syntax and default values:

view win /new true /title "Dialog" /offset 20x20 /options 'resize

remove_last: func [{remove last (n) element(s) of a series}
	series [series!] /n: 1 [integer!]
	][
	remove skip tail series negate n /part n
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /part /only /dup
	][
    head insert tail series :value /part part /only only /dup dup
]


Note that append could also be redifined as: #macro append [] [head 
insert tail]
BrianH
26-Nov-2011
[9830]
You might want to check out the way Topaz does function options - 
it's even better than that :)
Marco
26-Nov-2011
[9831]
Topaz options are nice but not nicer for my tastes.
BrianH
26-Nov-2011
[9832x3]
Make your own then :)  I'm not blowing you off, it's a real suggestion.
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.
BrianH
2-Dec-2011
[9835x3]
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?
Steeve
2-Dec-2011
[9838x2]
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
BrianH
2-Dec-2011
[9840]
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.
Steeve
2-Dec-2011
[9841]
console
Geomol
2-Dec-2011
[9842x3]
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
BrianH
2-Dec-2011
[9845x2]
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.
Geomol
2-Dec-2011
[9847x2]
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.
BrianH
2-Dec-2011
[9849]
Seems that could be tweaked with pragmas, right?
Geomol
2-Dec-2011
[9850]
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.
Kaj
2-Dec-2011
[9851]
R3 is typically about a third faster than R2 in my tests on Linux, 
even with my CMS that mostly does text processing
Henrik
5-Dec-2011
[9852x2]
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?
Pekr
5-Dec-2011
[9854]
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 ...
Endo
5-Dec-2011
[9855]
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)
BrianH
5-Dec-2011
[9856x2]
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.
Henrik
5-Dec-2011
[9858]
It is possible to make this directory under OSX, as far as I can 
see.
BrianH
5-Dec-2011
[9859]
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.
Marco
11-Dec-2011
[9860]
wish for R3 / Topaz / Red / World:

callback! datatype so you can "really" use a lot of nice shared libraries.
Geomol
11-Dec-2011
[9861]
Do you have a simple example?
Marco
11-Dec-2011
[9862]
display: make callback! [...] [...]
glutDisplayFunc :display
Kaj
11-Dec-2011
[9863]
Red/System has native callbacks already. I'm using them in most library 
bindings
Marco
11-Dec-2011
[9864]
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?
Kaj
11-Dec-2011
[9865]
I've bound the standard C math library already, but it's waiting 
for the floats
BrianH
11-Dec-2011
[9866x2]
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.
Robert
11-Dec-2011
[9868]
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.
Steeve
29-Dec-2011
[9869]
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.
Ladislav
22-Jan-2012
[9870]
Wondering if there is an analogy of

    query/clear system/words