freenode/#clasp - IRC Chatlog
Search
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.
2:54:56
dvssa
drmeister: I'm running into issues when loading :design with the clasp/cando build from the latest master, I get this when I try: https://gist.github.com/DurhamSmith/081ab7f049fde1359a25300468b6a89d
3:07:59
drmeister
I'm implementing a CI system to make this sort of breakage unlikely. We will have it in place next week.
3:10:07
drmeister
I don't have the CI system fully in place yet. I just have it building the testing branch of clasp and clasp+cando when I push to those branches.
3:10:58
drmeister
Bike: It appears that source-pos-info-lineno is being passed a fixnum rather than a core:source-pos-info object.
3:12:45
drmeister
Bike: I don't know - but something uses fixnums as origin doesn't it? Default Cleavir? Default Eclector?
3:18:01
drmeister
dvssa: I'm actively working in design.lisp - so it's possible that I push broken code.
3:27:30
dvssa
Ok no prob, when you want to chat about it drop me a message on slack. You might also be interested in this: https://arxiv.org/pdf/1807.04259.pdf
3:28:17
dvssa
And this seems to be a good training data source https://www.nature.com/articles/sdata201422.pdf
3:29:23
dvssa
I'm slowly learning more about QML as well, I want to see how we could incorporate it into clasp