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

Using timezone: Central European Time
* arjanb leaves01:25
* Gummi_log_ joins02:15
* Leblin joins03:37
* Leblin joins03:37
* Leblin leaves
* Leblin leaves
* Gummi_log leaves09:13
* GummiEnte joins09:18
* GummiEnte leaves09:19
* arjanb joins11:58
* GummiEnte joins16:09
<GummiEnte>Did you already have fixed some bugs :-)16:10
<arjanb>no only found 1 more16:11
<arjanb>and now i'm working on instanceof
<arjanb>but i'm getting a compile error that i can't reproduce in a testcase
<GummiEnte>Why is it possible to define a non-null variable at function level without giving an initial value?16:12
<GummiEnte>simply something like:
void function_x() {
FOO f;16:13
I#'ll return in a second.16:14
* GummiEnte leaves
* GummiEnte joins16:15
<arjanb> String s;
if (condition) s = "abc";
else s = "xyz"
<GummiEnte>Yes, that what I'm also using this for.16:16
But, should'nt I then be forced to use ?String?! Or be forced to set use String s = (condition) ? "abc" : "xyz";16:17
<arjanb>no why?
<GummiEnte>So, in a function it isn't needed to set a value for a non-null value, but for a class variable it is?...16:18
<arjanb>yes because local variable can be checked whether they are initialized before use
<GummiEnte>Ah, Ok.16:19
Since using nice, my view to such things becomes sharper and sharper.16:23
Don't know why...
<arjanb>same here16:24
and i do understand java much better now
<GummiEnte>You're a compiler developer, so you will have a better understanding than many others... :)16:25
What about the following warning:
warning - cannot convert literal (of type gnu.mapping.Values) to FOO
<arjanb>that warning happens when compiling nicec as long as i know16:27
it comes out one of kawa lib no idea what it means or is caused by16:28
<GummiEnte>Well, it seems so, as if it has to do with nested try-catch clauses...16:32
...but I cannot reproduce it.
<arjanb>maybe it's just a trivial bug in the kawa lib16:33
<GummiEnte>well, I fell more comfortable with less warnings.16:34
<arjanb>i will ask daniel about it16:35
<arjanb>about cast's and notNull do you know how to retype java methods?16:47
the quote in the first chapter of the manual:16:56
language that doesn't affect the way you think about programming, is not worth knowing.
--Alan J. Perlis
<GummiEnte>What do you want to retype in java?17:11
<arjanb>i mean do you using retypings?17:12
<GummiEnte>I#m not quite sure what retyoing exactly does mean at the moment.17:15
<arjanb>declaration in the form of ... = native ...
<GummiEnte>Ah, I'm not using that. How to use that, for what purpose I may need it.17:16
<arjanb>using them you can give java methods the preciser nice types17:17
it's mentioned shortly in the manual
<GummiEnte>Can you make short example?17:18
<arjanb>in stdlib\nice\lang\java.nice are many examples17:19
<GummiEnte>I've also found the example in the manual.17:20
it says: String getName(MyJavaClass) = native String MyJavaClass.getName();
can I also do something like: String getXYZName(MyJavaClass) = native String MyJavaClass.getName();17:21
<GummiEnte>So, I can create aliases for functions..?
<arjanb>not aliases but you can rename java methods
<GummiEnte>Ok, what about the following:17:23
String getName(MyJavaClass) = native String AnotherClass.getName();17:24
That does not work, right?!
<GummiEnte>Ok, than I have a idea of what I could do with it,...17:26
<arjanb>if you can give a case where you use notnull or cast when calling a java method i can help17:27
<GummiEnte>Well, maybe you find a much better solution for the following:17:32
<Any T, Any U> void foreach(HashMap<T,U> m, (T, U) -> void f) {
Iterator<T> ks = m.keySet().iterator();
T key;
U value;
while (ks.hasNext()) {
key = ks.next();
value = notNull(m.get(key)); // notNull because we got the key17:33
(f)(key, value);
<arjanb>well that's another kind of problem but i can try17:35
foreach was defined for collections but not for maps.17:37
...is defined...
Or has something changed?
<arjanb>no but it's good suggestion
<GummiEnte>It's needed, but I assume, my implemenation is not the best.17:38
maybe another really not null check or at least a concurrend change check...
<arjanb>ok here is the foreach:17:43
<K,V> void foreach(Map<K,V> map, (K,V)->void fun)
for (Map.Entry<K,V> entry : map.entrySet())
fun(entry.getKey(), entry.getValue());
<arjanb>but do you have another case where you could use an retyping17:54
<GummiEnte>Well, not that I acutually have an idea of.17:56
There seems to be a function defined MAX_INT()... but no MIN_INT()!?!17:57
<arjanb>hmm odd
at the moment the compiler makes it easy to call java methods without retypings17:58
<GummiEnte>Yes, that's true.17:59
<arjanb>but if you turn -strict option on you will notice the method that should be retyped
<GummiEnte>So, that might be the point, why I didn't encountered it neccessary...
nicec --strict?
<GummiEnte>Uups... a few things I encounterd...18:05
wil return shortly
* GummiEnte leaves
* GummiEnte joins18:08
<arjanb>did you try --strict?18:16
<GummiEnte>From nice I'm using not that many java, but for one of the calls, it was sad while using --strict...18:24
<arjanb>can you show the call?
<GummiEnte>~/Work/WorkingDirectory/e3m/src/com/condor_edv/e3m/celleval/celleval.nice: line 582, column 63:18:25
Arguments (?com.condor_edv.e3m.celleval.ECell) do not fit:
?com.condor_edv.e3m.celleval.Expression getExpression(com.condor_edv.e3m.celleval.ECell)
?Expression ee = this._teh.getECell(a.column, a.row, this._z).getExpression();18:26
class ECell is a java class.18:27
_teh is a java interface...18:28
<arjanb>so method getECell isn't precise enough typed
can that method return null?
<GummiEnte>ECell getECell(int x, int y, int z) throws NoSuchMemberException;18:29
So, it can.
<arjanb>no an exception isn't a normal return18:30
<GummiEnte>Yes, true. But normally it should throoww an exeption instead of an null (so defined in my api)...
<arjanb>ok so now the retyping18:31
<GummiEnte>...cause there should be for every point a ECell.
<arjanb>ECell getECell(YourInterface, int, int, int) = native ECell YourInterFace.getECell(int, int, int);18:33
<GummiEnte>That worked, but now there are many more errors...18:35
<arjanb>that's possible18:36
and that's why --strict is turned off by default18:37
<GummiEnte>I see.
As long as the compiler assuptions are correct...18:38
<arjanb>no they aren't always
<GummiEnte>Should that alarm me?18:39
<arjanb>without --strict the assumptions are no null in return types and maybe null in argument types
<GummiEnte>Yes, that are some of my errors.18:40
<arjanb>it might be useful for you to use --strict and do retypings so you can say which arguments and returntype might be null or not18:43
but it's quite a lot work
<arjanb>it's up to you to determine if it's worth the effort18:46
<GummiEnte>So, I first need estimation how "unsafe" the compilers assumptions are.18:48
<arjanb>first you could look at which java methods you use that may return null18:50
<GummiEnte>That are less...
...less methods that I use and return null. If I know that, I'm using ?...18:51
<arjanb>yes but it's only about java methods
<GummiEnte>So, you mean, that it is worth to do so...18:54
<arjanb>for a large program or some code that won't change much\fast i think it's worth it18:56
<GummiEnte>...so, I'll do so... I'll ask you some questions if I encounter some miraclels... 18:57
for today I'll leave it like it is, cause I will close for today...
...so, we'll see us tomorrow...18:58
...have a good night..
<arjanb>cu tomorrow
* GummiEnte leaves
* bonniot joins20:07
i have improved the type inference by instanceof20:09
<bonniot>inside while?20:10
<arjanb>yes and with else and && || !
will commit it in a few minutes20:11
<bonniot>i'm testing a final fix for the super issue20:12
when did you modify ReturnStmt?20:14
<arjanb>last week
some nicei printing issue20:15
<bonniot>i don't see the testcase for it20:19
<arjanb>not one for the loops?
<bonniot>that does not have return20:20
<arjanb>i noticed that some statements did print the ; and others not20:21
so i made that consequent20:22
<bonniot>normally, if you do such a change, you should try to add testcases too, if it's possible20:24
in this case it's not a big problem, because I think in the long term it would be better not to have code in nicei files20:25
i have commited the instanceof type inference changes20:28
do you read the irc logs?20:32
<bonniot>not recently20:34
<arjanb>not important but many little things are discussed and i might forget to tell you about some of them20:40
GummiEnte: the anonymous cvs has an delay of less than 24 hours again20:52
daniel what do you think of literal maps?20:57
<bonniot>i would think it is better as a library, not in the core language21:07
<arjanb>as library the you would get something like21:12
[("abc", 5), ("def", 3), ("xyz" ,8)].toMap()
["abc": 5, "def": 3, "xyz": 8]
<bonniot>that does not look too bad, does it?21:15
<arjanb>no so i don't feel strongly about it21:17
are you up to date with the cvs tree now?21:18
<bonniot>was this syntax requested?
almost up to date
<arjanb>no i have seen it elsewhere
<bonniot>it could be good to add it to the stdlib, with a good nicedoc comment21:21
maybe call the method 'map'
<arjanb>yes various methods for tuples are missing in the stdlib21:22
but there are a few problem with tuples as the second open bug in the tracker21:24
i have a fix for the bug case with instanceof that i committed yesterday21:57
have you made changes to typecheck.nice?
did you look at the problem with accessing static fields of an interface from a subtype?22:17
can you reach cvs tree at the moment?22:26
are you there?22:31
cvs still doesn't work :(22:54
it works again23:17
but slowly
<bonniot>don't worry about the changes I might make. cvs will signal the conflicts if necessary23:24
so you can commit your fix if it is ready
i saw the testcase for the static fields
it does not seems urgent, since it is very easy to use the interface name instead23:25
but if Java behaves like this, i agree we could implement this too
<arjanb>java does it23:27
i committed the fix23:28
Christian asked today what causes warnings like: warning - cannot convert literal (of type gnu.mapping.Values) to java.lang.String23:30
i have no idea either23:31
that warning i get during compiling nicec as long as i know23:34
i think Isaac has a good point with integer overflow in java23:46
one thing that could be done easily is range checks on narrowing conversion23:47
<bonniot>wdym exactly?00:23
<arjanb>for example make byte(...) check it's argument to be between -128 and 12700:24
<bonniot>there could be two versions: byte(...) and checkByte(...)00:32
<arjanb>yes but then i would like checked as default00:34
i think there no need for an unchecked one01:00
because it's the same as byte(... & 0xFF)01:02
does the fix of super work now?01:04
<bonniot>there would be no default: there would be two different functions01:10
byte(x & OxFF) is not pretty to write anyway, so one might as well declare two functions
<arjanb>yes but the name of checked one just byte(...)
<bonniot>and the other?01:11
<arjanb>no idea yet01:12
<bonniot>i have a possible fix, but it does not recognize anymore the ambiguity in:01:14
void f(A);
f(x) {}
f(x@A) {}
<arjanb>isn't it possible to use different comparison rules for dispatch testing and super method finding01:16
good night01:47
<bonniot>that would be inelegant, and there should be no need for such complication01:59