World: r3wp

I think you are correct. But, as soon as we are confident in 3.0, 
we should put it out, even if missing a few features.

For example, the new REBOL.com website runs on R3 scripts.

I am fully for R3, and to not look back. Did you notice, how positive 
reactions you got to initial Host release? Hopefully that cooperative 
aproach works. But in some areas, we NEED design leadership. So - 
that is why I put a note to my "marketing" related docs, stating 
that simply transferring the responsibility to the community, might 
not see the features delivered.


So - maybe you could blog a bit - hey, guys, tasking's next. If you 
want it, try to prepera following details for me .... 1) 2) 3), etc.

I totally agree with you here.  In fact, I won't accept anything 
that does not meet my requirements.

yes, so hopefully you can now understand, why I objected to your 
(taken from Project plan) words: "Also, this list is only for R3 
core operation and does not include community-based projects such 
as graphics, GUI, protocols, documentation, and other features that 
can be developed externally, depending on the needs of the community."

I can (well, maybe I even can't :-) imagine, how picky you might 
be about the code quality. So it is really not imo enought to state 
- hey, guys, here's host code, who does the best task implementation, 
wins a bottle of Rebol wine :-)

I know that BrianH might not agree with me. Community can do some 
research, reference implementation, but I would expect stuff like 
tasks being DESIGNED (not implemented) by the author of first multitasking 
operating system himself :-)

OK, going to sleep, 2:30 here ... and soon enough Doc might jump 
here, that I turned his group off-topic ...

Steeve seemed to imply that R3 has its own thread scheduler. Is that 
true?

No.

I thought so :-)

I think he's referring to the R3 Device timeslicer.

Is that based on async I/O or something?

Yes.

But not all devices are async.

So, if no devices have "work to do" then we sleep for a short period 
of time (as long as that period is greater than the minimum dispatch 
time for the host CPU.)

We have more adjustments to make on this. E.g. OS X burns extra CPU.

I thought Henrik would have it fixed by now. ;-)

Ah, I remember that. Good info

Carl, I'm not a C programmer, so I can't fix that stuff. :-)

@doc: is there macos version of cheyenne?

Endo, I run Cheyenne off my macbook, script version, though. Runs 
fine.

Thx. Does not it require be compiled? Console should be stay open 
I guess, there is no service edition on MacOS?

No compilation necessary. Services are builtin: launchd

I use Lingon to create services and then use the launchd console 
to load and manage services.

Ok. Thanks a lot.

Endo: you can run it on OS X either from sources or using a binary 
version from here : http://cheyenne-server.org/download.shtml

Doc: is this the session-problem fixed version? or it was only a 
windows related problem?

Btw, I wrote a "intranet voting system" using cheyenne & rsp just 
in 2-3 hours (with login, user management, messaging, voting, product 
upload etc.). That was a real fun to use rsp.

session-problem

: if you mean the issue raised by Janko and fixed a few days ago, 
it's in the SVN repository: http://code.google.com/p/cheyenne-server/

Intranet voting in RSP: "simple things should be simple to do." ;-)

Doc: yes, I meant that, you sent me the fixed version r40.

Right, I forgot...

Anyone know if RT is looking at using Cheyenne on the backend?

Also, is Cheyenne currently being ported to R3?

1) Don't know.
2) No, see yesterday's discussions here.

Doc - sorry to flood your channel here, but I tried to convince Carl 
to finish concurrency, while he was still here :-)

I thought that 10 other users might help me to convince him, but 
noone helped :-)

The only advantage of task! is about 1MB of memory. Otherwise, you 
can fire up multiple R3 processes and communicate between them.

 <- I thought task! would make things like that much simpler. I've 
 always found that using multiple processes was too complicated, unless 
 you have a powerful tool at hand to handle this for you.

Henrik - yes, just read the discussion. Carl claimed, that RT has 
long time the code to IPC between processes. I objected, that no 
such code was standardised over-time, so that is maybe a reason, 
why ppl do wait for tasks. We await stuff like ipc:// scheme, etc.

also - isn't there difference between tasks and threads and how they 
scale in multi CPU/multicore environments?

A task is an OS thread in R3. Carl just confirmed that here yesterday

yes, I know. But he also asked, why don't we use OS tasks, via 'launch 
funciton probably, and such solution would mean OS tasks, not threads. 
My question was plainly theoretical - I was curious, what scales 
better in modern multicore envrionments - tasks, or threads, or it 
does not matter?

Those are called processes

Pekr: no problem. Cheyenne is one of the application that would benefit 
the most from threads.


IPC between processes can't compare to shared memory between threads. 
With processes, you need to serialize values, transfer them (multiple 
memory copies or worth using a disk file), then LOAD them back. With 
shared memory, you just pass a memory reference to the value and 
you ensure (using a sync mechanism) that no concurrent writes occur 
on that value. It's at least a magnitude faster and uses so much 
less memory.

hmm, how is that Amiga tasks were so fast? Didn't they share some 
space too? Well, but AOS is not memery protected, so most probably 
you are right, that in most OSes, processess are isolated ...

thanks for explanation ....

In AmigaOS, there's no difference between processes and threads, 
hence tasks. The major difference is that processes have their own 
memory space, while threads share memory within a process. AmigaOS 
has no protected memory, so there is only one task concept

Needing to advocate for multithreading support in a programming language 
two days from 2010 is almost...anachronic.

Almost?