World: r3wp

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]
>>

good to know that tasks are this far already, though. should be fairly 
straightforward to get linux to the same level as windows, and from 
there on to continue and make them actually useful :)

So, what exactly is safe and unsafe in using task!

ok another question i know i'm a bother ... but if  us tiny bunch 
of crazy fans we don't ask us silly asks we will never get steps 
further and get rebol writed in history. So the crazy is is why not 
doing rebol in java instead of C or C++ ?


I mean now in days having rebol based on java what are the possible 
gains ?

1) Easier way to handle multiplateform

2) Big big java comunity and so getting strong specialised people 
to enhance rebol VM will be easier.
3) no need to adapt algorithms across plateform.
4) all the curent technologies are adapted to java. 

the bad points are:


1) jre weights alot and rebol being based on it will not be stand 
alone so it will need the jre to be installed to run
2) goodbye AGG 
3) interfacing with java libraries can be problematic.

I think the good points overcome the bad points.

but the kind of interface we can do with java is that -> 
http://uploads.siteduzero.com/files/111001_112000/111843.jpg

i know rebol wants to be something else ... but that's the main reason 
why rebol isn't not being use more extensively and is so much undergrounded...

i like hte idea of rebol being something else based on the language 
at fame ... REbol can be thinked as an abstraction why using this 
language instead of this other to build rebol ? Since the goal is 
to make rebol way to build software the way to build software widely 
in the futur ... s

Add a few bad points:

4) We would have to throw all of the current code away and start 
over.

5) The semantics of REBOL have very little in common with Java, so 
we would be very limited in what Java libraries we could use.

6) The JVM is much worse at dynamic languages than its competitors, 
such as the CLR.
7) SLOW.
This might tip the tables in the other direction.

Most of the Java technologies mentioned in positive point 4 would 
be unavailable or awkward to use because of the semantic mismatch.

Brianh's bad point: 
 

4) hum yes but maybe you will attrack some more hella programers 
ultra specialised that will help us do the translation ...

5) the semantic and datatypes of rebol have few in comon with C/C++ 

6) yes but looking at the jobs offers now in day most of them aorund 
70% are based on java jdbc job offers ... 

7) slow but now we have 4 to 6 cores processors that was a good excuses 
10 years ago but today that's not...

But if you make this change: "doing rebol in java instead of C or 
C++" -> "doing another rebol in java in addition to the current C/C++ 
version"

Then you can get rid of bad points 1, 2 and 4. And add a good point: 
5) R3 for Android.

brianH Rebol on android i say Woooooooooooooooohooooooooooooo that 
smells good 

and iphone too since apple doesn't seems to be willing to support 
flash but have no problems with java

4) "ultra specialised that will help us do the translation" Manual 
translation. The code would not be comparable, and the entire implementation 
strategy would need to change because of the differences between 
C and Java.

5) REBOL doesn't have classes. And accessing C libraries from REBOL 
is awkward too.

brianH any way you know scripting language have the reputation to 
be the slow pokes in computing area ... so basing them on java shouldn't 
make the difference

You are underestimating just how fast R3 is, when compared to other 
interpreted languages. Orders of magnitude better.

ok lets be frantic and compare rebol with tcl/tk, perl, python,  
ruby. All those scripts langage have in common to use GNU bases main 
portable libs so the community making them grow and known is bigger 
than our community 1000 times ...