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

Using timezone: Central European Time
* magnus-- leaves01:52
<arjanb>did nothing on line numbers :(02:37
good night02:42
* arjanb leaves
* bonniot leaves03:27
* bonniot joins10:19
* magnus-- joins13:14
* arjanb joins
<bonniot>hi15:10
what is alwaysAssert used for atm?15:11
it would be useful to have such a feature
i'm not sure what would be the best syntax15:12
<arjanb>it's used in pre/postcondintions so the check that assert are on is done once15:13
<bonniot>ok15:14
we can use alwaysAssert(...) at the moment15:15
any other syntax idea?
<arjanb>the word assert suggests that it's executed always i think15:17
what about "assume" for the version that can be turned off15:19
<bonniot>i agree assert is stronger than assume15:21
otoh assume sounds a bit fuzzy
and this would go against the widely known behaviour of assert15:22
it could also be check / assert
<arjanb>the meaning of assert has been weakened in prog langs by performance reasons15:25
<bonniot>well, actually it makes sense:15:27
Assert: 1. To affirm; to declare with assurance, or plainly and
strongly; to state positively;
to assert is to declare that something is true, and to check is to actualy verify that it is the case
<arjanb>and how differ between the 2 in pre/post-conditions?15:28
<bonniot>i'm not sure we need to15:29
there can be a property to setup if you want to run them or not15:30
but contracts should not have side effects, so it does not matter in the source
the reason I needed check is:
check(file.renameTo(file2));
the operation has a side effect, and I want to fail if it returns false15:31
otherwise i need:
let ok = file.renameTo(file2);
assert ok;
hum, it's not the same behaviour15:32
but that might be OK15:33
i don't see a reason not to want to fail if you know there is a bug
while there is a reason not to execute asserts under certain conditions (performance)15:34
<arjanb>check could be just a function in stdlib15:35
<bonniot>yes, i don't think we should introduce a keyword15:36
<arjanb>agreed
<bonniot>but it cannot be pure nice if you want a string argument computed only when needed
check(foo(), message: "...")15:37
<arjanb>lazy evaluated argument can be added to nice (sometime)15:39
<bonniot>sure. would need syntactic sugar only if we use closures15:41
but check is exactly like alwaysAssert, no?
<arjanb>yes15:42
* bonniot is away: send me a private message if needed17:34
* CIA-3 leaves18:33
* CIA-3 joins18:34
* CIA-3 leaves
* CIA-3 joins
* bonniot is back (gone 04:09:58)21:44
<arjanb>latest bug report looks like an infinite loop in Satisfier.enumerate but i have no idea what causes it21:47
<bonniot>are you sure it's an infinite loop?22:03
at the look at the case, I would think that it might generate a very high number of cases to test, not infinite
<arjanb>i gave up running after 10 minutes
<bonniot>ok22:04
don't worry about it22:05
<arjanb>not infinite after all22:34
~20 mins is a bit worrisome for 10 lines of code22:44
<bonniot>yes :-)23:01
it's a worst case (like the ML program that takes an exponential time to typecheck)23:02
<arjanb>but this case is likely to happen in some real programs23:03
<bonniot>not sure23:04
it's quite rare to have
<T,U> void m6(T i, U j){}
for one
that is a method that takes two arbitrary and independent types of arguments23:05
and then dispatching once only in the fist arg, once only on the second...
<arjanb>a possible optimization is to split independent parts of the domain to generate the alternatives and combine it at the end?23:10
<bonniot>how do you find independent parts?23:13
<arjanb>no constraint relation between the argument types23:14
<bonniot>it's when you combine that the list will become huge. i don't think this would gain23:22
<arjanb>that list contains all classes right?23:23
<bonniot>for one param, yes23:24
<arjanb>combining such a list with itself would be much faster than it is now23:26
<bonniot>is it the generation that takes time? or the checking afterwards?23:28
<arjanb>i think the generation23:30
<bonniot>you think?23:32
<arjanb>with profiler after 10 mins i saw only generation part of the code23:33
<bonniot>ok23:35
doesn't the profiler slow down execution a lot?
which one is it?23:36
<arjanb>java -Xprof
it slowdown but only a little
it looks at which method it is executing every 10ms23:38
<bonniot>it is probably optimizable, but it might be tricky to get it correct, and i don't think it's a priority23:49
<arjanb>true00:00
it's at least more than 95% for generation part
<CIA-3>03bonniot * 10Nice/src/bossa/syntax/analyse.nice: 00:52
Fix misleading message: there might be a method with that name but a different
number of arguments.
<bonniot>is there a pb with generating the try/catch?00:59
<arjanb>only that i don't get started01:00
* magnus-- leaves01:02
<bonniot>are you afraid it would be hard?01:03
<arjanb>no just no motivation atm01:10
<bonniot>isn't 0.9.6 motivating? ;-)01:14
<arjanb>no i look more at 1.001:16
<bonniot>well, that's a step :-)
<arjanb>i have inactive periods sometimes but no idea why01:23