freenode/#lisp - IRC Chatlog
Search
19:06:39
aeth
SQL might be like Scheme, I don't know enough about it. And I think that's literally it, unless including old languages with competing commercial implementations (Fortran, COBOL, Pascal, etc.)
19:11:16
q1999
anyone developing in sbcl on emacs using slime who is willing to help with a (probably setup) problem?
19:11:33
aeth
If you went into #haskell how many people are using the GHC vs. other implementations? Here, the CCLers are a vocal minority and pretty much every SBCLer who writes libraries tests on at least CCL
19:13:04
aeth
I think ECL is #3 here. It might not be #3 in the Lisp community in general. It's probably really hard to determine a #3
19:17:26
q1999
ok. installed sbcl, using emacs 24.5.1 on windows 7, using slime from elpa. when I create a new package using quicklisp, I can quickload the package and use in-package to move the reple from cl-user to package. but when I close emacse, go to the root, start slime and try to quickload the same package, all I get is SYSTEM-NOT-FOUND. It is driving me up the wall. uninstalled and reinstalled everything except emacs, but still no go.
19:20:38
q1999
I start slime from dired buffer or test.lisp buffer, the package asd and lisp are one folder (named after the package) down. starting slime from within that folder results in the same pesky SYSTEM-NOT-FOUND.
19:22:36
Xach
q1999: not at all. you can put stuff anywhere. but you do have to teach asdf how to find it (or put it in a place asdf already knows about).
19:23:07
Xach
q1999: one easy way to teach asdf is (push "c:/Users/.../path/to/project/" asdf:*central-registry*)
19:23:32
Xach
q1999: quicklisp also extends asdf by making it search <quicklisp-directory>/local-projects/ specially.
19:24:04
Xach
there are ways to teach asdf to scan directory trees. i find the asdf config syntax too complicated to remember so i don't use it much.
19:25:20
q1999
ok. I'll first try the push. (I was following Baggers on youtube and there was no mention of this. probably should have rtfm, right?)
19:27:08
Xach
q1999: I'm not sure - it's something that you internalize fairly early, so maybe it wasn't on his mind to explain
19:31:36
q1999
I tried a quick and dirty, but for now no success with the push. think I need to mess about a bit, read about the manual about push.
19:36:13
pjb
q1999: in general, I would advise to use #P"" instead of strings for paths, notably if they contain system specific notations (eg. ~/ on unix, C: on ms-dos).
19:36:43
Xach
q1999: what do you get if you try (probe-file "c:/Users/SENNAC/Desktop/Fotos/Nieuwe map (5)/bit-stream.asd")?
19:38:57
pjb
Now, with *central-registry*, you may want to use pushnew: (pushnew #P"c:/Users/SENNAC/Desktop/Fotos/Nieuwe map (5)/" asdf:*central-registry* :test (function equalp))
19:39:23
pjb
q1999: probe, like open, merges the path with *default-pathname-defaults*, not with the paths in asdf:*central-registry*.
19:40:13
pjb
(find-if (lambda (*default-pathname-defaults*) (probe-file #P"bit-stream.asd")) asdf:*central-registry*)
19:46:10
q1999
tried the pushnew but am now on a merry go round, lol. there is a bit-stream.asd in the dir.
19:48:12
q1999
after the pushnew and a ql:quickload :bit-stream, slime came back with: (ql:quickload :bit-stream)
19:58:59
q1999
thanks for now Xach and pjb. I'm parting to have a closer look at asdf registry docs and your feedback. If you don't see me back soon, your input helped to solve my problem.
20:03:35
aeth
Is there a way to print a CLOS object and all of its slots? The debugger is not a good solution because there are just so many objects. I have to dissect them programatically.
0:12:15
on_ion
is there a temp setting of a symbol? ie (while-set (abc 5) ...) where abc is returned to original value? probably LET ?
0:48:14
edgar-rft
theemacsshibe[m], a few more documents are linked in the "Reference" section of https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager
0:49:33
theemacsshibe[m]
i'm just trying to write some simple GUI applications and honestly most of the background crap goes over my head
1:00:35
drmeister
It says when the second argument is t: Returns a documentation string specialized on the class of the argument x itself. For example, if x is a function, the documentation string associated with the function x is returned.
1:01:20
Bike
the second argument of documentation is only not t when the first argument is a name rather than a thing
1:03:34
Bike
in clasp functions don't actually have docstrings, so if you have like (lambda () "docstring" nil) there's no way to get at the string, as it's destroyed during compilation
1:03:34
drmeister
Peter Seibel's "manifest" system doesn't work on Clasp - but parts of it - most importantly "toot" does.
5:13:01
beach
theemacsshibe[m]: The #clim channel will answer questions about CLIM and McCLIM. I usually hang out there, but I am traveling at the moment. I'll be back online on Wednesday.
5:20:39
beach
Also, scymtym is working on the reader (called Eclector) which used to be part of SICL, but that is now in a separate repository.
5:22:25
beach
I am trying to extract "modules" from SICL into separate repositories as much as is reasonable.
5:31:18
vtomole
As long as it's not split up too much. I think this stays true to SICL's goal of separating a CL implementation into modules. An implementer will clone the sub-components he/she wants.
5:31:31
beach
stylewarning: Since the basic specification (i.e. the Common Lisp HyperSpec) is stable, I don't think it will be a big problem.
5:33:28
beach
vtomole: It is still non-trivial to use those modules though. For Eclector, either an implementation uses it as a second reader (it has to have a reader in order to read the Eclector source code) or the implementation must cross compile on a different implementation the way SICl does.
5:37:01
beach
Right. But you are right. Take Eclector again. It has functionality that extends the Common Lisp HyperSpec, and that functionality is essential for client code, in particular source tracking. And it is important not to break client code that uses it.
5:39:37
vtomole
beach: To me, Common Lisp implementations are overwhelming. How is the back-end of SICL going? Are you still planning on compiling to x86_64? How much resources (time) does it take to write a "good" optimizing compiler?
5:42:52
beach
vtomole: The back-end is almost done. I have a separate repository containing an assembler for x86-64.
5:44:25
beach
vtomole: Hard to say how long it takes. I am not working on it full time, so it is taking longer.
5:46:15
vtomole
For sure, a lot of implementors compile their languages to LLVM because they don't want to deal with writing optimizers. But you are not worried about performance being equal to SBCL are you?
5:48:29
beach
It doesn't know how to do things like type inference, path replication, escape analysis and other things that are crucial to Common Lisp performance.