World: r3wp

Alright, not "most of the time", just in this case. For others:
>> 1 + 1.0
== 2.0
>> 1 + $1
== $2
>> 1 + 100%
== 2.0


Maybe that's why it seems weird. I guess that since R3 char! values 
are currently limited to the codepoints in the BMP they are 16 bits, 
so converting back to char! would be a potential loss of range. It 
could go either way, so I guess the datatype-on-the-left rule is 
a way for the developer to specify which they want. And that rule 
applies to string types too (for INSERT and APPEND), so it's not 
completely weird.

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

I don't like this inconsistency though:
>> "a" > "A"
== false
>> #"a" > #"A"
== true

Too bad we don't have a hierarchy of inequalities. Only two levels 
would be needed. Maybe a /case option to the functions that the the 
operators map to? Is it even possible to map an op! to a function 
that can take an option?

Perhaps the relative comparison functions could be made to all be 
case-insensitive (for datatypes that have case defined as a concept), 
and have additional STRICT-* case-sensitive functions which would 
combine the functions and STRICT-NOT-EQUAL?.

We have a ticket for an improved equality comparison hierarchy:
http://www.curecode.org/rebol3/ticket.rsp?id=1834

I think that would nicely fit with a inequality comperison hierarchy 
as well (strict vs non-strict).

Nicely fit with an inequality comparison hierarchy
, of course. Bad typing day, I guess.

The term "relative comparison hierarchy" may be better, since it 
wouldn't include NOT-EQUAL? and such.

The STRICT-* relative comparison functions wouldn't have operators, 
unless we could come up with some that don't look like line noise 
(or worse: Perl).

Andreas, given that Carl is one of the ones who was tripping over 
the equivalence hierarchy (that he helped decide on) that ticket 
looks pretty promising. The caveat is that Ladislav is the one who 
would likely be doing the work, and he seems to need some convincing. 
Plus, it would require a new R3 release, not just a host kit update.

Ladislav is the one who would likely be doing the work, and he seems 
to need some convincing

 - I do agree, that LESSER? etc. functions having two versions (or 
 a refinement, or something) would be useful.

I was talking about http://issue.cc/r3/1834but that's good to hear 
too :)

hello

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.