Hxcpp 2.05.0

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

Hxcpp 2.05.0

Gamehaxe
Hi,
I have just released hxcpp 2.05.0, via haxelib.
As you can seem I have changed the version numbers to match the
haxe release - this should make it a bit clearer what version of
hxcpp to use.

In addition the great development that Nicolas has put into the 2.05  
release,
the hxcpp target comes with the additional changes:

* Default to IMMIX based internal garbage collection.
* Reorginised files - split big ones, and moved common ones out of  
"runtime".
* Put internal classes in "hx" namespace, or HX_ prefix for macros.
* Remove multiple-inheritance, and use delegation instead.
* Write "Options.txt" from compiler so dependency can be determined.
* Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to avoid  
overhead if not required.
* Build thread code into executable for better control.
* Fix return values of parseINt/parseFloat.
* Added comprehensive list of reserved member names.
* Put if/else statements in blocks.
* Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
* Added control over how fast-cffi routines are created by requiring  
cpp.rtti.FastIntergerLookup to be "implemented".
* Construct anonymous object fields in deterministic (as declared) order.
* Fix code generation for some complex inline cases.
* Added cpp.zip.Compress
* Change "Reflect" class to be more standard
* Use array of dynamics for StringBuf.
* Fix setting of attributes in XML nodes.

Build-tool:
* Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N) for  
faster building on multi-code boxes.
* Added FileGroup dependencies
* Added pre-compiled headers (windows only, at the moment since gcc seems  
buggy)



The first 2 points are the biggest, although if you "just use" the target,
it should not make much difference.

By switching to the internal garbage collection, I was able to get modest
performance increases, however I also gain much greater control over
the source code.  For the end user, this means I will be able to offer
much more help when the compiler fails, ie avoid errors with boehm_gc
compile.

I have also added pre-compiled headers.  However, there was a bug in gcc
that made me disable it for that compiler.  Later version of gcc (>4.2 I  
think)
may have fixed this, so if you are interested, you may be able to get it  
going.

