headers
Nicolas Cannasse | 2 Dec 2005 21:11
Favicon
Gravatar

New APIs

Hi list,

Just to let you know that I committed today two new API function sets in 
the Neko standard library : MD5 digest and full UTF8 support.

Nicolas

---
Neko : One VM to run them all
Permalink | Reply | 0 comments |
headers
Nicolas Cannasse | 7 Dec 2005 13:11
Favicon
Gravatar

Added Linker

Hi list,

I made a change in the Neko CVS. There is now a way to "link" dependent
bytecode files together by using the neko compiler. The compilers are
then now provided as a single fat .n bytecode file (in the /boot directory).

One change is that the command to run the Neko and Nekoml compilers is
no longer  "nekovm neko/Main ...." or "nekovm nekoml/Main ..." but
simply "nekovm neko ...." and of course "nekovm nekoml ....".

You can run the linker by running :
    nekovm neko -link out.n file1.n file2.n ...

It will also automaticaly try to find the static dependencies in each
bytecode and link them together. A "static" dependency is represented by
the bytecode of the expression :

    $loader.loadmodule("constant string",$loader)

since all modules are dynlinked in Neko.

The next step is to be able to create a "boot.bin" file to which we can
append the bytecode in order to create standalone binary (you'll still
need libneko.so and .ndll libraries you're using). Of course if you have
precompiled boot.bin libneko.so and std.ndll available for
Linux/Windows/OSX then you can use Neko on Linux to make Windows
binaries which is quite nice.

Nicolas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bent Rasmussen | 22 Dec 2005 20:41

two things

Hi Nicolas et al.
 
I've just read up on haXe and I'm impressed. The feature set is great. It looks as if some features are inspired by functional languages. Enumerations and switches, for example, resemble the functional datatype and pattern matching and the nice aspect that you can ensure all patterns are handled. Type parameters and constructors are sweet. You've helped the community a lot. This is just what web developers need. Type-safety and interoperability.
 
I have two questions though.
 
First. Is it possible that there will be something like Java's static import in the future? Math.bla gets boring fast. :)
 
Second. Is it possible to qualify an enumeration constructor? E.g. if you have
 
enum A {
    X; Z;
}
 
enum B {
    X; Z;
}
 
Then what?
 
Anyway, I'm going to experiment with it as I regularly use both js and as...
 
Best regards
 
Bent
 
---
Neko : One VM to run them all
Permalink | Reply | 1 comment |
headers
Nicolas Cannasse | 22 Dec 2005 22:34
Favicon
Gravatar

Re: two things

(from Neko list)

> Hi Nicolas et al.
>  
> I've just read up on haXe and I'm impressed. The feature set is great. 
> It looks as if some features are inspired by functional languages. 
> Enumerations and switches, for example, resemble the functional datatype 
> and pattern matching and the nice aspect that you can ensure all 
> patterns are handled. Type parameters and constructors are sweet. You've 
> helped the community a lot. This is just what web developers need. 
> Type-safety and interoperability.

Hi Bent,

Although some Neko/haXe interoperability questions might be suitable for 
the Neko list I think it would be better if you post on the haXe list. 
I'm forwarding this answer as well there so it will be kept in the archives.

> I have two questions though.
>  
> First. Is it possible that there will be something like Java's static 
> import in the future? Math.bla gets boring fast. :)

Not planed right now.

> Second. Is it possible to qualify an enumeration constructor? E.g. if 
> you have
>  
> enum A {
>     X; Z;
> }
>  
> enum B {
>     X; Z;
> }
>  
> Then what?

First all identifiers must be lowercase so you'll have :

enum A { x; z; }
enum B { x; z; }

then "x" and "z" are of type B, but you can still refer explicitly to 
A.x or B.z which will disambigous the cases. Also, in a "switch", if the 
type matched is A you can directly use "x" and "z" even if they don't 
have priority in current scope.

> Anyway, I'm going to experiment with it as I regularly use both js and as...

JS generator is not yet ready, will be done by next month.

Best,

Nicolas

---
Neko : One VM to run them all
Permalink | Reply | 0 comments |
headers
Nicolas Cannasse | 26 Dec 2005 19:26
Favicon
Gravatar

TCO and Call/CC

Hi list,

I added today Tail-Call Optimization (TCO) to Neko.
I'm planing to implement soon "continuations" (call/cc)

Anyone having a good idea for a call/cc API in Neko ?

Nicolas

---
Neko : One VM to run them all
Permalink | Reply | 8 comments |
headers
Hermann Kruud | 27 Dec 2005 03:00
Picon
Favicon

Building Neko VM in Mac OS X

Hi!

I'm trying to build Neko VM 1.1 and the current CVS
revision in Mac OS X.4.3, but I get:

  $ make
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/alloc.o -c vm/alloc.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/builtins.o -c vm/builtins.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/callback.o -c vm/callback.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/context.o -c vm/context.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/interp.o -c vm/interp.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/load.o -c vm/load.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/objtable.o -c vm/objtable.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/others.o -c vm/others.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/hash.o -c vm/hash.c
  /usr/bin/gcc -Wall -O3 -fPIC -fomit-frame-pointer -I
vm -DCOMPACT_TABLE -o vm/module.o -c vm/module.c
  gcc-4 -dynamic -o bin/libneko.so vm/alloc.o
vm/builtins.o vm/callback.o vm/context.o vm/interp.o
vm/load.o vm/objtable.o vm/others.o vm/hash.o
vm/module.o -ldl -lgc -lm
  /usr/bin/ld: Undefined symbols:
  _main
  collect2: ld returned 1 exit status
  make: *** [bin/libneko.so] Error 1

