freenode/#lisp - IRC Chatlog
Search
17:44:13
loli
beach: also do you have any more references for first class environments, I've read your SiCL paper about the subject
18:33:41
rpg
I could use some iterate advice if anyone has it. I have an iter loop using with-vector, and when I declare the type of the iteration variable I get this warning: Iterate, in clause (FOR CHILD IN-VECTOR (CHOICE-CHILDREN CHOICE-ENTRY) WITH-INDEX INDEX): Cannot supply an initial value for type (OR NULL CHOICE); using NIL. I have no idea how to make it go away.
18:38:55
rpg
The problem only arises when I put in a type declaration for this variable (so, yes, I know -- don't do that then!).
18:54:19
Bike
the function that's coming from looks dicey but i don't understand what it does well enough to diagnose anything
18:54:36
Bike
seems like they could just do (subtypep null declared-type) and if true, heyo, initialize to nil
19:42:33
nij
Is there a typo in Alexandria's manual, as in "Function: mappend function &rest lists" ;; https://common-lisp.net/project/alexandria/draft/alexandria.html
20:19:26
jackdaniel
I wrote a small tutorial about CLIM: http://turtleware.eu/posts/You-dont-need-a-backend-to-use-CLIM.html for those interested :)
21:07:11
nij
How much mouse should I use with CLIM? Is it possible to customize it to be keyboard-centric?
21:23:53
jackdaniel
nij: thanks. that depends on the application, but in principle commands may have keyboard accelerators
21:24:48
jackdaniel
as of selecting presentations on the screen, at some point of time I saw that someone hacked something so small numbers appeared beside acceptable presentations so it was possible to type the number instead of using a pointer
23:11:27
copec
What sort of CI/CD do you use with CL? Do you create a fresh image if you fix something and commit it to a repository? Have you setup a way to update the remote image? What sort of interaction do you do between a local copy of your source, and local running emacs with a remote swank?
23:24:40
pjb
copec: yes, if you want to validate or build a library or application, it's better to start from a fresh image.
23:28:31
pjb
and more: https://www.google.com/search?client=safari&rls=en&q=CI/CD+Common+Lisp&ie=UTF-8&oe=UTF-8
23:29:21
pjb
copec: of course, it's related to the question of delivery: it will depend on how you will deliver your code, and how you test it.
23:29:59
pjb
copec: but assuming you build (save) executable images, here is a typical example of how I proceed: https://github.com/informatimago/hw
23:31:24
pjb
copec: note, ecl is a special case, since it doesn't save executable images, but instead it will produce normal elf objects and binaries (or whatever native format on the target platform, since it goes thru gcc to compile and link).
23:32:00
copec
The code I'm using is just for me to administrate a bunch of things, we use SaltStack and gitlab internally, so I made some states that build roswell, and then I use that to build my image (against sbcl specifically)
23:33:27
copec
It all seemed so what everybody does for non-lisp stuff, I just wondered if I'm doing it wrong
23:35:03
fiddlerwoaroof
The build is failing now :( but, here's a CircleCI configuration for one of my projects: https://github.com/fiddlerwoaroof/daydreamer/blob/master/.circleci/config.yml
23:35:19
fiddlerwoaroof
I also just like to have a simple shell script or makefile instead of using Roswell
23:38:37
fiddlerwoaroof
Here's an example of that: https://github.com/fiddlerwoaroof/cl-git/blob/master/.github/workflows/test.yaml
23:43:10
etimmons
copec: and here's a concrete example with Gitlab CI https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/gitlab-ci.yml
23:58:18
pjb
Definitely. Once you've written whatever you use to build or run tests, you should have a Makefile to do it easily from he shell.
0:56:47
no-defun-allowed
This dictionary says an apocalypse is "something viewed as a prophetic revelation". Since people know that shells are pretty janky, I would say you are in a post-apocalyptic scenario already.
1:37:05
Xach
etimmons: adopt-subcommands got me to add support for looking up release info from gitlab
1:37:46
Xach
it turned out to be pretty easy - i can mostly pretend it's github, the protocol of GFs meant I only had to implement a single method in a key place...
1:40:43
copec
nij bash is actually a bit faster than python in many cases, and it's directly interpreting the text stream, I've thought it would be funny to have a lisp on top of bash
2:45:02
pjb
nij: https://cliki.net/programming%20language says Bash: no known CL implementation written in bash.
2:57:12
nij
Hmm.. I've asked this newb question before, but I wasn't happy with the solution. So here's another try.
2:57:56
nij
In my sbcl config, I use the package asdf and some symbols in it. However, in a freshly new workstation there's no asdf yet.
2:58:27
nij
Is there a way to wrap those that contain `asdf:..` in some form, so that when there's no asdf yet, it doesn't get loaded at read time?
3:02:50
pjb
nij: https://cliki.net/programming%20language says Bash: no known CL implementation written in bash.
3:04:24
beach
loli: Can you give me more context to your question? I am not sure what you are referring to.
3:05:13
beach
loli: We extracted the code for first-class global environments into the Clostrum library which has more documentation. There is also a presentation in the context of the online Lisp meeting that I made.
3:06:07
loli
I believe that was in response to your comment about it being more costly for CL to have a notion of either first class environments or modules.
3:06:23
loli
beach: if you don't mind, could you link me the presentaiton, that would be interesting to review
3:07:47
loli
I believe it was in a discussion about performance, you mentioned nested hash table calls
3:09:07
loli
well I assume CL already deals with a flat version of this, as it has to lookup things in it's image which we can view as a flat table?
3:09:09
beach
Usually, a typical Common Lisp implementation uses the symbol as an indirection to the function, so that SYMBOL-FUNCTION merely accesses a slot in the symbol.
3:09:59
beach
But that won't do when you have first-class global environments, because it name must resolve differently in different environments.
3:10:02
loli
ahh, so when you use libraries, it dumps the names into the namespace so it's a O(1) lookup call?
3:10:47
beach
Yes, the late binding costs O(1) and a very small O(1) in a typical Common Lisp implementation.
3:11:22
beach
So what most previous work does is to replace that indirection by a hash-table lookup.
3:12:15
beach
But if you do a hash-table lookup for each function call, you will slow down that important operation by an order of magnitude.
3:14:19
loli
thinking on it, I don't think it's relevant here, but it resolves the name to the proper one
3:14:26
jasom
A hash-table lookup is a larger (but still potentially O(1)) cost than reading a slot from a symbol
3:14:57
loli
have the schemes guys done first class environments, I heard the MIT guys have with their reflective tower?
3:15:01
beach
So what I did for the SICL work was that I use an indirection through a de-materialized "function cell" (just a CONS cell really), so that when code is loaded into some environment, the name resolves to an environment-specific cell.
3:15:44
beach
loli: Scheme has traditionally not been that concerned with performance, so they seem to accept the hash-table lookup for each function call. At least that's what Queinnec's work does.
3:19:23
beach
So it is easy to have first-class global environments or modules if you either don't need late binding (as static languages do) or if you don't care about performance of function calls.
3:20:38
loli
I believe this was the post I was referring to https://factor-language.blogspot.com/2008/01/compiler-overhaul.html
3:23:48
beach
So my work on first-class global environments solves the problem by resolving names to function cells at load time, but that works only when the name is known statically. If you call (SYMBOL-FUNCTION <non-constant-form>), then you still need a hash-table lookup, but the performance of such a call is less critical than that of a function call.
3:25:06
beach
Oh, and my ELS paper this year is another solution to the problem of late binding, and it is potentially even faster than the function-cell technique.
3:25:07
loli
Factor as a language is early binding, but with a few tricks, they make it seem like they have late binding which works in a lot of scenarios
3:26:05
beach
But on that page they talk about "interpreter", so they obviously don't position themselves in the "performance" camp.
3:27:23
beach
saturn2: They could. That's another possible solution. It would be very confusing, and you would need a way to refer to "the symbol which has the same name and package as this one, but in a different environment".
3:28:29
beach
saturn2: Plus, because the reader creates symbols, you would have to decide on the module/environment at read time.
3:28:31
saturn2
beach: it would just be going from package->symbol to environment->package->symbol, so it doesn't seem much more confusing than packages are
3:30:47
loli
ahh perfect I was just about to ask you if it was "Call-site optimization for Common Lisp" in the Preceedings
3:32:38
beach
I invented them so that I could isolate the host Common Lisp system from the SICL code during bootstrapping.
3:32:53
beach
SICL bootstrapping uses 5 different first-class global environments for different phases.
3:33:56
beach
You may want to isolate (say) the compiler internals from the API. Then if you put the internals in a first-class global environment by itself, you can "export" only the API to other first-class global environments.
3:35:10
beach
saturn2: So you can then also have different versions of the same system as long as each version is in a different first-class global environment. That solves the problem of two systems, needed simultaneously, require different versions of some library.
3:35:56
beach
saturn2: But my plan is also to use first-class global environments to isolate different users from one another, and to isolate users from the system, in a multi-user Common Lisp system.
3:37:08
loli
beach: with this new call-site optimization you found, is there still much more overhead versus the traditional model CL has? I'm curious from a new compiler perspective, and where the state of this research is at
3:38:22
loli
saturn2: you can do a lot of fun things, I've thought of having some way of sharing my nyxt browser state between my machines, then switching to different environments for a different machines state, and manipulating that, and through some protocol send the changes back (this is a bit silly, but would be fun to try to setup)
3:38:45
beach
loli: No, it's the other way around. The work on first-class global environments is already as fast as the traditional indirection through a symbol, and the work on call-site optimization suggests that we will be able to do function calls as fast as a static language like C++ can.
3:39:34
loli
beach: perfect, I can use this to my own means, and hopefully give something back to this field at some point in the future.
3:42:01
loli
Well I've been writing a compiler, and if things go well the language shall blossom quite nicely in enough time
4:14:05
terpri
beach, any thoughts on object-capability security models? a la johnathan reeves's w7 or chris lemmer webber's spritely goblins
4:18:11
terpri
a number people thought that common lisp was basically impossible to secure, but i think they were overly pessimistic and perhaps stuck in an actor-model rut
4:19:06
terpri
(granted, CL has a fair amount of global state and likely a number of funky edge cases)
4:21:44
terpri
beach, any recommended reading for multics security? i'm totally unfamiliar with it (but willing to trawl through multicians.org if nothing comes to mind, it's be good to know multics better in any case)
4:24:29
beach
I don't have anything specific in mind for the security aspect. But the basic idea is that you have an "object store" (i.e. the segment hierarchy in Multics) with ACLs (access control lists), and when you access an object in the store (done by the dynamic linker in Multics) the ACL determines the capability you get. After that, everything is capability based.
4:26:08
beach
EROS removed the ACLs, I think completely, and did everything with capabilities, but I find it hard to think in those terms.
4:26:41
terpri
beach, also...random question...would SICL potentially be useful for adding CL as a supported language to guile (a multilanguage scheme system that already fully supports "core" elisp and other langs)? e.g. for the later/higher-level parts of the spec? or is it its own thing like sbcl and other traditonal implementations?
4:29:04
terpri
beach, i'll try it out when the time comes (i'm barely past number parsing!) and let you know if i discover anything interesting. really cool project either way
4:29:04
beach
I am afraid that the SICL system code is going to require its own bootstrapping technique. I used to believe that I could write "modules" of system code to be added to a partial Common Lisp system, but it turned out to be too hard for a person with limited brain capacity like myself to write modules in a subset of the language.
4:30:22
beach
... so I decided to write the modules using the full Common Lisp language. But that means that you either need to have an existing Common Lisp implementation (which could be a slow interpreter) to load those modules. And then Guile would not qualify I guess.
4:31:06
beach
For SICL, I have a solution of course. I bootstrap using an existing conforming Common Lisp implementation, plus the CLOSER-MOP library.
4:31:49
beach
But Guile isn't built like that. Nor is any existing Common Lisp implementation as far as I know.
4:34:04
terpri
yes, and "layering" CL in a nontrivial way would be difficult (or at least the proposals for it were rejected as too complicated or unnecessary iirc)
4:34:08
beach
Then the ACLs can contain wildcards like *.admin (read/write) and beach.* (read only).
4:35:23
beach
terpri: Yes, the entire language is very tightly coupled. You can do evaluation at read time, etc.
4:36:26
beach
terpri: It is still possible to layer the implementation. For example, the SBCL compiler doesn't use classes or generic functions (or so I have been told). But I am not able to work like that.
4:38:35
beach
And I was told by stassats that there was no reason for the SBCL compiler to use generic functions and classes, because doing so would only have the effect of making it slower.
4:40:08
beach
Now, the way I see that issue is that, because generic dispatch is not very fast in SBCL, they then avoid the use of a great tool to write a major component of the system. I would much rather make generic dispatch faster and use the tool.
4:42:07
terpri
beach, btw, you *do* know of TUNES.org, right? conceptually, vaguely like CLOSOS, but much more of a pie-in-the-sky research project that fizzled out years ago; we were more often engaged in reflection-related wool-gathering instead of setting concrete goals and writing functioning programs (imho)
4:50:27
beach
I mean, this stuff is not rocket science. Anybody thinking about what we have and what we are doing wrong would come to similar conclusions.
5:11:09
terpri
a bit off-topic, but i'm personally interested in new approaches and optimizations for multiple dispatch, as adding prototypes with multiple dispatch to JS would allow me to (in a roundabout way) correct some serious design flaws in JS BigInt's design that i still feel guilty about (i was the main spidermonkey implementer and worked on other aspects of it)
5:13:05
terpri
(tl;dr google enabled a draft implementation early and changes to mathematical edge cases were rejected because "google says no", despite independent objections from me and fabrice bellard)
5:15:59
Nilby
terpri: You may have seen them, but there's some interesting papers about multiple dispatch here: https://opendylan.org/documentation/publications.html
5:19:11
beach
terpri: Can I assume you know about my work on generic dispatch? http://metamodular.com/SICL/generic-dispatch.pdf
5:21:08
terpri
Nilby, oh, neat, i have in fact not seen them (despite being interested enough in dylan to have a dead-tree copy of the language reference). even some of the older papers look potentially relevant to modern JS, ty for the link!
5:22:12
terpri
beach, you can indeed :) i think stumbling across that is how i actually heard about SICL