freenode/#lisp - IRC Chatlog

8:22:33 markasoftware I'm still trying to wrap my head around it...it seems they do not pass the next methods as an argument to the method-function

8:23:36 markasoftware And it seems like they threw away MOP compliance to do it this way, because make method lambda does not exist

8:23:45 beach The default way is to pass a list of next methods, but for specified classes and generic functions, they may change that for reasons of performance.

8:24:12 beach Yes, make-method-lambda has been abandoned in several implementations.

8:26:03 markasoftware What do you mean "for specified classes"?

8:27:16 beach A general rule that says what client code can do is that a client-specific method must not be applicable when given only arguments that are direct instances of library classes.

8:28:08 beach So since clients can't write such methods, the library is free to violate specified behavior when this violation can't be observed by client code.

8:29:50 markasoftware But client code could access the method-function, right? So its not quite unobservable?

8:30:16 markasoftware Using mop:method-function

8:30:39 beach Hold on... the method function is not what receives the list of next methods.

8:31:25 beach The method function has the same lambda list as the DEFMETHOD form, minus specialization.

8:31:31 markasoftware The method-function takes a list of arguments and a list of next methods according to amop, I think.

8:31:58 beach You may be right.

8:32:40 beach But that doesn't count as observable.

8:32:57 markasoftware What you just described is what ccl does

8:33:38 beach I see.

8:34:03 beach But I bet you it doesn't do that if you define your own method class.

8:36:21 beach What CCL does in this case would be a very normal optimization for the case when only specified classes are involved, because it is way faster that passing a list of arguments and a list of next methods.

8:38:41 beach mop compute-effective-method

8:38:41 specbot http://metamodular.com/CLOS-MOP/compute-effective-method.html

8:39:51 markasoftware I believe ccl does this for custom classes, which is how i discovered this in fact. There's some fancy magic (their word, not mine) that goes into call next method I'm still trying to figure out

8:40:12 Nilby The CCL MOP maybe a little messy but it ran on a 68k Mac with 1mb memory.

8:40:21 markasoftware They admit their generic functions don't really work with amop

8:40:38 beach I haven't studied what CCL does, so it is entirely possible that the violate specified behavior even when they are not supposed to.

8:40:52 beach s/the/they/

8:41:44 markasoftware Is it your understanding that a mop compliant implementation's method functions, for a custom method class, would always have to take a list of arguments, then a list of next methods

8:41:51 markasoftware ?

8:42:01 beach Yes, I think so.

8:42:28 beach Er, wait...

8:42:30 markasoftware Thats my main concern, since I'm writing code that relies on this property, and while I'm OK with implementation specific exceptions I want to get my "default" code right

8:43:07 beach It is probably possible for client code to customize make-method-lambda, compute-effective-method, call-method, make-method, etc. to do something else

8:43:35 beach But with no such customization, it is my understanding that the default is what you said.

8:43:41 markasoftware Yeah, I suppose with make method lambda it could be changed...

8:43:57 markasoftware Thank you!

8:44:08 beach Have you looked at what closer-mop does in case of CCL?

8:44:32 markasoftware Not much, yet.

8:44:52 beach Maybe it fixes this problem.

10:34:32 jackdaniel it does fix some problems with ccl, but at a cost of shadowing operators

10:35:12 jackdaniel i.e a casual standard-generic-function is not recognized by some closer-mop methods (because it provides its own defgeneric version - on ccl)

10:47:44 alanz I have a general question. I.n. e.g pharo smalltalk, you can load source from well-defined git repos etc via metacello. You can then work on the live image, changing whatever, and then do a diff for the modified in-image source vs the original, and possibly commit it back. Is that kind of workflow possible in common-lisp?

10:48:29 alanz i.e. capture that changes from a live image and the files it was loaded from?

10:56:55 beach Certainly not using only the standard. An implementation could provide something like that, but I know of no implementation that does.

10:57:49 alanz Thanks, I was pretty sure that was the case, just checking I was not missing something. FWIW, that experience is pretty good, in pharo

10:58:29 alanz ACTION loves the fact that anything is in principle *possible*

11:01:34 Nilby I do in-image editing and have an in image git tool, but I like to save my work to permanent storage frequently. CL editors can do that, but we tend to like the emacs style of editing. I've tried the pharo style, but I'm not so fond of it.

11:03:06 alanz Nilby, how do you keep things in sync? I find myself killing and restarting the lisp image frequently, to make sure I have everything lined up. Particularly when messing with package definitions, which affect scope

