--- Log opened Mon May 25 00:00:33 2009
09:58 <@penberg> vegard: we are missing them everywhere
09:59 <@penberg> tgrabiec, vegard: btw guys, since you figured out I messed up
09:59 <@penberg> can you please (1) complain to me and/or (2) send a patch
09:59 <@penberg> in the future
09:59 <@penberg> it works on my machine (tm) :(
10:01 <@penberg> ok fixed up now.
10:02 <@penberg> tgrabiec: I'll take a look at your patches little bit later today
10:02 <@penberg> tgrabiec: are you going to resend the one I already reviewed (and complained about)
10:07 < tgrabiec> penberg: the nullcheck via sigsegv patch is beeing reworked now, but i'm not sure if  i'll send it today, i really want to make it good
10:08 <@penberg> tgrabiec: ok
10:08 <@penberg> the INSN_THROW_REG_CU thing puzzles me a little bit
10:08 <@penberg> but I didn't look at it too closely
10:09 < tgrabiec> yeah, it's the same thing as with chackcast and arraycheck - i need a branch there
10:10 <@penberg> tgrabiec: did ahuillet come up with anything?
10:10 < tgrabiec> i know we haven't agreed yet what to do with those branches.
10:10 < tgrabiec> penberg: AFAIK nothing concrete
10:10 <@penberg> tgrabiec: ok
10:10 <@penberg> tgrabiec: I appied the rwlock patch now.
10:11 <@penberg> I guess I need to take a peek at hotspot/mono/cacao sources again ;)
10:11 <@penberg> to see how they deal with that
10:12 < tgrabiec> penberg: oh, i didn't know HotSpot has open sources..
10:14 <@penberg> tgrabiec: sure they do.
10:14 <@penberg> tgrabiec: http://openjdk.java.net/groups/hotspot/
10:15 <@penberg> it's a mercurial repository somewhere there
11:04 < tgrabiec> penberg: about your question what's the purpose of removing #include <arch/instruction.h> from compilation-unit.h etc.: arch/x86/exception_32.c needs both compilation-unit.h and ucontext.h. But enumerator machine_reg from registers_32.h conflicts with definitions from ucontext.h, so i solved it by not including arch/instruction.h in jit/compilation-unit.h
11:05 <@penberg> tgrabiec: aha
11:05 <@penberg> tgrabiec: so can you make that a separate patch?
11:05 < tgrabiec> penberg: ok
11:06 <@penberg> tgrabiec: it's usually better to arrange a patch series in such a way
11:06 <@penberg> that you first do a bunch of cleanups
11:06 <@penberg> and only after that you do the actual change
11:06 < tgrabiec> i understand. though usually the cleanup changes come out when you already have done the change :)
11:06 <@penberg> otherwise it's pretty difficult for me to look at the patch and figure out whether the patch does what it's supposed to do.
11:06 <@penberg> tgrabiec: sure
11:06 <@penberg> but are you aware of how to split commits in git?
11:07 <@penberg> it's super easy IMHO
11:07 <@penberg> furthermore, there's the --patch option to git add
11:07 <@penberg> so you can split changes to a specific file as well
11:07 <@penberg> tgrabiec: it's really worthwhile to spend so time thinking about your git workflow
11:07 <@penberg> what I usually do is
11:07 <@penberg> i just hack away
11:07 <@penberg> for a while
11:07 <@penberg> and then figure out how to split the patch properly
11:07 <@penberg> so I might end up with a monster patch
11:08 <@penberg> which I then split up
11:08 <@penberg> git rebase --interactive is your friend ;)
11:08 < tgrabiec> penberg: it's my first time with git
11:08 <@penberg> tgrabiec: right
11:08 <@penberg> check out "splitting commits" in git rebase man pages.
11:08 <@penberg> also
11:08 <@penberg> it's not usually the case that I have a single monster patch
11:08 <@penberg> actually
11:08 <@penberg> it's more like a collection of random small commits
11:09 <@penberg> that need to be rearranged and cleaned up
11:09 <@penberg> tgrabiec: look at vegard's git repository as a good example
11:09 <@penberg> there's no way in hell we're going to merge it as-is
11:09 <@penberg> but it simplifies the development a lot!
11:09 <@penberg> and when he's done, he will do the cleanup part before sending
11:09 <@penberg> (or before I pull his tree)
11:10 < tgrabiec> thanks, i'll take a look at it
11:14 < tgrabiec> penberg: another issue. in order to see the definitions like REG_EIP from ucontext.h, __USE_GNU must be defined. _but_ __USE_GNU is glibc internal macro and should not be used outside it. We sould add -D_GNU_SOURCE to cflags instead. are you ok with that ?
11:16 <@penberg> tgrabiec: I am
11:16 < tgrabiec> ok
11:17 <@penberg> doesn't -std=gnu99 define that, btw?
11:18 < tgrabiec> hmm, it seems, so nevermind
11:20 <@penberg> and I assume we define -std=gnu99?-)
11:21 < tgrabiec> yes we do
11:22 <@penberg> right
11:22 < tgrabiec> for some reason it dodn't work for me yesterday so i had to do __USE_GNU, but it works now without after some rearrangement
11:23 <@penberg> strange
11:24 < tgrabiec> ah, i know why. yesterday i used sys/ucontext.h and today just ucontext.h
11:24 <@penberg> aah
11:24 <@penberg> vegard: ping
11:31 < tgrabiec> penberg: i probably haven't woken up yet,   -std=gnu99 does not seem to define _GNU_SOURCE, we had to define it. forgot to do make clean while testing
11:31 <@penberg> :)
11:31 <@penberg> well, send a patch when you've had your morning coffee ;)
11:31 < tgrabiec> i'll do
11:46 <@penberg> hmm
11:47 <@penberg> the amount of spam our list is getting is starting to become annoying...
12:05 < vegard> penberg: pong! :)
12:06 <@penberg> vegard: ping-pong
12:06 <@penberg> vegard: so how is it going?
12:06 <@penberg> since you're working mostly out-of-tree
12:06 < vegard> I've also been adding _GNU_SOURCE to the top of some files :) mostly to get strndup(), but also asprintf().
12:06 <@penberg> I am following you like a hawk!
12:06 < vegard> ah
12:07 <@penberg> I see invokevirtual works now
12:07 < vegard> I actually wanted to talk a bit about object layout
12:07 <@penberg> great!
12:07 <@penberg> but can you give me an executive summary of your status?
12:07 <@penberg> well
12:07 <@penberg> lets put it in a slightly different way: are you facing any problems?
12:09 < vegard> not major problems
12:09 <@penberg> I was afraid you'd say that ;)
12:09 < vegard> hey, that's a good thing!
12:09 <@penberg> from a manager point of view?
12:09 <@penberg> ;)
12:09 < vegard> uh-huh
12:09 < vegard> from all our points of view?
12:09 <@penberg> just kidding vegard!
12:09 <@penberg> so
12:10 <@penberg> object layout?
12:10 < vegard> but I'm having a hard time wrapping my head around "array of primitive" objects
12:11 < vegard> first of all, what class does a byte[] belong to?
12:12 < vegard> it might sound like a silly question, because I've never had to worry about it when _programming_ with java.
12:12 < vegard> but now, arrays are "struct object", and those have a pointer to struct class!
12:13 < vegard> and I have no idea what to put in that ->class in order for array.length to work.
12:14 < vegard> wait, there's an arraylength instruction for that. hmm
12:15 <@penberg> array of primitives?
12:15 <@penberg> primitives are not objects in the jvm.
12:15 <@penberg> so byte[] is an array of 8-bit entries
12:16 <@penberg> Byte[], OTOH, is an array of _references_ to objects of type Byte
12:16 <@penberg> and yes
12:16 <@penberg> array is an object.
12:16 <@penberg> well
12:16 <@penberg> hmm
12:16 <@penberg> yes
12:16 <@penberg> a special kind of object, I suppose.
12:17 <@penberg> because array.length is _not_ a method.
12:17 <@penberg> arrays are special. ;)
12:17 < vegard> hm, yes.
12:18 < vegard> it seems that Jam VM has used 'struct object' for both objects and arrays. I was wondering if I should make a struct array.
12:18 < vegard> hey
12:18 < vegard> actually, there's no problem at all
12:18 < vegard> I know how to fix this.
12:19 <@penberg> :)
12:19 < vegard> Tests OK.
12:19 <@penberg> cool
12:19 <@penberg> what was the problem?
12:20 < vegard> field->offset = 0 for every field, so different (non-static) variables reused the same memory
12:20 <@penberg> ahaa
12:21 < vegard> field->offset = rand() % 256; solved that very efficiently!
12:22 <@penberg> hmm. :)
12:29 < vegard> shouldn't we use net.sourceforge.jatovm.* for packages instead of jato.*?
12:31 <@penberg> vegard: not really.
12:32 <@penberg> the domain name as package name thing is so 1990s
12:32 <@penberg> what we really should do is use the java/ namespace
12:33 <@penberg> but anyway, jato.internal will go away
12:33 <@penberg> so I wouldn't worry about it
12:34 < vegard> why so 1990s?
12:34 < vegard> or maybe: why invalid today?
12:37 <@penberg> it doesn't bring a whole lot to the table, really.
12:37 <@penberg> the "com" and "net" part is obviously redundant.
12:37 <@penberg> the actual domain name is so and so
12:37 <@penberg> jatovm is unique enough
12:38 <@penberg> I used jato, though, which is bit of a problem
12:42 < vegard> I actually loved the package naming scheme of java
12:42 < vegard> it's the only 100% foolproof method
12:42 < vegard> just look at how much of a mess C is, for the lack of namespaces
12:42 <@penberg> well
12:43 <@penberg> as soon as you have two classes with the same name
12:43 <@penberg> you get into trouble even if you have different package names
12:43 <@penberg> that is, if you need to _use_ both classes in the same file
12:43 < vegard> hm, yes, I agree that would be a problem.
12:44 <@penberg> and the java package name + directory structure coupling causes headaches as well
12:44 <@penberg> which is why short package names are nicer.
12:44 < vegard> but I think the real solution would be to provide a typedef in the java front-end
12:44 <@penberg> anyway, if you care, feel free to send a patch that moves jato.internal.VM to java
12:44 <@penberg> argh!
12:44 <@penberg> java/vm/internal/VM or something
12:45 < vegard> :-P
12:45 < vegard> always making us do the dirty work... hah, I'll just wait one more day and you'll have done it for me :-P
12:47 <@penberg> vegard: yes, I've noticed that you've discovered my evil plans.
12:47 <@penberg> but don't worry
12:47 <@penberg> I'll find a way to get my revenge!
12:48 <@penberg> vegard: you know what would probably help here
12:48 <@penberg> print out a picture of linus
12:48 <@penberg> then write "pekka = linus" to the picture
12:48 <@penberg> and have it visible while you hack on jato
12:48 < vegard> oh... that would be too terrifying
12:48 <@penberg> ;)
12:49 <@penberg> vegard: alternatively, print out a picture of al viro
12:49 <@penberg> with davem
12:49 < vegard> cripes!
12:49 <@penberg> hahaha!
12:49 <@penberg> anyway
12:49 <@penberg> the point is that I don't care too much about the package name
12:49 <@penberg> because it's going away
12:50 <@penberg> so it's unlikely that I can be bothered to fix it
12:50 < vegard> yep. I guess I don't REALLY care either.
12:50 < vegard> but.. I like to be consistent.
12:51 < vegard> what's it called? pendantery?
12:51 <@penberg> pedantry?
12:51 < vegard> yes :P
12:52 <@penberg> I am hoping you'll have nightmares about it.
12:52 <@penberg> so you'll submit a patch first thing tomorrow morning.
12:53 < vegard> we'll see.
12:54 < vegard> about object layout, are all fields 32 bits except long and double?
12:54 < vegard> or do we make them all 64 bits? what about alignment?
12:55 <@penberg> hmm
12:56 <@penberg> I suppose you mean primitive fields now?
12:56 < vegard> no, all fields. so add "object reference" to list of exceptions (on 64-bit)
12:57 <@penberg> well
12:57 <@penberg> I'd just make references sizeof(void *)
12:57 <@penberg> double and long 64-bit
12:57 <@penberg> and rest of them 32-bit
12:57 <@penberg> because that gives us nice natural alignment.
12:58 < vegard> not on 64-bit
12:58 <@penberg> I am thinking of x86 here
12:58 <@penberg> 4 byte alignment should be fine for x86-64, no?
12:58 < vegard> gcc aligns on 8-byte boundary on x86_64
12:58 <@penberg> and intel optimization manual agrees?
12:59 < vegard> ah, I'd have to check
12:59 <@penberg> well, anyway, I would do what I suggested
12:59 <@penberg> because what you really want to do on 64-bit
12:59 < vegard> btw, I think we could reorder the fields without problems
12:59 <@penberg> is reorder the fields so that you fill any holes caused by 32-bit fields
12:59 < vegard> :D
12:59 <@penberg> vegard: yup.
12:59 < vegard> cool.
12:59 <@penberg> I am fine with that too
13:00 <@penberg> if you can come up with a simple algorithm to do that.
13:00 <@penberg> it's bit problematic, though
13:00 <@penberg> because then you really want to take cacheline size into account
13:00 < vegard> um, yes. split fields in 32 and 64 bit sizes. put all 64-bit fields first, put the rest afterwards.
13:00 <@penberg> which is why I suggested the simple approach.
13:00 <@penberg> ok
13:00 <@penberg> sounds good to me!
13:00 <@penberg> you are one smart cookie!
13:01 <@penberg> you know
13:01 < vegard> ehe
13:01 <@penberg> then you could also keep 8-bit and 16-bit sizes
13:01 <@penberg> vegard: what do you think?
13:02 < vegard> is char 16-bit on java?
13:03 < vegard> I know Java is heavy user of UTF-16.. but you still need 20 bits to represent all the characters in unicode, I think
13:03 < vegard> yes, sounds good.
13:03 <@penberg> char is 16-bit on java indeed
13:04 <@penberg> vegard: btw, you are familiar with this right? http://java.sun.com/docs/books/jvms/second_edition/jvms-clarify.html
13:04 < vegard> aha, nope
13:04 <@penberg> vegard: and can you explain what the hell "miranda methods" are?
13:05 < vegard> uhm. I can try.
13:05 < vegard> it's a hack that sun added to their jvm
13:05 < vegard> because some early compilers were buggy
13:06 < vegard> they didn't... output methods... for abstract interface methods
13:06 <@penberg> argh!
13:06 <@penberg> and we need to support that?
13:06 < vegard> so the jvm has to add them
13:06 < vegard> no, I don't think so
13:07 <@penberg> ok, great
13:07 < vegard> it's an ancient hack and would most likely not be needed
13:07 <@penberg> I think we can safely ignore anything that's pre 1.4
13:07 < vegard> only for really old .class files
13:17 < vegard> ok, for now I am just making each field 64 bits
13:18 < vegard> but with XXXs in place
13:18 < vegard> correctness first, optimisations later ;)
13:31 <@penberg> I like your style.
13:31 <@penberg> :)
13:43 < vegard> how come LIR mov_reg_memindex r1, (r2, r3, 2) turns into mov %eax,(%esi,%ebx,4)? (I'm thinking about the 2 -> 4)
13:44 <@penberg> vegard: 2 is _shift_
13:45 < vegard> but so is 4
13:45 <@penberg> hmm
13:46 <@penberg> i don't think it is
13:46 <@penberg> i think it's the scaling factor.
13:46 -!- ahuillet_ [n=user@ensi-vpn-28.imag.fr] has joined #jato
13:46 < vegard> hm
13:46 < vegard> aha.
13:47 <@penberg> ahuillet_: salut!
13:48 < vegard> ok, you're right. thanks :)
13:51 < ahuillet_> hi :)
13:51 < vegard> hello
13:52 < vegard> I'm looking at STMT_STORE(inst_field, reg)
13:54 < vegard> what does base and index point to?
13:59 <@penberg> hmm
14:00 <@penberg> vegard: state->left
14:00 < vegard> I think I figured it out -- that shift (2) needs to be 0, since we already compute the offset in bytes
14:00 <@penberg> yup, makes sense.
14:01 < vegard> and I think the corresponding load would be inst_field: INSTANCE_FIELD(reg) ?
14:01 <@penberg> yes
14:01 <@penberg> actually no
14:01 <@penberg> reg: EXPR_INSTANCE_FIELD
14:01 <@penberg> ^^^
14:01 <@penberg> the rule you are referring to is part of the _store_
14:01 < vegard> aha
14:02 < vegard> replaced that 2 with 0 as well, works now :D
14:04 <@penberg> vegard: hmm, I'm confused
14:04 <@penberg> did you find a bug?
14:05 < vegard> no -- but I think jam vm used a fixed 8 bytes per field
14:06 <@penberg> oh.
14:06 < vegard> so for object offset = 1, you get (void*)object + 8
14:06 < vegard> while now, we don't have offset = 1 for the first field, we have offset = 8
14:06 < vegard> makes sense?
14:07 < vegard> uhm, sorry, that should be _second_ field
14:07 <@penberg> uhm
14:08 <@penberg> if you meant: field 0 = offset 0, field 1 = offset 8
14:08 <@penberg> then yes, it makes sense.
14:08 < vegard> yes :)
14:32 <@penberg> tgrabiec: so
14:32 <@penberg> tgrabiec: why do we need to introduce INSN_THROW_REG_CU?
14:32 <@penberg> because of the branch?
14:33 <@penberg> I don't like the solution. Hmm.
14:33 <@penberg> because it seem to me we would end up with bunch of special case instructions if we follow this path.
14:33 <@penberg> so I'd suggest we look into what others do
14:33 <@penberg> perhaps we need to resurrect this after all: http://www.laughingpanda.org/~penberg/insn-label.patch
14:34 < tgrabiec> penberg: i don't like this soultion too
14:36 <@penberg> tgrabiec: ok, good. :)
14:36 <@penberg> then we just need to find something better.
14:36 <@penberg> I am beginning to open up for INSN_LABEL
14:37 <@penberg> but I still worry about breaking basic block assumptions
14:37 < tgrabiec> it seems better to me than splitting bb
14:37 <@penberg> hmm
14:37 <@penberg> splitting bb is known to be safe
14:37 <@penberg> insn_label otoh is not
14:37 <@penberg> so we need to do some thinking here
14:38 <@penberg> to convince us that insn_label isn't going to hurt us in the long term.
14:41 <@penberg> hmm
14:41 <@penberg> hotspot seems to have lir_checkcast thing
14:41 <@penberg> which would mean INSN_CHECKCAST for us hmm
14:42 <@penberg> they also have lir_throw, for example. hmm.
15:55 -!- ahuillet_ [n=user@ensi-vpn-28.imag.fr] has quit ["Leaving"]
17:40 < tgrabiec> `git add -p` and `git rebase -i` are awesone :)
18:04 -!- tgrabiec [n=tomekg@91.90.189.107] has quit [Read error: 104 (Connection reset by peer)]
18:05 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
20:03 -!- Eduard_Munteanu [n=edi@79.115.194.182] has joined #jato
20:03 < Eduard_Munteanu> Hi there.
20:13 < tgrabiec> hello
20:15 < Eduard_Munteanu> I'm running Jato with './jato -Xbootclasspath:/opt/gnu-classpath-0.97/share/classpath/glibj.zip -verbose regression/jamvm/ExitStatusIsZeroTest.java'.
20:16 < Eduard_Munteanu> But it errs out with "Error initialising VM (initialiseMainThread)". Any ideas?
20:23 < tgrabiec> Eduard_Munteanu: you should include also lib/classes.zip in bootclasspath, so: -Xbootclasspath:lib/classes.zip:/opt/gnu-classpath-0.97/share/classpath/glibj.zip
20:25 < tgrabiec> but if you want to run the test, you should probably try something like this: ./jato -Xbootclasspath:lib/classes.zip:/opt/gnu-classpath-0.97/share/classpath/glibj.zip -Dgnu.classpath.boot.library.path=/opt/gnu-classpath-0.97/lib/classpath/ -cp regression/ jamvm/ExitStatusIsZeroTest
20:26 < tgrabiec> or:  scripts/java -cp regression jamvm/ExitStatusIsZeroTest
20:27 < Eduard_Munteanu> tgrabiec, thanks.
20:35 < Eduard_Munteanu> tgrabiec, hmm, now it errs out with "Cannot create system class loader".
20:36 < tgrabiec> which command exactly?
20:36 < Eduard_Munteanu> tgrabiec, both the "./jato ..." and the "scripts/java".
20:37 < tgrabiec> are working on latest master?
20:37 < tgrabiec> *are you working
20:37 < Eduard_Munteanu> tgrabiec, probably not, last time I git-fetched was like a week ago.
20:38 < Eduard_Munteanu> tgrabiec, will rebase and try again.
20:38 < tgrabiec> does make regression work?
20:42 < Eduard_Munteanu> tgrabiec, err no, lemme checkout origin/master again
20:46 < Eduard_Munteanu> tgrabiec, nevermind, I was going to use it to test my patches. Will fetch later and try again. Thanks for helping.
20:49 < Eduard_Munteanu> ahuillet, penberg, I just sent some patches. I'd appreciate some review.
21:31 < Eduard_Munteanu> penberg, are you here?
21:48 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
21:48 < penberg_home> vegard: ping
21:49 < penberg_home> vegard: did you really think jamvm has regression tests?-)
21:49 < penberg_home> vegard: "regression: remove jamvm test-cases from the script" is a bogus
21:49 < penberg_home> vegard: they're proper jato code
21:49 < penberg_home> the package name "jamvm" is historical
21:49 < penberg_home> from the time when I thought I'd submit jato code to jamvm at some point.
21:50 < penberg_home> vegard: so pls don't remove them ;)
21:52 < Eduard_Munteanu> penberg_home, regarding the stuff we were discussing on mail...
21:53 < penberg_home> Eduard_Munteanu: yeah?
21:53 < Eduard_Munteanu> Sure, we could set up a global emitter table, however, we still need those symbols in emit-code_64.c. Things like __emit_push_reg, for example.
21:54 < penberg_home> aah right.
21:54 < penberg_home> well, lets make an arch/x86/include/emit-code.h then
21:54 < penberg_home> the #include "foo.c" thing is simply too ugly to live with.
21:55 < Eduard_Munteanu> penberg_home, yeah, I thought it was ugly, so that's why I asked whether it was alright :-).
21:55 < penberg_home> Eduard_Munteanu: :)
21:55 < vegard> penberg_home: aha. thx, I thought I saw a license there
21:55 < penberg_home> vegard: you probably did
21:56 < penberg_home> and the license is wrong
21:56 < Eduard_Munteanu> penberg_home, okay, will create an emit-code.h. A few extra global symbols probably don't hurt.
21:56 < penberg_home> jato was gplv2 only at some point.
21:56 < penberg_home> Eduard_Munteanu: no they don't
21:56 < penberg_home> Eduard_Munteanu: there' going to be one "emit" namespace per arch anyway
21:57 < Eduard_Munteanu> Yeah.
21:57 < Eduard_Munteanu> penberg_home, any other comments on the patches?
21:58 < penberg_home> they look good tome
21:58 < penberg_home> to me
21:58 < penberg_home> Eduard_Munteanu: btw
21:58 < penberg_home> why do we want to split the files in the first place?
21:58 < penberg_home> couldn't you just do #ifdef CONFIG_X86_64 in emit-code.c and be done with it?
21:58 < penberg_home> that's probably a cleaner approach isn't it?
21:59 < penberg_home> Eduard_Munteanu: have you looked at linux/arch/x86 lately?
22:00 < penberg_home> they do #ifdef CONFIG_X86_64 in various places and the result is quite clean
22:00 < Eduard_Munteanu> penberg_home, emit-code.c was meant to contain code that works on x86-64. Having an unified emit-code.c for both 32-bit and 64-bit needs quite a few #ifdefs.
22:00 < penberg_home> Eduard_Munteanu: are you sure?
22:00 < Eduard_Munteanu> penberg_home, hmm, I might have overestimated the spagetti effect.
22:00 < penberg_home> Eduard_Munteanu: I think you have
22:00 < penberg_home> looking at emit-code_64.c, it's pretty small, isn't it?
22:01 < penberg_home> Eduard_Munteanu: well, anyway, up to you, really
22:01 < penberg_home> except for #include "foo.c" ;)
22:01 < Eduard_Munteanu> penberg_home, for the moment.
22:01 < penberg_home> Eduard_Munteanu: true that
22:01 < penberg_home> well, up to you
22:02 < Eduard_Munteanu> penberg_home, should end up the same size as emit-code_32.c when all portable stuff is moved.
22:02 < Eduard_Munteanu> penberg_home, I think I'll do as the Linux guys did, and have an unified emit-code.c file. We also get rid of making an emit-code.h.
22:03 < Eduard_Munteanu> penberg_home, thanks.
22:20 < penberg_home> Eduard_Munteanu: no prob
22:26 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit []
--- Log closed Tue May 26 00:00:33 2009