If you have a multi-core box, then you can speed up the compile time  
significantly.
Set the environment variable HXCPP_COMPILE_THREADS to the number of  
processors you
have - generally also count "hyper-threading cores".  So on a quad-core box
with hyperthreading, set it to 8, for about a 6x increase in compile speed.
(Note: you can't do this on vc7 (2003) because of shared pdb files).

While I think I have addressed most of the bugs reported, but I ran out of
time to do a comprehensive check of all reported bugs.
So at this time, I'm going to "wipe the slate clean", and discard
existing bug reports I have accumulated.  This means that if you
have a problem, you should re-report it.  I think try this mailing list
first, and if I do not report a quick fix, please log it in the haxe issue  
tracker:
http://code.google.com/p/haxe/issues/list
if it has not already been reported.

Initially, NME based applications may be slower due to the way I have
changed the CFFI interactions.  However, I hope to do a minor update
that will speed them up again - better than they were initially.

Hugh








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

Re: Hxcpp 2.05.0

Gamehaxe
One more thing I completely forgot:
* Added runtime properties for dynamics.  eg:

var d:Dynamic = new neash.display.Sprite();
d.x = 10;  // This will call the "setX" property

Hugh



> Hi,
> I have just released hxcpp 2.05.0, via haxelib.
> As you can seem I have changed the version numbers to match the
> haxe release - this should make it a bit clearer what version of
> hxcpp to use.
>
> In addition the great development that Nicolas has put into the 2.05  
> release,
> the hxcpp target comes with the additional changes:
>
> * Default to IMMIX based internal garbage collection.
> * Reorginised files - split big ones, and moved common ones out of  
> "runtime".
> * Put internal classes in "hx" namespace, or HX_ prefix for macros.
> * Remove multiple-inheritance, and use delegation instead.
> * Write "Options.txt" from compiler so dependency can be determined.
> * Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to avoid  
> overhead if not required.
> * Build thread code into executable for better control.
> * Fix return values of parseINt/parseFloat.
> * Added comprehensive list of reserved member names.
> * Put if/else statements in blocks.
> * Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
> * Added control over how fast-cffi routines are created by requiring  
> cpp.rtti.FastIntergerLookup to be "implemented".
> * Construct anonymous object fields in deterministic (as declared) order.
> * Fix code generation for some complex inline cases.
> * Added cpp.zip.Compress
> * Change "Reflect" class to be more standard
> * Use array of dynamics for StringBuf.
> * Fix setting of attributes in XML nodes.
>
> Build-tool:
> * Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N) for  
> faster building on multi-code boxes.
> * Added FileGroup dependencies
> * Added pre-compiled headers (windows only, at the moment since gcc  
> seems buggy)
>
>
>
> The first 2 points are the biggest, although if you "just use" the  
> target,
> it should not make much difference.
>
> By switching to the internal garbage collection, I was able to get modest
> performance increases, however I also gain much greater control over
> the source code.  For the end user, this means I will be able to offer
> much more help when the compiler fails, ie avoid errors with boehm_gc
> compile.
>
> I have also added pre-compiled headers.  However, there was a bug in gcc
> that made me disable it for that compiler.  Later version of gcc (>4.2 I  
> think)
> may have fixed this, so if you are interested, you may be able to get it  
> going.
>
> If you have a multi-core box, then you can speed up the compile time  
> significantly.
> Set the environment variable HXCPP_COMPILE_THREADS to the number of  
> processors you
> have - generally also count "hyper-threading cores".  So on a quad-core  
> box
> with hyperthreading, set it to 8, for about a 6x increase in compile  
> speed.
> (Note: you can't do this on vc7 (2003) because of shared pdb files).
>
> While I think I have addressed most of the bugs reported, but I ran out  
> of
> time to do a comprehensive check of all reported bugs.
> So at this time, I'm going to "wipe the slate clean", and discard
> existing bug reports I have accumulated.  This means that if you
> have a problem, you should re-report it.  I think try this mailing list
> first, and if I do not report a quick fix, please log it in the haxe  
> issue tracker:
> http://code.google.com/p/haxe/issues/list
> if it has not already been reported.
>
> Initially, NME based applications may be slower due to the way I have
> changed the CFFI interactions.  However, I hope to do a minor update
> that will speed them up again - better than they were initially.
>
> Hugh
>
>
>
>
>
>
>
>


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

Re: Hxcpp 2.05.0

David Bergman
Me impressed. You genius.

/David

On Jan 10, 2010, at 9:03 AM, Hugh Sanderson wrote:

> One more thing I completely forgot:
> * Added runtime properties for dynamics.  eg:
>
> var d:Dynamic = new neash.display.Sprite();
> d.x = 10;  // This will call the "setX" property
>
> Hugh
>
>
>
>> Hi,
>> I have just released hxcpp 2.05.0, via haxelib.
>> As you can seem I have changed the version numbers to match the
>> haxe release - this should make it a bit clearer what version of
>> hxcpp to use.
>>
>> In addition the great development that Nicolas has put into the 2.05 release,
>> the hxcpp target comes with the additional changes:
>>
>> * Default to IMMIX based internal garbage collection.
>> * Reorginised files - split big ones, and moved common ones out of "runtime".
>> * Put internal classes in "hx" namespace, or HX_ prefix for macros.
>> * Remove multiple-inheritance, and use delegation instead.
>> * Write "Options.txt" from compiler so dependency can be determined.
>> * Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to avoid overhead if not required.
>> * Build thread code into executable for better control.
>> * Fix return values of parseINt/parseFloat.
>> * Added comprehensive list of reserved member names.
>> * Put if/else statements in blocks.
>> * Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
>> * Added control over how fast-cffi routines are created by requiring cpp.rtti.FastIntergerLookup to be "implemented".
>> * Construct anonymous object fields in deterministic (as declared) order.
>> * Fix code generation for some complex inline cases.
>> * Added cpp.zip.Compress
>> * Change "Reflect" class to be more standard
>> * Use array of dynamics for StringBuf.
>> * Fix setting of attributes in XML nodes.
>>
>> Build-tool:
>> * Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N) for faster building on multi-code boxes.
>> * Added FileGroup dependencies
>> * Added pre-compiled headers (windows only, at the moment since gcc seems buggy)
>>
>>
>>
>> The first 2 points are the biggest, although if you "just use" the target,
>> it should not make much difference.
>>
>> By switching to the internal garbage collection, I was able to get modest
>> performance increases, however I also gain much greater control over
>> the source code.  For the end user, this means I will be able to offer
>> much more help when the compiler fails, ie avoid errors with boehm_gc
>> compile.
>>
>> I have also added pre-compiled headers.  However, there was a bug in gcc
>> that made me disable it for that compiler.  Later version of gcc (>4.2 I think)
>> may have fixed this, so if you are interested, you may be able to get it going.
>>
>> If you have a multi-core box, then you can speed up the compile time significantly.
>> Set the environment variable HXCPP_COMPILE_THREADS to the number of processors you
>> have - generally also count "hyper-threading cores".  So on a quad-core box
>> with hyperthreading, set it to 8, for about a 6x increase in compile speed.
>> (Note: you can't do this on vc7 (2003) because of shared pdb files).
>>
>> While I think I have addressed most of the bugs reported, but I ran out of
>> time to do a comprehensive check of all reported bugs.
>> So at this time, I'm going to "wipe the slate clean", and discard
>> existing bug reports I have accumulated.  This means that if you
>> have a problem, you should re-report it.  I think try this mailing list
>> first, and if I do not report a quick fix, please log it in the haxe issue tracker:
>> http://code.google.com/p/haxe/issues/list
>> if it has not already been reported.
>>
>> Initially, NME based applications may be slower due to the way I have
>> changed the CFFI interactions.  However, I hope to do a minor update
>> that will speed them up again - better than they were initially.
>>
>> Hugh
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> 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: Hxcpp 2.05.0

Heinz Hölzer-2
In reply to this post by Gamehaxe
great great work

is it correct that the env var is HXCPP_COMNPILE_THREAD
or should it be HXCPP_COMPILE_THREAD

cheers
heinz

Am 10.01.2010 14:59, schrieb Hugh Sanderson:

> Hi,
> I have just released hxcpp 2.05.0, via haxelib.
> As you can seem I have changed the version numbers to match the
> haxe release - this should make it a bit clearer what version of
> hxcpp to use.
>
> In addition the great development that Nicolas has put into the 2.05
> release,
> the hxcpp target comes with the additional changes:
>
> * Default to IMMIX based internal garbage collection.
> * Reorginised files - split big ones, and moved common ones out of
> "runtime".
> * Put internal classes in "hx" namespace, or HX_ prefix for macros.
> * Remove multiple-inheritance, and use delegation instead.
> * Write "Options.txt" from compiler so dependency can be determined.
> * Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to
> avoid overhead if not required.
> * Build thread code into executable for better control.
> * Fix return values of parseINt/parseFloat.
> * Added comprehensive list of reserved member names.
> * Put if/else statements in blocks.
> * Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
> * Added control over how fast-cffi routines are created by requiring
> cpp.rtti.FastIntergerLookup to be "implemented".
> * Construct anonymous object fields in deterministic (as declared) order.
> * Fix code generation for some complex inline cases.
> * Added cpp.zip.Compress
> * Change "Reflect" class to be more standard
> * Use array of dynamics for StringBuf.
> * Fix setting of attributes in XML nodes.
>
> Build-tool:
> * Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N)
> for faster building on multi-code boxes.
> * Added FileGroup dependencies
> * Added pre-compiled headers (windows only, at the moment since gcc
> seems buggy)
>
>
>
> The first 2 points are the biggest, although if you "just use" the
> target,
> it should not make much difference.
>
> By switching to the internal garbage collection, I was able to get modest
> performance increases, however I also gain much greater control over
> the source code.  For the end user, this means I will be able to offer
> much more help when the compiler fails, ie avoid errors with boehm_gc
> compile.
>
> I have also added pre-compiled headers.  However, there was a bug in gcc
> that made me disable it for that compiler.  Later version of gcc (>4.2
> I think)
> may have fixed this, so if you are interested, you may be able to get
> it going.
>
> If you have a multi-core box, then you can speed up the compile time
> significantly.
> Set the environment variable HXCPP_COMPILE_THREADS to the number of
> processors you
> have - generally also count "hyper-threading cores".  So on a
> quad-core box
> with hyperthreading, set it to 8, for about a 6x increase in compile
> speed.
> (Note: you can't do this on vc7 (2003) because of shared pdb files).
>
> While I think I have addressed most of the bugs reported, but I ran
> out of
> time to do a comprehensive check of all reported bugs.
> So at this time, I'm going to "wipe the slate clean", and discard
> existing bug reports I have accumulated.  This means that if you
> have a problem, you should re-report it.  I think try this mailing list
> first, and if I do not report a quick fix, please log it in the haxe
> issue tracker:
> http://code.google.com/p/haxe/issues/list
> if it has not already been reported.
>
> Initially, NME based applications may be slower due to the way I have
> changed the CFFI interactions.  However, I hope to do a minor update
> that will speed them up again - better than they were initially.
>
> Hugh
>
>
>
>
>
>
>
>


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

Re: Hxcpp 2.05.0

Heinz Hölzer-2
In reply to this post by Gamehaxe
after reading your post again it's clear that it was a misspelling ;)
it's HXCPP_COMPILE_THREADS

Am 10.01.2010 14:59, schrieb Hugh Sanderson:

> Hi,
> I have just released hxcpp 2.05.0, via haxelib.
> As you can seem I have changed the version numbers to match the
> haxe release - this should make it a bit clearer what version of
> hxcpp to use.
>
> In addition the great development that Nicolas has put into the 2.05
> release,
> the hxcpp target comes with the additional changes:
>
> * Default to IMMIX based internal garbage collection.
> * Reorginised files - split big ones, and moved common ones out of
> "runtime".
> * Put internal classes in "hx" namespace, or HX_ prefix for macros.
> * Remove multiple-inheritance, and use delegation instead.
> * Write "Options.txt" from compiler so dependency can be determined.
> * Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to
> avoid overhead if not required.
> * Build thread code into executable for better control.
> * Fix return values of parseINt/parseFloat.
> * Added comprehensive list of reserved member names.
> * Put if/else statements in blocks.
> * Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
> * Added control over how fast-cffi routines are created by requiring
> cpp.rtti.FastIntergerLookup to be "implemented".
> * Construct anonymous object fields in deterministic (as declared) order.
> * Fix code generation for some complex inline cases.
> * Added cpp.zip.Compress
> * Change "Reflect" class to be more standard
> * Use array of dynamics for StringBuf.
> * Fix setting of attributes in XML nodes.
>
> Build-tool:
> * Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N)
> for faster building on multi-code boxes.
> * Added FileGroup dependencies
> * Added pre-compiled headers (windows only, at the moment since gcc
> seems buggy)
>
>
>
> The first 2 points are the biggest, although if you "just use" the
> target,
> it should not make much difference.
>
> By switching to the internal garbage collection, I was able to get modest
> performance increases, however I also gain much greater control over
> the source code.  For the end user, this means I will be able to offer
> much more help when the compiler fails, ie avoid errors with boehm_gc
> compile.
>
> I have also added pre-compiled headers.  However, there was a bug in gcc
> that made me disable it for that compiler.  Later version of gcc (>4.2
> I think)
> may have fixed this, so if you are interested, you may be able to get
> it going.
>
> If you have a multi-core box, then you can speed up the compile time
> significantly.
> Set the environment variable HXCPP_COMPILE_THREADS to the number of
> processors you
> have - generally also count "hyper-threading cores".  So on a
> quad-core box
> with hyperthreading, set it to 8, for about a 6x increase in compile
> speed.
> (Note: you can't do this on vc7 (2003) because of shared pdb files).
>
> While I think I have addressed most of the bugs reported, but I ran
> out of
> time to do a comprehensive check of all reported bugs.
> So at this time, I'm going to "wipe the slate clean", and discard
> existing bug reports I have accumulated.  This means that if you
> have a problem, you should re-report it.  I think try this mailing list
> first, and if I do not report a quick fix, please log it in the haxe
> issue tracker:
> http://code.google.com/p/haxe/issues/list
> if it has not already been reported.
>
> Initially, NME based applications may be slower due to the way I have
> changed the CFFI interactions.  However, I hope to do a minor update
> that will speed them up again - better than they were initially.
>
> Hugh
>
>
>
>
>
>
>
>


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

Re: Hxcpp 2.05.0

Fei Yin
Cool  , But I still can't use it , I need the c/cpp standard library (dll or sod) support and database . for server development .

2010/1/10 Heinz Hölzer <[hidden email]>
after reading your post again it's clear that it was a misspelling ;)
it's HXCPP_COMPILE_THREADS


Am 10.01.2010 14:59, schrieb Hugh Sanderson:
Hi,

I have just released hxcpp 2.05.0, via haxelib.
As you can seem I have changed the version numbers to match the
haxe release - this should make it a bit clearer what version of
hxcpp to use.

In addition the great development that Nicolas has put into the 2.05 release,
the hxcpp target comes with the additional changes:

* Default to IMMIX based internal garbage collection.
* Reorginised files - split big ones, and moved common ones out of "runtime".
* Put internal classes in "hx" namespace, or HX_ prefix for macros.
* Remove multiple-inheritance, and use delegation instead.
* Write "Options.txt" from compiler so dependency can be determined.
* Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to avoid overhead if not required.
* Build thread code into executable for better control.
* Fix return values of parseINt/parseFloat.
* Added comprehensive list of reserved member names.
* Put if/else statements in blocks.
* Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
* Added control over how fast-cffi routines are created by requiring cpp.rtti.FastIntergerLookup to be "implemented".
* Construct anonymous object fields in deterministic (as declared) order.
* Fix code generation for some complex inline cases.
* Added cpp.zip.Compress
* Change "Reflect" class to be more standard
* Use array of dynamics for StringBuf.
* Fix setting of attributes in XML nodes.

Build-tool:
* Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N) for faster building on multi-code boxes.
* Added FileGroup dependencies
* Added pre-compiled headers (windows only, at the moment since gcc seems buggy)



