World: r3wp

Can you make a `red` global variable in C when `red` is already use 
as an enumeration value?

Specification document fixed.

Can you make a red global var..
 No, we cannot.
document fixed
, still we cannot compile the examples on Windows,
because of "redeclaration of c" in win32.reds file.

I mentioned it above, it needs a fix in the compiler and/or the runtime 
code.

*** Compilation Error: unknown directive enum
  = should I fix it to provide correct error message?

Endo - I'm sure that in a real life. you don't want to use #enum 
to define values like a, b, c, d as well as common names like red, 
blue etc.. Real life enum example naming is for example:
#enum DitherMethod! [
	  NoDitherMethod
	  RiemersmaDitherMethod
	  FloydSteinbergDitherMethod
]

Such an enumeration you can use in the import like:
#import [
	"CORE_RL_wand_.dll" cdecl [ 
		MagickRemapImage: "MagickRemapImage" [

   ;== Replaces the colors of an image with the closest color from a 
   reference image

   ;-- MagickBooleanType MagickRemapImage(MagickWand *wand,const MagickWand 
   *remap_wand,const DitherMethod method)
			wand	             [MagickWand!] ;the magick wand.
			remap_wand	[MagickWand!]

   method	[DitherMethod!] ;choose from these dither methods: NoDitherMethod, 
   RiemersmaDitherMethod, or FloydSteinbergDitherMethod.
			return:               [MagickBooleanType!]
		]
	]
]

I was also thinking about value test to prevent passing for example 
value 10 as a method in the MagickRemapImage, as it accepts only 
values 0, 1and 2. This is not implemented yet.

You are right.

The problem above, enumrated value clashes with a local variable 
in a function.

#enum test! [a b]
;...

f: func [a [integer!] /local b] []    ;<---- compile error, "redeclaration 
of b"

which could be problem in a big source.
...prevent passing...
 catch in compile time would be nice for sure.

if I compile just:
c = 0;

I get: *** Compilation Error: local variable c used before being 
initialized!

it's not bug related to enumerations.

(ech my error)

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