#jogamp @ irc.freenode.net - 20131001 05:05:30 (UTC)

20131001 05:05:30 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20130930050530.html
20131001 05:05:30 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20131001050530.html
20131001 05:38:40 <sgothel> Bug 843: Remove Platform's requirement and use of TempJarCache.bootstrapNativeLib(), allowing versatile use of 1st native jar file (big-java-jar w/ big-native-jar)
20131001 05:42:43 <sgothel> http://jogamp.org/git/?p=gluegen.git;a=commit;h=506ae5e9fd258db7bfe737999e769477a32643a7
20131001 05:43:16 <sgothel> THANK YOU Xerxes for triaging this 'bug'.
20131001 05:53:43 <xranby_ac100> sgothel: Thank YOU, for prividing a fix! :D i will test this usecase later today
20131001 05:54:07 <xranby_ac100> providing
20131001 05:54:24 <sgothel> good to remove all these workaround, we previously needed .. but are no more required
20131001 05:54:57 <sgothel> testing test-2 of jar-in-jar .. manually now .. the URI regression
20131001 05:55:31 <sgothel> personally, I would recommend this method, since it maintains the identity of the jogamp modules -> better error tracking etc
20131001 05:55:31 * xranby_ac100 (~xranby@anon) Quit (Read error: Connection reset by peer)
20131001 05:56:26 * xranby_ac100 (~xranby@anon) has joined #jogamp
20131001 06:02:35 * xranby_ac100 (~xranby@anon) Quit (Ping timeout: 248 seconds)
20131001 06:08:37 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=844
20131001 06:08:45 <sgothel> (jar-in-jar regression)
20131001 07:15:23 * monsieur_max (~maxime@anon) has joined #jogamp
20131001 07:39:46 <xranby> sgothel: if we add a os.arch zip-folder to the native library file name then it would be possible to putt all the natives inside one jar directly
20131001 07:40:07 <sgothel> this would be abusive ..
20131001 07:40:27 <sgothel> and .. no, since we add the native suffix
20131001 07:41:37 <sgothel> so the native split, is still intended .. the discussion of a big-far-native-jar .. is something diff.
20131001 07:41:50 <sgothel> that would allow such thing ..
20131001 07:42:18 <xranby> -> jar:file:/somepath/onefatexclipsexportedjar.jar!/natives-linux-i586/
20131001 07:42:21 <sgothel> i.e. os.and.arch subfolder ..
20131001 07:42:22 <xranby> etc
20131001 07:43:57 <sgothel> w/ the eclipse way, ofc you can add all native jars anyways
20131001 07:44:23 <sgothel> but w/o using this eclipse 'magic' .. we would need to add os.and.arch separation within one jar file
20131001 07:44:27 <xranby> ? how the native library names will collide and override
20131001 07:44:52 <sgothel> you have the native jar files in the jar file
20131001 07:45:00 <sgothel> and he java jar files -> Test-2
20131001 07:45:06 <sgothel> which I fix now ..
20131001 07:45:32 <xranby> yes.. i agree what i suggest is to allow the "default" eclipse export native jar option
20131001 07:45:42 <sgothel> however .. we can think about a fat-native-jar ..
20131001 07:46:47 <xranby> other usecases that may need investigation is this "onejar" thing that some people use
20131001 07:47:20 <xranby> https://jogamp.org/bugzilla/show_bug.cgi?id=522#c2
20131001 07:48:00 <xranby> i wonder if peter is still around to test it
20131001 07:48:56 <xranby> http://one-jar.sourceforge.net/
20131001 07:51:37 <xranby> this should imho be supported by using the classloader in mode-2
20131001 07:54:20 <xranby> sgothel: cuttlefish work fine now using your fix for 843!
20131001 07:54:43 <xranby> cryobacterium: fixed ^
20131001 08:36:34 <sgothel> Bug 844 is fixed as well (jar-in-jar)
20131001 08:38:23 <sgothel> the problem w/ one single big-fat jar is that we are not aware of this fact .. and I am reluctant to attempt to load several resources just to peek in it ..
20131001 08:38:46 <sgothel> so at least a single big-fat-jar file usage would require the user to set a property
20131001 08:40:44 <sgothel> then we could prepend 'natives/os.and.arch/' to the jar root path, from which we extract native libraries ..
20131001 08:41:03 <sgothel> or imply 'os.and.arch' .. matter of tatse
20131001 08:41:06 <sgothel> *taste* :)
20131001 08:41:40 <xranby> any solution will do i think as long as the jar path is different for each native lib
20131001 08:42:04 <xranby> i dont know jar fashion :)
20131001 08:42:04 <sgothel> Q: why ?
20131001 08:42:30 <xranby> to support all in one jar without relying on classloaders we dont know about
20131001 08:42:42 <xranby> like eclipse magical calssloader
20131001 08:42:49 <sgothel> :)
20131001 08:45:40 <sgothel> well, I guess we could check whether the classloader of tested class knows about a folder 'native/os.and.arch' .. and if so .. extract native libs from there
20131001 08:46:12 <xranby> if so then pick natives/os.and.arch
20131001 08:46:15 <sgothel> this won't work w/ Eclipse's default one-jar .. since it will produce all native libs in the root folder
20131001 08:46:30 <sgothel> but w/ a custom one-jar builder (ant/jar) .. sure it will work
20131001 08:46:30 <xranby> to make the inside of the jar to look like the multi jar namespace
20131001 08:46:36 <sgothel> yes
20131001 08:46:53 <xranby> (10:46:50) sgothel: this won't work w/ Eclipse's default one-jar .. since it will produce all native libs in the root folder <-- wtf?!
20131001 08:46:54 <sgothel> big-jar namespace - yes
20131001 08:46:59 <xranby> it do?
20131001 08:47:05 <sgothel> I just checked ..
20131001 08:47:14 <xranby> thats crazy :)
20131001 08:47:23 <sgothel> it creates a one-jar file .. but native libs all in root-folder of jar
20131001 08:47:36 <sgothel> well .. they don't know about such concept ..
20131001 08:47:56 <sgothel> they use 'flat' jar (java+natives) for SWT for example
20131001 08:48:45 <sgothel> all this is to server customers of ours .. who like to do this .. against our recommendation, since the split java/native concept does scale best for networking
20131001 08:48:46 <xranby> thus the only way to support eclipse craze is to use really odd looking native lib names
20131001 08:48:49 <xranby> :(
20131001 08:49:14 <sgothel> I don't intend to specifically support Eclipse .. well, jar-in-jar work again ..
20131001 08:49:31 <sgothel> i.e. downloading a fat-jar .. is more expensive ..
20131001 08:49:48 <xranby> lib-os.and.arch-nativewindow_x11.so etc may solve eclipse crazyness
20131001 08:49:48 <sgothel> plus the whole repackaging removes our artifact information for error reports
20131001 08:50:06 <sgothel> I don't intend to change our whole deployment design for eclipse
20131001 08:50:20 <sgothel> i.e. our current native jars are compatible w/ JNLP
20131001 08:50:41 <sgothel> but yes .. it would do the trick ..
20131001 08:51:01 <sgothel> however .. users can easily add an ant recipe as well
20131001 08:51:34 <xranby> excellent, its good to have one example of a simple one jar solution that work
20131001 08:51:41 <xranby> that can be scripted during the build process
20131001 08:52:04 <sgothel> all natives: 3.0M
20131001 08:52:13 <xranby> not a big deal i say
20131001 08:52:22 <xranby> especially if we remove the 3mb uuntu fonts
20131001 08:52:25 <xranby> ubuntu
20131001 08:52:36 <xranby> from the jogl-all.jar
20131001 08:52:37 <sgothel> but multiple jar files are neither :)
20131001 08:52:58 <sgothel> i.e. are we solving a non-existing problem ?
20131001 08:53:52 <xranby> i belive people still like to use single jar deployment
20131001 08:53:56 <xranby> for some reason
20131001 08:54:02 <xranby> and this fixes it
20131001 08:54:11 <sgothel> nevertheless .. since I don't want to tell users what to do .. I will check such extension of namespace search .. if inexpensive .. will add
20131001 08:54:31 <sgothel> besides jar-in-jar .. (that classloader must be open-source as well)
20131001 08:54:59 <xranby> one-jar is opensource
20131001 08:55:00 <sgothel> the real problem I have .. is the removal of our artifacts
20131001 08:55:19 <sgothel> haven't looked into one-jar .. just a repackage script ? :)
20131001 08:55:29 <xranby> its a magical classloader thing
20131001 08:55:33 <sgothel> (i.e. a 3 line ant target)
20131001 08:55:37 <sgothel> ah
20131001 08:56:20 <sgothel> one-jar allows jar-in-jar ..
20131001 08:56:28 <sgothel> so it should work by now .. right ?
20131001 08:57:44 <sgothel> if not, I will fix that issue as well .. but I like to wait before I waste 2 hours of dealing w/ it :)
20131001 08:57:58 <sgothel> will check the big-fat-jar option now ..
20131001 09:05:50 <xranby> i can try use one-jar to package one of the jogamp junit tests
20131001 09:19:17 <xranby> one-jar is broken using 2.0.2 will not test using todays fixes
20131001 09:19:27 <xranby> i will *now* test
20131001 09:19:43 <sgothel> sure .. I assume same URI exception ..
20131001 09:23:52 <xranby> sgothel: this is the output using 2.0.2 https://gist.github.com/xranby/9c87ab55fa38fd1f652c
20131001 09:24:59 <xranby> i will now update the jogamp jars and retest
20131001 09:26:01 <sgothel> Catched FileNotFoundException: /movieplayer.jar .. hmm different ..
20131001 09:26:48 <xranby> this is the one fat jar content.. its using jar in jar https://gist.github.com/xranby/9c87ab55fa38fd1f652c/raw/465f5fbf4f4ad04bd63954fb502a2e4fa5d0eac1/gistfile1.txt
20131001 09:27:09 <sgothel> but is the one-jar classloader 'attached' ?
20131001 09:27:31 <xranby> not sure.. maybe i should use com/simontuffs/onejar/Boot inside the build.xml
20131001 09:27:39 <sgothel> Main-Class is still ours .. so I doubt it can work
20131001 09:28:22 <sgothel> it can only work .. if starting a launching class, which installs a CL .. which itself loads our main-class (JOGL demo) ..
20131001 09:40:36 <xranby> sgothel: ok i have not updated the logs using 2.0.2 (removed the gluegen-rt-android jar and fixed the manifest) https://gist.github.com/xranby/9c87ab55fa38fd1f652c
20131001 09:40:55 <xranby> its now using their main class
20131001 09:41:25 <xranby> https://gist.github.com/xranby/9c87ab55fa38fd1f652c/raw/c65f6365aa024ff125bc8e9f22753d426a4230af/java+-Djogamp.debug%3Dall+-jar+movieplayer.jar+.txt
20131001 09:43:02 <sgothel> getJarFile: jar:file:/movieplayer.jar!/lib/gluegen-rt-natives-linux-i586.jar!/ getJarSubURI res: file:/movieplayer.jar!/lib/gluegen-rt-natives-linux-i586.jar
20131001 09:43:20 <sgothel> the JarSUbURI is not compliant w/ URI .. no scheme .. :(
20131001 09:43:39 <sgothel> i.e. eclipse properly used it's own scheme 'rsrc'
20131001 09:44:11 <sgothel> this is quite ugly from 'one-jar'
20131001 09:45:00 <sgothel> jar:file:/movieplayer.jar!/lib/gluegen-rt-natives-linux-i586.jar!/ -> jar:file:/movieplayer.jar!file:/lib/gluegen-rt-natives-linux-i586.jar!/
20131001 09:45:02 <sgothel> would be fine
20131001 09:45:19 <sgothel> then the sub-uri would be: file:/lib/gluegen-rt-natives-linux-i586.jar!/
20131001 09:46:38 <sgothel> that we even get: jar:file:/movieplayer.jar! - is sort of odd .. hmm
20131001 09:46:53 <sgothel> I will look at it later, after one-big-fat jar
20131001 10:43:13 <xranby> sgothel: thank you, the problem presists when using the current gluegen git head
20131001 10:45:23 <xranby> oh more updates.. i will recheck
20131001 10:55:58 <xranby> retested using 1a8d2c627dbab5234aea72a458c00b6bba28add0 844 fix and... same issue https://gist.github.com/xranby/9c87ab55fa38fd1f652c/raw/15c527318fe95963753f383791100cf3af898812/4+2.1.0+1a8d2c627dbab5234aea72a458c00b6bba28add0+844+fix
20131001 11:13:05 <xranby> btw... http://edition.cnn.com/2013/09/30/politics/shutdown-showdown/index.html?hpt=hp_t1 - what happens when a foreign economy based on war income do not get their war/income
20131001 11:17:59 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=845
20131001 11:20:25 <sgothel> unit tests are welcome .. for Bug 845, 844, 843 .. (I used manual tests / shell scripts so far - not safe against regressions)
20131001 11:31:19 <sgothel> .. interesting .. doesn't work w/ a JOGL test .. reopening ..
20131001 11:32:03 <xranby> todays US government economy shutdown trouble is likely to be directly related to the now missing compensation from a war on syria http://www.dailymail.co.uk/news/article-2411806/Offer-table-Arab-countries-pay-scale-U-S-invasion-Syria-says-Secretary-State-John-Kerry.html
20131001 11:32:48 <sgothel> well .. yes, I have to say I was very very positively surprised by such a move (not to proceed w/ the war)
20131001 11:33:09 <sgothel> interesting to know: Who was it who asked Kerry that question ..
20131001 11:33:31 <sgothel> maybe the POTUS got cold feed .. and they arranged it w/ Putin ..
20131001 11:34:00 <sgothel> yes, the economy break down is assumed to happen ..
20131001 11:34:18 <xranby> "Florida Republican Rep. Ileana Ros-Lehtinen had asked Kerry to comment on the expenses related to carrying out attacks on Syria if Congress were to authorize them."
20131001 11:35:07 <sgothel> The Q .. was 'would you still going to war if they would remove the gas ..' (something like that)
20131001 11:35:34 <sgothel> so now .. US gets no money from Saudi Arabia and friends (Israel) for using the weapons etc ..
20131001 11:36:11 <sgothel> since we know Kerry elaborated on the reimbursements .. :)
20131001 11:37:07 <xranby> yes it is disgusting
20131001 11:37:17 <sgothel> so they probably gave a reporter a hint to such question and/or allowed this question to be asked (and answered) .. since I hardly can believe that such 'accidents' happen
20131001 11:38:17 <xranby> from kerrys mouth: 'In fact, some of them have said that if the U.S. is prepared to go do the whole thing, the way we’ve done it previously in other places, they’ll carry that cost. That’s how dedicated they are to this.'
20131001 11:38:37 <sgothel> US for hire ..
20131001 11:39:34 <sgothel> would be interested to know why they got 'cold feet' .. I don't think it's altruism :)
20131001 11:39:54 <sgothel> Must be Russia and China ..
20131001 11:40:33 <sgothel> or they realized .. the people wouldn't accept it -> revolt
20131001 11:41:11 <sgothel> Guess we have to spend our money fast now :)
20131001 11:42:14 <sgothel> (keeping an eye on currency development .. hmm)
20131001 11:42:20 <xranby> sure
20131001 12:14:55 <xranby> https://twitter.com/NASAVoyager2/status/384887422477430784 - "Due to government shutdown, we will not be posting or responding from this account. Farewell, humans. Sort it out yourselves."
20131001 13:02:24 <xranby> http://www.slate.com/articles/business/moneybox/2013/09/government_shutdown_versus_the_debt_ceiling_why_hitting_the_debt_limit_is.html - "On Oct. 17 something different—something more obscure but much worse—may happen. The government will breach what’s known as the debt ceiling."
20131001 13:03:30 <sgothel> "/pol" is mentioning this time-frame for quite a while now :-/
20131001 13:06:37 <xranby> "One is President Obama could decide that the government’s legal obligation to spend (and certain elements of the 14th Amendment) trump the statutory debt ceiling, and just order the Treasury to sell more bonds. The second option is Obama could instruct the Treasury to pay some of the government’s bills and just not pay the rest. The third option is to pay nobody. All three of these options face the same basic problem of seeming to be illegal. "
20131001 13:07:40 <xranby> "The general consensus is that the third option would, among other things, provoke a global financial crisis by causing a default on U.S. treasury bonds"
20131001 13:07:47 <sgothel> haha .. 'illegal' .. :)
20131001 13:07:59 <xranby> :)
20131001 13:08:22 <sgothel> so sacking Europe (as currently in progress) .. then the US .. hmm, maybe to convince folks that we need a new bigger currency union :)
20131001 13:11:11 <xranby> this year will have a special halloween for sure
20131001 13:13:17 <sgothel> if we could only agree to dismiss this interest based fiat currency all together ..
20131001 13:14:00 <sgothel> since there is no infinite growth .. :)
20131001 13:15:57 * xranby will put a reminder .. do not lend money in order to buy a house this month
20131001 13:16:25 <xranby> or borrow hmm
20131001 13:18:43 <xranby> Matthew Green: " First signs of the government shutdown: the supercomputers at Ft. Meade are now mining Bitcoin. "
20131001 13:22:18 <sgothel> borrowing money is good - as long you have something of intrinsic value worth the same amount (or half of it) :)
20131001 13:26:13 <xranby> jogamp 2.0.2 is in debian unstabl
20131001 13:27:23 <xranby> http://packages.debian.org/sid/libjogl2-java
20131001 13:28:23 <monsieur_max> great :)
20131001 13:28:29 <xranby> http://packages.qa.debian.org/libj/libjogl2-java.html
20131001 13:28:52 <xranby> http://qa.debian.org/popcon.php?package=libjogl2-java
20131001 13:35:25 <xranby> http://www.khronos.org/message_boards/showthread.php/9138-Requesting-feedback-on-disallowing-handle-attribute-values-in-EGLint-attribute-lists?p=29720#post29720 - The Khronos Group EGL Working Group requests feedback on change in attribute list type
20131001 13:39:00 <sgothel> Bug 845 Fix - Pushed
20131001 13:40:51 <sgothel> yes - that EGLint issue rings a bell :)
20131001 13:41:27 <sgothel> yes, they need to use a 64bit type .. well ..
20131001 13:42:29 <sgothel> so: multi, fat and eclipse_jar-in-jar works now ..
20131001 13:47:23 <xranby> sgothel: \o/ KUDOS!
20131001 13:47:34 <sgothel> now lets see for one-jar ..
20131001 13:53:05 * rmk0 (~rmk0@anon) Quit (Quit: Lost terminal)
20131001 13:53:48 <sgothel> https://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling#Custom_Bundling <- .. to be refined ..
20131001 15:59:24 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131001 16:43:52 * monsieur_max (~maxime@anon) has joined #jogamp
20131001 19:27:21 * kermyt (~kermyt@anon) Quit (*.net *.split)
20131001 19:31:57 * kermyt (~kermyt@anon) has joined #jogamp
20131001 19:33:26 * albert_ (4d392a4f@anon) has joined #jogamp
20131001 19:35:32 <albert_> i'm using jogl on osx 10.6.8 and cant create GL3 context because lack of OpenGL3 support by the os. Is there a way to use a different library? like glfw? and/or disable acceleration and use just software rendering?
20131001 19:36:20 <albert_> what i need jogl for is very simple (exercises) so i don't care if it is slow
20131001 19:46:37 * albert_ (4d392a4f@anon) Quit (Quit: Page closed)
20131001 20:06:42 * kermyt (~kermyt@anon) Quit (Ping timeout: 264 seconds)
20131001 20:26:07 * kermyt (~kermyt@anon) has joined #jogamp
20131001 20:55:15 * void256 (~void@anon) has joined #jogamp
20131001 21:41:06 * void256 (~void@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258])
20131001 21:41:13 * monsieur_max (~maxime@anon) has left #jogamp
20131001 21:41:22 * void256 (~void@anon) has joined #jogamp
20131001 22:09:25 * xranby-64 (~familjen@anon) has joined #jogamp
20131001 22:22:14 * xranby-64 (~familjen@anon) Quit (Ping timeout: 240 seconds)
20131001 22:30:40 * xranby-64 (~familjen@anon) has joined #jogamp
20131001 23:15:12 <xranby-64> i found a developers note on one-jar and apparently Eclipse's "Fat JAR" plugin is based on it http://www.ibm.com/developerworks/library/j-onejar/
20131001 23:16:29 <xranby-64> now.. the issue we face, how to construct a URI to a file inside a nested jar, is neatly described in this note
20131001 23:16:31 <xranby-64> "In theory, to get to an entry inside a JAR file inside a JAR file you would have to use something like jar:file:/fullpath/main.jar!/lib/a.jar!/a.resource, but unfortunately this doesn't work. The JAR file protocol handler treats only the last "!/" separator as indicating a JAR file. "
20131001 23:16:39 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=846 <- I close this one 'won't fix' ..
20131001 23:17:01 <sgothel> that's what I have mentioned .. yup
20131001 23:17:11 <sgothel> so Eclipse does it right ..
20131001 23:18:20 <sgothel> https://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling
20131001 23:18:30 <xranby-64> hmm.. after tonights experimentation.. i belive we have a regression for eclipse jar-in-jar
20131001 23:19:26 <sgothel> works here .. I added the manual test-cases in gluegen
20131001 23:21:03 <xranby-64> interesting.. because here JarUtil.getJarBasename returns the outer nested jar name instead of the inner nested jar
20131001 23:21:23 <xranby-64> thus the native jar can not use the original name
20131001 23:21:43 <sgothel> We are not talking about the same here ..
20131001 23:21:44 <xranby-64> and must be renamed to the outer nested jar name + os.and.arch
20131001 23:22:14 <sgothel> Eclipse jar-in-jar -> Test-2 https://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling
20131001 23:22:30 <sgothel> it uses a handler -> rsrc:inner.jar
20131001 23:22:59 <sgothel> all other _incomplete_ solutions w/o a handler won't work [by design]
20131001 23:23:49 <xranby-64> would it be a mess using something like.. final URL url = IOUtil.class.getProtectionDomain().getCodeSource().getLocation(); in IOUtil ?
20131001 23:23:50 <sgothel> so either they properly implement a handler .. or they are not usable .. or we would have to implement extracting the inner from the outter .. duh :)
20131001 23:24:07 <xranby-64> looking up the class using reflection
20131001 23:24:18 <xranby-64> instead of using the hardcoded IOUtil ofc
20131001 23:24:21 <sgothel> are you copying stuff from some advices / hints ?
20131001 23:24:42 <xranby-64> in this case yes http://stackoverflow.com/questions/320542/how-to-get-the-path-of-a-running-jar-file
20131001 23:25:01 <sgothel> haha .. well, we would need to extract the inner jars from the outter one
20131001 23:25:07 <xranby-64> http://stackoverflow.com/questions/320542/how-to-get-the-path-of-a-running-jar-file
20131001 23:25:16 <sgothel> we have all data already ..
20131001 23:25:32 <sgothel> they probably talk about get class's jar source and unzip it ..
20131001 23:25:59 <xranby-64> the answer i wanted to link to http://stackoverflow.com/a/12733172
20131001 23:26:00 <sgothel> so we could do similar w/ TempJarCache .. sure .. but right now I am reluctant
20131001 23:26:57 <sgothel> author of One-Jar mentions similar stuff (manual extracting) and he pledged to impl. a handler .. but nothing there in this pretty ole CVS repo
20131001 23:28:06 <sgothel> I say 'incomplete' b/c if their ClassLoader findResource method returns a URL, they also need to supply a handler for openConnection .. etc
20131001 23:28:30 <sgothel> I analyzed it quite a bit ..
20131001 23:29:01 <xranby-64> ... one-jar documentation is not helpful to resolve this native issue http://one-jar.sourceforge.net/index.php?page=details&file=native
20131001 23:29:16 <xranby-64> its like.. thats not how to do it
20131001 23:29:27 <sgothel> just forget about it
20131001 23:29:46 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=846#c1
20131001 23:29:53 <sgothel> the URL they create is also bogus
20131001 23:30:54 <sgothel> as I wrote in the wiki, better get the Eclipse jar-in-jar RSRC handler .. and add it to some standalone ..
20131001 23:34:17 <xranby-64> sgothel: ok i agree, there is no easy way to fix this unless the JAR file protocol handler gets improved
20131001 23:34:39 <xranby-64> to support URI's to nested jars
20131001 23:35:00 <sgothel> "improved -> implemented" by those tools (One-Jar, ..)
20131001 23:35:49 <sgothel> e.g. we have an assets URL handler dealing w/ 'asset:/slkslks' for example .. same thing
20131001 23:40:23 <xranby-64> ok at least we have the new Fat jar solution to offer one-jar people
20131001 23:40:36 <sgothel> fat + multi :)
20131001 23:41:12 <xranby-64> i think the /natives/os.and.arch/libfoo.so may work
20131001 23:41:18 <xranby-64> i will test
20131001 23:42:06 <sgothel> you can use the manual tests in gluegen to reproduce success
20131001 23:43:56 <xranby-64> i have tested those.. they worked nice
20131001 23:44:28 <xranby-64> i was about to add a jar-in testcase ... doing it and then realised that we did not have a magical classloader
20131001 23:44:42 <xranby-64> next to fat and multi
20131001 23:45:06 <xranby-64> i can add one using tome wget onejar foo
20131001 23:45:11 <xranby-64> perhaps
20131001 23:45:41 <sgothel> the eclipse class files are included in the manual test as well ..
20131001 23:46:30 <sgothel> maybe we can extract the required stuff .. (license is compatible) and simply add it as a tool in gluegen (w/ sources)
20131001 23:47:24 <xranby-64> the benefit would be ok git checksums in the bugreports
20131001 23:47:39 <xranby-64> by using unmodified jars inside jar
20131001 23:47:58 <sgothel> plus .. our upcoming verification ..
20131001 23:58:35 * xranby-64 is fooled by one-jar once again
20131001 23:59:28 <xranby-64> JarClassLoader: resource natives/linux-amd64/ resolved to null .. right
20131002 00:10:15 <xranby-64> ok. at least Fat jar work in combination with one-jar (the end user app can still be in a jar in jar) while all jogamp gluegen jogl and natives must be unpacked inside the jar
20131002 00:10:49 <xranby-64> tested and found to be working
20131002 00:11:58 <xranby-64> but with the added hurdle to prepare the natives/os.and.arch directory structure by hand/ant
20131002 00:12:45 <sgothel> IMHO it's either [multi and/or fat] or jar-in-jar (eclipse)
20131002 00:12:59 <sgothel> then .. producing stuff is done via ant recipes .. etc
20131002 00:13:08 <sgothel> so the latter shall be no problem
20131002 00:14:08 <sgothel> since this seems to be of huge interest .. maybe you can find the eclipse rsrc handler sources .. etc .. and extract them
20131002 00:14:53 <xranby-64> sure.. i can have a look
20131002 00:15:10 <xranby-64> the reason why i do it is to ease deployment
20131002 00:15:55 <sgothel> jnlp ?
20131002 00:16:12 <xranby-64> jnlp in app stores?
20131002 00:16:15 <xranby-64> etc
20131002 00:16:29 <sgothel> but .. yeah .. why not a single jar. what is an app-store ? :)
20131002 00:17:15 <sgothel> then .. we can host rsrc-tool on jogamp ..
20131002 00:18:00 <sgothel> for folks not using eclipse export via IDE .. (ugly)
20131002 00:19:38 <xranby-64> interesting mesa bugs on this machine
20131002 00:19:42 <xranby-64> radeon: The kernel rejected CS, see dmesg for more information.
20131002 00:19:57 <xranby-64> the movieplayer looks like a firecracker
20131002 00:20:26 <xranby-64> dmesg spits out
20131002 00:20:27 <xranby-64> [117381.271426] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:479 cb[0] bo too small (layer size 524288, offset 0, max layer 1, bo size 4096, slice 8191)
20131002 00:20:27 <xranby-64> [117381.271432] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:483 problematic surf: (1024 512) (4 1 1 1 4 1024 2)
20131002 00:20:27 <xranby-64> [117381.271436] radeon 0000:01:00.0: evergreen_packet3_check:2149 invalid cmd stream 529
20131002 00:20:27 <xranby-64> [117381.271438] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
20131002 00:21:04 <xranby-64> GL_RENDERER Gallium 0.4 on AMD BARTS
20131002 00:21:04 <xranby-64> GL_VERSION 3.1 (Core Profile) Mesa 9.1.4
20131002 00:21:29 <xranby-64> the app is running and no crash so hmm..
20131002 00:21:47 <sgothel> BARTS ?
20131002 00:22:39 <sgothel> looks like all the AMD (proprietary + open-source) devs are on a loong holiday :)
20131002 00:22:50 <xranby-64> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts PRO [Radeon HD 6850]
20131002 00:23:17 <sgothel> guess I am not up-to-date w/ those products
20131002 00:23:59 <xranby-64> this is my amd gl3 test machine
20131002 00:28:57 <xranby-64> monsieur_max posted this handy resource https://fr.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/?cr=fr
20131002 00:29:16 <xranby-64> at least it gives hope that bugs like this may get fixed if they are repoted in
20131002 00:30:40 <xranby-64> ok i will file a bug for this in https://bugs.freedesktop.org/ .. later
20131002 00:39:56 <xranby-64> eclipse fjep http://fjep.sourceforge.net/ -> turned into eclipse 3.5 enhancement -> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219530
20131002 00:43:05 <xranby-64> comment 67 -> 3. I am submitting the code for inclusion in future Eclipse releases under the EPL.
20131002 00:43:27 <xranby-64> https://bugs.eclipse.org/bugs/show_bug.cgi?id=219530#c67
20131002 00:44:15 <sgothel> is this good ?
20131002 00:44:41 <sgothel> at least .. you found it :)
20131002 00:44:53 <xranby-64> http://en.wikipedia.org/wiki/Eclipse_Public_License
20131002 00:45:44 <xranby-64> not exactly awesome
20131002 00:45:55 <sgothel> similar to APL2
20131002 00:46:21 <xranby-64> since it may be troublesome for gpl users if they want to use it to produce a jar-in-jar
20131002 00:46:37 <sgothel> Q: is the deployed handler under EPL as well ? I doubt ..
20131002 00:46:47 <sgothel> if only the 'producer ..
20131002 00:46:59 <sgothel> otherwise everybody 'exporting' would be EPL ? haha
20131002 00:47:16 <xranby-64> well most likely they are
20131002 00:47:27 <xranby-64> at least a part of their app is epl
20131002 00:47:38 <xranby-64> if the eclipse epl classloader is included
20131002 00:48:13 <sgothel> nah - I doubt that, they would need to make a special notice
20131002 00:50:51 <sgothel> Derivative works <- looks good
20131002 00:51:15 <sgothel> i.e. a loader module .. and the application -> not a derivative work
20131002 00:53:22 <sgothel> http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses <- link w/ diff license == yes
20131002 00:53:41 <xranby-64> [citation needed] ;)
20131002 00:54:02 <xranby-64> ok lets take a look
20131002 00:54:38 <xranby-64> http://www.eclipse.org/legal/eplfaq.php#LINK
20131002 00:55:52 <sgothel> so .. we are safe :)
20131002 00:56:19 <sgothel> just need to drop it in it's own git repo .. users can use-it .. or not
20131002 00:57:02 <sgothel> if we would use it .. not a derivative .. since our code base targets something else, i.e. using it just as a loader
20131002 01:00:08 <sgothel> well .. we could also re-implementing the missing parts (ClassLoader .. and handler) .. almost having all pieces in place .. just too lazy for now
20131002 01:09:31 <xranby-64> we may use the good description in https://bugs.eclipse.org/bugs/show_bug.cgi?id=219530#c0 as well
20131002 01:10:13 <xranby-64> that describe the rsrc: implementation in english
20131002 01:11:44 <sgothel> :)
20131002 01:13:23 <sgothel> validates my findings ..yup
20131002 01:25:04 <xranby-64> good night, thank you for the discussion!
20131002 01:25:29 <sgothel> good night .. good stuff & thx
20131002 01:28:50 * void256 (~void@anon) Quit (Remote host closed the connection)
20131002 01:32:31 * xranby-64 (~familjen@anon) Quit (Ping timeout: 246 seconds)
20131002 05:05:30 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131002050530.html