World: r3wp

The lack of coordination and exclusiveness of the current development 
methodology does not maximize the use of the community

Just because R3 isn't multi-threaded doesn't mean we can't be

Right now the main core of current development is coordinated. It 
would be nice to maximize the use of the community, but the interrelated 
projects are already being coordinated, and syncing up the projects 
that can be done independently would just add management overhead.

Anyone able to assess whether this is feasible http://www.libssh2.org/
as an extension or whatever ...

BSD license vs the LGPL license for libssh ( which also does server 
side ssh )

I have used it. Works very good. It's used in the communication layer 
I have done.

Are you releasing that or should we reimplement it?

It will be released. To really be convinient we need R3 callbacks. 
So, it's to much a prototype yet. My experience showed that things 
need to have a critical maturity level before others will pick it 
up and really use it.

So, did you do a R3 or R2 implementation?

ssh extension? this would be great!

It's not something I have any immediate need for, but it looks like 
an interesting project to try

Brian, you say "We have a task! type now, and have had it for a while. 
It doesn't work well but when last I checked it does work."


Could you elaborate on this? How does one actually use task!, with 
current R3?

In general, one doesn't. There is no infrastructure code around tasks, 
no way to stop or track them that I know of (they may stop on their 
own), and the only testing of them that I have done is to track down 
errors. But they seem to do something. The task-local user context 
is for the moment by definition rather than actual - it hasn't yet 
been implemented. But you can MAKE a task! and it will do something.

a: make task! [wait 5 print "Hello in a task"] do a print "Hello"

as you can see, it will print "Hello" first, and after 5 secs it 
will print "Hello in a task" .... the question is, if I got the usage 
right :-)

It's been like that for more than a year now. Oh, and if an error 
is triggered in a task and not handled, it will crash R3. I'm not 
sure it is stable to trigger an error and handle it either.

Yup, that works Pekr, and the task ends on its own.

>> a: make task! [wait 5 print "Hello in a task"] do a print "Hello"
Begin Task
Hello
>> Hello in a task
End Task

interesting. does nothing at all on linux, so i guess that's why 
i didn't ever notice that tasks actually do something.

but it indeed works fine on win32 R3. thanks for your help, guys!

There's a lot of R3 that only works on Windows for now, if there.

I wonder where the code is that prints "Begin Task" and "End Task"...

you've got me wondering how we could already setup some thread IPC 
and burst mode control with the current  !task.implementation.... 
hum... worth looking into.

the "begin/end task" printing happens somewhere in r3lib, and in 
native code, afaict

I hope it pays attention to the quiet setting.

timers cannot be started from another thread .. error

? Code?

Interesting .. so I can start my gui that way as a task

oh .. I think it's a Qt error message

Likely not, because task-local data isn't implemented yet. It's probably 
not safe.

I started up multiple Qt windows as tasks

Nope, it does not pay attention to the quiet setting.

Debug code then.

Surely, a bug nevertheless.

Well, nevermind. Considering that it's mostly unsupported functionality 
at this point, probably not worth a bug report :)

Yup, there is no point to reporting task! bugs yet, they all get 
deferred. But not deferred very long, if recent indications are true 
:)

When they are worth reporting, we'll let you know.

interesting .. this seems to be working well.

still a bug if you can't use it for cgi ...

You can barely use it for anything except reliably crashing R3.

I mean the ignoring of the -quiet flag .. you can't use r3 for cgi

We're not disputing that it is a bug - actually, we think it is debug 
code that is only there temporarily. But reporting it is of no good 
for the moment, and it's not nearly as bad as its other bugs.

>> do task [] [print 42]
stack size: 50000
[New Thread 0xf7d75b70 (LWP 25615)]
waiting for task to become ready
Begin Task
REBOL System Error:
REBOL System Error #1411: REBOL System Error

that's tasks almost working on linux as well :)

Wow, they're almost working as well as they almost work on Windows 
:)

unfortunately that error is caused somewhere deep within libr3, so 
i don't get any further than this :)

Start with the host code's implementation of tasks - that's where 
the platform-specific code is.

that's what i did. the above is the result.

i implemented the thread management functions in the host lib. the 
create_thread hostlib function gets a function pointer as argument 
that is to be run in the new thread. and the error is occuring within 
this function, so it's a bit outside my reach

That's a good start. Keep that code for when we start working on 
this :)

just for comparison, without the hostlib stubs implemented, all you 
get on linux is:
>> do task [] [print 42]
>>