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

Using timezone: Central European Time
<bonniot>dice? what for?03:25
<arjanb>for making a choice03:27
well this isn't getting anywhere so what's the best temporarily solution?03:28
i think option 1 would break the least code if making another choice later03:31
<bonniot>the solution is clear to me. and I think luc agreed
<arjanb>ok that would be a change to your code..03:34
<bonniot>good night
you close the bugreport?03:37
<bonniot>i will when the dev version is updated03:46
it seems it is not building atm
<arjanb>since 22 nov or is it a new problem?03:48
<bonniot>since then
* bonniot leaves03:52
* zzorn_afk leaves03:54
* lucp leaves04:22
* arjanb leaves05:33
* Vurlix joins09:27
* Vurlix leaves11:58
* swarm joins12:29
* swarm leaves13:01
* bonniot joins13:48
* zzorn joins15:16
* arjanb joins15:26
afaik only 2 bugs found since previous release aren't solved yet15:41
that is maybe type overrides and constructor retypings causing problems accessing static methods/fields15:42
<bonniot>what is the second?15:51
<arjanb> String str = String.valueOf(true);15:54
String String(char[]) = native new String(char[]);
D:\Nice\testbug\test.nice: line 6, column 23:
Method valueOf expects parameters (T)
it looks like the class name gets in the varscope somehow15:56
a workaround is to rename the static method/field in a retyping16:04
<bonniot>it's not the class name, it's the method name16:11
that looks normal
'String' becomes a value16:12
<arjanb>i don't think a retyped constructor should become a method too16:17
<bonniot>there should be a different syntax then16:18
new String(char[]) = native ...;16:19
actually the return type needs to be specified
(useful for generic classes)
String new String(char[]) = native ...;16:20
alternatively, the method name could be simply ignored, that's just strange
<arjanb>or the overloading resolution could be made smarter so no conflict with static methods can happen16:22
<bonniot>i don't think this warrants complicating OR
rather not put the method in the global namespace16:23
<bonniot>is it a concrete problem at the moment?
<arjanb>adding a new kind of retyping for this is a bit too much i think16:26
i found it while converting but there's a workaround
<bonniot>there are simpler workarounds:16:29
1) use any different name in the retyping
2) use java.lang.String.valueOf(...)
i see it's flow4j blocking the dev version16:31
<arjanb>so it's not an urgent thing but it can easily fixed if you know where16:32
<bonniot>you saw it too?16:33
<arjanb>no i was typing slow16:34
<arjanb>it was a reponse to previous sentence16:35
keeping flow4j up to date doesn't make much sense anymore16:36
<bonniot>it's a real size testcase16:38
ok, I updated flow4j, the next pass should succeed17:01
<arjanb>did you find a testcase for reaching monotypeconstructor.substitute() ?17:08
<bonniot>didn't look at that yet17:12
trying now17:20
* lucp joins17:42
<arjanb>good morning17:43
<lucp>hi. thank you
<bonniot>hi luc17:44
arjanb: it's not true that only strings are used as keys. see niceclass.nice:43117:45
<arjanb>that's a substitute on AtomicConstraint and not the Monotype one17:47
<bonniot>right. then NiceMethod.java:12017:50
here's a testcase that exercises that situation:
class A
alike foo(List<String> bar) {}
<arjanb>well that's an unique id object, it could easily made an unique string17:51
<bonniot>is this substitute used with something else than alike?17:58
*away for dinner
<lucp>*away for breakfast.18:11
<CIA-3>03bonniot * 10Nice/testsuite/compiler/typing/alike.testsuite: 18:37
Additional testcase for alike, exercising substitution on constructed
<arjanb>so the current code is correct?18:46
<bonniot>well, it looks like the TC does not need to be substituted at all, atm18:50
so that part could be removed
<arjanb>will do18:52
thanks for finding out18:55
<bonniot>arjanb: np :-)19:02
<arjanb>sometimes i'm a little annoyed by my brain not cooperating in finding the way in the code19:05
<lucp>you need to upgrade it to a new model!19:06
how is your code going?
<lucp>a lot of work... but its getting there
is there a way to convert ?type[] to type[] without casting?19:11
<arjanb>depends on where the ?type[] comes from19:12
<bonniot>lucp: why do you want to do that? in general it's unsafe19:14
<lucp>Well, from my experience, you cannot instantiate an array as a non option type.. once you have filled your array with non null values, is there a way to change it without casting?19:16
<CIA-3>03arjanb * 10Nice/src/bossa/syntax/ (monotype.nice tools.nice): Changed to String key in the Monotype.substitute Map.19:18
<arjanb>if an array is filled right away i usually cast them at creation19:27
<bonniot>lucp: use new A[x].fill(int i => ...)19:48
(if you can ;-)19:50
<arjanb>now i have converted typeident, methods with first argument typeident doesn't get found..19:53
somehow they don't get into the dispatch class..19:56
it only seems to happen with methods defined in nice with only a defaultimplementation and having the first argument a class in nice20:01
i guess it's a leftover from the time there was a distinction between methods and functions20:03
calling them on fun instead of dispatch does fix the problem20:07
it would be more convenient if all methods were in dispatch20:08
<CIA-3>03arjanb * 10Nice/src/bossa/ (14 files in 2 dirs): Converted TypeIdent.20:41
<bonniot>arjanb: aren't the methods inside the class?20:46
now as many methods as possible are inside classes, not in dispatch20:47
<arjanb>yes they are in the TypeIdent class too20:48
<bonniot>the real method is _only_ there. in fun you have only implementations20:49
<arjanb>but it's little odd to have methods like createNewExp and createPattern inside TypeIdent
<bonniot>bc the first arg is a TypeIdent?21:03
<lucp>What is the behavior of for( Type t : list ) if list may be null, or is null? is the loop skipped, or is it a compiler error?21:06
<arjanb>compile error afaik
i have some code that causes a classcastexception at runtime but i can't look at the generated code because disassemblers crash22:12
hmm it doesn't happen anymore, no desire to figure out..22:40
<bonniot>arjanb: which disassembler do you use?22:59
is it really a disassembler, or a decompiler?
<arjanb>javap -c -classpath F:\nice\classes bossa.syntax.fun23:03
Exception in thread "main" java.lang.NullPointerException
at sun.tools.java.Environment.error(Environment.java:854)
at sun.tools.java.Environment.error(Environment.java:857)
at sun.tools.java.MemberDefinition.reportError(MemberDefinition.java:479)
<bonniot>shame on Sun...23:04
<CIA-3>03arjanb * 10Nice/src/bossa/ (5 files in 2 dirs): Converted Alike.23:05
<bonniot>i often use jcf-dump from gcc
<arjanb>i tried another tool called dis but that crashed23:06
* lucp leaves
<arjanb>src\bossa\modules\Package.java:291: cannot access bossa.link.Dispatch23:58
bad class file: classes\bossa\link\Dispatch.class
class file contains wrong class: bossa.link.dispatch
Please remove or make sure it appears in the correct subdirectory of the classpath.
oh it's probably interference with the nice generated dispatch class00:01
i have converted sourcealternative00:02
<bonniot>it looks like a case insensitivity problem on windows00:11
<arjanb>right so we need to rename bossa.link.Dispatch00:12
to DispatchTest or something00:13
<CIA-3>03arjanb * 10Nice/src/bossa/ (5 files in 2 dirs): Converted SourceAlternative.01:03
03arjanb * 10Nice/testsuite/compiler/methods/implementations.testsuite: removed ambigious fail here marker.01:10
03arjanb * 10Nice/src/bossa/ (7 files in 3 dirs): Renamed bossa.link.Dispatch to DispatchTest.01:28
<arjanb>cvs is strange01:30
why remove the failure marker?
<arjanb>during commit:
cvs update: warning: DispatchTest.java was lost
Checking out DispatchTest.java
RCS: /cvsroot/nice/Nice/src/bossa/link/DispatchTest.java,v
VERS: 1.1
the failure can happen in 2 places01:34
about cvs: are you working in a CVS checkout now?
<arjanb>on a copy of a checkout
<bonniot>that might be the reason01:38
<arjanb>i have replaced dozens file that way and never saw this before01:39
<bonniot>is it really during commit that it says "cvs update" ???01:40
<bonniot>are you using a special tool above cvs?
<bonniot>and how do you commit back your changes, since they are not in a checkout?01:41
<arjanb>just giving the full path and cvs figures out the rest using the CVS dirs01:44
<bonniot>so your copy also has the CVS dirs?01:45
but i think the server side caused it since CIA had an half hour delay on 'Converted SourceAlternative'01:46
<bonniot>then how is it different from a direct cvs checkout
<arjanb>ehm maybe no difference?01:48
<bonniot>it sounds fine. what you told me earlier is that your worked on a copy, then manually copied back your changes to the checkout. which made it possible to overwrite something that had changed, and commit it back to its previous state (which happened once)01:50
so you changed your system?
<bonniot>you remember?
<arjanb>i remember something went wrong but not how or what01:52
<bonniot>so you don't do what I said at 01:50?01:53
you commit from the copy? and update the master too then?01:54
i guess i was confused previously01:55
* arjanb makes no sense to others too often :(01:59
that's when the pb happened
but it seems the discussion about cvs must have been before
that's it
<arjanb>i see02:06
<bonniot>it seems you were not using cvs update02:08
can you have multiple build trees now?02:09
<arjanb>i don't use cvs update on the working copy02:10
yes if modifying the build batch file02:11
<bonniot>if you don't update the working copy, and cvs head has changed, then you cannot commit from your working copy02:12
<bonniot>so what do you do then?02:17
you should just do cvs update, nothing problematic with that02:18
<bonniot>good. i really don't want to see code lost by accident02:25
if there were changes at the same place, then you'll get a conflict, but that's really a good thing since you can then analyse what happened and find out to merge the changes together02:26
<arjanb>i don't feel convenient with cvs updating into my changes so i need an additional tree then
<bonniot>you cannot avoid merging the upstream changes with yours02:32
cvs nevers deletes your changes during the merge, so there is no risk02:33
if you do it by hand there is a risk
you can always make a copy of your tree before the update if the reinsures you, but you must use cvs update to do the merge02:34
<arjanb>i understand
<bonniot>you have never seen a merge conflict?02:35
<bonniot>you should check the CVS manual, there must be a section about it
as more people participate, this will become more important02:37
<bonniot>good night02:39
<arjanb>good night
* bonniot leaves02:40
* ChanServ leaves02:55
* ChanServ joins02:56