Subject: Re: Is neko the solution ?
Date: Saturday 1st October 2011 15:04:50 UTC (over 5 years ago)
Le 01/10/2011 00:39, johann Sorel a écrit : > If someone could answers my questions, I would greatly appreciate :) > - license : are there plans to change the license ? to something more 'free', public domain or give the copyright to a foundation ? it's not that I don't like the GPL license but I still have a very bad experience with OpenSolaris which has suddenly change license to something private (thanks oracle again). I guess you can understand I have a few fears about GPL, it's not a full proof guarantee for the futur. There are no plans to make the license more private. As the main developer of NekoVM as part of my work at Motion-Twin, we are not selling any kind of services based on NekoVM or haXe, so we have zero commercial interest in doing so (if that can help you). > - NekoVM : is there a basic IO support in nekoVM, at least to read and write files ? so I could build a parser Eria -> Neko with it ? > - NekoVM : some archive support ? zip, tar, gz, anything ? The VM itself does not have IO or ZIP support but there are some libraries for that : the standard library allows for file io and the zlib library allows for compression of archives. For full ZIP/TAR/GZ support you need additional code (see http://hxformat.googlecode.com/svn/trunk/format/ for a reference - written in haXe but running on NekoVM) > - NekoVM : my language requieres to have some advance reflexion, I want to store constraint informations on a function arguments, x between 0 and 10 . You'll need to general additional runtime checks for this I guess. > - NekoVM : how are objects organize ? in parrot I could store primitives/class/functions in namespaces and acces them using reflexion. Is there something similar in NekoVM. something like paths or namespaces ? Objects have a simple table of fields which is a sorted array of key/values. Each key is an integer that represents the hashed version of the field name. Hashing is done a compilation so runtime access is just a log(n) lookup in the object table. Objects also have a prototype pointer that can be set with $objsetproto (see http://nekovm.org/doc/view/builtins). The idea is that if a field is not found in the object table it's looked up in the prototype, recursively. This way you can simply encode classes by having the methods in the prototype and only the actual fields in the object itself, and chain prototypes for inheritance. You can read more here : http://nekovm.org/specs#objects and there : http://nekovm.org/doc/view/builtins Best, Nicolas -- Neko : One VM to run them all (http://nekovm.org)