Search
Wednesday, 19th of September 2018, 17:16:00 UTC
17:16:29
drmeister
The source-position generic function now takes the lambda list (client stream) and the method that we define in translate.lisp thinks it takes (stream client)
17:20:59
drmeister
Yes - I reversed the arguments and now it compiles.
17:21:06
Bike
yeah, so we got the parameters wrong so our method was never used
17:21:32
drmeister
Never ever? Or did eclector change the order?
17:21:50
Bike
"never" as in "since this problem started happening"
17:23:03
drmeister
I just pushed the fix - can you verify that it works?
17:44:30
Bike
that seems to have done it. gees.
17:47:11
Bike
seems slower than it was, though. maybe i have some messed up commits
17:47:55
Bike
yes. right,i didn't upgrade sicl. i'll do that then
17:54:45
beach
When he moved it from one package to another, he also changed the order.
17:57:14
Bike
i'll also do the subclass thing while we're at it
19:24:41
Bike
it gets to loop-read-and-compile-forms, then within a few anonymous funcalls it hits another bad access
19:24:45
Bike
while doing a c11 atomic load,i guess
20:06:22
drmeister
Do you need me to take a look at it?
20:06:30
drmeister
I just got done talking to some folks.
20:09:12
Bike
well i'm not surehow to proceed
20:09:31
Bike
the frame source info isn't any more specific, so i'm not even sure what function it is in
20:09:36
drmeister
Is it a particular form that causes the problem?
20:10:08
Bike
from the backtraces, it's in loop-read-and-compile-forms, and that's about all i got
20:12:44
drmeister
Do you have the problem up there? Otherwise - I just started a build.
20:27:06
drmeister
Which file did it fail on?
21:14:55
drmeister
It looks like its trying to call a function with a bad entry point
21:18:36
drmeister
It looks like it's inside of a discriminating function
23:09:34
drmeister
Bike: I have some more data
23:10:25
drmeister
I added to the bottom here:
23:10:26
drmeister
https://www.irccloud.com/pastebin/YPMX06Xj/
23:10:58
drmeister
https://www.irccloud.com/pastebin/wuDzlBwt/
23:14:01
Bike
that's what we knew already, isn't it
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?
Thursday, 20th of September 2018, 5:16:00 UTC