11:03:30 alanz (I'm still learning what these things do, so mess it up often)

11:04:52 Nilby I usualy edit on the function or class level, so when I'm satisfied with the function I send it back to the file buffer which I can then git diff.

11:04:55 beach alanz: Current Common Lisp implementations are easy to make inoperable. That fact discourages in-image manipulations.

11:05:51 alanz "edit on the function or class level": In the REPL?

11:06:26 alanz beach, so what is a normal workflow? restart the image often?

11:06:56 beach I suspect that's what most people do.

11:07:10 alanz ok, so I am not missing something then :)

11:09:25 beach The plan for SICL is to use multiple first-class global environments so that if you mess up the current one, you will get a default one that works. And the plan is also to keep the source text associated with every definition, which would make your workflow possible.

11:10:11 Nilby I don't restart much. But I use multiple images when I might do something that introduces bugs to the editor/repl. And it's true most modern lisps are easier to crash.

11:13:06 Nilby But it's true I sometimes find order of definition/loading bugs I didn't notice when just editing functions/packages.

11:13:58 Nilby I'll be glad to have first-class global environments again.

11:14:41 beach One mistake I often make is to introduce some circular dependency. While working interactively, the dependencies exist, so the problem does not manifest itself.

11:17:02 alanz modern lisps are easier to crash: is this because they have drifted away from being first-class, do everything in them environments?

11:17:49 alanz And what makes you think we will have first-class global environments again?

11:18:08 alanz ACTION just trying to understand the ecosystem

11:18:09 Nilby Old LispOSs took a long time to boot. Also they had an (vague) idea of separate users/sessions.

11:18:59 Nilby On on old lisps fully restarting the image was basically rebooting

11:19:21 beach alanz: I guess Interlisp was more like Smalltalk. But Common Lisp is mainly derived from Maclisp.

11:19:35 Nilby my memory is fuzzy on the specifics, but basically you could log-out to reset your environment

11:20:04 moon-child fwiw work has been ongoing to revive interlisp

11:20:13 beach alanz: We will have first-class global environments in SICL because I already implemented them.

11:20:30 moon-child (alanz: you may find this interesting https://interlisp.org/)

11:21:20 alanz so there was motivation to avoid that, so the effort was put in for hot code reload etc

11:21:20 alanz Wikipedia interlisp: First appeared 1968; 53 years ago. Respect.

11:21:38 Nilby Yes. They have the old Interlisp environment working fairly well. The only problem I saw was that it doesn't know how to idle the processor.

11:21:54 alanz beach, SICL is the common-lisp IDE?

11:21:59 beach minion: Please tell alanz about SICL.

11:22:00 minion alanz: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL

11:22:15 alanz :+1:

11:22:30 moon-child Nilby: iirc some of the machinery for idling was there, used for idle animations or screensavers I think?, so not a completely insurmountable task to restore

11:23:36 Nilby I'm sure it's just a tweak to the VM

11:24:05 Nilby But I didn't try since I'm pretty invested in CL

11:24:49 alanz beach, what is the one-line motivation for SICL?

11:25:07 moon-child as I recall, interlisp supports cl and 1 or 2 other lisps

11:25:14 alanz apart from: it sucks, time to do it over

11:25:54 beach alanz: Create a Common Lisp implementation that is adapted to modern processors, that uses CLOS a lot more than existing implementations, and that is way simpler to maintain.

11:26:05 alanz :+1:

11:26:28 Nilby Hmmm. Maybe I should try to port to it. Then I will have to figure out how to get it to not eat the full cpu.

11:26:55 alanz how does it relate to the standard? will it do all of it, or leave parts out? eg that whole filepath back-compatibility wart?

11:27:03 moon-child Nilby: https://github.com/Interlisp/medley/wiki/How-to-Run-Medley-without-pinning-the-CPU

11:27:13 beach alanz: I was convinced that maintainers of existing Common Lisp implementations would not accept the fairly radical modifications that I wanted to see.

11:27:35 beach alanz: SICL? It will follow the standard.

11:27:50 alanz makes sense. Hard to move things when there is so much history behind it

11:28:46 beach Yes, and my estimate was that it would be just as hard, perhaps harder, to transform an existing implementation, as creating a new one.

11:28:56 Nilby moon-child: Awesome. Thanks!

11:31:37 Nilby If you read the code of most CL implementations, it's not hard to get the sense that they could really use a clean slate approach.

11:31:51 beach Indeed.

11:33:24 alanz trouble with that is there is always so much baked-in hard-won knowledge in the old ones, that make them reliable

11:33:39 alanz or at leaast predictable, or "known"

11:34:30 Nilby The interesting thing about CL, is parts of an implementation would useful to many type of progams as separate customizable/subclassable module.

11:41:19 beach That's why I try to extract many SICL modules as separate repositories.

11:42:17 beach We already have Clostrum (first-class global environment) Trucler (lexical compile-time environments), Incless (printer), Eclector (reader), etc.

11:42:51 beach Oh, and Cleavir (compiler framework) of course.

11:44:56 Nilby I'm already using Eclector, and I imagine I'll end up having to use some of those other pieces too. It's awesome that they can already work on top of other implementations.

11:45:43 beach Well, they had to from the start, because I am using them to bootstrap SICL on an existing host Common Lisp implementation.

11:46:55 alanz sounds good

11:47:39 beach Also, that means I can often persuade someone else to be the maintainer. :)

