freenode/#lisp - IRC Chatlog
Search
19:27:31
decent-username
I guess I could create a github account over Tor. Connecting to the web with javascript enabled and over the clearnet is spooky.
19:27:56
wayneeseguin
lotuseater: ZOMG <3 thank you so much for this, I've been reading ancient posts and code to learn, these videos appear to be exactly what I have been looking for <3
20:05:45
pve
lotuseater: it's a bit of a joke, but I made this a long time ago: https://github.com/pve1/incongruent-methods
20:12:12
daphnis
i have a function that takes symbols as arguments that i want to export; but when i call it from another package, the symbols passed to it are from that other package .. what's the normal way to solve this?
20:15:08
Bike
it depends on the nature of the function. sometimes it's nice to allow multiple namespaces
20:17:55
phoe
this changes the interface of that package, and I have no idea why you would like to modify it as a part of standard program operation
20:22:51
daphnis
phoe: say i have a function #'foo in package A that returns a list of entities to which the symbol names given as arguments pertain. f.ex., (foo 'berries) returns a list of berries and (foo 'fruits 'berries) returns a list of fruits and berries. this function can't be exported, it seems
20:32:27
Kabriel
Is there an easy way to replace a symbol in the restvar (e.g. &body) in a macro definition so that you can provide that symbol to the user?
20:33:07
Kabriel
Not provide, but allow them to use it in the body, like loop allows you to use "it".
20:46:41
Kabriel
I would like to use it in a function in a second package, where I can actually use the symbol "line" defined in the macro.
20:47:03
Kabriel
because the packages are different, I have some-package-1::line vs some-package-2::line.
20:48:00
Kabriel
Is there an easy way to replace the symbol in the &body, so that the user of the macro does not have to specifiy the symbol.
20:48:50
iarebatman
Any ECL people on that can help me out? Whenever I try to load cffi on ECL (on windows..sorry....) - I get an error because cffi/toolchain/c-toolchain.lisp is trying to access C:*CC* - which doesn't appear to be set to anything by default in my ECL session
20:51:45
daphnis
pve: yeah, sorry, i meant: it can be exported, but it won't function the same way in B as in A.
20:51:55
iarebatman
I just managed to compile ecl 20.4.24 x64 via msvc compiler as specified in the docs finally. I tried switching to :C and (setf *CC* "gcc") for example, but that doesn't seem to matter.
20:52:00
Kabriel
There must be some way to do it, because loop can figure out what some-package-1:for is.
20:53:17
daphnis
since i only use the symbols as names, i don't want to have to specify their package. maybe keywords are the answer to this, as Bike suggested
21:01:09
Bike
it's just that when the loop macro does its parsing, it looks for loop syntax based on symbol names rather than comparison with a symbol.
21:26:54
Kabriel
Bike: so I guess the way to do that is to parse the body forms; i.e. there isn't some facility in language to do this easily.
23:51:55
Josh_2
just got done with a pretty trivial but very extensible blogging library for hunchentoot https://github.com/K1D77A/cl-bloggy if anyone is interested, i'd appreciate the feedback
2:36:34
borei
damn was while ago i visited channel. changed my job, road is pretty bumpy, especially current covid days
2:39:01
borei
i have question - what is the "proper way" to run lisp application. Currently im using ASDF to load modules my app depends on, but is there another way ?
2:40:46
White_Flame
as far as actually invoking, either repl or load everything up and create an exectuable
4:22:53
bqv
Context: would like to port this https://github.com/NixOS/nixpkgs/blob/8585991bfb629edda1e42c191bef935d9d70d690/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh#L107
4:27:15
fiddlerwoaroof
It looks like, if CFFI is loaded, that might just work? https://github.com/NixOS/nixpkgs/blob/8585991bfb629edda1e42c191bef935d9d70d690/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh#L102-L103
4:28:11
bqv
Ah, hm. Maybe it's just not pulling through then... can I safely remove the #+cffi to test?
4:31:19
fiddlerwoaroof
https://github.com/NixOS/nixpkgs/blob/8585991bfb629edda1e42c191bef935d9d70d690/pkgs/development/lisp-modules/clwrapper/build-with-lisp.sh
4:31:43
fiddlerwoaroof
Looking here, it looks like they support sbcl/ecl/clisp, maybe just add a case here for ccl?
4:33:30
bqv
What would the entry there contain? ccl is already supported, per my vague understanding, and I get packages to build
4:34:42
fiddlerwoaroof
Yeah, I think that's right, this looks like ccl: https://github.com/NixOS/nixpkgs/blob/8585991bfb629edda1e42c191bef935d9d70d690/pkgs/development/lisp-modules/clwrapper/setup-hook.sh#L18-L19
4:35:51
fiddlerwoaroof
I think you might try making sure that cffi is always loaded, and that code might cleanup the shared libraries
4:37:19
fiddlerwoaroof
Otherwise, look here: https://ccl.clozure.com/docs/ccl.html#the-foreign-function-interface
5:44:25
bqv
Still no dice. Not sure what's wrong. Don't quite understand how this works well enough to debug