The first 2 points are the biggest, although if you "just use" the target,
it should not make much difference.

By switching to the internal garbage collection, I was able to get modest
performance increases, however I also gain much greater control over
the source code.  For the end user, this means I will be able to offer
much more help when the compiler fails, ie avoid errors with boehm_gc
compile.

I have also added pre-compiled headers.  However, there was a bug in gcc
that made me disable it for that compiler.  Later version of gcc (>4.2 I think)
may have fixed this, so if you are interested, you may be able to get it going.

If you have a multi-core box, then you can speed up the compile time significantly.
Set the environment variable HXCPP_COMPILE_THREADS to the number of processors you
have - generally also count "hyper-threading cores".  So on a quad-core box
with hyperthreading, set it to 8, for about a 6x increase in compile speed.
(Note: you can't do this on vc7 (2003) because of shared pdb files).

While I think I have addressed most of the bugs reported, but I ran out of
time to do a comprehensive check of all reported bugs.
So at this time, I'm going to "wipe the slate clean", and discard
existing bug reports I have accumulated.  This means that if you
have a problem, you should re-report it.  I think try this mailing list
first, and if I do not report a quick fix, please log it in the haxe issue tracker:
http://code.google.com/p/haxe/issues/list
if it has not already been reported.

Initially, NME based applications may be slower due to the way I have
changed the CFFI interactions.  However, I hope to do a minor update
that will speed them up again - better than they were initially.

Hugh










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



--
Best regards

Yin Fei

From Icebirds.net

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

Re: Hxcpp 2.05.0

Cauê W.
In reply to this post by Heinz Hölzer-2
Thanks, Hugh!!! Great features added ! : )

