freenode/#clasp - IRC Chatlog
Search
14:55:37
makomo
pfdietz: thanks for the answer. right, but can you use the collected information at macroexpansion-time within the compilation invocation of that same top-level form?
14:56:16
makomo
so i have a top-level form F that is being compiled (and hence macroexpanded). i want to both store and use certain information within that same invocation?
15:04:38
makomo
pfdietz: here's the relevant code http://plaster.tymoon.eu/view/921#921. perhaps another layer of macro indirection can fix it? wouldn't that be relying on the order of macroexpansion though?
15:06:01
pfdietz
That was either used as a constructor, or as a pattern matcher, depending on where it occurred.
15:07:12
pfdietz
When parsing the string, the parser invoked macroexpand on a fake macro, and the env arg, to pull out a symbol table. The flow of information was always downward.
15:07:30
makomo
pfdietz: do the quotation marks indicate that it was used within strings or was it just to make it explicit?
15:08:25
pfdietz
The string occurred inside a thing that identified it as something to be parsed, and that thing was created by a reader macro for syntactic sugar.
15:09:45
pfdietz
Passing information upwards would involve a different mechanism: the surround macro would have to fully expand <body>, then walk over the expansion to pull out things the lower macros had stashed there.
15:16:29
makomo
hm right, i think my case is the latter. i need to pull stuff from the body of the macro
15:18:33
makomo
pfdietz: why does the outer macro have to walk the body's expansion? can't the local macros within body communicate information via some global state (as i'm doing with hash tables)?
15:23:44
pfdietz
Because in normal macroexpansion, the outer macro is expanded before the inner ones. The outer macro's function is going to have to "manually" cause its parts to be expanded "early" if it wants to get any results of those expansions before it is done expanding itself.
15:29:29
drmeister
I got the buildbot to build independently for the first time using AWS spot instances.
15:29:39
makomo
pfdietz: the walking i was thinking of was the one you said happens *after* the manual macroexpansion. once i expand the body, why do i have to walk the body? is that just one of the alternatives (and the other is using global state)?
15:30:20
makomo
you said "(...) the surround macro would have to fully expand <body>, then walk over the expansion (...)"
15:30:40
drmeister
It's easy to add non-AWS workers, save build products, chain builds and add tests. I'm interested in discussing what we should do with these new CI capabilities.
15:32:21
pfdietz
The macro expansion function for the outer macro needs to get some results computed by macros inside its body. Those results are not yet computed. The outer macro's function needs to explicitly cause those inner macros to be expanded if it wants those results. This will be done by walking DURING expansion of the other macro: that outer macro function will explicitly call a code walker to expand the macros in its body. There
15:32:22
pfdietz
will be another pass over that code afterwards, by the normal expansion process, but by that time all the macros will already have been expanded so that will be a no-op.
16:14:36
Bike
changing a lisp-exposed C++ function's signature to have Fixnum_sp instead of size_t is causing a build failure for reasons i don't understand
16:40:00
kpoeck_
Regarding the weak-pointer for an immediate, can‘t we put the immediate value in a vector and return a weak-pointer to the vector?
16:42:16
Bike
i don't understand why trivial-garbage even wants pointers to immediates. uniformity, i guess?
16:43:30
Bike
if we just do an actual weak pointer to a vector, the weak-pointer-value or whatever would be wrong, though
16:58:41
drmeister
A weak pointer contains a single slot 'value' and this is a pointer to an object on the heap.
16:59:27
drmeister
https://github.com/clasp-developers/clasp/blob/dev/include/clasp/gctools/gcweak.h#L535
16:59:43
Bike
there's an assert saying "value can never contain anything but a pointer - if it does then when it gets set to NULL by the GC it will be interpreted as a Fixnum 0"
17:00:09
Bike
make-weak-pointer seems to return a WeakPointer_O, which has a WeakPointerManager in it
17:00:53
drmeister
Right - disabling the ability to allocate weak pointers to all immediates might have been an overreaction.
17:01:37
pfdietz
Since common lisps are allowed to copy numeric (and character) values at any time, the whole notion of weakness for them is dubious.
17:01:56
drmeister
I think I could allocate weak pointers to any immediate value that isn't 0x0 - I'll just NOT tell the GC to watch that pointer and splat it because the value won't be a pointer.
17:03:41
Bike
it's dubious, but on the other hand it would be kind of dicey to make the user aware of what's immediate and what's not
17:04:33
Bike
also i thought making a parameter size_t would imply a sign check when converting from fixnum, but no. too bad
17:05:00
drmeister
Yeah - it doesn't make sense to allocate weak pointers on immediate values. But different lisps have different types as immediate values - so I guess you need a consistent API.
17:06:27
drmeister
I didn't sign check when converting fixnum -> size_t - you can find the translator and add that.
17:06:57
drmeister
Actually, we shouldn't put those kind of tests in translators - they will slow things down. Type inference is a better way to handle it.
17:07:50
drmeister
I think unsafe translators and type inference that generates appropriate bounds checking is the best way to deal with this.
17:11:35
pfdietz
Users already can tell by using EQ and EQL. I've encountered cases in SBCL where use of EQL type declarations alters the EQ-behavior of a function (allowed by the standard, but weird.)
17:13:45
pfdietz
Yes. And the constant in the EQL declaration is not EQ to the constant being passed to the function.
17:13:45
stassats
the only way for the type check to succeed is to have the same constant, so it substitutes all the cases where it's used
17:18:49
stassats
in that case, nothing's actually optimized, loading 1d0 is more expensive than returning the argument
17:21:36
drmeister
stassats: The only problem in my mind when I wrote this is that the value cannot contain 0x0 because the Boehm GC uses 0x0 to splat the pointer. Now I see a solution to this. I could add a flag that tells me if value contains a pointer or an immediate. If it contains a pointer - then 0x0 means it was splatted. If it contains an immediate - then I don't tell the GC that the value contains a splatable pointer.
19:13:20
drmeister
I was going to ask about updates - I'll do it in slack - I don't know if Steven sees posts here.
20:48:07
drmeister
::notify Bike The cst compiler behaves differently than the ast compiler. This is what I get in the Activity Monitor. https://usercontent.irccloud-cdn.com/file/1R6CRBUG/image.png
20:52:09
drmeister
::notify Bike - It seems to be spending a lot of time in sigtramp https://usercontent.irccloud-cdn.com/file/wQjK39GH/image.png
1:50:52
drmeister
Bike: I'm trying to get more info on what is going on. Could you speculate on what might be different between your configuration and mine?
2:08:28
drmeister
Hmm, I don't think it's the problem. I think I defined this so that I would have a C++ type that would indicate that something returns a tagged Fixnum_sp and not a Fixnum (which is untagged)
2:08:38
drmeister
https://github.com/clasp-developers/clasp/blob/dev/include/clasp/gctools/smart_pointers.h#L689
2:10:06
drmeister
To be really clear: A C+ Fixnum_sp that represents the value 1 (one) has the bit pattern #B100 in the word that it contains.
2:14:20
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/core/sourceFileInfo.cc#L117
2:15:42
drmeister
In core__source_pos_info_lineno info is T_sp and then I call clasp_sourcePosInfo_lineno, which expects a SourcePosInfo_sp type. It's bad to mismatch types when calling.