Search
Wednesday, 19th of September 2018, 23:14:06 UTC
23:14:52
drmeister
I wasn't convinced that it was the first argument rather than one of the other functions in the function list.
23:16:00
Bike
you mean like which argument to multiple-value-funcall?
23:16:42
drmeister
Yes - the result of coercing the function-designator or one of the functions in functions.
23:23:37
Bike
well, that it's one of the thunks, at least
23:33:15
drmeister
I changed it to this:
23:33:16
drmeister
https://www.irccloud.com/pastebin/SELoKx5a/
23:33:34
drmeister
https://www.irccloud.com/pastebin/0LSjT4NB/
23:34:23
Bike
so it's not a thunk, it's the generic function that's bunk?
23:34:35
drmeister
That's a weird cast - I'll change that.
23:36:04
drmeister
And I'll check fmv - a standard-generic-function can be a function designator - right? Of course it can.
23:36:20
Bike
a standard generic function is a function, and functions designate themselves, yeah
23:40:47
drmeister
Right now I'm not sure water is wet.
0:32:00
drmeister
Poof - the problem vanished.
0:32:07
drmeister
I'm investigating.
0:34:24
drmeister
I took out this: Closure_sp testClosure = fmv.asOrNull<Closure_O>();
0:34:37
drmeister
Oh - wait - how did that ever work.
0:35:01
drmeister
This is a generic function - it can't be cast to a Closure_sp
0:37:25
drmeister
Generic functions are instances of FuncallableInstance_O - that inherits from Function_O
0:37:55
drmeister
Is this the first time we have ever called a generic function this way?
0:38:12
Bike
it's possible. multiple-value-call with more than one argument is uncommon.
0:38:42
Bike
since we're just calling it, we only need a Function_sp, right?
1:04:55
drmeister
I think we only need a Function_sp
1:05:17
drmeister
We should check every call to coerce::functionDesignator and make sure we aren't coercing the result to a Closure_sp
1:05:38
drmeister
ptr.asOrNull<something>() is considered harmful.
1:05:48
drmeister
Especially when I don't check the return value.
1:05:57
Bike
we're pretty harmed, then
1:06:29
Bike
because we do that a lot
1:06:40
drmeister
I almost always use it for its intended purpose: if ( Something_sp = foo.asOrNull<Something_O>()) {...}
1:07:06
drmeister
Sorry: if ( Something_sp bar = foo.asOrNull<Something_O>()) {...}
1:25:26
drmeister
I did a survey of every use of asOrNull and there were only half a dozen outside of if expressions.
1:25:42
drmeister
Three had problems with no checking the return value - I fixed those.
1:25:51
drmeister
We should be fine wrt that now.
1:26:25
Bike
guess i'm pessimistic then
2:43:35
drmeister
[55 of 434] - that's good - I think it still needs some work to improve the compiler performance - were there improvements still to be made?
2:56:40
drmeister
Now that it appears to be building I'm going to try a little profiling.
3:00:14
drmeister
Is outside-in vs inside-out inlining part of the discussion anymore?
3:11:49
drmeister
It's chugging away [99 of 434]
3:12:43
drmeister
I set the CST feature in the buildbot build - so I'll get a better time from that.
3:14:17
drmeister
Like this is problematic:
3:14:19
drmeister
https://www.irccloud.com/pastebin/rtvShgvy/
3:15:22
drmeister
19.3 min to compile shiftf-rotatef.lsp (2%) llvm time - that's pathological.
3:16:01
drmeister
If we can do better - we should - especially while this stuff is fresh in your head.
3:17:47
drmeister
shiftf-rotatef.lsp https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/lsp/shiftf-rotatef.lsp#L41
3:18:02
drmeister
It contains two defmacro's - do we need fast macros?
3:38:13
Bike
it's probably slow partly because it evaluates while compiling which means compiling while compiling
4:06:45
Bike
drmeister: oh, and did you use a newer sicl?
5:27:33
beach
Good morning everyone!
Thursday, 20th of September 2018, 11:14:06 UTC