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

* Leblin joins04:47
Hello log, I see the developpers are not here. I'll try again later!04:56
* Leblin leaves
* arjanb joins08:57
* bonniot joins09:08
hello arjan
<arjanb>hello daniel09:10
<bonniot>had a good week-end?09:11
i see the american timezone has problems finding us here09:15
<bonniot>yes, that makes sense :-(
how do you know the timezone?09:17
<arjanb>just a guess
<bonniot>did you get the nice-commit email about my changes for bytecode constructors?09:18
<arjanb>only the one of the change in the changelog09:19
<bonniot>hum, so there was another hic-up...09:20
but it's implemented, anyway :-)
should be helpful for alex
<arjanb>have seen that error message in nice-info mail?09:22
<bonniot>yes, i'm writing a complement answer09:23
<arjanb>you can correct the retyping i forgot it should be non-null09:24
<bonniot>what should be non-null?09:27
<arjanb>the argument of the constructor see the java code
you should do it, and say it shows how nice is safer: with this retyping, you guarantee that the null pointer will never be raised :-)09:30
<arjanb>you get the same error message when you make a mistake on the right side of the retyping :-(09:33
<bonniot>don't you get an error message for the wrong retyping?09:35
<arjanb>how do you mean?09:36
<bonniot>if I write:
... = native new SingletonSet(ObjectFoo);
i get an error message
Unknown java class ObjectFoo
for ... = native new SingletonSet(String);09:37
i get : Method <init> was not found in class test.SingletonSet
so mistakes on the right side of the retyping seem well handled to me09:38
<arjanb>no the second one should say something like that no method was found with that type09:39
<bonniot>that's what is says. OK, it could be more precise, and speak about the types.09:40
but i don't understand why you said the you get the same error message
<arjanb>i hope it's possible to give different error message when the method name is wrong and when the types are wrong
<bonniot>sure it's possible09:41
what mistkae did you do on the right side?
and what error message did you get?
<arjanb>same a you
i meant to say that error message has the same imprecision09:42
what are your plans now?10:12
<arjanb>improving these error message and further things depend on how far you are for 0.9.010:13
<bonniot>what are the further things?10:14
you can always work on them, and only commit when they are ready
i don't plan to release very soon anyway
<arjanb>enums visibility-modifiers cleanup of parser 10:15
so you still have problems with the gnu.bytecode parts?
<bonniot>i just didn't have time to look at it10:16
i worked on the constructor thing, which was needed urgently
<arjanb>i see
i think it's useful to do a release more than once a month10:18
<bonniot>maybe for you visibility should be the priority, since having it can help in the design of other things (see how we discuss it about constructors, for instance)
why do you?10:19
there are new development versions quite often, for those who want the latest version, or to try if a bug has already been fixed10:20
<arjanb>because in the vacation people have hopefully more time to try nice and not everyone will download the development version
<bonniot>sure, but they can try 0.8 too10:21
for a new release, there must be a good set of new features, and they should be documented well enough (otherwise, how can people try them?)10:22
<bonniot>for instance, i will update the manual about the bytecode constructors
do you feel like working on the visibility?10:24
<arjanb>yes and i think the best is to implement visibility gradually so we end up with a good balance between making all restriction possible and being too restrictive10:26
<bonniot>so what would you start with?10:27
<arjanb>visibility for classes thus constructors
<bonniot>hum, this is not completely well-defined yet10:29
partly because constructors are still being designed at the moment10:30
a better defined area is fields
<arjanb>and so are fields which depends on making them properties
the only easy one are the global/package constants/varibles10:31
<bonniot>true, the implementations of fields can change, but i think the visibility feature will not
yes, that's true about globals
as i said before, i would like a generic implementation of visibility, to keep the core compiler small. then a first step could be to use it for globals10:32
and the library should include unit tests too :-))10:33
<arjanb>the library should handle the java visibility things like 'protected' too, right?10:37
<bonniot>not sure10:38
it should handle nested scopes, probably an unlimited number10:39
in Nice we would use two levels of nesting (package and file)
i don't think it should handle 'protected' especially10:40
but if there is a custom mechanism, that can be used in particular to implement protected, why not
it's not a priority. it should not complicate the library10:41
<arjanb>I didn't think of visibility as nested scopes yet10:42
<bonniot>it's just one view on it
you could also view it as a global table, with tags attached to each symbol, telling who is allowed to see it10:43
maybe that's actually better
more general. it can also help, if you want to report errors like:10:44
foo is defined in package bar, but it is not public
<arjanb>yes maybe can error reporting be a part of the library10:46
<bonniot>well, it should not format strings or anything like that, because different clients might want to do it differently10:47
but there can be objects (exceptions?) to report precisely the results in an high-level form10:48
<arjanb>in general it might be a good idea to move error message generation out of the code of the core compiler10:50
<bonniot>sure. there is already UserError, so the hamdling can be made out of the core10:52
that could be made more abstract, as we rewrite parts10:53
<arjanb>when the error message get more precise the normal code get more cluttered so i want to write the errors as 10:55
if (somecondition) reportSomeKindOfError(... , ...);10:56
<bonniot>yes. that can already be made by writing a subclass of UserError, and let it do the formatting10:58
but sometimes, to write a very precise error message, you need information from the context10:59
you can also pass it to the class, i guess, and then it can call some methods if needed to compute the error message
<arjanb>daniel did you generate this page? when you update it again could you remove my email address?12:58
* htpxffrkutp joins
* htpxffrkutp leaves
* alexgreif joins13:31
<alexgreif> Im in a mmeting, so the most time I'm a lurker :)13:36
<arjanb>daniel what do you think of giving a warning when a java method is ignored?14:22
<bonniot>this is not a good option at the moment, because there are tons of methods ignored14:25
it would be useful to tell it when there is an attempt to use the method. but i don't see you can know if the method is being used, since that requires to check the types, and ignoring is done precisely because the types are not valid14:27
<arjanb>can't the ignored method be given the most general type?14:32
and when only the ignored method matches for something then report such an error14:34
<bonniot>if you give a too general type, the risk is to report this too often, when it does not applies14:38
you would also need to ignore them in normal operation
so this would be non-trivial to do
maybe it can be worth looking at later, but for now it seems too complex for what it's worth14:39
* alexgreif leaves17:02
* arjanb leaves17:52
* bonniot leaves18:47
* arjanb joins18:56
* arjanb leaves20:20
* arjanb joins22:57
* arjanb leaves23:10