World: r3wp

hello

A test of SIZE-TEXT shows a bug in R2. This should hopefully not 
be present in R3.

The test to run:

f: make system/standard/font [name: "Verdana" size: 12]
g: make gob! []
t: import 'text
g/text: bind [font f bold true text "Boo"] t
probe size-text g				; I get 26x14 here
g/text: bind [font f bold false text "Boo"] t
probe size-text g				; I get 25x14 here


It's possible that the result may vary, but the bold version should 
produce a wider size than the normal one. if you can test this similarly 
to what you did for R2, that would be great. Thanks.

R3 2.100.110.3.1 on Win 7 gives 27x14 for plain and 26x14 for bold 
text (both 1x0 bigger than yours).

Really? So, the bold font is *smaller* than the plain font?

Not, but you've reversed the order of plain and bold in the test 
for R3  :D
So, it's 27x14 for bold and 26x14 for plain text, actually.

ok, good.

Nope, still post them here. We still work on R3, and some of us use 
it professionally.

wish for R3 / Topaz / Red / World:

Add possibility to extend "read" and "load" to let them transparently 
load also custom file types (.tiff, .mp3 etc.)
Use something like:
system/mime: context [
	JPG: context [
		extensions: [%.jpg %.jpeg ...]
		header: #{JFIF}
		open: func [...]
		read: func [...]
		load: func [...]
		save: func [...]
		write: func [...]
		close: func [...]
	]
	...
]

R3 has that (codecs), but we would welcome any suggestions you would 
have for making them easier to use.

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.

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.
]

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.

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.

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.

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]

You might want to check out the way Topaz does function options - 
it's even better than that :)

Topaz options are nice but not nicer for my tastes.

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.

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?