freenode/lisp - IRC Chatlog
Search
9:47:04
pjb
moon-child: structural editors feel like straight jacket. I like the flexibility of emacs, allowing you to work at the character level as well as structurally thru things like paredit. It's a nice compromise IMO.
9:53:30
beach
But yes, now that we can parse the buffer contents incrementally, using the Common Lisp reader, I don't think there is any need for such restrictions.
10:33:38
pjb
if you have automatic editing to do, why not. But otherwise, consider something like sedit.
10:35:25
pjb
paredit approaches it, while leaving the character basis. We could implement a sedit in emacs, purely structural.
12:51:08
nij
Hello! I found that a script "dictionary" I wrote hasn't been working for a while.. but failed to see why's that the case: https://bpa.st/UILA
12:55:18
beach
You don't exactly give the output that would tell us why. But one hint is that ASDF by default converts warnings to errors that will prevent the compilation from finishing properly. You may want to change that default.
12:57:14
nij
Err. whatelse output should I provide? This is the debugging message after I run (ql:quickload :dictionary)
12:58:30
beach
Try putting this in your .sbclrc: (setf asdf:*compile-file-failure-behaviour* :ignore)
13:50:04
beach
phoe: Are you the one in charge of the streaming for ELS? If so, what is the deadline for uploading the talk?
14:01:36
Josh_2
Was wondering if someone could show me an example in real code where they have used it to get a performance increase
14:02:17
lotuseater
Josh_2: this is something which I still don't get ^^ got to know this after reading the Google Common Lisp style guide
14:04:40
Bike
i mean, honestly, there's not much to it. if you make an object and you know it won't escape you can declare it dynamic-extent to hint to the compiler to stack allocate
14:05:01
pjb
the use of the guard cons cell lets you avoid a special case when you have to insert at the before the first element of the list. However, this cons cell is a temporary cons cell that won't be needed once the function returns.
14:05:12
lotuseater
had the thought it could be useful if you loop many times and create each time new data in a DO clause
14:05:24
pjb
Josh_2: therefore it can be declared dynamic-extend and the implementation could allocate it on the stack instead of the heap.
14:06:26
pjb
It's dangerous to write dynamic-extend declarations, because in maintenance, the status of the object could change! It's better to let the compiler determine it itself, without error.
14:08:23
Nilby
I would only use a dynamic-extent declaration where it was demonstrated to make speed critical code faster.
15:24:40
Bike
hm, dunno. it's a bit of an involved question. for a closure the code will be sort of separate from the closure vector, for example
15:25:42
phoe
beach: I am in charge of streaming; I don't know if we have an established deadline, heisig will know that as the programme chair
15:27:32
Bike
i guess you'd do sb-kernel:fun-code-header, and then look at the... there's a "code-size" and a "text-size". couldn't tell you what they are.
15:31:31
nnni
Bike: I am compiling some data into closures. I want to see the differences b/w (data+runtime functions) and closures implementations.
15:32:27
Bike
well, again, closures aren't stored as one thing. if you have multiple closures of the same function, in basically any implementation they'll all share the same code
15:35:26
Bike
generally speaking closures are represented with a simple vector. there will be an entry for each thing closed over.
15:35:58
Nilby
Perhaps a more portable and comprehensive way is to look at (room) differences under controled conditions, e.g. making sure gc is done.
15:36:22
Bike
i don't think i'm explaining this well, sorry. What I mean is that the code - the executable code I mean - is stored separately from the closure data. That's what I meant by the size of the closure versus the size of the function.
15:39:04
Bike
well it sounds like you're not actually interested in the executable size, since that's a fixed cost, unlike the actual closed over data, which every closure instance will have its own copy of
15:39:42
Bike
i'd say the basic guide here is that you can expect (let ((a x) (b y)) (lambda (n) (if n a b))) and (vector a b) to take up rougly the same amount of space, plus the closure has the fixed space of the code
17:07:30
phoe
During this year's ELS, we will be selling prints and hosting an auction of the original of The Y Combinator Codex, a 42cm x 240cm calligraphy piece.
17:07:37
phoe
All proceeds from the auction and print sales made during the two days of ELS (sans printing and shipping costs) will be split evenly and donated to the following organizations, earmarked as money for promotion and development of the respective Lisp languages and their implementations:
17:07:46
phoe
Free Software Foundation (elisp), Clojurists Together (clojure), Common Lisp Foundation (cl), Software Freedom Conservancy (Racket), and ACM SIGPLAN (earmarked as scholarships for the ICFP Scheme Workshop).
17:07:52
phoe
There's photos: https://www.reddit.com/r/LispMemes/comments/l5f4n9/the_y_combinator_codex_but_its_actually/ and a small-res scan: https://cdn.discordapp.com/attachments/532344856731975690/836296248528732170/y-combinator-codex-micro.jpg
19:40:12
pjb
ChoHag: Well, it's not strictly equivalent to scheme RnRS: there's only One CL ANSI Standard to rule them all, One CL ANSI Standard to find them, One CL ANSI Standard to bring them all, and in the darkness bind them. So if you write a conforming CL program in 1996, it will work the same in 2021, and it will work the same in 2046. On the other hand, with scheme, you'd be hard pressed to locate r3rs implementations, and in 2046,
19:40:12
pjb
won't find any working r5rs implementation, so your programs and libraries will be dusk, rotten bits.
19:40:27
pjb
ChoHag: http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html
19:42:01
pjb
ChoHag: said otherwise, my advice is, if you don't plan to finish the program this year, and become a billionaire selling it by next year, if instead you plan to work on your free time for the next few years, perhaps the next few decades, you should better use Common Lisp to avoid having to rewrite it every year (like, eg. swifth programs for iOS that require maintenance only to stay on the AppStore because of new versions of iO
19:43:45
pjb
Great! And this means that you won't have to change the implementation each year, so you can concentrate on making it better. You may also prefer to collaborate with beach on #sicl ?
19:44:41
Xach
I don't think I've ever come across someone unfamiliar with the CL standard who is writing a new language in which to implement CL
19:44:46
ChoHag
I'm not trying to get anyone to change implementations. I want to stop all that sort of shit.
19:47:34
ChoHag
My focus has been mostly on scheme. I've not touched CL for a few years. I want to re-acquaint myself.
19:54:57
pjb
ChoHag: if you write a CL implementation today, it will still be a CL implementation in 20 or 40 years from now. Actually, until the singularity!
19:55:50
pjb
ChoHag: that said, it is allowed to write implementations of a subset of Common Lisp, or superset (extensions) to CL as long as it's clearly documented.
19:56:14
pjb
ChoHag: nothing prevents you to spend the next 40 years improving on your extensions to the CL language in your implementation.
19:59:32
dieggsy
pjb: 'allowed' in what sense? just like, you can still call this CL by the standard's definition ?
20:03:55
pjb
dieggsy: in the sence that as long as the implementation is a conforming CL implementation, a conforming CL program will produce the same results as on any other conforming CL implementation. Ie. the extensions cannot modify the semantics of the base CL language.
20:05:06
pjb
dieggsy: an implementation can easily provide new functionalities in different packages. Eg. clisp provides a ffi in the FFI package, a interface to regex(3) in the REGEXP package, access to screen and keyboard in the SCREEN and KEYBOARD packages, access to LINUX specific operations in the LINUX package, etc.
20:05:47
pjb
dieggsy: furthermore, functions taking &key arguments, may allow additionnal key arguments for extensions. The standard behavior apply when those additionnal key arguments are not provided.
20:06:29
pjb
dieggsy: some extensions in the class hierarchy are possible when mentionned (intermediate classes, or subclasses could be provided). etc. It's all specified in great detail.
20:06:57
pjb
But the important point: to remain a conforming implementation any extension (or subset of the language) must be clearly documented.
20:07:47
pjb
dieggsy: well, it depends. sbcl has its own extensions, but both have problems. The best is to use all the implementations to validate one's conforming code, and to use the implementation best adapted to the deployment case.
20:09:45
pjb
When you want to write portable programs you would avoid those implementation specific extensions anyways, using preferably portability libraries or conforming libraries. Or using #+/#-, you would make use of the extension only when the specific implementation is used.
20:11:24
Nilby
dieggsy: Sadly clisp isn't as neat as it sounds anymore. It has some problems, which likely won't be resolved, and you can have all that in sbcl, and bunch other stuff which make it very fast.
20:12:55
pjb
dieggsy: for example, sbcl lies to you. It says that call-arguments-limit is 4611686018427387903, but when you try to call (apply f l) with a list L containing 100000 elements, it crashes.
20:13:40
dieggsy
when you're applying a function to that many arguments, one might argue it's more an issu of program design?
20:14:10
pjb
clisp has the best encoding support, notably unicode: it knows the name of all the unicode characters. That's not the case with sbcl or ccl they give you useless names such as #\u12345
20:14:48
pjb
All implementations have problem with pathnames: https://github.com/informatimago/check-pathname
20:15:38
pjb
clisp has a report of 72 lines, while sbcl (some old version) had 338 lines of problems!
20:16:40
_death
pjb: I've had trouble compiling it the last time I tried.. some .d compilation errors
20:31:22
jcowan
Call-arguments-limit is mostly important when applying a function rather than invoking one. (apply + list) really be non-portable when the list has more than 50 elements.
20:35:12
_death
since you can query its value, you can use it to portably apply with more than 50 elements on implementations that support it..
20:49:14
jcowan
So how would you write a function to apply an arbitrary number of list elements to an arbitrary (opaque) function?