freenode/#lisp - IRC Chatlog
Search
8:54:13
jeosol
I recently dabbled with it again, and someone here ( i forgot who), I think Luis, showed me some lisp interface libs
8:55:08
beach
My (admittedly small) family was in charge of the documentation for CPLEX for a long time.
8:57:02
jeosol
btw, been trying to do remote calls to scale my applications. I recently started using docker and learned about swank-client.
8:59:04
jeosol
I am doing some benchmark now running async jobs, seeing how may connections I can make to a docker running lisp (one container).
9:07:49
beach
Actually, Bike and karlosz are the ones working on the compiler these days. I am doing bootstrapping.
9:10:29
beach
jeosol: We have also forked off a few projects. Eclector is quite good these days. Trucler (lexical environments) seems to work. So does Clostrum (first-class global environments). Incless (Common Lisp printer) is being worked on.
9:12:07
beach
And of course there are several tools that are independent from the SICL project, like Clouseau, McCLIM, CLIM flamegraph, etc.
10:41:31
heisig
What is the state of Common Lisp in Visual Studio Code these days? I am asking because some of my students are very interested in working with Lisp, but don't want to switch to Vim or Emacs.
10:43:11
moon-child
heisig: maybe try https://portacle.github.io/? It's an 'emacs distro' bundled up with slime and sbcl
10:45:05
heisig
I know about Portacle. That is what I usually recommend newcomers. But I still need to explain plenty of C-c C-... tricks before they start enjoying it.
10:45:32
no-defun-allowed
There is https://marketplace.visualstudio.com/items?itemName=ailisp.commonlisp-vscode but there's no debugger support apparently.
10:46:11
heisig
flip214: Sure, that works for some people. But I still feel I am scaring away 50% of the potential Common Lisp programmers.
10:48:05
heisig
Interestingly, the group of people that doesn't want to learn Emacs also doesn't care about the full power of Swank. They usually just want completion and indentation.
10:55:22
jackdaniel
beach: https://ilyasherdotorg.files.wordpress.com/2020/01/too_busy_to_improve_-_performance_management_-_square_wheels-1.png -- related picture
10:55:45
beach
If I were an employer, I would ask the university for a list of those, so that I wouldn't bother interviewing them for a possible job.
10:56:56
flip214
heisig: I think that's a good initial filter... just make "learn vim or emacs" (or in the other order) 20% of the final rating of that class ;)
10:57:26
flip214
only people who're interesting in learning the right tools will know the right tools later on!
10:57:27
jackdaniel
that said, I'm sure that it would be easier to sell unknown features like slime had the person not need to learn about emacs first
10:57:49
jackdaniel
(and there are efforts towards that goal, there is i.e slimv for vim, and I think that there is a client for the "atom" editor)
10:58:08
jackdaniel
so things are not that bad, probably more a discoverability problem than a wall for newcomers
10:59:41
beach
When I was in charge of the undergraduate program, we had a first-year course called "development environments" where we taught them Unix tools, Emacs, version control, GDB, etc.
11:00:59
beach
jackdaniel: Exactly! And during the rest of the teaching program, we can assume knowledge of those tools.
11:01:05
phoe
these are important because they still make use of swank, and they reimplement just the frontend/slime part
11:01:08
no-defun-allowed
heisig: I agree with beach, I think they're missing out. There's still a bit more one can get out of that VS Code extension though, but it may just be a hassle to set up.
11:01:38
phoe
I assume that someone with enough patience could implement a swank frontend in vscode, too; it just hasn't been done because nobody did it
11:01:39
heisig
Firstly, it is not the case that you can't be productive outside of Emacs (blasphemy, I know).
11:01:51
jackdaniel
beach: that reminds me the book "concrete mathematics", very useful things. but I'm getting into offtopic :)
11:02:19
heisig
But more importantly, I see that many people learn new languages after casually tinkering with them.
11:04:06
heisig
phoe: Thanks for pointing me towards the sublime and atom plugins. That could be useful.
11:04:21
no-defun-allowed
To some extent, it would be like learning Smalltalk with just terminal IO (like with GNU Smalltalk or that didactic subset from that miniature interpreter tutorial) - but I guess you can still use SBCL's debugger and stuff with just a terminal emulator.
11:06:37
beach
heisig: You seem to suggest that the problem is just one of documentation. Like, if it weren't presented as "First learn Emacs", but as a complete environment, then it would be an easier sell.
11:08:58
ck_
maybe incentive is also a factor, a demonstration of what value can be gained by investing the time
11:09:00
phoe
emacs has multiple idiosyncracies that do not make sense to people used to other editors, with the most famous one being C-z C-x C-c C-v not doing what the average non-Emacs user expects them to do
11:09:02
jackdaniel
one could argue, that learning emacs increases productivity, and that position could be defensible, however when someone wants to learn common lisp to increase productivity, having an emacs as a prerequisite seems like a big distraction -- that said, I have a strong recollection of such discussions on this channel :)
11:09:24
ck_
I remember fondly a little swf screen recording on the slime website, narrated by a person called yusuke I believe
11:10:18
phoe
I am currently helping one person learn Common Lisp. learning Emacs, as much it is a contemporary prerequisite for real CL work, is also a distraction because I want to spend time teaching CL, not to spend time answering "how do I undo the last thing I did in this editor, control-z does a weird thing"
11:10:58
phoe
ultimately, to total newbies, I want to teach Common Lisp, not Emacs - and Emacs makes this impossible
11:12:44
phoe
it's an amazing recent development; I might actually try it someday with slima instead of emacs
11:13:33
heisig
We were also discussing a fundraiser for better VSCode integration at SBCL20. But I think that discussion went nowhere.
11:14:57
beach
phoe: So that suggests that only known tools are allowed. But doesn't that contradict the fact that people seem to be willing to learn a new IDE for a new language? Or have I misunderstood that?
11:16:05
heisig
scymtym: That is why I was asking about the current state of things. Is some of this already in a presentable state?
11:16:51
beach
phoe: If it just a problem with Emacs key sequences, then one could teach them the use of the menus.
11:17:23
scymtym
heisig: i don't know. mine isn't. it is a vehicle for playing with static analysis. one other one is a SWANK adapter, i think
11:17:39
jackdaniel
beach: emacs has more unusual quirks that are annoying at times - like automatic frame managament when a debugger pops up
11:20:02
phoe
If you try to bootstrap knowledge from an environment that is already somewhat familiar to people, then there is less to learn in order to be able to use the language.
11:20:12
phoe
If you try to bootstrap knowledge from an environment that is unfamiliar to people, then there is much more to learn in order to be able to use the language.
11:20:54
phoe
And that's not a deal that everyone wants to make, since time is the ultimate currency.
11:21:37
heisig
beach: Selling a programming language is not so much different than selling, e.g., clothes. The most important part is (unfortunately) not the quality of your products but to get people into your shop in the first place.
11:33:59
beach
I still feel that some important piece of the puzzle is missing here. I guess I'll think about it over my lunch break.
11:36:59
scymtym
i wonder how pharo is sold to people. maybe it is easier since the editor question doesn't come up if you only offer one complete environment
11:40:33
green_
I don't get the clhs docs for 'search'. http://clhs.lisp.se/Body/f_search.htm . What is 'start-end' that the Description references?
11:46:52
green_
is anyone thinking of doing that.. just with fixes like this, which is an obvious error?
11:48:24
jackdaniel
since it is obvious, there is not much incentive to undertake a massive endavour of pushing for a new standard
11:49:26
scymtym
beach has plans for such a document which would focus on corrections and clarifications. i don't think the result is intended as a new standard, though
11:52:45
phoe
there were several initiatives to produce a new CLHS-like document, but nothing conclusive just yet - it's a massive amount of precise and thankless work to do something like that
11:53:24
phoe
(*especially* if your want the document to be machine-reproducible from source TeX files that CLHS was generated from)
11:54:57
green_
thanks. the :start-end fix isn't in that list. I wonder if there are many more of those.
11:57:31
mfiano
I can also speak from experience. I spent about a month total and got less than 1% finished.
12:02:48
green_
somebody should make a browser plugin that applies these changes to the online spec :)
14:56:56
jmercouris
let's say I want EVERY class that inherits from class "Salmon" to implement a "Swim" method
14:58:17
jmercouris
if it isn't possible to enforce a protocol, what is a good way of showing that in the design that I intend for a protocol to be followed
14:58:27
jackdaniel
(defmethod swine :around (object) (if (deerp object) (call-next-method) (error "not a deer")))
14:59:40
jmercouris
because swine is a noun, and I'm having a lot of trouble thinking about it as a method
14:59:44
jackdaniel
no, swine was an implementation of the swank protocol for climacs, I have no interest in swimming
15:01:11
jackdaniel
the point is that you may put an around method specialized on t that checks preconditions
15:02:55
jackdaniel
that would be answers. yes, you could use a library traits, define a :before method instead, define a non-standard generic function that checks the type of an argument
15:03:33
jmercouris
but I am really thinking about how to indicate that a specific object should conform to a protocol
15:04:32
jmercouris
I guess I could check to see if there exists a method that specializes quack on that object
15:15:21
phoe
which I guess should still work even though I have not taken a look at it in a long while
15:43:37
Lycurgus
phoe, I meant that I presume the collective readership/audience will appreciate both the function and it's documentation
16:45:44
mfiano
I only know of one threading macro library in CL that handles diamond symbols at an arbitrary depth, and at first glance it appears this one does not.
16:46:21
phoe
arrow-macros depend on a code walker to implement this, but the author of arrows does not want to depend on such a heavy piece of machinery
16:52:48
mfiano
When I used threading macros, I switched to arrow-macros because limiting diamonds to the top level is pretty restrictive in the code I was writing
16:53:10
Bike
looks like it would happily replace the <> in '<>, since it doesn't know anything about lisp?
17:10:55
jeosol
Is there anyway, I can build an executable (SBCL) but have it run and enter a repl. I understand building application takes an entry function. I am trying to avoid (re)building a docker, if I can just rebuild on my local machine, then push to docker.
17:11:29
jeosol
Using core files, I obviously run into the issue of different runtime. Is there some hack around this?
17:11:40
lotuseater
but in a class that inherits from superclasses the :allocation :class isn't given to the subclass
17:12:17
jeosol
really. I tried to build a core file on my box but push it to the docker image and do sbcl --core corefile
17:12:53
jeosol
so maybe that is the hack I need, build an executable but leave out the entry function
17:23:59
jeosol
phoe: for my learning, when you say match, that's takes into account the machine/os. So using the same SBCL compiler v2.0.10 and say OpenSuSe, will not work for SBCL v2.0.10 and Debian
17:24:59
phoe
jeosol: AFAIK they must have the identical binary, so differently compiled binaries with different md5 hashes likely won't work
17:26:51
lotuseater
as far as i understand yet arrows are coming from category theory und functional programming for concurrency
17:28:48
_death
ebrasca: they may make sense in cases where you have a lazy processing pipeline, e.g. with series (->> (scan-file ...) (map-fn t ...) (choose-if ...) (collect)) but otherwise they're just massively abused
17:29:14
jackdaniel
is it possible on sbcl for the object to change its address (or whatever that number means) asynchronously? I mean the number in #<some-class {123412341234}>
17:30:29
jackdaniel
well, asynchronous in a sense that I'm not doing anything what could cause side effects, that's not the right term
17:31:09
jackdaniel
but it "looks like asynchronously", and it confused me quite a bit, because I was trying to find a piece of code that swapped my object (and find out when that has happened)
17:32:30
jackdaniel
thanks Bike and beach, that's the only explanation I could come up with - and printing a gensym seems to "prove" that it is the same object
17:33:47
beach
Sure. It happens to me all the time, given that I probably allocate huge amounts of memory, so the GC runs all the time.
17:38:34
jeosol
I know there is talk about CL libs having poor documentation, but given most libs are developed by small teams/individuals, there isn't much time to do full documentation for every function and also show how to use them.
17:38:57
jeosol
I say that in the light of having discovered gems and use cases by actually looking at library source code.
17:39:18
beach
jeosol: I don't think you can generalize that way. The libraries I mentioned before are usually well documented.
17:39:27
phoe
jackdaniel: yes, the GC is moving these objects - I asked about specifically this on #sbcl some time ago
17:39:46
phoe
in other words, the identity printed by print-unreadable-object is allowed to change at any time
17:40:29
jeosol
Pardon if my comment came out as a generalization. it is also not intended to mean we should not document or make things clearer
17:41:33
jeosol
I am considering teaching CL in a class setting, not formal, but introducing the students, so look for ways to avoid the frustration I hear with emacs and other tooling. I am no expert though
17:42:00
jeosol
esbrasca: I guess, I conflated "tutorial/examples" with documentation. I meant the former.
17:43:16
jackdaniel
sure, I'm usually recommending this writing by sjl_ when the topic of documentation comes up, because I've really enjoyed reading it
17:48:52
jeosol
beach: I do remember your metamodular document has a section about guidelines for documenting libraries
17:50:48
beach
jeosol: Oh? Great! I can never remember what stuff I write. People keep reminding me all the time.
17:51:58
jeosol
I remembered that section because around that time, I was trying to write and document better; so I looked at the google guide, norvig/pitman guide etc.
17:52:34
jeosol
beach: IIRC, in one of your libs you recommented for better doc, you advocted prepended % to slot names
17:53:45
beach
jeosol: I have to vanish. My (admittedly small) family just announced that dinner is served. I'll be back tomorrow morning (UTC+1).
18:00:13
ebrasca
jackdaniel: Probably I need to practice this fantastic tips of how to write documentation, instead of only reading it.
18:06:32
ebrasca
ACTION think if he master documentation he is going to have 2 topics to learn left : profiling and testing.
18:08:55
fiddlerwoaroof
Testing isn't so hard in lisps: the sorts of things you do to make a codebase nice to work with in the REPL makes testing easier too
18:09:20
fiddlerwoaroof
And things like WITH-INPUT-FROM-STRING make a huge difference here, compared to Java or somethign
18:10:51
fiddlerwoaroof
What I've found is that separating the part of code that interacts with outside things (disks/etc.) from the code that doesn't need to (file format parsers, etc.) makes a huge difference
18:11:30
fiddlerwoaroof
ebrasca: that's tricky :) property testing helps there, but it can be relatively slow
18:12:03
fiddlerwoaroof
I find well-chosen unit tests are often sufficient for the certainty you need in most cases
18:12:43
ebrasca
fiddlerwoaroof: How can you be sure you have 100% coverage or data waiting to be lost?
18:19:52
fiddlerwoaroof
ebrasca: yeah, for filesystems it gets more complicated because the stakes are higher
18:20:47
fiddlerwoaroof
In my experience, though, unit tests are a good way to discover edge cases and especially because they're easier to write and maintain than a lot of other sorts of tests
18:21:19
fiddlerwoaroof
Proofs, for example, often are too difficult to change to be feasible for anything except the most important code
18:48:09
phoe
which is an original development, not coming from clojure - mostly because clojure doesn't have places
18:48:31
fiddlerwoaroof
ebrasca: well, I'd say the first thing to do is to write unit tests, because that's easy to do and it'll help you think about things like API design and code structure
18:48:55
fiddlerwoaroof
phoe: is that just relying on the macroexpansion provisions of the specification?
18:49:51
phoe
fiddlerwoaroof: not really; I am currently rewriting arrows to expand into LET* for readability
19:16:15
phoe
my current implementation of arrows makes the assumption that each form passed to the threading macro is going to be evaluated; splicing such a form into a form with special evaluation rules, e.g. OR, breaks this assumption
19:16:39
phoe
and now that I think of it, I have no idea if this is acceptable from an implementation of arrow macros
19:19:45
fiddlerwoaroof
I've written a lot of Clojure code that uses arrows with macros that change evaluation rules
19:24:42
pfdietz
Property based tests are wonderful and powerful. I use them to find all sorts of bugs.
19:25:16
pfdietz
All those weird SBCL bugs I report? All due to various kinds of property based tests.
19:26:12
pfdietz
Example property: "the SBCL compiler should never signal an error, even on erroneous input".
19:26:42
pfdietz
Or: "a valid Common Lisp expression should do the same thing regardless of OPTIMIZE settings".
19:28:57
fiddlerwoaroof
pfdietz: yeah, it's a great tool my experience, though, is that I use the property tests to generate more deterministic test cases in my unit test suite.
19:30:39
pfdietz
Sure, you want to capture the failures, just to make sure they dont unfix themselves later. But PBT keeps finding new bugs as development introduces them. And sometimes it finds a very low probability failure, something that took billions of inputs to expose.
19:39:33
pfdietz
Nice! It's interesting that they have value later. That may say something deep about testing.
19:52:53
pfdietz
I have considered using random test generation and minimization to generate unit tests, not by keeping failures, but by keeping tests that satisfy some other property (coverage, killing mutants). This might give a distilled unit test set that preserves some of the value of a prolonged run of the random tester.
19:57:42
fiddlerwoaroof
pfdietz: I think unit test's primary value is in helping you figure out the problem space as you're working
19:58:24
fiddlerwoaroof
Making it efficient to run 100+ picked examples every minute or so to verify that you're making progress