Log of the #nice channel on irc.freenode.net

Using timezone: GMT+01:00
<GummiEnte>hello log!09:29
quit09:31
* GummiEnte leaves
* GummiEnte joins09:48
* arjanb joins10:25
hello10:27
the bug with loops in initializers is fixed in cvs10:28
<GummiEnte>hello...10:36
:)))
<arjanb>ask daniel for a new development version if you want to test it10:38
<GummiEnte>Ahhh, now I have to wait for the upate of the backup servers... :/ but I can deal with it...
I've send Daniel already a patch for sualtam, cause it has been working with the wrong timezone when compiled nativly. Now you can adjust the timezone...10:39
...and it get displayed on top of each sheet as you can see in the log of today at confer09.condor-edv.com/nice@freenode10:40
<arjanb>sourceforge is getting new cvs servers soon so then the anonymous cvs will be up to date again10:41
<GummiEnte>Goo to hear that.10:43
What about the gcj issue?10:48
<arjanb>daniel will look at the bytecode generation today10:49
<GummiEnte>Ok. Anyway, I'll write a mail... Hopefully, there do not come any special questions about the bytecode... 10:50
Well, the exploit you yesterday gave me, is compilable by nicec, but during jvm runtime it gaves me the following error:10:57
Exception in thread "main" java.lang.VerifyError: (class: testing/A, method: size signature: ()I) Illegal type in constant pool
That should be Ok, should'nt it?
<arjanb>abstract class A<T> extends AbstractList<T> {10:59
size() = 10;
get(0) = cast(null);
}
class B<T> extends A<T> {
get(index) = super;
get(0) = cast(null);
}
void main(String[] args)
{
B<String> b = new B();11:00
b.get(1);
}
<GummiEnte>Excactly that I'm using.
<arjanb>which jvm do you use?
<GummiEnte>Nice compiler version 0.9.2 prerelease (build 2003.08.27, 09:13:24 UTC)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)11:01
Should I use another compiler or another JVM?
<arjanb>could you use 0.9.3 for that
<GummiEnte>MomPl.11:02
Nice compiler version 0.9.3 prerelease (build 2003.09.24, 17:08:43 UTC)11:03
Compiled using JDK 1.3.0
Exception in thread "main" java.lang.AbstractMethodError: java.util.AbstractList.get(I)Ljava/lang/Object;
at testing.A.get(minimal.nice)
at testing.B.$super$get(minimal.nice)
at testing.fun.get$1(/2ndHDD/home/rubber/Work/WorkingDirectory/e3m/src/testing)
at testing.B.get(minimal.nice)
<GummiEnte>Welcome back @ Gummi_log :)11:07
* bonniot joins13:59
hi
<GummiEnte>Hello.14:01
<arjanb>hi14:03
daniel about multiline string literals i have the parser part working14:09
but i'm not sure how to handle end of lines because they are different on some os's14:10
<bonniot>what exactly is the problem?14:12
<arjanb>i don't know if there could a problem
if one os uses slash n slash r should that be coverted to slash n14:14
<bonniot>isn't \n the strandard in Java?14:16
for instance, if I write a string with \n, it will be converted to \r\n when run on windows, no?
<GummiEnte>I'll leave for lunch. CU later...14:17
<arjanb>i have to look at that14:21
<bonniot>that's what we use for error messages, for instance
<arjanb>i see that now slash r's do get into the literals in bytecode14:28
<bonniot>yes14:31
<arjanb>so do other os's care about that?14:35
<bonniot>well, every os has a EOL encoding, yes :-)14:37
on Mac OS it is just \r
<arjanb>so i should convert all to \n14:38
<bonniot>yes, but multiple EOL should not be merged into one14:41
so: ( "\n" | "\r" [ "\n" ] ) ==> \n
<arjanb>ok
<bonniot>(maybe is it \n \r in win?)14:42
<arjanb>no \r \n14:43
* arjan_b joins15:50
connection probs again15:51
daniel only the irc logs of 15 and 16 sept contain anything interesting for the time you have been away15:55
on a dutch forum was an discussion about the use of . for both packages resolution and functions calls15:58
what do you think about using 2 different symbols for that?15:59
* arjanb leaves16:09
<bonniot>i know the argument, but I think for Nice it would not be worth the incompatibility16:12
<arjanb>and it looks like we are being watched see log of 15 sept16:13
nice already reduced the overloading of .16:14
no innerclasses16:15
<GummiEnte>I've read a commit message about "do not generate a call to an abstract method". That should already fix my issue with the gcj compiler, should'nt it?17:26
Daniel, have you received my patch for sualtam?17:27
<bonniot>yes, this is the fix17:28
<GummiEnte>:)
<bonniot>about time: is it necessarily better to use the default locale of the computer running the log?17:29
people from anywhere can look at the logs, so there is no right or wrong timezone
<bonniot>that's UTC17:31
<GummiEnte>Uups... That I did'nt know.
<bonniot>oh sorry, no17:32
gtm-2?
i thought cest-2
<GummiEnte>Yes, really confusing... So now, we can set the time that should be used... No, it was GMT-2:00..!?!
But not for the java version, that was working correclty...
So, what timezone should we use?17:35
I also noticed, that the logger gets upset a bit often as native compiled version.... Did you also encoutered that with the plain java versi0on?
<bonniot>i think either UTC, or CET/CEST (most of us seem to be in that zone)17:38
upset?
<GummiEnte>Well, it throws the follwoing exception and dies:17:39
Ah, I just deleted the log file :(17:40
Well, let me drop some lines to the chatroom, maybe its really to much input at once?...
<GummiEnte> So, what timezone should we use?17:41
<GummiEnte> I also noticed, that the logger gets upset a bit often as native
compiled version.... Did you also encoutered that with the plain
java versi0on?
<bonniot> i think either UTC, or CET/CEST (most of us seem to be in that zone)
<bonniot> upset?
No, that is does not seem to be...
<bonniot>the dev version is updated, so you can check if native compilation now works for you17:51
<GummiEnte>Thnx... Is the dev version compiled with 1.3 or 1.4?
<bonniot>1.417:54
<GummiEnte>:( That won't work with gcj-3.3.1. Only with gcj-3.4 but that development version is not already patched with the mingw32 dll patches to enable eh over dll/exe boundaries.17:55
<bonniot>to enable what?18:04
<GummiEnte>eh == exception handling
<bonniot>i'm rebuilding with 1.318:05
is anon cvs still delayed?
<arjanb>yes18:06
<GummiEnte>Yes... If tried it this morning after arjan told me that the initilizers are fixed...
<bonniot>uploaded18:13
<GummiEnte>Thnx. I'll try in a minute.18:16
If I now try to compile arjans testcase, the compiles gives me: There is no super implementation to call18:20
That should be from now on normal, should'nt it?
<bonniot>which testcase? there were many18:29
<GummiEnte>abstract class A<T> extends AbstractList<T> {18:30
size() = 10;
get(0) = cast(null);
}
class B<T> extends A<T> {
get(index) = super;
get(0) = cast(null);
}
void main(String[] args)
{
B<String> b = new B();
b.get(1);
}
:-))) The compiler you uploaded is now again compilable through gcj and mingw32-gcj ! Great work! Thanx18:31
<arjanb>what does it at runtime?18:33
<GummiEnte>Well, then I have to boot a windows machine, please wait...
Well, seems so, as if you are rigth arjan... Does not work as expected... Does nothing on the windows side... no exception nothing... :(... I'll have again to investigate that.18:54
<arjanb>but does your project work now?
if so than can this issue rest untill it's a real problem again18:56
<GummiEnte>Ok, I've found a way to let the program again compile and also work on windows runtime... So, it does work now as it should (maybe not as it should, because of the bytecode that normally should get accepted...)... 19:00
So, again, Thnx.
<bonniot>the compiler reports an error as expected on this testcase19:14
wdym: "does not work as expected" and "i've found a way" ?
<GummiEnte>Well, does not work as expected, because a direct compile into one executable has not work the e way iit should, but when using at least one shared library it has worked... I assume this is nothing nice specific...19:16
There are quiet a few stumbling blocks to a successfull shared library executable with a linux hosted cross compiler to mingw32...19:17
Arjan has already asked, if I could create some docs on the wiki, and I'll do so, as soon as I find the time.19:18
Have you already get the point about 'LGPL does not allow to compile static binaries'? That is also a main reason, why I need a shared nice.dll...
<bonniot>ok, so the bug is indeed fixed, isn't it?19:20
about the license: are you redistributing your program?
<GummiEnte>Yes, although as arjan told me was no real bug in nice but (still) is in gcj-3.3.1...
<bonniot>yes19:21
<GummiEnte>yes, we do so...
<bonniot>maybe we should just choose a more liberal license19:22
<GummiEnte>LGPL forces, that the enduser must be able to exchange the library that stands under the LGPL.
<bonniot>yes, that's true19:23
but i don't see a strong need to impose that condition
<GummiEnte>Mabye you want to use the "Guile license"?...19:24
Gnu-crypto also uses that license: http://www.gnu.org/software/gnu-crypto/
<bonniot>what is it like?
<GummiEnte>It is GPL, except the linking exception.19:25
But, only for me you don't need again to adjust your license. We also depend on other libraries that use LGPL and they won't change it I assume...19:26
So, it would be allowed to redistribute a static program and also a program that uses the nice-lib as a shared lib...19:27
<bonniot>i don't want to impose special license difficulties when simply using Nice to compile your own code19:28
<GummiEnte>Yes, but LGPL should be sufficient. Why should'nt profit from all your changes.... But on the other hand, if the nice.[dll|so] changes, this is so basic, that also the hole program has to be recompiled, so that most likely won't work with a simply relink stage...19:30
So, I agree for all the classes that are needed at runtime. That should be just a "plain" and "easy" to use library.19:31
Just to come back to the time issue in sualtam: Isn't GMT+1:00 CET?19:34
<arjanb>not at summertime
<GummiEnte>I've started sualtam now with sualtam ... --timezone CET
Summertime :( I don't like summertime, but you are right...
<bonniot>it's CEST now (summer)
<arjanb>ah ok19:35
<GummiEnte>Not that I don't like the summer, but to my opinion summertime is not needed...
<arjanb>all these abbrevations are confusing
GummiEnte: is split up nice.lang still needed?19:37
<GummiEnte>Well, at the moment I don't really now.19:42
If I want to use nice.getopt (a really nice nice package :)), what will I need at runtime?
<bonniot>just nice.getopt.*19:43
it is pure nice, thanks to arjan :-)
<GummiEnte>Ahh, I'm not allowed to use it...19:44
<arjanb>it's only a minimal conversion of the java version
<GummiEnte>I've just seen it today, as I created the sualtam patch and wanted to integrate it into my application, but now I see, that it's not LGPL.19:45
<GummiEnte>Do you have an idea, why this could happen?19:47
GPL+link: That would be just fine...19:48
... not to say nice... :) (The name is really a good choice). Is there a story about the name?
<bonniot>did you recompile Sualtam from source?19:50
<bonniot>Gummi_log: after IRCConnection: Sleeping for a bit (1000)..20:28
did you try to wait for it to reconnect?
arjanb: i will be back a bit later
* Quick-Nic joins20:59
<bonniot>arjanb: i've been thinking about allowing non-default constructors21:15
i will probably put up a wiki page with a spec tomorrow
GummiEnte: do you have a sf account? what user name? I could add you as a developer of sualtam21:17
<arjanb>multiline string literals are working now i think21:18
i haven't thought yet about non-default constructor so i won't bother you with idea21:21
<GummiEnte>@daniel: Yes, I've got an account: It's rubberduck21:22
Well, the process is immediatly dead... So a ps aux | grep sualtam gives me an empty list...21:24
<arjanb>daniel bug #791630 should be moved to feature requests21:31
<bonniot>GummiEnte: ok, so it could be interesting to see if that also happens with a jvm version21:35
for that bug/rfe: there would need to be a clearly specified feature anyway21:38
with dynamic loading, some errors can only be reported at runtime anyway
probably the error message could be improved
ok, i'll go for tonight. bye!21:39
<GummiEnte>have a good night. I'll go also...
<arjanb>bye
* GummiEnte leaves
* bonniot leaves21:41

Generated by Sualtam