World: r3wp

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?

It wraps the webkit component of GTK, so you can add a webkit view 
in a GTK window and pass it an URL to open. As we already have a 
pretty broad support of GTK components, you can now build your own 
custom web browser in Red/System!

The webkit libs on Windows seems to weight ~66MB.

I'm looking into the 0MQ error messages...

Kaj: found the issue with 0MQ, it's related to integer! => logic! 
type casting in your wrapper functions. It seems that the runtime 
conversion code is not emitted.

Ah, another one of those. It must be a regression, that's why I've 
seen it before

The WebKit I use of a few years old is 18 MB installed size, on Syllable 
Server. It has quite a few more dependencies, though, and on Windows 
that would be more because none of the dependencies are preinstalled

Kaj: fix pushed for the 0MQ issue. Let me know if it works fine for 
you now. Also, any other regression to fix before releasing the new 
version?

Not that I found

Now the WebKit browser starts loading the Red site, but halfway I 
get this:

*** Runtime Error 7: float divide by zero
*** at: B01DE1F6h

0MQ works again

Yeah, same issue than previously with the "float invalid operation" 
exception. Webkit seems to mask them all, while Red/System let them 
pop up.

The browser runs fine here on Ubuntu 10.04. No divide by zero errors.

This is on Syllable Server, where it worked before

If I disable the float "divide by zero" exception, we'll have no 
way to detect it until proper support for INF will be added.

Sigh, the state of computing

datatype implement
 should be "datatype implements" imo ...

Typo fixed thanks.

So now you are finally free to start working on Red? :-)

Almost, I need to have a look at C init routines first, probably 
tonight or tomorrow, then I'm free to work on Red. ;-)

what is C init routines topic about? I mean - why Red/System needs 
it?

What's the decision on divide-by-zero?

You should not divide by zero, it gives an error :-)

Kaj: I will see if I can quickly add support for `system/fpu/flags` 
so users can set it as they want/need.

Yes, that would be good, otherwise I don't have a browser anymore

Pekr: it is possible to divide by zero in IEEE-754, that gives you 
+/- INF. I have not decided yet how it should be handled in Red/System, 
I would be in favor of raising an error rather than introducing INFs.

Kaj, in any case, you can just replace #{037B} by #{037F} in IA-32.r 
at line 20: 

    fpu-flags: to integer! #{037B}

Thanks, but I'd rather not do that

For non-variadic C functions, Red/System's compiler will promote 
float32! to float! automatically.

Does that mean that external functions that use single precision 
can't be bound?

Have the docs been republished yet? The #enum link points to #include

Sorry, forgot to update the docs online.

Docs updated.

Thanks

Kaj: you can pass single precision values to C functions, but C automatically 
converts them to double. C always passes single precision floats 
as double precision, and converts them before pushing them on stack.

but C automatically converts them to double
 => "but C always expects double"

That seems odd to me. What's the point of single precision, then? 
It would be slower than double precision

#enum <name>! [
   <label> +
   | <label>: + <value>
]