JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20150703 05:06:23 (UTC)

20150703 05:06:23 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150701144722.html
20150703 05:06:23 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150703050623.html
20150703 05:38:32 * bigpet (uid25664@anon) has joined #jogamp
20150703 06:19:44 * elect (~elect@anon) has joined #jogamp
20150703 06:30:03 <elect> hi
20150703 06:35:49 * monsieur_max (~maxime@anon) has joined #jogamp
20150703 06:36:02 * monsieur_max (~maxime@anon) Quit (Client Quit)
20150703 07:11:01 * rmk0_ (~rmk0@anon) has joined #jogamp
20150703 07:11:06 * rmk0 (~rmk0@anon) Quit (Ping timeout: 250 seconds)
20150703 07:25:53 * eclesia (~husky@anon) has joined #jogamp
20150703 07:26:01 <eclesia> good morning
20150703 07:28:15 * eclesia (~husky@anon) has left #jogamp
20150703 07:28:20 * eclesia (~husky@anon) has joined #jogamp
20150703 07:30:26 * monsieur_max (~maxime@anon) has joined #jogamp
20150703 07:34:56 <elect> hey
20150703 08:31:59 <sgothel> ho
20150703 09:06:48 <eclesia> sgothel: jgod , banzai !
20150703 09:07:55 <sgothel> [1] *you shall not complain w/o a bugreport and unit test* :)
20150703 09:08:51 <sgothel> 32C .. not used to warm weather anymore .. they say Sahara winds or something .. :)
20150703 09:09:32 <zubzub> 32?
20150703 09:09:33 <zubzub> pussy
20150703 09:09:41 <zubzub> 2 days ago it was 39.4 here
20150703 09:09:42 <sgothel> hehe
20150703 09:09:51 <zubzub> all time record
20150703 09:10:01 <zubzub> 40 in some places even
20150703 09:10:12 <sgothel> humidity is 77% though .. hmm
20150703 09:10:36 <sgothel> right .. it was just cold here lately
20150703 09:11:54 <xranby> remember if you want to stay out and survive without risk of dehydration then wear a lot of clothes!
20150703 09:12:21 <xranby> when you are outside you practically put yourself in a fusion dryer
20150703 09:12:22 <sgothel> .. containing all sweat for reuse later :)
20150703 09:12:47 <sgothel> depends on the humidity .. :)
20150703 09:12:49 <xranby> and as you all know clothes that you put on a drying rack do not dry if you put too many layers next to each other
20150703 09:12:57 <eclesia> black plastique bag are fashion ourdays too
20150703 09:13:36 <sgothel> those 'sexy things' .. thought 'they' use latex :)
20150703 09:13:40 <xranby> yes, you will feel moisturised and survive for ohurs
20150703 09:14:08 <xranby> ... also if you do feel dehydrated, only drinking water do not help
20150703 09:14:10 <sgothel> but then .. sweat needs to evaporate to help balancing the body temp.
20150703 09:14:22 <xranby> you need to drink paritally salted water
20150703 09:15:25 <xranby> so to sum it up.. eat salt food and drinking water in the sun do help
20150703 09:15:32 <sgothel> well .. we just drink normal groundwater here from the tap, not condensed water :)
20150703 09:15:38 <xranby> and wrap yourself in a rug
20150703 09:15:46 <sgothel> and put water on top :)
20150703 09:16:00 <xranby> yes yes.. else you turn into a stemed burrito
20150703 09:16:09 <xranby> steamed
20150703 09:16:24 <sgothel> make two holes for your arms .. and continue hacking then :)
20150703 09:16:37 <sgothel> isolated keyboard .. ofc
20150703 09:17:37 <xranby> with i had an furtine telling eightball ball to guide me while debugging
20150703 09:17:51 <xranby> can it be that mesa3d is not threadsafe while initializing?
20150703 09:18:24 <xranby> as i understand it jogl runs the probing of mesa3d in parallel
20150703 09:18:26 <sgothel> hmm .. JOGL initialization is single-threaded
20150703 09:18:49 <sgothel> GLProfile kicks it off .. within exclusive thread .. which blocks until done
20150703 09:19:19 <xranby> during debugging of https://jogamp.org/bugzilla/show_bug.cgi?id=1166 i have can trigger the crash in three different scenarios.. looks like a race to me duing static initialization
20150703 09:19:20 <sgothel> *the startup profile probing*
20150703 09:21:00 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1166#c4 ?
20150703 09:21:07 <sgothel> what happens first here ?
20150703 09:21:16 <sgothel> i.e. the Mesa debug logs .. then the crash ?
20150703 09:21:28 <sgothel> or the crash (stack trace) within the logs ?
20150703 09:21:42 <sgothel> guess 'bt' after logs .. right ?
20150703 09:22:17 <sgothel> so then, I guess: Mesa fails to init due to failing to load mali-drm -> then glXChooseFBConfig fails and crashes ..
20150703 09:23:23 <sgothel> the latter crash does not seem to be due to JOGL .. hmm but let me double check Java_jogamp_opengl_x11_glx_GLX_dispatch_1glXChooseFBConfig
20150703 09:23:49 <xranby> sgothel: i will update the bug later this evening, the mesa 3d debug logs output is generated two calls earlier to mesa before the call that triggers the crash i can find out which one by passing -Xverbose:jni
20150703 09:23:50 <sgothel> jogl/make/config/jogl/glx-CustomCCode.c
20150703 09:24:53 <sgothel> yes - our bug! XFree on _res, where it might be NULL .. hmm, XFree: A NULL pointer cannot be passed to this function.
20150703 09:25:28 <sgothel> editing bug report ..
20150703 09:26:51 <sgothel> Nope: if (NULL == _res) return NULL;
20150703 09:26:57 <sgothel> so we check the result .. hmm
20150703 09:27:15 <sgothel> seems like the result is != NULL .. and XFree crashes
20150703 09:27:30 <sgothel> this could only mean that result is invalid .. -> driver error
20150703 09:28:44 <xranby> sgothel: yes the crash logs do not make sence... for example in https://jogamp.org/bugzilla/show_bug.cgi?id=1166#c2 and https://jogamp.org/bugzilla/show_bug.cgi?id=1166#c3 we can trigger a crash in hotspot, for a function that shall accept any object thus it looks to me that the heap is all corrupt
20150703 09:30:13 <xranby> after mesa3d have pruinted the debug output then we crash later in A) hotspot B) GLX C) libxrender if i rerun the runtime verison check its kind of random where the crash ends up
20150703 09:30:27 <xranby> i can reproduce the bug repeatedly while running the runtime version check
20150703 09:30:53 <xranby> sh etc/test.sh
20150703 09:31:06 <xranby> i fail to reproduce the bug when enable debugging
20150703 09:31:10 <sgothel> how about using Mesa software renderer ?
20150703 09:31:12 <xranby> sh etc/test_dbg.sh
20150703 09:31:38 <xranby> sgothel: i expected mesa 3d to list doftware rendering like it did before and not make jogl crash
20150703 09:31:42 <sgothel> so even a JDK issue on that particular platform ?
20150703 09:31:43 <xranby> list software rendering
20150703 09:32:13 <sgothel> export LIBGL_ALWAYS_SOFTWARE=true
20150703 09:32:19 <xranby> i can try that
20150703 09:32:28 <sgothel> export LIBGL_DEBUG=verbose
20150703 09:32:28 <sgothel> export MESA_DEBUG=true
20150703 09:32:56 <sgothel> but well, if glxgears works .. w/ that driver .
20150703 09:33:21 <xranby> glxgears also output the mesa debug log warning
20150703 09:33:31 <sgothel> hmm
20150703 09:33:35 <xranby> yet it do not crash
20150703 09:33:42 <xranby> it runs
20150703 09:33:52 <sgothel> 'glxgears -info' ?
20150703 09:33:56 <sgothel> which renderer ?
20150703 09:34:16 <xranby> out of my head it said software rendering
20150703 09:34:21 <xranby> i am at work right now
20150703 09:34:23 <sgothel> I assume not the mali one then? since it complained? right ..
20150703 09:34:31 <xranby> i have the dev board at home that can generate the crash
20150703 09:34:35 <sgothel> ah
20150703 09:34:41 <xranby> its a mali gpu
20150703 09:34:48 <xranby> and mesa3d do not have a driver for this gpu
20150703 09:35:19 <sgothel> sound more like a config hell .. Ubuntu I read .. well :)
20150703 09:35:39 <xranby> if you only use the arm mali driver then opengl es works fine
20150703 09:35:43 <sgothel> I remember those 'blobs' using Mesa libGL dispatcher things .. ahem
20150703 09:36:06 <sgothel> so .. then just do that, since all other things are probably not supported by that blob
20150703 09:36:27 <sgothel> only Ubuntu tires to impl. libGL this way .. we already had this discussion a while ago .. AFAIK
20150703 09:36:53 <sgothel> use Debian .. or 'rm libGL.*'
20150703 09:37:08 <xranby> i will try understand why it is crashing a bit more.. before i give up and claim it is simply a libgl misconfiguration error
20150703 09:37:39 <xranby> it puzzles me why i cant trigger the crash when running the jogamp test_dbg.sh
20150703 09:37:52 <xranby> and can trigger the crash when running the test.sh
20150703 09:38:41 <sgothel> sure .. the debug code results in a different heap .. so the existing bug may not trigger a crash here
20150703 09:39:11 <sgothel> valgrind or other heap-safe measures may allow it to crash properly and reliably
20150703 09:40:25 <xranby> i ran valgrind on the test.sh and it did not find anything suspicious untill the last xfree
20150703 09:40:40 <xranby> it only found some minor memory leak of 16k memory
20150703 09:41:18 <xranby> i will try use it on the test_dbg.sh and see if i can trigger the crash
20150703 09:41:19 <sgothel> Q: why is the glX* call returning non NULL then ?
20150703 09:41:26 <sgothel> what is the resulting count ?
20150703 09:42:04 <sgothel> ^^ count = _nitems_ptr[0];
20150703 09:43:40 <xranby> i can add some debuging code to https://github.com/sgothel/jogl/blob/master/make/config/jogl/glx-CustomCCode.c#L87 and check later
20150703 09:44:21 <sgothel> if _res is != NULL, but not pointing to a valid memory region, the error is propagated to the JVM via JVMUtil_NewDirectByteBufferCopy (and yes, mind the memove in the code, i.e. _res is 'GLXFBConfig *' <- an array)
20150703 09:44:25 <xranby> i have checked that dpy is not null
20150703 09:44:43 <xranby> i realized that we did not check if dpy was null.. at least it is not null
20150703 09:44:56 <sgothel> thats done from java ..
20150703 09:45:19 <xranby> screen is 0 and i guess that is "normal"
20150703 09:45:38 <sgothel> yes .. the 'big desktop normal' <- xinerama
20150703 09:48:14 <xranby> sgothel: my impression has been that we do pass valid arguments to all glx functions when i stepped around inside this function in gdb
20150703 09:48:40 <sgothel> sure .. otherwise we would fail on many, if not all X11 platforms
20150703 09:49:00 <xranby> yup
20150703 09:49:19 <xranby> i am think ful that it do crash early in initialization
20150703 09:49:26 <xranby> thats why i still have hope this can be workaround
20150703 09:49:27 <sgothel> that code works for quite some time .. and has been enhanced (removing null entries in table/array via memmove .. etc)
20150703 09:50:50 <sgothel> fdea8596b2ccc1221a980e4c9fd10de85d885a3c <- Bug 961: Fix commit fdd60adb1d421f2018b47ee17e9079c94b54910f (memmove byte-count) .. etc
20150703 09:51:06 * eclesia wants dialogs and drag&drop :'(
20150703 09:51:13 <sgothel> Bug 961: Stabilize glXGetFBConfigAttrib(..) and glXChooseFBConfig(..) Usage Against OpenGL Bugs ; Fix glXGetFBConfigs
20150703 09:51:29 <sgothel> don't scare me w/ my intended first day in *public office* :)
20150703 09:52:09 <sgothel> btw .. while I understand your desire to interact w/ the native windowing system ..
20150703 09:52:44 <sgothel> the GraphUI design choice is to render the windows ourselves .. and dialogs etc, i.e. not using the native WM
20150703 09:53:07 <sgothel> however .. it drag&drop it can be integrated .. we can do that
20150703 09:54:14 <sgothel> but before all that .. I have to play catch-up w/ bugs, it seems
20150703 09:54:34 <eclesia> I see it as somekind of attachement on the mouse drag event
20150703 09:54:52 <eclesia> completly separate from windows stuffs
20150703 09:54:57 <sgothel> yup .. in KDE/Dolphin .. its the file URI it seems
20150703 09:55:26 <sgothel> so pls make a use case (NEWT X11 code) ..
20150703 09:55:33 <eclesia> ha, you had a look already ?
20150703 09:55:57 <sgothel> ofc I look at things. the drag and drop event is an X11 event though ..
20150703 09:56:15 <sgothel> but not as deeply looking like coding .. yet
20150703 10:41:25 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20150703 14:54:03 * monsieur_max is now known as Bod
20150703 15:03:24 * elect (~elect@anon) Quit (Ping timeout: 264 seconds)
20150703 15:06:04 * Bod is now known as max_monsieur
20150703 15:06:53 * max_monsieur is now known as monsieur_max
20150703 15:07:55 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150703 16:02:45 * eclesia (~husky@anon) has left #jogamp
20150703 16:16:35 * monsieur_max (~maxime@anon) has joined #jogamp
20150703 16:43:24 * elect (~elect@anon) has joined #jogamp
20150703 16:46:24 * bigpet (uid25664@anon) Quit ()
20150703 16:46:41 * bigpet (uid25664@anon) has joined #jogamp
20150703 17:13:09 * elect (~elect@anon) Quit (Ping timeout: 276 seconds)
20150703 18:06:11 * Eclesia (~eclesia@anon) has joined #jogamp
20150703 18:56:48 <Eclesia> sgothel: would that help if I write the classes/doc for drag&drop attachments ?
20150703 19:03:12 <sgothel> not before we know the API details of all other WMs .. so we can match the common denominator somewhat
20150703 19:03:23 <sgothel> hence - usually, we start w/ a tech-prototype ..
20150703 19:03:30 <sgothel> then we understand ..
20150703 19:03:36 <sgothel> then we assume our API ..
20150703 19:03:44 <sgothel> at least .. this is what I usually do :)
20150703 19:03:55 <sgothel> requirements are clear I guess ..
20150703 19:05:33 <Eclesia> sgothel: I work the opposite most of the time :D . design the API as it should be, write several implementation, find api weakness and incompatibilities with implementations. update API if needed.
20150703 19:06:01 <sgothel> if *creating* something, sure .. 1) req 2) api
20150703 19:06:23 <sgothel> but here .. 1st we shall fully understand what d&d gives us on all major WMs ..
20150703 19:06:35 <sgothel> i.e. understand their API right .. we are merely a binding to it
20150703 19:07:03 <sgothel> hence a tech-proto using one API at least .. proving it is understood
20150703 19:07:35 <sgothel> then doing win32 and OSX .. then fine grain and discuss NEWT API w/ all this insight .. IMHO
20150703 19:08:05 <sgothel> *or* study all d&d APIs totally dry (no code) .. an go on .. :) - not my kind of beef
20150703 19:09:20 <sgothel> I wish we can do it event driven .. i.e. a new input event for NEWT
20150703 19:09:25 * Eclesia see something really basic, drag has an AttachContainer. AttachContainer has a list of Attachments. An Attachment has 2 properties : String getMimeType, Object getValue() .
20150703 19:09:32 <sgothel> but writing its API first .. is a waste of time IMHO
20150703 19:11:48 <sgothel> maybe .. should be proven by impl/reading it for our 3 major WMs .. I mean, you can simply go on hacking one POC for X11, which would be great
20150703 19:12:44 <sgothel> wasn't it you who doesn't like to optimize before the POC?
20150703 19:13:06 <Eclesia> that's right
20150703 19:13:18 <Eclesia> API is not optimization
20150703 19:13:31 <sgothel> depends on the angle ..
20150703 19:13:50 <sgothel> its is the ultimate description .. which should be matched by the impl. ofc :)
20150703 19:13:58 <sgothel> or the other way around :)
20150703 19:14:26 <sgothel> ^^ just my opinion
20150703 19:15:20 <sgothel> having an API draft referencing all the underlying native WMs .. would be very helpful for implementing it ofc
20150703 19:15:36 <sgothel> ^^ the dry approach ..
20150703 19:15:54 <sgothel> then .. why not implementing it afterwards right away? :)
20150703 19:16:29 <sgothel> sure .. its all iterative
20150703 19:16:29 <Eclesia> if the api is driven by the implementation, then it's more likely to change. Imagining it before it is actually implemented avoid you to be influence by someone else technical choices
20150703 19:16:55 <Eclesia> sure it's iterative anyway :)
20150703 19:17:12 <sgothel> iterative it is .. since we have to follow what we have .. no new creation really. but all open for discussion sure, and there might be many ways to expose it.
20150703 19:17:16 <Eclesia> which one comes first : egg or chicken ? :D
20150703 19:17:48 <sgothel> so .. whoever of us starts anything will notify the other (bugreport) .. simple as that
20150703 19:17:56 <sgothel> then we have something to chew on :)
20150703 19:18:28 <sgothel> I don't want to enforce a process here .. other than .. bugzilla, git, unit-test :)
20150703 19:18:48 <sgothel> and btw - I cannot :)
20150703 19:19:39 <sgothel> if you like to go ahead - do it your way, you are most comfy with .. I will follow - or the other way around.
20150703 19:22:37 <Eclesia> I never learned C/C++ at school, only a bit of ASM/C for microchips in an electronic club 10 years ago. So java code/api first ^^
20150703 19:24:23 <sgothel> then .. pls try to be very brief and add references to X11/Win32/OSX D&D specs ..
20150703 19:25:23 <sgothel> the 'value' object .. that might be an issue, i.e. URL, 'a binary blob' (picture, whatever, ..) ...
20150703 19:25:49 <sgothel> if binary blob - who is the memory owner .. ?
20150703 19:25:59 <sgothel> i.e. we like to reduce copying data .. etc
20150703 19:26:07 <sgothel> maybe you can solve that ..
20150703 19:26:29 <sgothel> mime type .. hmm
20150703 19:27:19 <sgothel> MimeObject interface .. w/ specialization for Text, URI, 'Picture', .. ?
20150703 19:29:21 <Eclesia> I suggest it should be raw data/blob or primitive types only (int/string/float/double). anything else could because really complicate
20150703 19:29:29 <Eclesia> become*
20150703 19:30:40 <sgothel> that is why I would like to have the D&D specs in mind (of the WMs ..) first .. - well, we will see.
20150703 19:36:47 <Eclesia> seems pretty much linked to clipboard in both x11 and win32. Attachment -> CliboardObject
20150703 19:38:38 <sgothel> in this case: we have 1) D&D and 2) Ctrl-C&V ..
20150703 19:38:48 <sgothel> i.e. can support both in a similar way
20150703 19:40:06 <sgothel> or: ctrl-C == drag start
20150703 19:40:14 <sgothel> ctrl-v == drop
20150703 19:40:48 <Eclesia> then starting by working on the clipboard would be easier. it's more direct put and peek actions.
20150703 19:41:23 <sgothel> yup
20150703 19:41:42 <sgothel> and we can see how to solve the ownership .. i.e. it is like an IPC service actually
20150703 19:42:00 <sgothel> shared memory ..
20150703 19:42:20 <sgothel> (nobody shall say dbus now, otherwise I get a headache :)
20150703 19:43:59 <Eclesia> the truth is I just know the names : IPC,DBUS. but don't know how those work
20150703 19:46:08 <sgothel> shmem http://linux.die.net/man/3/shm_open - all one would need, maybe w/ mmap http://linux.die.net/man/2/mmap - X11 used this for ages :)
20150703 19:47:09 <sgothel> dbus .. oh well, 1st goal was to have an application IPC comm channel .. sort of reinventing xml schemata .. and now, the systemd folks sort of get confused and push it down to the Linux kernel :-(
20150703 19:48:39 <sgothel> http://www.x.org/releases/X11R7.7/doc/xextproto/shm.html <- for reference .. (usually impl. via shm)
20150703 19:49:48 <Eclesia> slow down, slow down. my head is already full of a lot of various specs, I have to make space first :D
20150703 19:49:56 <sgothel> :)
20150703 19:50:36 <sgothel> so keep in mind, this API has something to do w/ IPC .. i.e. shared memory and probably access-rights issues ..
20150703 19:51:03 <sgothel> zero-copy is highly desired!
20150703 19:51:37 <sgothel> (and here we do mean zero .. unlike kernel dbus .. ahem)
20150703 19:56:59 <Eclesia> ...project really need more devs...
20150703 19:57:58 <sgothel> right
20150703 19:59:59 <sgothel> ^^ this is time spend in hope for one more active contributor :)
20150703 20:00:45 <sgothel> however - yes, I am still trying to find either students or an increased budget (sponsors) .. but, well - no luck yet.
20150703 20:03:15 <Eclesia> little by little that's how our projects go
20150703 20:03:50 <sgothel> yup .. lets keep it up and running. world domination :)
20150703 20:31:37 * elect (~elect@anon) has joined #jogamp
20150703 21:11:03 * elect (~elect@anon) Quit (Ping timeout: 252 seconds)
20150703 21:21:58 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20150703 21:46:57 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150704 05:06:23 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150704050623.html