Testing require

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Testing require

Nicolas Cannasse
Hi list,

The whole compile team (Franco, Hugh and myself) have made many
improvements to haXe in the past weeks, and 2.07 release should be
released in a few days.

Please test your code using automated builds which are available here :
http://haxe.cmt.tc/
This way we can make sure that we have not overlooked any issue ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

jlm@justinfront.net
Er the latest seems to be empty for mac10.5 
[   ]haxe_r3631.tar.gz18-Jan-2011 16:35 0 

Is the 12:41 ok?

On 18 Jan 2011, at 20:45, Nicolas Cannasse wrote:

Hi list,

The whole compile team (Franco, Hugh and myself) have made many improvements to haXe in the past weeks, and 2.07 release should be released in a few days.

Please test your code using automated builds which are available here :
http://haxe.cmt.tc/
This way we can make sure that we have not overlooked any issue ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Cauê W.
oops! :)

fixed! - internet problem when sending it! :S

2011/1/18 [hidden email] <[hidden email]>
Er the latest seems to be empty for mac10.5 
[   ]haxe_r3631.tar.gz18-Jan-2011 16:35 0 

Is the 12:41 ok?

On 18 Jan 2011, at 20:45, Nicolas Cannasse wrote:

Hi list,

The whole compile team (Franco, Hugh and myself) have made many improvements to haXe in the past weeks, and 2.07 release should be released in a few days.

Please test your code using automated builds which are available here :
http://haxe.cmt.tc/
This way we can make sure that we have not overlooked any issue ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

James W. Hofmann
In reply to this post by Nicolas Cannasse
Win32 R3631

When compiling my main source base to SWF10, -debug flag enabled, Flash Debug Projector immediately fails at boot:

VerifyError: Error #1014: Class flash::Error could not be found.

Removing -debug fixes the problem.

Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Robin Palotai
On Linux flash seems to boot ok with a variety ok players (both normal
and debug mode).

On Tue, Jan 18, 2011 at 10:46 PM, James W. Hofmann <[hidden email]> wrote:

>
> Win32 R3631
>
> When compiling my main source base to SWF10, -debug flag enabled, Flash
> Debug Projector immediately fails at boot:
>
> VerifyError: Error #1014: Class flash::Error could not be found.
>
> Removing -debug fixes the problem.
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Testing-require-tp5936936p5937345.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Nicolas Cannasse
In reply to this post by James W. Hofmann
Le 18/01/2011 22:46, James W. Hofmann a écrit :
>
> Win32 R3631
>
> When compiling my main source base to SWF10, -debug flag enabled, Flash
> Debug Projector immediately fails at boot:
>
> VerifyError: Error #1014: Class flash::Error could not be found.
>
> Removing -debug fixes the problem.

Make sure that you have latest SVN "std" directory as well, flash.Error
is now flash.errors.Error

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
In reply to this post by Nicolas Cannasse
  There are some issues when using --gen-hx-classes to create header
classes, but I don't know if they are new because I never used the
feature before:

- type parameters are missing on static functions (Type, Reflect,
Lambda, List)
- haxe.remote.AsyncConnection implements itself
- @:core_api checks fail due to extra members (on flash: IntHash, Hash)
- Void -> Dynamic becomes -> Dynamic (hsl.haxe.DirectSignaler.bindVoid)

I suppose --gen-hx-classes wasn't intended to be used like that anyway,
but it's just sooo convenient to create these headers!

Looking forward to 2.07.
Simon


Am 18.01.2011 20:45, schrieb Nicolas Cannasse:

> Hi list,
>
> The whole compile team (Franco, Hugh and myself) have made many
> improvements to haXe in the past weeks, and 2.07 release should be
> released in a few days.
>
> Please test your code using automated builds which are available here :
> http://haxe.cmt.tc/
> This way we can make sure that we have not overlooked any issue ;)
>
> Best,
> Nicolas
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Nicolas Cannasse
Le 18/01/2011 23:34, Simon Krajewski a écrit :
> There are some issues when using --gen-hx-classes to create header
> classes, but I don't know if they are new because I never used the
> feature before:
>
> - type parameters are missing on static functions (Type, Reflect,
> Lambda, List)
> - haxe.remote.AsyncConnection implements itself
> - @:core_api checks fail due to extra members (on flash: IntHash, Hash)
> - Void -> Dynamic becomes -> Dynamic (hsl.haxe.DirectSignaler.bindVoid)

All of these should be now fixed, thanks for reporting.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
  Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
> All of these should be now fixed, thanks for reporting.

Wow, thanks! I can't check right now, but I just remembered another one:

class SocketConnection implements AsyncConnection, implements
Dynamic<AsyncConnection>

The header implemented AsyncConnection twice and dropped the Dynamic,
which made the standard use of scnx.api for remoting impossible.

Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
  Am 19.01.2011 10:20, schrieb Simon Krajewski:

>  Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
>> All of these should be now fixed, thanks for reporting.
>
> Wow, thanks! I can't check right now, but I just remembered another one:
>
> class SocketConnection implements AsyncConnection, implements
> Dynamic<AsyncConnection>
>
> The header implemented AsyncConnection twice and dropped the Dynamic,
> which made the standard use of scnx.api for remoting impossible.

