freenode/#lisp - IRC Chatlog
Search
18:31:13
White_Flame
when RAM is measured in KB, the footprint of just the CL symbols can be challenging
18:38:28
_death
Odin-: I played with ulisp a month ago or so (on an m5stickc), but indeed it's a bit limited (no compilation/macros).. I think something like a vm running clisp's bytecode or a subset of it could be nice
20:54:44
MrtnDk[m]
phoe: I'm on Matrix. I'm not sure how to join an IRC room, even if it is bridged and has no invitation requirement.
20:56:05
phoe
hmmm, https://gist.github.com/fstab/ce805d3001600ac147b79d413668770d says, "join the room #freenode_##lisp:matrix.org"
21:01:13
phoe
a person who can find a solution in ten seconds can sometimes save someone ten minutes
21:01:17
MrtnDk[m]
Sorry, I often suck at searchxing. Even at coming up with the idea to do it some times.
21:01:37
Odin-
I'm glad. Because it actually seems to be getting rarer and rarer that searching works like it should. :p
21:20:26
mason
Anyone know if https://gitlab.common-lisp.net/vsedach/cliki2 is suffering a temporary error, or some more permanent state?
21:35:21
MrtnDk[m]
* On the matrix it might be room #freenode_#common-lisp.net I'm guessing, if it be bridged.
21:40:44
etimmons
Mrtn Dk: yes (coming from a fellow Matrix user on that channel). Also, my understanding is that all of Freenode is "bridged"
22:02:22
nij
Hello! I recently started writing a personal project using emacs-lisp. It crashed me on performence so I wonder if I should switch back to common lisp.
22:02:57
nij
For now, my database is just a folder with ~7500 files. Each file contains one lisp list.
22:03:50
nij
I have never dealt with a database before, so I must be doing something wrong. But in any case, the performence is very bad. It is not clear in my head when I should read/write from/to the database, or when I should just use the variable to hold things.
22:04:30
nij
I wonder if switching back to common-lisp would solve this problem. I've heard of the power of CLOS, but have never experienced it in depth. That's my situation. So.. any advice would be appreciated.
22:18:05
phoe
also, yes, sqlite - unless you'd like to try a pure-CL solution of sorts, or try to reinvent the wheel for some personal learning
22:27:10
phoe
do you know what is a relational database, and how its data differs from object-oriented data?
22:27:27
phoe
if not, you should - and then you'll know that ORM is a toolkit that attempts to bridge that difference
22:28:22
nij
relational dbs are based on spreadsheets, and oo data are lots of classes,instances, and slots?
22:29:11
moon-child
data representation is slightly similar, and problem domain has some overlap, but the two have wildly different roles
22:29:53
moon-child
spreadsheet is end-user data flow & analysis. Relational db is relational algebra (=academia goodness) + long-term data storage & representation
22:45:16
White_Flame
nij: for something that's going to stay under 10MB for years from now, a simple persistence to log file and keeping all of it in RAM would be fine :-P
22:57:51
markasoftware
the simplest thing to do is just maintain it all in memory under a single top level variable, then use cl-marshal or similar to serialize it to a single file on disk periodically
23:26:43
jcowan
The main advantage of SQLite in this context is that it works very hard to either persist your data or fail.
23:29:25
jcowan
If you have an easy sqlite setup, then "INSERT INTO log VALUES (?)" with ? bound to the line to be logged is just about as easy as writing to a file.
23:41:46
Xach
yes, it would be much safer and more reliable. but if you go the diy route, a log is an easy step beyond stashing all the data from memory periodically.
23:43:15
Xach
and by log, i don't mean syslog things, i mean writing out data records, as in "write-ahead logs" or "commit logs"
0:00:33
White_Flame
and again, this is only if SQL is not worth learning for the scale of your project
2:07:34
aeth
postmodern (for postgresql) was the general recommendation back in the day. Idk if it still holds
2:08:59
copec
That's what I was looking at, and then looking at Mito since it is high on all my searches
4:49:23
fiddlerwoaroof
I generally think Postmodern or the sqlite wrappers are a good choice if you need a "Real DB"
4:50:06
fiddlerwoaroof
However, most programs work really well with a well-thought-out system of files for persistence
4:50:37
fiddlerwoaroof
e.g. logging updates as lisp forms and then replaying the log when your system starts up
4:51:22
fiddlerwoaroof
SQLite is useful here, because the developers of SQLite have put a lot of effort into handling the edge cases around "writing reliably to secondary storage"
4:54:24
fiddlerwoaroof
Anyways, would it be reasonable for EQL specializers to only hold a weak reference to the object they reference?
4:58:07
no-defun-allowed
From the protocol level, it makes sense. From the implementation level, I wonder how much having to remove methods which will never be called complicates things, and if having the weak-value indirection slows down things.
4:59:03
fiddlerwoaroof
Yeah, you'd probably need to make the GC aware of generic functions or something
5:01:24
no-defun-allowed
Or you could mess with the discriminator function constant vector and MMU to get similar performance.
5:02:30
fiddlerwoaroof
The reason I'm wondering is that it seems like there might be some interesting patterns around implementing protocols inside a LET or a DEFUN
5:02:45
no-defun-allowed
When the GC runs, it would have to replace any eql-specializer values that have been collected with some value - nah, we don't do anything with the value other than test it with EQL, so you couldn't use a memory trap to re-compile with dead methods.
5:04:58
fiddlerwoaroof
If the GC special-cased generic functions, it could remove the dead methods and collect the method objects
5:05:35
fiddlerwoaroof
Your method combination would have to be designed to handle dangling references, but that seems relatively easy
5:07:29
no-defun-allowed
If the function was removed, oh, there could still be mutator threads in the discriminating function, so that's true.
5:42:01
MrtnDk[m]
nij just tell us; are you raised in a Microsoft Windows environment, complete with Microsoft office, etc?
5:43:49
MrtnDk[m]
Never mind it will get off topic, and it seems you already found a solution for the db-stuff.