freenode/#lisp - IRC Chatlog
Search
3:30:21
edgar-rft
skidd0, is the Lisp REPL not text enough? Or what specifically are you looking for?
3:31:38
skidd0
so, mostly placing text around the terminal display, with some | bars and +---+ beams
3:36:04
edgar-rft
I usually use cl:format for ASCII graphics, but I think there are ncurses bindings for colors and stuff in the <https://www.cliki.net/>
3:48:47
ZombieChicken
skidd0: Might also try termbox. I think there is a lib to interface with it via FFI
7:37:30
xificurC
sbcl seems to disagree with me. Probably it needs to compile and execute the require before understanding foo:bar?
7:40:16
beach
xificurC: The FOO package needs to exist when the reader reaches FOO:BAR, or else an error will be signaled.
7:41:54
xificurC
beach: building a script that will be called from the command line. When you write ./command foo xyz I need to load package foo. When you write ./command bar xyz I might need to load bar or some other packages
7:42:59
xificurC
of course this is not set in stone and I can slice things as I wish but I would like to have a toplevel script that dispatches appropriately
7:45:25
xificurC
I could call a defined function and the requiring of a package would register it somewhere for the function to find it but that means foo needs to know about something above it
7:47:23
beach
Sorry, I don't use Common Lisp that way, so I haven't thought about the kludges that might be require to make it work.
7:48:14
beach
But if you want to write FOO:BAR in your code, the package FOO needs to exist when that code is read.
7:48:26
xificurC
beach: do you mean you don't use it like I'm describing or you don't write scripts that would be run from the command line?
7:48:45
beach
If you don't want to do it that way, you may have to do something like FIND-PACKAGE, then INTERN, then SYMBOL-FUNCTION.
7:49:42
scymtym
xificurC: you could make that work using (uiop:symbol-call '#:PACKAGE '#:SYMBOL) but if you want something like git, it seems better to dump everything into a single executable file ahead of time
7:50:52
beach
xificurC: If you write FOO:BAR in your code and try to compile it, then the READ function will first read it. When READ sees FOO:BAR, it looks for a package named FOO. If that package does not exist, an error will be signaled.
7:51:11
beach
xificurC: So you can't even COMPILE your code unless the FOO package has been created.
7:52:17
beach
xificurC: So, the code that reads (funcall (symbol-value 'foo:bar)) [note the quote] can not even be read by the compiler unless the package FOO exists.
7:52:53
beach
xificurC: What scymtym is suggesting is basically a shorthand for what I suggested, i.e, find the package with that name, find the symbol with that name in that package, find the function with that name, call it.
7:53:19
xificurC
I'll just require it in the toplevel for now. This is a habit taken from the previous version of this tool (written in python)
7:54:50
White_Flame
Even consider this, at the toplevel: (when <test> (require :foo)) (when <test> (foo:bar))
7:56:41
xificurC
White_Flame: well sure, but that's like saying (progn (let ((x 1)) (+ x 1)) (+x 10)) breaks
7:57:08
White_Flame
it has to do when the side effects of creating a package take place, vs READing source code
7:57:45
xificurC
eh, I'm not saying it's the same thing, just that you have to think of the consequences and structure your code
7:57:46
White_Flame
I don't know if you can get away with #+ style omission of an entire source code term if that term contains unreadable symbols
8:01:47
beach
What I am saying is that we have these problems because we insist on using OS technology from the 1960s.
8:02:39
White_Flame
but loading also might have initialization side effects, which make it a very decisive call
8:03:03
beach
Common Lisp has some features that allows it to run on 1960-style operating systems, but it would do much better as an operating system in itself.
8:03:27
White_Flame
CL doesn't have a nice clean notion of "load" and dependency. It only has things to mutate its image on command
8:04:40
White_Flame
so yeah, CL would need a lot of changes to clean up such issues; it's not just the OS
8:06:10
shka
xificurC: you don't have issue with interpreter or compiler, you simply don't understand how reader works
8:06:19
White_Flame
(when test (eval (read-from-string "lol lisp source code with read-time-unknown packages")))
8:07:54
beach
xificurC: Your question had to do with loading systems (that create packages) at run-time. Compilation and interpretation have to do with how programs are executed. The two are orthogonal concepts.
8:08:53
shka
anyway, if beach is not using CL for scripting, it may suggest that scripting in CL is not a good idea :P
8:09:06
antoszka
shka: which guide did you paste? my favourite noob-lisp article (the complete idiot's guide)?
8:09:06
aeth
White_Flame: nothing scales indefinitely. packages scale OK except for nicknames, though.
8:09:38
White_Flame
xificurC: think about your source code, as it is read. What are the symbols in the source code '(if test (require :foo) (foo:bar)) if the requirement is not loaded yet, before the form is executed?
8:09:48
antoszka
xificurC: I second the link that shka pasted, it was the *most* revealing CL text I read :)
8:09:49
aeth
xificurC: Even if it was interpreted it would still fail because it's read time, as shka said. As in, foo:bar becomes something else before an interpreter would get to it.
8:09:50
xificurC
shka: I'd rather put some effort into making it work with CL than keep using python
8:10:41
White_Flame
beach: yep, and I do like those ideas. But they are changes to CL, and old OS technology isn't 100% to blame
8:11:32
White_Flame
aeth: packages dont' scale great if every library in existence is always loaded all the time
8:11:36
beach
White_Flame: Oh, sure. By the way, first-class global environments do not alter the Common Lisp language, nor even extend it, any more than a library does.
8:11:41
aeth
xificurC: for instance, think about a literal read eval print loop, i.e. (loop (print (eval (read foo)))
8:20:10
White_Flame
at some point, re-commoning Racket, Clojure, etc into a Common² Lisp would be interesting
8:34:30
White_Flame
it's the same sort of namespacing that many languages have. it's just that other languages don't have first-class symbols
8:36:45
White_Flame
granted, it's a utility that isn't built in as a single function call; not sure if alexandria exports something like that
8:37:42
xificurC
there's uiop:find-symbol* which states "also works well when the package is not present"
8:37:56
beach
xificurC: If that worked, the system would have to store the package name and the symbol name. Whenever you need to call it as a function, it would have to find the package, then find the symbol in the package, then find the function that has that name.
8:38:37
beach
xificurC: That might be what Python does, which is perhaps why Python is a few orders of magnitude slower than Common Lisp.
8:39:02
beach
xificurC: Well, Common Lisp was designed for high performance applications. Not for scripting.
8:39:24
White_Flame
if it had some sort of syntax, it would be (if test (funcall '#?foo:bar)) if #? meant runtime resolution of symbols
8:39:33
xificurC
beach: I really don't want to discuss what python does, I just gave an example of a language I know accepts that
8:40:56
White_Flame
you should probably choose which file to load based on which libraries are there, not try to manage it per-expression
8:40:57
xificurC
shka: I'm switching paradigms all the time. from bash to python to CL to clojure to java to ...
8:43:31
beach
xificurC: You need to learn about compilation vs interpretation, because you are still confused about that.
8:45:14
xificurC
White_Flame: if git was a bunch of scripts then `git log` needs different things than `git tag`
8:45:52
xificurC
loading everything will have a different overhead to loading only what's needed for the particular command
8:48:17
TMA
xificurC: you should implement both variants and measure it -- performance is not much amenable to guesswork
8:48:33
White_Flame
I don't get the problem. If you want to minimally load things, and simulate a bunch of independent scripts, then have a .lisp file per thing you want to do, with the central launcher loading one of them. Each one would pull in its own dependency
8:49:35
xificurC
as an example - I used anki on my work pc one time and wanted to download a deck from within it. I got a handshake failure because we have a MITM certificate. Anki gives no options to handle this of course. So I checked what is it written in - python; searched for the correct file, edited it, saved, restarted, done
8:50:43
White_Flame
I guess your launcher could also set a feature, and wrap each functionality in its own toplevel #+foo (progn ...)
8:50:46
xificurC
White_Flame: yes I was just thinking about that. Even more small files but would solve this problem
8:50:53
beach
xificurC: Sure, if you think editing files to fix bugs is going to be a more frequent activity than running the code, then you should choose that model.
8:51:06
White_Flame
but that feature-based one might be fiddly with managing read-time vs when the feature is set
8:51:58
xificurC
beach: it's not just that. The tools we use are included in every project as a git submodule. If I keep it as a pile-of-files I'm done. If I save-and-die 50MB or bigger images I have a new problem
8:54:57
xificurC
especially in the beginning when changes are many and often breaking it's a big burden to maintain all of this
8:55:57
White_Flame
but in any case, loading fasls is quite fast. I suspect there's a good amount of overlap in the dependencies between the different things you're launching, and it wouldn't be expensive at all to just load in the union at the beginning, so all source code has the libs available
8:56:32
White_Flame
if your tools are big enough to seaprate into separate .lisp files, then just selectively load one of those
9:31:09
xificurC
after reading about shadowing I'm still confused. I have a package with (defpackage :foo (:shadow #:arg) ...) and when I try to use-package it I get name-conflict with sb-debug:arg. I thought saying (:shadow #:arg) I'm saying "if someone uses me I want my symbol to be used"
9:35:32
beach
xificurC: I strongly recommend you don't USE packages other than the COMMON-LISP package.
9:36:10
xificurC
so foo doesn't need the declaration, it would need it only if it was using another package that would have arg exported?
9:36:36
White_Flame
if foo wants to decalre its own symbol, and it's using something which already defines it, then you want foo to locally shadow it
9:37:36
beach
xificurC: I strongly recommend you not import symbols and instead use explicit package prefixes.
9:38:48
beach
xificurC: When you USE a package, you commit yourself to future modifications to that package. You are not protected from the author of that package exporting a new symbol in a future release, and that symbol causing a conflict.
9:39:16
xificurC
we are building a whole bunch of docker images. There's Dockerfiles now and I want to substitute them (or get before them) with a small CL library that copies its commands and generates a Dockerfile from it. That gets me a step ahead and I can easily extract some data from it
9:39:16
beach
xificurC: Just don't USE. Instead, when you refer to an exported symbol in a different package, use an explicit package prefix.
9:40:16
xificurC
so my colleagues will be writing dockerfile.lisp files that will look like e.g. (from "ubuntu") (arg :foo) (copy "data/" "/data/") ...
9:40:50
beach
xificurC: It doesn't matter what use case you have. Just don't USE any package other than COMMON-LISP (which we know will not change in the future). Whenever you refer to a symbol BAR in the package FOO, instead of USE-ing FOO and writing just BAR, don't use FOO and write FOO:BAR instead.
9:41:25
White_Flame
if you want all utilities exposed that you wrote, then that code should be in-package foo
9:42:42
xificurC
beach: I didn't expect you to tell me my use case is fine for USEing, I wanted to ask if there's another *good* way of achieving the same result
9:43:30
beach
xificurC: Oh, I don't understand your use case. I was just telling you how to avoid the conflicting symbol problem, and how to make your application safer in the process.
9:44:27
beach
White_Flame: Actually, it is even better to have a separate package (say FOO) that only contains the exported symbols, and to have a package (say FOO-IMPLEMENTATION) that contains all random symbols introduced by code for the symbols in FOO.
9:48:41
makomo
beach: what about the iterate library for example? the recommended way to use the library is to USE the package
9:49:09
makomo
i've asked about it here before, and i was told that just USE-ing the package is the way to go
9:49:35
xificurC
beach: i was about to USE the package just before falling off the edge, as in (use :foo) (run-from-foo some-args) and that's the end of the file
9:51:09
makomo
beach: i really like the first-class global environments idea. has it been implemented anywhere yet or is an implementation in progress?
9:52:30
makomo
hm, could a restricted reader achieve the same thing as FCGE (first-class global environments :-)) regarding the sandboxing issue?
9:52:56
beach
makomo: Cleavir uses the protocol. For SICL bootstrapping, the global environment is indeed an instance of a standard object that implements the protocol. Since Cleavir uses the protocol, so does Clasp and now the new CLISP compiler as well.
9:53:33
makomo
the issue regarding #. would obviously be handled in the reader i guess, so it's not very relevant
9:53:39
beach
makomo: But I think they use a very simple instance where the methods trampoline to their own global environment.
9:54:57
beach
makomo: karlosz is implementing a new Cleavir-based compiler for CLISP as a Google Summer-Of-Code project.
9:55:19
jmercouris
beach: How does that work exactly? does google interface with you directly or what?
9:56:06
beach
makomo: jmercouris No, CLISP is a GNU project, and the FSF is apparently pre-approved as a GSoC organization.
9:56:06
jmercouris
White_Flame: quick update, I've gotten 7 survey responses so far, collecting them is difficult
9:58:43
makomo
beach: and about my fcge vs. restricting the reader question (in the context of the sandboxing issue)?
9:58:43
_death
personally, I :use :cl and sometimes packages that I have under my control, and use :import-from for others.. whether to do that or use package prefix depends on the interface exported, but usually I go for the former
9:59:48
beach
I think karlosz idea is brilliant. It will improve CLISP, but it will also improve Cleavir, so everyone will benefit. For instance, he is working on SSA conversion that we haven't bothered with very much so far.
10:01:09
makomo
beach: it won't work because restricting the reader doesn't handle all of the cases or?
10:02:15
p_l
beach: I once looked into some of the memory management code, I remember running away in horror
10:02:38
beach
Recall that a major reason for Cleavir is to attempt to cut down on the global maintenance burden of free Common Lisp systems. If more free Common Lisp systems use the Cleavir compiler, then the hope is that there will be less implementation-specific code to maintain.
10:03:13
p_l
jmercouris: multiple implementations that are kept compatible *strengthen* the community
10:03:36
makomo
beach: hmm, i'm trying to think of such an example -- maybe a macro constructing the symbol in a sneaky way or something? you could still take care of it by doing extra checks after reading, i.e. reading everything, macroexpanding it and then checking, perhaps?
10:03:59
makomo
beach: but i think then you'll have to do codewalking, right? and that isn't really portable
10:04:01
p_l
if there's *no effort to provide compatible separate implementations*, bad shit happens (Python)
10:04:53
p_l
jmercouris: having a healthy ecosystem of multiple implementations gives more pressure to write portable code
10:05:19
beach
makomo: You would have to recognize attempts to do intern and fdefinition and funcall.
10:05:23
makomo
jmercouris: there's also this :-) https://github.com/robert-strandh/SICL/blob/master/FAQ.text
10:05:25
p_l
jmercouris: enough that you end up having companies that explicitly take different implementations for their specific quirks and write compatible code
10:06:12
p_l
jmercouris: for example ITA Software, iirc, used both SBCL and CCL, because CCL was much faster in compiling but SBCL had higher final performance, so CCL handled web code for example
10:06:34
jmercouris
p_l: wait a second, I thought you couldn't count on compiled code to work between different implementations?
10:06:57
makomo
beach: i've noticed that you rarely include pdfs in your repositories, i.e. leaving it to the reader to compile the documents from latex. is this a valid observation or did i just stumble upon a few such repos?
10:07:44
makomo
not sure what your rationale is, but it's much much easier to just click a pdf than to (1) clone the repo, (2) fetch the latex deps, (3) build the pdf
10:08:36
p_l
jmercouris: I've been trying to get one started, but it would be probably more DevOps oriented because it would exist to troll for contracts
10:08:45
makomo
they are both products of the build system, sure, but the pdfs are something that should be readily available imo
10:08:57
makomo
beach: nothing in particular, but i noticed it just now when i went to see the SICL docs
10:09:57
p_l
jmercouris: ... that's a tricky question, sometimes you actually should include them...
10:10:14
makomo
i agree with not including binaries such as fasls in your git repo, because they're implementation specific, blah blah
10:10:51
p_l
makomo: better option would be to provide a quick and easy way to publish them from repo
10:11:05
makomo
browsing a git repo through the web interface and having the convenience of just clicking on a pdf is great IMO
10:16:42
makomo
p_l: oh like that, yeah that's an option i guess, but it's much more work to do than just leaving a compiled pdf in the repo
10:17:25
makomo
beach: oh yeah, i actually wanted to read the ILC-2014 paper, do you have that one available somewhere?
10:20:39
makomo
beach: i found a few small typos in the FAQ btw: https://github.com/robert-strandh/SICL/blob/master/FAQ.text#L145 "files so obtain", https://github.com/robert-strandh/SICL/blob/master/FAQ.text#L182 "contribute should get"
10:25:17
makomo
beach: instead of pushing the pdfs into the repo, you should perhaps set up an index of the pdfs you host on metamodular, organized by projects or similar
10:27:14
makomo
SICL/Papers/ has a lot of good stuff and you can't read any of it without compiling it yourself. call me lazy, but i like being able to browse around a project's github repo and inspect the docs within my browser
10:38:07
White_Flame
given that one might describe something beneficial as "the bomb", does that mean you're someone who will set us up the bomb?
10:38:08
p_l
i.e. something that would build PDFs from your repos and publish them without any work from you?
10:38:42
makomo
would one have to pay for hosting or could one just use something like github pages?
10:57:23
p_l
I'll take a look later over your repos, you keep them all on github or also in some other places?
11:00:00
beach
But I think I need help with the mechanisms of publishing after modifications to some documentation.
11:00:20
p_l
beach: ultimately it's a question of how to push the changed documents, i.e. how to provide access to the server
11:00:40
p_l
with CI we can easily integrate that for example every commit to "master" will result in a build and push
12:29:53
xificurC
(asdf:load-system :foo) and therefore (require :foo) writes compilation output to *standard-output*. Giving :verbose nil to asdf:load-system still does it. Why isn't this information going into stderr?
12:39:22
Xach
xificurC: I don't know definitively, but *standard-error* is specified to be for warnings and non-interactive error messages.
12:41:10
xificurC
when I do (let ((*standard-output* (make-broadcast-stream))) (require :foo)) the output goes away
14:12:19
slyrus1
scymtym: I see you setup the sharplispers/xpath repo. are you going to push your code to it?
14:27:05
scymtym
slyrus1: yes, i'm planning to. i have a bug fix and few commits that get rid of ASDF warnings
14:33:28
slyrus1
scymtym: sounds good! I think I have a few minor fixes lying around that I'll dig up next week.
14:40:48
scymtym
Xach: sure. but since i just started, i would like to test the modifications a bit before they are rolled out to everyone
14:58:16
rpg
Is there a standard anaphoric if/when out there? I know alexandria doesn't provide one. I'd like one, but prefer to use one that's commonly use.
14:59:57
rpg
Xach: I usually do, too, but sometimes the let-binding followed by if seems like just too much
15:00:00
rpg
Xach: I usually do, too, but sometimes the let-binding followed by if seems like just too much >
15:03:39
rpg
loke: Oh. I was just looking at the comments in alexandria, which disclaim intent to add anaphoric constructs.
15:10:06
sjl
I have my own (if|when)-let*? macros I made a while back that handle declarations properly, etc. Maybe I should put them somewhere.