2.10 Release Candidate !

[Nicolas Cannasse]

Hi,

I'm please to announce that the Haxe 2.10 Release Candidate is now
available for testing !

I've posted many details here :

http://ncannasse.fr/blog/haxe_2_10_rc

Please download it from http://haxe.org/download#manual-install, give it
a try, and report us any error that you might find before we make an
official 2.10 !

Enjoy !

Nicolas

[Justin Donaldson]

I've been following the java/c# development, and it's a great addition.  Cauê did some really clever things to speed up reflection in java, making it practical for typical web coding styles.  I also feel confident recommending haxe for js projects now.  The overload, DCE, and --modern features are a huge improvement.   Finally, it's great to see new faces contributing to the core.

Best,

-Justin

p.s. Good idea using the release candidate approach, too.

--
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald

[Renaud Bardet]

Great !

here is what I tested so far :

allow direct initialization of properties and member variables 

works, except I can do the following

public var bar(default, never) : String = "some ploppy plop" ;

is it normal behaviour ? Doesn't sound like the "never" accessibility

using now imply import as well 

did it not already ? I use 2.08 and I don't import each time I'm using ;)

sub classes can now widen method visibility 

works great

overriden methods can now be covariant wrt to the original definition 

works great

allows callback(foo,_,0) notation instead of function(x) return foo(x,0) 

this is great (also works fine)

local named functions can now have type parameters and be declared as inline 

also works great 

type constraints are now supported on function and methods type parameters 

works, but not for a local named function (maybe it's too much asking ;)), it doesn't crash but let anything in

I wrote very basic example to test those so it's far from intensive testing,

I also compiled and run a whole big project with no errors, so no regression to report ;)

I must say these are really great additions to the language!

Congrats to everyone!

[Maximiliano Fernández]

"A Haxe/C++ Debugger is on the way ! You should soon be able to debug your code interactively whatever the platform you target."

This was a real surprise for me, didn't expect that. Have we some way to test this marvelous debugger in this RC release? Can't way for it :)

Maximiliano Fernández do Santos

0 1 0              0 1 0

0 0 1  Rammserker  1 0 0

1 1 1              1 1 1

[Nicolas Cannasse]

Le 22/06/2012 21:08, Maximiliano Fern�ndez a �crit :
> "/*A Haxe/C++ Debugger* is on the way ! You should soon be able to debug
> your code interactively whatever the platform you target./"

>
> This was a real surprise for me, didn't expect that. Have we some way to
> test this marvelous debugger in this RC release? Can't way for it :)

Hugh announced it at WWX already ;) I guess he can comment on the
current status/progress he's made.

Best,
Nicolas

[Nicolas Cannasse]

> works, except I can do the following
> |

> publicvarbar(default,never):String="some ploppy plop";

> |
> is it normal behaviour ? Doesn't sound like the "never" accessibility

Yes it seems normal.

It will be never writable after you have set it. The equivalent of
"const" in some other languages.

> |using| now imply |import| as well
>
> did it not already ? I use 2.08 and I don't import each time I'm using ;)

Well, you didn't need to import to access the using fields but if you
had enums defined in the module they didn't get imported.

> type constraints are now supported on function and methods type
> parameters
>
> works, but not for a local named function (maybe it's too much asking
> ;)), it doesn't crash but let anything in

Thanks, please fill a report on google code issues so we at least forbid
it or even better support it.

> I wrote very basic example to test those so it's far from intensive testing,
> I also compiled and run a whole big project with no errors, so no
> regression to report ;)

You can also make sure that your project compiles with -D haxe3, it will
activate some changes we are planning to enforce for 3.0

Best,
Nicolas

[blue...@gmail.com]

js.Boot.getClass seems to be missing in the generated javascript when we compile Prime's CSS parser.

Type.getClass = function(o) {

if(o == null) return null;

return js.Boot.getClass(o);

}

...

# Node.js stacktrace

#

PrimeVC/build/parser.js:244

return js.Boot.getClass(o);

TypeError: Object function () { } has no method 'getClass'

    at Function.getClass (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:244:17)

    at Object.setBackground (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:8775:80)

    at Object.parseAndSetBackground (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:8791:9)

    at Object.handleMatchedProperty (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:8134:9)

    at /Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11224:59

    at Function.matchAll (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11104:3)

    at Object.parseBlock (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:8033:26)

    at Object.handleMatchedBlock (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:7899:26)

    at /Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11224:59

    at Function.matchAll (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11104:3)

Op vrijdag 22 juni 2012 19:20:35 UTC+2 schreef Nicolas Cannasse het volgende:

[blue...@gmail.com]

And this one is even funnier! When compiling with --js-modern:

PrimeVC/build/parser.js:11254

if(typeof(haxe_timers) == "undefined") haxe_timers = [];

                                                   ^

ReferenceError: haxe_timers is not defined

    at /Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11254:52

    at Object.<anonymous> (/Users/blue/Development/Online Touch/editor/shared/PrimeVC/build/parser.js:11301:2)

    at Module._compile (module.js:446:26)

    at Object..js (module.js:464:10)

    at Module.load (module.js:353:31)

    at Function._load (module.js:311:12)

    at Array.0 (module.js:484:10)

    at EventEmitter._tickCallback (node.js:190:38)

