World: r3wp

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

OK, that's clear at least now ...

It's very nice that Red/System has a first class logic! but external 
code doesn't know that

would it be possible to cast import values directly in import clauses, 
to prevent the need to write another wrapping functions? call me 
lazy :-)

Integer! _is_ signed in Red/System, byte! is not.

I mean, so I could write:

return: as integer! [byte!]

or: return: as logic! as integer! [byte!], so that I would get true/false 
directly :-)

No! But you can use a macro to avoid making a function wrapper.

macro?

#define

Oh, right, the other way around. But how do you get a high integer 
from a library, then?

aha ... I would probably use something like _func-name ... and func-name: 
[as logic! as byte! _func-name]

I will look into #define ...

Pekr: yes, that's an option.

Kaj: the same way as you get a low integer. :) The signed representation 
is just a convention, the actual data remains the same, signed or 
unsigned.

It seems that Petr's library puts garbage in the high bytes if it 
returns 1 or a high integer

Pekr: it should be  [as logic! _func-name], while setting [return: 
[byte!]] in _func-name definition.

yes, I confused it - ti came from R2, where I put char as a return 
value, and then to-integer ... I develop in in R2, Red/System, World, 
to see if eventual crashes are environment specific, or library specific

the library is clearly a junk imo ... e.g. two consecutive calls 
to the same function do crash the app, etc.

I split the C library binding in two branches so that users of the 
Red release can keep using the main (trunk) branch:

http://red.esperconsultancy.nl/Red-C-library/timeline

The new "developing" branch is not compatible with Red/System 0.2.4 
but is needed to use WebKit

Kaj: I've just pushed a fix for the floats exceptions and regressions. 
Mandelbrot is running fine again now. Let me know if the issues are 
fixed for you too.

Fixed, thanks

; CLOCKS_PER_SEC value for Syllable, Linux (XSI-conformant systems)
; TODO: check for other systems
#define clocks-per-second		1000'000

Judging by your screenshot, it's different for Windows

IIRC, it should be 60 for Windows, but I'm not certain this is valid 
for all Windows versions.

Sounds like that could be 50 in the US

Possible.

Performancewise, 100 or 1000 seem most likely

1000 or 10'000 really

It's 1000:

http://en.allexperts.com/q/C-1040/time-milliseconds-Windows.htm

But stupid Windows measures wall-clock time instead of processor 
time

That explains why your measurement is pretty much the same as on 
my old CPU

I'm working on new benchmarks that you'll like :-)

Kaj - you should also be aware of this note iin the Libc docs:

— Macro: int CLOCKS_PER_SEC

The value of this macro is the number of clock ticks per second measured 
by the clock function. POSIX requires that this value be one million 
independent of the actual resolution.

Yes, that's already in the notes in my binding. See above (XSI-conformant 
systems)