Actually that seems to be the same error as the other implements one, so
never mind.
Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
In reply to this post by Nicolas Cannasse
  Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
> All of these should be now fixed, thanks for reporting.

I could test them now, works great. Thanks for your work!

One more thing I encountered:

interface IEngineHandler<A> {
     public function executeAction(user:User, action:A):Void;
}

import core.model.Action;
class ApiClient implements IEngineHandler<Action> {
     public function executeAction(user:User, action:Action):Void { }
}

This will produce

extern class ApiClient implements IEngineHandler<core.model.Action> {
     function executeAction(user : User, action : A) : Void;
}

Where A should be core.model.Action instead.

Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Gustavs
Are you planning to add automatic 'var me=this' for closures?

On 19/01/2011, Simon Krajewski <[hidden email]> wrote:

>   Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
>> All of these should be now fixed, thanks for reporting.
>
> I could test them now, works great. Thanks for your work!
>
> One more thing I encountered:
>
> interface IEngineHandler<A> {
>      public function executeAction(user:User, action:A):Void;
> }
>
> import core.model.Action;
> class ApiClient implements IEngineHandler<Action> {
>      public function executeAction(user:User, action:Action):Void { }
> }
>
> This will produce
>
> extern class ApiClient implements IEngineHandler<core.model.Action> {
>      function executeAction(user : User, action : A) : Void;
> }
>
> Where A should be core.model.Action instead.
>
> Simon
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Michiel Crefcoeur
+1 :-)

2011/1/19 Gustavs <[hidden email]>
Are you planning to add automatic 'var me=this' for closures?

On 19/01/2011, Simon Krajewski <[hidden email]> wrote:
>   Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
>> All of these should be now fixed, thanks for reporting.
>
> I could test them now, works great. Thanks for your work!
>
> One more thing I encountered:
>
> interface IEngineHandler<A> {
>      public function executeAction(user:User, action:A):Void;
> }
>
> import core.model.Action;
> class ApiClient implements IEngineHandler<Action> {
>      public function executeAction(user:User, action:Action):Void { }
> }
>
> This will produce
>
> extern class ApiClient implements IEngineHandler<core.model.Action> {
>      function executeAction(user : User, action : A) : Void;
> }
>
> Where A should be core.model.Action instead.
>
> Simon
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Nicolas Cannasse
In reply to this post by Gustavs
Le 19/01/2011 13:43, Gustavs a écrit :
> Are you planning to add automatic 'var me=this' for closures?

There's too much changes already so you'll have to wait after 2.07 is
out until it's available.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
In reply to this post by Nicolas Cannasse
  Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
> All of these should be now fixed, thanks for reporting.

Now all my exciting header/lib experiments received a heavy blow when I
realized I couldn't use macros in flash projects anymore. With a
generated header of haxe.io.BytesData in my -cp, the macro environment
rightfully complains about the typedef
     extern typedef BytesData = flash.utils.ByteArray
because
     "You can't access the flash package with current compilation flags
(for flash.utils.ByteArray)".

I don't think there's an obvious solution to this. The neko macro
environment could ignore all hxclasses -cps, but that might lead to
other issues in some cases. For now I solve this by adding a
hxclassesfix to my -cp that overwrites the problem classes with the std.

I didn't test having a neko generated hxclasses in the -cp yet, but it's
probably even worse due to externs leading to nowhere when running a macro.

Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Baluta Cristian
I have a project in which every trace i do is displayed as four "????" and the project is not working also
Seems to be OVA swf library fault (if you remember you helped me generating the headers Nicolas)
I'll try to post the necessary files later.

On Thu, Jan 20, 2011 at 1:07 PM, Simon Krajewski <[hidden email]> wrote:
 Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
All of these should be now fixed, thanks for reporting.

Now all my exciting header/lib experiments received a heavy blow when I realized I couldn't use macros in flash projects anymore. With a generated header of haxe.io.BytesData in my -cp, the macro environment rightfully complains about the typedef
   extern typedef BytesData = flash.utils.ByteArray
because
   "You can't access the flash package with current compilation flags (for flash.utils.ByteArray)".

I don't think there's an obvious solution to this. The neko macro environment could ignore all hxclasses -cps, but that might lead to other issues in some cases. For now I solve this by adding a hxclassesfix to my -cp that overwrites the problem classes with the std.

I didn't test having a neko generated hxclasses in the -cp yet, but it's probably even worse due to externs leading to nowhere when running a macro.

Simon


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Nicolas Cannasse
In reply to this post by Simon Krajewski
Le 20/01/2011 12:07, Simon Krajewski a écrit :

> Am 19.01.2011 10:00, schrieb Nicolas Cannasse:
>> All of these should be now fixed, thanks for reporting.
>
> Now all my exciting header/lib experiments received a heavy blow when I
> realized I couldn't use macros in flash projects anymore. With a
> generated header of haxe.io.BytesData in my -cp, the macro environment
> rightfully complains about the typedef
> extern typedef BytesData = flash.utils.ByteArray
> because
> "You can't access the flash package with current compilation flags (for
> flash.utils.ByteArray)".
>
> I don't think there's an obvious solution to this. The neko macro
> environment could ignore all hxclasses -cps, but that might lead to
> other issues in some cases. For now I solve this by adding a
> hxclassesfix to my -cp that overwrites the problem classes with the std.

