World: r3wp

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

As long as the clones are (L)GPL they will get no support.

BrainH yes they are compiled but using the Glib the GTK+ libs etc 
GNU libs and tools so people feels more confortable to contribute

BrianH but what is the purpose to have a deposited thing no one want 
to use ...

I am saying that you can't compare their speed to that of REBOL, 
because REBOL's semantics require interpretation. All successful 
languages on the JVM are compiled, because interpreters are just 
too slow on that platform.

truth is you say to 100  programers java they all knows what it's 
about  you say ruby 60% of them eard about it you say rebol in the 
best case if you have 2 guys that eard about it you are lucky

So? That is not an excuse to do the number-one worst thing that you 
can ever do as a programmer.

can we keep rebol in the shadows doesn't it impact it's spread to 
keep it in the actual model ...

BrianH i heard alot java sux etc ... but truth is it's the most wanted 
language now in day ... and you can't tell it will be better or not 
for rebol we didn't tryed ... and if java is not your prefered ok 
how about mono (the GPL ed  C# package) but mono have less visibility 
than java.

I have no problem with there being a semi-compatible R3 clone based 
on Java, and if I buy an Android phone I will start such a clone. 
But it will not replace R3 because that code is useful for many people 
*now*, and doesn't have any of the significant downsides of the JVM 
and its ilk, which is part of what makes it useful. And any clone 
that is based on (L)GPL can't share code with R3, so anyone who wants 
to help the community can't contribute it it.