#jogamp @ irc.freenode.net - 20131030 05:05:51 (UTC)

20131030 05:05:51 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20131029050551.html
20131030 05:05:51 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20131030050551.html
20131030 08:10:19 * monsieur_max (~maxime@anon) has joined #jogamp
20131030 08:55:27 <sgothel> @sinistersnare: looks more like GlueGen/JOGL mismatch
20131030 09:37:41 * [Mike] (~Mike]@anon) Quit (Ping timeout: 240 seconds)
20131030 13:00:15 * ievleff (~ievleff@anon) has joined #jogamp
20131030 13:03:31 * ievleff (~ievleff@anon) Quit (Remote host closed the connection)
20131030 13:35:33 <monsieur_max> sgothel: i'm gonna create 2 tickets on bugzilla for the 2 issues i reported on glmediaplayer
20131030 14:53:28 <monsieur_max> sgothel: i found a workaround for the URI issue on windows
20131030 16:05:07 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131030 17:03:09 * monsieur_max (~maxime@anon) has joined #jogamp
20131030 17:04:46 * [Mike] (~Mike]@anon) has joined #jogamp
20131030 17:55:46 <sgothel> @Max: Great!
20131030 17:57:04 <sgothel> @Max and all: Always notify me here to pull your stuff, or sent me an email if I am not responding here .. since I don't always check github. Thx.
20131030 18:01:22 <sgothel> @Max: Not there yet .. would be great if we can make it into 2.1.2
20131030 18:02:52 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=875 <- incl. commits simplifying the setGLFunctionAvailability(..) checks .. TODO: Add EGL/ES profile context creation!
20131030 18:11:10 <monsieur_max> sgothel : I won't be available in the next few days, but i'll try to git myself up. For now, i'll provide comments only as i've no idea of how to fix this.
20131030 18:11:53 <sgothel> oh .. ok, thx .. you can edit the workaround in the bug report if you like
20131030 18:12:04 <sgothel> but .. yeah, no rush .. all good
20131030 18:21:21 <monsieur_max> sgothel: for now, yes, only workarounds , I'll see what i will do , probably next week
20131030 18:22:03 <sgothel> i.e. we can add something like Platform.OSType.Windows .. URI->File .. for FFMPEGPlayer .. it would be a fix
20131030 18:23:08 <monsieur_max> well, i was not sure of such a "hacky" fix
20131030 18:23:33 <sgothel> it's reflecting the situation .. what can you do otherwise ..
20131030 18:24:36 <monsieur_max> yep, true ... at least, it'll remain RFC compliant :)
20131030 18:25:06 <monsieur_max> ( that's how i found the workaround, searching for valid rfc pattern )
20131030 18:26:01 <monsieur_max> well , i'm off, got a few minutes before girlfriend come back home for the week end, and i'll put them to good use ... playing videogames :P
20131030 18:26:09 <sgothel> hmm .. eager to learn in your bug report .. i.e. so we shall even fix our URI usage ?
20131030 18:26:36 <sgothel> oh .. have fun 2x then :)
20131030 18:27:04 <monsieur_max> hehe ;)
20131030 19:11:00 * Schrostfutz_ is now known as Schrostfutz
20131030 20:15:13 <hharrison> sgothel: something up with jenkins?
20131030 20:18:10 <hharrison> Got a failure email that looks more like infrastructure problems as opposed to build failures
20131030 21:24:47 <sgothel> yup .. _always_ ..
20131030 21:27:05 <sgothel> cleaning up ..
20131030 21:27:56 <sgothel> usually: lost connection (Socket closed ..) .. or weird workspace damage (filesystem ..)
20131030 21:30:19 <hharrison> just checking, saw my name on lots of the commits that were possible breakage
20131030 21:30:44 <sgothel> don't worry all those changes are good
20131030 21:31:02 <sgothel> even though ... you haven't tested the pipelines :)
20131030 21:31:20 * monsieur_max (~maxime@anon) has left #jogamp
20131030 21:31:42 <hharrison> Well, to be fair, they get loaded, just not actually _used_
20131030 21:32:07 <hharrison> the dangers of testing via jvisualvm heapdumps
20131030 21:32:09 <sgothel> hehe .. me used them and realized an old change of mine bugged it :)
20131030 21:53:29 <hharrison> I'm almost loathe to bring it up, but we did find a (hideous) workaround to our keyboard focus deadlocks on windows
20131030 21:54:24 <sgothel> oh there still is one ? thought last NewtCanvasAWT kbd focus change solved it
20131030 21:54:32 <sgothel> bring it up .. :)
20131030 21:54:47 <hharrison> By basically removing the native requestFocusID calls from the newt native code for windows
20131030 21:55:04 <sgothel> oh .. and that works for unit tests ?
20131030 21:55:25 <sgothel> hmm .. interesting
20131030 21:55:26 <hharrison> Don't even know yet...just a 'solves our current problem' hack
20131030 21:55:49 <hharrison> want the patch in bugzilla for you to cringe at...or emailed?
20131030 21:56:21 <sgothel> you mean at 'button press' ?
20131030 21:56:26 <sgothel> hmm ..
20131030 21:56:59 <sgothel> problem: w/o it .. we never get a focus i.e. for touch events or even mouse events (I am sure about the touch events)
20131030 21:57:02 <hharrison> yep, just commentin out the calls in the WM_LBUTTONDOWN, WM_MBUTTONDOWN and WM_RBUTTONDOWN cases
20131030 21:57:26 <sgothel> and the Newt window still gets the focus if 'clicked' by mouse ?
20131030 21:57:46 <hharrison> We have a NewtCanvasAWT inside a JFrame...focus appears to work fine
20131030 21:57:55 <hharrison> (for some reason)
20131030 21:58:07 <sgothel> then .. it shall be good, our unit test would catch it
20131030 21:58:10 <sgothel> (if buggy)
20131030 21:58:20 <sgothel> how about X11 ?
20131030 21:58:26 <sgothel> same thing is there ..
20131030 21:58:41 <sgothel> @ ButtonPress:
20131030 21:59:07 <hharrison> Don't know about X11, we only modified the windows stuff
20131030 21:59:21 <sgothel> would like to have this discussed in bug report (summary of this discussion .. sure)
20131030 21:59:30 <sgothel> so what is the problem in the first place ?
20131030 21:59:33 <sgothel> stealing focus ?
20131030 21:59:53 <hharrison> AWTWIndows thread and the newt renderthread both get deadlocked inside _native_ windows code
20131030 21:59:58 <sgothel> (shouldn't that happen in such case ?)
20131030 22:00:05 <sgothel> oh
20131030 22:00:07 <sgothel> Win8
20131030 22:00:12 <hharrison> Win7
20131030 22:00:45 <hharrison> Let me try and bash some details out of my partner in crime here, will do so in bugzilla
20131030 22:00:51 <sgothel> X11/Win: call: requestFocusID, JNI_FALSE
20131030 22:01:20 <hharrison> src/newt/native/WindowsWindow.c at approx line 904
20131030 22:01:21 <sgothel> +OSX .. same
20131030 22:01:58 <sgothel> WM_LBUTTONDOWN: line 975
20131030 22:02:39 <sgothel> requestFocus(boolean wait) i.e. wait=false
20131030 22:03:56 <sgothel> calls on EDT: requestFocusAction only if non focus .. _and_ non blocking, iff !windowLock.isOwner( Thread.currentThread() )
20131030 22:04:09 <sgothel> so that could be an issue ..
20131030 22:04:22 <sgothel> WindowImpl 1839
20131030 22:05:15 <sgothel> should be: if( !wait && windowLock.isOwner( Thread.currentThread() ) { run here } else { defer on EDT .. }
20131030 22:05:18 <sgothel> ?
20131030 22:05:35 <hharrison> Dumping details in bugzilla now...but yes, calling keyboardfocus from mutliple threads kills us here
20131030 22:08:27 <sgothel> would be nice if you can test the addional criteria .. me assuming requestFocusAction is not called from NEWT-EDT (since lock is hold)
20131030 22:08:42 <sgothel> ping when bugreport is avail .. thx
20131030 22:09:21 <sgothel> so I like to have this fixed there (root cause) than simply removing an action which might be not required for some windows platforms
20131030 22:09:31 <sgothel> for sure it was required .. some time ago :)
20131030 22:09:39 <hharrison> bug 879 has the patch and the trimmed stacktrace
20131030 22:10:20 <hharrison> Trying to beat a better desciption of the debugging my cohort here has already done, sorry for the second-hand reporting
20131030 22:11:44 <sgothel> not exactly latest source code ..
20131030 22:11:58 <hharrison> v2.1.0
20131030 22:12:01 <sgothel> however .. trace shows it is perf. on EDT
20131030 22:12:27 <hharrison> If you see the stacktrace, look at the "RenderThread-Display-.windows_nil-1-EDT-1 thread
20131030 22:12:38 <sgothel> yup .. what I mentioned ..
20131030 22:12:45 <hharrison> He's calling the AWT requestFocus...not on the AWT EDT
20131030 22:12:56 <hharrison> deadlocks ensue
20131030 22:12:59 <sgothel> on our NEWT-EDT :)
20131030 22:13:14 <sgothel> so what I was blabbering above is not the case ..
20131030 22:13:15 <hharrison> Which promtly deadlocks with the real AWT-EDT
20131030 22:14:19 <hharrison> Please don't assume I actually understand this very well at this point....this was the first thing that finally 'worked'
20131030 22:14:33 <sgothel> sure
20131030 22:14:51 <hharrison> Condier it a discussion-starter
20131030 22:14:57 <sgothel> as I said .. won't just remove it .. depends though, i.e. maybe it was needed for WinXP only
20131030 22:15:20 <sgothel> however, I like to understand .. those congestions .. sure 3 threads fighting is always a bad thing
20131030 22:15:32 <sgothel> Thread "AWT-Windows" ?
20131030 22:15:48 <sgothel> something new .. ?
20131030 22:15:55 <sgothel> can we produce this in a unit test ?
20131030 22:16:02 <hharrison> I don't know what that is...not ours, but seems part of the AWT implementation
20131030 22:16:20 <hharrison> And obviosuly tries to interact with AWT....yay
20131030 22:16:49 <hharrison> It's racy, I can describe the setup, maybe an AWT robot could abuse it
20131030 22:17:04 <sgothel> we call 'KeyboardFocusManager.clearGlobalFocusOwner(..)' to ensure that AWT has no more the focus, to give it back to NEWT
20131030 22:17:30 <hharrison> Literally just a NewtCanvasAWT as the only component inside a JFRame
20131030 22:17:32 <sgothel> otherwise I experienced that AWT steals it again
20131030 22:17:58 <sgothel> yeah .. we have some unit tests like this, but 'just' Frame .. maybe you can clone one ..
20131030 22:18:05 <hharrison> on right-click, open a pop-up JFrame and make it visible
20131030 22:18:19 <sgothel> ah ..
20131030 22:18:27 <hharrison> keep clicking back and forth opening popups from the main JFrame
20131030 22:18:30 <sgothel> so normal traversal w/o pop-up works ..
20131030 22:18:44 <hharrison> Our pop-up is just another JFrame
20131030 22:19:29 <sgothel> the problem 'was' that w/o clearGlobalFocusOwner(..)' the Canvas was focus greedy ..
20131030 22:19:48 <sgothel> hmm
20131030 22:19:53 <hharrison> For our purposes, key focus could be totally broken and we wouldn't care for that window
20131030 22:20:01 <hharrison> hence the patch ;-)
20131030 22:20:26 <sgothel> 'works only for us' (tm) :)
20131030 22:21:08 <hharrison> And we don't mind carrying it locally....until we go full-newt or something else
20131030 22:21:11 <sgothel> hmm .. the whole focus traversal .. (so you have an overview) .. in NewtCanvasAWT is to extend AWT's traversal w/ our NEWT child
20131030 22:21:41 <sgothel> I would love to see this fixed for sure
20131030 22:22:33 <hharrison> If there was a knob we could set without patching to just 'ignore keyboardfocus' we could also use that
20131030 22:22:45 <sgothel> if we would channel all those commands through the AWT-EDT .. there would be no deadlock
20131030 22:22:59 <sgothel> (me thinking here more for a general solution ..)
20131030 22:23:34 <hharrison> Wonder what that would look like....inject runnable, wait for completion on AWT?
20131030 22:23:37 <sgothel> i.e. attaching a notion, or even a custom EDT native calls shall be channelled through
20131030 22:24:06 <sgothel> we don't need to wait, i.e. the native calls explicitly state wait=false - b/c of this problem
20131030 22:24:20 <sgothel> so it is designed to be all deferred ..
20131030 22:25:08 <sgothel> the only problem is .. hmm is that the NEWT-EDT command waits for Component.requestFocus(Unknown Source)
20131030 22:25:12 <sgothel> look like
20131030 22:25:42 <sgothel> after that .. if gives the focus back to NEWT
20131030 22:25:49 <sgothel> thats while it's waiting ..
20131030 22:25:59 <hharrison> and injecting events onto two queues feels...maybe like an even worse problem
20131030 22:26:08 <sgothel> so if the tail (give focus back to NEWT) would work on AWT-EDT .. maybe
20131030 22:26:19 <sgothel> as long it's all non-waiting
20131030 22:26:24 <sgothel> non-blocking
20131030 22:27:13 <sgothel> NewtCanvasAWT could inject a runnable to AWT-EDT to perform the AWT requestFocus() + action to call NEWT-EDT to focus NEWT window (non-blocking)
20131030 22:27:21 <sgothel> all non-blocking .. streaming
20131030 22:27:36 <sgothel> maybe we can try this ..
20131030 22:27:57 <sgothel> I look at it .. if it passes our unit tests .. good
20131030 22:28:16 <sgothel> and solves these issues
20131030 22:28:27 <sgothel> I did same for OSX main-thread problems
20131030 22:28:47 <hharrison> I'd love to not patch locally....if you have anything you need tested, shoot me a git branch to test
20131030 22:28:48 <sgothel> where we have many threads: OSX-main-thread, AWT-EDT, NEWT-EDT, and Animator :)
20131030 22:29:33 <sgothel> thx!
20131030 22:59:41 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=873#c4 <- Intel/Mesa Shared GLContext issues - duh!
20131030 22:59:54 <sgothel> https://bugs.freedesktop.org/show_bug.cgi?id=41736#c7 <-
20131030 23:00:34 <sgothel> So Eric things .. multiple xlib display connections are 'crazy' .. how else can you achieve non-blocking rendering w/ I/O ?
20131030 23:07:23 <sgothel> https://bugs.freedesktop.org/show_bug.cgi?id=41736#c8
20131030 23:11:17 * rmk0 mutters
20131030 23:14:52 <sgothel> https://bugs.freedesktop.org/show_bug.cgi?id=50873#c7 .. same thing
20131030 23:15:14 <sgothel> so as long Eric doesn't change his mind .. no shared context w/ Intel/Mesa .. duh!
20131030 23:15:37 <sgothel> otherwise .. we would need to lock display connection .. which makes sharing nonsense
20131030 23:16:06 <sgothel> I hope my explanation is clear .. maybe you can also add your comment and ask Eric of Intel to reopen this bug!
20131030 23:16:17 <sgothel> maybe add more details .. dunno
20131030 23:16:23 <sgothel> *campaign* :)
20131030 23:16:44 <sgothel> https://bugs.freedesktop.org/show_bug.cgi?id=41736 <- do it here !
20131030 23:17:08 <sgothel> maybe increase 'Importance' .. this bug is alive for like 2 years now ..
20131030 23:17:31 <sgothel> better not just me doing all the noise :)
20131030 23:18:59 <rmk0> i seem to remember it being difficult to get the intel driver developers to check the result of malloc
20131030 23:19:06 <rmk0> they're not receptive to criticism
20131030 23:19:07 <sgothel> :)
20131030 23:19:31 <sgothel> so please join .. @Mark, @Harvey, @All ..
20131030 23:19:53 <sgothel> otherwise not even our GLMediaPlayer would work .. and wouldn't that be sad ? :)
20131030 23:21:08 <sgothel> Nasa WW2 .. Harvey's app .. and generally all shared context JOGL apps .. and native apps w/ non-blocking code
20131030 23:21:35 <sgothel> (like described Mesa's own 'xdemo manywins' test case .. tsts
20131030 23:22:16 <rmk0> i'm not sure i fully understand the issue
20131030 23:22:32 <sgothel> Eric's comment 7 ..
20131030 23:22:50 <sgothel> he maintains file pointers in the display stucture
20131030 23:23:17 <sgothel> he does not share them between multiple display connections to the same display (i.e. not using hash-maps)
20131030 23:23:24 <sgothel> so he violates the spec
20131030 23:23:39 <rmk0> i'll have to take your word for it, i've not done any raw X11 programming since 2001
20131030 23:23:54 <sgothel> but you can read his and mine comments ..
20131030 23:24:00 <rmk0> yeah, have read them
20131030 23:24:17 <sgothel> so we use exclusive connections to avoid the need of locking them .. i.e. non-blocking rendering
20131030 23:24:19 <rmk0> i'm not personally qualified to know if there's another way other than using multiple displays
20131030 23:24:29 <sgothel> sure is .. w/ blocking :)
20131030 23:24:30 <rmk0> i assume there isn't, as you seem pretty sure about ti!
20131030 23:24:33 <rmk0> well, or that
20131030 23:24:35 <rmk0> *it
20131030 23:24:47 <sgothel> but that makes it .. sort of .. redundant
20131030 23:24:49 <rmk0> and blocking would negate the purpose of the shared context
20131030 23:24:53 <sgothel> yup
20131030 23:25:04 <rmk0> because... operations that take a long time to complete would essentially block both contexts
20131030 23:25:12 <sgothel> yup
20131030 23:25:16 <rmk0> well, i'm up to speed
20131030 23:25:31 <rmk0> yeah, this would cripple my engine on intel
20131030 23:25:39 <sgothel> so pls bug 'em .. and maybe raise 'Importancy'
20131030 23:25:42 <rmk0> am explicitly relying on streaming resources at all times
20131030 23:25:48 <sgothel> ha!
20131030 23:25:58 <rmk0> to avoid loading screens and the like
20131030 23:26:03 <sgothel> as us maintainer .. we only see the red carpet (hi prio)
20131030 23:26:29 <rmk0> hm... i feel like i already have an account on the freedesktop bug tracker
20131030 23:26:32 * rmk0 rummages
20131030 23:33:28 <sgothel> final char k = Binary16.packDouble(23.0); <- why not 'short' ?
20131030 23:34:06 <sgothel> plus .. can we have this in JOGL math package ?
20131030 23:34:20 <sgothel> maybe you can add it there ..
20131030 23:34:57 <sgothel> com.jogamp.opengl.math.FixedPoint <- maybe in here ?
20131030 23:35:13 <rmk0> can do
20131030 23:35:56 <sgothel> (or similar .. your choice, so it matches case best .. in com.jogamp.opengl.math package)
20131030 23:36:13 <rmk0> no particular reason for char over short
20131030 23:36:22 <rmk0> i assumed the result was going to immediately be written into a byte buffer
20131030 23:36:27 <sgothel> haha
20131030 23:36:50 <sgothel> so you made the same mistake by associating char w/ byte .. which you don't w/ impl. :)
20131030 23:36:59 <rmk0> oh, no mistake
20131030 23:37:07 <rmk0> i mainly picked it because it was unsigned 16 bit
20131030 23:37:20 <rmk0> and also so that people didn't try to do arithmetic with it
20131030 23:37:31 <sgothel> ah .. is it ? char is uint16 ? great .. missed that
20131030 23:37:38 <rmk0> i'd rather have an explicit uint16_t, but i'm never going to get it in java (._.)
20131030 23:37:46 <sgothel> good point
20131030 23:38:41 <sgothel> could add a conversion in our GLBuffers as well maybe ..
20131030 23:39:24 <rmk0> excuse me while i try to remember how to use git
20131030 23:39:28 <rmk0> i swear i do this every time
20131030 23:42:53 <rmk0> i've added my barely adequate opinion to that bug
20131030 23:45:33 <sgothel> nice, thx
20131031 00:31:33 <rmk0> silly question... the ieee754b16 code includes a couple of non-public classes
20131031 00:31:41 <rmk0> as in, they're only visible within that package
20131031 00:32:00 <rmk0> they also have some unit tests, which are in the same package
20131031 00:32:22 <rmk0> if i follow the package naming convention for the existing jogl tests... i actually can't use those tests
20131031 00:32:36 <rmk0> because... they'd be in a different package and unable to see those non-public classes
20131031 00:32:40 <rmk0> if that makes sense
20131031 00:53:11 <sgothel> oh ..
20131031 00:53:25 <sgothel> in gluegen we alias same package names sometimes ..
20131031 00:53:27 <sgothel> let's see
20131031 00:53:44 <sgothel> yup
20131031 00:54:04 <sgothel> are those 'essential' .. i.e. coverage not triggered from 'black box' access ?
20131031 00:54:41 <sgothel> your choice .. you can add a package name unit test thingy .. I will adapt build-test.xml in that sense ..
20131031 00:54:57 <sgothel> btw .. do you think it has use outside of OpenGL/JOGL ?
20131031 00:55:04 <sgothel> if so .. GlueGen might be a better place .. dunno
20131031 00:55:28 <rmk0> not sure
20131031 00:55:30 <sgothel> i.e. com.jogamp.common.math for example
20131031 00:55:34 <sgothel> i.e. OpenCL ..
20131031 00:55:37 <rmk0> that's actually where i put it
20131031 00:55:52 <rmk0> didn't go in FixedPoint as it's ... not actually fixed point
20131031 00:55:57 <sgothel> that is GlueGen's namespace, i.e. com.jogamp.common
20131031 00:56:14 <sgothel> gluegen-rt to be exact
20131031 00:56:15 <rmk0> ah, oops, no, i put it in com.jogamp.opengl.math
20131031 00:56:33 <rmk0> hm
20131031 00:56:37 <sgothel> I guess we will figure ...
20131031 00:56:46 <sgothel> you know best .. use cases ..
20131031 00:56:49 <rmk0> is your call really... i'm only using it to populate textures
20131031 00:57:00 <rmk0> not sure if it'd ever be any use elsewhere
20131031 00:57:04 <sgothel> yes, my 1st idea as well :)
20131031 00:57:06 <rmk0> can't "compute" with them
20131031 00:57:10 <sgothel> so leave it there .. good
20131031 00:57:22 <sgothel> and will add package access .. oh ..
20131031 00:58:20 <sgothel> jogamp.newt.WindowImplAccess <- already have such things :)
20131031 00:58:35 <sgothel> so you can drop those there .. and derive into the test namespace .. :)
20131031 00:58:47 <sgothel> your .. white box tests ..
20131031 00:59:01 <rmk0> i, er...
20131031 00:59:03 * rmk0 looks blank
20131031 00:59:39 * rmk0 eyes build-test.xml
20131031 00:59:42 <sgothel> i.e. jogamp.opengl.math <- for private classes for example .. or package private in com.jogamp.opengl.math .. as you wish
20131031 01:00:04 <sgothel> i.e. create a test class in test source path within same package name ..
20131031 01:00:16 <sgothel> and _use_ it in the proper test package ..
20131031 01:00:23 <sgothel> then it will work as is now
20131031 01:00:33 <rmk0> oh, right
20131031 01:00:53 <sgothel> or - I will do the janitor work .. I am used to it :( :)
20131031 01:01:10 <rmk0> on second thoughts... there's actually no reason for these to be private really
20131031 01:01:31 <sgothel> :)
20131031 01:01:48 <sgothel> giving up privacy for convenience .. sounds familiar :)
20131031 01:02:08 <sgothel> make 'em public .. push and we discuss later .. all good, no need to work for hours on this
20131031 01:02:36 <sgothel> thank you, dude .. then we may have a HDR unit tests or something :)
20131031 01:02:47 <sgothel> half-float that is
20131031 01:02:49 <rmk0> hehe
20131031 01:09:21 <rmk0> http://jogamp.org/git/?p=users/mraynsford/jogl.git;a=commit;h=bca7777fa507a509f413c6dc8919bab641fe0d15
20131031 01:09:57 <rmk0> the tests are pretty exhaustive
20131031 01:10:02 <rmk0> "let's try every possible integer value"
20131031 01:10:08 <rmk0> good thing it's only a 16 bit domain
20131031 01:11:46 <sgothel> you hit the doc/code ratio championship - nice, KUDOS
20131031 01:12:21 <rmk0> hehe
20131031 01:13:06 <sgothel> looks like the only thing is missing is the actual open reference to that spec :)
20131031 01:13:25 <rmk0> yep
20131031 01:13:51 <rmk0> i'll give you a clue... there's a copy in a publically accessible place in the university of florida's computer science department
20131031 01:13:54 <rmk0> and i never said that
20131031 01:14:38 <sgothel> too later .. http://jogamp.org/log/irc/jogamp_20131030050551.html#l280 :)
20131031 01:14:47 <rmk0> hehe
20131031 01:14:55 <rmk0> well, i didn't put it there!
20131031 01:19:17 <sgothel> Added Bug 880 and to 2.1.2 ..
20131031 01:19:51 <sgothel> for the public to see .. :)
20131031 01:25:09 <sgothel> 'great' jenkins fails again ..
20131031 01:25:23 <sgothel> jenkins issues .. grrr
20131031 01:42:53 * [Mike] (~Mike]@anon) Quit ()
20131031 01:48:41 <sgothel> @Mark: I guess I have to rename your tests to comply w/ Test*NOUI* for target junit.run.noui ..
20131031 01:48:56 <rmk0> no problem
20131031 03:50:12 <sgothel> @Mark: How loooooooong are your tests running ?
20131031 03:50:27 <sgothel> :)
20131031 03:51:08 <sgothel> https://jogamp.org/chuck/job/jogl/1128/ <- we will see .. but .. quite long :)
20131031 04:21:30 * masterzen (~masterzen@anon) Quit (Ping timeout: 252 seconds)
20131031 04:25:25 * masterzen (~masterzen@anon) has joined #jogamp
20131031 05:05:51 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131031050551.html