freenode/#lisp - IRC Chatlog
Search
23:30:18
mfiano
Here is a flamegraph view of one draw call for example. Look at that that time spent: https://i.lisp.cl/JmiUBd.png
23:38:26
mfiano
Xach: curious, I recall recently you did some image thing with an octree. Did you write the octree yourself, or use some library?
1:03:21
moon-child
is there a version of mapcar which errors if the lists it applies to aren't the same length?
1:19:12
no-defun-allowed
You iterate over all the lists, then instead of terminating when one is '(), you check if all are '(), and if not, then you signal an error.
1:20:26
aeth
Fortunately, at least one log bot was on the "correct" side of the netsplit for anyone else who was confused
1:20:43
aeth
The rest of us were wondering what these answers had to do with the package system. :-)
1:21:49
aeth
frodef: There are some low-hanging fruits in package features, including hierarchical and versioned, although you can sort of fake the former with reexporting symbols and you can definitely do the latter manually (although only Alexandria does this afaik).
1:22:05
aeth
frodef: But the solutions would be controversial so it would take a lot to get anything.
1:23:08
frodef
aeth: The problem with CL is, it was so good back in 1990 that it's still "good enough" :-)
1:27:41
aeth
frodef: No, it's more like... how many > 100 kloc projects are there written in CL that aren't CL compilers?
1:28:22
aeth
And compilers can just add whatever internals they want, so they're not really having to deal with mostly-portable CL.
1:29:33
frodef
aeth: I tend to disagree, I suspect the lack of a global "module" system/architecture is holding CL back.
1:30:24
no-defun-allowed
How do you handle having version X for one package, and version Y for another?
1:31:31
no-defun-allowed
You might put versions in the package "names" or something, so they don't collide. But then would FIND-SYMBOL take a versioned name? These things seem hard with packages as bundles of sybmols.
1:32:13
aeth
The new version just inherits from the old one for the most part. Sometimes removing, but mostly adding.
1:32:39
no-defun-allowed
I think first class global environments, specifically sticking each module in a FCGE with its dependencies, is a good idea, but then you have edge cases like one module returning a FOO:B that's different to another module removing FOO:B, cause they came from different package objects.
1:33:24
no-defun-allowed
So you might want to have package objects collude to not create duplicate symbol objects somehow, I dunno.
1:34:25
aeth
no-defun-allowed: Versioned packages are way simpler than FCGE, though. Essentially you want to inherit symbols in a new package from an old one (several libraries do this, including UIOP and defpackage-plus afaik)
1:34:38
White_Flame
PLN would allow you to have package foo-3.5: and package foo-3.6: simultaneously, but I think those canonical package versions are better handled in the .asd file than scattered around the source's defpackages & imports
1:34:48
no-defun-allowed
Gnuxie tells me that in Self and Newspeak, module imports are just assignments to slots, so you can provide whatever objects you want. But packages, querying the environment for packages, and all that introspective stuff makes it harder.
1:35:15
aeth
no-defun-allowed: Except, sometimes, you want to do one of three things: (1) remove a symbol (something deprecated got removed from the API), (2) add a symbol (by far the most common and totally safe), (3) replace a symbol (because foo.1:barfoo and foo.2:barfoo have two different implementations so they refer to two different functions)
1:35:38
no-defun-allowed
Yeah, that much could be done with diffs. That'd handle deduping symbol objects across package versions.
1:37:12
aeth
To complicate things a bit, you'd want one of the symbol conflict resolution options to be "don't use the latest, use this specific version instead"
1:37:43
aeth
So if you USE my-package and it stops working because of a symbol conflict (and, yeah, USE is bad in general), then you can just use my-package.2 or whatever.
1:41:58
fiddlerwoaroof
Personally, I tend to distinguish "code that I might eventually put into quicklisp" from "application code"
1:42:17
fiddlerwoaroof
And only use implementation-specific features in the latter sorts of projects
3:35:07
mfiano
https://common-lisp.net/project/asdf/asdf/The-package_002dinferred_002dsystem-extension.html
6:13:09
beach
frodef: See http://metamodular.com/SICL/environments.pdf for a description of first-class global environments.
6:13:14
troydm
okey this might sound like a dumb question but it seems that there are two local-projects directories when using roswell
6:20:15
troydm
it seems like top level local-projects directory is not part of ql:*local-project-directories*
6:26:27
troydm
or rather roswell adds ~/.roswell/local-projects to ASDF registry but not ql:*local-project-directories*
6:32:34
troydm
moon-child: I do use slime, but sometimes I start repl just to quickly check something
6:53:06
fiddlerwoaroof
Tab complete for symbols and M-i for documenting the current symbol is pretty handy
6:54:15
fiddlerwoaroof
As for "why": I occasionally use lisp on servers where I don't have emacs installed
6:54:52
fiddlerwoaroof
And, if I'm already doing stuff at the shell, sometimes it's easier just to use the REPL in the context of my current session rather than context-switching into emacs
7:01:22
no-defun-allowed
Although a touch convoluted, you could start SWANK on the server, then use SSH to port forward and M-x slime-connect to that.
10:05:43
sauvin
in sbcl, I'm suddenly getting hit with an "undefined variable" error or warning when I try (setq a '(1 2 3 4 5)). What could be wrong?
10:06:35
phoe
define your variables before setting them - globals via DEFVAR or DEFPARAMETER, locals via LET or LET* or the other utilities for binding
10:07:25
sauvin
Yeah, well, folks in this channel about 24 hours ago told me about that, which is why I'm asking. Worked in gcl, ain't working in sbcl, wtf!?
10:10:02
phoe
it's a good thing on one hand, and on the other, it has caused a fair share of breakages in libraries that were working before but then SBCL found ANSI CL conformance bugs in them
10:11:40
sauvin
Well, see, this was one of the reasons the folks here gave yesterday for me to move to sbcl: more conformant to the standard.
10:13:12
phoe
the question with SETQ on symbols always is: where is this particular symbol defined to be a variable?
10:13:37
beach
sauvin: It's kind of the other way around. It "works" in SBCL, since it signals a warning, and it does not "work" in GCL because it lets a detectable undefined situation pass silently.
10:17:34
sauvin
Because I don't understand it. I'm just now learning how to assign variables in lisp, and it's a lot more complex than in perl, and it's more complex than in the AutoLISP that I used to use heavily but haven't seen in twenty years.
10:18:12
no-defun-allowed
You are going to understand it even less, if you attempt to intentionally break it.
10:18:30
sauvin
So, anyway, let works at the top level. I'm a big fan of lexical variables anyway. I avoid globals wherever I can.
10:18:41
beach
sauvin: How is (setq <variable> <value-form>) more complex than <variable> = <value-form>?
10:19:39
no-defun-allowed
You are not breaking anything with LET. You're also not really breaking things with SETQ on undefined variables on its own, but attempting to dispose of the warnings your implementation makes for using SETQ in that way is breaking it.
10:19:59
no-defun-allowed
my $thing = ... would be like wrapping the rest of the body in (let ((thing ...)) ...)
10:20:20
phoe
declaring local variables in Lisp is done via LET and LET* and some other similar operators
10:21:16
no-defun-allowed
However, note that DEFVAR and DEFPARAMETER are always used to declare special variables, which are dynamically scoped. I think Perl is another one of the few languages with dynamically scoped variables.
10:22:03
no-defun-allowed
Yes, DEFUN, DEFPARAMETER and DEFVAR usually don't do what you want them to do, if you put them inside a function body.
10:22:08
sauvin
perl DOES have dynamically scoped variables, but there are very few circumstances under which their use encouraged.
10:22:49
no-defun-allowed
That is not so far off in Lisp; you use lexically scoped variables by default, but dynamic scoping is useful for cross-cutting "customization" of things.
10:23:21
sauvin
Yes, and i perl, I'd have to have some pretty convincing reason to use 'local', which means 'dynamic'.
10:24:39
sauvin
I'll look at that later. For now, many years spent swearing at the machine (and destroying more than one keyboard in the process), I tend to disfavour global variables. I just wind up tripping over them.
10:25:02
no-defun-allowed
For example, you can re-bind *standard-output* to send printed text somewhere else (provided it is printed to *standard-output*).
10:26:28
sauvin
Had to do that already. *default-external-format* defaults to utf-8, but trying to read a couple of files I have caused sbcl to puke, so I had to change that variable to ISO-mumble.
10:27:10
no-defun-allowed
But I use a fair few global variables in my work, mostly to put weak hash tables somewhere, so that I can de-duplicate objects I use.
10:27:28
phoe
and use dynamic variables either for passing context information along your call stack, and almost only for that.
10:28:28
sauvin
I tend to prefer passing parameters. Dynamic variables (in my other-language experience) are just another morass.
10:29:35
phoe
(with-output-to-string (*standard-output*) ...) hijacks the output stream and returns everything that was printed as a string
10:30:24
phoe
(let ((*package* (find-package :keyword))) (prin1 x)) prints X with all symbols being fully qualified, so with all package prefixes
10:30:53
phoe
it can contain functions which call functions which call functions which print to standard output
10:31:16
phoe
and, no, they aren't printing to standard output anymore; they're printing into the stream that collects stuff into a string
10:32:55
phoe
(defun foo () (princ :asdf)) (with-output-to-string (*standard-output*) (princ :qwer) (foo) (princ :zxcv))
10:32:56
no-defun-allowed
I am aware that Haskell (or GHC maybe, who can tell the difference) has dynamic binding, so they're not totally useless.