World: r3wp

first i should use c: 0, and it compiles, so it's related to enums.

its another issue I think, in my example there is no c.

Example 1:
#enum test [a b]
b = 0   ;<--- global, redeclaration error, which is correct.

Example 2:
b = 0  ;global
f: func [/local b] [] ;<--- no error, correct

Example 3:
#enum test [a b]

f: func [/local b] [] ;<--- redeclaration error, incorrect! local 
b should not be clashed with enumarated-global b

oops sorry, I wrote "b = 0" should be "b: 0"

You are right.

I've modified the behaviour as you want, but we should wait what 
Doc will think about it. Now it works like:
#enum test! [a b]
f: func[/local b][
	b: 3
	?? b
]
f ;will print 3, not 1

f: func[][ b: 3 ] ;throws error as before

I think this is the correct behaviour, more compatible with REBOL 
as well.

I'm not sure about giving a warning if a local var. clashes with 
a global one (just for enums may be?)

warning's good in such a case imo, or your app will most probably 
behave incorrectly in the runtime anyway, no?

the problem is, that now it throws this error if C is used in enum:
*** Compilation Error: type mismatch on setting path: char/1
*** expected: [byte!]
*** found: [integer!]
*** in file: %runtime/utils.reds
*** in function: prin-byte
*** at line: 29
*** near: [
    char/1: c
    prin char
    c

I don't have time to check it now more deeply... maybe in the evening.

Oldes: I agree with your fix, the locally defined value should prevail 
over the enumeration value.

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