#jogamp @ irc.freenode.net - 20141109 05:06:27 (UTC)

20141109 05:06:27 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20141108050627.html
20141109 05:06:27 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20141109050627.html
20141109 09:26:05 * monsieur_max (~maxime@anon) has joined #jogamp
20141109 10:40:59 * theNecris (~Pavel@anon) has joined #jogamp
20141109 10:46:51 * Eclesia (~eclesia@anon) has joined #jogamp
20141109 10:47:14 <Eclesia> morning ghosts
20141109 12:07:30 * gouessej (5279453b@anon) has joined #jogamp
20141109 12:07:34 <gouessej> Hi
20141109 12:07:45 <gouessej> I'm not a ghost and I read the logs anyway...
20141109 12:07:57 * gouessej (5279453b@anon) Quit (Client Quit)
20141109 12:20:59 <Eclesia> You are a ghost :p hiding in the shadows
20141109 12:32:58 <rmk0> .o.
20141109 12:34:41 <Eclesia> rmk0: hi
20141109 12:35:44 <rmk0> lo
20141109 13:14:02 <theNecris> I feel so bad ! can't even draw a single triangle. I really suck :(
20141109 13:34:41 * theNecris (~Pavel@anon) Quit (Quit: Leaving)
20141109 13:51:40 <monsieur_max> the infamous triangle :)
20141109 13:54:00 <Eclesia> the first boss we encounter. definitely a hard one when you are level 1.
20141109 14:06:47 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20141109 14:51:05 * Eclesia (~eclesia@anon) has joined #jogamp
20141109 14:53:01 * Eclesia (~eclesia@anon) Quit (Client Quit)
20141109 16:08:59 * monsieur_max (~maxime@anon) Quit (Ping timeout: 245 seconds)
20141109 16:25:58 * monsieur_max (~maxime@anon) has joined #jogamp
20141109 16:25:59 * monsieur_max (~maxime@anon) Quit (Client Quit)
20141109 19:06:27 * monsieur_max (~maxime@anon) has joined #jogamp
20141109 19:41:40 * Eclesia (~eclesia@anon) has joined #jogamp
20141109 19:42:12 <Eclesia> rmk0: evening, small question : what graphic card do you have ?
20141109 19:43:41 <rmk0> radeon 4670 in desktop A, radeon 4870 in desktop B, and some intel sandy bridge thing in the laptop
20141109 19:44:01 <Eclesia> it supports GL4 ?
20141109 19:44:26 <rmk0> nope
20141109 19:45:15 <Eclesia> :'(
20141109 19:45:41 <rmk0> can only get up to opengl 3.3 on the open source radeon drivers anyway, which is what i'm using
20141109 19:45:49 <rmk0> the 4* range is pre opengl 4
20141109 19:45:59 <rmk0> think the 6*** range and beyond are gl 4 capable
20141109 19:47:07 <Eclesia> do you know a tool which could say if I'm making my gl calls right ?
20141109 19:47:38 <rmk0> not ... sure how to answer that
20141109 19:47:54 <rmk0> what does "right" mean here?
20141109 19:48:21 <Eclesia> well my engine seems to work ok on NVidia cards, but have multiple and various bugs on Radeons.
20141109 19:48:42 <Eclesia> use Core profile helped me to fix several, but there are still many
20141109 19:48:47 <Eclesia> using*
20141109 19:48:50 <rmk0> the AMD stuff is generally a lot more compliant to the spec
20141109 19:49:27 <Eclesia> yes that's what I've read, that's why I would like to know more exactly what I'm not doing as expected
20141109 19:50:25 <rmk0> i don't know anything beyond enabling the debug context
20141109 19:50:32 <rmk0> in other words... DebugGL
20141109 19:50:51 <Eclesia> that will only catch exceptions ?
20141109 19:51:10 <rmk0> it'll eject all sorts of warnings on AMDs context
20141109 19:51:36 <rmk0> it'll tell you about all sorts of stupid things like "don't use unsigned byte indices in index buffers, it's faster to use unsigned shorts or ints on this hardware"
20141109 19:52:25 <rmk0> i think i took the opposite approach to you here
20141109 19:52:38 <rmk0> i wrote that jcanephora thing... basically a well tested safe layer of types over the opengl 3.* spec
20141109 19:52:57 <rmk0> so it's very hard for me to write something that isn't conformant, as the types won't let me
20141109 19:53:12 <rmk0> won't do much good for you though... it lacks anything in opengl 4.*
20141109 19:53:50 <rmk0> i always forget if any other steps are needed to enable the debug context
20141109 19:53:58 <rmk0> don't... think there are any
20141109 19:56:13 <Eclesia> you think jcanephora could be improved ? at least to make it compatible with gl 4 even if raise only the gl3 errors, that would still be helpfull ?
20141109 19:56:41 <rmk0> doubt it, i intended to rewrite it for gl 4 when it became widespread
20141109 19:56:53 <rmk0> think you tend to do things quite differently on gl 4
20141109 19:57:11 <rmk0> the api enforces the one or two "right" ways to do things on gl 3... you'd not do them the same way on 4
20141109 19:57:22 <rmk0> what sort of bugs are you running into?
20141109 19:58:02 <Eclesia> seems like blending, depth test and matrices
20141109 19:58:14 <Eclesia> and artifacts on line drawing
20141109 19:58:21 <Eclesia> as if indexes where wrong
20141109 19:58:25 <Eclesia> were*
20141109 19:58:40 <rmk0> hrm
20141109 19:58:58 <rmk0> how do you ... get depth testing wrong?
20141109 19:59:57 <Eclesia> it pretty much looks like this bug : http://stackoverflow.com/questions/24990637/opengl-radeon-driver-seems-to-mess-with-depth-testing
20141109 20:01:11 <Eclesia> I don't have a radeon to make tests and debugging, so I focusing on being conform with OpenGL, hoping it will fix all issues
20141109 20:02:03 <rmk0> not sure if you read the responses to that
20141109 20:02:21 <rmk0> he screwed up specifying the stride parameter
20141109 20:02:43 <rmk0> this stuff is so incredibly error prone
20141109 20:04:03 <Eclesia> hmm
20141109 20:05:08 <rmk0> seriously... calling the opengl API directly is like playing that knife game where you spread your hand on a table and repeatedly ram the blade into the gaps between your fingers
20141109 20:05:30 <rmk0> the number of ways to fuck things up badly outnumber the correct ways by orders of magnitude
20141109 20:05:45 <Eclesia> might be that the probleme ... I always use 0
20141109 20:05:50 <Eclesia> :x
20141109 20:05:54 <rmk0> /o\
20141109 20:06:04 <Eclesia> well I have a //TODO comment :D
20141109 20:06:25 <Eclesia> never had issues so I considered it wasn't very important
20141109 20:06:44 <rmk0> it scares me that an nvidia implementation will magically do the "right" thing in that situation
20141109 20:06:49 <rmk0> is not helpful for anyone
20141109 20:07:31 <Eclesia> so... any advice ?
20141109 20:07:45 <rmk0> get the stride right!
20141109 20:08:15 <Eclesia> lol
20141109 20:10:12 <rmk0> i suppose you could look at jcanephora
20141109 20:10:21 <rmk0> not to use it, but you could rip code out of it
20141109 20:10:33 <rmk0> i'll dedicate whatever you need to the public domain
20141109 20:11:07 * Eclesia is currently searching for a good doc on how to calculate the stride correctly
20141109 20:11:36 <rmk0> http://mvn.io7m.com/io7m-jcanephora/documentation/p4s2.xhtml#st200_p4s2
20141109 20:11:37 <rmk0> might help
20141109 20:12:50 <rmk0> the "stride" is the total size in bytes of T
20141109 20:14:22 <Eclesia> if I'm correct : a 3D vertex in float 32bits, the stride would be : 3 * 4
20141109 20:14:49 <Eclesia> primitive type size in bytes * number of values in the tuple
20141109 20:14:50 <rmk0> if by vertex, you mean that it only contains the vertex position as three floats
20141109 20:15:10 <rmk0> like, er... struct vertex { vec3 position; };
20141109 20:15:14 <Eclesia> yes
20141109 20:15:20 <rmk0> yeah, will be twelve bytes
20141109 20:15:47 <Eclesia> ok, easy then ^^
20141109 20:16:08 <rmk0> the spec demands that ints are 32 bit signed, and floats are 32 bit IEEE 754 singles, these days
20141109 20:16:22 <rmk0> prior to 3.0, they were allowed to be anything /o\
20141109 20:22:07 <Eclesia> you think that could be source of all the problems on radeon cards ?
20141109 20:23:31 <rmk0> doubt it
20141109 20:24:05 <rmk0> you do really need to be sitting at one and testing with the debug context, i think
20141109 20:25:08 <rmk0> and ideally have minimal things you can test in isolation
20141109 20:25:36 <Eclesia> I have tests cases in my engine. but I don't have a radeon card ^^
20141109 20:26:03 <rmk0> i may be talking about somewhat more granular tests
20141109 20:26:48 <Eclesia> some are really simple, like render a line or a texture
20141109 20:27:10 <rmk0> http://fossil.io7m.com/repo.cgi/io7m-jcanephora/artifact/12cf40bb3717f12ec0edbc1b6a005392230d0870
20141109 20:27:59 <Eclesia> awfull formating :/
20141109 20:28:09 <rmk0> \o/
20141109 20:28:23 <rmk0> there is the other danger when using opengl
20141109 20:28:33 <rmk0> you can accidentally use extensions, because the api doesn't require you to say you're using them
20141109 20:28:52 <rmk0> you then use that code on another card that doesn't implement the extensions... splat!
20141109 20:29:16 <Eclesia> any way to say ? 'strict gl' , 'disable extensions' ?
20141109 20:29:20 <rmk0> nope
20141109 20:29:23 <Eclesia> haha
20141109 20:29:26 <rmk0> i wish there was
20141109 20:29:29 <rmk0> it's idiotic
20141109 20:30:13 <rmk0> i try to statically indicate that in jcanephora wherever possible
20141109 20:30:27 <rmk0> like, er...
20141109 20:31:11 <rmk0> http://fossil.io7m.com/repo.cgi/io7m-jcanephora/artifact/f3e863ac255b30783cdf6a2521a2e87967c1c777
20141109 20:31:52 <rmk0> you can only access texture allocation functions that work on the implementation you're currently on
20141109 20:32:00 <rmk0> are statically prevented from trying to allocate an unsupported format
20141109 20:32:08 <rmk0> if an extension provides new formats:
20141109 20:32:22 <rmk0> http://fossil.io7m.com/repo.cgi/io7m-jcanephora/artifact/b2c00d3449c7e815049635063e081e00b0ad6e21
20141109 20:32:56 <rmk0> you have to specifically ask the api for a value of type JCGLExtensionDepthTextureType
20141109 20:33:05 <rmk0> it won't give you one if the extension isn't supported
20141109 20:33:32 <rmk0> only the texture formats that the specification guarantees are available are exposed
20141109 20:33:54 <rmk0> think this sort of thing is essential to avoid accidents
20141109 20:34:58 <rmk0> it's a lot of work to put together... jcanephora took about 9 months and i still make adjustments now
20141109 20:35:43 <rmk0> i couldn't imagine working without it
20141109 20:36:00 <rmk0> for that camera stuff i was doing a couple of weeks back... i wrote some "raw" opengl for the first time in two years or so
20141109 20:36:07 <rmk0> took hours to get a fucking triangle onscreen
20141109 20:36:10 <rmk0> made every mistake possible
20141109 20:36:29 <Eclesia> lol
20141109 20:36:41 <Eclesia> the triangle boss ^^
20141109 20:36:57 * rmk0 stomps on it
20141109 20:37:14 <rmk0> the same code in jcanephora took about ten minutes and was correct first time... is "hard" to do the wrong thing
20141109 20:37:28 <Eclesia> I'm not even sure anymore that I'm rendering a single triangle right ^^
20141109 20:37:32 <rmk0> fuck opengl, seriously...
20141109 20:37:36 * rmk0 kicks opengl
20141109 20:38:08 <Eclesia> but that's all we have ...
20141109 20:38:12 <rmk0> urhur
20141109 20:39:41 <rmk0> it bothers me when i read stuff about bleeding edge opengl
20141109 20:39:52 <rmk0> where they basically say "here, you need to do this drastically unsafe stuff for good performance"
20141109 20:40:04 <rmk0> like they're actively working to make the api even more dangerous
20141109 20:40:22 <rmk0> no thought is given towards correctness because performance concerns come above all else
20141109 20:40:43 <rmk0> doesn't matter if it's fast if it takes two years to get anything into a working state
20141109 20:40:57 <rmk0> and then goes wrong as soon as you try it on another card...
20141109 20:41:52 <Eclesia> hehe, they insert bugs, makes it hard, this way OpenGL will continue to 'evolve' and they will always have maintenant/compatibility payed work ;)
20141109 20:42:25 <Eclesia> maintenance*
20141109 20:42:35 <rmk0> (._.)
20141109 20:43:40 <Eclesia> sell a knife today and you will sell a bandage tomorrow ^^
20141109 20:44:21 <Eclesia> not sure this expression exist in english
20141109 20:44:28 <rmk0> i understood it
20141109 20:46:49 <Eclesia> rmk0: does that looks ok ? http://pastebin.com/VhPnUhAn
20141109 20:47:28 <rmk0> think so, but... use an enum!
20141109 20:47:44 <Eclesia> for the type ?
20141109 20:47:49 <rmk0> urhur
20141109 20:48:03 <Eclesia> nope, enum are not allowed in my library :p
20141109 20:48:09 <rmk0> ?
20141109 20:48:25 <rmk0> you targeting obsolete jvms?
20141109 20:49:13 <Eclesia> I have too, because I will have to make my own VM and parser. so enum, annotations, generic, lambdas are not allowed. plain old fashion objects
20141109 20:49:40 <rmk0> (._.)
20141109 20:50:21 <Eclesia> and people from other language can read it more easily too
20141109 20:50:51 <rmk0> don't think i could work without generics
20141109 20:52:40 <Eclesia> I agree, same for functions/lambda. but after all, It doesn't make a big difference. just syntaxic sugar
20141109 20:52:57 <rmk0> i'd hardly call generics syntactic sugar
20141109 20:53:08 <rmk0> parametric polymorphism...
20141109 20:53:18 <rmk0> utterly critical for safety
20141109 20:53:30 <rmk0> i'd agree lambdas are
20141109 20:53:37 <rmk0> they... literally are, in the case of java
20141109 20:53:46 <rmk0> given that it's already possible to instantiate anonymous class instances
20141109 20:54:24 <rmk0> most of the techniques i use to make programming in java "safe" require generics
20141109 20:54:38 <Eclesia> they disappear at compilation, so they don't enforce anything. you can simply cast List<String> in List and put whatever you want in it.
20141109 20:55:00 <rmk0> you can subvert it deliberately, yeah
20141109 20:55:16 <rmk0> but if you're going to be subverting deliberately, there are any number of better ways
20141109 20:55:24 <rmk0> i could pour orange juice into the computer, for example
20141109 20:55:38 <rmk0> that's not a reason not to use it
20141109 20:56:10 <rmk0> the point is to protect myself from my own mistakes
20141109 20:57:39 <Eclesia> 100% right, 0 objections to this logic :) it's just for my project. I need to, otherwise parsing will be a pain to implement.
20141109 20:57:54 <rmk0> can appreciate that...
20141109 20:58:41 <rmk0> how long is a public domain jvm going to take?
20141109 20:59:38 <Eclesia> it won't be a jvm since none of the jre api will be in it.
20141109 21:00:00 <rmk0> hm
20141109 21:01:06 <Eclesia> maybe there will be something working in one year.
20141109 21:01:07 <rmk0> no reflection at least, so that's a plus
20141109 21:02:27 <Eclesia> regex,lexer,parser,ast work even if they are not perfet yet. so/dll readers are just draft so far. the virtual stackvm is just a draft too.
20141109 21:03:02 <rmk0> i assume no llvm allowed
20141109 21:03:06 <Eclesia> well plenty of work remaining ^^
20141109 21:03:20 <Eclesia> nope, unless you make them use public domain
20141109 21:03:34 <Eclesia> rmk0: good luck :D
20141109 21:04:09 <rmk0> writing a native code emitter doesn't strike me as fun
20141109 21:04:56 <Eclesia> maybe we could have something sooner by using jamvm, if xranby is interested that could be a solution.
20141109 21:05:50 <rmk0> is that public domain?
20141109 21:06:54 <Eclesia> nope, but it's a small jvm kernel which can work with openjdk or icedtea, so maybe it could be adapted to use unlicense-lib as main core lib.
20141109 21:08:11 <Eclesia> xranby works on it, you can ask him for details
20141109 21:12:07 <Eclesia> http://nekovm.org is also a fun vm
20141109 21:12:42 <Eclesia> but binding it seems more difficult
20141109 21:12:53 <rmk0> lacks types
20141109 21:13:07 <Eclesia> ho you know nekovm ?
20141109 21:13:15 <rmk0> i... just read it on that page
20141109 21:13:18 <Eclesia> lol
20141109 21:16:04 <Eclesia> I tryed quite a few things before starting Unlicense-lib. I was frustrated by oracle actions, so I explored other solutions, D, Ruby, Python, scala, C#(with mono), eiffel, parrotvm, ... that was several month of traveling the web ^^
20141109 21:17:01 <rmk0> there's lot a great deal out there
20141109 21:17:16 <rmk0> *not
20141109 21:19:23 <Eclesia> the most promising solutions I found : Ruby and D. nice comunity, ruby in particular are very friendly with public domain. NekoVM is in a design a promising vm. and HelenOS maybe the futur Linux killer ^^ with a concept of 'fibril', someking of shared memory threads
20141109 21:19:46 <rmk0> ruby's utter shit
20141109 21:20:04 <Eclesia> well I like it ^^, at least more the python
20141109 21:20:07 <rmk0> no idea about D, but as it's intended to be a "slightly better c++", i'm not entirely filled with confidence
20141109 21:20:12 <rmk0> python's utter shit
20141109 21:20:38 <Eclesia> they are script languages, so they are 'shit' by definition
20141109 21:20:55 <rmk0> it's more than that... they're just a collection of fundamental "design" errors
20141109 21:21:09 <rmk0> made by people who know nothing about programming language research, type systems, compiler construction...
20141109 21:21:30 <Eclesia> we could say the same about matlab
20141109 21:21:45 <rmk0> probably... never seen it
20141109 21:22:02 <Eclesia> it's a different perspective, different objectives
20141109 21:23:36 <rmk0> the perspective must be "let's make a language with really fucked up semantics, no type system, no abstraction, no privacy, no immutability, and no thought to tool support"
20141109 21:24:08 <rmk0> that applies equally to ruby and python... that whole "dynamically typed OO scripting language" mess, really
20141109 21:24:52 <rmk0> seriously, we're talking about languages where the scoping rules change every release and have never been formally documented or specified
20141109 21:25:00 <rmk0> that stuff has serious every-day consequences
20141109 21:25:11 <rmk0> it's not suitable for any kind of programming work, period
20141109 21:25:28 <rmk0> i consider it grossly negligent to use it at all
20141109 21:25:42 <Eclesia> still, some of them are widely used, javascript, python ...
20141109 21:25:57 <rmk0> loads of people smoke heavily
20141109 21:26:02 <rmk0> doesn't make it any less stupid
20141109 21:26:24 <rmk0> programmers are generally pretty dogmatic and not able to critically analyze, ironically
20141109 21:26:31 <rmk0> you'd think the work would require it
20141109 21:27:26 <rmk0> most are not equipped to actually make any kind of critical evaluation of programming languages, so they just listen to what some meatbag on a python forum says
20141109 21:27:34 <rmk0> "you should use python, it's really pythonic"
20141109 21:27:45 <rmk0> i'm told binary trees aren't python
20141109 21:27:49 <rmk0> hash tables are pythonic
20141109 21:28:07 <rmk0> if i have security concerns about hash collisions, i shouldn't. it's not pythonic.
20141109 21:28:19 <rmk0> etc
20141109 21:29:31 <Eclesia> I think we can make 2 groups of coders. 1 - quick typing, write once, read never again == scripts : javascript/html, python, ruby, ... 2 - backend types : typesafe, static type, exception support, parameters constraints : eiffel, java, C#, D
20141109 21:29:56 <rmk0> probably
20141109 21:30:13 <rmk0> amusingly, those languages aren't even particularly good at "write quickly"
20141109 21:30:23 <rmk0> they're "spend ten minutes writing, spend two hours debugging"
20141109 21:30:42 <rmk0> modern type systems don't require all the verbosity, and catch errors early
20141109 21:30:50 <Eclesia> hehe, but they try to look like they are easy
20141109 21:30:54 <Eclesia> buzz effect
20141109 21:30:55 <rmk0> yeah
20141109 21:31:05 <rmk0> "you don't have to write a load of types"
20141109 21:31:22 <Eclesia> javascript should have died long ago, yet it's 'bleeding edge' web technology
20141109 21:31:47 <rmk0> the web is dead to me... the whole stack is fucked as far as i'm concerned
20141109 21:31:56 <Eclesia> agree on that
20141109 21:32:02 <rmk0> i'll publish as static xhtml strict 1.0 pages, and try to avoid the rest like the plague
20141109 21:33:00 <rmk0> not that xhtml is that great... is just that i can validate it without specialized tools
20141109 21:33:08 <Eclesia> the only web I do are the few html pages of my project web site (plain html) and Java web start. thats all
20141109 21:34:43 <rmk0> if i was going to do server side stuff on the web, i think it'd definitely be java
20141109 21:34:52 <rmk0> i can't actually run long-running processes on the hosting i use, unfortunately
20141109 21:35:22 <rmk0> i think doing things on the server side started dying out because people thought it was "too slow" to fork a whole new php interpreter for each request
20141109 21:35:31 <rmk0> so they started pushing everything into javascript on the client side
20141109 21:36:08 <rmk0> so... i wonder if you removed that cost of request handling by doing it in a long running java process... could you eliminate the "need" for javascript entirely
20141109 21:36:30 <rmk0> i try not to think about it
20141109 21:39:21 <Eclesia> we run a lot of servers at work (cartography). we don't use server session anymore. just services, one request with all parameters, one answer. that's it. nothing stored on the server.
20141109 21:39:30 <Eclesia> stateless
20141109 21:40:05 <Eclesia> we deploy a lot using JWS, so we have 'heavy' clients
20141109 21:40:41 <rmk0> right
20141109 21:40:49 <Eclesia> javascript is just slow and impossible to maintain when you start doing complication stuffs
20141109 21:41:08 <Eclesia> not even talking about browser compatibility ...
20141109 21:41:08 <bruce-> …
20141109 21:41:21 <rmk0> … … …
20141109 21:42:49 <Eclesia> final word : web sucks ! no objections ?
20141109 21:45:31 <rmk0> .. still sort of interested to see where ceylon is going
20141109 21:45:46 <rmk0> interesting type system
20141109 21:46:17 <rmk0> it's a bit one-way though... you can call java code from ceylon, but there's no way to publish ceylon packages on maven or anything like that
20141109 21:46:45 <rmk0> so you can call ceylon from java, but i don't see a way to actually use any of the existing package infrastructure to get ceylon code packaged up in a way that plays nicely with java
20141109 21:47:22 <rmk0> they have some valid criticisms of the way maven does things... really any of the systems that use maven packages, really
20141109 21:47:38 <rmk0> so i'm not sure they'll ever work on integrating it... is counter to what they want to do
20141109 21:47:41 <Eclesia> I don't like the syntax, scala like. to much {{}} ()() makes it unreadable
20141109 21:49:01 <rmk0> scala syntax is... demented
20141109 21:49:07 <rmk0> i mean, really really complicated
20141109 21:49:39 <rmk0> someone gave me a good example the other day... locating
20141109 21:50:19 * rmk0 displays hourglass
20141109 21:51:22 <rmk0> can't find it
20141109 21:51:38 <rmk0> i think it was something about how the syntax interacts with their system of "implicits"
20141109 21:51:50 <rmk0> in scala, you can omit () for functions that don't take parameters
20141109 21:51:56 <rmk0> so x.getY == x.getY()
20141109 21:52:03 <rmk0> only... sometimes they aren't the same
20141109 21:52:10 <rmk0> you'll get a bizarre type error when it happens
20141109 21:52:26 <rmk0> all of the language features react really badly, you can never tell what a given piece of code is going to do
20141109 21:52:47 <rmk0> don't think ceylon is like that, is vastly simpler in syntax and semantics
20141109 21:52:54 <rmk0> they do look similar at first glance, though
20141109 21:53:13 <rmk0> they have some generic syntax for instantiating tree-like types splashed all over the front page
20141109 21:53:43 <rmk0> is amusing... they integrated xml parsing and construction into scala, and then it turned out that the standard library xml stuff was completely unusable
20141109 21:53:50 <bruce-> is the Ceylon compiler at least faster than Scala's? I could not believe how slow the Scala 0.10 compiler was
20141109 21:53:50 <rmk0> and... now they can't remove it, because it's part of the language
20141109 21:54:09 <rmk0> the pre-1.0 compiler i tried was definitely faster
20141109 21:54:18 <rmk0> scala compilation is brutally slow
20141109 21:55:12 <rmk0> the ceylon type system is nowhere near as complex, and they don't have to do resolution of implicits, so it's pretty much guaranteed to be faster unless they make a total mess of it
20141109 21:55:32 <rmk0> i've interrogated the authors at length, i trust them not to make a mess!
20141109 21:58:02 <Eclesia> rmk0: was he wearing a neck tie ?
20141109 21:58:17 <rmk0> i couldn't see
20141109 21:58:58 <Eclesia> Rule number 1 : neck tie == never trust
20141109 21:59:06 <rmk0> hehe
20141109 22:00:51 <Eclesia> fix the stride value, we will see if it's better ..
20141109 22:01:06 <rmk0> enable the debug context
20141109 22:01:13 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141109 22:01:46 <Eclesia> it's in the mail. have to wait for feedback now.
20141109 22:06:32 <Eclesia> week end already finished ... it too short !
20141109 22:06:49 <Eclesia> it's*
20141109 22:13:24 <Eclesia> good night everyone ++ thanks again for your help rmk0
20141109 22:13:37 <rmk0> byeeee!
20141109 22:13:45 <rmk0> you realize this means i have to go back to writing documentation
20141109 22:14:04 <rmk0> i've managed to avoid it so far by droning on in here for hours
20141109 22:14:35 <Eclesia> ^^ I managed to make a bit of code while talking
20141109 22:14:44 <Eclesia> you should have done the same :p
20141109 22:14:50 <rmk0> hehe
20141109 22:15:39 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20141110 03:49:37 * kermyt (~kermyt@anon) Quit (Ping timeout: 255 seconds)
20141110 03:55:26 * kermyt (~kermyt@anon) has joined #jogamp
20141110 04:04:29 * kermyt (~kermyt@anon) Quit (Ping timeout: 250 seconds)
20141110 04:14:58 * kermyt (~kermyt@anon) has joined #jogamp
20141110 04:15:02 * kermyt (~kermyt@anon) Quit (Changing host)
20141110 04:15:02 * kermyt (~kermyt@anon) has joined #jogamp
20141110 04:25:59 * kermyt (~kermyt@anon) Quit (Read error: Connection reset by peer)
20141110 05:06:27 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20141110050627.html