freenode/#sbcl - IRC Chatlog
Search
18:20:31
stassats
is there a rationally for poorly implementing our own mutexes and condition variables?
18:22:51
jsnell
I would have guessed it was another of those cases of system calls actually working properly on OS X
18:24:34
nyef
stassats: IIRC, the memory requirement for futexes is a single (unboxed?) word, plus possibly kernel memory overhead /while they are being slept on/.
18:26:42
nyef
So no foreign objects to track that can leak, for example. A winapi mutex is represented by a HANDLE, but it's tied to some kernel state that can leak.
18:30:41
jsnell
I'm trying to remember whether that special support was anything except custom finalizer machinery. probably not
19:28:28
stassats
i'd be fine with that, as i'm fine with using dispatch_semaphore in slime, but something available to a wider audience would be preferable
19:31:22
stassats
i still think any normal program shouldn't create and discard too many mutexes, so finalizers should do
19:58:05
fortitude
is it normal for a thread in gc_stop_the_world to have GC_INHIBIT and IN_WITHOUT_GCING set? relatedly, shouldn't gc_start_the_world set IN_WITHOUT_GCING to NIL, or a stored value?
20:32:42
foom2
Google open sourced the C++ Mutex implementation we use internally. It doesn't use pthread mutex, instead using some sort of per-thread waiter or something like that.
20:33:02
stassats
we could even detect that a function is only using a hash-table to call gethash/puthash and not lock it
20:34:15
stassats
foom2: the current sb-thread:grab-mutex works everywhere too, but it doesn't unscheduled itself and has to spin instead
20:35:46
stassats
i still imagine a proper pthread_mutex can use better techniques than just sleeping
20:35:58
foom2
https://github.com/abseil/abseil-cpp/blob/master/absl/synchronization/internal/waiter.cc
20:40:57
foom2
But in any case, the possibly-heavyweight platform-specific stuff is only used to implement blocking, and so there's only one per thread.
0:09:54
White_Flame
hopefully a dumb question, but since sb-ext:run-program's :environment accepts a new environment list, does that mean it entirely replaces all envvars? How do you get the current complete envvar list in order to pass all existing envvars plus some additions?
0:34:52
White_Flame
now I just have to figure out why python is ignoring my PYTHONPATH, but that's for another place
0:40:36
White_Flame
I think I'll have to break down and register a nick with freenode. the demanded registration idiocy of all the other larger programming channels is getting unbearable
0:41:41
pfdietz
In SBCL, (upgraded-complex-part-type 'integer) == RATIONAL. In CLISP, it is INTEGER.
0:43:11
pfdietz
"(complex type-specifier) refers to all complexes that can result from giving numbers of type type-specifier to the function complex, plus all other complexes of the same specialized representation."
0:43:44
stassats
and that it should satisfy (typep realpart 'type-specifier) (typep imagpart 'type-specifier)
0:45:29
pfdietz
(complex integer) is the same as (complex #.(upgraded-complex-part-type integer)), by that quote.
0:47:04
pfdietz
(upgraded-complex-part-type 'rational) = RATIONAL, so complexes formed by giving rationals have the same specialized represention. So, the "plus all other" part of that sentence means they're included too.
0:48:55
pfdietz
"This type encompasses those complexes that can result by giving numbers of type typespec to complex."
0:51:57
pfdietz
If INTEGER and RATIONAL both have their own specialized representations, then #C(1 1) should not be in (COMPLEX RATIONAL), even though 1 is a RATIONAL. It can't be in both. So I take this to mean "upgrade to the most specialized representation that works and use that."
0:53:31
pfdietz
typep does say this: "(typep object '(complex type-specifier)) returns true for all complex numbers that can result from giving numbers of type type-specifier to the function complex, plus all other complex numbers of the same specialized representation."
0:55:04
pfdietz
I vaguely recall this became a point of contention when I was putting together ANSI-TESTS, so perhaps it's best to just document what interpretation SBCL will be using and move on.
1:01:35
pfdietz
nyef: you specify the element type of arrays explicitly when you make them. Complex does it automatically, and exactly how that's supposed to work is the issue.
1:03:13
pfdietz
CLISP does have the problem that #C(1 1.0) is a complex, mixing integer and float. That contradicts the spec.
1:03:29
stassats
should've said "returns true for all complex numbers that can result from giving numbers of type (upgraded-complex-part-type type-specifier) to the function complex"
1:05:55
pfdietz
Ah, I see what I was forgetting. Unlike in arrays, if A is a subtypep of B, then (complex A) is a subtype of (complex B), even if they have different specialized representations.
1:17:56
stassats
'(upgraded-complex-part-type 'T1) and (upgraded-complex-part-type 'T2) return two different type specifiers that always refer to the same sets of objects'
1:18:21
stassats
how can two different type specifiers refer to the same objects? why is upgraded-complex-part-type different then?
1:19:34
nyef
Aren't BIT, (UNSIGNED-BYTE 1), (MOD 2), and (INTEGER 0 1) different type specifiers that refer to the same objects?
1:23:11
pfdietz
He's just illustrating that different type specifiers can denote the same set of objects.
1:25:21
pfdietz
By the definition of subtypep, if T1 and T2 denote the same set of objects then (if subtypep can determine their relationships) then each must be a subtypep of the other.
1:25:59
Bike
it says "T1 is a subtype of T2, or [etc]" so the etc covers the case where rather T2 is a strict subtype of T1, i.e. they upgrade to the same thing. right?
1:26:06
nyef
That "if subtypep can determine their relationships" might be important, but is unlikely to be in this case.
1:26:51
pfdietz
The only reason this is not totally clear is because of the contradiction on the page for TYPEP.
1:27:52
pfdietz
Where it asserts that (typep x (complex foo)) ==> (typep (realpart x) foo) and (typep (imagpart x) foo).