#jogamp @ irc.freenode.net - 20130617 05:05:17 (UTC)
20130617 05:05:17 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130616050517.html
20130617 05:05:17 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130617050517.html
20130617 06:37:07 * monsieur_max (~maxime@anon) has joined #jogamp
20130617 06:45:57 * [Mike] (~Mike]@anon) Quit ()
20130617 08:53:24 * sgothel (~sven@anon) has left #jogamp
20130617 12:37:15 * odin_ (~Odin@anon) has joined #jogamp
20130617 15:59:28 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130617 16:43:45 * sgothel (~sven@anon) has joined #jogamp
20130617 16:43:45 * ChanServ sets mode +v sgothel
20130617 17:28:08 * monsieur_max (~maxime@anon) has joined #jogamp
20130617 18:01:23 * hharrison (~chatzilla@anon) has joined #jogamp
20130617 18:01:40 <hharrison> sgothel: I see you were busy in gluegen
20130617 18:01:40 <sgothel> good evening/day to all
20130617 18:01:48 <sgothel> yup .. and jogl ..
20130617 18:02:22 <sgothel> .. if you haven't read: NEWT: No more keyTyped(..) TYPED event
20130617 18:03:06 <sgothel> making some local tests now .. then finishing GL4.3 + ES3.0 - how often did I say this w/o doing it ? :)
20130617 18:04:00 <sgothel> the 'funny' in between ES3 hacks .. are due to already available ES3 drivers, which report GLSL 300 in the version query, even though you requested an ES2 ctx .. well
20130617 18:04:04 <monsieur_max> sgothel: you mean that keytyped has been removed ?
20130617 18:04:10 <sgothel> yes sir
20130617 18:04:21 <monsieur_max> oh... am i using this, checking ...
20130617 18:04:27 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=688
20130617 18:04:44 <sgothel> http://jogamp.org/git/?p=jogl.git;a=commit;h=8b33170ec6fd3f215976875cb66d746fa1b48f61
20130617 18:05:03 <sgothel> simply: http://jogamp.org/git/?p=jogl.git;a=blobdiff;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/gl2/newt/TestGearsNEWT.java;h=3c33a4899878f69b688e4cf10d18cbff6a6686f8;hp=93dc885b69ef1c9426058b460a12fa3693c24d8f;hb=8b33170ec6fd3f215976875cb66d746fa1b48f61;hpb=c24f44036971bf58b5c47a6e1f7d9f186c67e789
20130617 18:05:14 <sgothel> .. it was announced for a _looong_ time :)
20130617 18:05:44 <monsieur_max> haha ;) no problem about this, it's great to announce that here. I don't track all the changes
20130617 18:06:00 <monsieur_max> thanks for mentionning
20130617 18:06:08 <sgothel> and all API changes must happen NOW, to safe semantics of version number .. (@Mark hint hint) :)
20130617 18:06:29 * rmk0 emits smoke and sparks
20130617 18:06:31 <monsieur_max> haha the version number headache :)
20130617 18:06:58 <sgothel> Yes .. if I seem to be too relaxes .. Mark pulls me into this discussion :)
20130617 18:07:15 <monsieur_max> haha :)
20130617 18:07:22 <rmk0> i can whine and complain extensively!
20130617 18:07:28 <rmk0> \o/
20130617 18:09:16 <sgothel> so the APT inclusion on gluegen.jar would be cool for GLSL UBO .. see http://forum.jogamp.org/Uniform-Buffers-mapping-and-size-td4029403.html#a4029411
20130617 18:09:27 <sgothel> APT .. Annotation Processing Tool
20130617 18:09:43 <sgothel> BTW: This is the very 1st tru Java 1.6 feature :)
20130617 18:09:45 <sgothel> *true
20130617 18:10:54 * hharrison (~chatzilla@anon) Quit (Remote host closed the connection)
20130617 18:11:50 <sgothel> would be nice to have a demo / unit test w/ UOB hmm .. maybe a generated java StructAccessor following this mentioned 'std40' thingy .. but no time to dig into details.
20130617 18:14:51 <monsieur_max> sorry to ask, but, i guessed that a release is about to happen, any idea when ? ( or am i totally wrong ? )
20130617 18:15:09 <sgothel> about to happen .. yes
20130617 18:15:22 <sgothel> https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.0.2_of_JOGL
20130617 18:15:41 <sgothel> The 1st section of open bugs is already empty .. puhh
20130617 18:16:01 <sgothel> Now the 2nd section is targeted .. at least ES3 + GL43 (-> API change)
20130617 18:16:21 <sgothel> then rest may follow as we go, not API change in core modules intended ..
20130617 18:16:54 <sgothel> @Petrs: Can you fix the bugs I assigned to you ? TGA/RLE .. and ? (I forgot)
20130617 18:17:08 <sgothel> SWT ? I dunno - lowest prio right now.
20130617 18:17:29 <sgothel> IF anybody likes to volunteer fixing / testing / analyzing bugs .. pls don't let me stop you!
20130617 18:17:53 <monsieur_max> i'm not good enough for this, sorry
20130617 18:22:10 <monsieur_max> sgothel: any idea of the release date ( i'm not pushing anyone here :) )
20130617 18:22:13 <rmk0> i'm currently tied up preparing to replace the disk in my laptop
20130617 18:22:33 <rmk0> woke up this morning to SMART and "I/O error, dev sda, sector 961890232" errors
20130617 18:23:02 <sgothel> well, 'it's done when it's done' :) .. before siggraph, I hope until next week.
20130617 18:23:14 <sgothel> currently tests are promising ..
20130617 18:23:51 <sgothel> all depends of how many bugs will be reported .. etc now, usually report rate increases then, but we might need the release to trigger that :)
20130617 18:24:05 <monsieur_max> sgothel: classical !
20130617 18:24:36 <monsieur_max> it's bug free until someone uses it
20130617 18:24:55 <sgothel> yes, 'true until proven otherwise' :)
20130617 18:25:03 <monsieur_max> haha :)
20130617 18:25:09 * hharrison (~chatzilla@anon) has joined #jogamp
20130617 18:25:34 <sgothel> so a release soon - is good, just need to make sure most API changes are 'in' .. and the bug list is cleaned up.
20130617 18:26:31 <monsieur_max> i'm totally up to try this on my game, but have little time to investigate on bugs ( hobbyist inside )
20130617 18:26:51 <sgothel> no problem .. you always can test w/ aggregated builds
20130617 18:27:00 <sgothel> -> Wiki ..
20130617 18:27:23 <monsieur_max> like there ? https://jogamp.org/deployment/autobuilds/master/
20130617 18:27:24 <hharrison> Looking forward to a release as well, will hold my tongue on version discussions
20130617 18:28:21 <monsieur_max> ok, found ... https://jogamp.org/wiki/index.php/Downloading_and_installing_JOGL#Downloading_the_latest_aggregated_autobuild :)
20130617 18:28:28 <sgothel> yup
20130617 18:28:39 <sgothel> hehe
20130617 18:29:24 <sgothel> @Harvey: Current semantics are: No API change (in public major APIs) with subminor increases .. hope thats OK.
20130617 18:29:46 <hharrison> I do have opinions on the version thing, but trust you to do the right ting
20130617 18:30:02 <sgothel> ok .. so lets get over it .. me waiting for a build anyways :)
20130617 18:30:22 <sgothel> shoot ..
20130617 18:30:30 <hharrison> Sure, currently it's named major.minor.subminer?
20130617 18:30:35 <sgothel> yup
20130617 18:30:49 <sgothel> and RCs to that have a date attached
20130617 18:31:03 <sgothel> (the maven thing ..)
20130617 18:31:53 <hharrison> OK, I'd say, every month/quarter do a release incrementing subminer so that people get bugfixes/new API (not changed API)
20130617 18:32:13 <sgothel> Good!
20130617 18:32:23 <hharrison> If, at some point an API needs changing, that release bumps the minor number instead, subminer goes back to 0
20130617 18:32:25 <sgothel> ofc .. we shall release often ..
20130617 18:32:31 <sgothel> yup
20130617 18:32:45 <hharrison> Looking at the current pace, I'd like to see a monthly release TBH
20130617 18:33:03 <sgothel> (after 1st 2.0.2 - all current secret releases will be subminor ones ..)
20130617 18:33:19 <hharrison> Now, the controversial part ;-)
20130617 18:33:24 <sgothel> right now, we do release quite often .. but it's more a hidden thing :)
20130617 18:33:59 <sgothel> shoot .. holding my chair & coffee :)
20130617 18:34:36 <hharrison> On the first bump of miner, for a few release, some 'sucker' watches the mastr branch and cherry-picks bugfixes to a stable branch on the old miner, similar to the linux kernel stable releases
20130617 18:35:25 <hharrison> This gives people a month or three to update their program to the API changes and move to the next miner, while still having bugfixes available
20130617 18:35:28 <sgothel> as I already said: as long this sucker is not me - I am fine w/ backporting :)
20130617 18:35:49 <sgothel> but my opinion is: if you release a product, it really does not matter
20130617 18:36:02 <hharrison> OK, not that controversial then
20130617 18:36:04 <sgothel> b/c you have to test against even subminor upgrades . Q/A
20130617 18:36:21 <sgothel> so we will hold all versions (as usual) - to be referenced ..
20130617 18:36:32 <sgothel> and our infamous 'latest' symbolic links
20130617 18:36:44 <hharrison> Right, you're testing the subminer updates, to make sure nothing broke in the bugfixes, but not makign any code changes in your app
20130617 18:36:49 <sgothel> if one really loves the backporting stuff .. well - go ahead :)
20130617 18:36:56 <sgothel> yes
20130617 18:37:09 <sgothel> well .. any code changes will be more 'natural' ..
20130617 18:37:21 <hharrison> We'll play it by ear, I'm thinking of doing the backports as I'm already reviewing the commits that go by
20130617 18:37:24 <sgothel> intuitive .. i.e. you already get your hands dirty :)
20130617 18:37:33 <sgothel> sure ..
20130617 18:37:44 <sgothel> we will then remove the jenkins RC thingy
20130617 18:37:52 <sgothel> and add one for backport latest :)
20130617 18:38:12 <hharrison> If nobody cares for the backports and just follows mainline, then no prob
20130617 18:38:18 <sgothel> the current jenkins RC build job-tree .. is nonsense right now
20130617 18:38:39 <sgothel> so we can have a 'previous' build line, triggered manually
20130617 18:38:49 <sgothel> 'pre-minor' maybe
20130617 18:39:30 <sgothel> the 'sucker' will have complete authority over the whole module branches (SCM, jenkins)
20130617 18:40:01 <sgothel> but it must be the whole thing, i.e. gluegen, .. jogl, ..
20130617 18:40:38 <sgothel> on our SCM, we will have a subfolder for this pre-minor w/ own repos and permissions then
20130617 18:40:43 <sgothel> user account .. etc
20130617 18:40:56 <hharrison> Sounds reasonable
20130617 18:40:56 <sgothel> so this will be equal to the linux dev org
20130617 18:41:31 <sgothel> You have a new job Harvey, 'sucker' ! :)
20130617 18:41:33 <hharrison> But we'll play it by ear, if people complain about too many API changes, then backports would have more motivation
20130617 18:41:52 <hharrison> If nobody complains, just keep doing what you're doing
20130617 18:42:24 <sgothel> I doubt there will be any complaint .. really. my personal view: resources should focus on the evolution of the project, but well. ..
20130617 18:42:33 <sgothel> it's more an issue for the distri guys
20130617 18:43:03 <rmk0> most of my concern is from the perspective of someone that writes an open source library that depends on jogl
20130617 18:43:05 <sgothel> maybe having an arrangement w/ those .. a person who tries to solve issues and merge all their changes back ..
20130617 18:43:17 <sgothel> they can always use that version
20130617 18:43:26 <sgothel> again: if you update .. you update
20130617 18:43:37 <sgothel> i.e. you have to pull new source/blobs .. and test
20130617 18:43:46 <sgothel> while testing .. you may or may-not apply changes
20130617 18:43:55 <sgothel> in the end .. we are pretty much low-level
20130617 18:43:59 <hharrison> Aye, from your POV, I'd suggest no change for what you're doing currently...other than get that release ou!
20130617 18:44:06 <sgothel> but yes, the future will tell
20130617 18:44:31 <sgothel> i.e. I updated jake here .. pull new blobs, 10 minutes of changes .. done
20130617 18:44:52 <rmk0> i write a library that depends on version N, and i declare in the maven dependencies that it works on N. then M comes out, containing no backwards-incompatible changes
20130617 18:44:54 <sgothel> (ScreenMode -> MonitorMode)
20130617 18:45:14 <rmk0> someone wants to use M for the bug fixes, but they can't because my library forces N on them
20130617 18:45:16 <sgothel> yes
20130617 18:45:27 <hharrison> Anyways, I'm content with your bump subminer plan, and bunp minor on API change
20130617 18:45:43 <sgothel> great
20130617 18:46:11 <hharrison> If it's API addition, as in, couldn't possibly break anyone's existing code, then I'd just bump subminer and move on, some people feel miner should get a bump
20130617 18:46:15 <sgothel> and when raycasting becomes immanent - or quantum equations, we bump the major :)
20130617 18:47:32 <sgothel> what a timing, jenkins just finished
20130617 18:48:27 <sgothel> secret build: http://jogamp.org/deployment/archive/master/gluegen_681-joal_445-jogl_1008-jocl_808 :)
20130617 18:50:52 <rmk0> any idea what i should do given the situation i just mentioned?
20130617 18:51:05 <sgothel> hu ?
20130617 18:51:49 <hharrison> Afraid I don't know maven well enough to comment on dependencies
20130617 18:52:08 <hharrison> Does in support wildcarding?
20130617 18:52:14 <sgothel> all good - if you (or anybody) .. has time, well .. dunno, triage bugs or think about stuff .. hmm
20130617 18:52:15 <rmk0> it's not really a maven issue... it's an issue for anyone that releases open source libraries that depend on jogl
20130617 18:52:26 <rmk0> it does support version ranges
20130617 18:52:31 <sgothel> maybe add bugs we should fix before 2.0.2 ..
20130617 18:52:41 <sgothel> i.e. remove ubuntu fonts from all jar ?
20130617 18:52:50 <hharrison> depends on jogl 2.0.n (v >= 2)
20130617 18:53:02 <hharrison> sorry (n >= 2)
20130617 18:53:17 <rmk0> well, and < 2.1.0
20130617 18:53:40 <hharrison> I assume that 2.0 would implicitly force < 2.1
20130617 18:53:56 <hharrison> As in rely only on the 2.0.x series
20130617 18:53:59 <rmk0> right
20130617 18:54:00 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=754 .. added
20130617 18:54:12 <rmk0> in maven, that translates to "[2.0.2, 2.1.0)"
20130617 18:54:31 <rmk0> [ ] being inclusive, ( ) being exclusive
20130617 18:56:07 <hharrison> Then (if/when) you ever update your lib, you can choose newer dependencies at that time
20130617 18:56:07 <sgothel> hmm .. apps I have seen use either -SNAPSHOT dependencies for their SNAPSHOT using SNAPSHOTS - or - a specific version anyways.
20130617 18:57:07 <hharrison> This isn't an app problem, I'm pretty sure rmk0 is approaching this with his distro hat on
20130617 18:57:09 <rmk0> sort of
20130617 18:57:09 <rmk0> i obviously want people using my libraries to be able to use them on as wide a range of versions as possible
20130617 18:57:09 <rmk0> so i don't force people into picking a specific version
20130617 18:57:14 <sgothel> jogamp.org down .. grrr
20130617 18:57:35 <rmk0> erk!
20130617 18:59:05 <sgothel> 20:58:48 up 8 days, 1:35, - hmm .. didn't reset though
20130617 18:59:48 <hharrison> Hmm, dunno how best to deal with that, you don't know what API changes will be in the 2.1 series until it happens
20130617 19:00:00 <hharrison> So you can't allow those versions initially
20130617 19:00:04 <rmk0> yeah
20130617 19:00:31 <hharrison> But once the 2.1 comes out, if you don't get affected by API change, you can just open the versions wider and exclude the 2.2 series
20130617 19:00:44 <hharrison> repeat when 2.2 comes out
20130617 19:00:52 <rmk0> is most likely going to be the approach
20130617 19:01:02 <sgothel> back .. probably network problems ..
20130617 19:01:06 <rmk0> it's sort of why i'd like to see jogl modularized further
20130617 19:01:24 <rmk0> the library i write depends on the GL APIs... it doesn't depend on any of the display handling stuff, except for in the unit tests
20130617 19:01:33 <rmk0> the GL interfaces aren't likely to change... ever
20130617 19:01:36 <rmk0> by their nature
20130617 19:01:46 <sgothel> I thought about this once .. years ago
20130617 19:02:00 <sgothel> my solution was to streamline all core module versions - to simplify life
20130617 19:02:02 <hharrison> I'll maintain jogl.math, kinda an equivalent to the old vecmath package
20130617 19:02:10 <hharrison> -)
20130617 19:02:18 <sgothel> i.e. we build and test all together - thats what we mark: complete and working
20130617 19:02:34 <sgothel> you can do all that, but it should be streamlined in the versions
20130617 19:02:42 <sgothel> ofc .. you can use the 'atomic' jar files
20130617 19:03:14 <sgothel> i.e. the *all* jar files shall be 'just' a convenience covering most common cases
20130617 19:03:26 <sgothel> (reducing download time etc)
20130617 19:03:38 <rmk0> right
20130617 19:04:51 <sgothel> so even if jocl doesn't change itself, if it's version bumps w/ rest of the pack, it means it is tested in that constellation
20130617 19:05:08 <rmk0> yeah, would be extremely difficult to do otherwise
20130617 19:05:23 <sgothel> in the end, we deliver a harmonic set of modules .. for .. audio, 3d, .. blabla :)
20130617 19:05:55 <rmk0> for me personally, splitting out the interface types and the implementations would be a great help
20130617 19:06:05 <rmk0> it would help for the maven packages for android too
20130617 19:06:19 <sgothel> an example ?
20130617 19:06:21 <rmk0> as in... you write your program to depend on the GL stuff and GLEventListener (and there's one package that provides those and only those)
20130617 19:06:31 <sgothel> oh ..
20130617 19:06:42 <rmk0> the actual GL3/GL2/GL2GL3/... interface types
20130617 19:06:49 <sgothel> for developers you mean .. practically .. you would need the impl. for sure :)
20130617 19:07:31 <sgothel> you know, you can keep you very busy w/ all that - I like the compile dependency tests very much!
20130617 19:07:46 <sgothel> hence most of our stuff _is_ modularized, i.e. using the atomic jars
20130617 19:08:03 <sgothel> if you look into the build xml's .. we use NEWT only, or non-android .. etc
20130617 19:08:14 <sgothel> so from that perspective .. we are quite clean
20130617 19:08:26 <sgothel> the only thing I am missing, is the rt.jar w/o AWT :)
20130617 19:08:38 <rmk0> need to check what the issue was with android
20130617 19:08:41 <sgothel> .. to prove .. it's clean
20130617 19:09:06 <sgothel> we had a dependency w/ android a while ago, thx to Syllvestre .. it's solved
20130617 19:09:23 <sgothel> i.e. only android part is compiled w/ android jar if available (gluegen)
20130617 19:09:39 <sgothel> .. and jogl, thats it .. I guess
20130617 19:10:08 <rmk0> ah, that was it
20130617 19:10:14 <sgothel> ofc .. I dont' know how much of this fine granularity is mapped to maven ..
20130617 19:10:16 <rmk0> see the jp4da demo
20130617 19:10:38 <rmk0> one sec...
20130617 19:10:53 <sgothel> but our ant build stuff .. does distinct all these things
20130617 19:12:09 <rmk0> https://outland.arc7.info/2013/06/17/jp4da.txt
20130617 19:12:16 <rmk0> it'd be nice to rework the maven packages to clean up that stuff
20130617 19:13:08 <rmk0> not exactly sure why jp4da-desktop excludes the dependency explicitly... need to check that
20130617 19:13:18 <sgothel> Secure Connection Failed
20130617 19:13:18 <sgothel> An error occurred during a connection to outland.arc7.info.
20130617 19:13:19 <sgothel> Cannot communicate securely with peer: no common encryption algorithm(s).
20130617 19:13:19 <sgothel> (Error code: ssl_error_no_cypher_overlap)
20130617 19:13:25 <rmk0> yow
20130617 19:13:37 <rmk0> http://waste.io7m.com/2013/06/17/jp4da.txt
20130617 19:13:41 <rmk0> *ahem*
20130617 19:14:24 <sgothel> I can imagine .. hmm, so as long the non-android / android stuff (and all other dependencies) maps w/ maven .. it should be fine. AFAIK we only build w/ following distinctions:
20130617 19:14:31 <sgothel> Android and SWT
20130617 19:15:18 <sgothel> let's discuss this more on an abstract level, since I am not sure if reading the maven file really tells me a lot :)
20130617 19:15:41 <rmk0> oh, it's just the fact that dependencies need to be manually excluded
20130617 19:15:51 <rmk0> something's not granular enough, but i'm not sure what
20130617 19:16:05 <sgothel> jp4da-android: has android in: ok
20130617 19:16:29 <sgothel> isn't there a dependency graph tool for maven ?
20130617 19:16:41 <rmk0> yeah
20130617 19:17:13 <sgothel> rm -rf cache, mvn2 .. - grep DOWNLOAD a.log :)
20130617 19:18:13 <rmk0> ... i'm still not sure why that dependency exclusion is there for the jp4da-desktop module
20130617 19:18:47 <sgothel> exclusion ?
20130617 19:19:01 <sgothel> you mean _not_ referencing the android stuff ?
20130617 19:19:27 <rmk0> in that text file, note that jp4da-desktop depends on jp4da-core, but explicitly "excludes" the jogl-all dependency that jp4da-core introduces
20130617 19:19:30 <sgothel> would be nice if there is a maven feature (like JNLP): only include if OS == android, or something
20130617 19:20:01 <sgothel> ah ..
20130617 19:20:05 <sgothel> so no double inclusion ?
20130617 19:20:12 <sgothel> right: i don't get it either
20130617 19:20:18 <rmk0> double inclusion is no problem... no idea why it's there
20130617 19:20:29 <rmk0> i'd play around with it but i'm trying to clear this laptop off for a wipe
20130617 19:20:30 <sgothel> so who says it must be there ?
20130617 19:20:39 <rmk0> well, i wrote it, so presumably i had a reason
20130617 19:20:45 <rmk0> i don't see that reason in the wiki page i wrote...
20130617 19:22:38 <sgothel> hehe .. if your own git log fails you :) .. happens to me quite often, even though I try to be verbose
20130617 19:23:03 <rmk0> i should probably have picked better names than "jogl-all" and "jogl-all-main"
20130617 19:23:16 <rmk0> one has natives, one doesn't
20130617 19:23:18 <rmk0> guess which!
20130617 19:23:25 <sgothel> hmmm :)
20130617 19:23:35 <rmk0> is the sort of thing that will screw people trying to do android with the maven packages
20130617 19:23:38 <sgothel> I look in the folders :)
20130617 19:23:44 <rmk0> it's doable but it's not immediately obvious
20130617 19:23:46 <sgothel> so .. change it
20130617 19:23:56 <sgothel> we haven't released yet :)
20130617 19:23:58 <rmk0> well, the natives are deployed with jogl-all
20130617 19:24:02 <sgothel> ah
20130617 19:24:07 <rmk0> but the jogl-all-main package is the one that depends on them
20130617 19:24:23 <rmk0> so depending on jogl-all-main gives you all the natives automatically
20130617 19:24:30 <sgothel> right, intuition would be: jogl-all (java) depends on jogl-all-natives :)
20130617 19:24:50 <sgothel> or: jogl-all -> [ jogl-all-java , jogl-all-natives ]
20130617 19:25:18 <rmk0> we can't split them up like that without pain, unfortunately
20130617 19:25:24 <rmk0> but jogl-all-main could have a better name
20130617 19:25:24 <sgothel> or jogl-all -> jogl-all-java -> jogl-all-natives (but thats redundant I guess)
20130617 19:25:53 <sgothel> isn't it already split up .. just a rename ?
20130617 19:26:11 <rmk0> i mean that the natives are "attached" to jogl-all
20130617 19:26:12 <sgothel> also change 'semantics' of jogl-all ?
20130617 19:26:30 <sgothel> so you change it .. attach them to jogl-all-natives
20130617 19:26:39 <sgothel> and put java stuff in jogl-all or jogl-all-java
20130617 19:26:42 <rmk0> sorry, it's awkward to understand
20130617 19:26:46 <sgothel> (yes, I don't know)
20130617 19:27:17 <rmk0> the normal jogl java jars are placed into the maven jogl-all package
20130617 19:27:18 <sgothel> well, on the other hand .. too much perfectionism .. is also a trap :)
20130617 19:27:36 <rmk0> and each native library jar is added as an extra artifact to jogl-all, and it's all uploaded in one shot
20130617 19:27:45 <rmk0> but if you depend on jogl-all, you won't get the natives
20130617 19:28:03 <sgothel> that is great! .. hey, it works great .. maybe just this one android thing.
20130617 19:28:08 <sgothel> btw .. how about SWT ? :)
20130617 19:28:09 <rmk0> you'd have to depend on jogl-all, jogl-all-linux-amd64-natives.jar, etc, etc
20130617 19:28:23 <rmk0> jogl-all-main explicitly depends on jogl-all and all the attached native jars
20130617 19:28:31 <rmk0> so if you depend on jogl-all-main, you get it all
20130617 19:28:36 <rmk0> is a convenience
20130617 19:28:48 <sgothel> and 'main' says it all - great!
20130617 19:29:02 <rmk0> yeah... should publish those other packages too
20130617 19:29:06 <rmk0> they're currently missing, i think
20130617 19:29:09 <rmk0> "no awt" and so on
20130617 19:29:26 <sgothel> uh .. well .. not a prio IMHO
20130617 19:29:35 <sgothel> but me not the maven man, you are!
20130617 19:29:48 <rmk0> i suppose if noone's asked for it
20130617 19:30:17 <sgothel> so the 'all' stuff includes all ? i.e. also SWT ?
20130617 19:30:42 <sgothel> maybe one nice thing to have would be no-awt, for other mobile platforms, i.e. GNU/Linux
20130617 19:30:43 <rmk0> ...
20130617 19:30:52 <rmk0> oh, looks like we are publishing the mobile jars and the noawt jars
20130617 19:30:56 <rmk0> i don't remember doing that...
20130617 19:31:03 <sgothel> good!
20130617 19:31:03 * rmk0 tries to put brain back into head
20130617 19:31:26 <rmk0> the android jars were the ones that were conspicuously absent for rc11
20130617 19:31:33 <rmk0> but they're in the testing repository now, obviously
20130617 19:36:15 <rmk0> yeah... won't mess with this
20130617 19:36:21 <rmk0> is maybe a bit strange but it does work
20130617 19:36:34 <rmk0> imagine changing names around would cause even more problems
20130617 19:36:36 <sgothel> great
20130617 19:36:37 <rmk0> now that people know them
20130617 20:05:33 * [Mike] (~Mike]@anon) has joined #jogamp
20130617 20:21:12 <monsieur_max> oh oh ScreenMode disappeared :P
20130617 20:21:56 <sgothel> yup .. now we support multiple monitors .. fullscreen can span across selected ones .. etc
20130617 20:22:30 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=600
20130617 20:22:43 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=600#c6
20130617 20:22:58 <sgothel> http://jogamp.org/files/screenshots/newt-mmonitor/html/
20130617 20:23:22 <monsieur_max> you sir are a bugtracker master :)
20130617 20:23:52 <sgothel> well, for a reason we have connected all dots, requirement/bug .. source .. tests .. etc
20130617 20:24:16 <sgothel> so we would satisfy security / automotive requirements.
20130617 20:24:47 <sgothel> http://jogamp.org/git/?p=jogl.git;a=blobdiff;f=src/test/com/jogamp/opengl/test/junit/newt/TestScreenMode00bNEWT.java;h=f4eaec5fa202e460c4eb746e2579bf50483e3de8;hp=75a31268619575a4c61cccf8819d0deb8376bdfe;hb=6ebf649d1b87944257fe492e0aef842d1b8debc2;hpb=4d35eaa766071fd8dedab8b6e2ee53710831c567
20130617 20:24:55 <sgothel> as an example .. how to change to new code
20130617 20:25:12 <monsieur_max> great great great :) i was looking for that
20130617 20:25:56 <monsieur_max> sgothel: thanks a lot !
20130617 20:26:20 <sgothel> i.e. Screen has all monitor-modes, and also all attached monitors .. window can gather the main monitor, screen at a position. each monitor has it's supported list of MonitorModes .. I guess thats it
20130617 20:27:05 <sgothel> how to find this info ?
20130617 20:27:14 <sgothel> check the git log of that file .. which has changed
20130617 20:27:24 <sgothel> use that git-sha1 and search in bugzilla
20130617 20:27:37 <sgothel> since all bug entries do have an SCM section!
20130617 20:28:03 <sgothel> jenkins can be searched as well for same git-sha1
20130617 20:28:48 <sgothel> https://jogamp.org/bugzilla/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__all__&content=6ebf649d1b87944257fe492e0aef842d1b8debc2&list_id=1175
20130617 20:29:38 <monsieur_max> yeah i saw all the links , nice work
20130617 20:29:49 <sgothel> dinner .. laters
20130617 21:00:49 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130617 21:28:56 * void256 (~void@anon) has joined #jogamp
20130617 22:34:12 * void256 (~void@anon) Quit (Remote host closed the connection)
20130618 00:52:11 * [Mike] (~Mike]@anon) Quit ()
20130618 01:13:56 <sgothel> @Harvey ?
20130618 01:14:22 <sgothel> I just received from Dominik an email. .. regarding T-Shirts .. looks like it's getting *tight* ..
20130618 01:14:56 <sgothel> Maybe order something online (if we know they are good) - and deliver it to Annaheim directly ?
20130618 01:18:49 <hharrison> I placed a few calls today, will get whatever numbers I get back tomorrow for you to decide
20130618 01:31:49 <sgothel> awesome - thx. let's hope quality is OK .. and they can deliver fast .. the latter is the problem, since the design may take still 1 week .. hmm
20130618 01:31:57 <sgothel> thank you
20130618 01:39:22 * [Mike] (~Mike]@anon) has joined #jogamp
20130618 02:42:21 <sgothel> .. aligning our GL header files w/ khronos, i.e. remove our GL3 .. using new glcorearb.h .. etc
20130618 05:05:17 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130618050517.html