World: r3wp

Anyway, we should shift groups. This is the wrong one. But, I am 
very interested in some kind of voting method.

is there any way that the community can 
vote" on what priorities it considers important ?"

..................yup.

Altme is buggy.

  Graham...........on that I have to call BS!  AltME has less bugs 
  in it that almost any multifunctional application I know of.  It 
  should get a bloody award.

One thing worries me. AltME hasn't change much in the last two years. 
I haven't add anything beyond its basic functionality, however two 
major bugs have persited during this time:
- Recycle bug
- Losing postings

!AltME group?

So, it is not perfect and this is not a contest about who has less 
bugs, but how can the supporting technology response quickly to address 
the problems that an end-user application has.

In two years those issues were not removed. Not new features were 
added. In the eyes of some developers that raises eyebrows.

(cloacking back to hack in orca)

Reichart, this was in response to Carl saying effectively that Altme 
was bug free .. saying that some developers were able to work past 
perceived bugs.  This was not a criticism of Altme per se.. but to 
refute that assertion.

I'll answer t this in AltME.

Orca can be found at trac.geekisp.com/orca

http://trac.geekisp.com/orcaclick on timeline to track progress

svn://svn.geekisp.com/orca if you want to download the develpment 
code

Back to my question does anybody care on Ops working on tuple decimal 
combinations?

I guess it would be nice but I wouldn't consider it high priority

Any one wishing to monitor the advancement of orca on a daily basis 
can suscribe to this RSS feed.

http://trac.geekisp.com/orca/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss

Firefox locked up on me when I tried that.

oh well, I reported the problem to microsoft.

Strange it works here with my RSS reader (not a browser based one). 
You can find a direct link at the bottom of this page http://trac.geekisp.com/orca/timeline

nice to see some mezzaines to check for different types of tuples 
eg. reserved local addresses, and multicast addresses while you're 
blazing in this area.

I posted mezzanines for this sometime ago. I don't know in which 
version of rebol world. Any how, I will package them again and post 
them to rebol library.

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