libera/#commonlisp - IRC Chatlog
Search
23:41:26
jcowan
Naturally. Writing a CL requires a bunch of students or very remarkable stick-to-it-iveness
3:20:02
beach
Maybe some people were asleep when I suggested a project 12 hours or so ago, so let me repeat it:
3:22:27
beach
It would have clickable presentations in addition to keyboard shortcuts, so that the mouse could be used, with context menus and such.
3:23:12
beach
I don't know whether vim has something like magit, and if not, I would think such a project would be attractive to users of vim.
3:23:59
beach
And splittist pointed out to me that Shinmera has written "legit" which is a Common Lisp library for interfacing with GIT, so that part is partly done.
3:28:31
moon-child
I have never found git 'frontends' very interesting, but I hear good things about And it encourages lots of monomorphization in e.g. ranges. fwiw
3:36:06
beach
A McCLIM pane would still be useful of course, and it would be an essential part of a future IDE for Common Lisp.
3:41:14
moon-child
I wonder the extent to which it's meaningful to create an 'IDE' vs a general window-management paradigm which can be used to organize arbitrary tools; including those which are used for software development, but not limited to them
3:42:41
beach
I am thinking of a collection of pane classes for McCLIM that the user can then assemble in various ways. So McCLIM would act as a "window manager".
3:43:24
beach
Like an editor pane, a debugger pane, an inspector pane, a backtrace-inspector pane, a GIT pane, an ASDF pane, etc.
3:44:21
beach
I think for Common Lisp users, there is no other choice, because people have individual preferences that can't be met by one common design.
3:44:55
beach
Plus, it's a development environment for Common Lisp written in Common Lisp, so programmers are capable of doing the "pane assembly" themselves.
3:47:07
beach
But the important part here is that these tools can collaborate, which is made easier with CLIM presentations and such.
4:11:35
rdrg109
[Q] Consider this simple script: (let ((items '(1 2 3))) (push 4 (cdr (last items))))
4:11:53
rdrg109
Why I'm getting: Destructive function SB-KERNEL:%RPLACD called on constant data: (3)?
4:13:03
beach
I don't know what you are trying to do, but you can create the list using LIST instead of using a literal object.
4:15:23
rdrg109
beach: Given a list, I want to insert at the end of it. I found this question at Stack Overflow: https://stackoverflow.com/questions/13359025/adding-to-the-end-of-list-in-lisp
4:16:46
rdrg109
The reason why I used let in my example is because I use let for writing minimal working examples. Thus, I can see the behavior of functions without cluttering my SLIME REPL session with global varaibles. I guess I need to stop doing that and use defvar instead. Is that right?
4:16:49
beach
Your technique for inserting is correct, and the code in that link is really bad in many ways.
4:17:12
mfiano
rdrg109: ' is a reader macro that expands into (quote ...). As the name suggests, a reader macro applies its transformation at read time, before any code is compiled.
4:19:03
rdrg109
As someone coming from Emacs Lisp, I found that disturbing because I've been using that in all my Elisp code.
4:19:07
mfiano
These forms should never be mutated, instead copied or created at runtime. This is because they are expanded at read-time, and thus are embedded into compiled code.
4:20:41
beach
rdrg109: Let me give you an example of why you should not do that. Try this: (defun ff () '(1 2)) then (defparameter *l* (ff)) then (setf (car *l*) 234) then (ff).
4:22:23
beach
rdrg109: You see, Common Lisp uses what I call "uniform reference semantics" meaning that, semantically speaking, every object is manipulated indirectly through a reference or a pointer. So there is only one list object containing the elements 1 and 2, and that same object is returned each time FF is called.
4:23:55
beach
rdrg109: You should consider yourself lucky that SBCL was able to catch the problem this time. It is not always that easy, and you can have some very strange bugs that are difficult to find if you modify literal data.
4:27:04
moon-child
beach: apparently, the emacs lisp of the code that you showed will run without error, with ... consequences
4:29:17
mfiano
Whether a warning/error is raised is just a convenience. It could just as well launch nethack :)
4:30:12
beach
rdrg109: It is time to go over all your Emacs Lisp programs and make sure you don't modify literal data.
4:31:43
mfiano
It may be unintutive, but Lisp gives us access to different stages of the compiler, within other stages.
4:31:45
moon-child
a perhaps somewhat more practical consideration is interning. An implementation could very plausibly return 5, given the following: (let ((x '(1 2)) (y '(1 2))) (setf (car x) 5) (car y))
4:31:59
mfiano
Consider what would happen if you mutated other literal objects, such as a literal integer of 42 (not that you can without some serious hackage).
4:32:05
rdrg109
Thank you all for asnweing my question deeply. It is of much help. I guess I will have to read more docs and change the mistakes I made
4:49:47
pjb
rdrg109: alteratively you can use copy-list. Notaby in functions that want to modify their parameter, but that can accept literal (immutable) values: (let ((items '(1 2 3))) (let ((items (copy-list items))) (push 4 (cdr (last items))) items)) #| --> (1 2 3 4) |#
4:51:09
pjb
rdrg109: or more wisely, write your functions so they don't try to mutate their parameters at all.
4:51:58
pjb
(let ((items '(1 2 3))) (nconc (butlast items) (cons 4 (last items)))) #| --> (1 2 4 3) |#
4:52:30
pjb
rdrg109: ^ note the use of nconc, which mutates the fresh list returned by butlast, so we don't copy it again.
4:53:25
pjb
So you can use mutation inside your functions as long as you are only mutating objects created by (or for) your function, and not the arguments.
7:51:34
rdrg109
pjb: Thanks for helping! I will need to devote some time to understand what you all mentioned.
7:52:25
rdrg109
Fortunately, Org Babel supports Slime code blocks, so having that + irc logs is helpful for taking notes
7:52:58
susam
Quick survey: What do you prefer for outputting HTML? Writing HTML using CL macros or writing HTML as plain HTML and combining them with Lisp? And why?
7:53:44
moon-child
susam: I generally write plain html. Was at one point working on a macro language that would let you write html but without quotation marks around plain text. Never finished that, though
7:55:37
susam
I have been torn between the two approaches. While writing HTML using CL macros can be convenient as a developer, I worry it would prevent someone else who does not know CL from editing the HTML independently. So far I have been leaning towards writing plain HTML.
8:10:28
lisp123
susam: I like CL-WHO for outputting HTML, but I'm not trying out BKNR.IMPEX - it outputs to XML well (automatically, once you create a DTD). I don't think it will do tables well, but for that I wrote a custom function very quickly
8:11:44
lisp123
In general, I'm trying to store objects now in classes, and then have a defgeneric / defmethod to define a "print-html" method for each object - thus creating HTML files is just printing the objects
8:14:38
lisp123
also check out HTML-TEMPLATE - it's a great solution to allow designers to work on HTML and then have lisp populate it.
8:42:26
splittist
I use djula as a templating solution. Not that anyone should take web lessons from me.
10:46:23
coat
I am trying to load a file from current directory but I get error that the file does not exist. issue only in slime. works fine in shell.
10:47:47
susam
coat: Check *default-pathname-defaults* . Perhaps it is pointing to some directory other than the one you think is the current directory?
10:50:02
coat
susam: thanks. it is pointing to a different directory. i thought it would be automatically set to the directory of my current .lisp file.