headers
Alexander Ramm | 11 Apr 2006 17:25

neko and commandline args

Hi,

First of all I want to thank Nicolas for all his great stuff he is doing 
and wish him all the best.

Second, I have a question (and hoping it's not a stupid one) regarding 
the boot function:
Is there any possibility to get the commandline arguments?
Eg. when calling ">myapp.exe teststring".

Thanks and regards,
Alex

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
Permalink | Reply | 1 comment |
headers
Nicolas Cannasse | 11 Apr 2006 18:00
Favicon
Gravatar

Re: neko and commandline args

> Hi,
> 
> First of all I want to thank Nicolas for all his great stuff he is doing 
> and wish him all the best.
> 
> Second, I have a question (and hoping it's not a stupid one) regarding 
> the boot function:
> Is there any possibility to get the commandline arguments?
> Eg. when calling ">myapp.exe teststring".
> 
> Thanks and regards,
> Alex

The arguments are stored in the array  $loader.args

Nicolas

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
Permalink | Reply | 0 comments |
headers
Alexander Ramm | 20 Apr 2006 09:30

stdout binary mode - unsigned int

Hi,

I have currently to issues:

1] The stdout should be opend in binary-mode not text-mode.
I run into problems as I tried to send an image to the webserver via 
stdout on the windows platform. The problem seems to be that the stdout 
(and might stdin) is opened in text-mode which makes all datastreams 
altered.
 From a few other mailing lists, the problem seems to be that the 
default option on ANSI-C is the textmode for the standart-streams which 
converts the line-carriges on windows.
However, I didn't done anyting a long time in C, therefore I guess it's 
more something for the next release.

2] I'm playing with haxe and neko and would like to build a few 
standart-libaries (zlib, jpeg, etc.). What might would do my job much 
easier, would be if there is anyhow a way to implement the native 
c-datatypes, since I sometimes need to work with the unsigned versions 
eg. of int32.

Alex

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
Permalink | Reply | 1 comment |
headers
Nicolas Cannasse | 20 Apr 2006 10:27
Favicon
Gravatar

Re: stdout binary mode - unsigned int

> Hi,
> 
> I have currently to issues:
> 
> 1] The stdout should be opend in binary-mode not text-mode.
> I run into problems as I tried to send an image to the webserver via 
> stdout on the windows platform. The problem seems to be that the stdout 
> (and might stdin) is opened in text-mode which makes all datastreams 
> altered.
>  From a few other mailing lists, the problem seems to be that the 
> default option on ANSI-C is the textmode for the standart-streams which 
> converts the line-carriges on windows.
> However, I didn't done anyting a long time in C, therefore I guess it's 
> more something for the next release.

Right now the stdout returned is the one that is opened by the terminal
by default. And it's always in text mode. There is two possibilities I see :

a) changing the output mode of stdout : I found the "setmode" C function
but it's neither ANSI nor POSIX, and I'm not sure it's supported on a
lot of platforms

b) closing then reopening the stdout. I remember using this trick by in
my system programming days, I don't remember exactly how it works and if
it's possible to do completely with current Neko API. Try to have a look
 and tell me if you need something.

> 2] I'm playing with haxe and neko and would like to build a few 
> standart-libaries (zlib, jpeg, etc.). What might would do my job much 
> easier, would be if there is anyhow a way to implement the native
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Gushee | 23 Apr 2006 19:49

Minor build error on Linux

Hi, all--

I am compiling Neko 1.2 on Linux, and noticed that if I simply type 
'make' in the top-level directory, the build fails because it can't 
create 'bin/libneko.so'--because the 'bin' directory doesn't exist. It's 
easy to fix with a moment's thought, but it would be nice if the 
directory existed in the source archive, or got created automatically.

-- 
Matt Gushee
The Reluctant Geek: http://matt.gushee.net/rg/

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
Permalink | Reply | 1 comment |
headers
Matt Gushee | 23 Apr 2006 23:20

Re: Minor build error on Linux

Matt Gushee wrote:

> 'make' in the top-level directory, the build fails because it can't 
> create 'bin/libneko.so'--because the 'bin' directory doesn't exist.

Oh, well ... I see it's fixed in CVS. Still, if you're going to offer a 
"stable release," maybe it should be patched.

-- 
Matt Gushee
The Reluctant Geek: http://matt.gushee.net/rg/

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
Permalink | Reply | 0 comments |
headers
daniel fischer | 26 Apr 2006 17:00

sharing pointer kinds between libraries


hey nicholas,

i'm having progress with my OpenGL wrapper, i'll publish soon.

one question tho- opengl uses plain double* and int* a lot. i have no problem in doing a simple neko library to
allocate/read/write those, so they are createable and accessible from neko (and thus haxe). what i
really want to do tho, is to share the kinds i define for those between libraries (GL and GLU for example, but
also others).

now, the ad-hoc way to do this of course is to make a new shared library (say, "cptr"), that exists both as a
.ndll providing the access/alloc functions, and as a .so to link the other libs (GL.ndll) against. then i
can DECLARE_KIND my kinds in cptr.h, and DEFINE_KIND them in libcptr.so, against which both cptr.ndll
and GL.ndll will link to have access to the kind.

tho i am thinking that these types are so fundamental and appear in libs again and again that it would be nice
to be able to use them without the additional burden of another shared lib. so- what do you think about
defining them as constant integers instead of using the memory address of a symbol? or is this too ugly
design-wise? if not, should they probably be defined in neko.h? or at least be part of the standard dist?

-dan

-- 
http://0xDF.com/
http://iterative.org/

--

-- 
Neko : One VM to run them all
(http://nekovm.org)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicolas Cannasse | 26 Apr 2006 17:47
Favicon
Gravatar

Re: sharing pointer kinds between libraries

> hey nicholas,
> 
> i'm having progress with my OpenGL wrapper, i'll publish soon.
> 
> one question tho- opengl uses plain double* and int* a lot. i have no problem in doing a simple neko library
to allocate/read/write those, so they are createable and accessible from neko (and thus haxe). what i
really want to do tho, is to share the kinds i define for those between libraries (GL and GLU for example, but
also others).
> 
> now, the ad-hoc way to do this of course is to make a new shared library (say, "cptr"), that exists both as a
.ndll providing the access/alloc functions, and as a .so to link the other libs (GL.ndll) against. then i
can DECLARE_KIND my kinds in cptr.h, and DEFINE_KIND them in libcptr.so, against which both cptr.ndll
and GL.ndll will link to have access to the kind.
> 
> tho i am thinking that these types are so fundamental and appear in libs again and again that it would be nice
to be able to use them without the additional burden of another shared lib. so- what do you think about
defining them as constant integers instead of using the memory address of a symbol? or is this too ugly
design-wise? if not, should they probably be defined in neko.h? or at least be part of the standard dist?

That's a good question.

I actualy already thought the same about the "hashtable" and "int32"
types. Should they be declared in libneko ? in the standard library ?
where should the exported api go ?

I made the following choices :

- int32 is declared in libneko, and has only very minor support
(printing). It's mainly used in Std but is "standardized" so the same
"kind" can be used in different libraries. Actually, the only reason
(Continue reading)

Permalink | Reply | 0 comments |

Gmane