As Nicholas suggested effort could be spent more on swfmill. But, I have to confess, I love ming and cannot do without it in my work & projects.
Ogla
On 6/9/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
Send Neko mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.motion-twin.com/mailman/listinfo/neko
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Neko digest..."
Today's Topics:
1. Re: Curious about languages available for Neko (Nicolas Cannasse)
2. RE: Curious about languages available for Neko
(Lee McColl-Sylvester)
3. Re: neko-cptr: handling C pointers from neko/haxe (daniel fischer)
4. RE: neko-cptr: handling C pointers from neko/haxe
(Lee McColl-Sylvester)
5. swfmill (was: Re: [Neko] Re: Cairo Bindings Request or
nekobind) (daniel fischer)
6. Re: neko-cptr: handling C pointers from neko/haxe
(Nicolas Cannasse)
7. Re: Curious about languages available for Neko (Robert Feldt)
8. Re: swfmill (Nicolas Cannasse)
9. RE: Curious about languages available for Neko
(Lee McColl-Sylvester)
----------------------------------------------------------------------
Message: 1
Date: Fri, 09 Jun 2006 12:23:57 +0200
From: Nicolas Cannasse <[EMAIL PROTECTED]>
Subject: Re: [Neko] Curious about languages available for Neko
To: Neko intermediate language mailing list
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
> Hi All,
>
> Been lurking for a bit but wanted to find out the state of language
> availability for Neko. It's a little fuzzy for me what the relationship
> is to Haxe, Neko, how this NekoML fits in. Are there other compilers
> that target the Neko VM?
>
> Thanks.
NekoVM is the lowlevel virtual machine.
Neko is the languages that is meant to program the NekoVM. Instead of
specifying a bytecode in binary format, the VM is accessible through
this intermediate - still highlevel - language.
NekoML is one of the languages that are targeting the NekoVM. In
particular, both Neko and NekoML compilers are written in NekoML. NekoML
was then the way to achieve bootstrapping of Neko.
haXe is a language that is also targeting Neko, but not only Neko since
it also have _javascript_ and SWF generators. Before haXe, Motion-Types
was targeting Neko as well.
Robert Feldt started implementing a Ruby to Neko compiler in Ruby. He
can maybe talk more about it but I think he just did a proof-of-concept.
With further work it might be possible to run 100% of Ruby on NekoVM,
which might be very interesting for Ruby users interested in
performances. Of course one of the big part of the work is to
reimplement the Ruby C libraries by using the Neko ones.
Nicolas
------------------------------
Message: 2
Date: Fri, 9 Jun 2006 11:39:56 +0100
From: "Lee McColl-Sylvester" <[EMAIL PROTECTED]>
Subject: RE: [Neko] Curious about languages available for Neko
To: "Neko intermediate language mailing list"
<[email protected]>
Message-ID:
<[EMAIL PROTECTED] >
Content-Type: text/plain; charset="us-ascii"
That's what I said.... well, sorta. Mine was less specific, less
accurate and was missing lots of what you said, but other than that, is
was kinda similar. :-)
Lee
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED]] On Behalf Of Nicolas
Cannasse
Sent: 09 June 2006 11:24
To: Neko intermediate language mailing list
Subject: Re: [Neko] Curious about languages available for Neko
> Hi All,
>
> Been lurking for a bit but wanted to find out the state of language
> availability for Neko. It's a little fuzzy for me what the
relationship
> is to Haxe, Neko, how this NekoML fits in. Are there other compilers
> that target the Neko VM?
>
> Thanks.
NekoVM is the lowlevel virtual machine.
Neko is the languages that is meant to program the NekoVM. Instead of
specifying a bytecode in binary format, the VM is accessible through
this intermediate - still highlevel - language.
NekoML is one of the languages that are targeting the NekoVM. In
particular, both Neko and NekoML compilers are written in NekoML. NekoML
was then the way to achieve bootstrapping of Neko.
haXe is a language that is also targeting Neko, but not only Neko since
it also have _javascript_ and SWF generators. Before haXe, Motion-Types
was targeting Neko as well.
Robert Feldt started implementing a Ruby to Neko compiler in Ruby. He
can maybe talk more about it but I think he just did a proof-of-concept.
With further work it might be possible to run 100% of Ruby on NekoVM,
which might be very interesting for Ruby users interested in
performances. Of course one of the big part of the work is to
reimplement the Ruby C libraries by using the Neko ones.
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org )
------------------------------
Message: 3
Date: Fri, 9 Jun 2006 12:35:47 +0200
From: daniel fischer <[EMAIL PROTECTED]>
Subject: Re: [Neko] neko-cptr: handling C pointers from neko/haxe
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII
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/
------------------------------
Message: 4
Date: Fri, 9 Jun 2006 11:46:19 +0100
From: "Lee McColl-Sylvester" <[EMAIL PROTECTED]>
Subject: RE: [Neko] neko-cptr: handling C pointers from neko/haxe
To: "Neko intermediate language mailing list"
<[email protected]>
Message-ID:
<[EMAIL PROTECTED] >
Content-Type: text/plain; charset="us-ascii"
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)
------------------------------
Message: 5
Date: Fri, 9 Jun 2006 12:47:06 +0200
From: daniel fischer <[EMAIL PROTECTED]>
Subject: swfmill (was: Re: [Neko] Re: Cairo Bindings Request or
nekobind)
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII
What Jarrad is referring to here -i think- is that i mentioned to him that swfmill will be reimplemented in pure haXe. it's a bit far up my sleeve tho, meaning, it's a while to go.
i'm not so sure that ming is not up to date- AFAIK, it supports all flash8 features (not sure), something that swfmill is not up to (just yet- although steve is working hard on it). Also, swfmill in its current form is not well fit to do bindings- it *could* be done, but would be a mess.
i'm still unsure how to re-do swfmill, the only sure thing is that i will (someday). a pure C "libswf" for reading/writing would sure be nice, but i also like haxe so much that i maybe wont care. obviously, though, a libswf could nicely be bound to neko to construct the actual swfmill functionality (xml conversion, font/image import) in haXe then.
also, ming has the advantage of being known to a lot of people- PHP programmers, eg, so maybe a ming binding would make sense after all.
meanwhile, of course, swfmill might well be used as an external tool- just feed some swfml-simple XML into its stdin, and it will give you an SWF on stdout ("swfmill simple stdin stdout")
-dan
"Jarrad Hope" <[EMAIL PROTECTED]> (on Fri, 09 Jun 2006 15:26:09 +0800):
> That's Dan's anyway - I think he has something even better up his sleeve :)
>
> On Fri, 09 Jun 2006 15:14:46 +0800, Nicolas Cannasse
> <[EMAIL PROTECTED]> wrote:
>
> >> Hmmm ming-swf w/ Neko. Wish I had more time. Also, using haXe to
> >> develop ming apps? interesing stuff definitely.
> >> Ogla
> >
> > Instead of Ming, which I think is not up-to-date with latest Flash
> > features, I would prefer someone to build a haXe/Neko NDLL from SWFMill.
> > http://iterative.org/swfmill/
> >
> > Nicolas
> >
>
>
>
> --
> Neko : One VM to run them all
> (http://nekovm.org)
>
--
http://0xDF.com/
http://iterative.org/
------------------------------
Message: 6
Date: Fri, 09 Jun 2006 12:48:52 +0200
From: Nicolas Cannasse <[EMAIL PROTECTED]>
Subject: Re: [Neko] neko-cptr: handling C pointers from neko/haxe
To: Neko intermediate language mailing list
<[email protected]>
Message-ID: <[EMAIL PROTECTED] >
Content-Type: text/plain; charset=ISO-8859-1
> Flash does give milliseconds, though not sure about the api in haXe /
> Neko
Yes , Date.getTime gives second precision in Neko.
To get a milli/micro second precision, there is only neko.Sys.time()
Nicolas
------------------------------
Message: 7
Date: Fri, 9 Jun 2006 12:54:36 +0200
From: "Robert Feldt" <[EMAIL PROTECTED] >
Subject: Re: [Neko] Curious about languages available for Neko
To: "Neko intermediate language mailing list"
<[email protected] >
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Robert Feldt started implementing a Ruby to Neko compiler in Ruby. He
> can maybe talk more about it but I think he just did a proof-of-concept.
>
Yes, it was a proof-of-concept to explore some ways to map Ruby's OO
mechanisms to Neko ones. It was fairly easy.
> With further work it might be possible to run 100% of Ruby on NekoVM,
> which might be very interesting for Ruby users interested in
> performances. Of course one of the big part of the work is to
> reimplement the Ruby C libraries by using the Neko ones.
>
If someone is interested in this I plan to work on it in late summer
(I'm hoping the Neko JIT and maybe also continuation support will be
there by then). Would be great to setup a group effort. Personally, I
think a Ruby compiler targetting Neko is far more interesting and has
more potential than the current efforts to implement a new and special
Ruby VM for Ruby 2.0. YMMV.
Best regards,
Robert Feldt
[EMAIL PROTECTED]
------------------------------
Message: 8
Date: Fri, 09 Jun 2006 12:56:29 +0200
From: Nicolas Cannasse <[EMAIL PROTECTED]>
Subject: [Neko] Re: swfmill
To: Neko intermediate language mailing list
< [email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
> What Jarrad is referring to here -i think- is that i mentioned to him that swfmill will be reimplemented in pure haXe. it's a bit far up my sleeve tho, meaning, it's a while to go.
Oops sorry looks like I skipped that point !
> i'm not so sure that ming is not up to date- AFAIK, it supports all flash8 features (not sure), something that swfmill is not up to (just yet- although steve is working hard on it). Also, swfmill in its current form is not well fit to do bindings- it *could* be done, but would be a mess.
If you need some infos about some of the new FP8 stuff I've been doing
some work on it for the MTASC/haXe SWF library.
> i'm still unsure how to re-do swfmill, the only sure thing is that i will (someday). a pure C "libswf" for reading/writing would sure be nice, but i also like haxe so much that i maybe wont care. obviously, though, a libswf could nicely be bound to neko to construct the actual swfmill functionality (xml conversion, font/image import) in haXe then.
>
> also, ming has the advantage of being known to a lot of people- PHP programmers, eg, so maybe a ming binding would make sense after all.
Yes, true.
In my thinking it was a not so much up-to-date but maybe I should have a
look at it again.
> meanwhile, of course, swfmill might well be used as an external tool- just feed some swfml-simple XML into its stdin, and it will give you an SWF on stdout ("swfmill simple stdin stdout")
Yes that's very useful already.
For the Web it doesn't make a lot of sense to be able to dynamicly
generate SWF, unless for captchas maybe :)
Nicolas
------------------------------
Message: 9
Date: Fri, 9 Jun 2006 12:07:23 +0100
From: "Lee McColl-Sylvester" <[EMAIL PROTECTED]>
Subject: RE: [Neko] Curious about languages available for Neko
To: "Neko intermediate language mailing list"
<[email protected]>
Message-ID:
< [EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Agreed, seeing as the point of Ruby is its ease. Having Ruby syntax for
Neko would still support that effort as I find installing, maintaining
and updating Neko far more simpler than the equivelent with Ruby, so I
guess it would put the Ruby project to bed as it were. Besides, Neko
runs like s**t of a shovel and beats Ruby for speed hands down.
:-)
Lee
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Robert Feldt
Sent: 09 June 2006 11:55
To: Neko intermediate language mailing list
Subject: Re: [Neko] Curious about languages available for Neko
> Robert Feldt started implementing a Ruby to Neko compiler in Ruby. He
> can maybe talk more about it but I think he just did a
proof-of-concept.
>
Yes, it was a proof-of-concept to explore some ways to map Ruby's OO
mechanisms to Neko ones. It was fairly easy.
> With further work it might be possible to run 100% of Ruby on NekoVM,
> which might be very interesting for Ruby users interested in
> performances. Of course one of the big part of the work is to
> reimplement the Ruby C libraries by using the Neko ones.
>
If someone is interested in this I plan to work on it in late summer
(I'm hoping the Neko JIT and maybe also continuation support will be
there by then). Would be great to setup a group effort. Personally, I
think a Ruby compiler targetting Neko is far more interesting and has
more potential than the current efforts to implement a new and special
Ruby VM for Ruby 2.0. YMMV.
Best regards,
Robert Feldt
[EMAIL PROTECTED]
--
Neko : One VM to run them all
(http://nekovm.org)
------------------------------
_______________________________________________
Neko mailing list
[email protected]
http://lists.motion-twin.com/mailman/listinfo/neko
End of Neko Digest, Vol 11, Issue 15
************************************
-- Neko : One VM to run them all (http://nekovm.org)