I uncommented the two lines under the "For OSX"
comment in the Makefile. And I tried compiling with
GCC versions 3.3 and 4.0.

I'd love to get this thing working, because I'm very
eager to try to compile haXe into Neko.

HK

___________________________________________________________
Don't buy what they're selling below!

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

---
Neko : One VM to run them all
Permalink | Reply | 6 comments |
headers
Nicolas Cannasse | 27 Dec 2005 10:14
Favicon
Gravatar

Re: Building Neko VM in Mac OS X

> Hi!
> 
> I'm trying to build Neko VM 1.1 and the current CVS
> revision in Mac OS X.4.3, but I get:
> 
> I uncommented the two lines under the "For OSX"
> comment in the Makefile. And I tried compiling with
> GCC versions 3.3 and 4.0.
> 
> I'd love to get this thing working, because I'm very
> eager to try to compile haXe into Neko.
> 
> 
> HK

Hi,

There should not be so many problems with compiling Neko on OSX. 
Actually, someone already send me a patch for this, but there was some 
changes in the C sources that I'm not sure if they are not other way of 
doing it.

- first you need to build a shared library (bin/libneko.dylib). the "gcc 
-shared" parameter is not supported on OSX. I read somewhere that you 
need to use "gcc -dynamiclib". One other option is to use "libtool 
-dynamic" at link time, although I would prefer to know how to do with gcc

- it seems that OSX makes a difference between "shared" (.dylib) and 
"dynamicly loadable" (.bundle/.so) libraries. Other .ndll libraries need 
to be compiled as "dynamicly loadable", only libneko.dylib is really 
"shared" in the sense of OSX.

- there was another error at linking time that was due to some C globals 
not being initialized. I would like to avoid initializing all the 
globals and I think this should be possible with some compilation flag.

Anyway thanks for your help, with only a few Makefile changes it should 
be possible to compile Neko on OSX.

Best,
Nicolas

---
Neko : One VM to run them all
Permalink | Reply | 5 comments |
headers
Robert Feldt | 27 Dec 2005 19:55
Picon

Re: TCO and Call/CC

On 12/26/05, Nicolas Cannasse <ncannasse <at> motion-twin.com> wrote:
> Hi list,
>
> I added today Tail-Call Optimization (TCO) to Neko.
> I'm planing to implement soon "continuations" (call/cc)
>
> Anyone having a good idea for a call/cc API in Neko ?
>
Not really but with these additions Neko will go higher up on my list
of targets for a coming Ruby compiler.

Thanks for the good work,

Robert Feldt

---
Neko : One VM to run them all
Permalink | Reply | 7 comments |
headers
Nicolas Cannasse | 27 Dec 2005 20:17
Favicon
Gravatar

Re: TCO and Call/CC

>>Hi list,
>>
>>I added today Tail-Call Optimization (TCO) to Neko.
>>I'm planing to implement soon "continuations" (call/cc)
>>
>>Anyone having a good idea for a call/cc API in Neko ?
>>
> 
> Not really but with these additions Neko will go higher up on my list
> of targets for a coming Ruby compiler.
> 
> Thanks for the good work,
> 
> Robert Feldt

That would be pretty interesting.
Could you say more about your project ?

(BTW I'm currently working on some - still experimental - JIT)

Nicolas

---
Neko : One VM to run them all
Permalink | Reply | 6 comments |
headers
Robert Feldt | 28 Dec 2005 01:18
Picon

Re: TCO and Call/CC

On 12/27/05, Nicolas Cannasse <ncannasse <at> motion-twin.com> wrote:
> >>Anyone having a good idea for a call/cc API in Neko ?
> >>
> >
> > Not really but with these additions Neko will go higher up on my list
> > of targets for a coming Ruby compiler.
> >
> > Thanks for the good work,
> >
> > Robert Feldt
>
> That would be pretty interesting.
> Could you say more about your project ?
>
I had a student some time back who started on a Ruby to CIL compiler.
However, continuations is a real problem/pain on the CLR/CIL so
if/when Neko supports that I have plans on having someone look into
using Neko as a first target instead of the CLR/CIL.

I have barely checked out the basics of Neko so far though. Do you
have any recommendations on how people should/could be mapping
dynamically typed OO langs to Neko? A naive Ruby-to-Neko mapping would
be to simply use Neko objects directly but that will not work when
instance methods on inherited classes change (since I imagine $new()
really does a copy of all the fields of the object). One alternative
would be to do the recursive traversal of classes up the class
hierarchy explicitly by linking "instance prototype" objects. But then
each method call would have to be done with something like:

rmcall = function(object, methodint, args) {
  lm = $objget(object, methodint);
  if $typeof(lm) == $tfunction {
    return ($objcall(object, methodint, args));
  } else {
    if lm == null {
      so = object._ <at> super
      if so == null {
        throw("Method missing exception");
      } else {
        return rmcall(so, methodint, args);
      }
    } else {
      throw("Calling value field as a method exception!");
    };
  };
};

but then it is not clear to me what I would really gain by using the
builtin objects. Can you elaborate on your ideas about language
interoperability on this issue?

I guess other alternatives would be to "roll out" the hierarchy by
having the "instance prototype" object for each Ruby class having the
correct neko function in each slot and instead updating all the
affected "instance prototype" objects when there is a method
changed/added. However, it is not clear what performance/mem
implications that solution will have. Is there any sharing between
(similar/copied/cloned) neko objects?

Thanks,

Robert Feldt

---
Neko : One VM to run them all
Permalink | Reply | 5 comments |

Gmane