freenode/clasp - IRC Chatlog

Search
18:47:28 Bike drmeister: we were reading the environment wrong. (entry . 0) just meant 0 was the index- the actual value was (:eval . (core:quit))
18:47:36 Bike sonow i don't have any idea whatthe problem is again
18:54:29 Bike drmeister: if i'm looking at the argument valist, it's empty (whereas it should have one value, the string).
18:55:24 drmeister Ah - well - this is less unsettling problem.
18:56:07 drmeister Is the read-from-string a newly compiled function?
18:56:35 Bike it's defined in lisp, so probably?
18:56:47 Bike and it takes a &key, so i can vaguely imagine there being a problem
18:57:21 Bike is there a way to verify that a function is compiled, from lldb?
18:57:49 drmeister Well, these are supposed to be loaded from fasl files
18:58:53 Bike i mean interrogating the object or something. i have it available in lldb
18:59:10 Bike i tried core__dumpFunctionDescription but it's giving me crap about casting
18:59:24 drmeister Cast the argument to (void*)
18:59:34 drmeister lldb is annoying
18:59:46 Bike cannot castfrom T_sp to void*
18:59:57 drmeister What is the T_sp object?
19:00:02 Bike the function.
19:00:09 Bike #<FUNCTION READ-FROM-STRING>, thatis.
19:00:27 drmeister Oh - so you know it's a Function_O object?
19:00:45 drmeister Do you have the raw tagged pointer?
19:00:58 drmeister print *(Function_O*)0xYYY
19:01:09 drmeister Where 0xYYY is the raw pointer after you strip the tag from it.
19:01:36 drmeister That will give you the pointer to the FunctionDescription object
19:01:40 drmeister And the entry point.
19:02:38 drmeister And what I'd really want to do is get a break point on the entry to the function and see what is going on with the arguments.
19:02:47 drmeister Because I'm suspecting that you aren't rewinding properly.
19:02:58 Bike maybe. but i don't think i messed with rewinding.
19:03:11 drmeister Or you are iterating through the va_list and then using it up.
19:03:14 drmeister You get one shot.
19:03:17 Bike read-from-string takes both &optional and &key, so i can imagine there being an issue- i didn't test that.
19:03:33 Bike but i just replaced the keyword argument compilation, all the other stuff is the same.
19:03:41 Bike or should be, maybe i did something dumb
19:03:44 drmeister "just"
19:03:54 Bike i mean, it's after the rewinding
19:04:52 Bike anyway i don't know what the raw tagged pointer is. i have (core::T_sp)headFunc = (theObject = 0x###)
19:05:11 drmeister The 0x###
19:05:14 drmeister What is it?
19:05:29 drmeister That's the raw tagged pointer
19:06:00 drmeister What is the value?
19:06:38 Bike 1715902
19:06:46 drmeister Hex value?
19:06:51 Bike yeah.
19:07:16 drmeister no - that can't be it.
19:07:22 drmeister Coming there..
19:07:30 Bike oh, you're right. oops
19:07:37 Bike looking at the wrong thing
19:07:48 drmeister What is it?
19:07:56 Bike 158487679
19:08:04 drmeister That's the hex value?
19:08:08 Bike yes.
20:07:22 drmeister Bike: How is it going - did that solve the issue.
20:08:38 kpoeck Did you see issue ##574: New Lisp dialect with no gc rely (use reference count and develop by C++) call for notice and help
20:08:56 kpoeck Doesn't look like related to clasp
20:09:24 Bike So... spam?
20:09:32 Bike Cool that we're famous enough for it, I guess.
20:09:51 Bike drmeister: I essentially didn't think about the case of having both &optional and &key, so I have to do some rewriting.
20:12:43 kpoeck well it links to another github projects, so perhaps its really a cry for help, but definitively not a clasp issue
20:13:58 Shinmera Bike: is the lambda list destructuring done in C++?
20:14:47 Shinmera ACTION remembered the time he wrote his own lambda-list destructurer https://github.com/Shirakumo/maiden/blob/master/agents/commands/parsing.lisp#L127-L242
20:15:06 Bike there's one in C++ and one in cleavir. just in case one breaks, you know,
20:15:15 Shinmera Hah
20:15:15 Bike i'm doing the code generation though
20:15:32 Bike which there is only one of, because cleavir doesn't handle it. except it does for macro lambda lists
21:03:03 drmeister Another package use fiasco.
21:03:16 drmeister literal uses core. core uses literal. apropos blows up.
21:03:34 drmeister No
21:03:43 drmeister No - not that. apropos blows up yes.
21:03:57 drmeister But I my eyes slipped a line and I made the wrong conclusion.
21:04:52 drmeister Hmm, I don't see any cyclic package uses - why is apropos blowing up?
21:08:08 Shinmera why would apropos care about use relationships anyway?
21:08:17 drmeister I guess it shouldn't
21:08:51 drmeister apropos is blowing up - I guessed (wrongly) it had something to do with cyclic package uses - I fixed cyclic package uses - apropos continues to blow up.
21:09:26 drmeister (do-symbols (x) ...) blows up.
21:10:24 drmeister Maybe clasp has too many symbols.
21:10:34 Bike kinda doubt that's it
21:10:52 Bike we only have a few thousand in packages
21:10:55 drmeister I'm kidding - I'm looking at do-symbols.
21:11:26 Bike anyway, do you know what's up with the "outputs" thing in the lambda list code
21:11:56 Bike if we have the lambda list X we basically do "x1 = va_arg(va_list); x2 = x1;" and then x1 is never referred to again, unless i'm missing something
21:12:03 Bike lambda-list (x), that is
21:12:51 Bike guess i'll just go with it
21:12:55 drmeister Isn't it what you need to work with Cleavir?
21:13:24 drmeister x1 and x2 are llvm registers - right?
21:13:34 Bike they're allocas
21:13:43 Bike llvm presumably eliminates one
21:13:50 drmeister In bclasp, cclasp or both?
21:13:58 Bike i don't think it's needed for cleavir, but i'll have to look at some hir to check
21:14:04 Bike this happens in both, i think
21:15:38 drmeister I'm pretty sure they are how I deal with bclasp needing to put them into lexical variables stored in value-frames (until they are optimized away) or in Cleavir to put them in lexical variables.
21:16:51 Bike i'lll look at it... it just seems pretty bizarre since they both have to be allocas anyway.
21:17:38 karlosz a little stupid but contifying can reduce this down to nop infinite loop https://paste.gnome.org/pp7s1rflb
21:24:18 drmeister hash-table-iterator is blowing up/
21:27:29 Bike The curreng arguments code increments an arg-idx-alloca for every argument processed. But then the rest argument compiler ignores that and uses calling-convention.nargs* instead. How does that know how manya rguments are left?
21:27:52 Bike calling-convention-remaining-nargs* i mean
21:28:12 Bike oh, calling-convention-args.va-arg updates it.
21:28:18 Bike so that's, like... redundant.
21:28:47 Bike i'm probably going to try to overhaul all of this.
21:33:17 Bike i think we are probably giving llvm kind of stupid code, and doing lotsof weirdthings beside.like i'm pretty sure we initialize va_lists if we just use register arguments
21:34:34 drmeister I think we initialize va_lists when we use register arguments to spill them for backtraces.
21:37:11 Bike setup-calling-convention generates the va-start
21:37:33 Bike and setup-calling-convention is called unconditionally by layout-procedure
21:38:39 Bike ok, wait.maybe calling-convention-args.va-start only sometimes actually generates a va_start
21:38:56 Bike even if this isn't generating weird code i want to overhaul it into understandability
21:39:38 Bike i'll figure out the outputs thing first
21:41:39 Bike we're definitely both counting up and down arguments
21:42:08 Bike vaslists are a va_list plus the count,right? where do we use the count? i don't think we need it for argument parsing.
21:43:03 Bike except for key arguments sometimes
21:43:31 drmeister I don't recall the details.
21:43:53 drmeister We may use it to figure out when we are done.
21:44:18 Bike Done? With what?
21:44:29 drmeister Done with arguments for &key or &rest
21:44:36 drmeister how many argments remain
21:44:48 drmeister hash-table-iterator is definitely blowing the stack sometimes.
21:45:00 Bike right, that's where we need some kind of size, but we can deal with it separately in the arguments code, rather than embedding it in the vaslist
21:45:34 Bike so it can be compiled to be a register and such
21:46:35 drmeister It blows up except when I touch it.
21:47:01 drmeister What can be compiled to be a register?
21:47:47 Bike The count of arguments remaining.
21:48:01 drmeister Ok.
21:48:08 Bike Instead of being part of the vaslist structure, I mean.
21:48:16 drmeister If there ever was a time I needed tail call optimization it is now.
21:48:27 Bike yeah, hash-table-iterator is pretty weird.
21:48:42 drmeister It's blowing the stack ... sometimes.
21:49:39 Bike I don't think it calls itself though.... it's ust a closure
21:49:43 Bike j
21:49:56 drmeister It does in clasp
21:50:03 Bike no, wait, this is packages-iterator i'm lookingat.
21:50:13 drmeister foundation.lsp
21:50:42 drmeister advance-hash-table-iterator
21:50:52 Bike uhhuh, i see. maybe we could rewrite that as a tagbody.
21:50:54 drmeister There are no arguments - can I just use a tagbody and go?
21:50:59 Bike the poor man's tail call optimization
21:51:03 drmeister Yes.
21:51:10 Bike look at packages-iterator in packlib.lsp for an example
21:51:39 Bike i think this can probably be a tagbody. yeah.
21:52:24 drmeister Like this?
21:53:01 Bike shouldn't hte lambda name just be advance-hash-table-iterator
21:53:07 Bike but yeah, like that.
21:53:20 drmeister Yeah
21:59:54 drmeister While you are working on the &key argument handling - are you taking out the PHI node code>?
22:02:00 drmeister It's funny how I said that about needing tail-call optimization and we both keyed in on using tagbody/go
22:02:34 drmeister apropos works now
22:03:27 Bike I'm still using phi nodes a bit, but I put a lot of comments, and pseudo-C to explain what it's supposed to look like.
22:03:58 drmeister It's peppier as well now.
22:04:03 Bike nice.
23:04:09 Lord_Nightmare2 ** NICK Lord_Nightmare
23:38:58 karlosz i recloned clasp and keep getting a StopIteration exception when using waf
23:39:13 karlosz this look familiar to anyone?
23:39:54 drmeister Can you provide the entire log?
23:40:33 drmeister I haven't seen that - but I suspect something weird in the file system and an infinite recursive loop due to a symlink or something.
23:42:29 karlosz which log file?
23:52:06 karlosz this is the full stdouyt after ./waf configure https://paste.gnome.org/pg7yokd60
23:53:26 drmeister You are doing ./waf distclean and then ./waf configure and you get that?
23:56:37 karlosz even ./waf distclean gives me the same rror
23:56:42 karlosz every invocation of ./waf gives that
23:56:50 karlosz i tried deleting and recloning the repo too
23:56:50 drmeister I've never seen that before.
23:57:04 drmeister Gaah
23:57:10 drmeister What operating system? Arch?
23:57:22 karlosz yeah, although ./waf worked yesterday, soo dunno what the deal is
23:57:41 drmeister Did I mention that I hate Arch?
23:57:46 drmeister I'm sure I mentioned it.
23:57:50 karlosz heh
23:58:24 drmeister Do you have clang 6?
23:58:32 karlosz yes
23:58:36 drmeister Type this: which llvm-config
23:59:06 karlosz /usr/bin/llvm-config
23:59:17 drmeister llvm-config --version
23:59:32 karlosz yeah, 6.0.1
23:59:50 drmeister It's not even getting to that.
0:00:06 drmeister Crap - I would start putting print statements after def config(...):
0:00:19 karlosz alright, ill do something investigating and ask again if i find something
0:00:20 drmeister Something absolutely bizarre is going on.
0:01:06 stassats in the world?
0:11:08 karlosz drmeister: you won't believe this. the culprit is python3.7, which has a breaking change
0:11:14 karlosz so downgrading to python3.6 fixed it
0:11:19 karlosz i think that means waf needs to be updated
0:11:27 drmeister Jeeeeeeezzzzzzzzzz
0:11:31 karlosz and the breakiong change is intentional!
0:12:06 drmeister Keep going python! - drive your users crazy and into my waiting arms.
0:12:15 drmeister What is it?
0:13:04 karlosz its thje bullet with PEP 479
0:13:11 karlosz with the changes to generator raising runtime exceptions
0:16:00 drmeister When did Arch upgrade to python3.7?
0:16:35 stassats arch and stability? name a less iconic duo
0:17:44 karlosz drmeister: looks like july 15
0:17:51 drmeister On one hand this was helpful - and on the other hand Arch sucks.
0:19:19 stassats will the new waf work on python3.6?
0:20:27 drmeister I shlepped over to #waf and posted a note to the developer.
0:21:34 drmeister He moved it to gitlab.
0:21:51 drmeister If he doesn't respond in a few days I'll register with gitlab and post an issue.
1:50:48 karlosz looks like we cant afford to do value numbering on closure vars. dataflow analysis on a higher order graph requires kCFA which is a known exponential/nfeasible problem
1:51:34 karlosz our best bet is to aggressively inline and get rid of local functions whenever possible for dataflow
1:54:09 karlosz i don't know if anyone is still interested in at least getting something like 0CFA for cleavir. could be useful for a static analysis, rather than actually compiling http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/
2:28:31 drmeister The article says that there are cubic implementations - is that still out of the question?
2:29:11 drmeister Cubic sounds bad though.
2:44:55 Bike cubic's probably about as good as a flow analysis is gonna get
3:11:36 karlosz Bike: is that sarcastic? most flow analyses are linear
3:12:24 Bike for type inference with closures and assignment?
3:13:14 karlosz oh, well if you include higher order functions then you are lucky if you can make it polynomial time
3:13:40 Bike right.
3:15:44 karlosz the third to last paragraph of this article is extremely enlightening https://wingolog.org/archives/2011/07/12/static-single-assignment-for-functional-programmers
3:16:26 Bike "But if you can't do whole-program analysis..."? yeah, that's the problem, really
3:17:07 karlosz well, the sentence afterwards is whats important
3:17:23 Bike i was just identifying the paragraph, yes
3:17:27 karlosz we should closure convert as much as possible so that we *can* leverage traditional optimizations
3:17:48 karlosz otherwise we are stuck with the CFAs
3:18:18 karlosz i mean, this isnt scheme either though, so i dont know how common functional style even is
3:19:03 karlosz but since we are thinking about treating closures right, it probably makes more sense to eliminate as many closures as we can and appply linear dataflow optimizations rather than do some cubic or exponential cfa
3:20:39 karlosz on another note, drmeister: the arch thing people were running into with the boost symbol disaappeared when i reverted to a May 20th version of clasp
3:20:54 karlosz so it doesnt seem to be the version of boost bundled with arch
3:20:59 karlosz thats the problem
3:22:14 karlosz i started the build a few hours ago on my laptop and it still hasnt finished though so i dont think its possible for me to bisect this issue
3:29:33 drmeister karlosz: I'm being told that waf-2.0.7 has the fix for python3.7
3:31:11 karlosz and clasp bundles waf right? so is there an easy way to use the systems or wait for clasp to update it?
3:31:31 karlosz i just downgraded to 3.6 in the meantime just to get it to work
3:31:49 drmeister It's best if I upgrade it.
4:08:25 drmeister Oh dear god!
4:08:28 drmeister The usual strategy for this kind of implementation is to write it all in C++. The latency requirements are too strict to do otherwise. Once you start down this road, you never stop: your life as an implementor is that of a powerful, bitter C++ wizard.
4:17:23 karlosz Andy Wingo's blog is great.
4:27:14 karlosz is there an incanctation for only rebuilding the ceavir part of clasp? i am used to making a small change or print statements in cleavir and starting a quick self compile to check my work
4:42:43 scymtym hello everyone
4:45:31 scymtym beach: i'm getting close to pushing the parse result protocol to the eclector master branch. if you have time, could you have a brief look at the documentation and tell me whether it makes sense to you? the current version is https://techfak.de/~jmoringe/eclector.pdf , section 2.4 is about the new package and protocol
5:08:30 Bike karlosz: usually i just rm -rf the cclasp fasls and rebuild
5:11:03 Bike drmeister: if you started this for the startup time i think you messed up pretty bad