Op vrijdag 22 juni 2012 19:20:35 UTC+2 schreef Nicolas Cannasse het volgende:

Hi,

[Nicolas Cannasse]

Le 22/06/2012 23:35, blue...@gmail.com a �crit :

> js.Boot.getClass seems to be missing in the generated javascript when we
> compile Prime's CSS parser.

Maybe the Node library is defining it's own js.Boot ? In the case try to
remove it to use 2.10 one.

Best,
Nicolas

[Nicolas Cannasse]

Le 22/06/2012 23:39, blue...@gmail.com a �crit :

> And this one is even funnier! When compiling with --js-modern:
>
> PrimeVC/build/parser.js:11254
> if(typeof(haxe_timers) == "undefined") haxe_timers = [];

I think this is similar, the Node library is including an old version of
haxe.Timer. Try to use the 2.10 one.

Could you also inform the library author so he can make appropriate
changes before 2.10 is released ?

Best,
Nicolas

[Jason O'Neil]

Hi Nicolas,

Looks good! I was hoping to submit a patch for haxelib before I go to
sleep tonight (adding functionality so that you can install libraries
via hxml build file).

If you're keen for this to be included I'd appreciate holding off before
releasing. Otherwise it can wait till the next version :)

Jason

[Nicolas Juneau]

Hi,

 

I have a little suggestion for the final release (if such a thing doesn't exist already), but is it possible to have source tarballs for download? I believe it would be easier to compile a stable version from source than having to know the specific revision to checkout from SVN.

--

Nicolas Juneau

[clemos]

Hi

I just attempted to upgrade try.haxe.org with latest SVN.
But it looks like something is broken, and now the haxe compiler
process never ends...

The compiler execute code is quite classic:

var proc = new sys.io.Process( "haxe" , args );

var err = proc.stderr.readAll().toString();
var out = proc.stdout.readAll().toString();
var exit = proc.exitCode();

//proc.close();

var o = {
proc : proc,
exitCode : exit,
out : out,
err : err
};

return o;

It used to work (with r4796), but now it just never ends (see try.haxe.org)...
Even weirder, everything works fine for me locally (Ubuntu 64), but
not on the server (Ubuntu 32).
Also, other processes seem to run fine and end properly ("ls" for instance).

Maybe there have been recent changes in the way the haxe compiler
outputs things (stderr, stdout, exit code, whatever) that make it
impossible for the PHP Process to "readAll" or something ?

I'm sorry to bring it to the list, but I don't really have any clue here.

Regards,
Clément

[blue...@gmail.com]

After removing all non-std Boot.hx I could find, almost got it to work. 

It looks like public inline methods are removed when they are only called via an interface.

Op vrijdag 22 juni 2012 23:55:23 UTC+2 schreef Nicolas Cannasse het volgende:

Le 22/06/2012 23:39, blue...@gmail.com a �crit :

[blue...@gmail.com]

Hash.prototype.keys() returns a.iterator();

But Array.prototype has no iterator();

DCE is turned off btw.  Aggressive optimizations! ;-)

Op vrijdag 22 juni 2012 19:20:35 UTC+2 schreef Nicolas Cannasse het volgende:

[blue...@gmail.com]

Sorry, DCE is on after all :)

Op zaterdag 23 juni 2012 19:11:52 UTC+2 schreef (onbekend) het volgende:

[Simon Krajewski]

I can't think of anything that should affect it. The last change to
main.ml was in r4940, but that shouldn't break anything. Note that
Nicolas is on vacation, so you should probably revert try.haxe.org to a
previous haxe version for now. Could you maybe try some different
revisions to see if you can find the one that broke things?

Simon

[dlots]

After removing all non-std Boot.hx I could find, almost got it to work. 

It looks like public inline methods are removed when they are only called via an interface.

What? Please confirm what you mean.

[Benjamin Dubois]

Nice to see, there is a release candidate before the release.

A good move.

Ben

On Sun, Jun 24, 2012 at 6:05 AM, dlots <image...@gmail.com> wrote:

After removing all non-std Boot.hx I could find, almost got it to work. 

It looks like public inline methods are removed when they are only called via an interface.

What? Please confirm what you mean.

On Saturday, June 23, 2012 1:01:20 PM UTC-4, (unknown) wrote:

After removing all non-std Boot.hx I could find, almost got it to work. 

It looks like public inline methods are removed when they are only called via an interface.

Op vrijdag 22 juni 2012 23:55:23 UTC+2 schreef Nicolas Cannasse het volgende:

Le 22/06/2012 23:39, blue...@gmail.com a �crit :
> And this one is even funnier! When compiling with --js-modern:
>
> PrimeVC/build/parser.js:11254
> if(typeof(haxe_timers) == "undefined") haxe_timers = [];

I think this is similar, the Node library is including an old version of
haxe.Timer. Try to use the 2.10 one.

Could you also inform the library author so he can make appropriate
changes before 2.10 is released ?

