freenode/#clasp - IRC Chatlog
Search
16:18:55
karlosz
also, Bike, i don't know if you saw, but i added the "Unused lexical variable" warnings
16:20:58
Bike
like if we delete code later and references go with it, no warning. some warnings is a lot better than never warnings, though
16:21:38
karlosz
to only warn about variables that are clearly unused and written that way by the user
16:21:58
karlosz
we don't want to warn about variables that are unused because of compiler optimizations, that would be confusing and not helpful i think
16:23:03
karlosz
the thing that is missing is that the condition isn't a style warning as mandated in the spec because i was too lazy to add the condition and i don't know where that would go
16:23:45
karlosz
also warning about macroexpanded ignored variables is not good, but i figured that would require CST coordination/origin somehow
16:24:11
Bike
probably the client should be able to customize the actual presentation, but yeah i see. i'll merge that and look at little improvements then
16:24:35
karlosz
if you try a self build it really does catch many real instances of unused variables in the source code
16:34:09
Bike
so on the topic of expanding passes, when i was looking over the local call stuff i noted that you moved the actual interpolation into a post-find-local-calls function that's called by the local call finder
16:34:49
Bike
could we not just have an exported function for it and have the client call? i mean, i get that it works in terms of local calls now, but making it a package deal is kind of eh
16:35:00
Bike
which you mentioned in a comment, but why do CLOS stuff if we can just call or not call
16:52:18
beach
Now, if you fixed those package names, you could load Clasp code into a host Common Lisp as well. :)
16:52:21
Bike
hm, there are some in cleavir... but it's possible we're missing something like declaring specialized defmethod parameters as ignorable. i'll find out
16:58:02
karlosz
Bike: yeah i hear what you're saying about a package deal and i worry about that too
16:58:34
karlosz
it's just that that's the natural place to trigger it, hence it would be cool if a client could say "yes do convert lets right after detecting local calls"
16:59:33
karlosz
since im imagining we can potentially discover more local calls later, as a result of deleting a readvar or writevar or whatever, and that makes new code eligible for conversion, and... you get the idea
17:00:35
karlosz
Bike: also, keep in mind, some of the unused variable warnings are bogus because at the bir level, we currently don't understand if the variable is coming from source code or not
17:01:25
karlosz
and it sucks that there's nowhere to put ignore info into the lexical-ast, as far as i could find, so i kludged it and put it on lexical-bind
17:07:21
karlosz
i didn't check if any of the unused variable warnings in clasp were "real". are they?
17:19:48
Bike
maybe i don't understand what you mean by soruce code though. i mean if a macroexpansion binds some variable and that variable is unused is that not still worth a warning
17:27:19
Bike
some of them are definitely generated, e.g. "The Variable ARGS is defined but never used" comes up about a million times because the compiler macro on FORMAT is missing an ignorable
18:03:14
Bike
yeah, we're not doing defmethod ignorance correctly, that's going to cause a ton of spurious notes
18:20:24
karlosz
hm, maybe you're right that even macroexpanded code should still warn about their internally unused variables
18:20:51
karlosz
im just imagining you are using a macro from another library you have no control over and you don't want like a billion style warnings from that
18:23:17
Bike
we could probably determine whether code is a macroexpansion fairly easily with some work in cst-to-ast and cst
19:01:04
karlosz
i don't really have a good handle conceptually on how to get clients to decide on that sort of thing
19:01:20
karlosz
we already have cleavir doing decisions for style warnings in cst-to-ast in many casses
19:05:15
Bike
it's usually a bit easier with conditions since the client can just handle the condition
19:06:34
Bike
with this, probably we just need to keep enough info in the condition that the client can decide whether or not to muffle
19:12:25
karlosz
yeah maybe just an additional slot like (generated-p) or something for the decision
19:13:18
karlosz
hopefully this is a first step to doing notes more generally instead of putting it off
19:50:07
Bike
all my method fastness magic makes the defmethod ignorability stuff way more annoying to implement
22:05:17
karlosz
Bike: yeah if we kept track of where that source code came from it would help a lot with debugging macroexpansion stuff like that
22:08:00
karlosz
and, unrelated to the issue at hand, i recall macroexpansion being slow, so there might be some easy drive by issues to pick off there too
22:13:26
karlosz
cst-to-ast just proportionally takes a long time, what with the macroexpansion stuff
1:47:27
Bike
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/random.h#L70-L78 oh, yeah. just call these
1:51:47
drmeister
Why do we have a write_ugly_object function? What's ugly about it? This is copied from ECL
1:52:24
Colleen
Clhs: variable *print-pretty* http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_pre.htm
1:54:35
drmeister
I'm looking for where the dispatching happens. It looks like I implement __write__(T_sp stream)
1:56:30
Bike
the pretty printer is more or less separate from the rest and written mostly in lisp, but the ugly printer, yeah, i don't know
2:07:48
drmeister
I'll initialize a random-state in a separate operation and then use it from then on to generate sequences.
2:08:34
drmeister
This will allow me to generate the sequences and setup the synthesizers using the same code path on subsequent re-runs of the jupyter notebook as the first run.
2:09:03
drmeister
Currently in the first run of the synthesis planner I was generating sequences and initializing a lot of state for the robotic synthesizers.
2:09:53
drmeister
Then I would rerun the notebook multiple times but to get the same sequences I would load the synthesizer state with the sequences.
2:10:22
drmeister
Then I would improve the code so that it would generate more stuff that the robots needed and I'd do this over and over again.
2:11:06
drmeister
A problem came up yesterday where somehow the saved state of the synthesis was not internally consistent - I don't know how that happened. But I couldn't recover.
2:12:11
drmeister
Today something else happened. Two of our latest building blocks refused to dissolve in N-methylpyrrolidone (the solvent we use for synthesis).
2:12:36
drmeister
This was when we were deep into weighing and dissolving all of the building blocks.
2:12:55
drmeister
So we needed to quickly swap out those building blocks for others that we weren't using.
2:14:13
drmeister
So it would be nice if I could run the whole setup again and get all the same sequences from the saved random-state - but with a small substitution file that substitutes building blocks for other ones and recalculate everything.
2:16:31
drmeister
Next I'm going to write code to build three-dimensional structures for every possible molecule that we can make that has this initial plan that we are using.
2:19:14
drmeister
It's more than 1.1M compounds that we can make with our current setup - that's just a sequence of four building blocks and we've made more than 33 of them. Nature has the 20 amino acids. We have 33 building blocks right now and can make hundreds more.
2:48:35
drmeister
(read-from-string (let ((*print-readably* t)) (with-output-to-string (sout) (print (make-random-state t) sout))))
2:55:45
Bike
like you give it a random state and a string, and it fills the random state with the info from the string
2:56:43
drmeister
I'm going to have random-state-set return the random-state - then I don't have to make the form in the #.(...) any more complicated.