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

Using timezone: Central European Time
* zzorn_sleep leaves02:41
* bonniot leaves04:00
* arjanb leaves04:11
* zzorn joins07:30
* bonniot joins11:19
<CIA-2>03bonniot * 10tester/ (gcj.test run): Added gcj testing (running the testuiste only)11:52
* ArtemGr joins12:08
* arjanb joins13:08
<bonniot>did you upgrade to 0.9.10? ;-)14:04
<ArtemGr>No, I didn't noticed. 8 ) Have prerelease build 2005.02.21 now.14:12
<bonniot>you can register to get email notifications...14:13
Sun says that ignoring 'file.encoding' is not a bug. They recommend to use OS locale. But from my experience, locale settings does not change the Sun encoding at least on FreeBSD...
<bonniot>then maybe that one is the bug14:23
<ArtemGr>I'd say it's a mess (rather than a bug). : )14:26
<bonniot>sounds like it14:28
<ArtemGr>file.encoding is docummented by Sun in a lot of places, it was a de-facto standard, and now they don't have a clean (or even working, IMHO) way of setting the encoding. Alas, I have the way of setting the encoding on FreeBSD, it's a one-string patch to j2se/src/share/classes/sun/io/Converters.java: if( true ) return "UTF-8"; in the beginning of the getDefaultEncodingName method, but I can't of cou14:29
rse apply it on linux binaries.
<bonniot>you can't get UTF-8 owrking on linux?14:31
<ArtemGr>That's why I filed http://sourceforge.net/tracker/index.php?func=detail&aid=1076945&group_id=12788&atid=362788 RFE, although i don't remember if i tried locale settings on Linux, i admit.14:33
<bonniot>i see javac has an -encoding option14:37
<ArtemGr>GCJ have --encoding option too.14:39
It's not practical to use Locale even if it works, there might be different encodings used in the same project.14:40
<bonniot>i guess you could set the locale locally14:41
but yes, -encoding seems to be the best solution
don't you want to gice it a try? it should be fairly simple ;-)14:43
<ArtemGr>for example, it would require a special ant task to set locale (charset encoding in particular, if possible, without changing the locale itself) locally...
<ArtemGr>You mean patching nicec? I'll try if you point me to where to look.
it's about how source files are read, right?
<bonniot>i think the action is in src/bossa/modules/DirectorySourceContent.java
* Bluelive leaves14:55
<bonniot>ArtemGr: are you there?14:59
<ArtemGr>Yes, I've just updated Nice sources from CVS...15:00
just let me know if you have any question15:01
ArtemGr: did you have a look?17:27
<ArtemGr>Yes, seems clear, but i need an environment to test any modifications, so i've started writing the Nice bootstrapping Ant script.17:30
<bonniot>oh, cool
are you on BSD now?17:31
why cannot you use the Makefile?17:32
<ArtemGr>No, I have BSD on servers, but my workstation have Windows XP, and currently i use GPRS at home so i can't just copy everything to Linux for testing (well, i can configure rsync, that will be almost no traffic, but it's still a painful debugging setup i think).17:34
the ant script will be very useful in any case17:37
isn't the Makefile confusing?17:40
<ArtemGr>There are things i'm currently omitting, like classes/classes-inline separation. Otherwise it's straightforward so far.17:43
<bonniot>ok. these are subtleties that are necessary when a change is made in the core compiler (which will not match the bootstrap compiler)17:46
<ArtemGr>Currently i want a simplest working way to build Nice, when this works, i'll think about making Ant script closer to the Makefile.17:49
<ArtemGr>src\nice\tools\unit\api.nice: line 50, column 22: getSourceLocation is not declared21:25
why doesn't it see getSourceLocation in nice.lang?21:26
Becouse I compiled console.jar without "--exclude-runtime" ?21:29
<bonniot>nice.lang is in stdlib/, if you are looking for the source
<ArtemGr>i now, i'm lookig why there is the error message mentioned21:30
<bonniot>what is your script at the moment?
oh, wait
this one changed names recently
maybe your compiled version has the old version?
<ArtemGr>It was "getSourceLocation__" and became "getSourceLocation"?21:31
<bonniot>upgrade to 0.9.10 ;-)
<ArtemGr>Is it possible to build 0.9.10 release using 0.9.10 prerelease? Should it be possible with my Ant script?21:33
<bonniot>it should be possible, but it's harder (a real bootstrap)21:34
i started to work on the visibility system21:46
<ArtemGr>great. i'm very interested in how that will develop.21:52
<bonniot>what aspect?
<ArtemGr>java intergration, protection of protected members (for reflection-based systems like Velocity) but their availability for extending classes, removal of public get_ set_ accessors at least for protected/private methods.21:54
err. fields21:55
<bonniot>ok. in the first step I'll concentrate on the pure-Nice aspects ;-)
<ArtemGr>do you have a plan? : )21:57
<bonniot>for java integration?
<ArtemGr>for that too
for how to implement visibility having multimethods and such21:58
<bonniot>I think the semantics for pure-Nice is about clear for me now
I think the visibility of a (multi-)method is what restricts how it can be called21:59
implementation/specialization should always be possible
<ArtemGr>but then it is ok if specializing class can't invoke the very method being specialized?22:00
<bonniot>why not?22:01
that's the point in not having the method public
<arjanb>what about calling of super methods?22:02
<ArtemGr>fair enough for me, just checking if i understood correctly
<bonniot>an implementation can always call super
<ArtemGr>what about protected, are you going to implement them?22:04
<bonniot>i don't see what it would mean
I guess one could find some definition. in the first step I don't see it as necessary. we can see from experience later22:06
<ArtemGr>say, method can access protected field if it's first argument is compatible with the class where the field belongs?22:07
<bonniot>yeah, possible for protected fields22:09
I was thinking about methods
<ArtemGr>i'm primarily concerned with fields. i think it is a bad practice to declare fields as private since i can't really extend the class functionality then. i have a lot of java libraries i had to patch only to change private fields to protected in order to reuse them by extending their classes...22:11
although i don't currently see why the same rule cannot be applied to access protected methods.22:12
<bonniot>with properties, you don't need to have so many private fields. doesn't that help?22:13
<ArtemGr>what do you mean by 'properties'?22:14
<bonniot>ability to replace a field by accessor methods without changing the client interface22:15
+ different get and set visibilities for fields22:17
<ArtemGr>well, if these 'properties' getters and setters are available to extending classes by default, then it's perfectly fine.22:19
<bonniot>yes, I would say they are
TDD is fun22:23
<ArtemGr>but, sincerely, i thought that 'private/protected/public' field modifiers and 'private/protected/public' get/set modifiers are overlapping each other. why not made all fields private, which seems to be better for performance, and control only get/set visibility? (i'm not proposing, just wondering)22:25
<bonniot>Test Driven Development
the whole point of properties is that you don't need both fields and getters/setters22:26
<ArtemGr>Where can i read about properties? I see them mentioned only casually in http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/VisibilityModifiers22:29
<bonniot>PropertySyntax I think22:30
<ArtemGr>so, will 'private' modifier be default and redundant when using 'rw' modifier?22:34
<bonniot>i think default would be package-read package-write22:36
private == private-read private-write
private-write -> package-read private-write22:37
public-read -> public-read package-write
this does not seems to be exactly on that page22:38
I'm sure i wrote it down
maybe to nice-info, or a private mail to martin
<ArtemGr>would be nice to have some 'protected' access by default, or at least using a modifier as it is in other languages, so that the field doesn't clatter public interface but still can be accessed from another packages by extending classed....22:41
<bonniot>there is an extensibility/security tradeoff to find here...22:43
<ArtemGr>the main programming problem is not security but reuse. after all, i can do almost anything with reflection by default. being from c++ world i happen not to believe in 'internal' program security at all. private properties where made primarily becouse of performance. Some say 'private' fields are required for 'encapsulation', but encapsulation is not the main goal of OO, the main goal is reuse. En22:54
d full "bulletproof" encapsulation is almost impossible to achieve in practice anyway, so encapsulation should be on a logical level, not on 'enforced' 'private' level, that's where 'protected' members are good for, to made a clean separation between interface and implementation and still allow extensibility. Having only public/private is forcing the programmer to blur that distinction by moving s
ome implementation details to 'public' level for some reusability/extensibility, and from practice it usually isn't achieving either goal - no encapsulation and no real extensibility.
i think it would help to design typical scenarios, to evaluate how different choices fare on them22:59
<ArtemGr>speaking of security, i think it is practical to have some "pragma" which modifies default behaviour for the current source file, then it is simple to made everything private (or protected, if privateness is not required)23:05
And 'properties' thingy seems to eleminates the performance issue of not using private fields, which might be a good advantage over Java.23:06
One example of successfull reuse is using RanabFtp to implement FTP server which works on virtual filesystem instead of a real one. RanabFtp design is good, i managed to implement virtual filesystems without changing RanabFtp itself - i only had to change a lot of 'private' fields to 'protected'.23:18
My 'extending' code is only 350 lines long, instead of 9500 lines of RanabFtp code (with GUI already cut).23:22
* zzorn_afk leaves23:29
<bonniot>I'm not sure if accessors are a performance issue, they can be inlined by the JIT23:35
ArtemGr: could you extract one or a few of those typical scenarios from that experience? on a Wiki page?23:37
<ArtemGr>it's much more complicated to inline protected methods then private ones, since protected method can be specialized by a dynamically loaded class. but i've spoke of fields, not methods. i remeber it was a popular performance recipe in the days of slow early java - to make everything private, so that access can be inlined. i think that fewer affected fields 'together' with methods.23:46
dynamically loaded and dynamically linked in case of native compilation23:47
<bonniot>yes, but I think these days JITs are smart enough to optimize things, and unoptimize when needed on class loading23:48
<ArtemGr>i can try to make a wiki page. what should be the name of it? VsPrivate ?
<bonniot>what I was thinking about could be ModularityScenarios23:49
it really depends on what you put there
anyway, don't be afraid when writing in the Dev section, it's not carved in stone ;-)23:50
i'll be here tomorrow noon/afternoon00:03
<ArtemGr>i've just compiled tools00:04
without first upgrading to the new version
i.e. the Ant bootstrapping works, getSourceLocation compiled ok
time to go for me too. bye.00:07
* ArtemGr leaves
<bonniot>arjanb: tomorrow?00:13
<arjanb>i'm away tomorrow00:15
now that 0.9.10 is out, do you have plans to work on something?00:17
<arjanb>if i get myself to it00:18
<bonniot>i think there are interesting times ahead. by starting to work on visibility, 1.0 suddenly seems more concrete ;-)00:24
<bonniot>ok, see you later. have a good Sunday!00:40
* bonniot leaves00:51
* arjanb leaves01:31