World: r3wp

FYI, I am currently merging the float-partial branch and preparing 
for the 0.2.4 release.

Downloaded new branch, and now my error message changed. Was there 
any change to error handling?

*** Runtime Error 101: no value matched in SWITCH
*** at: 004013ADh

I am able to disrupt R2 compilation session to the state, where its 
restart is needed. Not a big deal, but maybe you will see something 
obvious. The code causing it is as follows:

print ["led-set-language: " led-set-language 3 lf]


The trouble is, that led-set-language does not return any value (void). 
This is understandable, that 'print has problem with such a clause. 
The error returned was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


Correcting the issue (moving function call away from the print block, 
I get another error:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


This error repeats, untill I restart the R2 compiler session, which 
is a proof, that I corrected the source code, as aftern the R2 restart, 
I can get clean pass ...

Sorry, wrong cut and paste. The first error was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compilation Error: return type missing in function: led-set-language
*** in file: %led/led.reds
*** at line: 87
*** near: [led-set-language 3 lf]

OK, case closed - I got reply from Linsn, that the library is compiled 
to be used only by C++ compilers. Strange that half of the functions 
work correctly though (was able to turn led screen on/off for e.g.)

pekr, in this case, wrap another dll around it, a.k.a. "thin layer" 
dll.


use a C++ compiler, but use the functions within a C sourced dll 
project.  this dll will then serve as your translation from the C++ 
libs to Red/Rebol whatever.    If the C++ use requires special steps 
on function entry/exit, the compiler will add these for you (when 
it compiles) and from outside the C function you'll be back into 
"normal land". 


 I've even read that some C++ compilers can't even properly use libs 
 from a different C++ compiler.

Kaj: I did a few tests for the 0.2.4 candidate with some of your 
bindings on Windows and Linux. No issue so far. Could you please 
check if all your bindings latest versions are working fine before 
I make the release?

Maxim: thanks, that was my idea. Will learn a bit of C too :-)

I just posted the result so that Doc could see, that now the error 
message is different (more concrete?). Did anything changed internally 
apart from float support? Also - before 0.2.4, the output exe was 
61xx bytes, whereas with 0.2.4 is 5632 bytes ...

The runtime error handler now better catch unknown errors and the 
use of SWITCH has decreased the runtime code size significantly.

I tried to resync my repository but lot of errors pop up. Can I rebuild 
a clean version without deleting my fork first ?

Do you have local changes you want to keep?

No

Then what is it you "don't want to delete"?

No I have no problem with that ,  I just  fear Github will not be 
happy :-)

I don't think so :)

just a note - solved the ledctrl problem. I noticed it generated 
system.con configuration file, but this file was just 210 bytes. 
So I copied over the larger one from real set-up, and those affected 
functions started to work. Tomorrow I will try directly with the 
ledscreen. So, although the library is said to be C++ only, it now 
works even from R2.

Kaj: I did a few tests for the 0.2.4 candidate with some of your 
bindings on Windows and Linux. No issue so far. Could you please 
check if all your bindings latest versions are working fine before 
I make the release?

Will do. Fortunately, I just got the new Syllable development release 
out the door

Petr, that library is weird, and I guess the Windows environment 
makes it even weirder. The interface is so convoluted that I assumed 
the reason was to export normal C functions, so maybe that's the 
case after all

There's a problem with the WebKit binding:

bash-4.0# ./LazySundayAfternoon-Browser 

*** Runtime Error 9: float invalid operation
*** at: B66C5447h

Looking into it...

I'm also getting weird error messages on 0MQ, although it basically 
works:

bash-4.0# ./request-client 
0MQ version: 2.1.4

Connecting to Hello World server...
Sending request 1
Received reply 1: World
Resource temporarily unavailable
Sending request 2
Received reply 2: World
Resource temporarily unavailable
Sending request 3
Received reply 3: World
Resource temporarily unavailable
Sending request 4
Received reply 4: World
Resource temporarily unavailable
Sending request 5
Received reply 5: World
Resource temporarily unavailable
Sending request 6
Received reply 6: World
Resource temporarily unavailable
Sending request 7
Received reply 7: World
Resource temporarily unavailable
Sending request 8
Received reply 8: World
Resource temporarily unavailable
Sending request 9
Received reply 9: World
Resource temporarily unavailable
Sending request 10
Received reply 10: World
Resource temporarily unavailable
Resource temporarily unavailable
Resource temporarily unavailable

I've seen that before during development, but it had been fixed for 
quite some time. It must be generated during cleanup

Webkit: can't run it on Windows, I was able to get a suitable libwebkit 
but it fails to find some functions in the dependent DLL. Trying 
on Linux.

It seems that the newest WebKit versions have broken compatibility

0MQ messages: I can see them on Windows too, do you have an idea 
on what causes them?

It must somehow be unable to do cleanup, or the cleanup has already 
occurred. But the same code ran OK on earlier Red versions

Webkit crash: reproduced on Linux.

What Linux distro? I ask because the WebKit in the newest Linux Mint 
is incompatible

Ubuntu 10.04 LTS.

OK, thanks. 11.10 is the culprit. Not that it would crash, but the 
library names and versions have changed

If I remove the x87 FPU init code, the crash disappears.

I was suspecting something like that

The other bindings are OK

I am not sure, but it might be a collision with C init routines.

Well, they're still not called :-)

I was thinking that libwebkit might be calling some of them in some 
way.

I wonder if activating the Intel FPU in x87 mode, then using SSE 
instructions (in libwebkit) could trigger such error. IIRC, the FPU 
needs to be    properly set in x87 or SSE mode before using an x87 
or SSE instruction.

I'll search deeper tomorrow, sleep time now. I'll postpone the 0.2.4 
release until I get a clearer view on this issue.

OK, good luck

I messed up SSE and MMX in my posts above, it's MMX that shares hardware 
with x87 and not SSE.

It seems that the issue is caused by FPU control word settings used 
by Red/System that make webkit crash. I need to find a common setting 
that would work for both.

Ok, found the culprit bit in the exception mask.

We have wrapped Webkit? :-) It is just yesterday when my friend reported 
to me, trying to write some basics of media playback, that downloading 
new version of Webkit broke Python binding, hence I would expect 
some incompatibilities between the releases :-) (R/S one had probably 
different reasons)

Kaj: issue fixed.

Pekr: don't you know that we already have a GTK-webkit-powered web 
browser? :-)

Yes, I just realised it today :-) But my friend told me something 
like WebKit library having 100MB? (maybe a typo)  So I expected the 
wrapper being thousandns of lines, whereas it is just few functions 
:-) So what kind of wrapper do we have? It surely is not complete 
wrapper to all the WebKit  functionality?