World: r3wp

I don't think I will be working on mezz for a while there is a lot 
to do in Orca.

Jaime, what do you think the result of 1.2.3 + 0.5 should be ?  1.7.3, 
or 2.3.4  (rounding to nearest integer) ?

Well. I implemented in orca the same behaviour found in rebol. Do 
you think that it should be changed?

I hadn't even noticed that worked !

I would say - try to keep compatibility, while you are considering 
it now.

BTW, Everybody is invited to contribute to Orca's development effort. 
Initially if you have a patch email it to me, and we will reviewed. 
Once the core team are comfortable with the quality of the contributions 
the author will be given repository access.

Finished support of tuples for all operator actions.

XOR OR and AND have slightly different behavior than REBOL when arguments 
are a tuple and a number. ie:

O> 1.2.1 xor 2015.345 ;== 222.221.222
R> 1.2.1 xor 2015.345 ;== 255.255.255


Which behaviour the community prefers? I believe orca's implementation 
is more correct, but we can change it.

Does anyone use such feature bitwise ops between tuples and numbers?

It's great to find out about this project. It would help a lot if 
any of you know the developers of the two previous related projects 
(sievertsen.de - freebell.sf.net) and (softinnov.org - dockimbel 
- r#) and get them to contribute to Orca. It looks like orca is very 
close to getting some momentum !

Carl has a point though.  Orca needs to be BETTER than Rebol, or 
at least as good.

I didn't pay RT $1200+ to help develop Rebol.  Forget that noize.

Jaime thanks for asking...But there's not a simple answer.

The point I am about to make applies to any proposed variant in ORCA 
vs REBOL.


The problem with changing fundamental behaviour is that it makes 
it hard to port applications: think a few years ahead when ORCA is 
a fully operational REBOL clone, and (as an example) (unlike REBOL) 
runs on PDAs. I'd like to use ORCA so I can run an application in 
a PDA; but I want to use REBOL for all my other platforms. And I 
don't want to have to pick through code and/or support two source 
versions because of avoidable differences in behaviour.


On the other hand, an ORCA-only application might benefit from the 
"more correct" implementations of basic operations.


One possible way to square that circle is to have a set compatibility 
flag:
    system/orca/xor: false  ;; gets me REBOL XOR behaviour

I just have to wrap that in an 'attempt and I can keep a common source 
that will run under either.


[I appreciate that there may be performance issues doing it that 
way -- may be better to have compatibly options specified in an orca.r 
file that is only processed at start-up....I'll leave the details 
to the people doing the design]

I vote 1.7.3

But as Sunanda said, compatibility should win, and may I suggest 
deviations should be "extra parameters"

Sunanda. I fully agree, and the reason for my asking. I will wait 
for a bit more input before deciding which route. An solution is 
to create rebol-compat mezz. That way you get the best of both worlds.

With only a penalty in performace for backward compatibility, specially 
when it is about correctness.

Terry, Out aim is to make Orca better than rebol, but first we must 
catch on ;-)

Joe, Both Dockimbel and Frank know about hte orca project and may 
decide to contribute, the project is open to anyone willing. I believe 
they are tied up with other commitments and may have their own plans 
for their clone efforts. I am interesting in collaboration and pragmatics, 
more that discussions. So Orca is open to anyone willing to collaborate 
;-)

I hope to see more skilled C programmers jumping at any point. But 
need more than programmers and designers. We need people documenting, 
testing, creating regresion tests, optimzing, etc.

Maybe some of these folks can help out on the open modules that are 
part of REBOL 3.0 too. And, we could always use more tests, etc.

I hope there is a lot of cross-pollination.

IIRC Doc did not planned to be 100% compatible either. IIRC he wanted 
to introduce two layers to networking. It comes from his experience 
when working with networking (Uniserve etc.). I think that redesign 
is the right time for language to correct/improve some of concepts. 
I expect REBOL 3.0 to go that route. 2.0 was rewrite too.

IIRC even Carl thought about e.g. some View min-face layered concept, 
at least I do remember it from some blog article. And that is that. 
I am the one who is willing to redesign my few apps for 3.0, IF, 
of course, it adds significant improvements .... so the same goes 
for Orca. If we feel that we have something in Rebol what is limiting 
(conceptual wise), I, in opposite to Sunanda (although understanding 
his pov), am for incompatibility, if done for good ...

... well, but I am not a designer, nor I am in situaion having lots 
of REBOL apps to redesign ...

and you can always use your old 2.x SDK to improve on your apps .... 
having time to redesign for new branch (3.0)

maybe Carl could nowadays tell us something about REBOL 3.0, as some 
info is leaking here or there ...

<<A solution is to create rebol-compat mezz>>

I've suggested to RT a couple of times that REBOL needs a compatibility 
mode for behaviour changes  between its versions.

That would give Carl the freedom to change things (like reverse vs 
head reverse) while guaranteeing (more-or-less) that applications 
continue to work unchanged on newer versions of REBOL.

Perhaps the ORCA crew and RT could exchange ideas on such a mode 
so we don't end up with incompatible compatibility modes.

tuple + number in rebol makes sense IMHO:
!> gray + 30 ; lighter
== 158.158.158
!> 1.2.3 + 0.5 ; i can round myself. i can not deround
== 1.2.3
!> 1.2.3 + 1.1
== 2.3.4

Sunanda, <<A solution is to create rebol-compat mezz>> we have decided 
to provide a compiler flag for backwards compatibility; so you just 
need to recompile to obtain previous behaviour.  We may investigate 
mode switching in the future, but we don't want to carry the bloat.

.

Some stats

Timing test - parse 2000 int/decimal

  Parser                    Seconds
  ---------------------------------
  Thune (C)                 0.0008
  Rebol (built-in)          0.0044
  Thune (rebol-style parse) 0.0097   ; work done in ()
  Rebol (parse)             0.0228   ; Just parse - no ()

Timing test on Lua's fib test.

   Language       Seconds
   ----------------------
   Lua 5.0        0.14
   Thune          0.20
   Orca           0.36
   Rebol          0.80

Basics ops benchmark, measured using Ladislav time-blk tools, results 
in seconds:

;REBOL
;getword  0.08612
;setword  0.2006635
;funccall  0.194279125
;make-object  1.750536

;ORCA
;getword  0.072630
;setword  0.133684
;funccall  0.177569
;make-object  0.917472

BTW. I forgot to mention lowe r is better. So, in some instances 
Orca is two times faster than Rebol.

because it is doing less?

No. As you see the benchmark for basic ops shows that Orca is already 
faster in what the interpreter does the most.

So, Orca can now has a full parse implementation?

Pretty much. It is being fine tuned currently

Jaime, is this something that could be compiled for my Sharp Zaurus?

Probably

Hmmm. It's like Core?

It's part of Core, currently

Thanks.

But some things are also nicer. It's designed as an embeddable library

well it can open guis too, no... using QT?

Yes, on Linux. Hm, maybe on Windows as well

I'll have to try to carve out a bunch of time. I've never compiled 
anything on my Z. Sounds like fun though.

Good luck :-)

Thanks....I'll need it.

Yes. It produces GUIs in OSX too. But you need to install Qt.