libera/#commonlisp - IRC Chatlog
Search
20:14:32
phantomics
Here's some discussion about wasm/CL concerns: http://article.gmane.org/gmane.lisp.steel-bank.devel/19495
20:24:10
rdrg109
[Q] newbie here. Just as I can create tests for Emacs packages through the ert package. Is there any widely used package for testing Common Lisp modules?
21:01:56
entre-parenteses
phantomics: Thanks for the reference! I'm having trouble accessing the gmane.org article but I'm reading through the PR comments - hopefully that covers most of what's discussed.
21:56:03
sm2n
kind of late and Guest63 seems to have gone, but for posterity—SO is bigco now as well, it got bought out recently
22:00:42
rdrg109
I'm gonna put it clearer: I've recently installed Quicklisp and the documentation mentions that to install a package, you need to execute (ql:quickload system-name), but before doing that I would like to know the docstring of ql:quickload to understand what it does
22:01:59
sm2n
there are many ways to do it, but easiest is probably C-c I #'ql:quickload to open it in the slime inspector
22:17:28
rdrg109
[Q] Thanks for the help! All of them worked. Another quesstion: Let's say I install a package with (ql:quickload "package-name") How to list all the functions that are defined by a given package?
22:19:22
Bike
(loop for s being the symbols of "package" when (fboundp s) collect s else if (fboundp `(setf ,s)) collect `(setf ,s))
22:19:51
Bike
a given quicklisp system may have any number of packages, and the names of any packages defined don't have to coincide with the name of the system
22:20:03
_death
(package-name: C-c C-i ... you could also use lisp's introspective capabilities.. (remove-if #'fboundp (apropos-list "" "PACKAGE-NAME")) ;; homework: write a better apropos
22:37:02
rdrg109
[Q] I'm using SBCL + Emacs Slime, is it possible to get the list of all existing/loaded functions?
22:40:02
phoe
loop over all packages, loop over all external symbols of a package, collect that symbol if it is fboundp and does not name a macro and does not name a special operator
23:06:34
Bike
you probably don't even want all the external symbols, unless you're really interested in sbcl compiler internals
23:09:08
White_Flame
rdrg109: tab completion is much more useful than a massive list of thousands of things
23:10:02
White_Flame
you can do sb-ext:<Tab> to see all the exported symbols in a package, for instance.
23:10:25
White_Flame
and then search that list however you want, or from whatever prefix you tab from to pare it down
23:23:15
jasom
On Firefox it's 2 minutes before it prints "Startup completed" and a total of about 5 before you get a REPL.
23:25:34
jasom
about 3 years ago I said I'd profile the doppio JVM to see where the hot-spots are... yeah I didn't do that
23:29:46
jasom
Naive (doubly recursive) fibonacci of 20 takes ~2 seconds on Doppio/Chrome vs 11ms on the native JVM
23:30:43
jasom
My new plan: convince the "Must Rewrite Everything In Rust" brigade to make a JVM in rust, and compile *that* to wasm.
0:51:14
Bike
in that case it needs to be accepted asn an initarg to the direct slot definition class, and you'll probably need to specialize compute-effective-slot-definition to get the information into the effective slot definition as well
0:54:07
Bike
here's the basics. a direct slot definition is the particular slot definition for a class - with no inherited information. the direct slot definition is constructed by, essentially, (apply #'make-instance [slightly-modified-slot-specification])
0:54:25
Bike
so if you want to have a slot (foo :initarg :foo :mykeyword baz) you need make-instance to understand :mykeyword
0:55:06
Bike
Which you can do either by adding a slot to your direct slot definition class, or by specializing one of the instance initialization methods - so basically the same as for any old class
0:55:23
Bike
Next, the system will compute an effective slot definition - this is the definition incorporating inherited information
0:56:17
Bike
For that to work with your new information, you will have to define a method on compute-effective-slot-definition that figures out how to merge the information from all of the direct slot definitions, and puts that in the effective slot object
0:57:37
Bike
I linked it the other day, but you can see an example of this in cl-jupyter, which adds a :trait keyword
0:58:07
Bike
you can see the slot definition classes that are defined, as well as methods on effective-slot-definition-class, compute-effective-slot-definition, and direct-slot-definition-class
1:13:00
kakuhen
I did the mistake of trying out qtools on a Mac and pulled in two dozen dependencies that I don't use or need
1:15:11
Bike
Josh_2: Say you have (defclass foop () ((%bar :initarg :bar :type integer))) (defclass fooc (foop) ((%bar :type fixnum)))
1:15:29
Bike
Josh_2: there's a direct slot for the %bar in foop, and a different direct slot for the %bar in fooc
1:15:58
Bike
Josh_2: Then, an effective slot for fooc has the information from both - initarg :bar, type fixnum
1:19:27
Bike
The inheritance can get complicated if there are multiple superclasses, or depending on the information
1:19:47
Josh_2
So if I want subclasses of classes defined with my superclass then I need an effective slot as well as a direct slot
1:20:01
_death
kakuhen: nope.. looking at the uninstall code it does delete some text files and the local archive, but I never did that
1:30:23
Josh_2
Okay, I am getting an error saying there is no application method for generic function sb-mop:slot-definition-allocation when called with <my direct slot>
4:14:33
beach
raeda: Did you find a Common Lisp system to contribute to? Or a separate project to work on?
4:17:16
raeda
Instead of retrofitting ABCL with new JVM features, it might be easier to make a JVM backend for SICL though
4:23:58
mayureshkathe
just to give an idea; i fiddled with autolisp in 1995 as an engineering intern.
4:27:20
beach
mayureshkathe: On Lisp is an advanced book about Common Lisp macros. I suggest you start with something like Practical Common Lisp.
4:28:12
mayureshkathe
i am actually starting off with "computer science logo style" to work with a lisp which has an approachable syntax for someone coming-in from the world of c++.
4:29:12
mayureshkathe
once i get confident about thinking in the functional way, i'll get to common lisp.
4:29:44
beach
That's a very strange road, especially since Common Lisp is not used much for functional programming.
4:29:50
mayureshkathe
though, if i fail, i'll be working through that book by touretzky to start-off afresh.
4:30:26
mayureshkathe
beach, common lisp isn't used for functional programming? what paradigm is the prefered one then?
4:30:29
beach
Touretzky's book is not very good if you already know something like C++. I honestly suggest PCL.
4:31:18
beach
mayureshkathe: Well, Common Lisp is multi-paradigm. You will see functional programming in things like macro expanders. Otherwise, modern Common Lisp code uses Common Lisp-style object orientation using CLOS generic functions.
4:31:21
susam
Nice. I have a similar story. I learnt CL out of curiosity 14 years ago. Did not really do anything serious with it. Used Python for writing most of my personal tools. C, C++, and Python at work.
4:31:47
susam
Then two things happened. (A) Someone at work wrote a DSL engine to specify correlation rules to analyze the data we were dealing with. It was a complicated piece of code and quite difficult to maintain. It immediately occured to me that this DSL could have been much simpler in CL.
4:31:52
susam
(B) I also began to get tired of Python. Every upgrade of dependency packages has the potential to break things. I am older now. I don't have the time or energy to fix breakages introduced by other developers because they don't care about backward compatibility anymore. CL's and its ecosystem's remarkable stability attracted me.
4:33:24
mayureshkathe
i mean, i even got tired of c++ with it's frequent version upgrades, though once in every 4~5 years.
4:34:22
susam
C++ keeps getting more and more complex. C++03 itself was complex enough. C++11 was good and I think it could have stopped there.
4:34:47
mayureshkathe
it's like everybody is trying to come up with their own language and via for mind space.
4:35:11
beach
So, I recall Autodesk having a project to convert AutoCAD to Common Lisp, and they even started advertising for Common Lisp programmers. But the project was apparently canceled.
4:36:06
mayureshkathe
beach, did you know, now a days, AutoCAD has dotnet-based languages along with AutoLisp?
4:36:14
susam
One of my favourite C++ jokes: https://i.imgur.com/3wlxtI0.mp4 . It really drives the point how much there is for a beginner to learn in C++.
4:37:54
mayureshkathe
beach, one of my school classmates worked for AutoDesk on C# integration for AutoCAD.
4:38:42
susam
By the way, there is #lispcafe for off-topic chat but not all my favourite people of this channel hang out there. What is the channel's opinion on off-topic chat like this? Okay when otherwise silent? Not okay?
4:41:08
loke[m]
beach: probably because they didn't try enough (not enough buy-in, causing fragmentation internally). That's the usual explanation.
4:42:36
loke[m]
beach: That sure sounds like internal fragmentation to me. One hand announcing something the other hand is still working on.
4:43:07
mayureshkathe
beach, agree about C++, but OO is definitely an overkill for an extension language.
4:43:35
loke[m]
mayureshkathe: why? The object orientation features should be the core of the extension API.
4:43:39
beach
mayureshkathe: That's part of my problem with it. Writing software in (say) a static language and then using Lisp as an extension language is like the words combination.
4:44:29
beach
mayureshkathe: You will get a much nicer, faster, and more maintainable system if you write everything in Common Lisp.
4:45:37
loke[m]
Is there a current issue with the version of static-vectors in QL and the latest version of SBCL? It appears static-vectors is trying to access SB-KERNEL:SYSTEM-AREA-UB8-FILL which is not available in recent SBCL
4:45:42
mayureshkathe
though, i had once noticed a cmucl implementation of a numerics library that far outperformed the c counterpart.
4:46:14
beach
mayureshkathe: As I often say, it is impossible to write a C++ program that is both modular and fast. And since modularity would be a requirement for such a large project, there is no way the code can be fast.
4:47:22
beach
mayureshkathe: Plus, combining a static and a dynamic language creates a maintenance nightmare.
4:48:11
mayureshkathe
beach: true that, our mechanical engineers at l&t used to rip out their hair at times while sharing AutoLisp code.
4:49:31
beach
mayureshkathe: Several projects I have known in the past chose C++ "because the compiler is known to generate fast code", but then to keep sane, the developers introduce smart pointers and reference counters, thereby slowing down the code by a factor 10 or so compared to the equivalent Common Lisp code.
4:49:43
mayureshkathe
another off-topic question; if my aim is to work with common lisp just as a hobby, would it make sense to migrate to LispWork from SBCL under Windows?
4:50:03
beach
mayureshkathe: But they still think their system is as fast as it can be, because, after all, the C++ compiler is known to generate fast code, right?
5:01:32
mayureshkathe
okay, in the meanwhile, i took a decision, i'm sticking with ubuntu + sbcl + emacs + slime
5:03:01
susam
mayureshkathe: I switched to Emacs after 18 years of Vim. I like it. It is just took a while to become comfortable with it.
5:03:25
edgar-rft
mayureshkathe: Ubuntu is based on Debian packages and if I remember right then CMUCL was dropped from Debian because it can't be automatically built by C-style autotools. Raymond Toy complained about this some time ago.
5:03:51
moon-child
I remain halfway between emacs and vim. And started working on my own texteditor so we'll see what happens
5:04:01
susam
The main reason I switched was because I was using Emacs + SLIME for Lisp already which gradually kept exposing me to Emacs' other features. Over time I realized that I could be equally productive with Emacs if I were to use it fulltime.
5:06:14
edgar-rft
One of the main reasons why SBCL was forked from CMUCL is because the CMUCL build process needs to be hand-tuned and is a bit whacky.
5:08:02
jackdaniel
beach: speaking of c++: this language is less than the sum of its parts (i.e there are numerous sensible parts of c++ but put together they don't really play)
5:09:20
edgar-rft
mayureshkathe: CMUCL is probably faster in some aspects but SBCL is *much* easier to maintain
5:13:41
mayureshkathe
beach: there was a numerical processing system written in cmucl which was way faster than all those written in c.
5:14:51
moon-child
I find it doubtful you can do numerical processing way faster than any existing solution; the bottleneck is generally memory bandwidth, and when it's not it's usually the hardware's numerical capacity
5:19:26
edgar-rft
CMUCL definitely is a great piece of work but the practical problem is that with today's multi-core and multi-level-cache CPUs mainaining *fast* assembly code is a real challenge. The low-level hardware has become a lot more complex than it was at the times when CMUCL had started.
5:20:12
moon-child
I don't know as it's more challenging per se, but the performance characteristics have definitely changed
5:24:05
raeda
What are people's opinions on Lem? I'm not an Emacs power user so the two are pretty much the same for me
5:47:23
beach
raeda: It looks like a pretty traditional Emacs clone to me, except that it is written in Common Lisp, of course.
5:48:10
beach
raeda: The result of that is that it will inevitably be missing lots of Emacs features, while not providing a substantial improvement to editing Common Lisp code.
5:48:30
raeda
coat: not sure what it stands for, but it's an editor written in CL https://github.com/lem-project/lem
5:49:24
beach
raeda: On the other hand, we are working (very slowly) on an editor that we hope will provide a much better experience with editing Common Lisp code, namely Second Climacs.
5:50:05
beach
Again, even when configured to look like Emacs, it will obviously lack tons of features of Emacs, but at least it will have the advantage over Emacs for editing Common Lisp code.
5:50:07
coat
does Lem support CL as a configuration language? the readme does not say a lot about the kind of things curious folks would like to know.
5:50:52
coat
one thing I like about Emacs is that it is first and foremost an Emacs Lisp interpreter and Emacs, the editor, the UI, etc. are coded in that Emacs Lisp interpreter. so Emacs Lisp interpreter starts first and executes the editor.
5:50:58
beach
coat: Since the entire thing is written in Common Lisp, it would be surprising if you couldn't modify it in arbitrary ways.
5:52:12
beach
Which is a better design in my opinion than Emacs Lisp. Though things were different when Emacs was written, so this is not an accusation of bad design.
5:53:39
beach
I frequently quote (from memory) my email to RMS when he announced GNU Emacs. I wrote something like "I think it would be much better to first write a real Lisp system, and then write Emacs in it" (as I had experience from with Multics Emacs), to which RMS answered "Sounds good. Let me know when you have implemented it".
5:59:26
beach
I am not sure he remembers that I was the author of that mail, but I have met RMS a few times much later, and he was in fact an invited guest of our department for I think two weeks at some point.
7:53:49
kakuhen
so i decided to look into libfixposix a bit more and now i have ruled out using io-lib for anything
7:54:19
kakuhen
did the mistake of testing libfixposix on mac os, and caused an annoying error that had to make me reinstall my os
7:55:09
kakuhen
earlier today i also tried out qtools, and that also failed, though in a considerably more graceful manner than the io-lib stuff.
7:58:37
kakuhen
well I was looking at my options for GUI toolkits in common lisp, just out of curiosity
7:59:26
beach
Then work on changing the appearance (but that is also being worked on) rather than taking on a huge foreign library will all the work that implies.
7:59:27
kakuhen
A lot of alternatives to McCLIM I found ends up using FFI voodoo to get the job done, except for Ltk
7:59:47
kakuhen
Ltk is very interesting because your lisp image just talks to the tcl interpreter, so there's no random ffi issues to worry about there
8:01:14
beach
McCLIM is being actively worked on, and it is getting better by the day. If more people put in a small amount of work (like another "look"), then others will benefit as well, and we will have a truly great GUI library.
8:01:56
kakuhen
anyway, CAPI from LispWorks looks very interesting, though I'm not sure if I want to spend $1,500 just to mess around with it :x
8:02:26
beach
Good. Also the #clim IRC channel is very active and help is given when people have questions.