Best,
Nicolas

--

[clemos]

On Sun, Jun 24, 2012 at 12:16 AM, Simon Krajewski
<simon.k...@simn.de> wrote:
>
> I can't think of anything that should affect it. The last change to main.ml
> was in r4940, but that shouldn't break anything. Note that Nicolas is on
> vacation, so you should probably revert try.haxe.org to a previous haxe
> version for now. Could you maybe try some different revisions to see if you
> can find the one that broke things?

Ok I finally managed to fix it.
It was apparently related to haxelib that was "blocking", somehow, so
I upgraded it as well.
So in case anybody else has this problem, don't forget to upgrade haxelib...

So try.haxe.org uses r4957 now :)

Regards,
Clément

[Jason O'Neil]

Problems doing a manual install with Linux64.  The usual

    haxelib: error while loading shared libraries: libneko.so: wrong ELF class: ELFCLASS64

Would be wonderful if we can make this *actually work* out of the box before an official release.

[Philipp Klose]

You need to install a 64 bit neko version, or get a 32bit Haxe running.
(Previously it was possible to have 32bit neko and 64bit haxe, but not
anymore)

> <mailto:haxe...@googlegroups.com>
> http://groups.google.com/group/haxelang?hl=en

[Jason O'Neil]

I already had 64bit neko installed.  Haxelib is a compiled binary, presumably in the download it is compiled against 32 bit.

My solution:

    haxe std/haxelib/haxelib.xml
    cp std/haxe/haxelib /usr/bin/haxelib

It's a pretty easy fix, just need to make sure we get it right when we release I guess.  Or get the PPA updated.  On another note someone has re-added "Install Haxe via the Ubuntu Software Center" to the download page.  Unfortunately that installs haxe 2.07.  *facepalm*

Jason

[Nicolas Cannasse]

Le 23/06/2012 17:09, clemos a �crit :

> Hi
>
> I just attempted to upgrade try.haxe.org with latest SVN.
> But it looks like something is broken, and now the haxe compiler
> process never ends...
>
> The compiler execute code is quite classic:
>
> var proc = new sys.io.Process( "haxe" , args );
>
> var err = proc.stderr.readAll().toString();
> var out = proc.stdout.readAll().toString();
> var exit = proc.exitCode();
>
> //proc.close();
>
> var o = {
> proc : proc,
> exitCode : exit,
> out : out,
> err : err
> };
>
> return o;
>
> It used to work (with r4796), but now it just never ends (see try.haxe.org)...
> Even weirder, everything works fine for me locally (Ubuntu 64), but
> not on the server (Ubuntu 32).
> Also, other processes seem to run fine and end properly ("ls" for instance).

Please note that this can happen in the following case :

a) the haxe process has written a lot of data on stdout and is trying to
write more, it is then waiting for the launcher process to read some of
it before writing more

b) the launcher process OTOH is waiting for some data on stderr (or for
the process termination)

This is a typical deadlock case, and is not easy to fix. The most simple
being to fire another thread that will read on stderr while the main
thread read on stdout.

Best,
Nicolas

[Cauê Waneck]

AFAIK the only guaranteed way to deal with this problem (if you don't need to interact with contents with stdin) is to call exitCode() before reading all from stderr/stdout:

var proc = new Process(...);

proc.exitCode();

trace(proc.stderr.readAll());

trace(proc.stdout.readAll());

2012/7/1 Nicolas Cannasse <ncan...@motion-twin.com>

[Nicolas Cannasse]

Le 01/07/2012 22:36, Cau� Waneck a �crit :

> AFAIK the only guaranteed way to deal with this problem (if you don't
> need to interact with contents with stdin) is to call exitCode() before
> reading all from stderr/stdout:

That does not work if the process output are buffered, since in case the
buffer is full they will block any write and wait for some read.

Best,
Nicolas

[Cauê Waneck]

really? wow, I've been using it always! I even had to force the support for java to this by reading the entire buffer when exitCode() is made and making it available to the stdout input later ;) 

Is readlAll() guaranteed to read until the process exits? I had some problems with it one time, when it was reading only part of it (since the operation was slow - svn) but the problem could be eleswhere.

2012/7/1 Nicolas Cannasse <ncan...@motion-twin.com>

Le 01/07/2012 22:36, Cauê Waneck a écrit :

AFAIK the only guaranteed way to deal with this problem (if you don't
need to interact with contents with stdin) is to call exitCode() before
reading all from stderr/stdout:

That does not work if the process output are buffered, since in case the buffer is full they will block any write and wait for some read.

Best,
Nicolas

[Nicolas Cannasse]

Le 01/07/2012 22:48, Cau� Waneck a �crit :

> really? wow, I've been using it always! I even had to force the support
> for java to this by reading the entire buffer when exitCode() is made
> and making it available to the stdout input later ;)
> Is readlAll() guaranteed to read until the process exits?

Yes.

Please note that the issue might be quite specific to OCaml enabling
buffered output for stdout and stderr, but you can quickly try to
reproduce by writing a small command that print a lot of data on both
stdout and stderr.

Best,
Nicolas