#jogamp @ irc.freenode.net - 20131117 15:25:53 (UTC)

20131117 15:25:53 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20131117140032.html
20131117 15:25:53 -NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
20131117 15:25:59 * jogamp (~jogamp@anon) has joined #jogamp
20131117 15:25:59 * Topic is 'http://jogamp.org | Hacking 3D Graphics, Multimedia and Processing across Devices'
20131117 15:25:59 * Set by rmk0 on 20130116 23:58:04
20131117 15:25:59 -NickServ- You are now identified for jogamp.
20131117 15:26:41 <sgothel> @Mark (back from a nap) - you only try to use JAWT if considered available .. (classes found .. headless property not set .. etc)
20131117 15:26:51 <sgothel> *we*
20131117 15:27:06 <rmk0> hm
20131117 15:27:30 <sgothel> pls backtrace that method and double check
20131117 15:27:32 <rmk0> well i mean, i'm not doing anything special here... is the absolute bare minimum hello world that just calls GLProfile.getDefault()
20131117 15:27:43 <rmk0> am waiting for the main ceylon developer to get back to me
20131117 15:27:59 <rmk0> is possible they do something unusual with the native libraries
20131117 15:28:01 <sgothel> -Djava.awt.headless=true
20131117 15:29:23 <rmk0> moves the error to "Caused by: java.lang.UnsatisfiedLinkError: jogamp.nativewindow.x11.X11Util.initialize0(Z)Z" instead
20131117 15:29:31 <rmk0> like i said... i'll wait until they get back to me
20131117 15:29:41 <rmk0> otherwise i'm just blundering around in the dark
20131117 15:32:51 <sgothel> Hi Johan
20131117 15:32:57 <sgothel> oh
20131117 15:35:49 * Eclesia johanN (with 2N for me)
20131117 15:36:24 * hija (~hija@anon) Quit (Quit: hija)
20131117 15:36:54 <Eclesia> rmk0: you are named johan too ?
20131117 15:37:01 <rmk0> nope
20131117 15:37:07 <rmk0> i could be, if it'd help
20131117 15:37:34 <rmk0> we could all be called johan, to reduce confusion
20131117 15:37:39 <Eclesia> lol
20131117 15:37:53 <Eclesia> that's my real name, so it won't bother me :D
20131117 15:46:33 <Eclesia> finally fixed all the problems i had with multisampling.
20131117 15:46:35 <Eclesia> http://unlicense.developpez.com/temp/edit3d.jpeg
20131117 15:46:59 <Eclesia> can render font at normal size and still be readable :)
20131117 15:47:07 <rmk0> nice
20131117 15:49:49 <sgothel> how do you do font rendering ? render curves to texture ?
20131117 15:50:11 <sgothel> jogl way (old/new) .. or own ttf .. and graphics
20131117 15:50:58 <Eclesia> parse ttf > map unicode char to glyph > build geometry > flatten curves at a given resolution > triangulate > vbo > shader > multisample image
20131117 15:51:46 <sgothel> if you like to join our graph .. .. since we duplicate most of the world in our both worlds :)
20131117 15:52:01 <sgothel> tried GPU curve rendering ?
20131117 15:52:04 <Eclesia> aside from GL4, GLProfil, GLCapabilities and GLFactory I don't use anything else from jogl
20131117 15:52:44 <sgothel> yes, it's a pitty
20131117 15:53:16 <Eclesia> you already know why ^^
20131117 15:55:15 <sgothel> but later about all of that .. finishing a few more bugs (sure you do use more JOGL stuff .. surface/drawable/context platform logic) .. is it NEWT
20131117 15:55:15 <sgothel> I know your position, but I don't know why :)
20131117 15:55:15 <sgothel> (BSD vs PD here .. but we go into the infight after 2.1.3 -> i.e. how to share stuff best)
20131117 15:55:15 <Eclesia> had a bad experience when moving a project from LGPL to apache license
20131117 15:55:15 <Eclesia> and other stuffs about oracle,google common apis
20131117 15:55:22 <sgothel> well - I do understand that! :)
20131117 15:55:38 <sgothel> I quit my job b/c of it once
20131117 15:56:35 <sgothel> I can ensure you - our usage of BSD is in no way restricting anybody here .. just a min. legal 'allowance' but, hey - later more. me like to finish on 2.1.3 - sorry!
20131117 15:57:11 <Eclesia> sure, later, I have to finish linear gradiant paint on my side :)
20131117 16:00:02 <sgothel> in the meantime, if somebody else here knows about how to setup a 'dual license' for a set of files/packages (PD + our BSD) and make it 'binding/legal' - this could solve issues w/ upcoming sharing w/o the need of fruitless and endless discussions :)
20131117 16:00:51 <sgothel> ^^ not a problem for the PD part, but maybe for our BSD part - dunno
20131117 16:39:33 <Eclesia> question : I have declared in a shader :
20131117 16:39:43 <Eclesia> uniform float[10] GSTEPS;
20131117 16:39:43 <Eclesia> uniform vec4[10] GCOLORS;
20131117 16:40:14 <Eclesia> is it possible to push all values in a single call?
20131117 16:42:06 <sgothel> dunno from memory .. AFAIK you can add a 'count' value. otherwise .. use a struct, maybe w/ the annotation and GL 'layout/alignment' (I have added something to gluegen .. experimental .. need to test it one day )
20131117 16:43:20 <sgothel> all jogamp modules are clang clean now (OSX + X11) - fixed glibc symver issue ..
20131117 16:46:43 <sgothel> feels like a DOS .. @ jogamp.org .. hmm
20131117 16:59:41 <sgothel> cpu low / net-if low
20131117 16:59:59 <sgothel> jenkins/apache restarted
20131117 17:01:22 <Eclesia> added my link ?
20131117 17:01:49 <Eclesia> ^^
20131117 17:05:45 <sgothel> No Johan, adding your link didn't lead to this issue (not added yet, PR stuff come when 2.1.3 issues are done, focus on technical stuff now)
20131117 17:06:15 <sgothel> JohanN
20131117 17:06:16 <sgothel> :)
20131117 17:53:04 <sgothel> http://www.hetzner-status.de/en.html <- yup .. DDOS or something
20131117 17:53:50 <sgothel> 60 Gbit/s attack .. :)
20131117 17:54:24 <sgothel> all those a**h*le*
20131117 17:55:01 <sgothel> we had ~100GB/month so far
20131117 18:25:40 <Eclesia> gradiant paint working :) http://unlicense.developpez.com/temp/gradiant.jpeg
20131117 19:13:03 * hija (~hija@anon) has joined #jogamp
20131117 19:14:02 <sgothel> Hi Hija .. how is the SWT stuff going ? This week I like to finish 2.1.3 .. I may find time to validate/help towards end of the week.
20131117 19:17:19 * Eclesia (~eclesia@anon) has left #jogamp
20131117 19:19:31 <hija> hi sven
20131117 19:20:24 <hija> my fix breaks at linux ...
20131117 19:20:39 <sgothel> I remember you mentioned it ..
20131117 19:20:53 <hija> so I either add flags or I take a look at SWT source
20131117 19:20:54 <sgothel> have you added information to the bug reports ? which one was it ? sorry, my memory ..
20131117 19:21:46 <sgothel> sure you can branch for X11/Windows/.. etc .. using NativeWindowFactory .. WindowingType
20131117 19:22:08 <hija> bug 672
20131117 19:22:36 <sgothel> Pls add your branch and findings there ..
20131117 19:23:11 <sgothel> and put it on 'in progress' .. I am sure we can fix it this week .. maybe even time for other SWT issues
20131117 19:24:51 <sgothel> https://jogamp.org/bugzilla/showdependencytree.cgi?id=674&hide_resolved=0
20131117 19:24:53 <hija> ok i'll add the flags, and more info over at the bug report page
20131117 19:24:54 <hija> https://jogamp.org/bugzilla/show_bug.cgi?id=672
20131117 19:25:00 <sgothel> thank you
20131117 19:25:27 <sgothel> ^^ all SWT issues in a dependency tree
20131117 19:36:52 <hija> btw what do you think about this? http://stackoverflow.com/questions/19649634/clang-error-unsupported-option-static-libgcc-on-mac-osx-mavericks
20131117 19:37:12 <hija> because I removed that option for building
20131117 19:37:39 <sgothel> AFAIK we have enabled it if 'isGCC' only
20131117 19:38:06 <sgothel> I am a bit unsure about the clang equivalent of statically 'clang-lib' linkage ..
20131117 19:38:40 <sgothel> <linkerarg value="-static-libgcc" if="isGCC"/>
20131117 19:39:12 <hija> yes but it seems that for osx clang qualifies as gcc
20131117 19:39:24 <hija> it passes that if and throws an error as reported
20131117 19:39:50 <sgothel> clang is tested on OSX (xcode/clang or commandline clang) and Linux
20131117 19:40:32 <sgothel> for our modules: gluegen/make/lib/gluegen-clang.properties gluegen/make/lib/gluegen-xcode_clang.properties
20131117 19:40:52 <hija> its only for mavericks btw
20131117 19:40:57 <hija> (the latest version)
20131117 19:40:58 <sgothel> i.e. define gcc.compat.compiler
20131117 19:41:09 <sgothel> clang or xcode.clang
20131117 19:41:19 <sgothel> probably the link cc -> clang
20131117 19:41:23 <sgothel> *they*
20131117 19:41:33 <sgothel> we build w/ xcode.clang on OSX now
20131117 19:41:42 <sgothel> (default in our jenkins node)
20131117 19:42:17 <sgothel> we may need to make it default in general by gluegen .. etc for OSX
20131117 19:43:35 <hija> dunno, this is a bit too much into c compiling for me :D
20131117 19:43:35 <sgothel> wow .. they dare to: gcc -> clang
20131117 19:43:38 <sgothel> ugly
20131117 19:44:18 <sgothel> good point .. xcode.clang should be default now for jogamp .. thx for the hint
20131117 19:45:28 <hija> :D
20131117 19:49:23 <hija> so it appears that although it does not break windows, my fix adds nothing to that version
20131117 19:49:29 <hija> so its only an osx flag
20131117 19:52:03 <sgothel> hence add it only to OSX .. use Platform or NativeWindowFactory (type)
20131117 19:56:10 <hija> this specific class already contains it...
20131117 19:56:18 <sgothel> ah :)
20131117 19:56:20 <hija> private static final boolean isOSX = NativeWindowFactory.TYPE_MACOSX == NativeWindowFactory.getNativeWindowType(false);
20131117 19:57:40 <hija> actually this boolean is there to fix the windowing...
20131117 19:58:32 <hija> maybe thats the culprit?
20131117 19:58:42 <hija> i'll build without that
20131117 19:59:58 <hija> meh
20131117 19:59:59 <hija> clang: error: unsupported option '-static-libgcc'
20131117 20:00:30 <sgothel> pls use the property as I mentioned above ..
20131117 20:00:52 <sgothel> a 'fresh' git pull might be also a nice thing to do ..
20131117 20:02:51 <sgothel> NewtCanvasSWT's getLocationOnScreen() seems to be broken .. i.e. !isOSX is a NOP
20131117 20:03:23 <hija> it is?
20131117 20:03:30 <sgothel> ah .. it's from the inner SWTNativeWindow ..
20131117 20:03:33 <sgothel> memories ..
20131117 20:04:13 <sgothel> inner getLocationOnScreen() is used w/ NEWT's OSX impl. which fetches the parent LOS
20131117 20:04:38 <sgothel> since OSX requires us to use the LOS .. (ugly ugly)
20131117 20:04:58 <sgothel> so it should be OK'ish .. hmm maybe it helps
20131117 20:05:29 <sgothel> -> NEWT's OSX WindowDriver impl .. calls getLocationOnScreen() of this inner NativeWindow impl.
20131117 20:05:30 <hija> well yeah but when you add the canvas to a sash (which is not at 0,0 of the window) the offset is not applied
20131117 20:06:05 <sgothel> sorry .. what is a 'sash' ?
20131117 20:06:29 <hija> its a combination of composites that allow fast resizing
20131117 20:06:36 <hija> SashForm
20131117 20:06:37 <sgothel> can you add a unit test ?
20131117 20:06:49 <sgothel> (copy one using NewtCanvasSWT .. etc etc)
20131117 20:06:57 <hija> the bug is about that actually
20131117 20:07:02 <sgothel> :)
20131117 20:07:37 <sgothel> the getLOS() returns the actual position on screen .. but needs to add it's SWT parent's or something ?
20131117 20:07:47 <hija> yeap
20131117 20:07:55 <hija> exactly
20131117 20:07:59 <sgothel> well.. I am sure you know better .. at least you know the rational begind this getLOS() .. :)
20131117 20:08:15 <sgothel> so you cannot just 'remove' it .. it's for NEWT parenting itself
20131117 20:08:51 <hija> I don't really understand how is this possible though since the whole NewtSwtCanvas is
20131117 20:08:53 <sgothel> if you can add a test case .. and you fix .. (OSX only branch) .. I will also test ..
20131117 20:09:01 <hija> an extension of the swt canvas
20131117 20:09:17 * hharrison (~chatzilla@anon) has joined #jogamp
20131117 20:09:21 <sgothel> NEWT parenting ?
20131117 20:09:47 <hija> no...
20131117 20:09:47 <sgothel> NewtCanvasSWT _is_ NEWT parenting itself :)
20131117 20:09:50 <sgothel> oh
20131117 20:10:00 <hija> it is an extension of SWT Canvas yes?
20131117 20:10:16 <hija> extends Canvas
20131117 20:10:17 <sgothel> NewtCanvasSWT extends Canvas .. <- yes :)
20131117 20:10:39 <hija> the SWT canvas does not need these fixes...
20131117 20:11:01 <hija> it should have been able to position itsself
20131117 20:11:07 <sgothel> but _we_ need to have a NativeWindow representation .. hence SWTNativeWindow
20131117 20:11:12 <hija> unless newt positions itsself according to the window...
20131117 20:11:36 <sgothel> yes .. NEWT operates on normal native things .. like OSX NSView ..
20131117 20:11:43 <sgothel> so it's the binding to such
20131117 20:11:54 <hija> so it doesnt take into account the swt parents...
20131117 20:12:00 <sgothel> nope
20131117 20:12:07 <sgothel> the getLOS() shall do it ..
20131117 20:12:07 <hija> well now it makes sense :P
20131117 20:12:23 <sgothel> i.e. location on screen .. which seems to be wrong here
20131117 20:12:44 <hija> yeah
20131117 20:13:13 <sgothel> /jogl/src/newt/classes/jogamp/newt/driver/macosx/WindowDriver.java -> line 353 !
20131117 20:13:36 <sgothel> translates the LOS .. using parent ..
20131117 20:13:51 <sgothel> parent's LOS here is our SWTNativeWindow's ..
20131117 20:14:05 <hija> the parent... but maybe the super is more proper?
20131117 20:14:08 <sgothel> same in line 376 WindowDriver ..
20131117 20:14:27 <sgothel> must be solved in SWTNativeWindow's getLOS()
20131117 20:14:32 <hija> (because the swt canvas properly positions its self)
20131117 20:14:39 <sgothel> maybe ..
20131117 20:14:57 <sgothel> I have to admit .. I hacked NEwtCanvasSWT as a proof of concept
20131117 20:15:04 <hija> :D
20131117 20:15:23 <sgothel> hence the big open bug tree for SWT things .. I mentioned it :)
20131117 20:15:32 <hija> hehehe
20131117 20:15:45 <sgothel> however . . the getLOS() impl shows how it should work .. in theory, w/ native methods
20131117 20:16:16 <sgothel> looks like here the native position as retrieved is not correct .. and this 'sash' is somewhat a lightweight component ?
20131117 20:16:56 <hija> how can I tell whether its a lightweight component? :P
20131117 20:16:58 <sgothel> if you can make it work for OSX w/ 'normal' SWT UI .. and your sash .. great ..
20131117 20:17:23 <hija> its not my component..
20131117 20:17:37 <hija> http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fcustom%2FSashForm.html
20131117 20:17:49 <sgothel> see .. thats where I don't want to deal w/ SWT anymore :) .. I stopped at the level of retrieving the native handles .. and adding some components for integration
20131117 20:17:52 <sgothel> hehe :)
20131117 20:18:07 <sgothel> sorry .. I was making a bit fun .. sure, it's not your personal component type
20131117 20:18:19 <hija> :P
20131117 20:18:50 <hija> so I can hack away and plug the holes :P
20131117 20:18:52 <sgothel> if you can validate that the SWT's own getLOS() is valid .. or it's super .. or whatever alternative path .. works - go for it!
20131117 20:19:02 <sgothel> yes!
20131117 20:19:15 <sgothel> THANK YOU in the name of the many unknown or known SWT users :)
20131117 20:19:44 <hija> hehehe
20131117 20:19:45 <sgothel> we can bring you onto our Wiki maintainer page .. so you can be sure to always be busy :)
20131117 20:20:23 <sgothel> send me an email to give you write access to our wiki
20131117 20:20:24 <hharrison> Old code never dies....it just shows up in weirder and weirder places
20131117 20:20:37 <sgothel> hehe
20131117 20:20:52 <hharrison> That's what Java3d has taught me
20131117 20:20:57 <sgothel> one day .. maybe even I see JOGL in Eclipse :)
20131117 20:21:32 <sgothel> yup .. many people have a strong interest in it ..
20131117 20:21:37 <sgothel> oh while we are so many here ..
20131117 20:21:45 <hija> email email... I guess I can retrieve that online somewhere
20131117 20:21:51 <hija> gotta put my bots to look
20131117 20:22:06 <sgothel> sgothel at jausoft dot com
20131117 20:22:12 <hija> :D
20131117 20:22:26 <sgothel> the offscreen drawable 'uninitialize' behavior .. currently it's err uninitialized :)
20131117 20:22:47 <sgothel> so many complained about noise .. and weird content before they start to draw ..
20131117 20:23:11 <sgothel> since I don't like to add operations which slow down things .. I kept it this way .. hmm
20131117 20:23:56 <sgothel> we could add 'blanking' in higher level components, like GLJPanel .. or for OSX's FBO usage w/ CALAyer ..
20131117 20:24:19 <sgothel> again - I dont' really care .. opinions ?
20131117 20:24:42 <rmk0> i'd quite like to be able to blank an AWT GLCanvas before drawing starts
20131117 20:24:56 <rmk0> it looks a bit crap on windows, as you can see through it to the desktop
20131117 20:25:05 <sgothel> haha :)
20131117 20:25:05 <rmk0> extremely low priority... it's there for barely a second
20131117 20:25:16 <sgothel> a whole second ?
20131117 20:25:22 <rmk0> a whole second!
20131117 20:25:24 <sgothel> wow
20131117 20:25:38 <sgothel> windows + glcanvas .. thats is funky .. since it's no FBO
20131117 20:25:51 <sgothel> a transparent GL object ?
20131117 20:26:01 <sgothel> scratching head ..
20131117 20:26:25 <sgothel> will add a bug entry .. so maybe you all can add your comments .. and maybe test cases
20131117 20:26:52 <rmk0> should be easy to get a test case together
20131117 20:27:03 <rmk0> this is just a JFrame, a menu bar, and a GLCanvas
20131117 20:27:32 <sgothel> so the AWT-EDT roundtrip .. takes quite a while :)
20131117 20:32:41 <sgothel> ok .. dinner / bed - hmm seems like Animator stop() w/ AWT-EDT rendering loves to fail waiting until stopped .. plus NEWT focus traversal changes are not good for OSX / Java7 (CALayer/AWT-event-translation) .. https://jogamp.org/chuck/job/jogl/1149/testReport/
20131117 20:32:51 <sgothel> laters .. and good night
20131117 20:33:49 <rmk0> byeee!
20131117 20:38:54 <hharrison> damn, was hoping those focus bit would be a slam-dunk
20131117 20:47:44 <rmk0> d'oh... think the issue was actually that my init() was holding up rendering
20131117 21:12:05 * kermyt (~kermyt@anon) Quit (Ping timeout: 245 seconds)
20131117 21:15:28 * kermyt (~kermyt@anon) has joined #jogamp
20131117 22:07:29 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131117 22:26:18 * hharrison (~chatzilla@anon) Quit (Ping timeout: 246 seconds)
20131118 00:05:00 * kermyt (~kermyt@anon) Quit (Ping timeout: 245 seconds)
20131118 00:08:49 * kermyt (~kermyt@anon) has joined #jogamp
20131118 00:41:47 * hija (~hija@anon) Quit (Quit: hija)
20131118 00:47:53 * rmk0 (~rmk0@anon) Quit (Quit: Lost terminal)
20131118 00:48:23 * hija (~hija@anon) has joined #jogamp
20131118 00:50:02 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 00:50:02 * rmk0 (~rmk0@anon) Quit (Changing host)
20131118 00:50:02 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 01:36:38 * hija (~hija@anon) Quit (Quit: hija)
20131118 01:47:05 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20131118 01:51:24 * xranby (~xranby@anon) has joined #jogamp
20131118 02:02:54 * hija (~hija@anon) has joined #jogamp
20131118 02:18:28 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131118 02:23:39 * xranby (~xranby@anon) has joined #jogamp
20131118 02:25:43 * [Mike] (~Mike]@anon) has joined #jogamp
20131118 05:35:44 * dita (~dhityyata@anon) has joined #jogamp
20131118 05:35:51 <dita> anda bermasalah dengan kartu kredit/KTA?? Kami bantu dibebas bayarkan hub. Dita 02190409949
20131118 05:47:24 * dita (~dhityyata@anon) Quit (Killed (idoru (Spam is off topic on freenode.)))
20131118 06:24:18 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131118 06:34:21 * xranby (~xranby@anon) has joined #jogamp
20131118 06:35:46 * hharrison (~chatzilla@anon) has joined #jogamp
20131118 07:46:03 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131030081700])
20131118 08:17:43 * eclesia (~husky@anon) has joined #jogamp
20131118 08:17:48 <eclesia> morning
20131118 08:30:28 * monsieur_max (~maxime@anon) has joined #jogamp
20131118 08:47:32 * hija (~hija@anon) Quit (Quit: hija)
20131118 08:56:18 * xranby1 (~xranby@anon) has joined #jogamp
20131118 08:56:32 * xranby (~xranby@anon) Quit (Read error: Connection reset by peer)
20131118 09:16:28 * [Mike] (~Mike]@anon) Quit ()
20131118 09:39:46 * hija (~hija@anon) has joined #jogamp
20131118 09:46:07 <bbbruce> sgothel: some jogl in the wild: http://www.domusweb.it/en/news/2013/11/13/lust_type_dynamics_.html
20131118 11:48:37 * trigger (~trigger@anon) has joined #jogamp
20131118 12:01:54 <trigger> is there any information on porting "normal" jogl apps to android?
20131118 12:06:06 <monsieur_max> define normal
20131118 12:06:18 <monsieur_max> desktop ?
20131118 12:10:50 <trigger> yes jogl desktop applications :)
20131118 12:11:35 <monsieur_max> trigger: mmmh i'll have to do it one day or another, but i guess you'll have to rely on examples or test classes
20131118 12:12:09 <sgothel> Brice and teams of DoW .. See Ticket to Ride (game) .. and ofc C3D Mobile -> see last slides / video of siggraph!
20131118 12:12:36 <sgothel> @Brice .. could you validate 2.1.3 RC for ES3.0 devices ?
20131118 12:13:09 <trigger> monsieur_max: thx a lot i will check that
20131118 12:15:55 <monsieur_max> trigger: masterzen can maybe provide a bit of info on this topic
20131118 12:18:11 <trigger> monsieur_max: ah ok, gonna try it myself first and maybe write a blog entry on how to do it
20131118 12:18:36 <monsieur_max> trigger: great :) i would totally be interested
20131118 12:18:43 <masterzen> sgothel: yes, I'm going to do that this afternoon
20131118 12:19:28 <masterzen> trigger: well, it was harder than we first thought. But that was mostly an issue with Android than jogl itself
20131118 12:20:05 <masterzen> like you can't have more than 65k methods in your program :)
20131118 12:20:59 <trigger> but you guys found a workaround?
20131118 12:21:45 <trigger> wellto be honest i dont even earn an adroind phone myself.. my gf has one .. so i was thinking about porting my java apps to GLES and test them on her cellular
20131118 12:22:54 <sgothel> haha .. before risking your GF to get impatient you may consider to get one yourself :) - Well, the emulators work ok these days .. (in Android SDK)
20131118 12:23:47 <trigger> sgothel: dont have the money right now.. looking for a job
20131118 12:23:55 <masterzen> trigger: proguard is mandatory
20131118 12:24:26 <masterzen> trigger: and the other gotcha was to port our fixed func based implementation to GLES2 to get descent performances
20131118 12:25:36 <trigger> masterzen:ah ok for gl profiels < 3.0 ?
20131118 12:25:40 <masterzen> trigger: then memory optimizations everywhere we could - dalvik is like the jvm we had 10 years ago, it doesn't really like allocations if you want to be fast. We also offloaded some things to the be native for more performances (sound decoding and so on)
20131118 12:26:25 <masterzen> trigger: as long as you're code runs on GLES2 you should be fine
20131118 12:26:55 <trigger> the 56k constrsaint ist not a problem anymore for developers that just use jogl?
20131118 12:27:34 <monsieur_max> masterzen: did you test your game on ART ?
20131118 12:27:59 <masterzen> trigger: it
20131118 12:28:01 <masterzen> oops
20131118 12:28:25 <masterzen> trigger: it's still an issue as jogl consumes a lot of method that you won't probably never call, like all the ones in GL4 :)
20131118 12:28:33 <masterzen> monsieur_max: ART?
20131118 12:29:07 <monsieur_max> masterzen: new runtime replacing dalvik on the new android ( optionnal )
20131118 12:29:33 <masterzen> monsieur_max: hmm, I wasn't aware of that, do you have any pointers or docs?
20131118 12:29:46 <trigger> cool, never heared about proguard before but sounds great :)
20131118 12:29:56 <sgothel> I have tested ART on new NExus 5(?) .. was working well
20131118 12:30:04 <monsieur_max> masterzen: well, i was about to google for it
20131118 12:30:32 <trigger> have to switch os, ttyl
20131118 12:30:40 <monsieur_max> trigger: yup proguard is pretty good
20131118 12:30:56 * trigger (~trigger@anon) Quit (Quit: Ex-Chat)
20131118 12:31:26 <monsieur_max> masterzen: https://source.android.com/devices/tech/dalvik/art.html
20131118 12:31:44 <monsieur_max> you can find a bit more technical posts around
20131118 12:32:06 <monsieur_max> but basically, it's a new runtime, so you may expect some issues, or not
20131118 12:32:19 <masterzen> monsieur_max: thanks, I'll have a loog
20131118 12:32:22 <masterzen> *look
20131118 12:32:50 <monsieur_max> masterzen: would be interesting to know how things went for you :)
20131118 12:33:25 <sgothel> (01:29:56 PM) sgothel: I have tested ART on new NExus 5(?) .. was working well <- our many JOGL test activities ..
20131118 12:34:05 <monsieur_max> sgothel: ha ok :) that was the part i was asking myself
20131118 12:34:28 <monsieur_max> that's a good news
20131118 12:49:36 <rmk0> ... a 65k method limit?!
20131118 12:50:56 <rmk0> that's horrible
20131118 12:53:11 <masterzen> rmk0: yes, all the class in a given apk ends in the same dex file. The dalvik runtime when calling a method uses an index in a huge table of all methods of all classes. This index is an unsigned short.
20131118 12:53:28 <rmk0> delightful
20131118 12:53:58 <masterzen> sgothel: sorry, the 2.1.3-rc-20131111 doesn't seem to work on our xperia ES3. I'm creating a gist with the logcat
20131118 12:54:19 <sgothel> interesting .. Nexus 5 works here :-/
20131118 12:57:46 <sgothel> yup .. a logcat of the DEBUG JoglVersion .. err JoglDebug (new activity) would be nice
20131118 12:57:56 <sgothel> besides your application ..
20131118 12:58:03 <masterzen> sgothel: check this logcat: https://gist.github.com/masterzen/50ee8898489a98548499
20131118 12:58:16 <sgothel> i.e. here it detects ES3 and maps it to GL2ES2
20131118 12:58:21 <masterzen> sgothel: the error seems: main: GLContext.setGLFuncAvail.X: FAIL, GL version mismatch (Int): 2.0 (ES profile, hardware) -> OpenGL ES 2.0 V@6.0 AU@04.01.02.44.002 (CL@2778170), 3.0.0
20131118 13:02:12 <sgothel> I do miss: 'Pre version verification - expected 3.0'
20131118 13:03:01 <sgothel> and it's sad that the integer GL version doesn't match the GL version string (ES2 string, 3.0 integer) ..
20131118 13:03:51 <masterzen> sgothel: what do you mean?
20131118 13:04:41 <masterzen> sgothel: do you mean I'm not running the latest version or the code is incorrect?
20131118 13:05:01 <sgothel> no no .. the driver
20131118 13:05:30 <sgothel> but similar here .. i.e. the version string may produce 'ES 2.0' but integer queried version is 3.0
20131118 13:06:03 <sgothel> so what I am missing is the 3.0 ES query .. we do trigger in EGLDrawableFactory .. looking
20131118 13:06:46 <masterzen> ok
20131118 13:07:04 <sgothel> maybe you use an older version ?
20131118 13:07:27 <sgothel> EGLDrawableFactory line 618
20131118 13:07:32 <masterzen> I used the rc in your maven
20131118 13:07:34 <sgothel> hmm
20131118 13:07:43 <masterzen> let me double checkl
20131118 13:07:45 <sgothel> ok .. let me double check ..
20131118 13:07:46 <sgothel> :)
20131118 13:08:00 <masterzen> 2.1.3-rc-20131111
20131118 13:08:08 <masterzen> is what I built with
20131118 13:08:15 <masterzen> do you have anything more recent?
20131118 13:08:57 <sgothel> not yet .. right .. you don't have the version number (git commit .. etc) .. lets me check
20131118 13:09:44 <sgothel> http://jogamp.org/deployment/archive/master/gluegen_746-joal_499-jogl_1146-jocl_875/log/all.artifact.properties.sorted
20131118 13:11:00 <sgothel> 2dce639c479f820d1a1e701f5eddffc4b02f5e0f Bug 890 is in ..
20131118 13:13:51 <sgothel> W/System.err(15205): EGLDrawableFactory.mapAvailableEGLESConfig: GLES3 ( 3 ), defaultSharedResourceSet false, mapsADeviceToDefaultDevice true (QUERY_EGL_ES_NATIVE_TK false, hasDesktopFactory false, isEGLGraphicsDevice true)
20131118 13:13:52 <sgothel> W/Adreno200-EGL(15205): <qeglDrvAPI_eglChooseConfig:715>: EGL_BAD_ATTRIBUTE
20131118 13:13:52 <sgothel> W/Adreno200-EGL(15205): <qeglDrvAPI_eglChooseConfig:715>: EGL_BAD_ATTRIBUTE
20131118 13:13:55 <sgothel> here we go ..
20131118 13:15:52 <masterzen> sgothel: you're talking Chinese to me :)
20131118 13:17:03 <eclesia> he often talk chinese :D
20131118 13:18:00 <sgothel> :)
20131118 13:18:30 <sgothel> yeah .. so it looks like the EGLConfig attribute ES3 is not available .. many egl-cfg query errors
20131118 13:18:44 <sgothel> in found EGLCaps .. I only see ES1 and ES2 ..
20131118 13:18:55 <sgothel> chosen GLCaps[egl cfg 0x2, vid 0x4: rgba 5/6/5/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GLES2/GLES2.sw], offscr[pbuffer], [0x7: GLES1, GLES2, VG]]]] ,
20131118 13:19:07 <sgothel> this is .. another driver issue
20131118 13:19:31 <sgothel> well, we could add a quirk .. or relax this issue .. dunno
20131118 13:19:51 <sgothel> for sure .. everything below core 3.0 profile shall not check the int-version ..
20131118 13:20:37 <sgothel> we should also be more verbose .. which EGLConfig attribute fails to query ..
20131118 13:21:20 <sgothel> I guess I make another patch .. would be great if you can test again then .. at least it will enable ES2 .. and we will see which EGLConfig attributes fail to query ..
20131118 13:21:29 <sgothel> is this more .. err .. English ?
20131118 13:21:30 <sgothel> :)
20131118 13:22:12 <sgothel> Ni Hao
20131118 13:22:17 <masterzen> sgothel: definitely :)
20131118 13:22:52 <masterzen> sgothel: I can test anything quite quickly today and the rest of this week, as long as you publish it on the jogamp maven repository
20131118 13:23:19 <sgothel> awesome .. thx
20131118 13:23:26 <monsieur_max> masterzen , eclesia: haha i'm not the only one then :)
20131118 13:23:50 <masterzen> sgothel: just ping me when ready (I need to borrow the culprit device from one of my co-worker)
20131118 13:24:19 <sgothel> yup thx
20131118 13:24:26 <monsieur_max> tha annoying part of android, testing is long :(
20131118 13:25:08 <sgothel> well .. tbh .. ES3 driver 'quality' is not very good .. to say the least
20131118 13:25:22 <sgothel> Mesa seems to be best right now
20131118 13:25:56 <sgothel> you also will find a hack in GLMediaPlayer test code .. GLSL version .. etc .. quite ugly
20131118 13:28:28 <monsieur_max> well, for now we're not even sure of porting the game to android, i'm not feeling confident about this one, not sure that it'll be worth it
20131118 13:29:56 <sgothel> at least it is a good exercise .. also stabilizing your code .. be ready when needed
20131118 13:30:17 <sgothel> try using MESA w/ ES 2.0 and 3.0 first IMHO
20131118 13:30:40 <sgothel> if working .. go ahead w/ Android :)
20131118 13:33:09 <sgothel> @Brice: Have you also set debug property 'nativewindow.debug=all' ?
20131118 13:33:45 <sgothel> this should give us more details about the EGLConfig failures ..
20131118 13:34:05 <monsieur_max> sgothel: just to be sure to understand, Mesa is the default driver for desktop ?
20131118 13:36:01 <sgothel> pardon me ? .. Well, Mesa is a OpenGL implementation ..
20131118 13:36:20 <sgothel> and probably your default open-source driver on some platforms ..
20131118 13:36:36 <sgothel> opensource: AMD, INTEL, .. etc
20131118 13:38:48 <sgothel> .. adding more verbosity to EGL cfg query failure ..
20131118 13:42:01 <monsieur_max> sgothel: ok, understood the advice you gave
20131118 14:23:35 <sgothel> W/System.err(11845): GL_RENDERER Adreno (TM) 330
20131118 14:23:36 <sgothel> W/System.err(11845): GL_VERSION OpenGL ES 3.0 V@53.0 AU@ (CL@3776187)
20131118 14:23:36 <sgothel> W/System.err(11845): GLSL true, has-compiler-func: true, version: OpenGL ES GLSL ES 3.00 / 3.0.0
20131118 14:24:12 <sgothel> ^^ Nexus 5 - w/ ES1 + ES3 (not ES2, due to string version ES 3.0)
20131118 14:24:43 <eclesia> speaking chinese again
20131118 14:59:03 * rmk0 (~rmk0@anon) Quit (Ping timeout: 272 seconds)
20131118 15:01:03 * trigger (~trigger@anon) has joined #jogamp
20131118 15:09:42 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 15:09:42 * rmk0 (~rmk0@anon) Quit (Changing host)
20131118 15:09:42 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 15:15:28 * rmk0 (~rmk0@anon) Quit (Ping timeout: 264 seconds)
20131118 15:15:49 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 15:15:49 * rmk0 (~rmk0@anon) Quit (Changing host)
20131118 15:15:49 * rmk0 (~rmk0@anon) has joined #jogamp
20131118 15:33:32 <sgothel> @Brice: ES1 and ES3 OK: Mali-T604 (Nexus 10), and Adreno (TM) 330 (Nexus 5)
20131118 15:34:00 <sgothel> will do another RC when build is done
20131118 15:34:40 <sgothel> curious about the result .. probably on your device: ES2 avail, ES3 not (due to EGLConfig bug) - EGLConfig DEBUG values are of interest
20131118 15:34:44 <eclesia> quick question : what is common GL profile for all mobile ?
20131118 15:34:50 <eclesia> (android only)
20131118 15:35:01 <sgothel> either GL2ES1 or GL2ES2
20131118 15:35:09 <sgothel> GL2ES2 .. only if serious ..
20131118 15:35:10 <eclesia> thanks
20131118 15:35:20 <sgothel> pls check the UML diagram as well
20131118 15:35:44 <sgothel> http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html
20131118 15:35:49 <sgothel> http://jogamp.org/jogl/doc/uml/html/fig128069.png
20131118 15:36:26 <eclesia> I was just wondering what was the current opengl capabilities of modern mobiles, nothing more :)
20131118 15:36:46 <sgothel> thats a diff. question :)
20131118 15:37:03 <eclesia> still no GL4 ...
20131118 15:37:09 <sgothel> oh well ..
20131118 15:37:15 <sgothel> ES3 + extensions
20131118 15:37:25 <sgothel> (very new devices)
20131118 15:38:07 <eclesia> nvidia made a quad core arm cpu with a gpu supporting gl4 if I remember correctly
20131118 15:38:39 <eclesia> somekind of trimmed down and underclocked gtx
20131118 15:39:13 <sgothel> yes - they dropped their orig Tegra design
20131118 15:39:26 <sgothel> so core GL on mobile is their goal
20131118 15:39:34 <eclesia> that would be nice
20131118 15:55:49 * xranby1 (~xranby@anon) Quit (Ping timeout: 248 seconds)
20131118 16:05:35 * xranby (~xranby@anon) has joined #jogamp
20131118 16:59:47 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131118 17:10:01 * kermyt (~kermyt@anon) Quit (Ping timeout: 246 seconds)
20131118 17:11:14 <rmk0> sgothel: you got any idea what causes libjawt.so to be loaded, these days?
20131118 17:11:30 <rmk0> we're still trying to work out why it's not loaded when running a trivial JOGL program under ceylon
20131118 17:11:50 <sgothel> we do load it manuallly
20131118 17:12:01 <rmk0> strange
20131118 17:12:19 <sgothel> hence a most early GLProfile/NativeWindowFactory initSingleton() might be advised .. if not loading ..
20131118 17:12:29 <rmk0> hm!
20131118 17:12:29 <sgothel> I assume your Ceylon uses a normal JVM ?
20131118 17:12:39 <rmk0> yep, uses the system jdk
20131118 17:12:39 * eclesia (~husky@anon) Quit (Quit: Leaving.)
20131118 17:12:49 <rmk0> will try initSingleton
20131118 17:12:50 <sgothel> is it working w/ headless=true .. as advised ?
20131118 17:12:56 <sgothel> i.e. no AWT at all ..
20131118 17:13:41 <rmk0> headless=true suppresses the libjawt error, but results in a further link error:
20131118 17:14:22 <sgothel> right ..
20131118 17:14:39 <sgothel> but that is another link error- which ofc should not happen
20131118 17:14:44 <rmk0> http://waste.io7m.com/2013/11/18/ouch.txt
20131118 17:14:51 <rmk0> sorry, took FIVE attempts to get eclipse to copy and paste
20131118 17:14:51 <sgothel> so this is _not_ a normal JVM
20131118 17:15:10 <rmk0> it's the system JVM, but they do seem to be loading things in a non-standard way
20131118 17:15:20 <rmk0> i think they've done some sort of partitioning in preparation for jigsaw
20131118 17:15:32 <sgothel> so it's a broken JVM
20131118 17:15:42 <rmk0> it could well be, yes, we're trying to determine how/why it's broken
20131118 17:15:52 * kermyt (~kermyt@anon) has joined #jogamp
20131118 17:15:59 <sgothel> ldd -r -v libnativewindow_x11.so
20131118 17:16:07 <sgothel> and something is not available in the JVM
20131118 17:16:24 <rmk0> http://waste.io7m.com/2013/11/18/linkage.txt
20131118 17:16:34 <rmk0> this is the conversation i've just been having with them
20131118 17:17:03 <rmk0> clearly libjawt.so isn't being loaded by the jvm configuration they have, but noone's exactly sure why
20131118 17:17:05 <sgothel> well .. so Caused by: java.lang.UnsatisfiedLinkError: jogamp.nativewindow.x11.X11Util.initialize0(Z)Z at jogamp.nativewindow.x11.X11Util.initialize0(Native Method)
20131118 17:17:13 <rmk0> yeah, that's with java.awt.headless=true
20131118 17:17:18 <sgothel> maybe they use a different JNI linking schema ?
20131118 17:17:18 <rmk0> without it, the error is:
20131118 17:17:40 <rmk0> http://waste.io7m.com/2013/11/18/output.txt
20131118 17:17:42 <sgothel> b/c ldd -r -v doesn't even show other symbols ..
20131118 17:18:02 <sgothel> btw .. not _awt -> _x11 !
20131118 17:18:13 <sgothel> pls try w/ headless 1st ..
20131118 17:18:37 <sgothel> but probably it's the same root cause
20131118 17:18:44 <rmk0> sgothel: please re-read, as i said: without java.awt.headless=true, the error is http://waste.io7m.com/2013/11/18/output.txt
20131118 17:18:49 <sgothel> however headess simplifies things ..
20131118 17:18:59 <rmk0> with java.awt.headless=true, the error is: http://waste.io7m.com/2013/11/18/ouch.txt
20131118 17:19:09 <rmk0> so there are two separate issues
20131118 17:19:17 <sgothel> not really
20131118 17:19:22 <rmk0> no?
20131118 17:19:39 <sgothel> both expose - that your VM does not link properly w/ JNI names
20131118 17:20:19 <sgothel> sven@risa:/usr/local/projects/JOGL/jogl/make$ ldd -r -v ../build-x86_64/nativewindow/obj/libnativewindow_x11.so
20131118 17:20:19 <sgothel> linux-vdso.so.1 (0x00007fffb5da8000)
20131118 17:20:19 <sgothel> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb1620b8000)
20131118 17:20:19 <sgothel> libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fb161eb0000)
20131118 17:20:19 <sgothel> libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fb161ca0000)
20131118 17:20:19 <sgothel> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb1618f0000)
20131118 17:20:19 <sgothel> libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb1616d0000)
20131118 17:20:20 <sgothel> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb1614c8000)
20131118 17:20:20 <sgothel> libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb1612b0000)
20131118 17:20:21 <sgothel> /lib64/ld-linux-x86-64.so.2 (0x00007fb162640000)
20131118 17:20:21 <sgothel> libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb1610a8000)
20131118 17:20:22 <sgothel> libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb160ea0000)
20131118 17:20:31 <sgothel> quite simple .. no JVM dependencies ..
20131118 17:20:59 <sgothel> so linkage error is not caused by missing symbols ..
20131118 17:21:05 <rmk0> yeah, that's the same output i get here
20131118 17:21:11 <rmk0> i'm using the 2.1.2 jars
20131118 17:21:12 <sgothel> hence root cause must be your VM's JNI linker
20131118 17:21:21 <sgothel> same probably w/ JAWT
20131118 17:21:24 <rmk0> right
20131118 17:21:41 <sgothel> so you guys have to look .. simple JNI use case .. try to load/link and use
20131118 17:21:48 <sgothel> GlueGen has a simple unit test ..
20131118 17:21:56 <rmk0> i should mention... i have nothing to do with the ceylon project whatsoever
20131118 17:22:07 <rmk0> i saw it mentioned, decided to give it a try
20131118 17:22:07 <sgothel> too late now :)
20131118 17:22:09 <rmk0> hehe
20131118 17:22:26 <rmk0> they expressed interest in seeing an OpenGL program written in ceylon, so i gave it a try
20131118 17:22:59 <sgothel> btw .. they should better use openjdk8 as a base w/ the 'profiles' .. jigsaw is a PIA AFAIK .. and not yet proven to be working
20131118 17:23:18 <sgothel> our JIGong attempts w/ openjdk8 profiles .. was successful
20131118 17:23:25 <rmk0> right
20131118 17:23:44 <sgothel> in short -> probably a waste of time at this stage ..
20131118 17:24:44 <rmk0> they're actually not using jigsaw directly, they've just exposed the java standard library in ceylon as if it was organized according to jigsaw
20131118 17:25:05 <rmk0> so i don't think it makes much difference to them whether or not jigsaw works, it's just an organizational scheme
20131118 17:25:10 <sgothel> but great to learn that our native jar stuff works well :)
20131118 17:25:28 <rmk0> it's by far the least painful native library handling i've used
20131118 17:27:40 <sgothel> .. we did that all together .. good team work!
20131118 17:28:03 <rmk0> \o/
20131118 17:28:18 <rmk0> is nice how it's resistant to name changes now, too
20131118 17:28:27 <rmk0> means it tends to work with all these different package manager
20131118 17:28:28 <rmk0> s
20131118 17:28:33 <sgothel> yup
20131118 17:28:53 <sgothel> you are 'guilty' here as well :)
20131118 17:28:57 <rmk0> yep!
20131118 17:30:58 <sgothel> 2.1.3-rc-20131117: our-maven + http://jogamp.org/deployment/archive/master/gluegen_751-joal_502-jogl_1153-jocl_879/
20131118 17:31:06 <sgothel> @Brice: Please test - Thank you!
20131118 17:31:20 <sgothel> I will update AMD driver on Windows box .. too instable .. oh well
20131118 17:31:42 <sgothel> we have a new certificate .. for 2+ years (jar files) .. will install it now
20131118 17:38:51 * trigger (~trigger@anon) Quit (Quit: Ex-Chat)
20131118 17:45:08 * gavinking (~gavinking@anon) has joined #jogamp
20131118 17:45:17 <rmk0> 'lo
20131118 17:45:18 <gavinking> hi
20131118 17:45:29 <rmk0> sgothel: gavinking <- one of the ceylon authors
20131118 17:45:48 <gavinking> so what's going on here is i have a bog standard Java 7 JRE
20131118 17:46:09 <gavinking> and i'm running my code in something called JBoss Modules
20131118 17:46:16 <gavinking> which is the core of JBoss AS
20131118 17:46:24 <gavinking> it's a system a whole lot like OSGi
20131118 17:46:30 <gavinking> but much simpler
20131118 17:46:45 <gavinking> we know the module runtime works because lots of people run Java EE apps on it :)
20131118 17:46:54 <gavinking> the only thing "funny" here is that
20131118 17:47:09 <gavinking> this is a p-to-p classloading architecture
20131118 17:48:07 <gavinking> where the Java SDK classes are not coming from the parent classloader
20131118 17:48:18 <gavinking> but from a separate classloader under the control of jboss modules
20131118 17:48:51 <gavinking> this appears to work fine, since we can run Swing and AWT applications
20131118 17:49:12 <gavinking> the question is what is special in the case of jogl
20131118 17:49:26 <gavinking> that causes native libs to not be found
20131118 17:49:50 <rmk0> back shortly
20131118 17:49:55 <rmk0> \o\
20131118 17:50:17 * hharrison (~chatzilla@anon) has joined #jogamp
20131118 17:50:48 * monsieur_max (~maxime@anon) has joined #jogamp
20131118 17:51:27 <gavinking> my assumption is that JOGL does something other than simply calling AWT APIs via Java
20131118 17:51:33 <gavinking> though i have no clue what
20131118 17:52:38 * rmk0 appears
20131118 17:53:08 <rmk0> sgothel did mention earlier that libjawt.so is manually loaded by JOGL
20131118 17:53:25 <gavinking> ahwell
20131118 17:53:35 <rmk0> not being too familiar with JNI, i'm not sure what could affect loading
20131118 17:53:36 <gavinking> precisely *how* manually loaded?
20131118 17:53:44 <gavinking> i don't know JNI at all, FTR
20131118 17:54:03 <sgothel> so .. then .. we need to load the native stuff from a classloader actually being used by the using classloader ..
20131118 17:54:10 <sgothel> sorry: _you_ :)
20131118 17:54:31 * rmk0 eyes source
20131118 17:54:51 <sgothel> but please - the 'user' CL must have the system CL as it's parent ..
20131118 17:54:59 <gavinking> i mean, jogl has its own classloader, because it is a module
20131118 17:55:00 <sgothel> otherwise nothing could get found
20131118 17:55:20 <gavinking> and then java.desktop has a classloader, because it is a dependency
20131118 17:55:23 <sgothel> so: System-CL <- JOGL-CL <- User-CL
20131118 17:55:30 <sgothel> similar thing as w/ Android
20131118 17:55:53 <sgothel> 'just' make sure .. the CL dependency / hierarchy is correct
20131118 17:56:01 <gavinking> i don't see how that would work in a p-to-p classloader world
20131118 17:56:09 <gavinking> think about a system like OSGi
20131118 17:56:21 <gavinking> or JBoss, or whatever
20131118 17:56:35 <gavinking> JOGL isn't creating the application classloader
20131118 17:56:59 <gavinking> that is to say, we can't force it onto a parent CL
20131118 17:57:23 <gavinking> the parent CL is for a tiny microkernel, not for applications and libraries
20131118 17:57:47 <gavinking> the concept behind modularity is that libs run on isolated classloaders
20131118 17:58:00 <gavinking> so you can have multiple versions of the same lib in the same VM
20131118 17:58:07 <gavinking> even in the same application, if necessary
20131118 17:58:56 <gavinking> even if you would try to *force* the lib onto the system classpath
20131118 17:59:04 <gavinking> the application would not see it
20131118 17:59:11 <gavinking> b/c the application doesn't see the system cp
20131118 17:59:26 <rmk0> what is it that's required from the system classloader?
20131118 17:59:34 <rmk0> presumably it's the one that knows where the jre libraries are?
20131118 17:59:36 <gavinking> it only sees things it explicitly declares dependencies to
20131118 17:59:53 <gavinking> rm, now you're asking me details that i'm not completely sure about
20131118 18:00:06 <rmk0> well that wasn't directed at you specifically
20131118 18:00:27 <rmk0> just wondering if there's some other way the required information can be published without needing a classloader dependency
20131118 18:01:04 <gavinking> perhaps
20131118 18:01:09 <gavinking> let's ask Ales
20131118 18:01:24 <sgothel> well .. it works w/ OSGi .. etc .. on Android I use a launcher ..
20131118 18:01:50 <sgothel> launcher: kick's off new CL w/ JOGL .. etc .. and user JARs .. then the user main entry on new CL
20131118 18:02:00 <sgothel> sorry .. bust now w/ 2.1.3 stuff ..
20131118 18:02:24 <gavinking> well the diff is perhaps that
20131118 18:02:46 <gavinking> i'm not sure if, in osgi, whether maybe java sdk stuff is available on the parent CL
20131118 18:02:58 <sgothel> so make it so ..
20131118 18:03:18 <sgothel> we have a minimum Java system class dependency ..
20131118 18:03:35 <sgothel> let's say OpenJDK8 min-profile .. or Android's subset
20131118 18:04:37 <gavinking> i'm a little confused ... is Android even Java?
20131118 18:04:44 <gavinking> are the native libs the same?
20131118 18:04:45 <sgothel> IANAL :)
20131118 18:04:57 <sgothel> there is something like that .. yes
20131118 18:05:01 <gavinking> i thought it was like a clean reimplementation?
20131118 18:05:10 <gavinking> the VM is not a Java VM, i know that much
20131118 18:05:14 <sgothel> compliant w/ API .. incl. JNI
20131118 18:05:25 <gavinking> including the JNI stuff ok i did not know that
20131118 18:05:52 <gavinking> and what CL does Java SDK get loaded on in android?
20131118 18:06:11 <sgothel> we have a few ClassLoader unit tests in GlueGen .. which shows separation .. etc .. you may look at it and do a launcher .. however OSGi has the same thing
20131118 18:06:13 <gavinking> is it loaded as an ordinary OSGi bundle?
20131118 18:06:50 <sgothel> nope - but we have one magic APK reusage .. which daisy chains CLs for each APK
20131118 18:07:26 <gavinking> hrm
20131118 18:07:42 <gavinking> well, gtg, ales is not responding, all this is well beyond my expertise
20131118 18:07:52 <sgothel> http://jogamp.org/deployment/archive/master/gluegen_751-joal_502-jogl_1153-jocl_879-signed/ <- pls test !
20131118 18:07:53 <rmk0> hehe, mine too
20131118 18:08:16 <gavinking> i don't know jni and i don't even really know jboss modules
20131118 18:08:22 <sgothel> for somebody dealing w/ CLs .. and OSGi etc .. this is easy and should make sense
20131118 18:08:25 <gavinking> i know what it looks like when i use it from ceylon
20131118 18:08:31 <gavinking> but this is one level down
20131118 18:08:49 <gavinking> we'll wait for Ales
20131118 18:09:02 <gavinking> gtg
20131118 18:09:06 <rmk0> byeee!
20131118 18:09:09 * gavinking (~gavinking@anon) Quit (Remote host closed the connection)
20131118 18:09:29 <rmk0> pleasant people
20131118 18:09:39 <sgothel> http://jogamp.org/deployment/archive/master/gluegen_751-joal_502-jogl_1153-jocl_879-signed/jogl-applet-bug848_glcanvas01.html
20131118 18:09:40 <rmk0> have been very receptive to .. everything, so far
20131118 18:10:01 <sgothel> shows that indeed (on NV) it makes a difference to only vsync the 'last GLEventListener'
20131118 18:10:01 <rmk0> they seem very interested in getting everything working correctly
20131118 18:10:09 <sgothel> nice nice
20131118 18:10:30 <hharrison> sgothel: afraid focus deadlock still there, have patch in progress I'll attach to bug 879
20131118 18:10:40 <sgothel> autch ..
20131118 18:11:01 <sgothel> slow-mo slam dunk :)
20131118 18:11:17 <sgothel> however .. NEwtCanvasAWT focus Java7/OSX issue are gone
20131118 18:11:38 <sgothel> pls incl. a stack trace .. latest sources I assume
20131118 18:11:51 <hharrison> Already added to the bug
20131118 18:12:03 <hharrison> Commit identified in the comment
20131118 18:12:21 <hharrison> Essentially I wrap the call to clearGlobalFocusOwner in a Runnable and ship it over to the AWT event thread....which has survived some toture so far this morning
20131118 18:13:05 <sgothel> sweet!
20131118 18:13:24 <sgothel> thats the kind of patch I like - hope it survives the 'new locking' ..
20131118 18:13:46 <sgothel> git pull req maybe ?
20131118 18:13:54 <sgothel> or is it a git patch ?
20131118 18:17:09 <hharrison> I will provide it as a pullable commit w/ message after a bit more hammering
20131118 18:17:25 <hharrison> Say, 20 minutes or so?
20131118 18:17:44 <hharrison> If you want it right away, I can do so and then hammer a bit more
20131118 18:22:24 <sgothel> nono .. all good
20131118 18:22:37 <sgothel> won't do 2.1.3 before weekend
20131118 18:22:42 <sgothel> i.e. time to test ..
20131118 18:23:06 <sgothel> will make an announcement for further testing later
20131118 18:23:44 <hharrison> grrrr, fucking modal dialogs
20131118 18:24:36 <hharrison> Was hoping to get away without waiting for the AWT event to resolve, but may have to or else modal focus appears to get pretty screwed up
20131118 18:25:40 <hharrison> But I may be able to live with that
20131118 18:25:50 <sgothel> hmm .. clearGlobalFocusOwner() <- thought that was not so intrusive :(
20131118 18:26:14 <hharrison> it apparently can still get locked against the native calls....whee!
20131118 18:26:52 <sgothel> delegate on AWT-EDT w/ blocking may not work .. since it could originate from AWT-EDT, i.e. AWT-EDT -> NEWT-EDT (or else) -> AWT-EDT XXX
20131118 18:27:03 <sgothel> at least .. this must be ensured .. to work
20131118 18:27:13 <sgothel> IMHO our unit tests to cover that
20131118 18:27:53 <hharrison> Your AWTEDTExecutor class seems to take care of that
20131118 18:28:18 <hharrison> Oh wait, I see what you're saying
20131118 18:28:27 <sgothel> not about the deadlock
20131118 18:29:29 <sgothel> AWTEDTExecutor: Only delegates to AWT-EDT if not there yet
20131118 18:29:58 <sgothel> I would love to have a mechanism .. whether to learn if we originate from AWT-EDT
20131118 18:30:00 <hharrison> The non-waiiting version seems to work here, modal dialogs get a bit odd as they can't always capture focus
20131118 18:30:02 <hharrison> But that
20131118 18:30:11 <hharrison> 's what you get for mixing AWT and NEWT I supose
20131118 18:31:29 <sgothel> sure - well, if it does not deadlock .. we can think about that .. just want to mention such thing as a risk ...
20131118 18:33:17 <hharrison> I was hoping block until AWT had done its thing would fix the modal dialog, but it made no difference, so non-blocking in my patch
20131118 18:34:48 * alesj (~alesj@anon) has joined #jogamp
20131118 18:35:07 * alesj (~alesj@anon) has left #jogamp
20131118 18:44:46 <hharrison> Yeah, with enough torture I can make it deadlock if it is a waiting call
20131118 18:45:36 <hharrison> exactly like you warned about above AWT-EDT waiting for itself
20131118 18:49:29 <sgothel> 'great' :)
20131118 18:49:53 <hharrison> The non-waiting version has survived everything so far, which is a good sign
20131118 19:10:50 <hharrison> https://github.com/AusencoSimulation/jogl.git master
20131118 19:11:08 <hharrison> 3 commits waiting for you there, two cleanups, then the push to AWT EDT patch
20131118 19:13:19 <hharrison> I also put the commits in the comments of bug 879
20131118 19:15:31 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20131118 19:17:06 * xranby (~xranby@anon) has joined #jogamp
20131118 19:19:26 <sgothel> THANK YOU
20131118 19:19:52 <hharrison> Even a blind squirrel finds a nut every so often
20131118 19:20:14 <hharrison> I'll admit I'm patching the symptoms and may not appreciate any of the subtley here
20131118 19:21:00 <sgothel> oh .. the AWT-EDT delegation is a true fix .. :)
20131118 19:21:27 <hharrison> I notice there is another call to clearGlobalFocusOwner in NewtCanvasAWT (inside requestFocusNewtChild) but I don't know if it needs the same treatment
20131118 19:21:47 <sgothel> would be good to know .. since that method has that risk ..
20131118 19:22:03 <sgothel> i.e. simply apply same treatment .. can't hurt too much
20131118 19:22:29 <hharrison> I don't have a test case for that path, but I will do the patch and wait for complaints ;-)
20131118 19:22:39 <hharrison> (from jenkins)
20131118 19:22:42 <sgothel> sure
20131118 19:23:50 <sgothel> 0a9d16f057727652220a5983b65f22f427df6a22 oh dear :)
20131118 19:24:05 <sgothel> I missed that while changing the branch .. lol
20131118 19:24:18 <hharrison> Will push to same place as above (away from my ssh key, so will use the ausencosimulation one)
20131118 19:24:27 <sgothel> ay .. dinner time .. laters
20131118 19:24:47 <sgothel> will test ofc ..
20131118 19:26:13 * alesj (~alesj@anon) has joined #jogamp
20131118 19:26:30 <alesj> what was the issue with Ceylon and CL?
20131118 19:28:26 <alesj> sgothel: ^^
20131118 19:30:30 <hharrison> sgothel just stepped away for food
20131118 19:30:41 <hharrison> missed him by that >< much
20131118 19:31:33 <hharrison> sgothel: pushed out follow-on commit 177d0da1a9a8e031f15efa9e89465f8ed97f25e5 for your review
20131118 19:33:13 <alesj> hharrison: ok, let him know to ping me when he's back
20131118 19:33:40 <hharrison> Do you have the backlog of the earlier discussion?
20131118 19:34:19 <hharrison> alesj: Do you have the backlog of the earlier discussion?
20131118 19:35:12 <alesj> hharrison: just what Gavin pushed to me — there is some log, let me then read that first
20131118 19:35:20 <hharrison> Do you have the backlog of the earlier discussion?
20131118 19:35:23 <hharrison> sorry
20131118 19:35:28 <hharrison> http://jogamp.org/log/irc/jogamp_20131117152553.html
20131118 19:38:02 <alesj> hharrison: where does the relevant part start/
20131118 19:38:04 <alesj> ?
20131118 19:38:51 <hharrison> right about 20131118 17:11:14
20131118 19:39:19 <hharrison> Or more specifically the gavinking bit
20131118 19:39:50 <alesj> ok, tnx, will have a look
20131118 19:57:12 <sgothel> https://jogamp.org/chuck/job/jogl/1154/
20131118 20:04:03 <sgothel> @Alesj: @Mark is the 'contact' to Ceylon .. me just blabbering about CL's and native lib loading ..
20131118 20:05:16 <rmk0> 'lo
20131118 20:05:38 * hija (~hija@anon) Quit (Quit: hija)
20131118 20:06:25 <sgothel> I guess @Brice is home .. hmm
20131118 20:06:39 <sgothel> anybody here w/ such Xperia ES device ?
20131118 20:06:49 <sgothel> @Xerxes: Did you try on your mothers device ?
20131118 20:09:17 <sgothel> @All: I will be 'on tour' from Tomorrow until Thursday ~ 6pm UTC+1
20131118 20:09:28 <alesj> sgothel: which one is @Mark?
20131118 20:09:35 <sgothel> rmk0
20131118 20:09:38 * rmk0 waves
20131118 20:09:51 <alesj> ok :-)
20131118 20:10:01 <rmk0> not sure if you've followed in #ceylon
20131118 20:10:11 <rmk0> all of the details are in the backlog here, anyway
20131118 20:10:12 <alesj> imo, the issue, is just a case of missing native lib
20131118 20:10:50 <alesj> rmk0: yeah, i just re-read the backlog
20131118 20:11:03 <alesj> where do you current keep native libs?
20131118 20:11:18 <rmk0> where does JOGL keep them?
20131118 20:11:32 <rmk0> or...
20131118 20:11:33 <alesj> btw: what exactly is JOGL?
20131118 20:11:45 <alesj> OpenGL?
20131118 20:11:48 <rmk0> yes
20131118 20:11:53 <alesj> but Java version of it
20131118 20:12:00 <sgothel> http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFiles
20131118 20:12:18 <rmk0> essentially, the JOGL native libraries are distributed in jar files along with the standard jars
20131118 20:12:26 <rmk0> they're unpacked a temporary directory at runtime
20131118 20:12:29 <rmk0> *to a
20131118 20:12:38 <sgothel> http://jogamp.org/jogl/doc/userguide/index.html#automatednativelibraryloading
20131118 20:12:41 <sgothel> :)
20131118 20:12:43 <rmk0> hehe, yes, all that
20131118 20:12:50 <alesj> and how do you point the runtime to these tmp locations?
20131118 20:13:22 <rmk0> the documentation explains it better than i will
20131118 20:13:29 <sgothel> derived from class containing jar file
20131118 20:13:53 <sgothel> point is, Mark showed that native jar loading and extracting seem to work well
20131118 20:14:15 <rmk0> yes, the library loading appears to work exactly as it does in java
20131118 20:14:18 <alesj> "it falls back to the traditional native library loading mechanism via the java library path."
20131118 20:14:24 <sgothel> also .. the native library in the temp-folder-per-classloader is found!
20131118 20:14:36 <sgothel> but then .. unsatisfied link error
20131118 20:15:19 * gavinking (~gavinking@anon) has joined #jogamp
20131118 20:15:19 <sgothel> all this is JVM and JRE-system-class centric ..
20131118 20:15:20 <alesj> can you point me to the code that does the native lib loading?
20131118 20:16:41 <sgothel> /gluegen/src/java/com/jogamp/common/jvm/JNILibLoaderBase.java method loadLibraryInternal(..)
20131118 20:17:26 <sgothel> as stated .. it uses TempJarCache implicit, TempJarCache is the cache per ClassLoader and JVM instance
20131118 20:17:27 <rmk0> http://jogamp.org/git/?p=gluegen.git;a=blob;f=src/java/com/jogamp/common/jvm/JNILibLoaderBase.java;h=201fc590f16c6a0496bd38fb072299f1bb0c3424;hb=HEAD
20131118 20:17:40 <sgothel> /gluegen/src/java/com/jogamp/common/util/cache/TempJarCache.java
20131118 20:18:37 <rmk0> http://jogamp.org/git/?p=gluegen.git;a=blob;f=src/java/com/jogamp/common/util/cache/TempJarCache.java;h=99bb272fe8fbf0f028482cc6f9fb70178ebf04c6;hb=HEAD
20131118 20:18:43 <rmk0> i am your URI resolution bot for today
20131118 20:18:50 <sgothel> but I don't think we need to go this route .. via TempJarCache details, since native lib was found. Otherwise an earlier exception would have been thrown
20131118 20:18:55 <sgothel> :)
20131118 20:19:05 <sgothel> I assume they use an IDE
20131118 20:21:03 <sgothel> http://waste.io7m.com/2013/11/18/ouch.txt
20131118 20:21:32 <alesj> how do you know the lib was found?
20131118 20:21:35 <alesj> from log?
20131118 20:21:40 <alesj> but was it properly loaded
20131118 20:21:46 <sgothel> JNILibLoaderBase: loadLibraryInternal(nativewindow_x11), TempJarCache: /tmp/jogamp_0000/file_cache/jln9099199413698586173/jln5553470894009779611/libnativewindow_x11.so
20131118 20:21:46 <sgothel> JNILibLoaderBase: System.load(/tmp/jogamp_0000/file_cache/jln9099199413698586173/jln5553470894009779611/libnativewindow_x11.so) - mode 2
20131118 20:21:47 <sgothel> JNILibLoaderBase: loadLibraryInternal(nativewindow_x11): OK - mode 2
20131118 20:21:47 <sgothel> JNILibLoaderBase: Loaded Native Library: nativewindow_x11
20131118 20:21:47 <sgothel> JNILibLoaderBase: loaded nativewindow_x11
20131118 20:21:47 <sgothel> Exception in thread "main" java.lang.reflect.InvocationTargetException
20131118 20:21:47 <sgothel> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
20131118 20:21:48 <sgothel> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
20131118 20:21:48 <sgothel> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
20131118 20:21:49 <sgothel> at java.lang.reflect.Method.invoke(Method.java:606)
20131118 20:21:49 <sgothel> at com.redhat.ceylon.launcher.Launcher.run(Launcher.java:89)
20131118 20:21:50 <sgothel> at com.redhat.ceylon.launcher.Launcher.main(Launcher.java:21)
20131118 20:21:50 <sgothel> Caused by: java.lang.UnsatisfiedLinkError: jogamp.nativewindow.x11.X11Util.initialize0(Z)Z
20131118 20:21:51 <sgothel> at jogamp.nativewindow.x11.X11Util.initialize0(Native Method)
20131118 20:22:01 <sgothel> ^^ see above
20131118 20:22:16 <sgothel> JNILibLoaderBase: loadLibraryInternal(nativewindow_x11): OK - mode 2
20131118 20:22:16 <sgothel> JNILibLoaderBase: Loaded Native Library: nativewindow_x11
20131118 20:22:40 <sgothel> not 'loaded' .. but located!
20131118 20:23:05 <sgothel> System.load(libraryPath); <- fails then
20131118 20:23:55 <sgothel> not really .. but _using_ one of the defined JNI methods fails later!
20131118 20:24:21 <rmk0> assume the jvm does lazy symbol resolution with dlsym underneath
20131118 20:24:22 <sgothel> so: "System.load(libraryPath);" was "working", at least didn't 'complain'
20131118 20:24:58 <sgothel> so locating lib was ok .. but unresolved .. JNI symbols ..
20131118 20:25:15 <sgothel> I assume it's the JNI native method resolution or something
20131118 20:25:35 <rmk0> that is the expected behaviour when using dlsym with RTLD_LAZY
20131118 20:25:41 <sgothel> - or - the classloader problem, however .. our native lib loading TempJarCache does take care of that
20131118 20:25:43 <rmk0> it'll fail on individual symbol lookups
20131118 20:25:50 <sgothel> yup - and thats good
20131118 20:25:53 <rmk0> yes
20131118 20:26:37 <sgothel> ClassLoader/JNI Issue: One native-lib file location per ClassLoader <- TempJarCache solves this
20131118 20:27:19 <sgothel> I almost thought Ceylon uses a different JNI naming convention .. or something like Ceylon_ instead of Java_ :)
20131118 20:27:58 <sgothel> We also checked that the native lib in question does not require any JVM symbol .. it's self contained - besides some std X11 libs
20131118 20:28:12 <sgothel> (I assume JOGL runs well on that test machine ..)
20131118 20:28:56 <rmk0> if you mean mine, then yeah, no issues
20131118 20:35:05 <alesj> so you're saying when your code did System::load("somelib") it worked?
20131118 20:35:26 <alesj> rmk0, sgothel ^
20131118 20:36:21 <rmk0> it found the JOGL libraries and loaded them, yes, but then failed on symbol lookups as the native libraries themselves had unresolved dependencies
20131118 20:36:25 <sgothel> well .. it found the file ..
20131118 20:36:28 <sgothel> :)
20131118 20:36:53 <sgothel> which it otherwise does not have .. (regular JVM) ..
20131118 20:37:13 <rmk0> http://waste.io7m.com/2013/11/18/linkage.txt
20131118 20:37:14 <sgothel> must not have unresolved dependencies .. at least it could not find the invoked JNI method
20131118 20:37:44 <sgothel> not that Mark .. pls focus on !AWT
20131118 20:37:52 <sgothel> i.e. headless - simpler case
20131118 20:37:58 <rmk0> *ahem*, right
20131118 20:38:06 <sgothel> so nativewindow_x11 .. has no unresolved things
20131118 20:40:47 <alesj> rmk0, sgothel: do you have the code of the example you're trying to run?
20131118 20:41:12 <alesj> or how does example import JOGL?
20131118 20:41:34 <rmk0> i've uploaded the project somewhere, let me see...
20131118 20:41:47 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl-003.7z
20131118 20:41:58 <rmk0> can ./make.sh && ./run.sh
20131118 20:42:00 <sgothel> Note: If you run it, pls do it w/ '-Djava.awt.headless=true' to avoid the 'other' JAWT issue for now
20131118 20:42:07 <rmk0> yes, would add that property too
20131118 20:42:32 <rmk0> i've just realized that the make.sh and run.sh contain an LD_LIBRARY_PATH... would remove that, it makes no difference whether it's there or not
20131118 20:49:12 * dmlloyd (~dmlloyd@anon) has joined #jogamp
20131118 20:49:18 <dmlloyd> hello
20131118 20:49:43 <alesj> rmk0, sgothel: ^^ dmlloyd is the author of JBoss Modules, which is what we use in Ceylon
20131118 20:49:49 <rmk0> 'lo
20131118 20:49:56 <dmlloyd> so to repeat what I told ales in the other channel
20131118 20:50:13 <dmlloyd> in the JNI spec there are two different ways to link Java methods declared "native" with their C/C++ counterparts
20131118 20:50:13 <dmlloyd> this exception is typically thrown when dlsym fails for the generated Java name and the JNI lib never registered its native methods
20131118 20:50:35 <sgothel> we do not do JNI register ..
20131118 20:50:56 <dmlloyd> okay so you rely on the static dlsym method then
20131118 20:50:58 <sgothel> yup .. the lazy unresolved JNI ..
20131118 20:51:20 <sgothel> yup .. dunno whats static here though
20131118 20:51:26 <dmlloyd> well static in a relative sense
20131118 20:51:38 <dmlloyd> if you use registernatives, you can dynamically register whatever methods you want
20131118 20:52:20 <dmlloyd> anyway I had suggested to ales to use ldd on the /tmp/jogamp_0000/file_cache/jln9099199413698586173/jln5553470894009779611/libnativewindow_x11.so file
20131118 20:52:40 <dmlloyd> but I would expect that a problem with the linkage at that level would have caused loadLibrary to fail
20131118 20:52:49 <dmlloyd> this looks more like the symbol just isn't there
20131118 20:53:00 <dmlloyd> you could use nm on the .so file to check it
20131118 20:53:18 <sgothel> ldd is fine here .. pls note that the same native lib works well on Marks JOGL test
20131118 20:53:30 <dmlloyd> is there more than one overload of shutdown0?
20131118 20:53:38 <sgothel> hence my idea of .. diff. JNI naming convention ?
20131118 20:54:07 <sgothel> private static native void shutdown0(); <- no
20131118 20:54:21 <dmlloyd> the only thing I know of which would cause the naming convention of a method to change is if you added a second overload, which would cause the name to be expanded to include the signature
20131118 20:55:27 <dmlloyd> otherwise it should just be: Java_jogamp_nativewindow_x11_X11Util_shutdown0
20131118 20:55:36 <dmlloyd> if someone stripped the .so, that would cause this as well
20131118 20:56:06 <rmk0> the .so is stripped here
20131118 20:56:31 <dmlloyd> well, then that will probably explain it
20131118 20:56:46 <dmlloyd> you can strip it as long as you keep all the needed symbols
20131118 20:56:46 <rmk0> but... why does it work correctly when used from Java?
20131118 20:57:23 <dmlloyd> I couldn't tell you that
20131118 20:57:28 <dmlloyd> perhaps it's not the same JAR or .so
20131118 20:57:39 <rmk0> it's definitely the same
20131118 20:57:48 <rmk0> i took them straight from my local maven cache
20131118 20:57:57 <dmlloyd> jboss modules does nothing special with .so files other than looking for them in a different place
20131118 20:58:45 <dmlloyd> could you pastebin the nm output of the one that isn't working?
20131118 20:58:54 <rmk0> nm: /tmp/jogamp_0000/file_cache/jln4978453744420764725/jln5094264651834668860/libnativewindow_x11.so: no symbols
20131118 20:58:59 <alesj> rmk0: the lookup: https://docs.jboss.org/author/display/MODULES/Native+Libraries
20131118 20:59:42 <dmlloyd> yeah I don't see how it could work anywhere then
20131118 21:00:01 <dmlloyd> JNI relies on exported symbols to link against dynamic JNI libraries
20131118 21:00:59 <sgothel> use 'objdump'
20131118 21:01:05 <sgothel> objdump -T
20131118 21:01:10 <sgothel> grep UNRE
20131118 21:01:32 <sgothel> sure we have exported symbols ..
20131118 21:01:44 <rmk0> http://waste.io7m.com/2013/11/18/objdump.txt
20131118 21:02:30 <sgothel> System.load(/tmp/jogamp_0000/file_cache/jln9099199413698586173/jln5553470894009779611/libnativewindow_x11.so)
20131118 21:02:37 <sgothel> ^^ we do not strip the '.so' !
20131118 21:02:48 <rmk0> one sec...
20131118 21:02:50 <sgothel> we use the full qualified name
20131118 21:03:23 <dmlloyd> yeah that happens automatically by System.mapLibraryName(String)
20131118 21:03:41 <dmlloyd> the library is clearly loading else loadLibrary would have failed, not linking
20131118 21:03:53 <rmk0> ah, now i get an UnsatisfiedLinkError
20131118 21:03:54 <dmlloyd> this looks like it's failing when invoking the method, as if it can't find the symbol
20131118 21:04:11 <dmlloyd> when you load rmk0? or when you call the method?
20131118 21:04:17 <rmk0> http://waste.io7m.com/2013/11/18/testdl.java
20131118 21:04:34 <dmlloyd> ah
20131118 21:04:38 <rmk0> http://waste.io7m.com/2013/11/18/error.txt
20131118 21:04:48 <dmlloyd> well that error should only be thrown when the file does not exist
20131118 21:04:57 <dmlloyd> which is simple enough to test for
20131118 21:05:23 <dmlloyd> I suppose it might also be thrown if there's a missing dependency though
20131118 21:05:27 <dmlloyd> you can check that with ldd
20131118 21:05:31 <rmk0> argh, excuse me... that's the wrong path
20131118 21:05:35 <sgothel> circles ..
20131118 21:06:07 <rmk0> http://waste.io7m.com/2013/11/18/TestDL.java
20131118 21:06:19 <rmk0> sorry, that one was my fault, correct path this time
20131118 21:06:26 <rmk0> that program runs without error
20131118 21:07:30 <dmlloyd> okay so then we'll just ignore that small diversion :)
20131118 21:08:24 <dmlloyd> it had also complained about initialize0 beung unable to be linked
20131118 21:09:07 <rmk0> you'll have to bear with me, this is the first time i've touched JNI
20131118 21:09:12 <rmk0> is there something i can add to test that?
20131118 21:09:35 <dmlloyd> hmm
20131118 21:10:00 <sgothel> (gluegen unit tests .. ?)
20131118 21:10:02 <dmlloyd> you could maybe use strace to hook in and observe all calls to dlsym
20131118 21:10:11 <sgothel> ah .. strace
20131118 21:10:22 <sgothel> should show dlsym ..
20131118 21:10:24 <dmlloyd> and grep to see if it is looking for e.g. ...shutdown0__V or something
20131118 21:10:32 <rmk0> would probably make more sense to trace the ceylongl program then...
20131118 21:10:40 <dmlloyd> yeah the one that's failing
20131118 21:10:54 <dmlloyd> you could also catch dlopen and make sure it's really opening what you think it is opening too
20131118 21:11:30 * [Mike] (~Mike]@anon) has joined #jogamp
20131118 21:11:31 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl.txt
20131118 21:12:24 <rmk0> hm... lack of both dlopen and dlsym there
20131118 21:12:33 <rmk0> may need some extra flags to strace
20131118 21:13:09 <rmk0> yes, that did it
20131118 21:13:47 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl2.txt.gz
20131118 21:13:56 <rmk0> a mere 4.7mb of output
20131118 21:16:52 <sgothel> https://jogamp.org/chuck/job/jogl/1154/ <- this makes me angry .. the win7-amd network loss removed the great stats :)
20131118 21:17:13 <dmlloyd> heh you might have wanted to filter that a little :)
20131118 21:17:34 <dmlloyd> anyway I see no dlopen
20131118 21:17:38 <dmlloyd> in that one either
20131118 21:17:45 <sgothel> kernel dumps .. :)
20131118 21:18:38 <rmk0> i am seeing references to libnativewindow_x11.so, so presumably on my system, dlopen is achieved with mmap
20131118 21:18:43 <rmk0> as opposed to being a system call
20131118 21:18:45 <dmlloyd> I se a stat and unlink of it
20131118 21:19:43 <rmk0> i think you're looking for an open() followed by an mmap of the resulting file descriptor
20131118 21:20:52 <rmk0> lines 57190-57236
20131118 21:21:10 <rmk0> can see an open() that returns 47, and then some apparent parsing and mapping of the file
20131118 21:21:32 <dmlloyd> which .so has the actual symbol in it? is it libnativewindow_x11?
20131118 21:21:59 <dmlloyd> and, do the .so files have links to each other?
20131118 21:22:14 <rmk0> ah shit, that was running without -Djava.awt.headless=true
20131118 21:22:23 <rmk0> ugh, third time lucky then...
20131118 21:23:59 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl3.txt.gz
20131118 21:25:06 <rmk0> ok, same thing again: starting at line 55226, you can see the loading of libnativewindow_x11.so
20131118 21:25:24 <dmlloyd> hmm thought there was a way to trace library calls with strace
20131118 21:25:29 <dmlloyd> maybe that was truss on solaris
20131118 21:26:41 <dmlloyd> ltrace
20131118 21:26:52 * rmk0 installs
20131118 21:28:47 <rmk0> strange... it doesn't seem to want to trace a shell script (ceylon)
20131118 21:29:00 <rmk0> perhaps i trace /bin/sh ceylon ...
20131118 21:29:03 <rmk0> *if i
20131118 21:30:23 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl_ltrace0.txt.gz
20131118 21:30:36 <rmk0> doesn't appear to have worked
20131118 21:31:47 * gavinking (~gavinking@anon) Quit (Remote host closed the connection)
20131118 21:31:50 <dmlloyd> you may have to tell it to follow forks
20131118 21:32:02 <rmk0> what on earth is going on here... "Unable to access jarfile ./../lib/ceylon-bootstrap.jar"
20131118 21:32:13 <rmk0> it is following forks, yes, with -f
20131118 21:32:43 <rmk0> ah, it may be missing part of my environment
20131118 21:32:45 <rmk0> sigh
20131118 21:33:43 <dmlloyd> be sure to also give -e dlopen+dlsym
20131118 21:33:47 <rmk0> wow... it actually receives SIGSEGV when run under ltrace
20131118 21:34:05 <dmlloyd> interesting, maybe the compiler interferes with it
20131118 21:34:10 <dmlloyd> might want to give -Xint to the JVM
20131118 21:35:12 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl_ltrace2.txt
20131118 21:35:47 <rmk0> not exactly enlightening
20131118 21:36:17 <rmk0> trying to see if there's a way to prevent it truncating strings like that
20131118 21:36:31 <dmlloyd> what JVM is this?
20131118 21:36:44 <rmk0> openjdk 7
20131118 21:36:51 <rmk0> java version "1.7.0_45"
20131118 21:36:51 <rmk0> OpenJDK Runtime Environment (IcedTea 2.4.3) (ArchLinux build 7.u45_2.4.3-1-x86_64)
20131118 21:36:54 <rmk0> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
20131118 21:37:05 <dmlloyd> it seems to look for JNI_OnLoad but it's not doing a dlsym to fetch the other symbols
20131118 21:37:28 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl_ltrace3.txt
20131118 21:37:34 <rmk0> same thing without truncated strings
20131118 21:41:34 <dmlloyd> does libnativewindow_x11.so link against libgluegen-rt.so or any other JNI lib?
20131118 21:42:08 <rmk0> http://waste.io7m.com/2013/11/18/ldd.txt
20131118 21:42:11 <rmk0> appears not
20131118 21:43:43 <dmlloyd> it looks as if it is not even attempting to load symbols from that library
20131118 21:44:03 <dmlloyd> or any other library for that matter
20131118 21:45:09 <rmk0> how d'you mean?
20131118 21:45:32 <rmk0> i mean... plenty of dlsym calls for the other natives
20131118 21:46:08 <dmlloyd> right but it's not even trying to load initialize0
20131118 21:46:16 <dmlloyd> perhaps it wasn't associated with the right class loader
20131118 21:46:46 <dmlloyd> such that the library is there, but the class loader can't see any symbols because the library belongs to someone else
20131118 21:47:12 <rmk0> wasn't this touched upon earlier?
20131118 21:47:22 <rmk0> due to the extra isolation that ceylon imposes
20131118 21:47:44 <dmlloyd> yeah they use jboss modules, but perhaps they use it wrong
20131118 21:49:19 <dmlloyd> alesj: are you using it wrong? :)
20131118 21:49:59 <alesj> dmlloyd: we don't do anything with native libs beyond what the Modules already do
20131118 21:50:14 <alesj> dmlloyd: or define wrong? :-)
20131118 21:50:21 <dmlloyd> what about the JARs they are associated with?
20131118 21:50:33 <alesj> the modules or libs?
20131118 21:50:41 <dmlloyd> the modules
20131118 21:51:21 <dmlloyd> the module loads the JARs and it must also load the native libraries
20131118 21:51:28 <dmlloyd> the same module
20131118 21:51:35 <alesj> https://github.com/ceylon/ceylon-runtime/blob/master/impl/src/main/java/ceylon/modules/jboss/runtime/CeylonModuleLoader.java
20131118 21:51:52 <dmlloyd> so either it must be the same resource loader that loads the JARs, or you must add a resource loader for the native bits
20131118 21:52:09 <alesj> i guess we don't add native bits?
20131118 21:52:36 <rmk0> dmlloyd: i'm not sure if you missed the parts about how libraries are loaded by JOGL
20131118 21:52:42 <rmk0> i think you came in afterwards
20131118 21:53:04 <rmk0> they're unpacked from the jar files into a temporary directory at runtime
20131118 21:53:07 <dmlloyd> it shouldn't matter as long as they are loaded in the JARs that linked against them
20131118 21:53:31 <sgothel> http://jogamp.org/jogl/www/ <- Added J4K and Unlicense (Tools/Libraries ..)
20131118 21:53:32 <dmlloyd> I'm not sure whether the default resource loader allows absolute module paths though
20131118 21:56:32 <alesj> dmlloyd: what would we have to do in Ceylon module loader to support natibe libs?
20131118 21:56:41 <alesj> i thought this is done by default
20131118 21:56:43 <dmlloyd> have a resource loader that maps it
20131118 21:56:54 <dmlloyd> the default module loader looks for native libs along side the JARs
20131118 21:56:55 <alesj> such as lib/ ?
20131118 21:57:04 <alesj> default module loader?
20131118 21:57:13 <alesj> LocalModuleLoader?
20131118 21:57:15 <dmlloyd> yes the one we use everywhere except for in ceylon
20131118 21:57:16 <dmlloyd> yes
20131118 21:57:58 <dmlloyd> hey rmk0, want to try one more test?
20131118 21:58:08 <dmlloyd> no traces or anything
20131118 21:58:11 <rmk0> can do
20131118 21:58:35 <alesj> dmlloyd: where does it do that? https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/org/jboss/modules/LocalModuleLoader.java
20131118 21:58:39 <dmlloyd> just try your simple test program except instead of "java -classpath blah com.Whatever" do "java -jar path/to/jboss-modules.jar -classpath blah com.Whatever"
20131118 21:58:53 <dmlloyd> that will tell us whether jboss modules is blocking absolute library paths
20131118 21:59:01 <rmk0> i'm actually running the ceylon command line tool
20131118 22:00:12 <rmk0> will attempt to decipher
20131118 22:00:13 <dmlloyd> yeah you might have to grab jboss-modules.jar out of maven or something
20131118 22:00:26 <rmk0> looks like org.jboss.modules-1.1.3.GA.jar is included
20131118 22:00:37 <alesj> it should be in ceylon repo
20131118 22:00:42 <rmk0> yep
20131118 22:01:15 <rmk0> the command ceylon runs is:
20131118 22:01:19 <rmk0> /usr/lib/jvm/java-7-openjdk/bin/java -Dcom.redhat.ceylon.common.tool.terminal.width=195 -Dcom.redhat.ceylon.common.tool.progname=ceylon -jar /home/m0/var/tmp/ceylon-1.0.0/bin/../lib/ceylon-bootstrap.jar run --define java.awt.headless=true --rep ./jogamp com.io7m.joglexample
20131118 22:01:26 <rmk0> what was it you wanted me to change it to?
20131118 22:01:51 <dmlloyd> don't run the ceylon test
20131118 22:01:56 <dmlloyd> run that simple java program you wrote
20131118 22:02:05 <rmk0> ah, right, i see
20131118 22:02:14 <rmk0> yes, sorry, misunderstood what you mean
20131118 22:03:42 <dmlloyd> it might not actually be an adequate test given the ltrace output though, you might actually have to try to access a symbol
20131118 22:05:06 <rmk0> am almost certain i shouldn't be seeing this: http://waste.io7m.com/2013/11/18/testdl_out.txt
20131118 22:05:24 <rmk0> that's with TestDL.class in the current directory, and: java -jar ~/var/tmp/ceylon-1.0.0/repo/org/jboss/modules/1.1.3.GA/org.jboss.modules-1.1.3.GA.jar -cp . TestDL
20131118 22:05:56 <rmk0> oh dear, TestDL is in the "testdl" package, isn't it...
20131118 22:05:59 * rmk0 kicks self
20131118 22:06:14 <rmk0> and to answer your question...
20131118 22:06:31 <rmk0> http://waste.io7m.com/2013/11/18/testdl_out2.txt
20131118 22:06:35 <rmk0> seems like it is blocking them, yes
20131118 22:07:27 <dmlloyd> hmm that is a different exception
20131118 22:08:16 <rmk0> ugh, the last ceylon run unlinked the library
20131118 22:08:28 <rmk0> re-ran with the new path and it doesn't appear to be blocked after all
20131118 22:08:55 <rmk0> perhaps i shouldn't write these tests against transient temporary files :)
20131118 22:12:13 <dmlloyd> ha
20131118 22:13:58 <alesj> dmlloyd: so it's CeylonModuleLoader?
20131118 22:18:26 * hija (~hija@anon) has joined #jogamp
20131118 22:22:20 <alesj> specBuilder.addResourceRoot(new ResourceLoaderSpec(new NativeLibraryResourceLoader(new File(rootPath, "lib")), PathFilters.rejectAll()));
20131118 22:22:26 <alesj> dmlloyd: ^^ missing this?
20131118 22:23:18 <monsieur_max> sgothel: found a strange thing while playing a video with no sound on it
20131118 22:23:49 <monsieur_max> i removed the sound of the video using avconv / ffmpeg
20131118 22:24:13 <monsieur_max> the no sound video plays at high speed
20131118 22:24:43 <monsieur_max> with glmediaplayer
20131118 22:24:55 <monsieur_max> i tested the no sound video in vlc, plays at right speed
20131118 22:28:11 <alesj> dmlloyd: but wouldn't that mean that the only way to find a native lib for the module is to place it into <MODULE_ROOT>/lib?
20131118 22:39:54 <alesj> dmlloyd: ^ ?
20131118 22:48:32 <dmlloyd> yes alesj, so if you want to support this use case you need to do something different
20131118 22:55:15 <alesj> dmlloyd: any idea what / how different?
20131118 22:55:46 <dmlloyd> yes alesj
20131118 22:55:57 <alesj> ok, i'm all ears :-)
20131118 22:56:04 <dmlloyd> but I don't have time to walk you through the last hour of conversation
20131118 22:56:19 <dmlloyd> I just did that with my 8 year old with her math homework :)
20131118 22:56:25 <dmlloyd> now I have to make dinner for these kids
20131118 22:56:38 <dmlloyd> just implement loadLibrary rightly
20131118 22:56:59 <alesj> in which class?
20131118 22:57:02 <alesj> overriding what?
20131118 23:04:46 <alesj> dmlloyd: but it looks like ClassLoader::loadLibrary already fallbacks to sys_paths
20131118 23:05:11 <alesj> shouldn't that then be fine, if they place the native libs into sys_paths = initializePath("sun.boot.library.path");
20131118 23:05:28 <alesj> or usr_paths = initializePath("java.library.path");
20131118 23:05:42 <alesj> rmk0, sgothel ^^
20131118 23:37:29 * alesj (~alesj@anon) Quit (Quit: Leaving.)
20131118 23:40:11 * monsieur_max (~maxime@anon) has left #jogamp
20131119 00:27:47 * kermyt (~kermyt@anon) Quit (Ping timeout: 272 seconds)
20131119 00:30:40 * kermyt (~kermyt@anon) has joined #jogamp
20131119 00:32:33 <dmlloyd> in your resource loader alesj
20131119 00:32:35 <dmlloyd> sheesh
20131119 00:32:44 <dmlloyd> gone of course
20131119 00:34:47 <sgothel> .. hope 'that' loader also takes care of making a copy of he native libs, as I pointed our much earlier (CL req. unique file location) ..
20131119 00:35:52 <sgothel> thx dmlloyd for helping - I am just following things here regarding Ceylon .. hope Mark, and you guys can solve it
20131119 00:36:50 <dmlloyd> it's pretty simple to solve, ales just isn't trying
20131119 00:37:24 <sgothel> @Hija .. something to merge for SWT support ? Maybe .. Thur/Wed ?
20131119 00:37:43 <dmlloyd> anyway we'll give it another try tomorrow I guess
20131119 00:37:49 <dmlloyd> ttyl folks
20131119 00:37:51 * dmlloyd (~dmlloyd@anon) has left #jogamp
20131119 00:39:38 <hija> sgothel: Not really... I took a look yesterday and some other things surfaced
20131119 00:39:54 <hija> gonna have to look a bit deeper and don't have much time now :/
20131119 00:40:34 <sgothel> ok .. so we put it on ice for 2.2. .. sure you can add annotations in bug report, so I may pick it up - the unit test would be great though
20131119 00:40:40 <sgothel> i.e. for me to test
20131119 00:40:55 <hija> will try
20131119 00:41:02 <hija> :D
20131119 00:41:02 <sgothel> thank you
20131119 00:56:03 <sgothel> 2.1.3-rc-20131117 - http://jogamp.org/deployment/archive/master/gluegen_751-joal_502-jogl_1153-jocl_879-signed/
20131119 00:56:12 <sgothel> (maven repo .. etc etc)
20131119 00:56:17 <hharrison> I'll ssume my patches were OK?
20131119 00:56:22 <sgothel> yup
20131119 00:56:55 <sgothel> just a few AMD / NV Windows driver crashes .. every now and then - but unrelated to JOGL AFAIK :)
20131119 00:56:59 <hharrison> I've beaten on it all day and no deadlocks, so I'm finally happy with it
20131119 00:57:06 <sgothel> great stuff
20131119 00:57:24 <sgothel> finally non-blocking focus ..
20131119 01:08:05 <sgothel> good night
20131119 01:08:24 * sgothel (~sven@anon) Quit (Quit: Leaving.)
20131119 01:12:03 * rmk0 (~rmk0@anon) Quit (Ping timeout: 240 seconds)
20131119 01:17:27 * rmk0 (~rmk0@anon) has joined #jogamp
20131119 03:12:13 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131119 03:15:42 * xranby (~xranby@anon) has joined #jogamp
20131119 04:17:27 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20131119 04:30:36 * [Mike] (~Mike]@anon) Quit ()
20131119 04:35:27 * xranby (~xranby@anon) has joined #jogamp
20131119 04:52:25 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20131119 04:59:24 * xranby (~xranby@anon) has joined #jogamp
20131119 05:09:16 * [Mike] (~Mike]@anon) has joined #jogamp
20131119 07:22:34 * [Mike] (~Mike]@anon) Quit ()
20131119 08:08:28 * monsieur_max (~maxime@anon) has joined #jogamp
20131119 08:35:21 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20131119 08:36:48 * eclesia (~husky@anon) has joined #jogamp
20131119 08:36:54 <eclesia> good morning
20131119 08:45:36 * xranby (~xranby@anon) has joined #jogamp
20131119 08:56:44 * hija (~hija@anon) Quit (Quit: hija)
20131119 09:14:05 * RS2 (~randolf.s@anon) has joined #jogamp
20131119 09:16:38 * alesj (~alesj@anon) has joined #jogamp
20131119 09:16:44 <RS2> How do I compile Gluegen/Jogl on Win7-64 for Win32-x86 (32Bit); MingW32/64 is installed, but a simple "ant" just builds the AMD64 variant...
20131119 09:41:45 * hija (~hija@anon) has joined #jogamp
20131119 11:09:12 <xranby> RS2: compile using ming 32 and use a 32bit jvm to run ant
20131119 11:09:26 <xranby> RS2: you can take a look at jogl/make/scripts/make.jogl.all.win32.bat
20131119 11:15:04 <RS2> Thank you.
20131119 11:25:11 * xranby (~xranby@anon) Quit (Ping timeout: 246 seconds)
20131119 11:39:22 * xranby (~xranby@anon) has joined #jogamp
20131119 11:55:17 <xranby> sgothel: https://gist.github.com/xranby/3e3b4ebd5b1fd67cef13 - sigsegv [libGL.so.1+0x6bf82] glXChooseVisual+0x6472 during GraphTextDemo applet window close on 32bit ubuntu 12.04 + icedtea-web using opengl 4.3 core profile 4.3.0 NVIDIA 319.32 drivers
20131119 11:57:37 <monsieur_max> xranby: i have a suggestion about GLMediaPlayer. I have an issue where I must force JavaSound rather than JOAL for audio. At the moment, looking at the source, I can't do that easily. I was about to override the initStreamImpl of FFMPEGMediaPlayer, but faces a lot of private members. My suggestion would be to create a kind of "initAudio" method that one can override.
20131119 11:58:18 <monsieur_max> or maybe you have a suggestion about how i can perform this :)
20131119 11:58:33 <monsieur_max> ( i must keep joal.jar in my classpath though )
20131119 12:00:53 <monsieur_max> copying and editing the relevant part of the class is a possibility but not quite elegant :)
20131119 12:01:31 <xranby> monsieur_max: personally i would add some way to pass an already initialized AudioSink to the FFMPEGMediaPlayer factory constructor in situations where you do not want to use the autodetection
20131119 12:01:55 <monsieur_max> good idea
20131119 12:05:10 <xranby> monsieur_max: not sure if it is a good idea because we really want the FFMPEGMediaPlayer to simply work... can you give my some info why the current implementation dont work for your usecase?
20131119 12:05:34 <xranby> monsieur_max: ideally you simply use the GLMediaPlayer and it simply work on all platforms
20131119 12:05:49 <monsieur_max> xranby: sure, i totally understand
20131119 12:06:29 <monsieur_max> my case is that i use a library called SoundSystem that already relies on JOAL and it seems that there is a kind of conflict preventing using both of them
20131119 12:06:54 <monsieur_max> ( soundsystem and glmediaplayer )
20131119 12:07:07 <xranby> what kind of conflict do you see?
20131119 12:07:49 <xranby> openal to my knowledge support that one application uses two openal contexts..
20131119 12:07:54 * RS2 (~randolf.s@anon) Quit (Quit: Verlassend)
20131119 12:08:27 <monsieur_max> well i still have to investigate on this topic but it's taking me a lot of time and i was looking for a quick solution :)
20131119 12:09:02 <monsieur_max> the issue seems to be that soundsystem can't work after glemediaplayer has started to use openAL
20131119 12:09:30 <monsieur_max> i've got bunch of openAL errors "Invalid_operation"
20131119 12:10:06 <monsieur_max> so, my dirty workaround would have been to use javasound for mediaplayer
20131119 12:10:16 <monsieur_max> hence the suggestion
20131119 12:11:06 <xranby> most likely one of the librarys forget to make its openal context active
20131119 12:11:29 <monsieur_max> mmmh i'll investigate this then
20131119 12:11:39 <monsieur_max> thanks for the tip
20131119 12:12:16 <xranby> all al* functions operate on the current context
20131119 12:12:44 <xranby> thus you make sure that the two librarys are not used in parallel for your application
20131119 12:13:41 <monsieur_max> yes that's something i've already done, but it fails when glmediaplayer has finished and when i want to use again soundsystem... this could totally be the problem
20131119 12:14:03 <monsieur_max> gosh, it seems so obvious now
20131119 12:26:10 * alesj (~alesj@anon) Quit (Quit: Leaving.)
20131119 12:43:42 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20131119 12:45:42 * alesj (~alesj@anon) has joined #jogamp
20131119 13:21:16 * xranby (~xranby@anon) has joined #jogamp
20131119 14:08:11 <alesj> rmk0: yt?
20131119 14:08:45 <rmk0> 'lo
20131119 14:08:55 <alesj> rmk0: I have a Ceylon test setup
20131119 14:09:09 <alesj> and I'm now wondering how to invoke some native method
20131119 14:09:13 <alesj> in jocl.jar
20131119 14:09:35 <alesj> i've loaded jocl native lib
20131119 14:09:39 <rmk0> i'm not too familiar with jocl... does it have to be jocl specifically?
20131119 14:09:42 <alesj> no
20131119 14:09:49 <rmk0> probably easier to use jogl
20131119 14:09:53 <alesj> ok
20131119 14:09:58 <alesj> which native lib to load then?
20131119 14:10:27 <rmk0> hm... when you say load... how are you loading them?
20131119 14:10:33 <alesj> System.loadLibrary("jogl");
20131119 14:10:37 <alesj> it used to be jocl
20131119 14:10:39 <rmk0> ah, right
20131119 14:10:55 <alesj> Skywalker:native_lib alesj$ cd jogamp-all-platforms/lib/macosx-universal/
20131119 14:10:55 <alesj> README.txt libjoal.jnilib libjogl_cg.jnilib libjogl_mobile.jnilib libnativewindow_macosx.jnilib libopenal.1.15.1.dylib libopenal.dylib
20131119 14:10:55 <alesj> libgluegen-rt.jnilib libjocl.dylib libjogl_desktop.jnilib libnativewindow_awt.jnilib libnewt.jnilib libopenal.1.dylib
20131119 14:11:32 <alesj> rmk0: openal perhaph?
20131119 14:11:45 <alesj> i need a way then to load a Java class
20131119 14:11:49 <alesj> and call its native method
20131119 14:12:08 <rmk0> i think it may be easiest to load libjogl_desktop.jnilib, libnativewindow_macosx.jnilib
20131119 14:12:15 <rmk0> and then attempt to call GLProfile.getDefault()
20131119 14:12:28 <rmk0> that'll definitely call some native methods
20131119 14:12:39 <alesj> do I need to load both?
20131119 14:12:58 <rmk0> i think so... i'm not very familiar with the native libraries as it's never necessary to load them manually
20131119 14:13:24 <alesj> should I just call GLProfile::getDefault?
20131119 14:13:30 <alesj> and that takes care of native lib loading?
20131119 14:14:28 <rmk0> yes, that should do it
20131119 14:14:58 <rmk0> have you seen the test project?
20131119 14:15:06 <alesj> Skywalker:Downloads alesj$ jar -tf ~/maven_libs/org/jogamp/jogl/jogl/2.1.2/jogl-2.1.2.jar
20131119 14:15:06 <alesj> META-INF/
20131119 14:15:06 <alesj> META-INF/MANIFEST.MF
20131119 14:15:09 <alesj> is this expected?
20131119 14:15:11 <rmk0> i forget who's seen what over the past few days
20131119 14:15:30 <rmk0> ah, you'll want jogl-all-2.1.2.jar
20131119 14:15:44 <rmk0> sorry, that's a maven side-effect... it requires jar files for each maven module
20131119 14:15:54 <rmk0> we had to publish empty jars for that one
20131119 14:16:25 <rmk0> the ceylongl-004.7z actually has a repos already set up
20131119 14:17:00 <rmk0> http://waste.io7m.com/2013/11/18/ceylongl-004.7z
20131119 14:18:08 <alesj> rmk0: java.lang.NoClassDefFoundError: jogamp/opengl/Debug
20131119 14:18:11 <alesj> where is this class?
20131119 14:18:33 <rmk0> ...
20131119 14:19:08 <rmk0> one sec...
20131119 14:19:57 <rmk0> is in jogl-all-2.1.2.jar
20131119 14:21:03 <rmk0> a typical opengl desktop program will only use these jars: http://waste.io7m.com/2013/11/19/layout.txt
20131119 14:21:20 <rmk0> and even then, the "natives" jars aren't on the classpath, as they're loaded by the custom classloader
20131119 14:21:35 <rmk0> so it should really just be gluegen-rt-2.1.2.jar and jogl-all-2.1.2.jar
20131119 14:22:43 <alesj> hmmm, yes, it's in -all
20131119 14:22:46 <alesj> but … Caused by: java.lang.ClassNotFoundException: jogamp.opengl.Debug from [Module "org.jogamp.jogl:jogl-all:2.1.2" from Ceylon ModuleLoader: RootRepositoryManager: FileContentStore: /Users/alesj/.ceylon/cache]
20131119 14:22:46 <alesj> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
20131119 14:23:40 <rmk0> what's giving you that error?
20131119 14:23:43 <rmk0> ceylon command line?
20131119 14:23:46 <alesj> my test
20131119 14:24:02 <rmk0> running from an IDE?
20131119 14:24:06 <alesj> I'm adding a test into Runtime
20131119 14:24:13 <alesj> yes, from IntelliJ
20131119 14:24:31 <alesj> but it's using proper Ceylon runtime underneath
20131119 14:25:08 <rmk0> the only thing i can think of is that it can't see the jogamp repository, for whatever reason
20131119 14:25:19 <rmk0> assuming you're using the one from ceylongl-004.7z
20131119 14:25:32 <alesj> no, pulled from Maven Central
20131119 14:25:55 <alesj> using Ceylon + Maven interop
20131119 14:26:08 <rmk0> sorry, i'm horribly confused... how are you getting it to see maven jar files?
20131119 14:26:23 <rmk0> i had to write a jboss module description to do that
20131119 14:26:41 <alesj> you can import Maven stuff directly
20131119 14:26:50 <alesj> @Module(
20131119 14:26:50 <alesj> name = "org.jogl.ceylon", version = "1.0.0",
20131119 14:26:50 <alesj> dependencies = {@Import(name = "org.jogamp.jogl:jogl-all", version = "2.1.2")})
20131119 14:26:50 <alesj> public class module_ {
20131119 14:28:06 <rmk0> the dependency looks right
20131119 14:29:27 <rmk0> well, i'm mystified!
20131119 14:32:31 <xranby> rmk0: alesj: first time i look at ceylon.. is the dependencies resolved from maven central?
20131119 14:33:12 <rmk0> xranby: well the issue i ran into is that it doesn't resolve transitive dependencies, like maven does, so i had to write a module description that explicitly depended on the native jars
20131119 14:33:21 <alesj> xranby: could be, if you add Mvn/Aether Ceylon repo into config
20131119 14:33:26 <rmk0> but it is at least able to pull jar files that you depend on directly
20131119 14:33:34 <alesj> rmk0: i think I know what the problem is ...
20131119 14:33:50 <rmk0> alesj: what's it?
20131119 14:34:47 <xranby> i guess you need to add gluegen-rt dependency as well?
20131119 14:35:00 <alesj> it's missing some jogl common
20131119 14:35:48 <rmk0> you sure? there really isn't anything outside of jogl-all
20131119 14:36:24 <rmk0> the other available jogl jars are "atomic" jars, that are combined to produce jogl-all
20131119 14:36:28 <alesj> rmk0: Debug depend on some jogl/common/PropertyAccess
20131119 14:36:31 <rmk0> so jogl-all is basically the superset of them all
20131119 14:36:34 <alesj> which is then missing
20131119 14:36:58 <alesj> Skywalker:Downloads alesj$ jar -tf ~/maven_libs/org/jogamp/jogl/jogl-all/2.1.2/jogl-all-2.1.2.jar | grep PropertyAccess
20131119 14:36:58 <alesj> Skywalker:Downloads alesj$
20131119 14:37:00 <rmk0> that's in gluegen-rt
20131119 14:37:27 <alesj> so jogl-all depends on gluegen-rt?
20131119 14:37:37 <alesj> what's the full Maven name for gluegen-rt?
20131119 14:37:37 <rmk0> yeah, those two jar files, as i said
20131119 14:38:01 <rmk0> org.jogamp.gluegen:gluegen-rt:2.1.2
20131119 14:38:32 <rmk0> http://jogamp.org/wiki/index.php/Maven
20131119 14:38:38 <rmk0> that explains a bit about how the packages fit together
20131119 14:44:15 <alesj> rmk0: https://gist.github.com/alesj/7546370
20131119 14:44:41 <rmk0> yeah, that's the error i get
20131119 14:44:55 <alesj> do I need to add that headless stuff?
20131119 14:44:59 <rmk0> if you use -Djava.awt.headless=true, you'll get the libnativewindow_x11.so unsatisfied link error instead
20131119 14:45:18 <rmk0> sgothel recommended focusing on the latter first, so yeah, would use that property
20131119 14:46:08 <alesj> rmk0: https://gist.github.com/alesj/7546398
20131119 14:46:09 <alesj> this?
20131119 14:46:32 <rmk0> ah, you're on OS X, so it's a different error
20131119 14:46:36 <rmk0> but it's the same root issue
20131119 14:46:48 <rmk0> i'm on linux here, so the error appears in libnativewindow_x11.so
20131119 15:07:06 <alesj> rmk0: hmmm, my mapped Lib name ends with dylib
20131119 15:07:06 <alesj> 4:06
20131119 15:07:06 <alesj> where all native libs in that folder end with jnilib
20131119 15:07:06 <alesj> 4:06
20131119 15:07:06 <alesj> hence it doesn't find them
20131119 15:08:16 <rmk0> hm
20131119 15:09:38 <rmk0> it seems that the native libraries are all named ".dll" when they're in the native jar files
20131119 15:09:49 <rmk0> so the classloader renames them to the correct platform-specific suffix on unpacking
20131119 15:10:06 <rmk0> (you'll have to bear with me, i'm not familiar with this part of jogl)
20131119 15:19:09 <alesj> rmk0: do I need those other OS-specific jars or not?
20131119 15:19:17 <alesj> Catched FileNotFoundException: /Users/alesj/.m2/repository/org/jogamp/gluegen/gluegen-rt/2.1.2/gluegen-rt-2.1.2-natives-macosx-universal.jar (No such file or directory), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/Users/alesj/.m2/repository/org/jogamp/gluegen/gluegen-rt/2.1.2/gluegen-rt-2.1.2.jar!/com/jogamp/common/os/Platform.class, nativeJarBaseName gluegen-rt-2.1.2-natives-macosx-universal.jar):
20131119 15:19:18 <alesj> Catched FileNotFoundException: /Users/alesj/.m2/repository/org/jogamp/jogl/jogl-all/2.1.2/jogl-all-2.1.2-natives-macosx-universal.jar (No such file or directory), while addNativeJarLibsImpl(classFromJavaJar class jogamp.nativewindow.NWJNILibLoader, classJarURI jar:file:/Users/alesj/.m2/repository/org/jogamp/jogl/jogl-all/2.1.2/jogl-all-2.1.2.jar!/jogamp/nativewindow/NWJNILibLoader.class, nativeJarBaseName jogl-all-2.1.2-natives-macosx-universal.jar): [ fil
20131119 15:19:18 <alesj> Catched IOException: TempJarCache: addNativeLibs: jar:file:/Users/alesj/.m2/repository/org/jogamp/jogl/jogl-all/2.1.2/jogl-all-2.1.2-natives-macosx-universal.jar!/, previous load attempt failed, while addNativeJarLibsImpl(classFromJavaJar class jogamp.nativewindow.NWJNILibLoader, classJarURI jar:file:/Users/alesj/.m2/repository/org/jogamp/jogl/jogl-all/2.1.2/jogl-all-2.1.2.jar!/jogamp/nativewindow/NWJNILibLoader.class, nativeJarBaseName jogl-all-2.1.2-nati
20131119 15:19:30 <alesj> ups … flood … sorry
20131119 15:19:34 <rmk0> hehe
20131119 15:19:40 <rmk0> you do need the natives for your platform
20131119 15:20:34 <rmk0> like i said, a typical opengl desktop program will be distributed with all of the following: http://waste.io7m.com/2013/11/19/layout.txt
20131119 15:21:08 <rmk0> with only gluegen-rt-2.1.2.jar and jogl-all-2.1.2.jar appearing on the classpath, and the associated native jars being present in the same directory so that jogl can find them
20131119 15:21:38 <rmk0> is basically why the maven packages are organized the way they are, so that the native jars are downloaded into the same directory in the repos
20131119 15:22:00 <alesj> yup
20131119 15:24:28 <alesj> rmk0: ok, manually copied those jars, helped
20131119 15:24:33 <alesj> but I still get the same error
20131119 15:24:44 <alesj> … it removed the flood from before ...
20131119 15:25:04 <rmk0> the same unsatisfied link error?
20131119 15:25:07 <rmk0> or ... something else
20131119 15:25:09 <alesj> yes
20131119 15:25:14 <rmk0> right, yeah
20131119 15:35:12 <alesj> hmmm ...
20131119 15:35:35 <alesj> rmk0: after adding this specific native jars
20131119 15:35:43 <alesj> it's by-passes Ceylon's classloading layer
20131119 15:36:03 <rmk0> yep, think so
20131119 15:36:37 <rmk0> sgothel mentioned that the current code assumes that the immediate parent of the jogl classloader is the system classloader
20131119 15:37:57 <alesj> nope, in our case parent is null
20131119 15:38:03 <rmk0> right
20131119 15:38:22 <rmk0> he also mentioned that on android, a launcher is used
20131119 15:38:24 * rmk0 locates
20131119 15:40:33 <rmk0> http://jogamp.org/log/irc/jogamp_20131117152553.html
20131119 15:40:47 <rmk0> starting at 17:53
20131119 15:41:46 <rmk0> oh, that was when you were mentioned
20131119 15:42:00 <rmk0> not sure how much gavinking told you before calling you in.. presumably you've already seen all that backlog
20131119 15:42:11 <alesj> how does that TempXX class load these native jars?
20131119 15:42:39 <rmk0> it basically unpacks them to a temporary directory and then calls loadLibrary on them by absolute path
20131119 15:43:15 <rmk0> http://waste.io7m.com/2013/11/17/output.txt
20131119 15:43:32 <rmk0> if you add "-Djogamp.debug=all" to your program, you'll get all that debug output
20131119 15:43:37 <rmk0> so can see what the classloader is trying to do
20131119 15:45:00 <alesj> rmk0: the class that does this is TempJarCache?
20131119 15:45:11 <rmk0> yep
20131119 15:47:13 <alesj> http://grepcode.com/file/repo1.maven.org/maven2/org.jogamp.gluegen/gluegen-rt-android/2.0.2-rc12/com/jogamp/common/util/cache/TempJarCache.java
20131119 15:47:24 <alesj> rmk0: which code calls System::loadLibrary?
20131119 15:48:35 <rmk0> JNILibLoaderBAse
20131119 15:48:44 <rmk0> .. JNILibLoaderBase
20131119 15:48:52 <alesj> which is in gluegen as well?
20131119 15:49:12 <rmk0> yep
20131119 15:49:38 <rmk0> you should realize, some of this stuff i'm seeing for the first time
20131119 15:49:48 <rmk0> sgothel generally knows much more about this part of the code, but he's away until thursday
20131119 15:50:48 * xranby (~xranby@anon) Quit (Ping timeout: 240 seconds)
20131119 15:50:57 <rmk0> you can see that, for example, NEWT implements a NWJNILibLoader class that extends JNILibLoaderBase
20131119 15:51:15 <rmk0> it basically calls JNILibLoaderBase methods with: final String libName = "nativewindow_"+ossuffix ;
20131119 15:53:42 <rmk0> http://jogamp.org/git/?p=jogl.git;a=blob;f=src/nativewindow/classes/jogamp/nativewindow/NWJNILibLoader.java;h=e7eb137562093dfffb4fcafaa8e336cb05677c78;hb=291c5ac4f0f55807172d1036e7c746db9af7ceec
20131119 16:06:15 * xranby (~xranby@anon) has joined #jogamp
20131119 16:11:42 * [Mike] (~Mike]@anon) has joined #jogamp
20131119 16:14:12 <alesj> rmk0: I;m out of ideas
20131119 16:14:21 <alesj> it looks like we're loading the lib just fine
20131119 16:14:27 <alesj> so it must be something on your side
20131119 16:16:18 <rmk0> dmlloyd mentioned:
20131119 16:16:21 <rmk0> 21:46:16 < dmlloyd> perhaps it wasn't associated with the right class loader
20131119 16:16:21 <rmk0> 21:46:46 < dmlloyd> such that the library is there, but the class loader can't see any symbols because the library belongs to someone else
20131119 16:17:03 <rmk0> it does claim to have loaded the library, but then can't resolve symbols
20131119 16:18:40 <alesj> the classloader is the right one
20131119 16:19:05 <alesj> as the System::load is invoked from the class, which was loaded by our ModuleCL
20131119 16:19:20 <rmk0> weird
20131119 16:21:43 <alesj> rmk0: which class then uses / invokes the native method?
20131119 16:22:39 <rmk0> jogamp.nativewindow.x11.X11Util
20131119 16:22:47 <rmk0> attempts to call initialize0
20131119 16:23:01 <alesj> which is in jogl-all?
20131119 16:23:23 <alesj> rmk0: ^
20131119 16:23:35 <rmk0> checking... i think so, just want to be sure
20131119 16:23:47 <rmk0> yep
20131119 16:24:18 <rmk0> specifically initSingleton()
20131119 16:24:26 <alesj> ah, ok, this explains it then
20131119 16:25:11 <alesj> rmk0: lib is loaded in gluegen-rt module, where native method is called in jogl-all module
20131119 16:25:16 <alesj> 2 diff classloaders
20131119 16:25:33 <rmk0> aha!
20131119 16:26:33 <rmk0> what's the correct way to deal with this?
20131119 16:28:11 <alesj> load it from the right classloader / module :-)
20131119 16:29:24 <alesj> e.g. perhaps create an uber jar
20131119 16:29:31 <alesj> jogl-all + gluegen-rt
20131119 16:29:34 <alesj> and make it into a module
20131119 16:29:41 <alesj> then they will have a single CL
20131119 16:29:50 <alesj> rmk0: ^
20131119 16:31:23 <rmk0> unfortunately that'll then mean that the classloader won't be able to locate the natives
20131119 16:31:39 <rmk0> actually... may be able to work around that
20131119 16:31:47 <rmk0> it uses the name of the jar to find the other native jars
20131119 16:32:17 <alesj> uh, auch
20131119 16:32:52 <rmk0> will attempt it shortly
20131119 16:32:57 <rmk0> thanks for the time!
20131119 16:33:04 <rmk0> am amused at how this has escalated
20131119 16:33:14 <rmk0> "i'll try writing a little opengl example..."
20131119 16:33:19 <rmk0> three days later and a team of specialists...
20131119 16:33:54 <rmk0> if it works, it should put gavinking's mind at rest regarding the handling of the SDK natives, hopefully
20131119 16:33:55 <alesj> rmk0: dml suggest you guys rather try "normal" Syste::loadLibrary
20131119 16:33:59 <alesj> then the System::load
20131119 16:34:12 <alesj> as then we could handle that in Ceylon's CL
20131119 16:34:21 <rmk0> ok
20131119 16:34:29 <alesj> otherwise it by-passes CL::findLibrary mechanism
20131119 16:59:39 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131119 17:03:18 * eclesia (~husky@anon) Quit (Quit: Leaving.)
20131119 17:40:11 * alesj (~alesj@anon) Quit (Quit: Leaving.)
20131119 17:53:40 * monsieur_max (~maxime@anon) has joined #jogamp
20131119 18:30:50 * hija (~hija@anon) Quit (Quit: hija)
20131119 19:40:58 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131119 19:47:22 * xranby (~xranby@anon) has joined #jogamp
20131119 19:49:44 <monsieur_max> xranby: you were right :) it was an issue regarding multiple AL Context :)
20131119 19:50:23 <monsieur_max> xranby: again, sir, I thank you in a very formal way
20131119 20:55:33 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131119 21:01:06 * hija (~hija@anon) has joined #jogamp
20131119 21:21:03 * void256 (~void@anon) has joined #jogamp
20131119 21:23:45 * Eclesia (~eclesia@anon) has joined #jogamp
20131119 21:23:49 <Eclesia> hi
20131119 21:24:55 <Eclesia> Does someone has a good doc on DXT/DDS image format ? most of what I found is msdn stuffs, descriptive, but not very tecnical
20131119 21:25:15 <Eclesia> and dds is a big mess, so much variations :/
20131119 21:36:58 * xranby (~xranby@anon) has joined #jogamp
20131119 21:44:07 <Eclesia> hi xranby
20131119 21:44:41 * xranby_ac100 (~xranby@anon) has joined #jogamp
20131119 21:44:49 <xranby_ac100> Eclesia: hi
20131119 21:45:47 <Eclesia> have you finaly made some nice screenshots with my project ?
20131119 21:50:18 <xranby_ac100> Eclesia: i have mostly been stressing your project.. testing it on different devices.
20131119 21:50:50 <Eclesia> aouch :/
20131119 21:51:01 <Eclesia> I don't think it behaves well
20131119 21:53:02 <xranby_ac100> some common opengl pitfalls found.. like the glsl shader code fails to compile on newer opengl 4.3 drivers
20131119 21:53:49 <xranby_ac100> that can be solved by using a class that customizes the shader for different glsl versions
20131119 21:54:02 <xranby_ac100> there is one inside the jogl project
20131119 21:54:16 <Eclesia> hm what kind of code qasn't working ?
20131119 21:54:20 <Eclesia> wasn't ?
20131119 21:54:52 <Eclesia> as far as i know, my shaders are very basic
20131119 21:56:10 <xranby_ac100> the driver simply refused to compile the shader.. let me give you a log
20131119 22:02:49 <xranby_ac100> Eclesia: https://gist.github.com/xranby/0d65c92872c7a1522a8b
20131119 22:03:25 <Eclesia> that one is normal
20131119 22:03:34 <Eclesia> GL4 is the baseline for the engine
20131119 22:04:25 <Eclesia> I don't intend to support lower versions, or perhaps only GL 1.1
20131119 22:05:50 <Eclesia> or if someone else want to do the work ^^
20131119 22:10:14 <xranby_ac100> the jogamp solution is to let the ShaderCode defaultShaderCustomization() function rewrite the shaders to stay compatible with new drivers
20131119 22:11:20 <Eclesia> you already know I use only the minimum classes from jogl . public domain
20131119 22:18:47 <Eclesia> (it's not that I dislike jogl, but the objective is a full public domain lib)
20131119 22:19:33 <xranby_ac100> ok, the code will then run when mesa update their drivers to support opengl 4.3 glsl 4.00 on AMD gpus
20131119 22:20:26 <xranby_ac100> i have a nvidia system at work where edit3d runs
20131119 22:21:08 <Eclesia> I have an nvidia gtx at home and a amd quadro at work
20131119 22:21:26 <Eclesia> have some ugly lines artifacts on the quadro but it works
20131119 22:21:47 <Eclesia> amd firegl*
20131119 22:27:46 <xranby_ac100> Eclesia: hehe.. i guess i am the retro computing opengl dude.. testing all jogl projects on linux opengl es 1 & 2 systems.. :)
20131119 22:29:02 <xranby_ac100> ... and mesa systems that currently implements opengl 3.1 core profile
20131119 22:29:32 <Eclesia> xranby_ac100: no problem. but I'm alone on the project, I can't spend all my time on opengl. I better focus on stuff like image reader,compressions,archive,.... stuffs which doesn't evolve every year
20131119 22:30:08 <Eclesia> by the time the project gets mature, I think the mesa driver will support GL4
20131119 22:37:12 <xranby_ac100> hopefully glsl spec will mature as well, khronos please stop replacing glsl keyword names :)
20131119 22:40:09 <Eclesia> I don't consider opengl to be mature yet ^^ . they need to write conformance tests. like we do in mapping specification
20131119 22:48:13 <rmk0> http://khronos.org/conformance
20131119 22:49:44 <Eclesia> :x
20131119 22:49:49 <Eclesia> my bad
20131119 22:49:58 <rmk0> i think it's a very recent development
20131119 22:50:19 <rmk0> doubt anyone conforms yet
20131119 22:51:24 <xranby_ac100> found this amusing: http://hackaday.com/2013/11/17/getting-a-shell-on-any-android-device/
20131119 22:53:48 <Eclesia> xranby_ac100: awesome, NSA will love it :D
20131119 22:59:26 <Eclesia> new record 95K lines of code, http://www.ohloh.net/p/unlicense-lib
20131119 23:02:58 <Eclesia> good night all ++
20131119 23:03:19 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20131119 23:08:28 * hija (~hija@anon) Quit (Quit: hija)
20131119 23:25:54 * monsieur_max (~maxime@anon) has left #jogamp
20131119 23:27:15 * hija (~hija@anon) has joined #jogamp
20131119 23:46:45 * xranby_ac100 (~xranby@anon) Quit (Remote host closed the connection)
20131120 00:54:52 * rmk0 (~rmk0@anon) Quit (Ping timeout: 272 seconds)
20131120 00:59:17 * hija (~hija@anon) Quit (Quit: hija)
20131120 02:08:25 * rmk0 (~rmk0@anon) has joined #jogamp
20131120 02:08:25 * rmk0 (~rmk0@anon) Quit (Changing host)
20131120 02:08:25 * rmk0 (~rmk0@anon) has joined #jogamp
20131120 02:29:46 * void256 (~void@anon) Quit (Remote host closed the connection)
20131120 05:05:53 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131120050553.html