r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Oldes
20-Feb-2012
[5203x3]
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
Endo
20-Feb-2012
[5206]
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?)
Pekr
20-Feb-2012
[5207]
warning's good in such a case imo, or your app will most probably 
behave incorrectly in the runtime anyway, no?
Oldes
20-Feb-2012
[5208x2]
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.
Dockimbel
20-Feb-2012
[5210]
Oldes: I agree with your fix, the locally defined value should prevail 
over the enumeration value.
PeterWood
20-Feb-2012
[5211]
I've added the example of the proposed change to enum-test.reds (Enum-11).
Oldes
20-Feb-2012
[5212]
And so what is expected behaviour for:
#enum test! [a b]
f: func[a [c-string]][]
PeterWood
20-Feb-2012
[5213]
In that case isn't a local to the function?
Oldes
20-Feb-2012
[5214x3]
Is it possible to test warning message?
enum-redec-10 must be changed
Forget it- it is, I was modifying the autogenerated file.
PeterWood
20-Feb-2012
[5217]
Yes it is possible to test for a warining message. assert-msg? simply 
does a find on the compiler output for the supplied string.
Oldes
20-Feb-2012
[5218]
Here is the fix in the pull request: https://github.com/dockimbel/Red/pull/206/files
Dockimbel
20-Feb-2012
[5219x4]
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>...
Kaj
20-Feb-2012
[5223]
Very nice, thanks! I suppose they should be turned OFF instead of 
ON?
Dockimbel
20-Feb-2012
[5224]
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...
Kaj
20-Feb-2012
[5225]
OK. Is it a standard that they should be disabled, or is WebKit just 
sloppy?
Dockimbel
20-Feb-2012
[5226]
It seems to be standard way for C floating point handling.
Kaj
20-Feb-2012
[5227]
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
Dockimbel
20-Feb-2012
[5228x2]
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.
Kaj
20-Feb-2012
[5230]
OK, I will wait a bit
Dockimbel
20-Feb-2012
[5231]
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.
Kaj
20-Feb-2012
[5232]
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
Dockimbel
20-Feb-2012
[5233]
Float issues for IA-32 fixed. Need to also fix them for ARM (tomorrow).
Dockimbel
21-Feb-2012
[5234x3]
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
Kaj
21-Feb-2012
[5237x5]
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
Pekr
22-Feb-2012
[5242]
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 ...
PeterWood
22-Feb-2012
[5243]
I've found the easiest way to raise that runtime error is to accidently 
treat an integer as a pointer.
Dockimbel
22-Feb-2012
[5244x3]
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
Kaj
22-Feb-2012
[5247x3]
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
PeterWood
22-Feb-2012
[5250x3]
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