World: r3wp

I've added the example of the proposed change to enum-test.reds (Enum-11).

And so what is expected behaviour for:
#enum test! [a b]
f: func[a [c-string]][]

In that case isn't a local to the function?

Is it possible to test warning message?

enum-redec-10 must be changed

Forget it- it is, I was modifying the autogenerated file.

Yes it is possible to test for a warining message. assert-msg? simply 
does a find on the compiler output for the supplied string.

Here is the fix in the pull request: https://github.com/dockimbel/Red/pull/206/files

Added support for `system/fpu/*` read/write properties. This allow 
controling the FPU at very low-level at runtime.

When compiling in debug mode, `show-fpu-state` function is available 
to print the current FPU properties: `show-fpu-state`

When called on IA-32, it would output::

FPU type: x87
- control word: 0000037A
- rounding    : nearest
- precision   : double extended (80-bit)
- raise exceptions for:
    - precision  : no
    - underflow  : no
    - overflow   : no
    - zero-divide: yes
    - denormal   : no
    - invalid-op : yes


See %red-system/runtime/system.reds for definitions and %debug.reds 
for a usage example.

Kaj: in order to get the LazySunday browser working, you need to 
add at the beginning of %math.reds:

#if target = 'IA-32 [
	system/fpu/mask/zero-divide: on
	system/fpu/mask/invalid-op:  on
	system/fpu/update
]


This will disable the exceptions used by Red/System to raise runtime 
errors on float operations. All x87 exceptions should be disabled 
when  calling C functions.

BTW, I guess I should also turn underflow and overflow exceptions 
for Red/System by default...

...turn <on>...

Very nice, thanks! I suppose they should be turned OFF instead of 
ON?

No, the masks are disabling the exceptions, so they need to be turned 
on to avoid raising them. I guess I should have made it more intuitive, 
instead of just mapping the low-level bits as-is...

OK. Is it a standard that they should be disabled, or is WebKit just 
sloppy?

It seems to be standard way for C floating point handling.

Then it should indeed be in the C library binding, but probably in 
the main file, because I will also move a few other functions there 
that use floating point

Right, it should be put before _any_ call to floating point code.

BTW, I'm currently tracking some regressions in floats support, the 
last commit doesn't pass all the float tests.

OK, I will wait a bit

Ok, it's just the new tests added by Peter which are triggering a 
runtime error (related to issue #205). So, playing with your browser 
code should work fine.

Unfortunately, if I put that code in the C binding now, there will 
be no compatible Red/System release, so I'll put it in the WebKit 
binding first

Float issues for IA-32 fixed. Need to also fix them for ARM (tomorrow).

Kaj: I have enabled underflow and overflow exceptions in x87 by default 
for Red/System. This will help us write more reliable code. We'll 
be able to optionally disable all FPU exceptions once we get support 
for INF and NaN. So the init code for C lib is now:

#if target = 'IA-32 [
	system/fpu/mask/underflow: on
	system/fpu/mask/overflow: on
	system/fpu/mask/zero-divide: on
	system/fpu/mask/invalid-op:  on
	system/fpu/update
]

or in shorter, but less readable form:

#if target = 'IA-32 [
	system/fpu/control-word:  033Fh 
	system/fpu/update
]

Kaj: where can I find the source code for __libc_start_main using 
Syllable online sources browser?

Kaj: see my comment wrt `__libc_start_main` at https://github.com/dockimbel/Red/issues/129#issuecomment-4082942

Responded

I'm compiling with -g but show-fpu-state is not available

I've added your FPU code to the C binding because all floating point 
code now generates an exception, but now the Mandelbrot doesn't work 
anymore:

*** Runtime Error 1: access violation
*** at: 08049FACh

At least the browser works again on my WebKit version

I got that error too. I thought it is related to my weak attempts 
to wrap my led library (which still can be the case), as I saw the 
error for the first time yesterday ...

I've found the easiest way to raise that runtime error is to accidently 
treat an integer as a pointer.

Kaj: `show-fpu-state` was renamed to `show-fpu-info` yesterday. I 
forgot to mention it here.

FP exceptions: will look into it.


Peter: can you send me an example code of your use case raising a 
FP exception?

Mandelbrot: it produces an error here too, but not the same one (testing 
on Win7): *** Runtime Error 11: float stack check

Mine is on Linux

Peter, yes, but this is the same Mandelbrot that worked with the 
0.2.4 release

You probably mainly meant that as a response to Petr

Yes my reponse was mainly to Petr as it may be of help to him.

The runtime errors that I got were correct - in the sense that the 
compiler and run-time acted correctly.

This code will cause an access violation as clock in libc returns 
an integer not a pointer to an integer.

pi: declare pointer! [integer!] 
#import [
	LIBC-FILE cdecl [
	  read-cpu-clock: "clock" [
	    return:    [pointer! [integer!]]
	  ]
    ]
]
pi: read-cpu-clock
pi/value

One question towards library wrapping and type casting. One DLL function 
is defined as:

typedef bool (WINAPI *LSN_OPENCARD)(void);//open led card 


When I defined the return type of wrapper funciton as LOGIC!, it 
was always true. When I defined it as an integer, it was either 1, 
or some really high integer number. So i took Cyphre's advice towards 
R2's interface, and in R2 I used CHAR, and in Red/System, I used 
BYTE! type.


Pity construct of a type return: "as integer! [byte!]" is not allowed, 
but at least I now get correct result - 0, or 1, in my print statement, 
where I do: print [as integer! led-open-card lf]


So my question is - why using Red/System's LOGIC! did not work? Is 
C level BOOL a clearly defined type, or can it be defined in various 
ways, so I can't say, that I can automatically use LOGIC! = BOOL 
logic, when wrapping stuff?

From the spec Red/System does not support the use of  the logic! 
datatype in #import  - http://static.red-lang.org/red-system-specs.html#section-14.1


The spec is also silent about how a the logic! field is actually 
stored. I'd guess a byte! but I'd probably be wrong.


By the way no need to cast byte! to integer!, just test for #"^(00)" 
or #"^(01)".

I do use logic! in #import:

gtk-set-window-resizable: "gtk_window_set_resizable" [  ; Set window 
resizability.
		window				[gtk-window!]
		resizable?			[logic!]
	]

Logic! is stored as an integer (so 32-bit). The specification document 
is not supposed to describe the implementation (that's why I try 
to put implementation-specific details in special notes). Logic! 
uses 1/0 internally to represent true/false values, so if the imported 
function is not conforming to that convention, type casting to logic! 
won't work and a manual test would then be required.

But you have to be sure that the library defines it as 0 or 1. There 
is no standard for it in C, but that's what Red uses

Right, we extended the import interface to allow logic!, the spec 
doc seems to lag behind on that feature, it needs to be updated (with 
a note about 1/0 requirement in such case).

The "other standard" for true is -1, but there are no signed integers 
in red/System, so that's where you get the high value from