11:48:22 Nilby A good deal all around

12:17:29 terpri_ ** NICK terpri

13:24:52 semz Is there a trick to easily reading nested backquotes or do you just have to be very careful and strict about the various contexts you're working in?

13:30:16 _death there are "pattern matching" hints in cltl2 backquote appendix

13:34:16 semz Thanks, that looks exactly like what I was looking for.

13:58:08 pyc What does UIOP stand for?

13:58:30 beach Nothing. Just consecutive keys on a US keyboard.

13:58:39 beach Just like ASDF.

13:59:22 _death unother iystem oefinition pacility

13:59:31 beach :)

13:59:54 contrapunctus pyc: Utilities for Implementation and OS Portability IIRC

13:59:57 beach pyc: We can figure one out if you are not happy with that answer.

14:00:11 beach Like that, yes.

14:00:16 contrapunctus Oh sorry I ruined it ^^'

14:00:23 Xach U and I Overcoming Problems [With Lisp]

14:00:31 contrapunctus rofl Xach

14:02:14 susam I always wonder why ASDF does not stand for ASDF System Definition Facility.

14:02:58 Nilby Is there some design decision why slime/sly subprocess output is not delivered to the repl buffer?

14:05:12 pyc how stable is uiop? has it ever broken backward compatibility so far?

14:07:13 Xach pyc: what prompts the question?

14:08:35 pyc Xach: I am making my script depend on uiop functions rather than CLHS functions. I decided this after I realized that (directory "vid/*") lists all files in CLisp but not in SBCL. What the wildcard characters mean seem to differ greatly from implementation to implementation.

14:09:14 pyc Xach: I realized I can't write even the most basic file I/O operation in a portable manner without writing a compatibility layer. UIOP seems like that compatibility layer.

14:09:37 Xach pyc: it is a compatibility layer, yes

14:09:53 pyc Xach: now the reason I chose CL was because I want my script to run without issues and without maintenance even 20 years into the future. That is why I want to know how stable UIOP is.

14:13:05 X-Scale` ** NICK X-Scale

14:14:26 pyc do you people write your script in portable manner using uiop or do you write for a specific implementation like SBCL?

14:14:41 beach I don't write scripts.

14:15:37 pyc beach: what do you write and how do you write them?

14:15:50 beach I just consider the REPL to be my shell.

14:16:14 Xach pyc: i generally write scripts in a way that works as i expect in sbcl.

14:16:29 pyc beach: do you write any programs that you save in files for the long term? if so, do you use something like uiop or do you target a specific implementation like SBCl?

14:16:59 pyc Xach: so you are okay to rely on SBCL-specific behaviour that may not be portable?

14:17:39 beach pyc: Yes, my programs are in files, and I use ASDF to load them.

14:17:50 pyc Xach: can you point me to some of your code, especially if you have something that manipulates files? I am hoping as a beginner I can learn from code written by experts.

14:18:03 Xach pyc: https://github.com/quicklisp/quicklisp-client is an example

14:18:09 beach pyc: I try very hard to write programs that don't use any implementation-specific features.

14:18:29 Xach pyc: for getting wildcard entries, i don't mind using sbcl. that is a very tiny part of the programs that i write.

14:18:36 pyc beach: so for something like list all the files in a directory recursively, you are likely to use UIOP instead of CLHS?

14:18:52 pyc Xach: understood. thanks!

14:19:23 pyc I think uiop has obvious benefits of portability. Are there any disadvantages of calling uiop functions in my code that I need to be aware of?

14:19:56 _death pyc: I think there is a chance for uiop code to work in 20 years (maybe even the same uiop version, on sbcl ;).. but I dislike its interfaces

14:20:03 Xach pyc: uiop includes a lot of things in it. if you are only concerned about one small piece like wildcards it may be prudent to extract it instead of taking all of uiop.

14:21:07 pyc _death: what do you prefer then? hand-write what you need? another alternative to uiop?

14:21:17 beach pyc: I might use ASDF or UIOP occasionally.

14:21:23 pyc Xach: that makes sense. thanks for the advice.

14:21:44 Xach pyc: it can also help if you make things that you need and like and don't worry about portability. if people want to use it, let them worry about it if they have a different environment. (this is just an option, not a requirement.)

14:22:33 Xach pyc: i think sometimes the means of distribution and widespread use becomes a roadblock to even getting started.

14:22:40 Xach that is, overthinking it.

14:23:13 Xach "if i can't give my friend a 500KB executable that has a gui and runs on all OSs why even bother using lisp" is a little extreme but less extreme but similar sentiments have been expressed

14:23:19 pyc Xach: you are right. I guess I am overthinking it. I wish I started learning CL when I was much younger. I didn't worry about these kind of things when I was younger. Now I waste a lot of time in analysis paralysis.

14:24:34 Xach pyc: I don't think portability is a bad thing, but it is not a simple story in CL, and you can actually ignore it for quite a while when learning and growing.

14:24:53 Xach I wish it was simpler but its complexity need not be an initial roadblock (for many tasks)

14:25:37 Nilby pyc: I just did a survey of some of my lisp scripts from 20 years ago. BTW uiop didn't exist 20 yrs ago. Everything that still works, works because they don't depend on external conditions. But for most useful things, the external conditions have changed enough that they don't run.

14:25:51 _death pyc: I find myself still using cl-fad to walk directories.. because then I don't need to first gather all names into a list

14:27:34 susam I agree with Xach. If I could mangle a famous quote, I would say: Make it work. Then make it beautiful. Then if you really have to, make it portable."

14:28:11 susam The programs you write for yourself should first solve your own problems. Only then it may solve others' problems.

14:34:44 X-Scale` ** NICK X-Scale

