freenode/#lisp - IRC Chatlog
Search
17:48:05
mfiano
I normally use an :after method for initialize-instance for this type of thing. With shared-initialize does that still make sense?
17:49:08
Bike
initialize-instance methods make sense when you want something to happen only during initialization (like through make-instance) but not other times (change-class, reinitialize-instance, make-instances-obsolete)
18:28:48
Xach
before when i was interactively kicking off builds, cutting the time down made a huge difference
18:31:05
Xach
I'd still like to pursue it. It would be nice to come up with a system that I could run on e.g. 100 cloud servers and complete in 5 minutes or something.
18:33:53
srji
I am trying to extract elements from a sequence and want to copy them to a new list. https://gitlab.com/snippets/1896440
18:35:38
ck_
Xach: well, its about to be the season for more indoor activities. maybe you will be coerced into continuing .. by snow for example
18:36:18
Xach
ck_: it's possible but that is also the best time to harvest trees for firewood and lumber - less sap to dry later.
20:02:34
thijso
I'm looking for a system/library to facilitate kind of a disk-backed memory store. Something that saves the data to disk regularly, but a little loss is acceptable. Is there something like that for Lisp already? Might cl-prevalence be a good fit? Ubiquitous looks kinda like something also, except it's documentation is about persistent _configuration_ storage. Any other suggestions?
20:03:18
thijso
I'm thinking I might just start out with plists (or maybe a hash) and just serialize that to disk with alexandria or something.
20:40:54
thijso
In the case that the id's are strings, is it better to use an eql hash or coerce the strings into keys (with intern)? Or is it basically the same difference? Or third option?
20:45:48
saturn2
interned symbols don't get garbage collected, so don't use them unless you want them to stick around forever
21:34:15
White_Flame
you can manually intern your keys using a separate string->self equal hashtable first, then your main content will have eq strings
21:54:18
thijso
Have a separate hashtable mapping the "string keys" to something else, is that what you mean?
21:55:21
White_Flame
yes, map "foo" => "foo", in a #'EQUAL hashtable. Then when you do (gethash "foo" *table*), it'll return the exact same "foo" string instance, which can be then eq compared in a table, without converting it to a symbol
21:55:49
pjb
That said, it all depends on the speed of the hash function, which should be O(1) fast anyways. So using an equal hash table should not be significantly slower than using an eq hash table.
21:56:53
White_Flame
again, it all depends on where you want the cpu to spend time, if this is an optimization issue
21:57:15
White_Flame
and depending on what you're doing, it might be advantageous to keep the data as a string
22:00:01
thijso
I'll have to look into that map "foo" => "foo" trick later, because it's late here and I'm getting a 'does-not-compute' error in my head atm... ;)
22:28:12
White_Flame
thijso: there may be many string instances of "foo". however, the one that is the value in that hashtable is the "canonical" one. by always looking up your string in that hashtable and only using the value from there (lazily adding to it if the key isn't found), you basically intern your strings to EQ-able instances