freenode/#lisp - IRC Chatlog
Search
9:47:01
McParen
hello, does somebody have experience with cffi-groveler? i am considering including the groveler to substitute a hard-coded set of constants in my ncurses library, and I cannot assess how risky it is to have a groveling step when the library is built.
9:50:57
heisig
McParen: I use the groveler for cl-mpi (https://github.com/marcoheisig/cl-mpi), if you need some inspiration.
9:54:04
McParen
the cl-test-grid often reports problems (or so i udnerstand it) with the groveler: https://common-lisp.net/project/cl-test-grid/library/cl-mpi.html
9:55:39
heisig
Oh, but that is because cl-mpi requires a particular C compiler (mpicc). If are happy with the default, or with something widely used like gcc, there shouldn't be any problems.
9:57:45
McParen
it is not only cl-mpi, other projects i checked also show problems on cl-test-grid: https://common-lisp.net/project/cl-test-grid/library/cl-charms.html
10:00:50
heisig
Is there a reason why cl-test-grid only tests sbcl-1.3.2 on arm, or does it only show test failures?
10:01:34
McParen
this varies from month to month, i think that depends on who contributes the test cases.
10:02:55
McParen
I only need a few integer constants, so I dont know whether it is less problematic to simply hardcode them or to add a dependence to a C compiler, include files, etc.
10:03:56
heisig
No, don't hardcode constants. C is not dynamically typed, so you can get some very bizarre bugs that way.
10:05:05
heisig
Asking the C compiler is the right way. Or, you could rewrite all the C dependencies in Lisp :)
10:07:32
McParen
I do not know how often the integers behind the defines are changed or whether they are equal between different systems
10:07:52
heisig
Fun fact: A C constant is not even a Lisp constant, because the Lisp process might live longer than the version of the C library in use.
10:08:21
heisig
This can actually happen if you reload dynamic libraries after resuming from save-lisp-and-die.
10:11:59
aeth
heisig: I assume that C type sizes won't change, although of course, that's only an assumption
10:13:40
McParen
Shinmera: does any of your systems have cffi-grovel as a dependence? if yes, did it cause problems for users?
10:14:11
Shinmera
I hard-code constants per platform and have not had issues because of that so far.
10:14:56
aeth
edgar-rft: I assume that the language I'm using is constant, which works for CL so far
10:14:56
Shinmera
Well, not just the C compiler dependency, but also the dependency on the library being installed (with header files to boot)
10:15:07
aeth
oone of these days someone's going to remove the deprecated functions like remove-if-not, though
10:18:13
heisig
Shinmera: I think you can re-grovel, if you really care about the life of your Lisp image. But nowadays, I just try to avoid C dependencies.
10:20:10
heisig
Only if your goal is to deploy long-lasting images. If you just want to obtain an executable, feel free to forget about this issue.
10:21:20
heisig
You can only have one active MPI implementation at a time. But for testing, it is nice if you can change the implementation while your REPL stays alive.
10:22:00
aeth
heisig: they could remove remove-if-not via (remove-if-not (complement #'deprecatedp) functions)
10:24:38
heisig
Nah. Should there ever be people with enough influence to release a new CL standard, they will also have enough wisdom not to change the CL package.
10:56:48
vms14
Using #<Package "COMMON-LISP"> in #<Package "GAME"> would cause name conflicts with symbols already present in that package:DEFPACKAGE COMMON-LISP:DEFPACKAGE meh
10:57:37
vms14
how should I use defpackage in a way it will work in all implementations without troubles? in sbcl I saw no problem
10:59:56
vms14
it's weird, if I put ccl --load game.lisp I see no warnings, but with slime I get a restart
11:05:25
_death
packages are stateful, so you may get yourself into a "weird" state.. if you're not sure about the current state, one way is to restart your lisp and try again
11:07:17
_death
you can also explicitly qualify symbols to help in figuring out the state, e.g., using cl:*package* to determine the current package
11:09:01
_death
or (cl:describe 'defpackage) to see information about the defpackage symbol in the current package
11:10:19
vms14
why defpackage gives me errors, and I even have to put the package name like cl:defpackage
11:12:48
vms14
the issue is defpackage tells me there is a shadowing problem with the 'defpackage symbol once I :use :common-lisp
11:17:28
_death
transient issues like getting into a "weird state" during development are ok to ignore, but for your written code you should understand 100% why something works or not
11:17:56
vms14
it's weird, because the only thing I've done was to quickload clx and defpackage then
11:27:27
theosvoitha
Hello. Am just curious. What is lisp still used for? I somehow like it. am learning programming for data science.
11:28:49
no-defun-allowed
"Having asked about the possibility that there are real people out there who use Lisp (as opposed to AI People who are known to be non-real and having received no answers, I can only conclude that LISP is not being used and that it is not, therefore, a real language." — Lisp Pointers, 198something
11:29:48
no-defun-allowed
A few things. Some that spring to mind include programs that give advice to traders, and the (in my opinion) best quantum computer compiler and simulator.
11:31:03
heisig
theosvoitha: I think there isn't a single domain where Lisp hasn't been used successfully. See https://lisp-lang.org/success/ for a few examples.
11:32:01
no-defun-allowed
There's also some game developers using Lisp, high performance computing people, Internet server making people, and generally it's usable for anything.
11:36:13
theosvoitha
also i found that Emacs Lisp is a dialect of the Lisp programming language used as a scripting language by Emacs
11:37:05
beach
theosvoitha: This channel is dedicated to Common Lisp. It has an ANSI standard, and multiple implementations.
11:37:32
beach
theosvoitha: Each implementation is independent. Common Lisp is not a single-implementation language.
11:38:09
beach
theosvoitha: Currently, the best suggestion for a newbie bundle seems to be Portacle.
11:38:30
minion
theosvoitha: direct your attention towards 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).
11:41:29
beach
theosvoitha: The Lispworks document is the standard. It is not a pedagogical document. It is the definition of the language.
11:58:31
vms14
specially with macros, creating dsl is very easy, which really helps at creating big and complex software
12:00:21
vms14
this is very important, since there is no compile cycle nor even save-file/call-interpreter
13:36:16
edgar-rft
theosvoitha: in case nobody has already mentioned it before, there is a Common Lisp Wiki with lots of useful information -> https://www.cliki.net/Getting%20Started
18:24:32
eta
is there a version of MACROLET that works like LABELS, i.e. you can reference variables in the lexical environment?
18:31:00
eta
> Declarations and macrolet and symbol-macrolet definitions affect the local macro definitions in a macrolet, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that lexical environment.
18:35:46
pjb
eta: notably, macros are expanded at compilation time, while lexical bindings are established at run-time. Like, in a 100 years, on a different computer (probably an emulator then).
18:36:03
eta
pjb, I want to write (let ((a 1)) (macrolet ((do-thing-with-a (b) `(+ ,a ,b))) (do-thing-with-a 2)))
18:36:57
pjb
eta: if you want to have variables that you can mutate in the macro (at macroexpansion time/compilation time) and then access it (or not) at run-time, you will need to write your own MACRO-LET macro.
18:37:55
pjb
(symbol-macrolet ((a 1)) (macrolet ((do-thing-with-a (b) `(+ ,a ,b))) (do-thing-with-a 2))) #| --> 3 |# seems conforming to me.
18:38:26
pjb
eta: if you changed ,a to a it would indeed work with let, since a would be referenced a run-time then.
18:39:03
eta
pjb, I hadn't seen that SYMBOL-MACROLET trick before (nice!), but I'll just go with a instead of ,a for this case :)
18:40:31
pjb
eta: just keep in mind of WHEN different expressions are evaluated. (macroexpansion time, compilation time, load time, run-time, when evaluated by a call to EVAL, when read (reader macros, #.) etc).
18:49:52
jcowan
My sense is that a construct for defining recursive local macros is not sufficiently useful.
18:50:40
jcowan
Indeed, I think it may be unnecessary, given that the result of a macro procedure is itself expanded again.
18:51:18
jcowan
So it would only come up if you want macro A and B, declared in the same scope, to invoke one another in their bodies