2010/1/10 Heinz Hölzer <[hidden email]>
after reading your post again it's clear that it was a misspelling ;)
it's HXCPP_COMPILE_THREADS


Am 10.01.2010 14:59, schrieb Hugh Sanderson:
Hi,

I have just released hxcpp 2.05.0, via haxelib.
As you can seem I have changed the version numbers to match the
haxe release - this should make it a bit clearer what version of
hxcpp to use.

In addition the great development that Nicolas has put into the 2.05 release,
the hxcpp target comes with the additional changes:

* Default to IMMIX based internal garbage collection.
* Reorginised files - split big ones, and moved common ones out of "runtime".
* Put internal classes in "hx" namespace, or HX_ prefix for macros.
* Remove multiple-inheritance, and use delegation instead.
* Write "Options.txt" from compiler so dependency can be determined.
* Require -D HXCPP_MULTI_THREADED for multi-threaded classes - to avoid overhead if not required.
* Build thread code into executable for better control.
* Fix return values of parseINt/parseFloat.
* Added comprehensive list of reserved member names.
* Put if/else statements in blocks.
* Added assert, NULL, LITTLE_ENDIAN, BIG_ENDIAN as keywords.
* Added control over how fast-cffi routines are created by requiring cpp.rtti.FastIntergerLookup to be "implemented".
* Construct anonymous object fields in deterministic (as declared) order.
* Fix code generation for some complex inline cases.
* Added cpp.zip.Compress
* Change "Reflect" class to be more standard
* Use array of dynamics for StringBuf.
* Fix setting of attributes in XML nodes.