Could you explain a bit how/why you're using --gen-hx-headers ?

Nicolas


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Simon Krajewski
  Am 20.01.2011 14:16, schrieb Nicolas Cannasse:
> Could you explain a bit how/why you're using --gen-hx-headers ?
I am currently working on my diploma thesis and as part of that explore
the possibility of modular development of flash applications using haxe.
I basically have a .dll functionality with .swf files now.

Imagine a central core shell that contains a lot of basic GUI elements,
the functionality to load .swf files into its ApplicationDomain and some
basic User class. No other logic whatsoever. I can compile that
application to a .swf and also use --gen-hx-headers to create a set of
header files.

A module can then add the hxclasses of the core to its -cp and gets
fully typed access to the GUI elements. Compiling a module results in a
very small .swf containing the logic of the module only, with references
to GUI elements of the core. It cannot run by itself, but that's why
it's called a module after all. The core application can load it into
its ApplicationDomain at runtime, thus resolving all references. A
module also exports its own hxclasses, so a second module can -cp these
and use functionality of the first module without actually including its
implementation.

For instance, I made a chat.swf module that contains the usual
Channel/User/Message stuff, and any fancygame.swf module can access this
via -cp chat/hxclasses to create a game channel and send game related
messages. Compilation is super fast for modules and I never really have
to recompile the core.

Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Baluta Cristian
Hello Nicolas, here are the files: http://dl.transfer.ro/haxe2.07test-transfer_RO-21jan-eae9c7.zip

Seems that is not the swf library fault, but of the generated hxclasses. If you compile with the hxclasses -cp the traces are "????", if you comment that -cp the traces are fine. The traces are also fine with the current stable haxe.

On Thu, Jan 20, 2011 at 3:54 PM, Simon Krajewski <[hidden email]> wrote:
 Am 20.01.2011 14:16, schrieb Nicolas Cannasse:

Could you explain a bit how/why you're using --gen-hx-headers ?
I am currently working on my diploma thesis and as part of that explore the possibility of modular development of flash applications using haxe. I basically have a .dll functionality with .swf files now.

Imagine a central core shell that contains a lot of basic GUI elements, the functionality to load .swf files into its ApplicationDomain and some basic User class. No other logic whatsoever. I can compile that application to a .swf and also use --gen-hx-headers to create a set of header files.

A module can then add the hxclasses of the core to its -cp and gets fully typed access to the GUI elements. Compiling a module results in a very small .swf containing the logic of the module only, with references to GUI elements of the core. It cannot run by itself, but that's why it's called a module after all. The core application can load it into its ApplicationDomain at runtime, thus resolving all references. A module also exports its own hxclasses, so a second module can -cp these and use functionality of the first module without actually including its implementation.

For instance, I made a chat.swf module that contains the usual Channel/User/Message stuff, and any fancygame.swf module can access this via -cp chat/hxclasses to create a game channel and send game related messages. Compilation is super fast for modules and I never really have to recompile the core.

Simon


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing require

Baluta Cristian
i'm using osx 10.5.8 btw.

On Fri, Jan 21, 2011 at 5:08 PM, Baluta Cristian <[hidden email]> wrote:
Hello Nicolas, here are the files: http://dl.transfer.ro/haxe2.07test-transfer_RO-21jan-eae9c7.zip

Seems that is not the swf library fault, but of the generated hxclasses. If you compile with the hxclasses -cp the traces are "????", if you comment that -cp the traces are fine. The traces are also fine with the current stable haxe.

On Thu, Jan 20, 2011 at 3:54 PM, Simon Krajewski <[hidden email]> wrote:
 Am 20.01.2011 14:16, schrieb Nicolas Cannasse:

Could you explain a bit how/why you're using --gen-hx-headers ?
I am currently working on my diploma thesis and as part of that explore the possibility of modular development of flash applications using haxe. I basically have a .dll functionality with .swf files now.

Imagine a central core shell that contains a lot of basic GUI elements, the functionality to load .swf files into its ApplicationDomain and some basic User class. No other logic whatsoever. I can compile that application to a .swf and also use --gen-hx-headers to create a set of header files.

A module can then add the hxclasses of the core to its -cp and gets fully typed access to the GUI elements. Compiling a module results in a very small .swf containing the logic of the module only, with references to GUI elements of the core. It cannot run by itself, but that's why it's called a module after all. The core application can load it into its ApplicationDomain at runtime, thus resolving all references. A module also exports its own hxclasses, so a second module can -cp these and use functionality of the first module without actually including its implementation.

For instance, I made a chat.swf module that contains the usual Channel/User/Message stuff, and any fancygame.swf module can access this via -cp chat/hxclasses to create a game channel and send game related messages. Compilation is super fast for modules and I never really have to recompile the core.

Simon


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
12