freenode/#lisp - IRC Chatlog
Search
19:20:14
akr
Hello, could anyone tell me roughly how painful would be updating a project from SBCL 1.1.14 to 1.4.5? This project has around a 100 dependencies.
19:25:29
Bike
akr: if the project doesn't use sb-ext i imagine it would go pretty smoothly. if it does (or other sbcl specific packages) you might need to make a few adjustments.
19:27:05
aeth
There might be bug fixes in obscure corners of elaborate parts of the language like FORMAT or LOOP that accidentally didn't follow the standard exactly.
19:27:30
aeth
So if your program already runs on different CLs there's probably going to be fewer surprises.
19:28:17
White_Flame
akr: if you update your dependencies as well (which is likely where SBCL specifics might lie, in back-end implementations), I doubt you'll have any major issues at all
19:30:48
aeth
in particular, things that might affect you are "incompatible change" and "minor incompatible change"
19:34:09
verisimilitude
A properly written Common Lisp program should face no issues in this situation, akr.
19:34:11
pjb
akr: yes, that's about it: if you wrote (or use) code that is accidentally not conforming, but just worked so far, and the implementation changes to become more conforming, you can have to do some maintenance. Also, if you used internal API, but then it was your fault, you've always been told not to use internal APIs >:-}>
19:35:07
aeth
an example from 1.3.14: "minor incompatible change: the SB-PCL walker no longer recognizes macros expanding into a DECLARE expression. This is not a language change, since ANSI forbids such usage (X3J13 issue DECLARE-MACROS:FLUSH)."
19:35:12
verisimilitude
It's good practice to test your code across multiple implementations, akr, not just to test for conformance, but also because different implementations perform different optimizations and inspections and so you can realize smaller issues in this way as well.
19:36:50
aeth
pjb: Never use internal APIs *directly*. If you could never use them then CFFI, bordeaux-threads, etc., couldn't work. Just make stuff like that the responsibility of some library author to maintain, if possible.
19:39:36
akr
okay, so I thought I'd give it a try, but I'm getting a build error that I'm not sure how to debug
19:39:39
akr
The symbol "*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*" is not external in the ASDF/FIND-SYSTEM package.
19:40:05
aeth
ASDF ships with the implementation and so that's a newer version of ASDF with a newer ASDF API.
19:46:51
aeth
akr: have you tried loading the system from quicklisp to see if you get the same error? (unfortunately, you might have discovered a bug in buildapp, though)
19:50:30
aeth
akr: Unless I'm misunderstanding what the "--load-system" means in buildapp, there's an ASDF system, so you could load it via Quicklisp in SLIME with (ql:quickload :lisperator) if it knew where to find lisperator
19:50:35
White_Flame
I've manually copied libraries from quicklisp into non-ql builds. if you have >100 it might be a lot, but the directories under QL are independently usable, if you want the latest versions whose inter-dependencies are tested
21:14:41
aeth
cqs: the let creates a new binding, but setf in this context (or setq in general) sets an existing binding
21:15:27
aeth
cqs: so the let is basically "int foo;" or "int foo = 42;" and the setf is basically "foo = 42;"
21:15:53
aeth
except there's no type there so it's more like a language that uses "var" or "local" or even "let" rather than "int"
22:41:38
minion
cqs: please see PCL: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).