Build-tool:
* Allow multiple build threads (via setenv HXCPP_COMNPILE_THREADS N) for faster building on multi-code boxes.
* Added FileGroup dependencies
* Added pre-compiled headers (windows only, at the moment since gcc seems buggy)



The first 2 points are the biggest, although if you "just use" the target,
it should not make much difference.

By switching to the internal garbage collection, I was able to get modest
performance increases, however I also gain much greater control over
the source code.  For the end user, this means I will be able to offer
much more help when the compiler fails, ie avoid errors with boehm_gc
compile.

I have also added pre-compiled headers.  However, there was a bug in gcc
that made me disable it for that compiler.  Later version of gcc (>4.2 I think)
may have fixed this, so if you are interested, you may be able to get it going.

If you have a multi-core box, then you can speed up the compile time significantly.
Set the environment variable HXCPP_COMPILE_THREADS to the number of processors you
have - generally also count "hyper-threading cores".  So on a quad-core box
with hyperthreading, set it to 8, for about a 6x increase in compile speed.
(Note: you can't do this on vc7 (2003) because of shared pdb files).

While I think I have addressed most of the bugs reported, but I ran out of
time to do a comprehensive check of all reported bugs.
So at this time, I'm going to "wipe the slate clean", and discard
existing bug reports I have accumulated.  This means that if you
have a problem, you should re-report it.  I think try this mailing list
first, and if I do not report a quick fix, please log it in the haxe issue tracker:
http://code.google.com/p/haxe/issues/list
if it has not already been reported.

Initially, NME based applications may be slower due to the way I have
changed the CFFI interactions.  However, I hope to do a minor update
that will speed them up again - better than they were initially.

Hugh










--
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: Hxcpp 2.05.0

tong-2
In reply to this post by Gamehaxe
On Sun, 2010-01-10 at 21:59 +0800, Hugh Sanderson wrote:
> Hi,
> I have just released hxcpp 2.05.0, via haxelib.
> As you can seem I have changed the version numbers to match the
> haxe release - this should make it a bit clearer what version of
> hxcpp to use.

hi,
should we report issues to haXe's issue tracker or the hxcpp's one ?
thanks.tong


--
[)   |   5   |<   †   |2   3   3


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

Re: Hxcpp 2.05.0

Simon Richardson
sorry for jumping on the thread, but any idea why I would be getting this error?

xxxx:~ xxxx$ /Users/xxxx/Documents/workspace/haxe/haxecpp/bin/Haxecpp ;
exit;
Error : Could not load module nme@nme_filter_image__2
logout




Cheers
si

On 10 Jan 2010, at 16:45, tong wrote:

> On Sun, 2010-01-10 at 21:59 +0800, Hugh Sanderson wrote:
>> Hi,
>> I have just released hxcpp 2.05.0, via haxelib.
>> As you can seem I have changed the version numbers to match the
>> haxe release - this should make it a bit clearer what version of
>> hxcpp to use.
>
> hi,
> should we report issues to haXe's issue tracker or the hxcpp's one ?
> thanks.tong
>
> 
> --
> [)   |   5   |<   †   |2   3   3
>
>
> --
> haXe - an open source web programming language
> http://haxe.org

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

haxecpp.zip (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hxcpp 2.05.0

Simon Richardson
In reply to this post by tong-2
FYI: I tried this as well, to no avail!

http://gamehaxe.com/2009/04/07/hxcpp-nme-neash-released/#comment-329

On 10 Jan 2010, at 16:45, tong wrote:

> On Sun, 2010-01-10 at 21:59 +0800, Hugh Sanderson wrote:
>> Hi,
>> I have just released hxcpp 2.05.0, via haxelib.
>> As you can seem I have changed the version numbers to match the
>> haxe release - this should make it a bit clearer what version of
>> hxcpp to use.
>
> hi,
> should we report issues to haXe's issue tracker or the hxcpp's one ?
> thanks.tong
>
> 
> --
> [)   |   5   |<   †   |2   3   3
>
>
> --
> 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: Hxcpp 2.05.0

Gamehaxe
In reply to this post by Simon Richardson
Hi,
It looks like there is some binary incompatibility between your hxcpp exe  
and your NME dll.
What version of nme are you using (On mac I presume) ?
Did the HXCPP_LOAD_DEBUG show a failed attempt to load the correct library?
I will have another look at this tonight.

Hugh

> sorry for jumping on the thread, but any idea why I would be getting  
> this error?
>
> xxxx:~ xxxx$ /Users/xxxx/Documents/workspace/haxe/haxecpp/bin/Haxecpp ;
> exit;
> Error : Could not load module nme@nme_filter_image__2
> logout
>


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

Re: Hxcpp 2.05.0

Simon Richardson
If I set the HXCPP_LOAD_DEBUG, I get the following output:

Searching for nme...
 try nme.dylib...
 try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.dylib...
 try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.dylib...
 try nme.ndll...
 try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.ndll...
 try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.ndll...
Error : Could not load module nme@nme_filter_image__2

I'm running Mac OS X 10.6.2. I built using the following set up, http://haxe.org/doc/build/haxe_macosx_build and I can see that I'm on 2.05 haxe build. Everything is stored in /usr/local/haxe (previously I think it was /usr/lib/haxe, but the setup script is different than the installer script).

haxelib:
        hxcpp: [2.05.0]
        neash: 1.0.1 [1.0.2]
        nme: [1.0.1]

Cheers
si
 
On 11 Jan 2010, at 00:05, Hugh Sanderson wrote:

> Hi,
> It looks like there is some binary incompatibility between your hxcpp exe and your NME dll.
> What version of nme are you using (On mac I presume) ?
> Did the HXCPP_LOAD_DEBUG show a failed attempt to load the correct library?
> I will have another look at this tonight.
>
> Hugh
>
>> sorry for jumping on the thread, but any idea why I would be getting this error?
>>
>> xxxx:~ xxxx$ /Users/xxxx/Documents/workspace/haxe/haxecpp/bin/Haxecpp ;
>> exit;
>> Error : Could not load module nme@nme_filter_image__2
>> logout
>>
>
>
> --
> 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: Hxcpp 2.05.0

Gamehaxe
Hi,
Thanks, this is very useful.  Can you please confirm that the following  
file exists:

/usr/local/haxe/lib/nme/1,0,1/ndll/Mac/nme.ndll

If so, it can't be loaded for some reason - probably wrong architecture
or some dependency missing.
Could you also please send a copy of one of the compile-lines
generated when building your exe, eg:
gcc .......

If it contains the "-m32" switch, then I guess it must be a dependency.

Hugh



> If I set the HXCPP_LOAD_DEBUG, I get the following output:
>
> Searching for nme...
>  try nme.dylib...
>  try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.dylib...
>  try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.dylib...
>  try nme.ndll...
>  try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.ndll...
>  try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.ndll...
> Error : Could not load module nme@nme_filter_image__2
>
> I'm running Mac OS X 10.6.2. I built using the following set up,  
> http://haxe.org/doc/build/haxe_macosx_build and I can see that I'm on  
> 2.05 haxe build. Everything is stored in /usr/local/haxe (previously I  
> think it was /usr/lib/haxe, but the setup script is different than the  
> installer script).
>
> haxelib:
> hxcpp: [2.05.0]
> neash: 1.0.1 [1.0.2]
> nme: [1.0.1]
>
> Cheers
> si
> On 11 Jan 2010, at 00:05, Hugh Sanderson wrote:
>
>> Hi,
>> It looks like there is some binary incompatibility between your hxcpp  
>> exe and your NME dll.
>> What version of nme are you using (On mac I presume) ?
>> Did the HXCPP_LOAD_DEBUG show a failed attempt to load the correct  
>> library?
>> I will have another look at this tonight.
>>
>> Hugh
>>
>>> sorry for jumping on the thread, but any idea why I would be getting  
>>> this error?
>>>
>>> xxxx:~ xxxx$ /Users/xxxx/Documents/workspace/haxe/haxecpp/bin/Haxecpp ;
>>> exit;
>>> Error : Could not load module nme@nme_filter_image__2
>>> logout
>>>
>>
>>
>> --
>> 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: Hxcpp 2.05.0

Simon Richardson
Here is the compile log:

http://pastebin.com/m43071864

cheers for looking into this
Si

On 11 Jan 2010, at 10:14, Hugh Sanderson wrote:

> Hi,
> Thanks, this is very useful.  Can you please confirm that the following file exists:
>
> /usr/local/haxe/lib/nme/1,0,1/ndll/Mac/nme.ndll
>
> If so, it can't be loaded for some reason - probably wrong architecture
> or some dependency missing.
> Could you also please send a copy of one of the compile-lines
> generated when building your exe, eg:
> gcc .......
>
> If it contains the "-m32" switch, then I guess it must be a dependency.
>
> Hugh
>
>
>
>> If I set the HXCPP_LOAD_DEBUG, I get the following output:
>>
>> Searching for nme...
>> try nme.dylib...
>> try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.dylib...
>> try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.dylib...
>> try nme.ndll...
>> try /usr/local/haxe/lib/hxcpp/2,05,0//bin/Mac/nme.ndll...
>> try /usr/local/haxe/lib/nme/1,0,1//ndll/Mac/nme.ndll...
>> Error : Could not load module nme@nme_filter_image__2
>>
>> I'm running Mac OS X 10.6.2. I built using the following set up, http://haxe.org/doc/build/haxe_macosx_build and I can see that I'm on 2.05 haxe build. Everything is stored in /usr/local/haxe (previously I think it was /usr/lib/haxe, but the setup script is different than the installer script).
>>
>> haxelib:
>> hxcpp: [2.05.0]
>> neash: 1.0.1 [1.0.2]
>> nme: [1.0.1]
>>
>> Cheers
>> si
>> On 11 Jan 2010, at 00:05, Hugh Sanderson wrote:
>>
>>> Hi,
>>> It looks like there is some binary incompatibility between your hxcpp exe and your NME dll.
>>> What version of nme are you using (On mac I presume) ?
>>> Did the HXCPP_LOAD_DEBUG show a failed attempt to load the correct library?
>>> I will have another look at this tonight.
>>>
>>> Hugh
>>>
>>>> sorry for jumping on the thread, but any idea why I would be getting this error?
>>>>
>>>> xxxx:~ xxxx$ /Users/xxxx/Documents/workspace/haxe/haxecpp/bin/Haxecpp ;
>>>> exit;
>>>> Error : Could not load module nme@nme_filter_image__2
>>>> logout
>>>>
>>>
>>>
>>> --
>>> 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


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

Re: Hxcpp 2.05.0

Gamehaxe
In reply to this post by tong-2
Not sure what the best answer is.
Let's say report errors in hxcpp for now - easier for me to filter.

http://code.google.com/p/hxcpp/issues/list

Hugh

> On Sun, 2010-01-10 at 21:59 +0800, Hugh Sanderson wrote:
>> Hi,
>> I have just released hxcpp 2.05.0, via haxelib.
>> As you can seem I have changed the version numbers to match the
>> haxe release - this should make it a bit clearer what version of
>> hxcpp to use.
>
> hi,
> should we report issues to haXe's issue tracker or the hxcpp's one ?
> thanks.tong
>
> 


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