World: r3wp

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

It's the replacement idea that is bad. We can make a vaguely REBOL-like 
language for Java that is good enough to interoperate with the C-based 
R3, but throwing away the R3 codebase like you said and starting 
over would kill the language and make us wait another 5-10 years. 
The "instead of" part is a BAD IDEA.

BrianH R3 is stuck in alpha since 3 years and it will take 3 more 
years to be officially released ... and mean while we keep a design 
based on  90's year design  i mean it implicates too a lot of difficulties 
that can't be overcomed easyly

Perl, Python and Ruby are compiled, and so is TCL now. They are not 
interpreted.

R3 is not stuck in alpha. What you are doing is suggesting throwing 
away a codebase and starting over. Perl 6 did that and they are still 
in alpha after 10 years.

BrianH yes that can be a side project ... but it have to be seriously 
done not another abandoned clone project that convince no one and 
get no support...