World: r3wp

http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl&
<--- interesting link from that site.

Looks like they have a Pet emulator.

I had a gold fish once. Died after a week.

oh... THAT Pet.

a port of REBOL would double the amount of software available

the system can build itself, including the kernel, common drivers, 
and all servers (112 compilations and 11 links) in less than 6 seconds 
on a 2.2-GHz Athlon processor.
   Yeah! I'm starting to get interested.

The Problem with Threads http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html

hmm, I read some doc when I was looking into liboop and libevent 
etc., somewhere on those sites, but each of groups tasks vs threads 
had some valid points ....

I have heard RT will go with threads, because those are optimised 
on multi-cpu environments?

Pekr, the article is not so much about which concurrency model is 
good or bad. The paper contentionis  that the emphasis on developing 
general-purpose languages that support concurrency is misplaced. 
Lee believes that a better approach is to develop what he calls "coordination 
languages", which focus on arranging sequential components written 
in conventional languages into some concurrent configuration (I suppose 
that piping in a Unix shell could be considered a limited coordination 
language). For concurrent programming to become mainstream, we must 
discard threads as a programming model. Nondeterminism should be 
judiciously and carefully introduced where needed, and it should 
be explicit in programs.

(Taken from LtU. More info on this topic here: http://lambda-the-ultimate.org/node/1481)

hmm - so even task concurency? concurency in general? then we should 
not have task? But how is that we accept multiplexing, which is kind 
of "concurrency"?

I will read pdf .... till the section where mathematic equations 
start :-)

Concurrency is fine. The problem is how to use it. Is it implicit 
or explicit. How you coordinate msg passing, pipes, shared state, 
etc.

so if Carl brings us task! based upon threads, and we don't need 
to care about threads related headaches in rebol level, then even 
threads are ok for us, right?

Depends on how they guarantee the order of execution. For examplie 
in Mozart/Oz you can have a concurrency that ensures that the sequence 
of computation is maintained, just like if was sequential even though 
is executed sequentially.

Sorry executed in paralell.

In C threads you do this buy using Locks and Semaphores.

In Erlang you use msg queues and process-id.

msg-queues would be on pair with rebol imo ... we already have event 
queue, we have blocks and their accessor functions ....

But msg-queues have some drawbacks.

hopefully Carl knows threads headaches (I do remember his long time 
ago post to ml :-) .... and will do it the right way ...

Lets see what the wizard brings us ;-)

if threads are said to better utilise multi-core cpu, then I expect 
R3 to be ported to PS3 soon :-)) ... or even next gen SUN's Niagara 
III, utilising 64 cores :-)

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.