JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20151126 19:08:06 (UTC)

20151126 19:08:06 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20151126050511.html
20151126 19:09:21 -NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
20151126 19:09:21 * jogamp (~jogamp@anon) has joined #jogamp
20151126 19:09:21 * Topic is 'http://jogamp.org | Hacking 3D Graphics, Multimedia and Processing across Devices | logs: http://jogamp.org/log/irc/?C=M;O=D'
20151126 19:09:21 * Set by rmk0 on 20141110 16:19:10
20151126 19:09:26 -NickServ- You are now identified for jogamp.
20151126 19:13:23 * i-make-robots (~dan@anon) Quit (Ping timeout: 264 seconds)
20151126 19:14:42 * bigpet (uid25664@anon) has joined #jogamp
20151126 19:14:42 * xranby (~xranby@anon) has joined #jogamp
20151126 19:15:28 * badshah400 (~badshah40@anon) has joined #jogamp
20151126 19:17:40 * i-make-robots (~dan@anon) has joined #jogamp
20151126 19:23:27 * darkfrog1 (~mhicks@anon) has joined #jogamp
20151126 19:27:02 * monsieur_max (~maxime@anon) Quit (Ping timeout: 240 seconds)
20151126 19:27:08 * monsieur_max (~maxime@anon) has joined #jogamp
20151126 19:27:32 * darkfrog (~mhicks@anon) Quit (*.net *.split)
20151126 19:30:13 * bruce-_ (~x@anon) Quit (Ping timeout: 264 seconds)
20151126 19:38:32 * bruce- (~x@anon) has joined #jogamp
20151126 19:52:45 * monsieur_max (~maxime@anon) Quit (Ping timeout: 240 seconds)
20151126 19:54:33 <i-make-robots> rmk0_ thank you! I really appreciate that. Now to find a 32 bit system to test....
20151126 19:55:25 <rmk0_> glad to hear it's working. deploying something with jogl shouldn't be difficult!
20151126 19:56:05 * monsieur_max (~maxime@anon) has joined #jogamp
20151126 20:08:07 * ArToX (6dda238d@anon) Quit (Quit: Page closed)
20151126 20:16:32 * bigpet (uid25664@anon) Quit (Quit: Connection closed for inactivity)
20151126 20:39:31 * bigpet (uid25664@anon) has joined #jogamp
20151126 20:54:39 * bigpet_ (uid25664@anon) has joined #jogamp
20151126 20:57:19 * bigpet (uid25664@anon) Quit (Ping timeout: 246 seconds)
20151126 20:59:11 * bigpet_ is now known as bigpet
20151126 21:29:28 * sgothel (~sgothel@anon) has joined #jogamp
20151126 21:29:28 * sgothel (~sgothel@anon) Quit (Changing host)
20151126 21:29:28 * sgothel (~sgothel@anon) has joined #jogamp
20151126 21:29:28 * ChanServ sets mode +v sgothel
20151126 21:30:43 <sgothel> back chatting .. hi-ho, hope all is good w/ all of you - here, everything is as usual. I was just quite occupied w/ good family stuff and a project
20151126 21:31:33 <sgothel> note: I will not read the backlog .. :)
20151126 21:40:19 <rmk0_> lo!
20151126 21:42:28 <sgothel> new keyboard must get warmed up, stickyness from newness instead of dirt :)
20151126 21:43:08 <sgothel> so I have not received any personal emails w/ pull requests - so nothing really new I guess
20151126 21:43:34 <sgothel> weather still bad in England Mark? Hope all is fine
20151126 21:43:43 <sgothel> Vulkan has not been released yet .. well
20151126 21:44:29 <sgothel> I still will do the gluegen callback generation, zuzub wanted to use it AFAIK (but no pull req. here either)
20151126 21:44:33 <sgothel> all good :)
20151126 21:44:45 <sgothel> a few bug reports, great
20151126 21:45:25 <sgothel> oh .. new ssl certs sha256 are in place of course
20151126 21:45:37 <sgothel> the java cert will be updated these days as well
20151126 21:46:01 <sgothel> and I closed the jenkins/java door those days in time as well - of course :)
20151126 21:46:22 <sgothel> guess that vuln. was around start of november?
20151126 21:49:23 <sgothel> Hope Xerxes has the ovens running hot, must be quite cold by now. Here its like on and off, warm and cold each other day.
20151126 21:49:48 <sgothel> ranging 18C - 0C :)
20151126 21:55:21 <rmk0_> weather's pretty cold now, but stable
20151126 21:55:31 <rmk0_> we had a week or so of brutal winds
20151126 21:59:33 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20151126 22:00:59 <rmk0_> sgothel: that issue i filed... as i mentioned in the ticket, i'm not sure it qualifies as a bug exactly
20151126 22:03:16 <rmk0_> it seems like platform specific behaviour that leaks into the api in an undocumented way
20151126 22:03:25 <rmk0_> the "fix" might just be mentioning that this can happen in the javadoc
20151126 22:04:47 <rmk0_> i can submit a pull request if you think that's enough
20151126 22:04:58 <sgothel> reading ..
20151126 22:05:25 <sgothel> bug number?
20151126 22:05:33 <rmk0_> https://jogamp.org/bugzilla/show_bug.cgi?id=1259
20151126 22:05:38 <rmk0_> hehe, sorry, that's the important bit!
20151126 22:06:56 <sgothel> AFAIK we do an explicit release before destroying the context .. no?
20151126 22:07:31 <rmk0_> it's necessary to call context.release() before calling drawable.destroy() here
20151126 22:07:39 <rmk0_> at least on this windows 7 install
20151126 22:08:01 <rmk0_> it's necessary to release all the shared contexts too
20151126 22:08:09 <sgothel> whats the use case where this does not happen?
20151126 22:08:27 <sgothel> the ATI driver .. hmm
20151126 22:08:52 <sgothel> well .. sure, if a drawable is used by a context, and the latter not flushed (i.e. using the resources) .. things can happen
20151126 22:09:17 <sgothel> you have a use case .. unit test?
20151126 22:09:22 <rmk0_> i discovered it because i have a test suite that creates offscreen drawables, does something with them, throws them away, per test
20151126 22:09:40 <rmk0_> it's literally that program i attached to the report
20151126 22:09:57 <sgothel> pls offer a unit test which reproduces this issue .. ah (I read the bug-emails)
20151126 22:10:17 <sgothel> so ,. as a unit test, that would be great :)
20151126 22:10:27 <rmk0_> https://jogamp.org/bugzilla/attachment.cgi?id=763
20151126 22:11:23 * rmk0_ clones jogl again
20151126 22:11:32 <sgothel> reading CreateUnsharedContext0 ..
20151126 22:11:44 <sgothel> well, so I can tell you: your use case is invalid :)
20151126 22:11:56 <rmk0_> because i don't release the context?
20151126 22:11:58 <sgothel> i.e. yes, it itself is a bug
20151126 22:12:15 <sgothel> i.e. you pull the resource (drawable) while context is alive
20151126 22:12:20 <rmk0_> that's fair enough, but the fact that it's invalid doesn't seem to be documented
20151126 22:12:31 <sgothel> in the OpenGL spec?
20151126 22:12:52 <rmk0_> is it?
20151126 22:12:53 <sgothel> its like you delete a buffer .. and run the shader
20151126 22:13:08 <sgothel> I am not so sure .. there are bits of 'delayed/deferred deletion'
20151126 22:13:22 <sgothel> however, I remember all those cases where it does not work
20151126 22:13:47 <sgothel> so here .. the FBO (I guess) is pulled .. while being used as render target
20151126 22:13:54 <sgothel> maybe it is mentioned somewhere
20151126 22:14:12 <sgothel> if the spec says 'deferred deletion' .. then the GL impl. is wrong
20151126 22:14:17 <rmk0_> worryingly, this pattern does work on other platforms
20151126 22:14:23 <rmk0_> "work"
20151126 22:14:28 <sgothel> well :)
20151126 22:14:30 <rmk0_> "doesn't raise an exception"
20151126 22:14:51 <sgothel> for example, we hold off deletion of other context and stuff for shared ones .. for exactly that reason
20151126 22:15:14 <sgothel> lets say the spec _was_ fuzzy about the lifecycle
20151126 22:15:33 <sgothel> and deferred deletion, even if allowed by the spec, was something not working everywhere
20151126 22:16:09 <sgothel> so 'drawable.destroy()' cannot signal its context implicitly, b/c there is no relation to the context being hold by drawable
20151126 22:16:23 <sgothel> only our context instance has its drawable handles
20151126 22:16:41 <sgothel> hence: harden your code here
20151126 22:16:44 <rmk0_> to be clear, i'm not pushing for any for any particular behaviour. my current test suite does do the right thing, i just discovered this because it was doing the wrong thing and failing on one platform in a manner that didn't on any other, so i filed a bug
20151126 22:17:00 <sgothel> all good
20151126 22:17:13 <sgothel> maybe you can find the spec wording whether this is allowed.
20151126 22:17:22 * rmk0_ eyes paperwork
20151126 22:17:47 <sgothel> I do remember for GL buffers and the like the wording 'deferred deletion' if resource is still in use (VBO, shader program, ..)
20151126 22:18:03 <sgothel> no surprise if some Windows driver does its own thang :)
20151126 22:18:13 <rmk0_> particularly this windows driver!
20151126 22:18:25 <rmk0_> is utter abandonware
20151126 22:18:37 <sgothel> we have all fun w/ proprietary ATI drivers :)
20151126 22:18:56 <sgothel> hence: me not using 'em anymore .. Mesa/ATI rocks though
20151126 22:19:05 <rmk0_> yeah, mesa everywhere i can use it here
20151126 22:19:26 <rmk0_> OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.6
20151126 22:19:28 <rmk0_> ♥
20151126 22:20:10 <sgothel> hope you guys all patched your java server stuff for that vulnerability of that beans serializer issue by now
20151126 22:25:10 <sgothel> https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli
20151126 22:25:53 <sgothel> I know .. old news from last century :)
20151126 22:27:29 <sgothel> btw .. Rami and Julien are both OK, I got email replies from them after it the terror attacks happened in Beirut and Paris
20151126 22:28:35 <rmk0_> \o/
20151126 22:28:47 <sgothel> wonder when Europe either kicks out Turkey from the NATO or 'we' simply leaving the NATO (IMHO better)
20151126 22:28:55 <rmk0_> for some reason it didn't occur to me that julien was in paris. i thought he was further south for some reason
20151126 22:30:07 <sgothel> around .. some kilometers, not in the center - but he travels around. two friends of friends (one of Julien) were there around 30 minutes earlier/later
20151126 22:30:49 <sgothel> so some of the financial funding seems to 'come back' .. well well (right, don't get me started again :)
20151126 22:31:32 <sgothel> looks like 'truth' come to surface by now .. piece by piece
20151126 22:32:38 <sgothel> see what a less than 17s border violation can gets you - not even Texas draws that fast (hey, thats actually a good one)
20151126 22:33:04 <sgothel> (assuming that jet had stalling speed ..)
20151126 22:36:54 <sgothel> http://www.zerohedge.com/news/2015-11-25/who-said-it-short-term-border-violation-can-never-be-pretext-attack
20151126 22:36:58 <sgothel> http://www.zerohedge.com/news/2015-11-24/russia-escalates-suspends-military-cooperation-turkey-moves-warship-coast-destroy-an
20151126 22:37:04 <sgothel> .. and so on .. and so forth
20151126 22:37:16 <sgothel> so, happy turkey eating today :)
20151126 22:37:31 <sgothel> (it is thanksgiving after all today)
20151126 23:00:20 * gouessej (5279482a@anon) has joined #jogamp
20151126 23:00:23 <gouessej> Hi
20151126 23:00:29 <sgothel> Hi Julien
20151126 23:00:47 <gouessej> sgothel: Something must be done for the defl/bin thingy
20151126 23:00:58 <sgothel> yup
20151126 23:01:03 <gouessej> sgothel: I take care of Java3D
20151126 23:01:22 <sgothel> the memory solution might be a security issue, if it is writable memory for dll loading
20151126 23:01:35 <sgothel> however, we could 'try' w/ a dll instead of an exe .. if that helps
20151126 23:01:47 <sgothel> hmm
20151126 23:02:15 <sgothel> or .. if we can setup memory for executables (i.e. immutable)
20151126 23:02:15 <gouessej> If you find my suggestion not viable, we can forget it
20151126 23:02:28 <sgothel> no no .. just brainstorming
20151126 23:02:45 <sgothel> it would be an empty dll anyways .. hmm
20151126 23:02:56 <sgothel> then I need to rerun all the tests .. grr :)
20151126 23:03:29 <gouessej> Actually, I was thinking about replacing the whole native automated extraction and loading mechanism
20151126 23:03:38 <sgothel> You maintain Java3D - Great news!
20151126 23:03:50 <sgothel> go on ..
20151126 23:03:59 <gouessej> Yes but I need you to choose the new package name
20151126 23:04:15 <gouessej> org.jogamp.java3d?
20151126 23:04:25 <sgothel> what we have now .. com.jogamp....
20151126 23:04:27 <gouessej> or com.jogamp.java3d?
20151126 23:04:32 <sgothel> yup
20151126 23:04:55 <gouessej> why did you choose com.jogamp instead of org.jogamp?
20151126 23:05:11 <sgothel> I don't know .. guess I was so much used to that '.com'
20151126 23:05:26 <sgothel> i.e. com.sun. .. which we had before
20151126 23:06:03 <gouessej> it's ok for me, it will be done in the version 1.6.1. The version 1.6.0 will keep the old package name
20151126 23:06:06 <sgothel> and 'come jogamp' sounds better than 'organize jogamp' :)
20151126 23:06:33 <sgothel> then please make it 1.7.0 - matching our versioning scheme
20151126 23:07:05 <sgothel> or even 2.0.0 if you like
20151126 23:07:18 <gouessej> I was planning to make some bigger changes in 1.7.0, dropping Java 1.6 support, etc
20151126 23:07:27 <sgothel> (we reserve the major number for huge changes though)
20151126 23:07:56 <sgothel> a patch number change implies binary compatibility
20151126 23:08:05 <sgothel> so it should be a minor number change IMHO
20151126 23:08:06 <gouessej> Ok, it would make sense to switch to 1.7.0
20151126 23:08:16 <sgothel> great
20151126 23:08:58 <gouessej> I'll use the generics then :) I don't want to support the Apple JRE, it causes too much troubles
20151126 23:09:06 <sgothel> so that ball is back in your court, you started the java3d revamp (not sure whether you really like it though)
20151126 23:09:19 <sgothel> its all your choice here
20151126 23:09:55 <gouessej> I won't implement any new features, I will just do a few things to make it more maintainable for the next 5 years.
20151126 23:10:05 <gouessej> I will accept some contributions
20151126 23:10:58 <gouessej> I will have to modify the package name of JogAmp's Ardor3D Continuation too to avoid name clash and confusion on Maven Central
20151126 23:11:15 <sgothel> great
20151126 23:11:39 <sgothel> I have added group writable for our java3d git scm .. i.e. you should be able to push there as well
20151126 23:11:57 <sgothel> groups jgouesse
20151126 23:11:57 <sgothel> jgouesse : jgouesse java3d ardor3d
20151126 23:12:08 <gouessej> Ok, I already do so for JogAmp's Ardor3D Continuation
20151126 23:12:50 <gouessej> I'll have to generate the Java documentation when the Maven build is ready and after some syntaxic changes
20151126 23:14:31 <gouessej> The virus scanners seem to cause a lot of troubles to our directory executable test
20151126 23:15:06 <gouessej> Do we have some short term solutions to improve the situation a little bit?
20151126 23:15:16 <sgothel> have you created a bug report exploring your ideas?
20151126 23:15:43 <gouessej> Yes, one bug report for the native loading without extraction
20151126 23:16:14 <sgothel> great .. then I will try that out .. and we can elaborate later on
20151126 23:16:16 <gouessej> https://jogamp.org/bugzilla/show_bug.cgi?id=1271
20151126 23:16:22 <sgothel> guess I can find a few hours for that one
20151126 23:16:48 <gouessej> Maybe using the other fallback I suggested would have less impact that the suggestion above
20151126 23:17:02 <gouessej> the new method in NIO 2
20151126 23:17:17 <gouessej> "than"
20151126 23:17:26 <sgothel> hmm .. used via reflection
20151126 23:17:40 <sgothel> but the process still may hang (exe test)
20151126 23:17:46 <sgothel> that one forum email ..
20151126 23:17:55 <sgothel> which I cannot explain :-/
20151126 23:18:58 <gouessej> he uses VMWare
20151126 23:19:07 <gouessej> I wrote this bug report too: https://jogamp.org/bugzilla/show_bug.cgi?id=1266
20151126 23:19:16 <gouessej> It's very low priority
20151126 23:19:39 <sgothel> yup .. I remember, that is a good one
20151126 23:19:44 <sgothel> and easy todo
20151126 23:20:26 <gouessej> I have read a lot of things about Vulkan but it won't replace OpenGL as a cross-platform API soon
20151126 23:21:25 <gouessej> https://github.com/KhronosGroup/WebGL/issues/1101#issuecomment-158384910 :D
20151126 23:21:28 <sgothel> sure .. may take time to be adopted, similar to GL-FFP -> GL-PP
20151126 23:21:42 <gouessej> Google doesn't like OpenCL :)
20151126 23:22:07 <sgothel> well .. they have to support it some day
20151126 23:22:39 <gouessej> Google should stop blocking it under Android, I agree with Xerxes
20151126 23:23:53 <sgothel> Google, one of many vendors ..
20151126 23:24:11 <gouessej> Apple too
20151126 23:24:17 <gouessej> I won't use Metal
20151126 23:24:40 <gouessej> Lol it makes me think about ... Mittal ;)
20151126 23:25:05 <sgothel> I keep saying for years .. Apple is not relevant as a generic and universal mobile platform for [serious|vertical] applications
20151126 23:25:29 <gouessej> http://economictimes.indiatimes.com/photo/20253813.cms
20151126 23:26:00 <sgothel> you have just widened my horizon, sir :)
20151126 23:26:56 <sgothel> https://github.com/fancycode/MemoryModule/blob/master/MemoryModule.c <- browsing through ..
20151126 23:27:19 <sgothel> and 'holy moly' that introduces a bunch of other API functions and PE parsing ..
20151126 23:27:35 <sgothel> so I would prefer having a 'more simple' solution :)
20151126 23:27:58 <sgothel> i.e. who is testing this bunch of code/API usage?
20151126 23:28:16 <gouessej> That's why I suggested a less impacting fallback
20151126 23:28:24 <sgothel> hehe .. thank you
20151126 23:28:58 <gouessej> This thing would be awesome for JOGL 3 or 4
20151126 23:29:09 <sgothel> yeah .. maybe NIO2 first if available -> dir-set2; then 'try loading a dll' -> dir-set3
20151126 23:29:37 <sgothel> if dll loading does not work .. well .. nothing we can do here anyways
20151126 23:29:52 <sgothel> at least we get rid of the exe test
20151126 23:29:58 <gouessej> Yes
20151126 23:30:02 <sgothel> but a virus scanner may hit here as well of course
20151126 23:30:07 <sgothel> but then it may hit anyways
20151126 23:30:21 <gouessej> Yes, it's a crappy kind of software
20151126 23:30:31 <gouessej> it shouldn't even exist
20151126 23:30:38 <sgothel> snake oil - always later, exposing even more backdoors
20151126 23:30:45 <sgothel> *always late*
20151126 23:31:34 <gouessej> Do you find MemoryModule interesting as a solution on the long term to replace the temporary cache?
20151126 23:31:55 <sgothel> it is interesting for sure
20151126 23:32:06 <sgothel> but we need to extract the jar file anyways
20151126 23:32:21 <sgothel> however, that could get rid of the 'dll copy' we need for each VM instance
20151126 23:32:34 <sgothel> which we do hold in the temp-cache
20151126 23:32:49 <sgothel> then we would need a POSIX way of things as well
20151126 23:33:51 <sgothel> having such a piece of code exposed is quite dangerous though
20151126 23:34:21 <sgothel> i.e. make some native memory, load it as dll .. overriding existing entries
20151126 23:34:36 <gouessej> Why would we need to extract the JAR file? I mean that nothing would force us to keep the decompressed content into a file in the file system
20151126 23:34:45 <sgothel> so .. surely must be used carfully (-> time)
20151126 23:35:01 <sgothel> jar file is compressed?
20151126 23:35:16 <gouessej> you remind me another problem
20151126 23:35:30 <gouessej> there is a problem with a setting on our server
20151126 23:35:41 <gouessej> a problem of file compression
20151126 23:35:59 <gouessej> I don't remember exactly, you'll have to look at the logs
20151126 23:36:20 <gouessej> When someone downloads a JAR, it is wrapped into a ZIP
20151126 23:36:22 <sgothel> you mean downloading a compressed file, which is decompressed by the client (browser)
20151126 23:36:34 <sgothel> yeah .. a browser thing IMHO .. no?
20151126 23:36:44 <gouessej> I thought it was caused by a "security" feature of Firefox under Windows but maybe there is something wrong on our side
20151126 23:36:46 <sgothel> or can we change a mime type?
20151126 23:36:56 <sgothel> wget works though
20151126 23:37:00 <gouessej> yes
20151126 23:37:05 <gouessej> I confirm it works
20151126 23:37:39 <sgothel> look at /srv/www/jogamp.org/deployment/.htaccess
20151126 23:37:47 <gouessej> rmk0_: Do you remember what I mean??
20151126 23:38:16 <sgothel> that htaccess files contains rules for .jar gzip, pack200 etc
20151126 23:39:06 <gouessej> "but we need to extract the jar file anyways". Why?
20151126 23:39:23 <sgothel> they are compressed
20151126 23:39:34 <sgothel> i.e. pack200, gzip .. etc
20151126 23:39:37 <rmk0_> gouessej: i remember it happening, i don't fully understand why
20151126 23:40:17 <sgothel> the htaccess file renames the jar.pack.gz etc -> jar
20151126 23:40:39 <sgothel> i.e. rewriting request rules .. i.e. serving a pack200.gz file for a jar request
20151126 23:40:57 <sgothel> reducing the download
20151126 23:42:01 <sgothel> if we need 'download a jar file' untouched .. or something, find the apache2 htaccess rules ..
20151126 23:42:14 <sgothel> then we may can put them into a subfolder
20151126 23:42:51 <sgothel> and/or study our htaccess file, maybe something is wrong
20151126 23:43:43 <sgothel> MemoryModule seems to request immutable memory 'if desired', it seems - good
20151126 23:44:24 <sgothel> https://github.com/fancycode/MemoryModule/blob/master/MemoryModule.c#L189
20151126 23:44:42 <gouessej> :)
20151126 23:45:18 <sgothel> (but it also copied the memory .. i.e. no performance win win)
20151126 23:46:47 <gouessej> I would just like to get rid of the temp cache without having to set the Java library path :)
20151126 23:47:05 <sgothel> but the temp cache is also used for other things
20151126 23:47:15 <sgothel> i.e. we load our assets from there
20151126 23:47:34 <sgothel> i.e. the temp-cache/jar tools are a manual resource-loader already
20151126 23:47:44 <sgothel> (class, libs, stuff ..)
20151126 23:47:58 <gouessej> ok but we wouldn't have to handle the executable bits for the assets
20151126 23:48:25 <sgothel> yes .. I just wanted to complete the 'view' of our tool :)
20151126 23:48:36 <gouessej> thanks, you're right
20151126 23:49:44 <sgothel> having my 'integrator' hat on, putting this stuff into jogamp would be a headache .. still, lets see how things go. a great idea for sure!
20151126 23:51:15 <gouessej> Maybe it's a wrong solution. If there are too much problems with the virus scanners, I'll have to use the Java library path but those craps will still sometimes block the DLLs of JOGL
20151126 23:51:35 <sgothel> we cannot fight the virus scanner
20151126 23:51:59 <sgothel> but you could try to talk to 'em ..
20151126 23:52:27 <gouessej> If the virus scanners know that we can store native libraries within JARs and load from them, they will scan them differently :s
20151126 23:52:39 <gouessej> My suggestion might cause some other problems
20151126 23:53:08 <sgothel> 'store native libraries within JARs and load from them' <- that is a normal java app using JNI
20151126 23:53:15 <sgothel> applets, jnlp ..
20151126 23:53:46 <sgothel> java does the same, just in their own java cache
20151126 23:53:58 <gouessej> I meant without extracting the native libraries into a temporary cache
20151126 23:54:11 <sgothel> still: technically .. the same
20151126 23:54:18 * bigpet (uid25664@anon) Quit (*.net *.split)
20151126 23:54:50 <gouessej> When we extract the native libraries from the JARs, there are independent files representing them with the correct extensions
20151126 23:55:02 <sgothel> they just don't handle the 'one dll file location per JVM/ClassLoader instance'
20151126 23:55:05 <gouessej> it gives the virus scanners some opportunities to scan them
20151126 23:55:20 <sgothel> the JRE puts them as files like 00101001
20151126 23:55:45 <sgothel> a virus scanner usually checks the content, not just file names :)
20151126 23:55:56 <gouessej> The virus scanners probably read the headers, don't they?
20151126 23:56:04 <sgothel> hooking (overriding) the windows API .. etc .. horrible
20151126 23:56:09 <sgothel> yes
20151126 23:56:16 <sgothel> of all files being opened
20151126 23:56:35 <gouessej> When they read the header of a JAR, they don't expect to find a native library inside it
20151126 23:56:56 <gouessej> they don't imagine that we might succeed in loading a DLL without extracting it into a separate file
20151126 23:57:01 <sgothel> if we write the dll to a file .. they may hit
20151126 23:57:21 <sgothel> again: the JRE does the same .. i.e. loading a native jar file
20151126 23:57:27 <sgothel> via jnlp desciptor
20151126 23:57:44 <sgothel> extracting that file in the java temp cache folder
20151126 23:57:49 <sgothel> then loading it later on
20151126 23:58:03 <gouessej> Yes but it doesn't use MemoryModule or something similar, right?
20151126 23:58:18 <sgothel> nope .. just plain stuff .. as we do
20151126 23:58:58 <sgothel> the temp-cache folder is added to the ClassLoader's resources
20151126 23:59:08 <sgothel> hence you can find things in there
20151126 23:59:11 <gouessej> Using MemoryModule would encourage the virus scanners to scan JARs differently as maybe we could load the native libraries directly from the JARs
20151126 23:59:30 <sgothel> you need to extract the compressed jar file
20151126 23:59:37 <gouessej> That's why I fear that my suggestion isn't as good as I thought
20151127 00:00:00 <sgothel> so you would need to do that all in memory (ouch) .. if not wanting to hit a scanners rules :)
20151127 00:00:14 <gouessej> The rules might change :s
20151127 00:00:40 <sgothel> scanner ofc can also extract all compressed files if loaded (file, http stream, ..)
20151127 00:00:54 <sgothel> and check its content .. at least they do that for zip files etc
20151127 00:01:00 <sgothel> hence they slow down everything
20151127 00:01:26 <sgothel> in short: this will not avoid the virus scanner issuer - no guarantee
20151127 00:01:56 <sgothel> you could encode the dll in a file, so it goes undetected 'for a while' :)
20151127 00:02:06 <gouessej> lol
20151127 00:02:09 <sgothel> evil virus you write then :)
20151127 00:02:48 <sgothel> question here: how many hours we want to spent on this 'feature'?
20151127 00:03:08 <gouessej> If there is no plus value, we can spend 0 hour
20151127 00:03:31 <sgothel> I would like that :)
20151127 00:03:59 <gouessej> The NIO 2 fallback seems to be more promising
20151127 00:04:23 <sgothel> .. and we might still need to test the dll ..
20151127 00:04:33 <gouessej> yes
20151127 00:04:33 * bigpet (uid25664@anon) has joined #jogamp
20151127 00:04:40 <sgothel> so this is not a remedy for virus .. its the other 'hanging process' issue
20151127 00:05:03 <sgothel> i.e. exe rules may be within windows .. or server, not accessible via permission bits
20151127 00:05:14 <sgothel> even ACL ones ..
20151127 00:05:42 <sgothel> so I will try the dll thing instead of exe .. and we will see who complains then
20151127 00:06:01 <sgothel> since we need to load dll files anyways, but not execute exe files
20151127 00:06:33 <sgothel> 'load dll files' directly or indirect (memory.. thingy)
20151127 00:06:50 <sgothel> doesn't matter here, iff there is at least one exe folder
20151127 00:06:57 <sgothel> so .. forget the virus scanner
20151127 00:07:22 <gouessej> Is there a mean of choosing the location of the temporary cache?
20151127 00:07:25 <sgothel> memorymodule can remedy issue w/ boxes w/o exe permission folder
20151127 00:07:32 <sgothel> sure
20151127 00:08:46 <gouessej> Is it possible to extract everything and package that as is so that there is no need of temporary cache?
20151127 00:08:54 <sgothel> env vars: TEMP, TMP - property: java.io.tmpdir
20151127 00:09:29 <gouessej> I thought that we had our own property
20151127 00:09:43 <sgothel> let me see ..
20151127 00:10:03 <gouessej> I need to reduce the startup time, that's why I ask this question
20151127 00:10:09 <gouessej> It's for JNDT
20151127 00:10:36 <sgothel> JNDT?
20151127 00:10:43 <gouessej> http://tuer.sourceforge.net/en/download/#jndt
20151127 00:11:04 <gouessej> it's a bit documented now
20151127 00:11:58 <sgothel> one hack would be to indeed reuse the primary cache folder, where one extracts the fat binary (containing class + libs)
20151127 00:12:16 <sgothel> but that would only work for one JVM/ClassLoader instance!
20151127 00:12:34 <gouessej> better than nothing
20151127 00:12:35 <sgothel> i.e. a 'reuse primary temp cache' short-cut
20151127 00:13:33 <sgothel> maybe you like to add this feature to our temp cache thing? .. i.e. create an instance of our TempCache re-using that folder?
20151127 00:13:37 <sgothel> that comes to mind
20151127 00:14:07 <gouessej> Why not? but I have to understand how it works first.
20151127 00:14:31 <sgothel> do you have a test project for JNDT?
20151127 00:14:38 <gouessej> TUER uses JNDT
20151127 00:14:41 <sgothel> i.e. some unit test?
20151127 00:14:53 <sgothel> i.e. pull stuff .. build .. and see how it works?
20151127 00:15:07 <sgothel> shell scripts .. whatever included?
20151127 00:15:32 <gouessej> It's based on Ant
20151127 00:15:53 <gouessej> There are just 4 Ant targets
20151127 00:16:18 <sgothel> so which temp-cache folder do you use w/ exe permissions?
20151127 00:16:24 <sgothel> i.e. same issue .. isn't it?
20151127 00:17:32 <gouessej> I use the default temporary directory for now but I'd like to eliminate decompression at startup even though it would lead to increase the size of the bundles
20151127 00:18:23 <sgothel> all research says: compression is better for download, despite decompression time
20151127 00:18:39 <sgothel> lmza is best AFAIK, even used in ZFS regularly
20151127 00:18:46 <sgothel> lzma .. oops :)
20151127 00:19:44 <gouessej> My problem isn't the download. The problem is that it takes too much time to start on some low end hardware and I need something more reliable that just uses the files coming from the bundle and nothing less
20151127 00:19:51 <gouessej> nothing else
20151127 00:19:59 <gouessej> no temporary directory
20151127 00:20:05 <sgothel> open-zfs.org/w/images/4/4d/Compression-Saso_Kiselkov.pdf
20151127 00:22:00 <gouessej> I have to go to bed. Bye. Good night
20151127 00:22:04 <sgothel> hmm .. then an archive filesystem ..
20151127 00:22:06 <sgothel> good night
20151127 00:22:13 * gouessej (5279482a@anon) Quit (Quit: Page closed)
20151127 00:23:29 <sgothel> 80min session - catching up w/ communication I guess :)
20151127 00:25:35 <sgothel> http://wiki.illumos.org/display/illumos/LZ4+Compression <- LZ4 real-time algo it was .. not lzma ..
20151127 00:29:07 <sgothel> http://catchchallenger.first-world.info//wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO#Compression_time
20151127 00:29:23 <sgothel> ^^ a memory hog though .. but who cares nowadays? :)
20151127 02:00:35 * i-make-robots (~dan@anon) Quit ()
20151127 03:32:54 * darkfrog1 (~mhicks@anon) Quit (Remote host closed the connection)
20151127 06:22:33 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151127 06:23:37 * sgothel (~sgothel@anon) Quit (Ping timeout: 264 seconds)
20151127 06:38:29 * sgothel (~sgothel@anon) has joined #jogamp
20151127 06:38:29 * ChanServ sets mode +v sgothel
20151127 07:54:00 * elect (~GBarbieri@anon) has joined #jogamp
20151127 08:29:57 * bruce- (~x@anon) Quit (*.net *.split)
20151127 08:30:00 * bruce- (~x@anon) has joined #jogamp
20151127 08:41:40 * bruce- (~x@anon) Quit (*.net *.split)
20151127 09:03:01 * elect (~GBarbieri@anon) Quit (*.net *.split)
20151127 09:03:14 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 09:12:57 * bigpet (uid25664@anon) has joined #jogamp
20151127 09:34:15 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 09:34:47 * bigpet (uid25664@anon) has joined #jogamp
20151127 09:36:08 <zubzub> /quit
20151127 09:36:08 <zubzub> ugh spaces
20151127 09:36:08 * zubzub (~zubzub@anon) Quit (Quit: leaving)
20151127 09:44:41 * elect (~GBarbieri@anon) has joined #jogamp
20151127 09:58:07 * zubzub (~zubzub@anon) has joined #jogamp
20151127 10:04:05 * bruce- (~x@anon) has joined #jogamp
20151127 10:21:36 * doev (~doev@anon) has joined #jogamp
20151127 10:28:48 * bruce-_ (~x@anon) has joined #jogamp
20151127 10:34:44 * doev (~doev@anon) Quit (*.net *.split)
20151127 10:34:56 * bruce- (~x@anon) Quit (*.net *.split)
20151127 10:34:57 * zubzub (~zubzub@anon) Quit (*.net *.split)
20151127 10:35:21 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 10:42:44 * bigpet (uid25664@anon) has joined #jogamp
20151127 10:46:12 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 10:46:52 * bigpet (uid25664@anon) has joined #jogamp
20151127 10:58:45 <xranby> sgothel: hi, and welcome back! I have prepared a small pull request https://github.com/sgothel/gluegen/pull/31
20151127 10:58:50 <xranby> fixes documentation
20151127 11:00:11 <xranby> and examples
20151127 11:04:03 -mquin- [Global Notice] We are again experiencing connectivity problems to some servers due to DDoS attacks. Please bear with us while we ride it out.
20151127 11:04:25 <xranby> sgothel: we are staying warm heating by burning bio mass
20151127 11:05:38 <xranby> however, you sill have to be caucious getting outside.. the cold managed to freeze the car door after entering it, causing me to be locked inside the car! I had to excape using one of the rear doors that furtunally had note jammed the lock mechanism
20151127 11:06:09 <xranby> things like that usually happens when it is getting colder
20151127 11:09:02 <xranby> right now.. they are conducting the lead ion high energy atom smashing at the LHC
20151127 11:09:21 <xranby> https://op-webtools.web.cern.ch/op-webtools/vistar/vistars.php?usr=LHC1 <- ** STABLE BEAMS**
20151127 11:10:28 <xranby> when they accelerate these ion atom nucleus to the speed of light, all increased energy to the ion's makes the ions heavyer instead of goin faster
20151127 11:10:58 <xranby> the heavyness is measured in GeV
20151127 11:12:10 <xranby> right now they have some quite extordinary excited nucleus at 5000 GeV for each beam!
20151127 11:12:28 * zubzub (~zubzub@anon) has joined #jogamp
20151127 11:13:53 <xranby> in the following days they will release many nice visualization images from the detector chambers visualized using JogAmp JOGL and the FROG library
20151127 11:15:36 <xranby> The first released images of JogAmp JOGL FROG visualizations from these lead - lead ion smashes can be seen here: https://twitter.com/CERN/status/669511873264529408
20151127 11:18:59 <xranby> http://frog.hepforge.org/
20151127 11:24:48 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 11:25:27 * zubzub (~zubzub@anon) Quit (Ping timeout: 264 seconds)
20151127 11:25:42 * bruce-_ (~x@anon) Quit (Ping timeout: 264 seconds)
20151127 11:36:14 * bigpet (uid25664@anon) has joined #jogamp
20151127 11:37:48 <rmk0_> CERN are using JOGL?
20151127 11:43:48 * xranby (~xranby@anon) Quit (*.net *.split)
20151127 12:03:37 * xranby_netsplit (d5866a3d@anon) has joined #jogamp
20151127 12:04:01 <xranby_netsplit> rmk0_: Yes LHC is using JogAmp JOGL for visualizations
20151127 12:04:26 <xranby_netsplit> CERN is using JogAmp
20151127 12:07:31 <xranby_netsplit> http://www.hep.ucl.ac.uk/theses/AdamDavisonThesis.pdf <- page 110 explain CERN's reasoning why they picked JogAmp JOGL
20151127 12:09:02 <xranby_netsplit> for visualizations for the ATLAS detector
20151127 12:10:33 <xranby_netsplit> Atlantis is the software they use to control the ATLAS detector
20151127 12:12:01 * doev (~doev@anon) has joined #jogamp
20151127 12:17:04 * zubzub (~zubzub@anon) has joined #jogamp
20151127 12:29:34 * doev (~doev@anon) Quit (Quit: Verlassend)
20151127 12:30:00 <rmk0_> nice
20151127 12:37:19 * bruce- (~x@anon) has joined #jogamp
20151127 12:42:04 <xranby_netsplit> http://atlas-live.cern.ch/ <- live and near live view of proton smashes recoded using the Atlantis software (using JOGL)
20151127 12:49:35 * badshah400 (~badshah40@anon) has joined #jogamp
20151127 12:54:51 * xranby_netsplit (d5866a3d@anon) Quit (Ping timeout: 246 seconds)
20151127 13:01:01 * xranby_netsplit (d5866a3d@anon) has joined #jogamp
20151127 13:01:41 <xranby_netsplit> https://lists.fosdem.org/pipermail/java-devroom/2015-November/000142.html <- FOSDEM 2016 Java Dev room deadline is set to Friday 11th December 1015 23.59 CET
20151127 13:05:34 <xranby_netsplit> At the moment there exist much time for long talks as only 5 submissions have been sent in for this years fosdem 2015 java-devroom: https://lists.fosdem.org/pipermail/java-devroom/2015-November/thread.html
20151127 13:11:01 <xranby_netsplit> https://lists.fosdem.org/pipermail/java-devroom/2015-October/000136.html <- Free Java Dev Room Call For Participation
20151127 13:11:03 * jvanek (jvanek@anon) has joined #jogamp
20151127 13:11:42 <xranby_netsplit> A template for submitting a talk can be found at: https://wiki.debian.org/Java/DevJam/2016/Fosdem/CallForParticipation
20151127 13:14:07 * xranby (~xranby@anon) has joined #jogamp
20151127 13:24:50 * xranby (~xranby@anon) Quit (Ping timeout: 264 seconds)
20151127 13:30:31 * xranby_netsplit (d5866a3d@anon) Quit (Quit: Page closed)
20151127 13:35:25 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20151127 13:41:44 * xranby (~xranby@anon) has joined #jogamp
20151127 14:27:16 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 14:48:23 * bigpet (uid25664@anon) has joined #jogamp
20151127 16:39:38 * elect (~GBarbieri@anon) Quit (Ping timeout: 260 seconds)
20151127 16:46:41 * bigpet (uid25664@anon) Quit (*.net *.split)
20151127 16:56:17 * bigpet (uid25664@anon) has joined #jogamp
20151127 17:44:36 * monsieur_max (~maxime@anon) has joined #jogamp
20151127 22:11:39 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20151128 02:10:19 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151128 02:13:42 * badshah400 (~badshah40@anon) has joined #jogamp
20151128 05:06:06 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20151128050606.html