10:32:28caffei might as well get this out of the way: i'm new to lisp. i'll try and stick to docs before asking for help here. i may inevitably ask a stupid question at some point, but i'll try and keep it to a minimum.

11:23:25schweersas much as I’d like the contrary to be true: using CL to write a program doesn’t automatically make it 'smart'

11:24:09_deaththe other day I "reversed" ql-setup::dumb-string-hash.. the result was still dumb though

11:26:29caffei mostly mean in what the language or programming environment has to offer... in assembly, for example; not much is really done for you. you have to do everything yourself. C is the same to some extent.

11:28:02caffeit sounds silly to say, but it reminds me of applesoft, very vaguely

11:28:19schweersI finally tried out CFFI the other day just to poke around in an mmap()ed region and was amazed

11:28:57antoszkacaffe: Common Lisp is nice about being able (but not having) to control the whole compiler right down almost to the metal. You can see the disassembly of your compiled functions right in the REPL.

11:29:34schweersantoszka: if you have a compiler which compiles directly to native code

11:29:42caffethe source is very easy to read, even if uncommented... you have the same sort of live interpreted enviroment... applesoft of course is just a lot more castrated. it's a nice break from the write-compile-test-edit grind

11:29:57schweersspeaking of which: is clisp still under development/maintainance?

11:33:32caffeyeah, the REPL is the sort of thing i've wished i had in other languages; but hadn't really seen anything vaguely similar to, sort of basic interpreters

14:49:33phoeDoes LOCAL-TIME provide any kind of precise timestamp difference? All I can see is TIMESTAMP-DIFFERENCE which returns a double-float, where I want an integer - seconds or nanoseconds of difference between the two timestamps.

14:50:13phoeOr should I create my own function for that based on subtracting two TIMESTAMP-TO-UNIX values?

15:58:16beachschweers: Code that uses your definition would look like normal Common Lisp code, but the symbols will be different because the package is part of the symbol, so the compiler will not attempt to optimize for those.

15:58:23schweersmy very own defun, which is exaclty the same as the original \o/

15:59:29schweersbeach: now that I know that is legal I know how that works, although I have to admit that I don’t have that much experience with how the reader treats packages

16:01:08beachIf the reader sees a symbol without a package prefix, it interns it in the package that is the value of *PACKAGE*.

16:01:26schweersI know the basics, I just never implemented anything of the sort ;)

16:04:45schweersbeach: that is also not quite true, as the symbol `defun' is not interned into my current package, although it has no package prefix. It is only interned into the current package if it is not interned "anywhere else where it is visible"

16:08:45schweerssadly common lisp package and symbol semantics are not implementable in elisp. At least I couldn’t find any way

16:09:29beachschweers: So what I said was true. It does intern it in the current package. However, "intern in the current package" takes used packages in to account through the definition of "accessible".

16:09:59schweerswell, you said that it happens when there is no package prefix, which is not true by itself :-P

17:05:31kencauseyI seem to be missing something basic regarding quicklisp. Once I have install some systems end the day, and come back the next day, what is the method for using the systems again? I'm on sbcl Windows. It doesn't seem that sbcl or asdf are aware of the quicklisp paths although quicklisp is loaded (via quicklisp/setup.lisp).