Search
Wednesday, 24th of April 2019, 20:28:53 UTC
20:34:43
Bike
incidentally, sicl appears to use both closures and literals in various situations relating to discriminating functions.
21:01:02
drmeister
I'm getting crashes in fixup.lsp - I'm having flash backs.
21:05:59
drmeister
Do you have some time to drop by again? I don't want to spend all night walking down memory lane.
21:08:58
drmeister
I have an infinite recursive loop when it calls the first generic function (I think). I'm doing something stupid and something something I'm too stupid something something to figure it out.
21:59:35
drmeister
This gf dispatch is hard because it's tricky to do it efficiently. It's starting to come back to me now.
22:01:39
drmeister
I want to handle the cases with only register arguments specially.
22:09:59
selwyn
i can't build from a fresh clone of dev
22:10:48
drmeister
Is this with the AST or CST?
22:11:17
selwyn
https://pastebin.com/PkEaYGsY with CST
22:12:52
drmeister
Hmm, Bike just cleaned up uintptr_t related stuff.
22:13:03
drmeister
Did you do ./waf distclean first?
22:13:12
selwyn
it was from a fresh clone
22:14:09
selwyn
looking at the backtrace, i think a uintptr_t was not changed to uint64_t
22:14:27
drmeister
Hang on - I'll grab the latest and check out what's going on.
22:29:28
selwyn
i removed Integer_sp Integer_o::create( uintptr_t ) and now everything is compiling fine
22:32:31
selwyn
located in numbers.h + numbers.cc
22:35:23
drmeister
selwyn: I was able to build when I pulled the latest changes - I'm trying a fresh clone now.
22:35:42
drmeister
Did you switch into the 'dev' branch?
22:36:24
drmeister
Oh wait - that's a stupid question - hang on.
22:38:07
drmeister
You are on linux - right? It's a linux thing.
22:38:19
drmeister
Or a macOS thing - depends on who you want to blame.
22:38:39
drmeister
On macOS uintptr_t and uint64_t are treated as separate types and on linux they are not.
22:40:25
selwyn
ah that would explain it. i am always on linux
23:13:18
drmeister
Got cut off for a bit
23:15:22
selwyn
it looks to be working fine, building CST now
23:29:04
Bike
i actually tried ereasing the uintptr_t definition and that made it not build on my machine
23:29:14
Bike
but i was already pretty sick of C++ type stuff at that point
23:32:16
Bike
as far as i could tell, macrology prevented the definition from ever existing
23:32:37
karlosz
was able to build up to inline.lisp in just under 7 hours serially for cclasp
23:33:48
karlosz
so the progression has been 12 hours > 9.5 hours (by r-u-i speedups) then 9.5 > 7 hours (by removing reinitialize-data)
23:34:06
karlosz
matches what the flamegraph predicted nicely
23:34:17
karlosz
the real good news is that theres still low hanging fruit here
23:34:42
karlosz
set-predecessors took up about the same amount of time, so im optimistic its still possible to easily shave about 1-2 hours off the cclasp build
23:34:51
karlosz
after that, things will get hairier
1:18:22
drmeister
That sounds really great!
3:13:21
beach
Good morning everyone!
Thursday, 25th of April 2019, 8:28:53 UTC