freenode/#lisp - IRC Chatlog
Search
0:17:02
Josh_2
I've already made all of the changes you have in that gist but it still struggles to compile, I also had a problem where some function that expected a symbol was getting a list containing a keyword
0:33:34
Josh_2
_death: https://github.com/K1D77A/Parmenides I added the problems I have with compiling as issues
0:34:58
_death
hmm, maybe better to fork the lispm repo which has the original code and then add your patch
0:43:23
Josh_2
_death: https://github.com/K1D77A/Parmenides this is a fork, I don't know how to add issues though
2:35:10
kilimanjaro
Are there any obvious ways to speed this up (e.g. on SBCL), without using multiple cores? https://gist.github.com/kilimanjaro/72eef27b8bd435b82461bfa2124e12ec
2:37:14
kilimanjaro
I am just curious -- the C version seems to be ~4x faster, but I don't really have any sense of why
2:50:54
aeth
kilimanjaro: Is the C version identical to what you just wrote? Because that currently returns nothing, and so can be optimized to do nothihng, but won't in SBCL.
2:56:08
aeth
Well, you can do this: (deftype matrix () `(simple-array double-float (,+size+ ,+size+))) ; except in CCL, if you do this portably and want it to run in CCL you'll have to wrap the defconstant in an eval-when
2:57:14
aeth
Then you can spin off the relevant part (and return c in the outer DOTIMES), e.g. (defun matmul-optimized (a b c) (declare (type matrix a b c) (optimize (speed 3) (debug 0))) (dotimes (i +size+ c) (dotimes (k +size+) (dotimes (j +size+) (incf (aref C i j) (* (aref A i k) (aref B k j)))))))
2:57:36
aeth
And then you can look at the asm in the now smaller function. (disassemble #'matmul-optimized)
3:00:40
aeth_
If you insist on having (safety 0) then you'll probably want to see the full asm in SBCL, i.e. (sb-disassem:disassemble-code-component #'matmul-optimized)
3:02:11
aeth
kilimanjaro: as for the C side, there's a website that does compiler asm output for such things because it's not built into C. You can then see how it differs. I forget the name of the site.
3:03:27
aeth
heh, I think DuckDuckGo was filtering out "C" because it was too short so I searched for C++ instead. It's this. https://godbolt.org/
3:06:06
aeth
So if the shortened version that I wrote has subsantially different generated assembly to what godbolt says for C/C++, that's the performance difference and #sbcl might be interested.
3:06:54
aeth
And if you (setf *print-case* :downcase) before you diassemble, you get the asm in lower case, which might help with the readability.
3:12:35
aeth
and this keyboard apparently needs cleaning because some keys are no longer pressing all of the way and I dropped some random letters in there
3:17:55
kilimanjaro
in this gist (updated), the SBCL disassembly is shown and all of the moves into XMM registers are 64 bit https://gist.github.com/kilimanjaro/72eef27b8bd435b82461bfa2124e12ec
3:23:40
kilimanjaro
so at the very least, if I want to write SBCL-specific code I can use https://pvk.ca/Blog/2013/06/05/fresh-in-sbcl-1-dot-1-8-sse-intrinsics/ etc
4:36:07
beach
The topic of this channel is Common Lisp. The language itself, implementations of it, libraries and applications written in it, etc.
4:37:17
lisbeths
there is more to what is expressed by the english word lisp than what is expressed in CLHS
4:37:51
lisbeths
even if you would like to relegate it to just commmon lisp, there is more that is expressed within the context of the phrase "common lisp" than what is expressed in clhs
4:38:20
lisbeths
newcomers hate this channel because this channel should be named #clhs based on the rules here
4:38:38
lisbeths
you have probably turned countless people away by rudely expecting them to be able to read a document only accessable by software engineers
4:39:31
lisbeths
You should create a channel named #CLHS or something like that, and transfer the rules of this channel to that one
4:39:47
lisbeths
you sohuld not censor people woh want to talk about extending commmon lisp beyond the hyperspec
4:40:34
lisbeths
Can you express to me in your own words what my point is do demonstrate that you understand what I've said
4:42:19
lisbeths
you have done wrong to lisp programmers, but you have done it "perfectly", without error
4:42:50
lisbeths
I half believe you are just an artificial intelligence behind that screen. A perfect machine made by the military or something.
4:48:24
lisbeths
I will protest htat you should leave to #clhs and do not come back or I will petition in #freenode to have you removed.
4:49:06
aeth
It's Friday in most of the world. Has anyone started/continued any interesting projects this week?
4:49:09
jasom_
4 hours ago people were discussing how to get sbcl to generate more optimal machine code, all things clearly mentioned in the clhs
4:50:07
ldb
aeth:not necessarily lisp related, but I heard someone made progress define formal semantics for python
4:51:50
lisbeths
If I shall not be banned then I declare a mutiny and the discussion topic is no longer #clhs but #common-lisp
4:51:58
lisbeths
and I shall discuss #common-lisp as I pleaes and if you do not like it then ban me.
4:53:11
lisbeths
It is clear to me that #common-lisp is the most superior programming language on the earth, because it is a supercategory of ada because it has syntactic macros.
4:53:38
lisbeths
In the 1980s the department of defence made note of ada and common lisp as very nice programming languages which were suitable for its needs.
4:53:52
lisbeths
Common lisp is the current best and fastest programming language for a quantum computer, which is the fastest computer on the public record.
4:54:03
aeth
ldb: Do you think that would work with CL? I think there's a Well-Specified Common Lisp project. It could be a good starting point.
4:56:42
lisbeths
There are many libraries for common lisp which aim to take an implementation of common lisp and apply it to make gtk applications.
4:56:54
lisbeths
it is a false statmenet to say that there is *only* one common lisp project, or that there could only be one
4:57:02
ldb
aeth: be precisely it is small step operational semantics, so I'd say maybe a particular implementation should be picked
4:58:09
aeth
ldb: CL-the-actual-language is just the intersection of how all of the major implementations behave, unless this behavior contradicts the spec
4:59:44
ldb
https://cs.brown.edu/~sk/Publications/Papers/Published/kle-next-700-semantics//paper.pdf
5:09:26
lisbeths
It seems to me that common lisp is the most superior programming language on the planet.
5:11:14
lisbeths
It seems to me that if my previous claim is true that it makes sence for the common lisp community to better advocate for lisp.
5:11:30
lisbeths
If it were in fact the most superior or best current available language then advocating for it would help humanity.
5:11:42
lisbeths
If it were not the best or most superior then advocating for it would reveal that it is not the best or most superior.
5:13:23
lisbeths
It seems to me that if my belief that common-lisp is the most superior langauge is true, then if the industry used common-lisp as a whole then they would not be able to then kick the habit of it, because each time they did so they would benefit negatively.
5:14:10
lisbeths
Thus, I predict that if the industry at large were comitted to lisp it would be so comitted indefinitely.
5:14:30
lisbeths
Therefore, I consider a good way to advocate for common-lisp should be to convince the industry to use it at large.
5:15:47
lisbeths
It seems to me that a good way to convince the industry to try using common lisp at large is a giant marketing campaign.
5:18:09
lisbeths
We can have a bot written in portable common lisp which accepts data as input, expects that data to be an image macro, and which produces memes.
5:18:35
lisbeths
this bot can be rewarded or punished based on how good the user thinks it's memes are
5:18:48
lisbeths
This bot can also be reward or punshed based on the number of google searches for lisp and common lisp
5:21:27
lisbeths
common-lisp programmers can additionally make an effort to promote lisp verbally and on thier online blogging platforms
5:21:48
lisbeths
Since common-lisp is a prefix language, I declare january to be lisp history month.
5:22:50
lisbeths
The first day of january is lisp week and the first day of that week, whenever january first is, is lisp day.
5:23:01
lisbeths
And the first hour is lisp hour and the first minute is lisp minute and the first second is lisp second and so on and so forth.
5:24:22
lisbeths
Lisp history will be for: enjoying common-lisp and lisp history, shaing lisp songs, sharing lisp image macros, lisp poems, and of course, writing and sharing and peer reviewing lisp code.
5:24:36
lisbeths
During lisp month it is traditional to read other peoples lisp code and rate it on github and comment on it.
5:26:45
lisbeths
Another ritual during lisp month is to completely re-read Practical Common Lisp or Gentle introduction to Symbolic computation (which is a beginner's lisp book)
6:04:47
aeth
to get things back on topic again, for anyone who hadn't ignored lisbeths, I'll repeat what I said earlier.
6:04:50
aeth
It's Friday in most of the world. Has anyone started/continued any interesting projects this week?
6:07:49
beach
I collaborated with jackdaniel on Clostrum, which is an extraction of SICL first-class global environments to a separate repository.
6:08:21
beach
And I am working on an "AST evaluator" that will be the basis of a general-purpose cross compiler.
6:09:29
beach
And jackdaniel will create a bunch of macros that are adapted to use Clostrum for ECL.
6:09:53
aeth
Will we see it in all of the major implementations, like with package-local-nicknames last year, or are there significant barriers to implementing it?
6:10:03
beach
Then, Clostrum plus those macros, plus Eclector, Cleavir, Trucler, can be used to cross compile ECL code.
6:10:59
beach
The main barrier is that macros with compile-time side effects, like DEFUN, DEFGENERIC, DEFVAR, etc. must be adapted to use Clostrum.
6:11:38
beach
On the other hand, while I said it can be used as a cross compiler, nothing prevents its use as a native compiler.
6:12:08
beach
And then, it would be normal for an implementation to replace its existing macros with Clostrum versions.
6:12:51
beach
I myself am doing the same work as jackdaniel, but for SICL, since SICL did not use Clostrum in the past.
6:18:57
beach
And the interesting part about the AST evaluator (if it works, which seems to be the case) is that it translates Cleavir ASTs to host Common Lisp code in a way that the resulting code accesses the Clostrum environment.
6:18:58
beach
That way, the host global environment is not involved, but the code can still be compiled by the host compiler, so execution should be fast in most host Common Lisp implementations.
6:20:47
beach
ldb: A single generic function TRANSLATE-AST with a method for each type of AST class.
6:21:09
aeth
beach: so if SBCL were to adapt to support it, then it would compile code as fast as "normal" SBCL?
6:21:55
beach
aeth: A bit slower because it needs to go though generic functions to access the global environment.
6:22:24
aeth
beach: ah, so the dynamic variables would be a bit slower, but the lexical ones (and functions) wouldn't?
6:23:15
aeth
sounds like a reasonable sacrifice to me... the only place where there are tons of dynamic variables is the IO streams
6:24:04
aeth
(dynamic as in dynamically scope... technically "special variables" in CLHS terminology iirc, in case anyone was confused)
6:24:08
beach
Maybe so, yes. But the main interesting aspect of this thing is that it could be used for bootstrapping a Common Lisp implementation like ECL.
6:24:43
beach
You could potentially compile system code on the cross compiler, say to C, and then build the system that way.
6:25:33
aeth
beach: Could it be used to provide a global lexical environment for languages that compile to CL that have lexical globals? (Even though CL itself doesn't.)
6:26:58
beach
Well, every aspect of every ingredient (Clostrum, Cleavir, Trucler, Eclector, AST evaluator) can be customized, so there is great flexibility for these things.
6:30:36
aeth
hmm, so if this was standard "middleware" of sorts, we could "fix" the underspecified nature of DECLARE, at least to some extent
6:32:18
aeth
At the very least, there could be more control. e.g. maybe the user could choose to ignore the (safety 0) ignore of type checking in e.g. SBCL
6:32:42
aeth
while on the other hand, implementations that just ignore DECLARE altogether could have this middle layer insert type checks
6:33:48
aeth
and in particular OPTIMIZE is allowed to have extra optimize qualities, so this could insert new ones, perhaps even programmatically by a library!
6:34:58
aeth
One thing that's currently lacking is the ability to mandate tail recursion in a DECLARE OPTIMIZE when required for the correctness of the function even when normally disabled e.g. (debug 3)
6:35:42
ldb
recently I read the documents of CamlP5 (formally known as CamlP4) and hopes to have such kinds of interface in CL, rather that the ad-hoc treatment of reader-macro
6:39:12
beach
Now, all this stuff requires a lot of work. It would be good if we could get some help with projects using this suite of libraries (Eclector, Cleavir, CST, Trucler, Clostrum, AST evaluator), at least once it is a bit more mature.
6:40:27
aeth
I, for one, would be willing to sacrifice a bit of special variable performance in order to "fix" (more like harmonize) the semantics of DECLARE. The only thing that would be a bigger deal afaik would be getting the implementations to agree on the names of conditions returned by certain errors (especially in destructuring-bind) so portable code could handle these.
6:43:31
loke
aeth: I think the world has pretty much settled on CHARACTER being a Unicode codepoint at this time. Only CLISP is the odd one out, but with it not having had an update in 10 years, I think we can ignore that one.
6:44:01
loke
That said, something analogous to SB-UNICODE should be standardised at least in a library. CL-UNICODE is kinda crap.
6:46:06
aeth
loke: yeah, sb-unicode needs to be turned into a portable thing that's exposed from implementations through a portable library. Perhaps also including string-to-octets and octet-to-strings (in sb-ext, but also in babel, but really it should be built in, at least for utf8)
6:47:26
loke
I think SB-UNICODE is mostly portable CL anyway. It was integrated in SBCL thanks to a Google of code things.
6:57:46
beach
loke: In what way is CL-UNICODE "crap"? I am not disputing it. But I would like to know. Since I know very little about the subject, I ignorantly decided to use it in SICL, but it sounds like I should use something else instead. If so, what would that be?
6:59:27
aeth
beach: e.g. in sb-unicode, to see if something is in a unicode general category I do (eql (sb-unicode:general-category character) category)
6:59:39
loke
beach: It's not maintained, for one. So it doespn't support newer Unicode versions (the readme says it's from january 2018)
6:59:47
aeth
beach: and in cl-unicode I think the closest equivalent is (eql (nth-value 1 (cl-unicode:general-category character)) (intern (symbol-name category) :cl-unicode-names))
7:00:03
loke
Also, it lacks a bunch of things, such as implementation of the the BIDI algorithm, and the word break stuff.
7:02:31
loke
That's not to say that SB-UNICODE is perfect. For example, SB-UNICODE:GRAPHEMES returns a list of the graphemes. It would be better to have some kind of iterator, or at least return a vector since it causes a lot of consing when working large strings.
7:02:57
beach
Correct me if I'm wrong, but this sounds like an excellent candidate for an implementation-independent library.
7:03:12
loke
In particular, when using it to do word-wrapping, you usually only want all the graphiemes leading up to the first newline, while the SB-UNICODE implementation will create a list out of all of them before you have a chance to search for a newline.
7:04:44
aeth
loke: oh, I see one of the core problems with sb-unicode:graphemes. It doesn't have a start/end, like most sequence/string-processing functions. If it did, you could (position #\Newline string) to get what you wanted.
7:05:04
aeth
Perhaps the author assumed you'd SUBSEQ, but that's just now how CL idiomatically does such things
7:06:14
loke
For word-wrapping you need a different algorithm, which SB-UNICODE implements in SB-UNICODE:LINES. This is also something missing from CL-UNICODE.
7:07:43
loke
But... To dig even deeper. SB-UNICODE:LINES is, again, limited to fixed-width grapheme clusters. For variable width, youy need to be able to provide a custom line width computation which I don't believe is implemented.
7:08:08
aeth
loke: Personally I'd start with sb-unicode, but I'm not sure which would be better: a portable library or porting sb-unicode to all of the implementations, to then expose in a library. I guess it depends on how sb-unicode works and how large its database is.
7:08:53
loke
aeth: I don't think SB-UNICODE has much paltform-specific stuff at all. I think it's mostly the assumptions of the behaviour of the CHARACTER datatype.
7:09:05
beach
loke: Good. I'll thing about ways that this could be done. Not by me, but by someone else.
7:09:22
loke
But if your CL implementation doesn't impleemnt CHARACTER as a single Unicode codepoint, a lot of CL libraries is going to fail on you anyway.
7:10:12
beach
ACTION needs to vanish for around 2 hours or so, and will read the logs upon returning.
7:10:36
aeth
SBCL is essentially the universal donor to any other implementation, assuming that it's portable enough
7:12:42
aeth
fwiw, I've very recently started doing #+sb-unicode instead of #+sbcl for unicode stuff (with an often-subpar fallback, of course)
7:13:19
aeth
code written in this way (instead of #+sbcl) should essentially have all of the sb-unicode extras "for free" for a portable sb-unicode