| dholbach | good morning | 05:35 |
|---|---|---|
| slytherin | persia: FYI ... default-jdk in Debian still points to java-gcj-compat-dev and jftp fails to build with GCJ. :-( | 08:19 |
| persia | :( | 08:19 |
| persia | I'm guessing that is exceedingly unlikely to change in the next month, assuming the sarge release is still targeted for 15th September. | 08:20 |
| slytherin | so should I tell submit the patch and tell them to specifically use openjdk to build? | 08:26 |
| slytherin | I thought doko usually keeps tool chain in sync in both teh distros | 08:26 |
| persia | He does, but Debian is fairly hard frozen in the run up to the lenny release: http://asdfasdf.ethz.ch/~tar/bts/ | 08:28 |
| persia | 31 days to go, with 134881 open bugs | 08:28 |
| persia | http://bugs.debian.org/release-critical/ is also interesting: only 1557 RC bugs, with 322 patches to review / process. | 08:29 |
| persia | (still something like 50 bugs a day that need to get closed, so big changes are unlikely) | 08:30 |
| slytherin | hmm | 08:31 |
| persia | So, we may have to diverge some stuff, and can feed the patches back to Debian in late September. | 08:32 |
| slytherin | persia: any chance, we can have today's java meeting an hour earlier? | 12:45 |
| persia | slytherin: Not with that much notice :) | 12:45 |
| persia | That said, if you can't make it, and want to send a short summary of your status to the list, that works too. | 12:45 |
| slytherin | persia: hmm. then I will miss the later half of meeting. | 12:46 |
| persia | OK. We'll do you first in Roadmap. Did you have any other items on the agenda? | 12:46 |
| slytherin | persia: I just added two. | 12:47 |
| persia | slytherin: Hmm. Well, we'll hope there is time then :) | 12:48 |
| slytherin | ok | 12:48 |
| slytherin | persia: free to sponsor a small fix? | 14:16 |
| persia | slytherin: No. I'm about 4 deep in my stack, and trying to eat before the Java meeting. I've reserved some time to pound the sponsors queue soon, so putting it there will likely be best (and someone else might get to it first). | 14:18 |
| slytherin | persia: Ok. It is already in sponsors queue. | 14:21 |
| robilad | meeting is in 90 mins? | 14:26 |
| robilad | or 150? | 14:27 |
| robilad | looks more like 30 ;) | 14:30 |
| persia | 20 now :) | 14:40 |
| Juli__ | persia: hi, have you had a chance to take a look on netbeans6.1 packages? | 14:43 |
| persia | Juli__: Not as much as I'd like, unfortunately. Work has been too busy. I've a holiday tomorrow, and ought be able to look at them. | 14:45 |
| * persia wants a physical duplicator with support for biological structures | 14:46 | |
| Juli__ | oh, I really appreciate that | 14:46 |
| slytherin | Juli__: WHy are netbeans packages on REVU? Shouldn't the .diff.gz be attached to a bug? | 14:48 |
| Juli__ | there are some new packages | 14:48 |
| slytherin | Juli__: I don't udnerstand | 14:49 |
| Juli__ | some packages are updated from 6.0.1 to 6.1, but there are new libs required | 14:49 |
| Juli__ | jna for example | 14:49 |
| Juli__ | and we decided to change platform source package name, so it is the new source package now | 14:50 |
| persia | My memory from the last time I looked was that there was some stuff on REVU, and some as diff.gz in bugs. | 14:50 |
| Juli__ | on REVU there are only platform, resolver and jna packages | 14:51 |
| persia | slytherin: If you have time to look through them, that'd be a great help, as you've a fair degree of experience with how things ought be packaged. | 14:51 |
| Juli__ | netbeans and other updated libs are in bugs | 14:51 |
| persia | Juli__: My memory is faulty: were the differences between xml-commons-resolver and libnb-resolver ever tracked down? | 14:52 |
| slytherin | persia: I will try but I am not sure what is complexity. But everything will be on hold till Monday | 14:52 |
| persia | slytherin: Heh. You're off tomorrow too, but that means you're unable to review, as opposed to me ? | 14:53 |
| Juli__ | the difference is in the patch only, but I haven't got in touch with somebody about that | 14:53 |
| persia | RIght, it's something that needs doing soon, as duplication of code is often grounds for rejection (causes hassles with security support, etc.) | 14:54 |
| persia | Meeting in 5 minutes in #ubuntu-meeting | 14:55 |
| slytherin | persia: I will not be able to do review on weekend. Won't have access to my machine over weekend. | 14:55 |
| persia | slytherin: Understood. | 14:55 |
| Juli__ | xml-commons-resolver is under java-pkg team now, Michael Koch is active with this package for last year | 14:55 |
| robilad | that's man-di | 14:56 |
| Juli__ | http://java.debian.net/ | 14:56 |
| persia | Team meeting in #ubuntu-meeting starting now | 15:00 |
| robilad | persia: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-7392&yr=2008&track=javaee | 15:53 |
| robilad | for an introduction into major performance improvements over the past year | 15:54 |
| robilad | basically, a very good dynamic compiler, i.e. hotspot, can afford to defer optimization decisions until runtime | 15:54 |
| robilad | and then optimize for the actual system it's running on | 15:54 |
| robilad | for example (hotspot does that now) reorder fields in a class so that the number of cache lines used for accessing frequantly used fields is minimized | 15:55 |
| robilad | or optimisitically inline code depending on 'hot paths' | 15:55 |
| robilad | and deinline it again once lightweight profiling shows that would be better | 15:56 |
| persia | Ah, whereas for native compilation, if one did that one would have to target specific processors, rather than relatively broad ISAs | 15:56 |
| robilad | (how much you can usefully inline depends on the cache of the system you're running on, obviously, and that's a hard choice you have to make in a native compiler) | 15:57 |
| robilad | yep | 15:57 |
| persia | OK. Then for most processors, I'll agree with you. For lpia, I think the number of variants are still small enough that native could be better, but even that probably won't last the lifetime of intrepid. | 15:57 |
| persia | Thanks for the explanantion. | 15:57 |
| robilad | so basically, hotspot has a ton of optimizations specifically for specific processors from intel, amd etc. developed together with their compiler engineers to try to optimize for that case. | 15:58 |
| robilad | see PDF above for explanation of some of them | 15:58 |
| robilad | and there is a lot of general optimizations that become possible at runtime | 15:58 |
| persia | intel, amd, via, and sun? Any chance of IBM processors being supported soon? | 15:58 |
| robilad | no idea | 15:58 |
| robilad | for example, you can at runtime figure out that a certain excaption is never being thrown | 15:59 |
| persia | Oh well. Ubuntu doesn't actually support s/390, but PPC still has a following. | 15:59 |
| robilad | and get rid of the code handling it, etc. | 15:59 |
| persia | Right. | 15:59 |
| robilad | it's a pretty mighty tool ;) | 15:59 |
| persia | Indeed. | 15:59 |
| robilad | and it's going to get a whole lot mightier with the da vinci vm | 15:59 |
| robilad | that#s a project to expose some of those optimization opportunities to dynamic language implementors | 16:00 |
| robilad | (jruby, jython, etc.) | 16:00 |
| robilad | so that they can rely on hotspot to optimize their method dispatch, etc. a lot more efficiently than a classic runtime for those languages would do. | 16:01 |
| robilad | so if you have jruby now matching performance of c ruby despite a lot of hacks to work around the lack of a hotspot api for dynamic languages, | 16:02 |
| robilad | picture the thing two years from now with a lot less code necessary, and the performance improvements outlined in the pdf above | 16:03 |
| robilad | and then the open source jvm becomes a very mighty tool in general. | 16:03 |
| persia | That will be powerful indeed. Whlie Ruby in Ubuntu is still not so common, there's a lot of python. | 16:04 |
| robilad | yep | 16:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!