freenode/#clasp - IRC Chatlog
Search
12:34:44
kpoeck
From the gray classes, only fundamental-character-output-stream is exported. Is this intentional?
12:36:31
kpoeck
Can I export the other, at least fundamental-character-input-stream fundamental-binary-input-stream fundamental-binary-output-stream?
12:41:16
kpoeck
Symbol named "FUNDAMENTAL-CHARACTER-INPUT-STREAM" is not external in the GRAY package.
12:41:51
Bike
the reason i asked is i know there's that redefine-cl-functions thing that does exports, but i suppose it only operates with... functions
12:42:55
kpoeck
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/lsp/packages.lsp#L52
12:43:14
Bike
right. there's also some exports at the C++ level, but none of them seem to be classes
14:52:57
kpoeck
https://github.com/clasp-developers/clasp/pull/949 exports the gray fundamental classes
15:04:28
kpoeck
Ironclad has the same thing in https://github.com/sharplispers/ironclad/blob/master/src/octet-stream.lisp#L27-#L37
15:19:02
drmeister
./configure --disable-parallel-mark --enable-threads=pthreads --enable-large-config --enable-handle-fork=yes
15:25:31
kpoeck
I did brew install --build-from-source bdw-gc to make brew use the edited formula, not sure whether this is needed
15:32:23
kpoeck
core__hash_table_pairs does not work on weak hash-tables, so with-hash-table-iterator does not work for weak hash-tables
15:35:04
kpoeck
perhaps just CL_DEFUN Vector_sp core__hash_table_pairs(HashTable_sp hash_table) needs to be changed to CL_DEFUN Vector_sp core__hash_table_pairs(HashTableBase_sp hash_table)
15:38:16
drmeister
We need a new hash-table implementation that unifies the regular hash-table code with weak key hash table code.
15:43:55
Bike
and we could soup it up to work with arbitrary tests and hash functions, because why not
15:44:00
drmeister
The weak-key hash-tables store keys in a separate vector from the values. The regular hash-tables store them in the same vector.
15:44:29
kpoeck
I believe https://github.com/clasp-developers/clasp/blob/dev/include/clasp/core/weakHashTable.h#L50 confirms my claim
15:44:40
drmeister
I think we should start with the less well developed code in gcweak.h and make it look like the stuff in hashtables.h
15:44:52
Bike
well, i mean, even if it is a subclass, code to get pairs from the normal hash table won't work for t he weak hash tables.
15:45:11
drmeister
Because it will be easier to add thread-safety to the gcweak code than weakness to the regular hash tables.
15:45:45
drmeister
It's unreadable because it's trying too hard to be generic code with C++ template programming.
15:47:29
drmeister
Bike: Could you get a sense of how the SBCL hash tables work? They have an extra level of indirection - don't they? An index?
15:48:02
Bike
i tried looking at that a bit after we talked about it, but the weakness stuff isn't really handled in lisp beyond setting a few flag bits
15:49:11
drmeister
If we can treat the hash tables as a (sort-of) vector of key/value pairs and an index then rehashing could just rehash the index. Hash table iterators would then walk the (sort-of) vector of key/value pairs.
15:49:46
drmeister
I say (sort-of) vector because right now we are targeting MPS - and it keeps weak pointers in a separate pool.
15:49:53
Bike
i also considered t hat with respect to lock freedom, but like... you still need to expand the key-value vector at some point
15:51:34
drmeister
Yes - but another idea is to add things to the hash-table we could have an atomic linked list that we add things to and if we could have a global synchronization.
15:52:34
drmeister
IF we could stop all threads and IF we could ensure that we aren't in hash-table code - we could copy the linked-list of new key/value pairs to the hash-table.
15:54:05
Bike
i mean i read a couple papers on lock free hash tables. it's pretty simple up until you have to rehash
15:55:04
Bike
if we store our keys in values in a linked list our access is linear time, thus making the hash table pointless
15:57:53
drmeister
kpoeck: So yes - we could we could enhance core:hash-table-pairs to handle weak-key hashtables for the short term.
15:58:20
Bike
the idea would be to make hash table iterators work for weak key hash tables, because they presently don't
15:58:59
Bike
however, because, as i said a while ago, the weak hash table code is kind of broken, and in particular it doesn't actually garbage collect values corresponding to splatted keys as far as i can tell, it might be better to say we don't support weak key hash tables yet
16:03:21
kpoeck
I think I will now to the safe thing and and extend the regression-test to include with-hash-table-iterator
16:15:52
drmeister
Yeah - broken weak-key hashtables suck. I'll talk with cracauer - if we are moving away from MPS it may change what we do with weak-key hashtables.
16:22:11
drmeister
The answer to linking in an alien boehm is LD_LIBRARY_PATH on linux and ??? on MacOS.
16:24:34
drmeister
I'm about to create another hack - someone tell me to stop if this is too horrifying... explanation...
16:25:51
drmeister
It will contain a makefile that untars boehm from a tar-file, configures it and builds and installs it in /opt/bdw-gc.
16:32:15
drmeister
I need it installed somewhere known (/opt/bdw-gc) and I need custom configure settings and I need easy install.
16:33:23
cracauer`
Realistically we need it for llvm, too, because Linux distributions are too far behind in their llvm version.
16:35:58
drmeister
We are also discussing hash-tables. Currently our weak-key hash-tables are broken - but fixable.
16:36:15
drmeister
The issue is weak-key hash-tables use completely different code from hash-tables.
16:43:04
drmeister
Should I add gc-8.0.4.tar.gz to the repo or have code to download it. Downloading it means dealing with wget and curl on linux and macOS separately. Bleh.
16:44:46
cracauer`
I think you should only invest the work to automate this after confirming that your new GC fixes the hangs.
16:46:52
drmeister
(cd ./gc-8.0.4; ./configure --prefix=/opt/clasp-support --disable-parallel-mark --enable-threads=pthreads --enable-large-config --enable-handle-fork=yes)
17:04:01
drmeister
I'm getting some occasional segfaults when I run multithreaded code within clasp that is NOT clasp multithreaded code.
19:25:28
kpoeck
For whatever reason, this procedure didn't install gc_allocator.h in /opt/clasp-support/include/gc/
19:33:41
drmeister
but gc_allocator.h is NOT included from any header files in /opt/clasp-support/include/gc
19:46:23
drmeister
It looks like gc_allocator.h is no necessary to build clasp - I'm building it now.
21:24:20
kpoeck
drmeister when you test https://github.com/clasp-developers/clasp/issues/937, which output do you get?