World: r3wp

As far as I know R3 Task! are going to be base in OS threads, they 
will not have shared state, but nothing has been said about how they 
will communicate with the environment, or how is the order of execution 
going to be guarantee.

.... to better maintain the task, Carl will opensource R3 :-)

got to go, later ....

From what i read Erlang works quite well. What problems?

A general-purpose concurrent language like Erlang or Ada has to include 
syntax for mundane operations such as arithmetic expressions, a coordination 
language need not specify anything more than coordination.

http://www.apple.com/macbook/macbook.html<-- Apple introduces the 
13.3 inch Macbook.

Jaime, you said "In Erlang you use msg queues and process-id. But 
msg-queues have some drawbacks." I was addressing that.

Not deep enough toin Erlang to judge about problems, but if you can 
explain :)

Jaime, from your link: "The real problem is not threads as such; 
it is threads plus shared mutable state. To solve this problem, it's 
not necessary to throw away threads. It is sufficient to disallow 
mutable state shared between threads (mutable state local to one 
thread is still allowed)."

I doubt a coordination language can do without general-purpose stuff. 
Messages must be queued, counted, somewhat verified etc.

And then things may break, and distribution helps against that. If 
the decisions can be made smart. http://www.sics.se/~joe/tutorials/robust_server/robust_server.html

Another way of blogging? http://www.google.com/notebook/public/04439832352277312501/BDSJaSwoQtNrJ-bMh

Gabriel. I agree with that statement. So vanilla threads are a problem, 
and adding concurrency to language need to be done with care. How 
is R3 going to handle tasking?

Sun to opensource JAVA? - http://www.vnunet.com/vnunet/news/2156205/sun-promises-open-source-java

Nice new SONY mini PC line - http://www.reghardware.co.uk/2006/05/16/sony_unveils_vaio_ux/

http://www.google.com/trends?q=rebol&ctab=2&geo=all&date=all

Jaime: the idea is to have no sharing between r3 tasks. at least, 
no implicit sharing. i personally think we don't need any explicit 
sharing either. for the system parts that will be shared for efficiency 
reasons, the idea is that the user should not know/care.

will it be fast enough to write better servers?

we'll know after testing i guess, but i think it should be. i'm quite 
sure Carl know how to handle multitasking ;)

:-)

are you on-schedule for alpha at the end of May? In Unicode group 
Jaime gave some answer, which sounds a bit unsatisfactory, like it 
would not be decided yet, which way to go in that respect ...

Was Rebol written though from the point of multitasking?

From my early recollections, Rebol was designed for communications 
..as a scripting language.

hmm, maybe so, but can't you just plug rebol language into surrounding 
multitasking framework? They "just" need to address those sharing 
issues, interpreter states etc. As I expect language being rather 
complete, it can be done fast, if Carl decides to use some existing 
system. Not sure for tasking, it seems RT is going its own way, but 
e.g. event system is being replaced by libevent?

About Amazon andSOA: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388

petr: who says unicode will be in the first alpha? :) i think we 
should have it however incomplete. there are many things that need 
discussion (see the r3 blog), and it's much easier to discuss when 
you can try the new features.

:-) ok, ok .... looking forward to first alpha then :-)

Now Google goes completely mad :) http://code.google.com/webtoolkit/overview.html

hehe, they want internet to become OS .... and PC OSes to become 
just - commodities - non-important in its own, just a layer for internet 
networked apps :-)

this is pretty bad ... it opens up a lot of stupid cases... http://www.theregister.co.uk/2006/04/21/moderator_liable_for_comments/

Regarding multitasking and REBOL, how far is it possible to go using 
communication between tasks over the TCP protocol? I've implemented 
multi-user locking this way with a relational database in REBOL, 
and it works quite well. I haven't done stress-test, so I have no 
real measurement, how effective it is, and what the performance is 
compared to other inter-task communication methods. I'm working on 
an OpenGL implementation, where OpenGL commands are sent from a REBOL 
task to an OpenGL server task (written in C), which will execute 
the OpenGL commands, so I'm about to get more experience in this. 
Both tasks will run on the same computer, but can easily be on different 
computers, of course.


Anyone with more experience in task communication using TCP? Where 
is the limit?

hmm, I am not sure I like it ... you open a port and firewall jumps 
in

Geomol - I remember some material re linux and using tcp for IPC 
and someone said it is quite expensive - communication wise (headers, 
ack)

it should be imo done on low-level, just the queue should be exposed, 
like event queue .... well, not sure, Carl does it right hopefully 
anyway, so :-)

:)

RE: Google...I want internet to become OS as well.

John...cool.  Build an X-Windows like layer between Rebol and OpenGL.

Someone: explain the top at Google, what REBOL is, so they can put 
development capital in REBOL Tech.

Google - the funny point here is: They say code in java, compile 
to javascript. The first time i see it that way around. Till now 
i heard "use scripting to get it running, use java/c for big things/speed". 
Javascript must be really awfull :)

Geomol - that is why I am heading towards IBM :-) We will see, but 
I have too little knowledge to work there probably :-) Carl once 
said, that he would like to sell rebol to some big party .... IBM 
is the right one ....

Geomol: someone exlain google *where* rebol is. They do this because 
ajax-the-runtime is everywhere, but seemingly the worst way to code.

but Reichart tends to have lunch with lots of those top guys, so 
why not. IIRC BeOS got 50mil injection from Intel .... and Intel 
did not want any share or so - they just wanted to support good technology

Intel may have done that just to piss off microsoft during thier 
negotiations.

rebol->tcp-<opengl: could work. bottleneck is lots of request. In 
your case you would only do one request/frame. Copying the bytes 
on the same machine should be fast.

I'm developing a byte-code style for OpenGL commands, so little communication 
is needed. Only 1 byte for the command (gl, glu and glut commands 
are fewer than 256), and 4 bytes for most parameters. So many commands 
are fewer than 10 bytes of communication. It may not be fast enough 
for games, but I hope, it's fast enough to make tools and fast OpenGL 
prototyping (trying out ideas).

hum Geomol, is it possible to start a new group for this?  I'd like 
to support your endeavor with testing and I think this can become 
a big thread!

Maxim, in a few days, I hope. I'll speak up, when I have something 
concrete to show.

Geomol - just be sure you send enough data for OS to send two packets 
at least, or you will notice 200ms delay imo ...

hehe sometimes more is less  ;-)

Maybe make benchmarks first. Blast a realistic amount of data from 
rebol to rebol. Maybe by beer or uniserve, something fast.