--- Log opened Tue Jun 02 00:00:51 2009
00:20 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit ["Leaving"]
03:25 -!- Netsplit over, joins: ahuillet
03:25 -!- Netsplit holmes.freenode.net <-> irc.freenode.net quits: vegard
03:26 -!- Netsplit over, joins: vegard
08:18 <@penberg> vegard: Yes, we should be compatible with standard Java command line options
08:18 <@penberg> vegard: I see you added libzip support. Nice!
08:18 <@penberg> vegard: What happened with the test merge?-)
08:35 <@penberg> ahuillet: did you say you had an eeepc?
09:14 -!- mode/#jato [+o ahuillet] by ChanServ
09:14 <@ahuillet> penberg : yes I said that
09:17 <@penberg> ahuillet: what distro are you running on that?
09:17 <@penberg> ahuillet: I tried Ubuntu 9.04 netbook remix
09:17 <@penberg> ahuillet: and it seems that the kernel is busted ;)
09:17 <@ahuillet> I have been running the shipped xandros distro for about nine months
09:17 <@ahuillet> and I recently wiped it out in favor of arch linux
09:17 <@penberg> ahuillet: http://www.laughingpanda.org/~penberg/eeepc-701.dmesg
09:17 <@penberg> ahuillet: i915 doesn't initialize properly.
09:18 <@penberg> ahuillet: aah, arch linux, interesting.
09:18 <@penberg> ahuillet: I found a patch that's supposed to fix things
09:18 <@penberg> but it's not in any kernel I am aware of
09:18 <@ahuillet> I get the same message with 2.6.29.4, no big deal apparently since the thing does work
09:18 <@penberg> ahuillet: but apparently it doesn't!
09:18 <@ahuillet> ah ?
09:18 <@penberg> the ubuntu netbook launcher is dead slow
09:18 <@penberg> ahuillet:
09:18 <@penberg> ahuillet: http://lists.freedesktop.org/archives/intel-gfx/2009-January/001186.html
09:18 <@ahuillet> arch starts in ~15sec
09:19 <@penberg> ahuillet: it's special app launcher, not a boot time thing
09:19 <@ahuillet> interesting patch, thanks - I'm not sure why it doesn't work out of the box
09:20 <@penberg> ahuillet: ok, just wanted to check if you had it working or not
09:20 <@ahuillet> 3D doesn't really work yet on my eeePC with this distro anyway, I think the Mesa version is a bit too recent
09:20 <@penberg> I pinged the patch author Jesse Barnes
09:20 <@ahuillet> penberg : I can run glxgears
09:21 <@ahuillet> FreedroidRPG sees a SIGFPE inside the GL driver code
09:21 <@penberg> ahuillet: yeah but I don't think the lack of tiling slows that down?
09:21 <@ahuillet> which is pretty much non standard behavior for a driver
09:21 <@ahuillet> glxgears isn't a real test, yes... lack of tiling probably does slow things down
09:21 <@ahuillet> lemme check my dmesg
09:23 <@ahuillet> http://paste.pocoo.org/show/120523/
09:23 <@ahuillet> same here
09:23 <@ahuillet> [    1.198764] [drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't read from MCHBAR.  Disabling tiling.
09:24 <@penberg> ahuillet: yup, same problem.
09:24 <@penberg> I wonder why it's not fixed.
09:25 <@ahuillet> because intel doesn't care about old hardware
09:25 <@ahuillet> *at least* this is true
09:26 <@ahuillet> have you tried KMS?
09:27 <@penberg> kernel mode setting?
09:27 <@penberg> no I haven't.
09:28 <@ahuillet> maybe it can help a bit, given that intel concentrates on KMS + UXA + GEM setup
09:28 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
09:28 <@penberg> ahuillet: aa
09:28 <@penberg> tgrabiec: No, I don't think we need to have compatible exception messages unless there's some conformance tests that require it.
09:29 <@penberg> tgrabiec: I would not worry about it for now.
09:29 < tgrabiec> penberg, ok
10:02 < vegard> penberg: the test merge, I have to make it compile first o.O
10:03 <@penberg> :)
10:14 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Read error: 110 (Connection timed out)]
10:17 < vegard> we need to merge as soon as possible.
10:23 <@penberg> vegard: :)
10:32 < vegard> or maybe I can just merge from mainline
10:32 < vegard> what do you think?
10:33 < vegard> I had originally planned not to. because it makes the history nice and rebasable.
10:33 <@ahuillet> penberg : have you changed the build system regarding unit tests?
10:33 <@ahuillet> it's difficult to run them inside gdb
10:34 < vegard> agree :)
10:34 < vegard> what I did was put "valgrind ./runner || true" inside scripts/build/test.mk
10:34 <@ahuillet> yeah, same with gdb --args :)
10:42 <@ahuillet> penberg : ping
10:42 <@ahuillet> sizeof(converters)/sizeof(converters[0]) = 200, opcode 239, converter 0x203d2120
10:42 <@ahuillet> opcode 239 is OPC_INSTANCEOF_QUICK
10:43 <@ahuillet> and it has no converter
10:43 <@ahuillet> hence the segfault
10:43 <@ahuillet>         convert = converters[ctx.opc];
10:43 <@ahuillet>         if (!convert) {
10:43 <@ahuillet> and this test isn't sufficient to detect this this
10:45 < vegard> <penberg> shoe me teh patch!!!
10:46 <@penberg> ahuillet: pong
10:46 <@penberg> ahuillet: no I have not changed them, what's wrong?
10:46 <@penberg> vegard: I think you ought to merge master to your branch and resolve conflicts
10:47 <@penberg> vegard: not _rebase_, but _merge_
10:47 <@penberg> ahuillet: OPC_INSTANCEOF_QUICK is not proper opcode.
10:47 <@penberg> ahuillet: it's some jamvm optimization
10:47 <@penberg> ahuillet: we don't convert it and nor should we.
10:48 < vegard> um. that's wrong?
10:49 <@penberg> vegard: what's wrong?
10:49 <@ahuillet> penberg : ok, so why do I get it there ?
10:49 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
10:49 <@ahuillet> penberg : because it seems to be the cause of the crash I am getting
10:49 < vegard> it's defined only in first edition
10:50 <@penberg> vegard: it's a real opcode?
10:50 <@ahuillet> anyway my problem is why do I get it in topic/ostack and not in master
10:50 < vegard> yes, defined only in jvm spec, first ed.
10:50 < vegard> http://www.j2ee.me/docs/books/jvms/first_edition/html/Mnemonics.doc.html
10:51 <@penberg> hmm
10:51 <@penberg> vegard: I don't still agree.
10:52 <@penberg> I doubt ECJ generates those bytecodes.
10:52 <@penberg> ahuillet: what test are you running?
10:52 <@ahuillet> jit-test-runner, not sure which exactly
10:53 < vegard> http://www.j2ee.me/docs/books/jvms/first_edition/html/Quick2.doc.html
10:53 < vegard> there, maybe that helps more :)
11:39 <@penberg> ahuillet: I don't think those should use OPC_INSTANCEOF_QUICK, really.
11:46 <@ahuillet> penberg : so it's some kind of corruption?
11:47 <@penberg> ahuillet: likely, yes.
11:48 <@ahuillet> ok
11:57 <@ahuillet> actually it's certain because it would happen in master as well
11:57 <@penberg> yup.
11:57 <@ahuillet> too bad valgrind doesn't catch errors with static arrays
11:57 <@ahuillet> I hear that exp-ptrcheck does (their new tool)
11:57 <@ahuillet> but it's 1-slow 2-not working
12:18 < tgrabiec> penberg:  "[PATCH 1/2] vm: Allocation and operations on guard pages", should be "[PATCH 1/6] ..." of course, sorry
12:18 <@penberg> yeah
12:18 <@penberg> tgrabiec: I was about to ask about that ;)
12:19 <@penberg> tgrabiec: +void *alloc_page();
12:19 <@penberg> tgrabiec: your classic mistake ;)
12:19 < tgrabiec> damn
12:19 <@ahuillet> memcheck doesn't see anything but the said convert crash
12:19 <@penberg> tgrabiec: sysconf(_SC_PAGESIZE) in hide_guard_page()
12:20 <@penberg> but getpagesize() in alloc_page()
12:20 <@penberg> tgrabiec: don't worry, I'll fix that up.
12:20 < tgrabiec> which is better ?
12:21 <@ahuillet> http://paste.pocoo.org/show/LQiIlg0QaW4a86gGirRG/
12:21 <@penberg> tgrabiec: __emit_memdisp_reg
12:21 <@ahuillet> penberg : would you consider this?
12:21 <@penberg> tgrabiec: I don't see a segment register used there
12:21 < tgrabiec> penberg: should it be ? why ?
12:22 <@penberg> ahuillet: yes, if you do that _before_ you reference invalid memory region ;)
12:22 <@penberg> tgrabiec: it's used to load the guard page pointer, no?
12:22 <@ahuillet> penberg : yes sir :)
12:22 <@penberg> tgrabiec: select_exception_test(), we need this only for native function calls, no?
12:23 < tgrabiec> penberg: well, yes, but the pointer to guard page is relative to ds: (as returned by &exception_guard)
12:23 <@penberg> tgrabiec: (and that's what you seem to be doing)
12:23 <@penberg> tgrabiec: aha ok
12:23 <@penberg> tgrabiec: so where is the test part of the code then
12:23 < tgrabiec> penberg: the test part? it's in select_exception_test()
12:24 <@penberg> I am confused now.
12:24 <@penberg> select_exception_test() test a global page?
12:24 <@penberg> how is that going to work with multiple threads?
12:25 <@penberg> tgrabiec: I think we should just do a global page_size variable
12:25 <@penberg> tgrabiec: and initialize that at run-time
12:25 <@penberg> or hmm
12:25 <@penberg> tgrabiec: or use getpagesize() everywhere.
12:25 <@ahuillet> http://paste.pocoo.org/show/PXmYAbNmhNf13iVvxk9i/
12:25 < tgrabiec> penberg: it tests a page, but it's a per thread page. the memory addres of exception_guard is the same but it has different contents in different threads
12:26 <@penberg> ahuillet: we have ARRAY_SIZE ;)
12:26 <@penberg> tgrabiec: yes, I do realize that. but how is that reflected in the generated test instruction!
12:26 <@ahuillet> nice :)
12:27 <@penberg> Last time I checked, gcc used the "gs" segment register for the load
12:27 <@penberg> gs or some other segment register, I forgot which.
12:29 < tgrabiec> penberg: well, AFAIK gs segment points to some thread-specific area. but when you want to get the address of thread specific variable, it returns the address in ds segment, but it's still thread-specific. Address is the same for all threads (some manual told me that) but the pages are mapped to different phisical pages for each thread
12:29 <@ahuillet> http://paste.pocoo.org/show/2Qo2jU5VcQRhMATY3wI6/ <- that to your mailbox ?
12:29 <@ahuillet> it fixes jit-test-runner here :]
12:29 <@ahuillet> I know it's kind of dodgy, still it makes the crash disappear, so what do I do?
12:29 <@penberg> ahuillet: yes, please.
12:30 <@penberg> tgrabiec: did you check what kind of code GCC generates when you access __thread variables?
12:30 < tgrabiec> penberg: yes
12:30 <@penberg> tgrabiec: and it explicitly uses "gs", no?
12:30 <@penberg> tgrabiec: if what you say is true, I'd like to see a reference to it.
12:31 < tgrabiec> penberg: ok, wait a moment :)
12:34 <@penberg> ahuillet: no sign off
12:35 <@ahuillet> grrrrr
12:35 <@ahuillet> sorry
12:35 <@penberg> ahuillet: I'll add that.
12:35 <@ahuillet> thx :)
12:35 < tgrabiec> penberg: this: http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html says that:
12:35 < tgrabiec> "When the address-of operator is applied to a thread-local variable, it is evaluated at run-time and returns the address of the current thread's instance of that variable. An address so obtained may be used by any thread. When a thread terminates, any pointers to thread-local variables in that thread become invalid. "
12:35 <@penberg> ahuillet: I assume your patch is on top of your ostack branch?-)
12:36 <@ahuillet> oh, it doesn't apply ? :)
12:36 <@ahuillet> I sucked on this one sorry
12:36 <@ahuillet> yes it was on top of ostack
12:37 < tgrabiec> penberg: hmm, ok, now when i read it, it seems that you are right :)
12:37 <@penberg> tgrabiec: yes, it doesn't mention anything about mapping to different physical pages.
12:37 <@penberg> ahuillet: well
12:37 <@penberg> ahuillet: I think you should keep the patch as-is
12:38 <@penberg> ahuillet: and keep it in your tree, no?
12:38 <@penberg> no point in backporting this
12:38 <@penberg> then fixing conflicts in your branch
12:38 <@penberg> ahuillet: right?
12:38 <@ahuillet> as you like
12:38 <@penberg> ahuillet: really depends on what you want to do ;)
12:38 <@ahuillet> it fixes a bug, but it's true we did not encounter it in master, so...
12:38 <@ahuillet> penberg : I want to understand why the hell this makes jit-test-runner not complain and not crash any longer
12:38 <@penberg> ahuillet: do a breakpoint there and see what triggers it?
12:39 <@ahuillet> opc.ctx = 239...
12:39 <@ahuillet> err
12:39 <@ahuillet> ctx.opc
12:40 <@penberg> ahuillet: yeah but see the _backtrace_
12:53 <@ahuillet> #4  0x08050edc in test_convert_goto () at branch-bc-test.c:171
12:54 <@ahuillet> clearly a problem we have :)
12:56 <@penberg> ahuillet: we probably jump to a bogus basic block
12:56 <@penberg> and attempt to parse that
12:56 <@penberg> probably cfg is corrupted or something.
13:03 <@ahuillet> the basic block address is fine
13:03 <@ahuillet> http://paste.pocoo.org/show/120543/
13:13 < tgrabiec> penberg: are you ok with adding separate instruction for segment prefixes, like INSN_SEG_PREFIX ?
13:14 <@penberg> tgrabiec: so it's just a seg prefix, not an instruction?
13:15 < tgrabiec> penberg: yes, it's a hack - so i expect you to say no
13:16 < tgrabiec> perhaps it's better to create something like seg_membase_reg_insn() ?
13:17 <@ahuillet> penberg : still here?
13:18 <@ahuillet> penberg : in test_convert_goto, you create a basic block "target_bb"
13:18 <@ahuillet> this block is empty (it has no code)
13:20 <@ahuillet> however, the conversion code tries to convert code in this block
13:21 <@ahuillet>     target_bb = alloc_basic_block(cu, TARGET_OFFSET, TARGET_OFFSET + 1);
13:22 <@ahuillet> so you put no code in this block
13:22 <@ahuillet> but you tell the conversion code to read one instruction nevertheless
13:22 <@ahuillet> am I wrong here?
13:29 <@penberg> tgrabiec: I don't have huge issues aganst INSN_SEG_PREFIX actually
13:29 <@penberg> ahuillet: not sure
13:30 <@penberg> ahuillet: I think 'end' is exclusive
13:30 <@penberg> ahuillet: so that should be an empty block
13:30 <@penberg> ahuillet: perhaps we just don't handle empty blocks in the new code?
13:30 <@ahuillet>     while (buffer.pos < bb->end) {
13:30 <@ahuillet> we still read the first
13:30 <@ahuillet> our target_bb has start = 4, end = 5
13:30 <@ahuillet> end is exclusive => we read at 4
13:30 <@ahuillet> but there is nothing at 4
13:30 <@penberg> ahuillet: right right
13:30 <@penberg> ahuillet: so just remove the "+ 1" and that fixes things?
13:31 <@ahuillet> no, it crashes :)
13:31 <@ahuillet> no goto statement is generated in that case, I don't know why yet
13:31 <@ahuillet> do we have a OPC_NOP ?
13:31 <@ahuillet> because I guess it's the best way of implementing empty blocks
13:32 <@ahuillet> Assertion failed at branch-bc-test.c:176: Expected 0x8123d28, but was (nil)
13:32 <@ahuillet> without the + 1
13:33 <@penberg> hmmmmmmm
13:33 <@penberg> ahuillet: well, yeah, I was thinking about that
13:33 <@penberg> OPC_NOP
13:33 <@penberg> hmm
13:33 <@ahuillet>         if (offset >= bb->start && offset < bb->end)                              |    if (!goto_stmt)
13:33 <@ahuillet> find_bb does this
13:34 <@ahuillet> so when you find_bb at TARGET_OFFSET
13:34 <@ahuillet> with a block that has start == end
13:34 <@ahuillet> you don't actually "find" it
13:34 <@penberg> ahuillet: right.
13:34 <@penberg> empty basic blocks don't really exist
13:34 <@ahuillet> so we have several possible fixes here.
13:35 <@ahuillet> NOP is probably the bestone
13:37 <@ahuillet> http://paste.pocoo.org/show/kCFGmS3agzKWeFnuW8gN/
13:38 <@ahuillet> penberg : ^
13:38 <@penberg> ahuillet: I am okay with that.
13:38 <@penberg> empty basic block is hacky anyway
13:39 <@ahuillet> sent to you
13:39 <@ahuillet> so, any reason to keep ostack as a different branch now?
13:39 <@penberg> ahuillet: no
13:39 <@penberg> ahuillet: so all I need is that + ostack branch
13:39 <@penberg> and everything works?
13:39 <@ahuillet> ok, so if you have ten minutes to kill at some point, merge ;)
13:39 <@ahuillet> yup, I have not touched the ostack branch
13:39 <@penberg> ahuillet: cool
13:39 <@penberg> will do
13:39 <@ahuillet> except for the two patches of today
13:40 <@penberg> haven't received your patch yet
13:40 <@ahuillet> ooh wait
13:40 <@ahuillet> one more
13:40 <@penberg> ahuillet: send them my wai
13:40 <@penberg> way
13:40 <@penberg> I'll merge in 30 mins or so.
13:40 <@ahuillet> .. in your mailbox, the last one
13:40 <@ahuillet> it's just a build fix for ObjectStackTest
13:52 <@ahuillet> ok, keep me posted, I'm on the bike for a few minutes
14:03 -!- vegard [n=vegard@ben.ifi.uio.no] has quit [Nick collision from services.]
14:03 -!- vegard [n=vegard@ben.ifi.uio.no] has joined #jato
14:04 -!- vegard is now known as Guest69394
14:04 -!- vegard [n=vegard@luke.ifi.uio.no] has joined #jato
14:14 -!- Guest69394 [n=vegard@ben.ifi.uio.no] has quit [Read error: 104 (Connection reset by peer)]
14:18 -!- huilleta_ [n=huilleta@ensibm.imag.fr] has joined #jato
14:20 <@penberg> huilleta_: merged
14:20 <@penberg> huilleta_: and pushed
14:21 <@penberg> huilleta_: as always, please double-check the result.
14:21 <@penberg> huilleta_: are you using github or korg repo?
14:22 <@penberg> vegard: ping
14:23 < huilleta_> penberg : I am using kernel.org :)
14:23 < huilleta_> penberg : to test here I'll need to fix jato to work with classpath .98
14:23 < huilleta_> arch linux tends to be too recent
14:24 < vegard> penberg: pong
14:25 <@penberg> vegard: so are you going to merge master to your branch and fix up conflicts?
14:25 < vegard> I did
14:25 <@penberg> vegard: ok, cool.
14:25 < vegard> well, not _my_ master
14:25 <@penberg> vegard: mainline
14:26 <@penberg> my tree
14:26 < vegard> http://github.com/vegard/jato/tree/test-merge-20090601
14:26 <@penberg> master as in master of the universe
14:26 <@penberg> huilleta_: ok, well, works here.
14:26 < vegard> O.o
14:26 <@penberg> huilleta_: will take a little bit time to mirror out
14:26 -!- ahuillet_ [n=user@129.88.57.59] has joined #jato
14:26 <@penberg> vegard: nice
14:26 < vegard> I meant, I merged your master ("mainline") not into my master, but into a copy of my master (called "test-merge-20090601")
14:26 <@penberg> vegard: did you have a lot of conflicts?
14:26 < vegard> yes!
14:26 <@penberg> vegard: yes!
14:26 < huilleta_> penberg : classpath .98 or my patches ? :)
14:26 <@penberg> vegard: makes sense.
14:26 <@penberg> huilleta_: your patches :)
14:27 <@penberg> I suspect classpath does not.
14:27 < huilleta_> I'm pretty sure it does not :)
14:27 < vegard> penberg: didn't know whether I should keep it or not. I am tempted to just merge your master, since that makes life a bit easier.
14:29 < tgrabiec> penberg: the trick with INSN_SEG_PREFIX won't work because of insert spill/reload ( spill insn is inserted between seg_prefix and the other instruction). What i propose is to add a new field to struct insn - "seg_prefix", and add new function like insn_set_seg_prefix(insn, seg). I suspect you might not like adding new field to struct insn?
14:30 -!- user__ [n=user@ensi-vpn-32.imag.fr] has joined #jato
14:31 <@penberg> vegard: you should probably merge to your branch, yes.
14:31 <@penberg> vegard: my master
14:31 <@penberg> vegard: to simplify the future merge.
14:31 <@penberg> tgrabiec: I don't know if you have much choice, really.
14:31 <@penberg> hello user__
14:31 <@penberg> ;)
14:31 <@penberg> tgrabiec: can you fix up the trivial bits in the patch series as well?
14:32 < tgrabiec> penbrg: i want to approve things like that before coding
14:32 < tgrabiec> penberg: "trivial bits" ?
14:32 < user__> that's me and my broken vpnc :)
14:32 -!- user__ is now known as Sven]
14:33 <@penberg> Sven?
14:33 < vegard> lol
14:33 <@penberg> tgrabiec: alloc_page()
14:33 < tgrabiec> ah, right
14:33 <@penberg> tgrabiec: well
14:33 <@penberg> tgrabiec: you could add a special INSN_TEST_THREAD_LOCAL thing, no?
14:34 <@penberg> tgrabiec: it's not like we're going to use segment prefix anywhere else?
14:34 < tgrabiec> penberg: probably we won't, but that's a hack, you didn't like INSN_THROW...
14:35 <@penberg> tgrabiec: I don't think it's a hack.
14:35 <@penberg> it's a real insn
14:35 <@penberg> vegard: ok, so, I just suggest you merge my master to your master now.
14:35 <@penberg> or whenever you feel like it
14:35 <@penberg> it's simpler to deal with conflicts early.
14:35 <@penberg> vegard: it's perfecly okay to have few merge commits in your branch
14:35 <@penberg> when I pull it.
14:36 < vegard> penberg: ok! :D
14:36 <@penberg> tgrabiec: the thing is
14:36 <@penberg> tgrabiec: making struct insn bigger for this special case hurts everyone
14:36 <@penberg> tgrabiec: INSN_TEST_THREAD_LOCAL doesn't hurt anyone
14:36 <@penberg> tgrabiec: and it documents the intent quite nicely.
14:36 < tgrabiec> penberg: actually it's INSN_MOV_MEMDISP_REG_THREAD_LOCAL
14:36 <@penberg> tgrabiec: that's fine.
14:37 < tgrabiec> penberg: ok, if you're fine with it i'm fine too :)
14:37 <@penberg> tgrabiec: then in emit-code.c you can use the proper name
14:37 <@penberg> tgrabiec: where you pass the segment register and so on.
14:37 -!- Sven] is now known as ahuillet__
14:37 -!- huilleta_ [n=huilleta@ensibm.imag.fr] has quit ["Leaving"]
14:38 <@penberg> vegard: so what's still broken in your tree right now?
14:38 < vegard> penberg: arch-x86 tests, I disabled them.
14:39 < vegard> penberg: some convert_ldc, basically converting the raw bytes of the constant pool into the right "native" values
14:39 < vegard> I also need to fix up some of the locking that came from tgrabiec via your tree
14:40 <@penberg> vegard: ok
14:40 <@penberg> vegard: what about the whole submodule thing?
14:40 < vegard> yes :) I was fearing that question ;
14:42 < vegard> three cohices, as I see it: 1. keep the submodule. 2. replace the submodule with a verbatim copy of current cafebabe. 3. use cafebabe as an external library.
14:43 <@penberg> hmm
14:43 <@penberg> (3) is pretty much out of the question because distributions are not carrying it.
14:43 -!- ahuillet_ [n=user@129.88.57.59] has quit [Read error: 110 (Connection timed out)]
14:44 <@penberg> vegard: I wonder how painful it is going to be with keeping it as a submodule.
14:44 <@penberg> vegard: plus if we did that, you'd need to relicense the code.
14:44 < vegard> ah, true
14:44 < vegard> LGPL?
14:45 <@penberg> vegard: no idea.
14:45 <@penberg> vegard: jato is gplv2 + linking exception
14:45 <@penberg> vegard: anything that's compatible with it is fine.
14:45 <@penberg> I am highly sceptical of the submodule approach
14:45 <@penberg> naturally
14:45 < vegard> oh right. should probably be the same.
14:45 <@penberg> vegard: if you use BSD license, for example, we're fine as well.
14:45 <@penberg> so
14:45 <@penberg> if you update cafebabe
14:45 <@penberg> do we automatically get new code?
14:46 <@penberg> or how is that supposed to work.
14:46 < vegard> yes and no
14:46 < vegard> I'll try to explain.
14:46 < vegard> when I update the cafebabe that is hosted on github, nothing changes automatically in jato.
14:46 <@penberg> aha
14:47 < vegard> the submodule in jato is bound to a specific commit, which only changes when you tell it to
14:47 <@penberg> vegard: but
14:47 <@penberg> vegard: what if you _remove_ cafebabe from github
14:47 <@penberg> vegard: do fresh clones of jato still get it?
14:47 < vegard> no
14:47 <@penberg> that's bad.
14:47 < vegard> the actual cafebabe code isn't saved with jato
14:47 <@penberg> vegard: so is there any way for me to _merge_ cafebabe to jato
14:48 <@penberg> vegard: while you can still keep your repo?
14:48 < vegard> jato only contains a pointer (url + sha1) to cafebabe
14:48 <@penberg> vegard: and I can pull from cafebabe?
14:48 < vegard> hm :)
14:48 < vegard> that's what linus did with btrfs
14:48 < vegard> brtfs?
14:48 <@penberg> yes.
14:48 <@penberg> so can we figure out how to do that.
14:48 <@penberg> because
14:49 <@penberg> if we do the submodule thing
14:49 <@penberg> I'd have to create a mirror of your repository anyway.
14:49 <@penberg> kernel.org
14:49 <@penberg> and I don't really want to do that.
14:49 <@penberg> I'd love to keep your history, though.
14:49 <@penberg> and your future changes to the damn thing.
14:49 < vegard> and it raises the bar for getting jato up and running
14:50 <@penberg> vegard: sure.
14:50 < vegard> with the extra steps (same with external lib)
14:50 <@penberg> vegard: extra lib is okay if distributions are carrying it.
14:50 < vegard> I doubt they'd carry cafebabe before jato ;)
14:50 <@penberg> :-)
14:51 <@penberg> vegard: so in summary: I am fine with cafebabe being a library
14:51 <@penberg> as long as I can _mirror_ it in my tree.
14:51 < vegard> I'll try to merge them with a git merge
14:52 <@penberg> ok, cool.
14:52 < vegard> I actually did that once before, at work. merge two disjoint trees.
14:57 -!- user__ [n=user@ensi-vpn-21.imag.fr] has joined #jato
15:01 -!- ahuillet__ [n=user@ensi-vpn-32.imag.fr] has quit [Read error: 60 (Operation timed out)]
15:23 < user__> mmh
15:23 < user__> I don't really understand how this classpath thing works
15:23 < user__> I'm sorry I do not believe I'll be able to fix that
15:23 < user__> I had to be rushed to the emergency room after fifteen seconds looking at java code, so... :)
15:23 -!- user__ is now known as ahuillet_
15:25 < tgrabiec> penberg: i sent reworked patches
15:26 < tgrabiec> ahuillet_: you're trying to make jato compile with cp 0.98 ?
15:27 < ahuillet_> yup
15:28 < tgrabiec> i could try
15:30 < ahuillet_> that would be greatly appreciated
15:37 < tgrabiec> gentoo dependencies are interesting. when i want to emerge gnu-classpath it wants to pull mozilla-firefox, but when i mask mozilla it does not complain
15:40 -!- ahuillet_ [n=user@ensi-vpn-21.imag.fr] has quit [Read error: 104 (Connection reset by peer)]
15:47 -!- ahuillet_ [n=user@ensi-vpn-16.imag.fr] has joined #jato
16:19 < ahuillet_> tgrabiec : any success ?
16:21 < tgrabiec> ahuillet_: classpath-0.98 fails to build, dunno why. i'm currently installing mozilla-firefox (from sources), maybe it will help
16:21 < tgrabiec> yeah, it's a long shot with that mozilla-firefox
16:22 -!- user__ [n=user@ensi-vpn-16.imag.fr] has joined #jato
16:22 -!- ahuillet_ [n=user@ensi-vpn-16.imag.fr] has quit [Read error: 104 (Connection reset by peer)]
16:22 < user__> why the hell does mozilla firefox need classpath?
16:22 -!- user__ is now known as ahuillet_
16:23 < tgrabiec> ahuillet_: i think classpath might need something that mozilla-firefox delivers
16:23 < tgrabiec> previously when i tried to emerge gnu-classpath-0.97-2 it tried to pull mozilla-firefox ebuild
16:25 < tgrabiec> ahuillet_, i'll have to go to university to consult some project, so i won't fix it in a few hours
16:28 <@penberg> http://github.com/penberg/jato/commit/719d40e53e92db621c2ffb9ef98ecd1da1011c63
16:28 <@penberg> aah, macro magic.
16:29 -!- user__ [n=user@ensi-vpn-6.imag.fr] has joined #jato
16:32 -!- user__ is now known as ahuillet__
16:32 -!- ahuillet_ [n=user@ensi-vpn-16.imag.fr] has quit [Read error: 104 (Connection reset by peer)]
16:33 <@penberg> tgrabiec: the series looks good to me
16:34 <@penberg> tgrabiec: but I want to read it bit more carefully before applying
16:34 < tgrabiec> penberg, sure
16:34 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Remote closed the connection]
16:50 -!- ahuillet_ [n=user@ensi-vpn-36.imag.fr] has joined #jato
17:00 -!- ahuillet__ [n=user@ensi-vpn-6.imag.fr] has quit [Read error: 110 (Connection timed out)]
17:28 -!- tgrabiec [n=tomekg@wifi-wpa.agh.edu.pl] has joined #jato
17:30 < tgrabiec> i figured out why classpath wants mozilla-firefox. it's trying to build gcjwebplugin. i disabled it, we'll see what happens
17:30 < ahuillet_> :)
17:30 < tgrabiec> oh, it built ok
17:40 < vegard> I think we should switch all jato's own includes into #include "" instead of #include <>
17:45 <@penberg> vegard: why
17:49 < vegard> because that means we can drop -I.
17:50 < vegard> erm, so. "" defaults to searching current directory first while <> doesn't
17:51 < vegard> and if there's a distinction, why not make use of it?
17:52 < vegard> I had a problem with #include <zip.h> because there was a jamvm/zip.h too -- solved by dropping -Ijamvm
18:02 < vegard> "" and <> are the de-facto way to distinguish between project-local and system-wide include files
18:03 < vegard> *is, maybe.
18:04 <@penberg> vegard: the problem is zip.h in jamvm/
18:04 <@penberg> everything should be in include/
18:05 <@penberg> you should use "" for headers that _are_ in the current directory
18:05 <@penberg> our header are in include/
18:06 < vegard> -Iinclude
18:06 < vegard> then "" would search include/ before /usr/include and <> would do the opposite -- I think.
18:08 -!- tgrabiec [n=tomekg@wifi-wpa.agh.edu.pl] has quit [Remote closed the connection]
18:11 -!- ahuillet_ [n=user@ensi-vpn-36.imag.fr] has quit ["Leaving"]
19:36 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
20:23 < vegard> argh
20:24 < vegard> ah nvm.
20:24 <@ahuillet> ? :)
20:53 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
21:30 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit []
22:47 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Read error: 104 (Connection reset by peer)]
22:48 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
--- Log closed Wed Jun 03 00:00:57 2009