World: r3wp

Back to REBOL on Java, I expect that the REBOL on .NET bindings would 
be semantically similar. We would be better off if we tried to make 
them as similar as possible in low-level semantics, so more code 
will be portable between Android and WinPhone7, for instance.

yeah there would be overlap....  but it would be the proper place 
to argue about new ideas, changes in the language, naming wars, etc, 
  how *should* it work


the other groups, IMHO, are meant for more "getting things done". 
  how *does* this work?.

wrt REBOL on JAVA...  probably only the host-kit would be an issue.

not sure REBOL on JAVA would be usefull nowadays. JAVA is dead :-) 
REBOL on JS would be interesting though :-)

And even slower

The host kit would be an advantage if we are going the native library 
route. All we would need is to create hosts that asct like Java-like 
or .NET-like native extensions.

Java is not dead on Android (yet). I am very interested in REBOL 
for Java because of this.

yep... I meant that it would be only thing which would really require 
changes to make it work... the rest is just bits and memory allocation, 
which is being run within the loaded app.

Never pronounce something dead, as it will live longer

Kaj: Amiga? :-)

Many things. REBOL, for example

REBOL is much deader than Java, for example

Trying to game the system, Kaj? :)

Just explaining the system...

Petr, Java the language has lost a lot of its shine, though you'd 
be surprised how widespread it still is in lots of companies. The 
thing is that the JVM is still a great platform to target and there 
are languages like Clojure and Scala which compile to this VM and 
their rapidly rising popularity will keep the JVM around for a long 
time to come. Remember, by riding on the JVM you instantly cover 
a whole bunch of platforms at once.

yeah, in most ways, the JVM bytecode specification is outliving both 
JAVA and the JVM itelf.

since the bytecode spec can be translated to other targets too. (androids 
own VM)

I think I know how JAVA is positioned. IT is one of the main corporate 
platforms - JAVA vs .NET. 10 years I was in the JAVA world, now 4 
years I am living in MS world :-) It is just apart from that, I know 
noone who would use it for his/her private project - too complex, 
unnecessary. But - as Max says - there's JAVA, and JVM, and the latter 
is more interesting for us. The question is, how can we integrate? 
Are we about to create some wrapper, which would allow us to utilise 
JAVA classes for e.g., or are we up to "porting" REBOL into JAVA 
entirely?

Pekr, I think you are dreaming like I am.

The idea is really nice. Having REBOL onto JVM or onto .NET using 
DLR would be really a dream.

Also I don't know which complexity is behind this kind of porting. 
Nice to read something about this from the gurus.

I think there are 2 ways : make a Jebol like Jython or make REBOL 
work on a JVM like Groovy or Scala. 

Jebol why not but I think there is no professionnal need behind. 
Because REBOL is very lightweight.

But make REBOL work on JVM  is very interesting because in that way 
REBOL could work on any device that has a JVM.

For the futur of REBOL, make it work on Mobile Phone, Tablet PC and 
WebOS is really important !

Can a couple of people check this bug on non-Windows platforms, please?
   http://www.curecode.org/rebol3/ticket.rsp?id=1753

Same problem on Linux:

>> mold tangent 89.99999999999986 
== "399405529304859.^O"

Looks like a MOLD problem, not a TANGENT problem.

>> type? tangent 89.99999999999986
== decimal!

Right. But it's only a problem when it is displayed or molded (regular 
display calls MOLD).

Yes, this was meant to illustrate that it's very likely some kind 
of MOLD issue.

Without the MOLD I see: 
  399405529304859.î

That decimal fraction part appears differently between alpha 110 
and alpha 109...Not tested in older versions.
   399405529304859.?   ;; alpha 109

>> mold tangent 89.99999999999986
== "399405529304859.$"

I have a question.

Somwhere, between Rebol Wiki and BLOG appeared an article about OBJECT 
creation and what is copied and what is shared.
Do you remember the exact position ?

Don't Mind. I have found the link: http://www.rebol.net/w/index.php?title=Copy_Semantics&redirect=no

hmm, we are preparing for the beta - finally! Carl is working on 
the Projects/Roadmap site, the list is gone and we will get new one. 
I wonder if we will be able to influence that. My bet is that we 
will kind of rush for beta, so things like tasking will be postponed 
for 3.1 :-)

where does it say this?

http://www.rebol.com/roadmap.html

Expect the community to take over the things it can improve on its 
own.

Yes, I can fear that "excuses" already, as it happened in the past 
too :-) E.g. tasking being part of host, and hence delegating the 
responsibility to the community, while that thing is absolutly fundamental 
to being designed properly, not just hacked-in ...

Excuses

 is the total wrong word and interpretation. We had this topic over-and-over 
 again: A lot say "Rebol is bad because it's not open-source.", well 
 I want to ask: "How many of you have contributed to the parts that 
 you can work on now?"

Taling is easy, doing is hard.

And doing is different than designing imo, and that is my point - 
some things should still be under the supervision of RT, especially 
things that need to be designed very carefully and precisely. I have 
nothing against various experiments done by the community ....

My list of what needs to be fixed/done before we can consider beta, 
in CureCure tickets: #539 (likely as definitional return), #851, 
#1509, #1515, #1518, #1519, #1520, #1742, #1743, maybe #1744, #1758, 
#1759. Plus all the PROTECT bugs. There isn't a single one of those 
that isn't more important than tasking or a new codec model.

And yes, I even have the numbers memorized. That is how important 
they are.

And now you can add #1760 to that list.

OK, so will you talk those tickets with Carl? Because - I might surprise 
you, but I prefer consistency and bugs fixed, instead of new features 
added (of course if adding those features later will not break things 
:-)

And #1521 (which is a side-effect of #1509 getting fixed).

I'll try to get in touch with Carl over this.

This one is a poll question everyone should not have trouble to answer. 
In R2, the USE function initialized the local values to #[unset!] 
for better user protection. In R3 (implementation quirk) the local 
USE variables are initialized to #[none!]. Which alternative do you 
prefer?

I, personally, do not mind much, but, depending on the result of 
this poll, I intend to adjust my policy when judging other cases, 
e.g. new functions, that are not yet implemented.

I think it should be the same, as if you were to use those values 
local to a function. Aren't they set to #[none] there too?

I sometimes have a tendency to write code like:

use [blah] [...body...]

and later move that code to:

func [/local blah] [...body...]

and it would be nice not to have to change the body.

Aha, OK, so 1 for the current R3 implementation.