#jogamp @ irc.freenode.net - 20140311 05:05:52 (UTC)

20140311 05:05:52 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140310050552.html
20140311 05:05:52 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140311050552.html
20140311 05:55:48 <sgothel> http://jogamp.org/deployment/v2.1.5/
20140311 05:56:14 <sgothel> @Mark: Added 2.1.5 to local maven repo, seems like the atomics are 'in'
20140311 06:06:31 <sgothel> git repos tagged .. uploading source/changelog artifacts
20140311 06:23:02 <sgothel> https://jogamp.org/wiki/index.php/Release_2.1.5
20140311 06:41:06 <phao> I've read in some places that Sun was backing up development of JOGL. Now, what is the status of it? Is oracle supporting it?
20140311 08:00:55 * monsieur_max (~maxime@anon) has joined #jogamp
20140311 08:37:44 <xranby> phao: http://jausoft.com/blog/2011/09/22/oracle-gives-up-on-java3d-and-jogl-for-ria-webstart-and-applets/
20140311 08:38:49 <xranby> phao: jogamp is maintained by the same people who maintained jogl at sun
20140311 08:39:48 <xranby> http://www.youtube.com/watch?v=DeupVAMnvFA - Video of James Gosling, Ken Russell and Sven Gothel on stage at JavaOne 2008 keynote
20140311 08:40:03 <phao> cool! video =D
20140311 08:40:21 <phao> Is Gosling also maintaining jogl, btw?
20140311 08:40:38 <phao> Ahh
20140311 08:40:46 <phao> I see. Started the video now =D
20140311 08:49:14 <xranby> James Gosling are now working on his Wave Glider robots http://liquidr.com/ ... for what I know James did influence the jogl texture documentation back in 2006
20140311 08:49:42 <phao> I see.
20140311 08:50:04 <xranby> Ken Russell now work for Google in the WebGL khronos group
20140311 08:50:28 <xranby> and Sven Gothel work full time on JogAmp
20140311 08:51:11 <phao> full time?
20140311 08:51:18 <phao> YOu mean, it's his job?
20140311 08:52:34 <xranby> sure
20140311 08:53:17 <zubzub> and still there is so much bad code in nativewindow ;)
20140311 08:54:57 <xranby> ?
20140311 08:55:28 <zubzub> well from an architecture point of view
20140311 08:56:37 <phao> I have no clue how someone could make $$ developing jogamp...
20140311 08:57:15 <zubzub> the implementation for different platform is scattered and mixed in nativewindow
20140311 08:57:37 <zubzub> it works sure, but adding a new platform is errr challanging
20140311 08:58:29 <xranby> zubzub: do you have a git for the wayland changes?
20140311 08:58:47 <zubzub> I saw a git repo on github
20140311 08:58:59 <zubzub> and I also saw there was some kind of official git on the site?
20140311 08:59:08 <zubzub> but I haven't yet started on the wayland changes
20140311 08:59:18 <zubzub> I'm trying to understand the existing code first :)
20140311 08:59:34 <xranby> the git at jogamp.org http://jogamp.org/git/ is the master
20140311 08:59:44 <xranby> the gits at github are mirrors
20140311 09:00:01 <xranby> it work fine to push patches for any of them
20140311 09:00:06 <zubzub> ah ok
20140311 09:00:13 <zubzub> then I'll take the one on github
20140311 09:00:33 <zubzub> https://github.com/sgothel/jogl
20140311 09:00:34 <xranby> yes that is convinient
20140311 09:01:13 <xranby> there is https://github.com/JogAmp/jogl as well
20140311 09:01:41 <zubzub> ah is that the 'official one?
20140311 09:02:25 <zubzub> it's a fork from sgothel one
20140311 09:03:00 <xranby> as long as the git checksums match
20140311 09:03:07 <zubzub> ok :)
20140311 09:04:02 <xranby> fir the wayland post, a good start is to implement the native window initialization first
20140311 09:04:14 <xranby> we can do input later
20140311 09:04:17 <zubzub> I was lookint at the factory classes
20140311 09:04:54 <zubzub> but it became confusing quickly :)
20140311 09:05:22 <xranby> the sourceode uses static constructors as a way to implement singleton initialization
20140311 09:05:51 <xranby> on many places.. to make sure initialization is only run once even in multithreaded applications
20140311 09:05:54 <zubzub> ideally platform specific code should also be isolated into seperate classes/packages/projects
20140311 09:06:04 <zubzub> but I understand that it grew organically over time
20140311 09:06:44 <xranby> most of jogamp code do lazy initialization since it reduces statup time for applications
20140311 09:08:12 <zubzub> yeah I remember seeing that in some display related classes
20140311 09:08:14 <xranby> native system librarys gets dynamically linked in using gluegen helper classes
20140311 09:08:38 <xranby> this allows jogl to make sure that the symbols actually exist
20140311 09:08:59 <zubzub> ic
20140311 09:10:07 <xranby> in some cases we can handle several native system library versions using the same code... by resolving library symbols at runtime
20140311 09:12:49 <xranby> do users of wayland need to open a new system library?
20140311 09:13:12 <xranby> do we need to lookup new symbold in libEGL?
20140311 09:13:16 <xranby> symbols
20140311 09:13:51 <zubzub> the wayland java library links directly the native libwayland
20140311 09:14:40 <zubzub> you don't need any seperate libraries except for libwayland afaik
20140311 09:15:57 <zubzub> as for new symbols not that I'm directly aware of
20140311 09:16:29 <zubzub> (it's still pretty vague for me as I'm following it for some time now from a distance)
20140311 09:17:21 <zubzub> http://ppaalanen.blogspot.be/2012/03/what-does-egl-do-in-wayland-stack.html
20140311 09:17:25 <zubzub> gives a good overview
20140311 09:19:48 <xranby> "The client calls the wayland-egl API (implemented in Mesa) function wl_egl_window_create() to get the native window handle."
20140311 09:19:55 <zubzub> and jekstrand on #wayland also knows quite a lot (and is the author of the java bindings)
20140311 09:20:37 <xranby> "The native window handle is used to create the EGLSurface EGL handle. "
20140311 09:21:11 <xranby> "The client now has an EGLSurface ready, and renders into it by using one of the GL APIs or OpenVG offered by Mesa."
20140311 09:22:38 <xranby> so in a nutshell we need to add code that can do this initialization
20140311 09:24:51 <zubzub> hmm idd
20140311 09:25:44 <zubzub> I'll ask jekstrand what his idea is
20140311 09:28:20 <zubzub> but wl_egl_window_create is a wayland api
20140311 09:33:39 <zubzub> so the java wayland binding should provide is afaik
20140311 09:33:44 <zubzub> s/is/it
20140311 09:37:12 <xranby> the https://github.com/jekstrand/wayland-java project never uses wl_egl_window_create
20140311 09:37:20 <zubzub> it's a generator
20140311 09:37:24 <zubzub> you have to run it
20140311 09:37:31 <xranby> it only use wl_display_connect for what i can tell
20140311 09:37:34 <zubzub> and look at the gnerated code
20140311 09:37:41 <xranby> ok let me try compile it
20140311 09:38:17 <xranby> i get compile errors when i try compile it hmm
20140311 09:38:29 <zubzub> afaik with wayland 1.3 it should work
20140311 09:38:56 <zubzub> (I got it to work but that was 3+ months ago)
20140311 09:39:16 <zubzub> wayland 1.4 is also out
20140311 09:39:24 <zubzub> not sure if it's already in official repos
20140311 09:39:30 <xranby> i see.. i only want some old 0.85 version shipped with ubunt
20140311 09:39:41 <xranby> ubuntu
20140311 09:39:53 <xranby> ii libwayland-dev 0.85.0-1ubuntu2 wayland compositor infrastructure - development files
20140311 09:40:00 <zubzub> 0.85 was the first wayland version declared stable
20140311 09:41:03 <zubzub> https://launchpad.net/ubuntu/+source/wayland/1.4.0-1
20140311 09:42:01 <xranby> since we do not know on forehand which version of wayland jogl is going to get used with.. we need to have support for all the current versions...
20140311 09:42:12 <xranby> which version is used on jolla?
20140311 09:42:30 <zubzub> good question
20140311 09:42:35 <zubzub> I think a relatively recent one
20140311 09:43:14 <zubzub> let me see
20140311 09:44:53 <zubzub> jolla uses sailfish that uses mer that uses qt5 that runs on wayland 1.3 iirc
20140311 09:45:05 <zubzub> hard to find the exact version
20140311 09:52:55 <zubzub> 1.1
20140311 09:53:00 <zubzub> they plan to move to 1.3
20140311 09:53:14 <zubzub> 10:46 < zubzub> does anyone one what version of wayland Jolla uses (1.3?)
20140311 09:53:14 <zubzub> 10:47 < Stskeeps> 1.1, sadly
20140311 09:53:14 <zubzub> 10:47 < Stskeeps> we'll move to 1.3 at some point
20140311 09:53:41 <zubzub> the java wayland bindings don't work with vanilla 1.1 wayland iirc
20140311 10:16:57 <xranby> i would start by creating a header file in jogl that define the wl_egl_window struct
20140311 10:17:18 <xranby> thus something similar to http://cgit.freedesktop.org/mesa/mesa/plain/src/egl/wayland/wayland-egl/wayland-egl-priv.h
20140311 10:18:19 <xranby> if this struct is different for the three wayland versions then we need three headers
20140311 10:19:20 <xranby> the goal is to have something you can use to compile a wayland binding without ahving access to the wayland sourcecode
20140311 10:20:12 <zubzub> the java wayland bindings use the protocol xml to generate the bindings
20140311 10:20:37 <zubzub> but the jni probably needs the libwayland header files
20140311 10:21:48 <zubzub> I'll see if I can get it to generate some bindings this evening
20140311 10:22:09 <zubzub> and ask jekstrand what could be a good approach
20140311 10:22:51 <xranby> feel free to ask us how we have soved things in jogl
20140311 10:23:16 <zubzub> afaik libwayland-client already links to mesa-with-wayland-egl and the java-bindings link to libwayland-client (and server)
20140311 10:23:23 <zubzub> I will! :)
20140311 10:57:18 * hija (~hija@anon) has joined #jogamp
20140311 11:48:19 <phao> HEy... besides saving space, is there any reason to prefer float over double?
20140311 11:48:39 <phao> For usual CPU computing afaik there is very little, but for GPU, I've heard the performance differences can be really large.
20140311 11:52:34 <xranby> phao: only opengl 4 hardware support double
20140311 11:52:59 <phao> I see
20140311 11:54:53 <xranby> http://blog.hvidtfeldts.net/index.php/2012/07/double-precision-in-opengl-and-webgl/
20140311 12:00:21 <phao> I see..
20140311 12:00:32 <phao> well, I guess I 'll keep my floats
20140311 12:00:34 <phao> floating around
20140311 12:00:35 <phao> =D
20140311 12:01:04 <rmk0> in my experience, cache effects tend to dominate
20140311 12:01:32 <rmk0> i think the general belief is that floats and doubles take the same amount of time to compute with (as the hardware will simply load single precision floats into double precision sized registers)
20140311 12:01:54 <rmk0> but that doubles, being twice the size of floats in memory, will cause things to spill out of cache lines
20140311 12:02:20 <zubzub> on arm machines there's also a performance diff between float & double iirc
20140311 12:02:22 <phao> rmk0, so even in CPUs it makes sense to use floats?
20140311 12:02:44 <rmk0> phao: i've seen performance improvements doing it on desktop CPUs, yeah
20140311 12:03:15 <rmk0> is more a matter of whether you can live with the loss of precision
20140311 12:05:00 <phao> I've never did something serious enough so that the difference in precision made a difference (to my knowledge).
20140311 12:05:09 <phao> I always used double though.
20140311 12:09:30 <phao> I sometimes become kind of frozen when I stop to make decisions like
20140311 12:09:45 <phao> should I use an int or byte here? Maybe a long? Float or double?
20140311 12:10:11 <phao> today, I'm pretty much going with the defaults
20140311 12:10:31 <phao> ints for everything; longs when I already know for whatever other reason I cannot use int; double.
20140311 12:10:42 <phao> I've started using floats for opengl. Outside opengl, it's all double.
20140311 12:11:37 <rmk0> not unreasonable
20140311 12:12:50 <phao> it's been working
20140311 12:12:57 <phao> the problem is how clueless I am about this
20140311 12:13:30 <phao> for example, it works, but I almost never think how reasonable is to choose double or int
20140311 12:14:07 <phao> anyway... Afaik, it doesn't matter so much.
20140311 12:17:07 <xranby> one thing to avoid is to use float or double as loop cpunters
20140311 12:17:11 <xranby> counters
20140311 12:18:23 <phao> There were very few situations in which I did such a thing.
20140311 12:18:42 <phao> I'm not actually sure though. That sounds really odd.
20140311 12:23:20 <rmk0> i'd recommend BigInteger for large discrete quantities or "identifiers" over long
20140311 12:23:25 <rmk0> because java has unchecked integer overflows
20140311 12:23:51 <rmk0> is obviously standard practice in safer languages like haskell to use big integers everywhere
20140311 12:24:20 <phao> I see.
20140311 12:24:33 <rmk0> they're not without cost, but it does eliminate classes of bugs that can be hard to even test for
20140311 12:24:50 <rmk0> like... are you really going to test what happens when your program manages to do something more than four billion times?
20140311 12:24:58 <rmk0> (and keeps a count of some sort)
20140311 12:25:05 <phao> hehee
20140311 12:26:10 <phao> I remember coding a linked list implementation which used some internal memoery management techniques for its own. And I decided to add checks for overflow and trying to behave appropriately.
20140311 12:26:14 <phao> It made the code a lot larger.
20140311 12:26:22 <phao> That was in C.
20140311 12:26:42 <rmk0> yeah, is difficult
20140311 12:28:57 <rmk0> really need language support to make it safe
20140311 12:29:42 <rmk0> in languages like coq, you're forced to supply proofs that arithmetic doesn't overflow, if you use fixed-size integers
20140311 12:29:50 <rmk0> in ada, the compiler inserts runtime checks at every expression
20140311 12:33:03 <phao> sounds nice... but there are there optimisations to remove it away in some cases? (done by the compiler)
20140311 12:33:17 <rmk0> some, yeah
20140311 12:33:36 <rmk0> it's an undecidable problem in the general case
20140311 12:33:52 <phao> I imagine so. Like the array check with java.
20140311 12:33:59 <rmk0> yesh
20140311 12:34:33 <phao> I've always wanted to use coq
20140311 12:34:44 <phao> not just coq, but other development tools and languages out there.
20140311 12:35:03 <phao> When I got onto scheme, I did some of the "other things out there", but I never went much further.
20140311 12:35:07 <rmk0> it's brutal
20140311 12:35:10 <phao> I did some SML and very little haskel.
20140311 12:35:16 <phao> Brutal?
20140311 12:35:28 <rmk0> coq, and the current pile of dependently typed languages
20140311 12:35:42 <phao> why brutal?
20140311 12:36:01 <rmk0> the learning curve is extreme, and you soon realize just how much is taken for granted in more weakly-typed languages
20140311 12:36:19 <rmk0> essentially anything that can't be proven trivially is a potential source of serious bugs
20140311 12:37:40 <rmk0> think the type systems in ML and ocaml are probably still the "best" in terms of the effort expended to write programs vs the number of guarantees the types provide
20140311 12:38:32 <rmk0> they just don't have good tool support or libraries
20140311 12:39:59 <rmk0> supposedly there's still an ongoing effort to port ocaml to the jvm
20140311 12:43:12 <rmk0> all that matters to me is program correctness, really
20140311 12:43:24 <rmk0> it's basically the one thing that you can't do without
20140311 12:43:42 <rmk0> if a language can't help me write correct programs, what use is it
20140311 12:43:43 <rmk0> ?
20140311 12:45:49 <rmk0> phao: http://www.cis.upenn.edu/~bcpierce/sf/
20140311 12:45:57 <rmk0> still the best available book on coq at the moment
20140311 12:46:32 <phao> I see.
20140311 12:46:45 <phao> I thought coq was some kind of tool which helped programming in other languages.
20140311 12:46:57 <rmk0> it's a theorem prover
20140311 12:47:09 <rmk0> and a dependently-typed pure functional language
20140311 12:47:19 <phao> I see.
20140311 12:47:24 <phao> About "correctness".
20140311 12:47:33 <rmk0> essentially write programs in coq, including proofs of correctness and then it can spit out the equivalent program in ocaml, scheme, haskell
20140311 12:47:48 <rmk0> with the dependent types erased
20140311 12:47:50 <phao> What about testing? We know that it doesn't prove correctness, but people afaik are getting good results with it.
20140311 12:48:21 <rmk0> is obviously still essential if you don't have formal correctness proofs
20140311 12:48:41 <rmk0> i obviously strive for close to 100% test coverage in all of the java i write
20140311 12:48:43 <phao> Do you make use of proofs?
20140311 12:49:10 <rmk0> i don't make use of proofs directly in java, but it teaches a certain mindset... you tend to learn to use types to enforce invariants and do some of the work of proofs
20140311 12:49:22 <rmk0> is only because there are basically no tools for doing that in java
20140311 12:51:03 <rmk0> no tools for proving the properties of code written in java, i mean
20140311 12:51:10 <rmk0> and no way to extract java from something like coq
20140311 12:51:12 <phao> Do you think some kind of toolset could be built... maybe based on annotations?
20140311 12:51:36 <rmk0> it's more a problem of proving things about code that's imperative and uses mutable state
20140311 12:51:57 <phao> and has concurrency* =D
20140311 12:52:09 <rmk0> shared memory concurrency, yeah
20140311 12:52:16 <rmk0> slightly less difficult to prove things about CPS or actors
20140311 12:52:45 <rmk0> CSP, even
20140311 12:53:19 <phao> I see.
20140311 12:53:31 <phao> And, do you __have__ to write java code at your work?
20140311 12:53:39 <rmk0> i'm self employed
20140311 12:53:48 <rmk0> settled on java because everything else failed
20140311 12:53:55 <phao> hehehhehe
20140311 12:54:14 <rmk0> wasn't an easy decision
20140311 12:54:17 <phao> But depending on what you're doing, you can use pretty much whatever you want.
20140311 12:54:30 <rmk0> more or less
20140311 12:54:43 <phao> I know a person who uses scheme for web development here in Brazil.
20140311 12:54:56 <phao> Believe me, that's completely counter-productive here.
20140311 12:55:00 <rmk0> hehe
20140311 12:55:04 <rmk0> no types!
20140311 12:55:43 <rmk0> i would have used ocaml, but it can't do concurrency and has no libraries. would have used haskell but the libraries are all broken and the language has bizarre performance characteristics... the C language families are way too unsafe, ada is dominated by a single company that produces a horrendously buggy compiler and there are also no libraries for it
20140311 12:55:56 <rmk0> pretty much everything else is untyped
20140311 12:56:07 <rmk0> basically left java... which does have excellent tool support and excellent libraries
20140311 12:56:17 <rmk0> can get just enough safety out of the language's type system to enforce most things
20140311 12:56:22 <rmk0> i'd be screwed if it didn't exist
20140311 12:56:33 <phao> what about c#?
20140311 12:56:38 <rmk0> not portable
20140311 12:56:43 <rmk0> mono is pretty terrible
20140311 12:56:56 <phao> I see.
20140311 12:57:01 <rmk0> the language isn't bad, though
20140311 12:57:03 <rmk0> as these things go
20140311 12:57:09 <phao> ahh
20140311 12:57:09 <phao> go =D
20140311 12:57:16 <rmk0> ugh!
20140311 12:57:17 <phao> there is also go.
20140311 12:57:20 <phao> heheehe
20140311 12:57:20 <rmk0> hehe
20140311 12:57:49 <rmk0> is a prime example of noone keeping up with programming language research
20140311 12:58:03 <phao> I'm out of ideas. I'd actually consider, in your situation to write tools on my own to support programming in the language I want.
20140311 12:58:10 <phao> and, afaik, ocaml has support for concurrency.
20140311 12:58:14 <phao> No?
20140311 12:58:19 <rmk0> that's pretty much what i do
20140311 12:58:25 <rmk0> the ocaml runtime is single threaded
20140311 12:58:27 <phao> What about scala?
20140311 12:58:35 <rmk0> you can spawn threads, but only one can run at once... is really bad
20140311 12:58:48 <rmk0> scala's pretty disastrous
20140311 12:58:57 <phao> why so?
20140311 12:59:11 <rmk0> they inherited a lot of type system complexity from making it java-compatible... pervasive subtyping, etc
20140311 12:59:25 <rmk0> and then layered on a lot of complicated type system features from languages like haskell
20140311 12:59:32 <rmk0> and then introduced implicit parameters!
20140311 12:59:53 <rmk0> the result is something that the compiler can barely cope with... type system is utterly unsound, inference is awful, tools can't deal with it, etc
20140311 13:00:21 <rmk0> i wrote a compiler in it for a simple shading language and then rewrote it in java in disgust
20140311 13:00:40 <phao> technology doesn't seem to be on your side.
20140311 13:00:44 <rmk0> hehe
20140311 13:00:58 <rmk0> the main issue is that most languages aren't developed with correctness in mind
20140311 13:01:34 <rmk0> as an example, count the number of "dynamically typed object-oriented" languages compared to statically typed functional languages available
20140311 13:01:51 <phao> yeah... it's pretty bad.
20140311 13:01:56 <rmk0> the latter provide strong correctness guarantees, the former are basically an invitiation to blow off all of your limbs
20140311 13:02:05 <zubzub> rmk0: I have a friend who's a go lover
20140311 13:02:11 <rmk0> /o\
20140311 13:02:13 <zubzub> rmk0: tell me again why it is bad so I can torment him
20140311 13:02:18 <phao> I know you don't like JS, but what about typescript?
20140311 13:02:28 <rmk0> not sure what typescript is
20140311 13:02:39 <rmk0> zubzub: it's not so much that it's "bad", but it's basically memory-safe C
20140311 13:02:48 <phao> typescript is a superset of js
20140311 13:03:04 <phao> it adds some features, like optional static typing afaik
20140311 13:03:09 <zubzub> rmk0: what about all the fluffy strand/fiber/thread thingies
20140311 13:03:41 <rmk0> phao: think the concept of "optional" typing is pretty ridiculous
20140311 13:03:52 <rmk0> think it shows a lack of understanding of the whole idea of typing
20140311 13:04:14 <rmk0> zubzub: don't know about those
20140311 13:05:21 <rmk0> the arguments for optional typing don't really stand up to scrutiny... they're almost always based on either "i don't want to write type annotations everywhere" or "i WANT this variable to either be an integer or a string or a ..."
20140311 13:05:47 <rmk0> well designed modern languages have full inference, so there's no need to write annotations
20140311 13:06:00 <rmk0> and variables having types that change over the course of evaluation is ... insane
20140311 13:06:14 <rmk0> and can be done in a way that's actually safe with algebraic types, anyway
20140311 13:06:32 <phao> rmk0, what about tools like quickcheck?
20140311 13:07:01 <rmk0> phao: i use the java quickcheck here and there
20140311 13:07:20 <rmk0> is pretty decent
20140311 13:07:30 <phao> couldn't you deal with the correctness issue by relying more on tools like that?
20140311 13:07:37 <phao> It's just testing, but it seems to be good enough, no?
20140311 13:08:08 <rmk0> well as i said, i do have to rely on testing in java for those things that can't be enforced at the type-level
20140311 13:08:28 <rmk0> quickcheck's decent for blasting code with a lot of random cases
20140311 13:08:46 <rmk0> isn't much good for testing specific behaviour... you still have to manually write tests for that
20140311 13:08:49 <phao> do you have some code I can see using types to enfoce properties that you like enforced. I can see this happening on a small scale, but on a larger scale I can't envision it.
20140311 13:09:07 <rmk0> it tends to be kind of program specific
20140311 13:09:23 <rmk0> i've got, er...
20140311 13:10:00 <rmk0> http://io7m.com/documents/java/tt0-pcio/index.xhtml
20140311 13:10:00 <rmk0> http://io7m.com/documents/java/tt1-pt/index.xhtml
20140311 13:10:00 <rmk0> http://io7m.com/documents/java/tt2-intcap/index.xhtml
20140311 13:10:07 <rmk0> these are three that i use heavily in all of the java code i write
20140311 13:10:38 <rmk0> depends what you mean by "scale", really
20140311 13:11:07 <rmk0> in the renderer i'm working on, i tag all matrices and vectors with their transform types and coordinate spaces, so i can never mix them up
20140311 13:11:26 <rmk0> that statically prevents a shitload of problems that opengl programmers often have (like trying to do lighting with vectors in different spaces)
20140311 13:12:03 <rmk0> it also acts as documentation... a programmer knows just by looking at the function prototype that he/she needs to pass in a vector that represents a position in world space, etc
20140311 13:12:27 <rmk0> i'd sort of class that as large scale, because it enforces correctness over thousands of lines of code
20140311 13:12:38 <phao> I see.
20140311 13:13:43 <rmk0> but all of the above came from typed functional languages like haskell/ocaml
20140311 13:13:50 <rmk0> can obviously push it a lot further in those
20140311 13:13:54 <rmk0> java's type system just can't do it
20140311 13:13:56 <phao> in here, http://io7m.com/documents/java/tt1-pt/index.xhtml
20140311 13:14:05 <phao> why is WorldSpace a class?
20140311 13:14:08 <phao> It could be an empty interface, no?
20140311 13:14:31 <rmk0> yeah, should fix that... it is an interface in any program i write
20140311 13:14:41 <rmk0> there's no value-level representation
20140311 13:14:49 <phao> I'll read those links. It seems really interesting.
20140311 13:15:13 <xranby> rmk0: http://forum.jogamp.org/2-1-5-Release-td4031829.html
20140311 13:15:16 <rmk0> should mention again that they're techniques that fall out naturally from languages like ocaml/haskell
20140311 13:15:26 <zubzub> rmk0: those links for me seem like things any good (java) programmer should do
20140311 13:15:27 <phao> The close that I've came to doing stuff like this is with type parameters in base class which must be of types which are subtypes of this base class.
20140311 13:15:30 <phao> like class Foo<T extends Foo>
20140311 13:15:34 <rmk0> xranby: \o/
20140311 13:15:39 <zubzub> (I know I try to do them as much as I can)
20140311 13:15:41 <rmk0> xranby: will push to central now
20140311 13:15:41 <phao> and that helps in some cases.
20140311 13:16:01 <rmk0> phao: yeah, is often essential
20140311 13:16:33 <phao> Maybe I should take a look at those things more often. To see what I can bring up to java and js development.
20140311 13:16:41 <phao> I'm not sure, but maybe C++ tool
20140311 13:16:45 <phao> ahh
20140311 13:16:53 <phao> rmk0, with C++ you can do a lot of what you want, afaik.
20140311 13:17:04 <rmk0> yeah, main issue there is that the polymorphism isn't implicit
20140311 13:17:05 <phao> the crap is all still there, but afaik, you can avoid it altogether.
20140311 13:17:15 <rmk0> you have to instantiate templates manually... can make it quite painful to write
20140311 13:17:29 <phao> well, maybe not with C++11 and C++14
20140311 13:17:30 <rmk0> the techniques are more or less the same though, because the type system is similar
20140311 13:17:43 <phao> there are some new feature which allow for much more convenient to write template code.
20140311 13:17:48 <rmk0> hm, right
20140311 13:17:58 <phao> I'm not sure if they solve the problems.
20140311 13:18:05 <phao> Firstly because idk which are the problems (hehehe)
20140311 13:18:12 <rmk0> knowing the c++ people, they probably introduce a hundred new ones
20140311 13:18:17 <phao> but there are new language feature which make C++ code writing and reading much better.
20140311 13:18:47 <phao> C++11 is huge... It has some type inference, it has closure now, it has templates with variable number of params
20140311 13:18:56 * rmk0 chokes
20140311 13:19:05 <phao> hehehe
20140311 13:19:11 <phao> take a look some time
20140311 13:19:12 <phao> For example
20140311 13:19:21 <phao> you can do stuff like
20140311 13:19:51 <phao> for (auto &a: points) { <change a somehow> }
20140311 13:20:12 <phao> auto there will deduce which type must be, and points may be anything you can call begin on, etc.
20140311 13:20:38 <rmk0> yeah
20140311 13:20:49 <rmk0> is the same local inference scala has
20140311 13:20:56 <rmk0> with all of the same issues, no doubt
20140311 13:21:01 <phao> hehehe
20140311 13:21:18 <phao> there is something which looks kind of like a templated typedef
20140311 13:21:19 <rmk0> inference in languages with subtyping is ... hard ... to say the least
20140311 13:21:55 <phao> it doesn't need to be templated. It's a new mechanism for specifying type aliases
20140311 13:21:57 <phao> and it can be templated.
20140311 13:22:03 <phao> it uses the 'using' keyword
20140311 13:22:32 <phao> iirc, you can do template<typename T> using vec = vector<T>;
20140311 13:22:42 <phao> I don't remember it very well... but it's something like that
20140311 13:23:12 <phao> template<typename T> using vecMyAlloc = vector<T, ...allocator stuff here...>; // for example
20140311 13:23:16 <rmk0> might be lipstick on a pig
20140311 13:23:21 <phao> heehehheeheh
20140311 13:23:45 <phao> anyway, I didn't get to see much of those features... I just know it has lots of them.
20140311 13:24:03 <rmk0> think it's more or less trying to accumulate every feature from every language
20140311 13:24:15 <phao> that was my impression
20140311 13:24:18 <phao> Ahh
20140311 13:24:23 <phao> it has threads and concurrency mechanisms now too
20140311 13:24:56 <rmk0> yep
20140311 13:29:14 <rmk0> likely better than writing a library once for windows threads, once for pthreads, etc... if the semantics are actually consistent
20140311 13:29:26 <rmk0> i bet they aren't!
20140311 13:29:31 <phao> hehehe
20140311 13:29:42 <phao> In the example saying that inheritance is not really a good way to go in http://io7m.com/documents/java/tt1-pt/index.xhtml
20140311 13:30:10 <phao> would'd doing something like <T extends Point> T reflectX(T point) solve the issue?
20140311 13:31:24 <zubzub> that would ensure that whatever you pass in as an argument has to be a point and must return the same type that was passed in
20140311 13:31:59 <rmk0> yeah, would likely do it, i think, as generic parameters are invariant
20140311 13:32:04 <phao> Sure zubzub. That's why I asked.
20140311 13:32:06 <rmk0> i can't remember what the issue was there
20140311 13:32:42 <phao> well
20140311 13:32:52 <phao> there is always casting
20140311 13:32:57 <rmk0> think it may have just been that if you've used inheritance, you now have three type definitions instead of one
20140311 13:33:16 <phao> you could do something like P1 extends P2 and do
20140311 13:33:27 <phao> reflectX((P2) p1)
20140311 13:33:35 <phao> that would give you a P1 back.
20140311 13:34:01 <phao> But that sort of problem doesn't seem to be avoidable with the other approach.
20140311 13:34:22 <rmk0> not sure what you mean there
20140311 13:34:27 <phao> Well
20140311 13:34:42 <phao> Thinking about it, it doesn't seem important
20140311 13:34:44 <phao> But...
20140311 13:34:56 <phao> if you wanted to make sure that it was THE SAME type that came in went out
20140311 13:35:05 <phao> what I suggest would fail
20140311 13:35:14 <phao> because you could pas an object of a subtype casted to a supertype
20140311 13:35:28 <phao> reflectX would return an object of supertype, but it was given one of a subtype.
20140311 13:35:28 <rmk0> oh, right
20140311 13:35:47 <phao> which is an issue because, as you've said, there are 3 types now
20140311 13:35:49 <phao> not just one.
20140311 13:36:11 <rmk0> there are a lot of edge cases like this
20140311 13:36:12 <phao> With your approach, you can make Point final and problem is solved. With the other approach, Point can't be final, but the other 2 can.
20140311 13:36:18 <rmk0> is... why i prefer to avoid the whole issue
20140311 13:36:42 <rmk0> you can imagine how much fun scala is where inference and implicits are involved, and it has to deal with types like this
20140311 13:37:35 <phao> I see.
20140311 13:37:40 <rmk0> think subtyping should be elective, if the language even has it at all
20140311 13:37:50 <phao> elective?
20140311 13:37:54 <phao> idk what that means, hehehe
20140311 13:37:59 <rmk0> like... you don't get it if you don't ask for it
20140311 13:38:18 <rmk0> haskell has no subtyping rules, ocaml has subtyping rules for a specific set of types
20140311 13:38:28 <rmk0> java just has subtyping everywhere
20140311 13:38:41 <phao> I see.
20140311 13:38:43 <rmk0> leads to problems
20140311 13:38:49 <phao> well, you can use final..
20140311 13:38:56 <phao> doesn't it solve the problem?
20140311 13:41:05 <phao> rmk0, changing subjects a little bit.
20140311 13:41:12 <phao> are you into stuff like agile, xp, scrum, ... ?
20140311 13:45:09 <rmk0> phao: you can use final, yes, but it doesn't change the fact that every typing judgement is affected by subtyping rules
20140311 13:45:21 <rmk0> so inference algorithms can't infer a "most general" type
20140311 13:45:28 <rmk0> they usually infer something useless like Object
20140311 13:45:37 <rmk0> and no... not really into those things
20140311 13:45:48 <rmk0> working alone!
20140311 13:47:22 <phao> cool texts, btw.
20140311 13:47:29 <rmk0> thanks... quite enjoy writing
20140311 13:47:33 <zubzub> idd
20140311 13:47:37 <zubzub> you should write more of them :p
20140311 13:47:57 <rmk0> i've got quite a few things i'd like to cover, but i can rarely fit it in
20140311 13:48:03 <phao> I've been reading about agile. It's kind of boring.
20140311 13:48:11 <phao> There are people really excited about it. I can't really see much why.
20140311 13:48:23 <rmk0> think it tends to be an excuse to not write documentation and not plan ahead at all
20140311 13:48:31 <phao> hehehe
20140311 13:48:45 <rmk0> at least that's the only way i've ever seen it used
20140311 13:48:46 <phao> Even when it's taken seriously (in which case, they do these things too) it sounds boring.
20140311 13:48:55 <phao> Martin Fowler has an article on this.
20140311 13:49:15 <zubzub> kanban++
20140311 13:49:20 <phao> He mentions that people adpt agile methods without having technical maturity for doing these things, and fail the same way they were.
20140311 13:49:45 <rmk0> right
20140311 13:50:25 <rmk0> the most pleasant way i've seen to work in teams is with small teams, with a rough executable specification written in haskell first
20140311 13:50:38 <rmk0> that way there can be no misunderstanding about what's being written
20140311 13:50:41 <phao> what is an executable specification?
20140311 13:51:12 <rmk0> is basically a small model of the intended program written in haskell... you can run it from the interpreter
20140311 13:51:30 <phao> and what does it mean to run it?
20140311 13:52:20 <rmk0> hehe... trying to think of the right way to explain
20140311 13:52:29 <phao> hehehehe
20140311 13:52:43 <phao> well, what is the input of it?
20140311 13:53:00 <rmk0> what i mean is, you make an idealized and simplified view of the program or system you're writing, and you make a sort of model of it using types and pure functions
20140311 13:53:30 <rmk0> the point is to eliminate the sort of ambiguity you get in written/spoken english (or language of choice)
20140311 13:53:44 <phao> I see.
20140311 13:53:50 <rmk0> if someone has a question about what the program is supposed to do, they evaluate some of the functions in the interpreter to see what the expected output is
20140311 13:53:50 <phao> So it's not really about running the program.
20140311 13:54:06 <phao> I see.
20140311 13:54:37 <rmk0> assume i say to you "this command, when sent to the server, returns a list of the logged-in users on the server"
20140311 13:54:48 <rmk0> there are any number of possible meanings for that
20140311 13:55:06 <rmk0> does it return the list of all users? does it return the list of users that i'm permitted to see, if there's a security model of some sort, etc
20140311 13:55:26 <rmk0> the executable specification tells you exactly, because you've been forced to describe it as types and functions
20140311 13:55:56 <rmk0> it's sort of a lightweight version of the way things are done during formal validation/verification in something like coq
20140311 13:56:01 <rmk0> without using proofs
20140311 13:56:14 <rmk0> is meant as a tool for understanding rather than a strict specification
20140311 13:56:31 <phao> can you apply this to stuff like computer graphics and opengl programming?
20140311 13:57:06 <rmk0> yeah, i use to describe the shaders for the renderer i'm working on
20140311 13:57:32 <rmk0> like "if this material has environment mapping enabled, this is exactly how it's applied with relation to the other material properties"
20140311 13:58:15 <rmk0> of course, because it's only me working on it, the specification has drifted out of sync with what was implemented
20140311 13:58:28 <rmk0> had i been working with other people, i'd have kept it up to date
20140311 13:58:33 <rmk0> it'll be updated when the whole thing is documented
20140311 13:59:00 <rmk0> the approach applies to any problem really
20140311 13:59:17 <rmk0> is up to the individuals involved how much detail they put into it... is supposed to be just enough for everyone to understand what they're writing
20140311 13:59:31 <rmk0> is obviously a huge problem in teams where everyone's working on their own idea of the program and the ideas don't match
20140311 13:59:59 <rmk0> just... down to the ambiguity of the language used to discuss the program
20140311 14:00:06 <rmk0> (english, etc)
20140311 14:00:31 <rmk0> i've only worked for one company that did it
20140311 14:00:38 <rmk0> not sure if they carried on after i left
20140311 14:01:24 <phao> that kind of stuff surely doesn't sound common
20140311 14:01:41 <rmk0> is a shame, because it's extremely effective given how easy it is
20140311 14:02:18 <rmk0> i think the type of development that "agile" is rebelling against is where everything is planned in excruciating detail, and the plan can't be kept up to date with changing requirements
20140311 14:02:47 <rmk0> their approach is to never plan at all, which causes as many problems as it solves, because the language used to discuss the problem is ambiguous and no two people have the same idea
20140311 14:02:54 <zubzub> the plan can't be kept up because of changing requirements but because of uknown factors that you *always* have
20140311 14:03:17 <rmk0> but if you have a way to write a plan that's non-ambiguous and can be kept up to date easily, it solves a lot of problems
20140311 14:03:38 <rmk0> doesn't require such detail, because the semantics of the language it's written in clear up the ambiguity
20140311 14:04:59 <rmk0> just looked up "executable specifications"
20140311 14:05:41 <rmk0> seems to be all related to test-driven development, which isn't the same thing at all
20140311 14:06:12 <phao> hehehe
20140311 14:06:28 <phao> yep.. there is an "executable specification" thing related to tdd
20140311 14:06:32 <phao> it seems pretty popular
20140311 14:06:49 <rmk0> the sort of specifications i'm talking about might only run to a few hundred lines in something like haskell that has compact syntax
20140311 14:06:55 <phao> but what you write, iirc, is some sort of spec
20140311 14:06:55 <rmk0> not including any informative comments
20140311 14:07:16 <rmk0> right
20140311 14:08:07 <rmk0> think the sorts of specifications they're talking about is the next step along... you write tests that show what the implementation will do, because the small spec you wrote in haskell says this is what should happen
20140311 14:08:32 <rmk0> are actually related to a direct implementation, as opposed to something more abstract
20140311 14:09:36 <rmk0> http://waste.io7m.com/2010/12/07/CES.hs
20140311 14:09:53 <rmk0> is an example of an olde executable specification i had laying around for an "entitlements server"
20140311 14:10:23 <phao> http://jnario.org/
20140311 14:10:24 <rmk0> basically a server that responds with a yes or no answer when a device asks it if the user owns something they're trying to download
20140311 14:10:35 <phao> you write the "spec" but not really
20140311 14:10:39 <phao> it's in terms of specific test cases
20140311 14:10:55 <rmk0> right
20140311 14:14:00 <phao> bbl
20140311 14:14:07 * rmk0 waves
20140311 14:14:26 <rmk0> hehe, can definitely tell the atomics are included this time... uploading to maven central is taking much longer
20140311 14:14:48 <xranby> \o/ /o\
20140311 14:14:55 <rmk0> hehe
20140311 14:42:34 * phao_ (~phao@anon) has joined #jogamp
20140311 14:42:37 * phao (~phao@anon) Quit (Read error: Connection reset by peer)
20140311 15:27:08 <rmk0> yow... maven upload still going
20140311 15:27:18 <rmk0> going to have to find a way to do these from the jogamp server
20140311 15:27:44 <rmk0> the main issue is signing the artifacts (happens during maven deployment)
20140311 15:27:58 <rmk0> i use my io7m signing key currently, but one could be generated on the server for doing this
20140311 15:28:08 <rmk0> needs to be on a publically accessible key server so that the central repos can fetch it
20140311 15:28:52 <rmk0> it's basically my connection here that makes it take so long
20140311 15:28:57 <rmk0> i only get about 80kb/s up
20140311 15:29:11 <rmk0> suspect jogamp.org has slightly more bandwidth than that
20140311 15:29:14 <rmk0> !
20140311 15:30:35 <rmk0> will sort that out when this upload is done
20140311 15:50:14 * phao_ (~phao@anon) Quit (Read error: Connection reset by peer)
20140311 15:57:32 <rmk0> hah, finally done
20140311 16:38:41 <zubzub> 17:04 < jekstrand> zubzub: You would have to add support for my bindings to JOGL
20140311 16:38:48 <zubzub> 17:05 < zubzub> yeah I was planning on using your bindings :)
20140311 16:38:49 <zubzub> 17:06 < zubzub> but I was wondering if I could use them as-is or if I would need to add some extra jni
20140311 16:38:56 <zubzub> 17:36 < jekstrand> zubzub: I think you'll need to add public long getNativeHandle() methods to Display and Proxy.
20140311 16:39:21 <zubzub> 17:39 < jekstrand> zubzub: Then you'll have to write a wrapper around wayland_native_surfac and it's 3 vfuncs.
20140311 16:40:04 <zubzub> 17:39 < jekstrand> zubzub: Also be warned that my bindings and JOGL handle memory management very differently. Theirs is handled almost entirely within Java, mine's handled almost entirely within C. Not sure if that'll make a huge difference or not.
20140311 16:41:15 <zubzub> so I gues I'll have to investigate that wrapper thing
20140311 16:42:06 <zubzub> http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-egl.h
20140311 16:42:12 <zubzub> that
20140311 16:59:57 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140311 17:05:32 <rmk0> sgothel: any chance i can get gpg-agent installed whenever you're around next?
20140311 17:05:41 <rmk0> will get a gpg signing key for releases generated on the server
20140311 17:12:45 * [Mike] (~Mike]@anon) has joined #jogamp
20140311 17:19:11 <sgothel> @Zuzub: WE may have a chat about the 'ugliness' :) Some hardcoded platform notions shall be tackled w/ Bug 973. However, the general design _is_ modular, i.e. packages per platform/driver etc.
20140311 17:22:24 <sgothel> It's always a 'challenge' to make a decision whether corner cases decorated w/ 'if ( Platform.OSType == X ) { }' qualify for a whole OO plugin infrastructure .. well, thats life ..
20140311 17:24:33 <sgothel> Maybe it's time to move the Wayland discussions .. or at least the findings to it's bug report, i.e. Bug 794 ..
20140311 17:26:03 <sgothel> Regarding 'data structs' and Wayland version: Yes, we must be able to use any version while linking dynamically .. data structures are usually difficult to deal w/ .. but we have done this for ffmpeg/libav
20140311 17:30:01 * phao (~phao@anon) has joined #jogamp
20140311 17:40:25 <sgothel> @Mark: oh it's not ? gpg-agent ? will see to it
20140311 17:41:10 <rmk0> thanks!
20140311 17:41:18 <rmk0> idea is to do the deployment of maven packages on jogamp.org now
20140311 17:41:35 <rmk0> the bottleneck is my awful upload bandwidth, but it obviously means creating a new signing key that lives on the server
20140311 17:41:51 <rmk0> i'll email you the passphrase in an encrypted mail
20140311 17:41:55 <sgothel> @Zuzub: I will prefer a plain Wayland layer to the NativeWindow, JOGL and NEWT layers ..
20140311 17:43:38 <sgothel> @Mark .. need to do an update/upgrade to install it .. in process
20140311 17:43:43 <rmk0> ok
20140311 17:49:39 <sgothel> '<rmk0> i only get about 80kb/s up' outch :)
20140311 17:49:49 <rmk0> yep!
20140311 17:50:45 <sgothel> Yeah .. so the 'cleanup' of OS and Toolkit dependencies is tricky .. i.e. is code eligible for abstraction or not ?
20140311 17:51:23 <sgothel> right now .. we do it both ways, good: interface and impl-class - bad: if-then-else in some cases
20140311 17:51:50 <sgothel> all can be queried via Platform.OSType .. or NativeWindowFactory's type
20140311 17:52:09 <sgothel> tons of Debian updates .. oh oh ..
20140311 17:52:17 * rmk0 hides under the carpet
20140311 17:52:44 <sgothel> scary: zfsonlinux user-tools as well .. hope they are compatible :)
20140311 17:52:56 <rmk0> erk
20140311 17:53:00 <rmk0> well... i'm sure we'll find out
20140311 17:53:05 <sgothel> haha
20140311 17:56:39 <rmk0> think they're generally good about that
20140311 17:56:48 <sgothel> '.. updating zfs module w/ DKMS ..' .. oh yes :)
20140311 17:56:48 <rmk0> i kept a pool at version 14 with version 29 tools
20140311 17:57:20 <sgothel> good provider has a remote console ..
20140311 17:59:05 <sgothel> testing reboot on jausoft .. always good to have a dummy'
20140311 18:01:24 * monsieur_max (~maxime@anon) has joined #jogamp