15:14:25 Josh_2 Afternoon

15:21:58 Josh_2 Is CFFI's foreign-string-to-list equivalent to pythons bytes_to_native_str(ffi.unpack ... ?

15:31:03 Josh_2 I've been stuck for the past few days on a single function, I'll be happy to see the behind of this project

15:36:47 Josh_2 Well seems I solved that issue

15:36:49 Josh_2 :D

15:41:14 Josh_2 Well darn I finally figured it out

15:55:59 Josh_2 What is no-applicable-method-error (SBCL) a subclass of? I'm trying to handle a missing method error

15:56:31 Josh_2 Obviously I could just use condition or error but then if there is another type of condition then the test would still pass

16:02:01 heisig Josh_2: Have a look at (sb-mop:class-precedence-list (find-class 'sb-pcl::no-applicable-method-error)).

16:06:08 Josh_2 Thanks

16:24:40 phoe Josh_2: do you control the generic function?

16:25:04 phoe if yes, maybe you instead want to add a method to NO-APPLICABLE-METHOD?

19:08:14 holycow hi.

19:09:26 holycow noob question. so i am able to parse text files, chop up the input in interesting wasy now and stuff that into alists and plists and then get the data out sorted in various ways.

19:09:36 Xach holycow: that's not a question!!

19:09:49 holycow well, it's a predicate to a q

19:10:41 holycow suppose i wanted to write a function that (using keystrokes) allows me to itarate up or down the list and 'pop' entries from the top of a pllist/alist and push it to the bottom or something like that

19:11:00 holycow i've looked at loop and iterate and i thiiiink i kinda get some ways to think about that.

19:11:33 holycow what might i want to look at as a concept and google to be able to do something like that? i'm not searching up anything obvious, everyone seems to iterate over a whole list and be done with it.

19:12:37 Xach holycow: like keystrokes without hitting enter?

19:12:49 holycow *nod* arrow keys

19:15:02 Xach holycow: that's a good q, i haven't done something like that. i've always thought of making an emacs UI a la sldb or the inspector for that.

19:15:08 fiddlerwoaroof holycow: basically you can choose between either implementing the terminal-control bits yourself, or use something like linedit/readline/etc.

19:15:13 fiddlerwoaroof or curses

19:15:30 holycow OH!

19:15:50 fiddlerwoaroof for the key-handling

19:16:25 fiddlerwoaroof You probably also need a "cursor" structure that maintains the current element of the list and the directions you can go from there.

19:17:39 holycow ok, i knew i was completely not thinking about this right. that looks right.

19:17:40 fiddlerwoaroof The annoying thing is that "raw" keyboard input is really crufty in terminals

19:18:02 fiddlerwoaroof For navigation you might look into zippers

19:19:02 holycow never heard of that before, huh

19:19:24 holycow okay, lots to google. off i go. thanks for the directional tips

19:19:38 fiddlerwoaroof It's basically a functional way to implement a navigable data structure

19:57:53 _death holycow: you can start with this https://gist.github.com/death/e4dcaf9e1a2dc8aacdef32a9831f25e5