Neko intermediate language compiler and virtual machine ()

ben kuin | 2 Mar 2010 10:57

nekoml: why no oo support?

hi
I think ocamls oo support is pretty controversial among experts. While
I don't like the syntax I think from a practical standpoint the oo
features makes sense (But then, I'm no expert  ).
As far as I can see nekoml is lacking oo completely, despite its roots
in ocaml and despite the prototype oo suport in the neko language.
So I'd like to ask:
Was the lack of oo support a deliberate design decision, or if it had
other reasons like technical difficulties?
Would it be possible to merge neko's oo features into nekoml?

thanks
ben

--

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

headers

Nicolas Cannasse | 2 Mar 2010 11:26

Re: nekoml: why no oo support?

ben kuin a écrit :
> hi
> I think ocamls oo support is pretty controversial among experts. While
> I don't like the syntax I think from a practical standpoint the oo
> features makes sense (But then, I'm no expert  ).
> As far as I can see nekoml is lacking oo completely, despite its roots
> in ocaml and despite the prototype oo suport in the neko language.
> So I'd like to ask:
> Was the lack of oo support a deliberate design decision, or if it had
> other reasons like technical difficulties?
> Would it be possible to merge neko's oo features into nekoml?

It was a design decision. I have been using OCaml for several years and 
had almost no use for OO, which is actually pretty hard to use IMHO. 
OTOH, haXe is an OO language with some of the OCaml features (minimal 
pattern matching, type inference, polymorphism).

I think that both paradigms have they own advantages. Although I like to 
program in haXe for everyday work, NekoML is a lot better for symbolic 
processing such as compilers.

Nicolas

--

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

headers

ben kuin | 2 Mar 2010 14:59

mutable vars in nekoml

hi
Nekomls documentation is a bit sparse, so I hope this excuses this
basic question:

How can I access the value of an mutable var (reference)? (There is
nothing written in the doc about mutables, so maybe I'm completely
wrong). It should be *var - no?

This doesn't work:

var mutbl = &0;
mutbl := 789;

print *mutbl;
error: Cannot unify '_a -> void and int
//  "Cannot unify '_a ..." what does that mean?

print mutbl;  // what does it show? I think  this should be the
reference itself ...
(789)

printf "my mutbl: %d" *mutbl;
error: Cannot unify int -> void and int

and for completeness:

printf "my mutbl: %d" mutbl;
error: Cannot unify int ref and int

regards

(Continue reading)

headers

Nicolas Cannasse | 2 Mar 2010 15:59

Re: mutable vars in nekoml

ben kuin a écrit :
> hi
> Nekomls documentation is a bit sparse, so I hope this excuses this
> basic question:
> 
> How can I access the value of an mutable var (reference)? (There is
> nothing written in the doc about mutables, so maybe I'm completely
> wrong). It should be *var - no?
> 
> This doesn't work:
> 
> var mutbl = &0;
> mutbl := 789;
> 
> print *mutbl;
> error: Cannot unify '_a -> void and int
> //  "Cannot unify '_a ..." what does that mean?

try :

print (*mutbl);

The * operator is ambiguous in some cases in NekoML.

Nicolas

--

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

(Continue reading)

headers

Justin Collins | 3 Mar 2010 06:13

Re: neko_check_stack failure

Nicolas Cannasse wrote:
> Justin Collins a écrit :
>> Hello all,
>>
>> I ran into a problem where module.c seems to be failing a stack check 
>> around line 151:
>>
>>    if( stack < istack || stack >= MAX_STACK_PER_FUNCTION - 4 )
>>
>> In particular, it is the "stack >= MAX_STACK_PER_FUNCTION - 4" which 
>> is true (and apparently bad).
>>
>> I am guessing this means something like I have too many local 
>> variables inside a function?
>
> Indeed.
> You cannot have more than 124 locals inside a given function.
> That's already a lot :)
>
> Best,
> Nicolas
>

Okay, granted. However, what about 124 locals at the top-level? That 
seems to fail, as well.
As I understand it, local variables are only copied into functions if 
they are accessed from those functions. This particular test seems to 
assume all local variables may be copied, whether they actually will or 
not. Is this correct?
My problem is that I generate a lot of short-lived, temporary variables.

(Continue reading)

headers

Nicolas Cannasse | 3 Mar 2010 09:53

Re: neko_check_stack failure

Justin Collins a écrit :
  > Okay, granted. However, what about 124 locals at the top-level? That
> seems to fail, as well.
> As I understand it, local variables are only copied into functions if 
> they are accessed from those functions. This particular test seems to 
> assume all local variables may be copied, whether they actually will or 
> not. Is this correct?

Yes, it will fail as well.

> My problem is that I generate a lot of short-lived, temporary variables. 
> They are not going to be accessed from inside other functions (so there 
> is no danger of having to copy 100+ variables to the function stack). I 
> don't want them to be globals, because I want them garbage collected as 
> soon as possible. What are my options?

Use {} blocks to separate the stacks :

{
  var v1,v2....v50;
  ...
}
{
   var v51,v52....v100;
   ...
}

This will ensure that your current stack never reach 128.

Best,

(Continue reading)

headers

Justin Collins | 3 Mar 2010 12:34

Re: neko_check_stack failure

Nicolas Cannasse wrote:
> Justin Collins a écrit :
>  > Okay, granted. However, what about 124 locals at the top-level? That
>> seems to fail, as well.
>> As I understand it, local variables are only copied into functions if 
>> they are accessed from those functions. This particular test seems to 
>> assume all local variables may be copied, whether they actually will 
>> or not. Is this correct?
>
> Yes, it will fail as well.
>
>> My problem is that I generate a lot of short-lived, temporary 
>> variables. They are not going to be accessed from inside other 
>> functions (so there is no danger of having to copy 100+ variables to 
>> the function stack). I don't want them to be globals, because I want 
>> them garbage collected as soon as possible. What are my options?
>
> Use {} blocks to separate the stacks :
>
> {
>  var v1,v2....v50;
>  ...
> }
> {
>   var v51,v52....v100;
>   ...
> }
>
> This will ensure that your current stack never reach 128.
>

(Continue reading)

headers

jmerrill | 3 Mar 2010 18:51

Re: neko_check_stack failure

Knowing nothing at all about what you're doing, I'm wondering -- could you make an array (or other data structure) that holds all the values? I would think that if you were to replace a not-needed value in an array with something else -- e.g. 0 -- then the value that had been in that slot would be eligible for GC right at that point (unless it was referenced elsewhere of course).

Could that solve your problem?

J. Merrill

From:	Justin Collins <justin <at> presidentbeef.com>
To:	Neko intermediate language mailing list <neko <at> lists.motion-twin.com>
Date:	03/03/2010 06:35 AM
Subject:	Re: [Neko] neko_check_stack failure
Sent by:	<neko-bounces <at> lists.motion-twin.com>

Nicolas Cannasse wrote:
> Justin Collins a écrit :
> > Okay, granted. However, what about 124 locals at the top-level? That
>> seems to fail, as well.
>> As I understand it, local variables are only copied into functions if
>> they are accessed from those functions. This particular test seems to
>> assume all local variables may be copied, whether they actually will
>> or not. Is this correct?
>
> Yes, it will fail as well.
>
>> My problem is that I generate a lot of short-lived, temporary
>> variables. They are not going to be accessed from inside other
>> functions (so there is no danger of having to copy 100+ variables to
>> the function stack). I don't want them to be globals, because I want
>> them garbage collected as soon as possible. What are my options?
>
> Use {} blocks to separate the stacks :
>
> {
> var v1,v2....v50;
> ...
> }
> {
> var v51,v52....v100;
> ...
> }
>
> This will ensure that your current stack never reach 128.
>
> Best,
> Nicolas
>

Aha, thank you.

It will take some thinking for me to figure how to use this...and
playing around with how it interacts with functions and other control
structures.

-Justin

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

--

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

headers

Justin Collins | 3 Mar 2010 20:31

Re: neko_check_stack failure

Hi,

Thanks for the suggestion, but I would like to avoid the overhead of 
storing everything in an array, if possible. In fact, I would like to 
not have to manage this at all. I am still thinking this check is being 
more conservative than it needs to be, although I will be trying the 
block idea.

-Justin

jmerrill <at> mmm.com wrote:
>
> Knowing nothing at all about what you're doing, I'm wondering -- could 
> you make an array (or other data structure) that holds all the values? 
>  I would think that if you were to replace a not-needed value in an 
> array with something else -- e.g. 0 -- then the value that had been in 
> that slot would be eligible for GC right at that point (unless it was 
> referenced elsewhere of course).
>
> Could that solve your problem?
>
> J. Merrill
>
>
>
> From: 	Justin Collins <justin <at> presidentbeef.com>
> To: 	Neko intermediate language mailing list <neko <at> lists.motion-twin.com>
> Date: 	03/03/2010 06:35 AM
> Subject: 	Re: [Neko] neko_check_stack failure
> Sent by: 	<neko-bounces <at> lists.motion-twin.com>
>
>
> ------------------------------------------------------------------------
>
>
>
> Nicolas Cannasse wrote:
> > Justin Collins a écrit :
> >  > Okay, granted. However, what about 124 locals at the top-level? That
> >> seems to fail, as well.
> >> As I understand it, local variables are only copied into functions if
> >> they are accessed from those functions. This particular test seems to
> >> assume all local variables may be copied, whether they actually will
> >> or not. Is this correct?
> >
> > Yes, it will fail as well.
> >
> >> My problem is that I generate a lot of short-lived, temporary
> >> variables. They are not going to be accessed from inside other
> >> functions (so there is no danger of having to copy 100+ variables to
> >> the function stack). I don't want them to be globals, because I want
> >> them garbage collected as soon as possible. What are my options?
> >
> > Use {} blocks to separate the stacks :
> >
> > {
> >  var v1,v2....v50;
> >  ...
> > }
> > {
> >   var v51,v52....v100;
> >   ...
> > }
> >
> > This will ensure that your current stack never reach 128.
> >
> > Best,
> > Nicolas
> >
>
> Aha, thank you.
>
> It will take some thinking for me to figure how to use this...and
> playing around with how it interacts with functions and other control
> structures.
>
> -Justin
>
> -- 
> Neko : One VM to run them all
> (http://nekovm.org <http://nekovm.org/>)
>
>
>

--

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

headers

Daniel Turing | 6 Mar 2010 20:53

Re: Hash.get(null) segfaults

On Wed, Jan 6, 2010 at 10:41, Nicolas Cannasse
<ncannasse <at> motion-twin.com> wrote:
> Daniel Turing a écrit :
>>
>> Hi,
>>
>> the following results in a SIGSEGV in neko_buffer_to_string() on neko
>> 1.8.1:
>>
>>    var hash = new Hash<Any>();
>>    hash.get(null);
>>
>> while, of course, get(null) is not a good idea to do, it surely
>> shouldnt segfault?
>
> I can't reproduce while using Neko CVS / Windows. But I don't see any recent
> change related to this either.

this just went away after installing haxe/neko with your official
linux installer; the problem must be related to the ubuntu packages i
had installed. can't really dig any deeper just now, posting this just
for reference...

-dan

--

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

5	March 2013
3	February 2013
8	January 2013
8	December 2012
10	October 2012
5	July 2012
16	May 2012
1	April 2012
33	March 2012
3	January 2012
1	December 2011
7	November 2011
22	October 2011
3	September 2011
5	August 2011
4	May 2011
8	March 2011
6	February 2011
15	January 2011
14	December 2010
5	November 2010
5	October 2010
6	September 2010
13	August 2010
5	July 2010
9	June 2010
31	May 2010
20	April 2010
14	March 2010
28	February 2010
54	January 2010
13	December 2009
12	November 2009
10	October 2009
19	September 2009
10	August 2009
37	July 2009
11	June 2009
18	May 2009
11	April 2009
23	March 2009
15	February 2009
16	January 2009
16	December 2008
21	November 2008
65	October 2008
25	September 2008
75	August 2008
44	July 2008
16	June 2008
10	May 2008
36	April 2008
25	March 2008
37	February 2008
24	January 2008
48	December 2007
64	November 2007
22	October 2007
12	September 2007
81	August 2007
43	July 2007
30	June 2007
48	May 2007
51	April 2007
71	March 2007
79	February 2007
52	January 2007
35	December 2006
72	November 2006
22	October 2006
32	September 2006
56	August 2006
83	July 2006
231	June 2006
111	May 2006
8	April 2006
84	March 2006
79	February 2006
101	January 2006
23	December 2005
25	November 2005
16	October 2005
15	September 2005