Flash does give milliseconds, though not sure about the api in haXe / Neko Lee
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of daniel fischer Sent: 09 June 2006 11:36 To: [email protected] Subject: Re: [Neko] neko-cptr: handling C pointers from neko/haxe Nicolas Cannasse <[EMAIL PROTECTED]> (on Fri, 09 Jun 2006 10:46:36 +0200): > Please be careful with the GC of the pointer. > It means that you must ensure that the pointer associated with the Neko > value is not used anymore by any other data structure in your program :) so true once more- although this seems to be mostly a matter of the C side of bindings, and such left to the binding developer to take care of-- if- there is a way to mark a value as being referenced from C? what i use it for - mostly passing shorter lists of ints or such to OpenGL functions, and getting image buffers from one library to pass them on to GL for making a texture - this is not really an issue. i should hint on this in the cptr documentation though. do you agree though, that the way i currently do it should be pretty safe security-wise, at it doesnt allow neko programs to write into arbitrary memory areas? this is my primary concern on the long run- crashes due to forgetting about pointer handling i could live with :) you say that once understood it's easy to implement- but i admit i dont really know how i would go about it if i'd have some pointer that i want to both pass to neko and keep handling within C (again, can i increase the refcount from C? i guess yes, but how?). I think both C memory handling and garbage collection are quite clear to me, although interaction between the two obviously poses a bit of a problem to my feeble mind :) in case of, eg. GObject stuff, which does reference counting, the issue could probably elegantly be resolved in that the neko finalize function just decreases the refcount- as long as there are refs from C, the pointer will stay valid. > > there is still open issues with NULL pointers, as handling these might sometimes be a valid thing to do, and casting between pointer types. i have ideas how to handle these situations, but currently i have no real use for them, so they're just delayed. > > Why ? a NULL pointer is simply a pointer with size 0 no ? :) not really- well, on a high level it could maybe be handled/expressed that way. of course, a pointer of size 0 can't be allocated. i'll think about it- it's not just "simply" so, as the "size 0" and "NULL" cases would have to be handled at the specific points of neko-cptr. > I'm checking your code and see that you're defining several kind of > abstracts - one per pointer type. Does it makes really sense to have > such an "high level" definition ? For instance you could just treat a > pointer as a memory block where you can store several kind of RAW data. well, yes- but then it would be rather hard to read and write elements in case the pointer is an array of ints or the like. for example, OpenGL expresses its matrices as simple float*, and i surely want to set them from neko. i would need to "encode" the data myself, likely taking care of endian issues from neko, etc. the current way assures that you're not passing pointers to data of the wrong type to functions expecting specific data. for raw buffers of some stuff it might make sense to just handle them abstractly, but if i really want neko to access the data, this makes stuff much easier- doesnt it? > As for "util_msec" you can use [EMAIL PROTECTED] that will work the same all > all platforms. uhm- youre right. seems i was using new Date() which gives me only second-precision. i had in mind that i couldnt get any kind of millisecond time on neko, but i just tested once more and it seems to work fine. anyhow, new Date() on neko, at least on linux, gives me only second precision- if it was milliseconds, i think that could be used cross-runtime to do profiling (JS, i know, gives milliseconds. unsure about flash right now).. -dan -- http://0xDF.com/ http://iterative.org/ -- Neko : One VM to run them all (http://nekovm.org) -- Neko : One VM to run them all (http://nekovm.org)
