From kukkerman at gmail.com Thu Nov 19 12:55:31 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Thu, 19 Nov 2009 13:55:31 +0100 Subject: [SamHaXe] 64bit arch compilation issues Message-ID: Hi! There were problems compiling SamHaXe under some 64bit archs. The error message was something similar: Called from neko/Main.nml line 144 Called from core/Args.nml line 50 Called from neko/Main.nml line 58 Called from neko/Main.nml line 47 Called from neko/Binast.nml line 141 Called from neko/Binast.nml line 44 Called from neko/Binast.nml line 44 Called from neko/Binast.nml line 44 .... Called from neko/Binast.nml line 44 Called from neko/Binast.nml line 43 Called from neko/Binast.nml line 182 Called from neko/Binast.nml line 143 Called from neko/Binast.nml line 182 Called from neko/Binast.nml line 137 Called from neko/Binast.nml line 55 Called from core/IO.nml line 233 Exception : Overflow(read_i32) Error : Neko compilation failure Further investigation showed that the problem might not be a neko compiler issue after all but a big constant value in the source of hxformat's SamHaXe branch. Please update hxformat to rev. 63 (external SVN dependency under lib/hxformat) and recompile SamHaXe. I've not been able to reproduce this error on our machine so every feedback is welcome. Cheers, Gabe From joacim at splashdust.net Sun Nov 22 00:14:43 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sun, 22 Nov 2009 01:14:43 +0100 Subject: [SamHaXe] Snow Leopard? Message-ID: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> Hello list, I'm trying to compile SamHaXe on OS X 10.6. The problem I'm having appears to be that libneko is 32bit and Ant is trying to compile SamHaXe as 64bit. So the libneko linking fails. Is there any way to force Ant to compile for a 32bit target? I've googled this, but without any luck... Thanks /J From viktor.hesselbom at gmail.com Mon Nov 23 13:05:22 2009 From: viktor.hesselbom at gmail.com (Viktor Hesselbom) Date: Mon, 23 Nov 2009 14:05:22 +0100 Subject: [SamHaXe] Donating? Message-ID: Hello people behind SamHaXe. I just started using SamHaXe after having many odd bugs with swfmill that I couldn't resolve and so far SamHaXe has worked perfectly! I had one small problem migrating that I couldn't at first understand what was wrong. It didn't work with flash.Lib.attach in haXe with images. I got an error saying I couldn't convert to MovieClip. I then realized that the images were in fact stored as Bitmaps and not MovieClips, like in swfmill. Small problem but I got it to work by redefining the flash.Lib.attach method for bitmaps. public static function attach (name : String) : Sprite { var cl = untyped __as__(__global__["flash.utils.getDefinitionByName"](name), Class); var obj : Dynamic = untyped __new__(cl); var spr = new Sprite (); try { // Cast to bitmap var tbit : Bitmap = obj; tbit.smoothing = true; spr.addChild (tbit); } catch (e : Dynamic) { // If that didn't work, simply cast to sprite var tbit : Sprite = obj; spr.addChild (tbit); } return spr; } Anyway, that wasn't really the point of this post, just thought I'd share that bit for anyone having similar problems. Because SamHaXe has saved me a lot of effort and headaches from swfmill I'd like to donate some money to show support for your work. But I couldn't find a "Donate" button anywhere on your site. Maybe that could be something to think about. ;) Cheers, Viktor Hesselbom -------------- next part -------------- An HTML attachment was scrubbed... URL: From kukkerman at gmail.com Mon Nov 23 22:28:28 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Mon, 23 Nov 2009 23:28:28 +0100 Subject: [SamHaXe] New features in r17 Message-ID: Hi! There're some new features in SamHaxe r17 worth mentioning: - Image loading with DevIL library. DevIL is much easier to use and install than ImageMagcik especially under windows and properly identifies if an image has alpha channel or not. I'm sure this can be done with ImageMagick too but I was unable to find out from its documentation. - New option for external library import (swf:library): symbols=true/false. The default is false with wipes out every ID -> Class mappings from imported library. This is especially useful for some flex generated libraries which include a weird character ID mapping. The flash player will refuse to play our resulting swf with this mapping in it (with haxe's -swf-lib for example). - There're also some bugfixes in hxformat library. Cheers, Gabe From ron at mindless-labs.com Tue Nov 24 10:29:28 2009 From: ron at mindless-labs.com (Robin Palotai) Date: Tue, 24 Nov 2009 11:29:28 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> Message-ID: <4B0BB588.1090108@mindless-labs.com> Hi! I compiled neko for 64bit. Here are my notes how I did it: Haxe (this is not needed but included for completeness): - emerge ocaml (18:10) - wget http://haxe.org/file/install.ml - emerge cvs (18:25) - ocaml install.ml (18:28) - puzzled about haxe linking to libz.so.1 (18:30) - tries symlinking /usr/lib64/libz.so to /usr/lib64/libz.so.1 - found out that /usr/lib/libz.so.1 points to /usr/lib64/libz.so - after googling: emerge emul-linux-x86-baselibs Neko: - emerge -av boehm-gc (18:42) - wget http://nekovm.org/_media/neko-1.8.1.tar.gz?id=download&cache=cache, untar - make (18:47) - skipped a few apache1 libs - Compiling mysql, gcc complains: gcc -shared -L../../bin -pthread -lneko -L/home/ron/install_haxe/neko-1.8.1/src -L/usr/lib -L/usr/lib/mysql -L/usr/local/lib -L/usr/local/lib/mysql -L/opt/local/lib -L/opt/local/lib/mysql -o ../../bin/mysql.ndll -lz -lssl mysql.o /usr/lib/mysql/libmysqlclient_r.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/mysql/libmysqlclient_r.a(libmysql.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/mysql/libmysqlclient_r.a: could not read symbols: Bad value - decided I don't need mysql (mysql5 is fine), commented out from src/tools/install.neko script - finished building, make install, ldconfig - neko test.n works.. let's try to compile somethig w/Haxe. It works (19:15) Haxelib: - had to recompile haxe/std/tools/haxelib/haxelib.hxml using haxe to create an x64 haxelib Best regards, Robin Joacim Magnusson ?rta: > Hello list, > > I'm trying to compile SamHaXe on OS X 10.6. The problem I'm having appears to be that libneko is 32bit and Ant is trying to compile SamHaXe as 64bit. So the libneko linking fails. > Is there any way to force Ant to compile for a 32bit target? I've googled this, but without any luck... > > Thanks > /J > _______________________________________________ > Sam HaXe - the friendly asset > From joacim at splashdust.net Wed Nov 25 21:18:15 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Wed, 25 Nov 2009 22:18:15 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: <4B0BB588.1090108@mindless-labs.com> References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> Message-ID: Thanks for those notes, Robin! I've now sucessfully built SamHaXe, but I can't get it to load its modules properly. There were't any trouble compiling other than some warnings about stuff that is deprecated in ImageMagick... Whenever I try to compile some resources I get "Error loading module 'Image'". So I tried $ SamHaXe --module-help Image and it returns this: Called from line 1 Called from SamHaXe.hx line 698 Called from SamHaXe.hx line 112 Called from a C function Called from SamHaXe.hx line 260 Called from Config.hx line 133 Called from SamHaXeModule.hx line 43 Called from a C function Called from SamHaXeModule.hx line 136 Uncaught exception - Error loading module 'Image' Same thing with any of the other modules I've tried with the --module-help option. Also, if i do $ neko Image.n I get this: Called from line 1 Called from Image.hx line 463 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports I've created a samhaxe.conf.xml file in /etc which has the correct path to the modules. Any ideas what might have gone wrong? Thanks /J On 24 nov 2009, at 11:29, Robin Palotai wrote: > Hi! > > I compiled neko for 64bit. Here are my notes how I did it: > > Haxe (this is not needed but included for completeness): > - emerge ocaml (18:10) > - wget http://haxe.org/file/install.ml > - emerge cvs (18:25) > - ocaml install.ml (18:28) > - puzzled about haxe linking to libz.so.1 (18:30) > - tries symlinking /usr/lib64/libz.so to /usr/lib64/libz.so.1 > - found out that /usr/lib/libz.so.1 points to /usr/lib64/libz.so > - after googling: emerge emul-linux-x86-baselibs > > Neko: > - emerge -av boehm-gc (18:42) > - wget http://nekovm.org/_media/neko-1.8.1.tar.gz?id=download&cache=cache, untar > - make (18:47) > - skipped a few apache1 libs > - Compiling mysql, gcc complains: > gcc -shared -L../../bin -pthread -lneko -L/home/ron/install_haxe/neko-1.8.1/src -L/usr/lib -L/usr/lib/mysql -L/usr/local/lib -L/usr/local/lib/mysql -L/opt/local/lib -L/opt/local/lib/mysql -o ../../bin/mysql.ndll -lz -lssl mysql.o /usr/lib/mysql/libmysqlclient_r.a > /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/mysql/libmysqlclient_r.a(libmysql.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC > /usr/lib/mysql/libmysqlclient_r.a: could not read symbols: Bad value > - decided I don't need mysql (mysql5 is fine), commented out from src/tools/install.neko script > - finished building, make install, ldconfig > - neko test.n works.. let's try to compile somethig w/Haxe. It works (19:15) > > Haxelib: > - had to recompile haxe/std/tools/haxelib/haxelib.hxml using haxe to create an x64 haxelib > > Best regards, > Robin > > Joacim Magnusson ?rta: >> Hello list, >> >> I'm trying to compile SamHaXe on OS X 10.6. The problem I'm having appears to be that libneko is 32bit and Ant is trying to compile SamHaXe as 64bit. So the libneko linking fails. >> Is there any way to force Ant to compile for a 32bit target? I've googled this, but without any luck... >> >> Thanks >> /J >> _______________________________________________ >> Sam HaXe - the friendly asset >> > > _______________________________________________ > Sam HaXe - the friendly asset From kukkerman at gmail.com Wed Nov 25 21:53:47 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Wed, 25 Nov 2009 22:53:47 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> Message-ID: Hi! > Whenever I try to compile some resources I get "Error loading module 'Image'". > > So I tried > $ SamHaXe --module-help Image > and it returns this: > > Called from line 1 > Called from SamHaXe.hx line 698 > Called from SamHaXe.hx line 112 > Called from a C function > Called from SamHaXe.hx line 260 > Called from Config.hx line 133 > Called from SamHaXeModule.hx line 43 > Called from a C function > Called from SamHaXeModule.hx line 136 > Uncaught exception - Error loading module 'Image' Looks like neko can't find the Image module. Make sure SamHaXe is using the correct config file: specify it in the command line with -c . Are there any "weird" characters in the path? Neko doesn't handle any encoding other than ASCII As a last resort move Image.n (and the other modules as well) into the directory of SamHaXe binary. Neko should find them this way. Gabe From joacim at splashdust.net Wed Nov 25 22:51:09 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Wed, 25 Nov 2009 23:51:09 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> Message-ID: Hi! Thanks for you suggestion. I tried it, but unfortunately it didn't work. It seems like neko does load the modules, but something goes wrong it tries to construct them. I commented out the try...catch code in SamHaXeModule.hx where it catches the load error. From the resulting stacktrace it appears that the line "lm.setExport(SamHaXeModule.INTERFACES, interface_versions);" causes the error. $ ./SamHaXe -c samhaxe.conf.xml --module-help Image === Module Help === Called from line 1 Called from SamHaXe.hx line 698 Called from SamHaXe.hx line 112 Called from a C function Called from SamHaXe.hx line 260 Called from Config.hx line 133 Called from SamHaXeModule.hx line 43 Called from a C function Called from SamHaXeModule.hx line 134 Called from neko/vm/Loader.hx line 132 Called from line 1 Called from Image.hx line 463 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports Next I created a haxe class with this content class Testneko { static function main() : Void { var lm = neko.vm.Module.local(); lm.setExport("interfaces", ["1.0.0"]); } } just to verify the issue. It gives the same stacktrace Called from line 1 Called from Testneko.hx line 6 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports So from this I would assume that I have some kind of problem with my Neko environment (I just compiled it for 64bit, so it might have something to do with that...). I'm not at all familiar with the Neko VM, so any pointers would be awesome! Thanks /J On 25 nov 2009, at 22:53, G?bor Szuromi wrote: > Hi! > >> Whenever I try to compile some resources I get "Error loading module 'Image'". >> >> So I tried >> $ SamHaXe --module-help Image >> and it returns this: >> >> Called from line 1 >> Called from SamHaXe.hx line 698 >> Called from SamHaXe.hx line 112 >> Called from a C function >> Called from SamHaXe.hx line 260 >> Called from Config.hx line 133 >> Called from SamHaXeModule.hx line 43 >> Called from a C function >> Called from SamHaXeModule.hx line 136 >> Uncaught exception - Error loading module 'Image' > > Looks like neko can't find the Image module. Make sure SamHaXe is > using the correct config file: specify it in the command line with -c > . Are there any "weird" characters in the > path? Neko doesn't handle any encoding other than ASCII As a last > resort move Image.n (and the other modules as well) into the directory > of SamHaXe binary. Neko should find them this way. > > Gabe > _______________________________________________ > Sam HaXe - the friendly asset -------------- next part -------------- An HTML attachment was scrubbed... URL: From kukkerman at gmail.com Thu Nov 26 10:13:40 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Thu, 26 Nov 2009 11:13:40 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> Message-ID: Hi! > $ ./SamHaXe -c samhaxe.conf.xml --module-help Image > === Module Help === > Called from line 1 > Called from SamHaXe.hx line 698 > Called from SamHaXe.hx line 112 > Called from a C function > Called from SamHaXe.hx line 260 > Called from Config.hx line 133 > Called from SamHaXeModule.hx line 43 > Called from a C function > Called from SamHaXeModule.hx line 134 > Called from neko/vm/Loader.hx line 132 > Called from line 1 > Called from Image.hx line 463 > Called from neko/vm/Module.hx line 130 > Uncaught exception - std at module_exports Well this is very strange because the exception comes from the neko builtin function module_exports which throws it when it's argument is not a module handle. I've attached a small test which creates a neko module tries to load it and list it's exports. Compile it with 'haxe build.hxml' and then run 'neko Main.n' and with 'neko -interp Main.n' The second method doesn't use JIT which is know to be buggy on 64bits. If everything goes well this small test just lists the exports of TestModule.n. If not then please specify your haxe/neko version, architecture, etc. and I'll post this issue on haxe mailing list. Good luck, Gabe -------------- next part -------------- A non-text attachment was scrubbed... Name: module_test.tar.gz Type: application/x-gzip Size: 438 bytes Desc: not available URL: From Joacim at splashdust.net Thu Nov 26 11:49:26 2009 From: Joacim at splashdust.net (Joacim Magnusson) Date: Thu, 26 Nov 2009 12:49:26 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> Message-ID: <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> Thank you for the test file Gabe. I ran the commands and they both returns the same thing: $ neko Main.n Called from line 1 Called from Main.hx line 4 Called from neko/vm/Loader.hx line 132 Called from line 1 Called from TestModule.hx line 7 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports $ neko -interp Main.n Called from line 1 Called from Main.hx line 4 Called from neko/vm/Loader.hx line 132 Called from line 1 Called from TestModule.hx line 7 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports Strange! I'm running OS X 10.6.2 (Darwin kernel 10.2.0 x86_64) NekoVM 1.8.1 This is how Neko was compiled: make MACOSX=1 skip mod_neko skip mod_tora skip mysql I used version 7.1 of the boehm gc. HaXe is 2.04 /J On 26 nov 2009, at 11:13, G?bor Szuromi wrote: > Hi! > >> $ ./SamHaXe -c samhaxe.conf.xml --module-help Image >> === Module Help === >> Called from line 1 >> Called from SamHaXe.hx line 698 >> Called from SamHaXe.hx line 112 >> Called from a C function >> Called from SamHaXe.hx line 260 >> Called from Config.hx line 133 >> Called from SamHaXeModule.hx line 43 >> Called from a C function >> Called from SamHaXeModule.hx line 134 >> Called from neko/vm/Loader.hx line 132 >> Called from line 1 >> Called from Image.hx line 463 >> Called from neko/vm/Module.hx line 130 >> Uncaught exception - std at module_exports > > Well this is very strange because the exception comes from the neko > builtin function module_exports which throws it when it's argument is > not a module handle. I've attached a small test which creates a neko > module tries to load it and list it's exports. Compile it with 'haxe > build.hxml' and then run 'neko Main.n' and with 'neko -interp Main.n' > The second method doesn't use JIT which is know to be buggy on 64bits. > If everything goes well this small test just lists the exports of > TestModule.n. If not then please specify your haxe/neko version, > architecture, etc. and I'll post this issue on haxe mailing list. > > Good luck, > Gabe > _______________________________________________ > Sam HaXe - the friendly asset -------------- next part -------------- An HTML attachment was scrubbed... URL: From kukkerman at gmail.com Fri Nov 27 09:52:44 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Fri, 27 Nov 2009 10:52:44 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> Message-ID: Hi! I've forwarded your bugreport to the haXe compiler list. Nicolas (the author of haXe and neko) requested some more information about this issue: > Seems strange, works on Windows. > > Could you tell me what is the value of the neko_kind_module and what is the type + kind of the > passed value ? > > Nicolas So please try the following: Open up 'libs/std/module.c' in neko sources and find this function: static value module_exports( value mv ) (should be around line 169) Change the function to this: static value module_exports( value mv ) { neko_module *m; printf("--- module_exports ---\n neko_kind_module: %p\n mv type: %d\n mv value: %p\n------\n\n", neko_kind_module, val_type(mv), val_kind(mv) ); val_check_kind(mv,neko_kind_module); m = (neko_module*)val_data(mv); return m->exports; } Recompile neko and run the test case I've sent you earlier. This should produce more info about what's really going on. Good luck! Regards, Gabe From joacim at splashdust.net Sat Nov 28 15:28:09 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sat, 28 Nov 2009 16:28:09 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> Message-ID: <09F8FE9C-5177-469B-AD2C-7A872415E1E8@splashdust.net> Hi! I modified module.c, recompiled and ran the test case. This is the results: $ neko -interp Main.n --- module_exports --- neko_kind_module: 0x0 mv type: 7 mv value: 0x100016558 ------ Called from line 1 Called from Main.hx line 4 Called from neko/vm/Loader.hx line 132 Called from line 1 Called from TestModule.hx line 7 Called from neko/vm/Module.hx line 130 Uncaught exception - std at module_exports /J On 27 nov 2009, at 10:52, G?bor Szuromi wrote: > Hi! > > I've forwarded your bugreport to the haXe compiler list. Nicolas (the > author of haXe and neko) requested some more information about this > issue: > > >> Seems strange, works on Windows. >> >> Could you tell me what is the value of the neko_kind_module and what is the type + kind of the > passed value ? >> >> Nicolas > > So please try the following: > > Open up 'libs/std/module.c' in neko sources and find this function: > static value module_exports( value mv ) (should be around line 169) > > Change the function to this: > static value module_exports( value mv ) { > neko_module *m; > printf("--- module_exports ---\n neko_kind_module: %p\n mv type: > %d\n mv value: %p\n------\n\n", > neko_kind_module, > val_type(mv), > val_kind(mv) > ); > val_check_kind(mv,neko_kind_module); > m = (neko_module*)val_data(mv); > return m->exports; > } > > Recompile neko and run the test case I've sent you earlier. This > should produce more info about what's really going on. > > Good luck! > > Regards, > Gabe > _______________________________________________ > Sam HaXe - the friendly asset -------------- next part -------------- An HTML attachment was scrubbed... URL: From joacim at splashdust.net Sun Nov 29 17:27:28 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sun, 29 Nov 2009 18:27:28 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: <09F8FE9C-5177-469B-AD2C-7A872415E1E8@splashdust.net> References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> <09F8FE9C-5177-469B-AD2C-7A872415E1E8@splashdust.net> Message-ID: <936A5883-6D59-4996-9C0C-9213364A57FD@splashdust.net> I saw Nicolas last response on the HaXe mailing list, so I compiled neko from CVS and got it working! So thanks a lot for the help Gabe! Now that I got SamHaXe working, I've summarized the steps I took on my blog: http://www.splashdust.net/2009/11/samhaxe-snow-leopard/ Might be useful to anyone else running in to these problems with Snow Leopard. /J On 28 nov 2009, at 16:28, Joacim Magnusson wrote: > Hi! > > I modified module.c, recompiled and ran the test case. This is the results: > > $ neko -interp Main.n > --- module_exports --- > neko_kind_module: 0x0 > mv type: 7 > mv value: 0x100016558 > ------ > > Called from line 1 > Called from Main.hx line 4 > Called from neko/vm/Loader.hx line 132 > Called from line 1 > Called from TestModule.hx line 7 > Called from neko/vm/Module.hx line 130 > Uncaught exception - std at module_exports > > /J > > On 27 nov 2009, at 10:52, G?bor Szuromi wrote: > >> Hi! >> >> I've forwarded your bugreport to the haXe compiler list. Nicolas (the >> author of haXe and neko) requested some more information about this >> issue: >> >> >>> Seems strange, works on Windows. >>> >>> Could you tell me what is the value of the neko_kind_module and what is the type + kind of the > passed value ? >>> >>> Nicolas >> >> So please try the following: >> >> Open up 'libs/std/module.c' in neko sources and find this function: >> static value module_exports( value mv ) (should be around line 169) >> >> Change the function to this: >> static value module_exports( value mv ) { >> neko_module *m; >> printf("--- module_exports ---\n neko_kind_module: %p\n mv type: >> %d\n mv value: %p\n------\n\n", >> neko_kind_module, >> val_type(mv), >> val_kind(mv) >> ); >> val_check_kind(mv,neko_kind_module); >> m = (neko_module*)val_data(mv); >> return m->exports; >> } >> >> Recompile neko and run the test case I've sent you earlier. This >> should produce more info about what's really going on. >> >> Good luck! >> >> Regards, >> Gabe >> _______________________________________________ >> Sam HaXe - the friendly asset > > _______________________________________________ > Sam HaXe - the friendly asset -------------- next part -------------- An HTML attachment was scrubbed... URL: From joacim at splashdust.net Sun Nov 29 20:02:20 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sun, 29 Nov 2009 21:02:20 +0100 Subject: [SamHaXe] New issue with image.ndll Message-ID: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> Hi! I just compiled SamHaXe from a fresh SVN checkout, and there is a new problem with the image module: $ samhaxe --module-help Image === Module Help === Called from line 1 Called from SamHaXe.hx line 698 Called from SamHaXe.hx line 112 Called from a C function Called from SamHaXe.hx line 265 Called from Config.hx line 177 Called from SamHaXeModule.hx line 238 Called from Image.hx line 447 Called from neko/Lib.hx line 33 Uncaught exception - load.c(352) : Primitive not found : image at init(0) This seem to originate from image.ndll, because if I replace it with the old image.ndll (checked out about a week ago) it works. None of the other modules are affected. /J -------------- next part -------------- An HTML attachment was scrubbed... URL: From kukkerman at gmail.com Sun Nov 29 21:48:09 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Sun, 29 Nov 2009 22:48:09 +0100 Subject: [SamHaXe] New issue with image.ndll In-Reply-To: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> References: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> Message-ID: Hi! > I just compiled SamHaXe from a fresh SVN checkout, and there is a new > problem with the image module: > $ samhaxe --module-help Image > === Module Help === > Called from line 1 > Called from SamHaXe.hx line 698 > Called from SamHaXe.hx line 112 > Called from a C function > Called from SamHaXe.hx line 265 > Called from Config.hx line 177 > Called from SamHaXeModule.hx line 238 > Called from Image.hx line 447 > Called from neko/Lib.hx line 33 > Uncaught exception - load.c(352) : Primitive not found : image at init(0) > This seem to originate from image.ndll, because if I replace it with the old > image.ndll (checked out about a week ago) it works. None of the other > modules are affected. Well, this is strange because the native image module hasn't changed for ages. We've added support for DevIL besides ImageMagick in revision 17 and image.cpp has been renamed image-imagemagick.cpp but that's all. Can you tell me exactly which revision is working for you and which is not? Maybe it has to do something with the new neko... Gabe From kukkerman at gmail.com Sun Nov 29 21:52:21 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Sun, 29 Nov 2009 22:52:21 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: <936A5883-6D59-4996-9C0C-9213364A57FD@splashdust.net> References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> <09F8FE9C-5177-469B-AD2C-7A872415E1E8@splashdust.net> <936A5883-6D59-4996-9C0C-9213364A57FD@splashdust.net> Message-ID: Hi! On Sun, Nov 29, 2009 at 6:27 PM, Joacim Magnusson wrote: > I saw Nicolas last response on the HaXe mailing list, so I compiled neko > from CVS and got it working! > So thanks a lot for the help Gabe! > Now that I got SamHaXe working, I've summarized the steps I took on my > blog:?http://www.splashdust.net/2009/11/samhaxe-snow-leopard/ > Might be useful to anyone else running in to these problems with Snow > Leopard. > /J I see it wasn't an easy procedure so this information is very useful. I've noticed that you had to modify build.xml: "Open build.xml and change image.dylib to libimage.dylib on line 238 and font.dylib to libfont.dylib on line 317" So the shared libraries should be named libsomething.dylib? I'm not familiar with OSX at all so if that's the case I'll modify build.xml in the repository. Gabe From joacim at splashdust.net Sun Nov 29 22:49:59 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sun, 29 Nov 2009 23:49:59 +0100 Subject: [SamHaXe] Snow Leopard? In-Reply-To: References: <438D53C6-7F84-4E23-8B89-58179A05BFBC@splashdust.net> <4B0BB588.1090108@mindless-labs.com> <157A5CDB-5AB6-47AD-AB79-415B0C759E2A@splashdust.net> <09F8FE9C-5177-469B-AD2C-7A872415E1E8@splashdust.net> <936A5883-6D59-4996-9C0C-9213364A57FD@splashdust.net> Message-ID: <7FB1190D-6234-4627-B29F-F1EF31AAC3D6@splashdust.net> Most shared libraries has the lib prefix, but not all of them so I don't think it is enforced. The reason I changed that in the build.xml file was that I got this compiler warning otherwise: [move] Warning: Could not find file /Users/joacim/Documents/samhaxe/trunk/obj/libimage.dylib to copy From what I understand, SamHaXe would compile fine for earlier versions of OS X. in that case this may be specific to 10.6. I have an other Mac with 10.5 on it, so I will check if the same thing occurs there and get back to you. /J On 29 nov 2009, at 22:52, G?bor Szuromi wrote: > Hi! > > On Sun, Nov 29, 2009 at 6:27 PM, Joacim Magnusson wrote: >> I saw Nicolas last response on the HaXe mailing list, so I compiled neko >> from CVS and got it working! >> So thanks a lot for the help Gabe! >> Now that I got SamHaXe working, I've summarized the steps I took on my >> blog: http://www.splashdust.net/2009/11/samhaxe-snow-leopard/ >> Might be useful to anyone else running in to these problems with Snow >> Leopard. >> /J > > I see it wasn't an easy procedure so this information is very useful. > I've noticed that you had to modify build.xml: "Open build.xml and > change image.dylib to libimage.dylib on line 238 and font.dylib to > libfont.dylib on line 317" So the shared libraries should be named > libsomething.dylib? I'm not familiar with OSX at all so if that's the > case I'll modify build.xml in the repository. > > Gabe > _______________________________________________ > Sam HaXe - the friendly asset -------------- next part -------------- An HTML attachment was scrubbed... URL: From joacim at splashdust.net Sun Nov 29 22:56:40 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Sun, 29 Nov 2009 23:56:40 +0100 Subject: [SamHaXe] New issue with image.ndll In-Reply-To: References: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> Message-ID: I don't remember what the revision number was when I checked out the working one. Is there a way to see this in the sources? All I know is that i checked it out at 21 Nov 15:28. /J On 29 nov 2009, at 22:48, G?bor Szuromi wrote: > Hi! > >> I just compiled SamHaXe from a fresh SVN checkout, and there is a new >> problem with the image module: >> $ samhaxe --module-help Image >> === Module Help === >> Called from line 1 >> Called from SamHaXe.hx line 698 >> Called from SamHaXe.hx line 112 >> Called from a C function >> Called from SamHaXe.hx line 265 >> Called from Config.hx line 177 >> Called from SamHaXeModule.hx line 238 >> Called from Image.hx line 447 >> Called from neko/Lib.hx line 33 >> Uncaught exception - load.c(352) : Primitive not found : image at init(0) >> This seem to originate from image.ndll, because if I replace it with the old >> image.ndll (checked out about a week ago) it works. None of the other >> modules are affected. > > Well, this is strange because the native image module hasn't changed > for ages. We've added support for DevIL besides ImageMagick in > revision 17 and image.cpp has been renamed image-imagemagick.cpp but > that's all. Can you tell me exactly which revision is working for you > and which is not? Maybe it has to do something with the new neko... > > Gabe > _______________________________________________ > Sam HaXe - the friendly asset From kukkerman at gmail.com Mon Nov 30 09:16:32 2009 From: kukkerman at gmail.com (=?ISO-8859-1?Q?G=E1bor_Szuromi?=) Date: Mon, 30 Nov 2009 10:16:32 +0100 Subject: [SamHaXe] New issue with image.ndll In-Reply-To: References: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> Message-ID: Hi! > I don't remember what the revision number was when I checked out the working one. Is there a way to see this in the sources? > All I know is that i checked it out at 21 Nov 15:28. You can look at the revision log here: http://trac.mindless-labs.com/samhaxe/log/ Revision 17 was committed at 23 Nov 21:41 so probably you're using revision 16. In r17 image.cpp has been renamed to image-imagemagick.cpp and build.xml has been modified accordingly (maybe it should be modified based on your recent findings about image.dylib -> libimage.dylib) You can look at the changes between r16 and r17 here: http://trac.mindless-labs.com/samhaxe/changeset?new=17%40%2F&old=16%40%2F Please try to check out r16 and see if it works. I think ant just doesn't copy the new image module because its name has changed. Gabe From joacim at splashdust.net Mon Nov 30 18:58:07 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Mon, 30 Nov 2009 19:58:07 +0100 Subject: [SamHaXe] New issue with image.ndll In-Reply-To: References: <8B01F5D5-90CB-4D5C-81AE-4037D16156DE@splashdust.net> Message-ID: You're right! It was because of the new name of image-imagemagick. After changing to libimage-imagemagick.dylib in build.xml, r17 works! I haven't been able to test this on the older OS X version yet, because apparently its java version is too old... I'll see if can get around that as soon as I have some time to spare. /J On 30 nov 2009, at 10:16, G?bor Szuromi wrote: > Hi! > >> I don't remember what the revision number was when I checked out the working one. Is there a way to see this in the sources? >> All I know is that i checked it out at 21 Nov 15:28. > > You can look at the revision log here: > http://trac.mindless-labs.com/samhaxe/log/ > Revision 17 was committed at 23 Nov 21:41 so probably you're using > revision 16. In r17 image.cpp has been renamed to > image-imagemagick.cpp and build.xml has been modified accordingly > (maybe it should be modified based on your recent findings about > image.dylib -> libimage.dylib) > You can look at the changes between r16 and r17 here: > http://trac.mindless-labs.com/samhaxe/changeset?new=17%40%2F&old=16%40%2F > Please try to check out r16 and see if it works. I think ant just > doesn't copy the new image module because its name has changed. > > Gabe > _______________________________________________ > Sam HaXe - the friendly asset From joacim at splashdust.net Mon Nov 30 22:52:20 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Mon, 30 Nov 2009 23:52:20 +0100 Subject: [SamHaXe] Importing multiple SWF Message-ID: Hi! Are there any known issues with importing multiple SWFs in SamHaXe? I have this in my resource descriptor file: The asset swf compiles fine, and it will open in flash player with an empty white window as it should. But when I try import it into my HaXe project using -swf-lib, I get this: Error : The input swf res/resources.swf is corrupted and --gen-hx-classes gives me this: File "../../mtcvs/swflib/swfParser.ml", line 1327, characters 18-24: Assertion failed If I comment out any of the two import lines and recompile the asset with just a single swf, it will work. I suppose this might have something to do with the fact that I'm using a 64-bit Neko... I tried the -interp option, but it made no difference. /J -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at mindless-labs.com Mon Nov 30 23:13:58 2009 From: ron at mindless-labs.com (Robin Palotai) Date: Tue, 01 Dec 2009 00:13:58 +0100 Subject: [SamHaXe] Importing multiple SWF In-Reply-To: References: Message-ID: <4B1451B6.2040901@mindless-labs.com> Hi! Not necessary a neko64 problem. Swf import is in kind of an experimental stage as it is the most complex type of import. Could you please upload a test scenario (resource xml, assets, and the haxe command failing) somewhere (or mail directly to Gabe and me)? We will take a peak on it and see if there's anything to fix. Thanks a lot for your investigations! Robin Joacim Magnusson ?rta: > Hi! > > Are there any known issues with importing multiple SWFs in SamHaXe? > > I have this in my resource descriptor file: > > xmlns:shx="http://mindless-labs.com/samhaxe" > xmlns:swf="http://mindless-labs.com/samhaxe/modules/Swf"> > > > > > > > > > The asset swf compiles fine, and it will open in flash player with an > empty white window as it should. > But when I try import it into my HaXe project using -swf-lib, I get this: > Error : The input swf res/resources.swf is corrupted > and --gen-hx-classes gives me this: > File "../../mtcvs/swflib/swfParser.ml", line 1327, characters 18-24: > Assertion failed > > If I comment out any of the two import lines and recompile the asset > with just a single swf, it will work. > > I suppose this might have something to do with the fact that I'm using > a 64-bit Neko... I tried the -interp option, but it made no difference. > > /J > ------------------------------------------------------------------------ > > _______________________________________________ > Sam HaXe - the friendly asset From joacim at splashdust.net Mon Nov 30 23:30:25 2009 From: joacim at splashdust.net (Joacim Magnusson) Date: Tue, 1 Dec 2009 00:30:25 +0100 Subject: [SamHaXe] Importing multiple SWF In-Reply-To: <4B1451B6.2040901@mindless-labs.com> References: <4B1451B6.2040901@mindless-labs.com> Message-ID: Allright, here's a simple test case of importing 2 swfs that will produce the error on my system. -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase.zip Type: application/zip Size: 19724 bytes Desc: not available URL: -------------- next part -------------- /J On 1 dec 2009, at 00:13, Robin Palotai wrote: > Hi! > > Not necessary a neko64 problem. Swf import is in kind of an experimental stage as it is the most complex type of import. > Could you please upload a test scenario (resource xml, assets, and the haxe command failing) somewhere (or mail directly to Gabe and me)? We will take a peak on it and see if there's anything to fix. > > Thanks a lot for your investigations! > Robin > > Joacim Magnusson ?rta: >> Hi! >> >> Are there any known issues with importing multiple SWFs in SamHaXe? >> >> I have this in my resource descriptor file: >> >> > xmlns:shx="http://mindless-labs.com/samhaxe" >> xmlns:swf="http://mindless-labs.com/samhaxe/modules/Swf"> >> >> >> >> >> >> >> >> The asset swf compiles fine, and it will open in flash player with an empty white window as it should. >> But when I try import it into my HaXe project using -swf-lib, I get this: >> Error : The input swf res/resources.swf is corrupted >> and --gen-hx-classes gives me this: >> File "../../mtcvs/swflib/swfParser.ml", line 1327, characters 18-24: Assertion failed >> >> If I comment out any of the two import lines and recompile the asset with just a single swf, it will work. >> >> I suppose this might have something to do with the fact that I'm using a 64-bit Neko... I tried the -interp option, but it made no difference. >> >> /J >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sam HaXe - the friendly asset > > _______________________________________________ > Sam HaXe - the friendly asset