freenode/#lisp - IRC Chatlog
Search
2:30:49
ahungry
Does scheme have something similar to a plist in CL or a map in Clojure? A simple way to get a field out like (getf '(:x 1 :y 2) :x) => 1 - I know of assoc - I guess I could write a wrapper to get the cadr of one
2:32:37
ahungry
Seems that wouldn't really solve my want of having a simple literal format for the data though, so I'd probably just have to make something that walks a list 2 atoms at a time and stops if the first matches my lookup
2:38:35
p_l
ahungry: not sure how standard it is, but: https://groups.csail.mit.edu/mac/ftpdir/scheme-7.4/doc-html/scheme_12.html
3:03:43
solrize
ahungry, there's some srfi's for all kinds of stuff like that... #scheme would know more
3:05:38
aeth
specifically, jcowan will know more about Scheme implementation support of $feature in #scheme
4:11:29
fiddlerwoaroof
In terms of LOOP alternatives, there's also https://github.com/Shinmera/for, which I prefer to iterate, if I'm going to use a library
9:27:37
ogamita
shrdlu68: I dare you write an implementation of LISP in Common Lisp. Call it (ql:quickload "lisp²")
10:14:36
d4ryus
hi, is there a way to create a in memory stream? I would like to pass one 'end' to a thread running uiop/run-programm and the other 'end' to a thread which reads from it.
11:06:03
lieven
the standard doesn't describe threads so adding those would be an exercise for the reader
11:07:51
d4ryus
but sadly uiop/run-programm does not write into the stream until the programm has finished :(
11:08:08
lieven
a good match for that problem is the mailbox API. it's native in lispworks and there are ports to other lisps
13:05:40
jmercouris
suggestons for ORM for CL? I'm already experienced with Crane but am open to other solutions
13:16:02
jmercouris
The problem that I have with ORMs is centered around issues with forein key relationships
13:16:07
jackdaniel
updating db deserves its own application-specific api but mixing it with object access isn't a fine idea (conceptually speaking)
13:17:06
jmercouris
do you have some sort of SQL directory where you write scripts that get executed manually to udpate the schema as necessary?
13:17:34
jmercouris
aka, how do you handle migrations, without an ORM that will generate them for you automatically
13:18:33
jackdaniel
keeping object relations and database relations model consistent is a hard (and unnecessary) thing.
13:18:56
jackdaniel
as I said, having abstraction to *access* database is fine, just mixing it with your objects is not
13:19:36
jackdaniel
as of keeping sql scripts in a directory: it is a fine idea like any other, but writing dsl for updating your relation and using this dsl in your migration functions is fine as well
13:22:12
jackdaniel
In other words you ask me how would I handle a problem without ORM which is introduced by ORM itself (automatic migration of class relations)
13:23:40
jmercouris
and we are just using raw SQL to access different columns and rows from a database
13:24:22
jmercouris
we'll change the code and change the query to also use the new column, however we have to ensure that when the new code is run, the database also has the new column
13:25:19
jmercouris
ok ok ok, so I re-read your message, and let me see if I understand what you are suggesting
13:25:49
jmercouris
you are suggesting that a SQL dir to update things is fine, and what-not, but you'd have something like a "DB-Access" package or something that you'd use to abstract getting data from the database
13:27:02
jmercouris
and you are saying that maintaining parity between the database structure and this DB-Access abstraction is not a huge issue since the code is all in one place, or what?
13:28:17
jackdaniel
I'm saying that your persistent data model is a separate thing than your runtime class hierarchy. When you change database schema, you need to write migration function (which calls dsl or loads hand-written scripts) which: a) updates schema, b) bumps databa schema version number
13:29:21
jmercouris
so, on the start of program execution, you make sure that these hand written scripts are run?
13:29:49
jmercouris
aka you check that the schema version number is as expected, and if not, you traverse your functions to get to your current version
13:30:16
jmercouris
do you maintain a separate table in your database for this? something like "schema-version"? that has an int or something?
13:30:49
jackdaniel
that's the way to do it. it may be a bit more general, like next-meta-information ;-)
13:30:53
jmercouris
have you found yourself doing this a few times? is there a library for this? do you think a library to do this would be useful?
13:31:54
jackdaniel
I'm working with a codebase which manages database that way and I find this abstraction very convincing. as of library: migration (if we skip dsl and actual migration script body) is a dozen of lines or so – such library wouldn't be useful
13:40:11
ogamita
jmercouris: ORM = impedence mismatch. Basically the problem is that to do it conveniently, you need to introduce a cache in the client host, and when each client has its own cache, then things break apart.
13:41:05
ogamita
jmercouris: you could have caches on the clients if they were integrated in a OO database, ie. synchronized with the other clients. But then, what do you think will occur when your OODB software needs to synchronise hundreds of clients!?!?
13:45:18
jmercouris
you are right, I actually want an object database, but none of them are mature enough to use
13:45:38
ogamita
Well, EOF-1 was not that bad, but it has been dropped by Apple, so it must have had some problem that I didn't see…
13:46:55
jmercouris
there was nothing enlightening in their marketing materials about how to obtain a copy
13:48:20
jmercouris
however I'm not interested in writing a CL object database at this time, I have enough on my plate
13:48:57
jmercouris
right, I mentioned that above, but it costs money and I don't even know how to buy it
13:48:59
dlowe
I've found through experience that the best DB abstraction is treating the whole DB like the backend for a very capable abstract collection.
13:49:50
ogamita
jmercouris: note that your objects can still know how to save and load themselves in a sql database!
13:49:51
dlowe
anything more granular and your abstractions will leak all over the place and you'll be writing bare SQL and cursing
13:51:36
jmercouris
however these defmethods will be within the db abstraction package and probably only used locally in functions