World: r3wp

Coordination can help prune non-determinism, coordination is different 
than communication between threads, lazy evaluation and continuations 
couuld help here, using a declarative approach to the whole computation 
can help get rid off non-determinism. The basic ideas are found in 
the CTM book.

Gabriele, Do you have documents that delienate how the communications 
between tasks will happen?

ideas == principles

Jaime, not yet, but most likely each task will have a message port.

Volker, Do you really mean this "Complete determinism makes no sense 
with parallel IMHO", the idea of paralellism is to  be able to perform 
any computation  done by a sequential machine faster, a random paralell 
machine may have some uses, but none of the mainstraem ;-)

huh, cool discussion - not that I would understand most of the things 
:-) Don't you want Pierre to join us to help you find the correct 
philosophy? :-)

Getting Real Work Shop - 

https://workshop.37signals.com/

   Getting Real is about getting the interface right before you get 
   the software wrong. It's about less software, making change inexpensive 
   and constant iteration. Less paper, more work. Less talk, more walk. 
   Getting Real is about deliverin

What sense makes perfect determinism with multiple physical inputs 
, like sensors or people entering data? The entries and their order 
is slightly off anyway.

It must be determined that things are processed, but not where and 
when.

Has anyone made rebol software to fill out forms scanned from paper?

Whoops. Wrong group, but I'll not post again.

that would be reading with OCR?

No. Just scanned in as graphic file.

I also want to save the data so I can edit it and fill out the form 
again later.

huh?

that sounds a little ineffective?

I am thinking the data would be in a layer above the graphic form. 
Click in the right spots, fill in the right data, print out the completed 
form, then save the data with the form  for later use. Something 
real simpe anyone can use.

There are still companies using paper forms, and I have to fill them 
out by hand. No fun.

that sounds like XForms to me

openoffice 2.0 has a free XForms implementation. it can save PDF's 
like this so you can edit them like a real form. I haven't worked 
with it deeply, but I think you can save data from them in a database.

edit them like a real form
 => edit them like a real form in adobe reader

OK, thanks. I''ll check it out.

An image can be used as a backdrop to a layout.  Stick some fields 
on top and you're done.

or just make your own form

What sense makes perfect determinism with multiple physical inputs 
, like sensors or people entering data? The entries and their order 
is slightly off anyway

 You can still have deterministic computation even in such situation. 
 We do have that today with any multitasking OS. Or would you like 
 to have your programs to produce any random result?

Volker, The fact that events can arrive at any given time doesn't 
mean that you can not have deterministic paralellel computation.

No, i want my program to have s much determinism as needed. I call 
"perfect determinism" when i know "this stuff is done on cpu3, then 
the other thing a bit later on cpu4". That is perfectly repeatable. 
But that is not what i need. "this stuff is done on the next free 
cpu" is enough. But to do that, i need a language which can determine 
what this next free cpu is. And for that i need a general purpose 
language (counting cpus, acountig used time, priorities etc). While 
you said general purpose is not needed for a coordination language. 
But maybe i miss simething, maybe coordination means something different?

I never said that you need or not a general purpose language. As 
matter of fact, I don't think being general purpose has anything 
to do with concurrency. What I understand is than any new features 
that add concurrency  to  a language should do so in a manner that 
avoid non-deterministic results. Some languages have already accomplished 
 this goal, usually avoiding  threads. Threads operate more at  the 
OS level than the language one. So I hope R3 bring us good concurrency 
features, that ensure that our programs are deterministic, otherwise 
we could be shipping programs that at first glancelook correct and 
 will work, but could  fail later in production as the paper points 
out.

I understood that the should be a coordination language coordinating 
stuff written in general purpose language. instead of putting coordination 
features in those languages.

And Erlang seems to work good, based on general purpose with threads 
and messages.

And their main priority is reliability, so correctness.

Hmm, did i miss a link?

this paper?

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

Sorry, Jaime, my last comment was aimed at Pekr..

.... yes, and even I did not understand your point - last line was 
mentioning some shares number. Generally I don't like companies missusing 
weak patent system ...

Jaime - the paper, well. Still need to do some reading. But I do 
remember some liboop link page paper, which referred to another paper, 
where other guys were defending threads and "demystified" myth that 
tasks are better ....

Yes, it seems the benefit of deterministic parallel computation is 
not understood.

If I have 10,000 computations, I might like to send half of them 
to task 1, and the other half to task 2, so they can be processed 
simultaneously by different cpu cores in a multi-core cpu.

Some of those computations may rely on the results of computations 
being performed by the other task, so that means some coordination 
between the tasks is needed occasionally.

Can't find it - but I remember I was moning somewhere surrounding 
following resources - http://www.kegel.com/c10k.html

moning=moving

hehe, it was you Jaime, who posted link to also following article 
- Why events are a bad idea - http://www.usenix.org/events/hotos03/tech/vonbehren.html

so now - are threads a problem, or events a problem? Where is the 
truth ...?

ah, it is about event based aproach vs threading, not task based 
vs thread based one ...

Basically, he argues are lot that threads and shared memory can not 
work,

suggest alternatives Erlang has, mentions Erlang in one sentence, 
and says a real solution must work with mainstream-languages. The 
last point is a good one. But not in our case, because rebol is as 
non-mainstream as Erlang. So we need no hybrids, and lots of this 
arguments are moot.

This diagrams look to me a lot like some things connected by message-streams.

But i do not know how this MapReduce-library etc. works, maybe i 
miss something cool.

http://labs.google.com/papers/mapreduce.html

Yet another attempt to be able to pull information out of the morass 
that is the WWW: SPARQL
An SQl-like language for turning RDF data into subsetted XML:

http://www.xml.com/pub/a/2005/11/16/introducing-sparql-querying-semantic-web-tutorial.html

If it catches on like RSS has, that'll be another publishing channel 
many websites will need to add.

Structure writing with LyX - http://www.freesoftwaremagazine.com/articles/documents_with_lyx

structured

The release of Syllable 0.6.1 got REBOL on OSNews:

http://osnews.com/comment.php?news_id=14669