freenode/#lisp - IRC Chatlog
Search
21:01:09
AeroNotix
johnjay: not sure if github still expose that feature where you can filter projects by language and age of commit
21:01:46
beach
makomo: For instance, Martin Simmons is a sponsor of ELS, a regular attendant, a nice guy to have dinner with, etc.
21:03:00
johnjay
the latest 4 minutes ago is rakugobot/shibuyarakugo-parser, a html parser for eurolive.jp
21:06:31
AeroNotix
https://github.com/search?l=&q=language%3A%22Common+Lisp%22&type=Issues haha, could be a useful thing to just spend a few hours hammering through issues here
21:10:48
makomo
beach: it's really nice how a community "feels" different depending on its size. since the lisp community is relatively small, you feel a greater sense of "connectedness" i would say. on the other hand, having a big community has its ups too, like having a bigger ecosystem or similar
21:22:30
AeroNotix
I've come to appreciate :package-inferred-system and every-file-is-a-system organization
21:25:35
Xach
no-defun-allowed: there is one every day in #lisp where distance is no object (although time can be)
21:25:50
no-defun-allowed
*Australia. The closest thing is a "functional programmer meetup" and it's probably just Haskell people jerking each other off and they haven't done anything regular for a year.
21:26:47
johnjay
no-defun-allowed: that sounds like the least attrative haskell meetup i can think of
21:27:48
no-defun-allowed
"Listen to some people talk about type theory" haha yes, that's all FP is. Fuck outta here with first class functions and other stuff, it's all types
21:29:19
no-defun-allowed
Anyways, Lisp isn't fp, blah blah, there's no meetups. There's no meetups in general around here.
21:31:57
aeth
The most important part of Common Lisp depends on what you're doing, and that's the point of Common Lisp imo.
21:32:00
no-defun-allowed
<freenode_aet "#'no-defun-allowed: Common Lisp "> Of course type inference is always good but it's probably a bad idea to bring Lisp in if everyone is talking types.
21:32:40
no-defun-allowed
Once I went into #haskell asking about how to write an article on functional programming and I was attacked for not knowing any Haskell and only Scheme. That wasn't very nice.
21:33:15
no-defun-allowed
Of course type inference is always good but it's probably a bad idea to bring Lisp in if everyone is talking types.
21:35:29
no-defun-allowed
Yes, then ML weirdos use type to prove their programs will run and so forth.
21:36:06
aeth
CL probably has the richest type system of any dynamically typed language and is probably one of the first to support optional gradual typing. The main weakness with respect to types is probably non-generic data structures.
21:36:35
aeth
You could use the type system in CL to do most of what the ML-derived languages do as far as using types for reliability.
21:37:51
aeth
I'd say the main problem is that half of that will only work on SBCL and about 0% of it will work on CLISP (okay, check-type probably works there), with the other implementations somewhere between CLISP and SBCL.
21:38:23
aeth
no-defun-allowed: Yes, the CL type system is superior. For one, you don't need a graduate degree in mathematics.
21:39:01
aeth
And attacking Haskell in particular, CL isn't lazy and doesn't demand immutability in most areas.
21:39:15
no-defun-allowed
(If the Haskell people realise they didn't need their PhDs to write functional programs, they'd be very upset.)
21:41:42
aeth
There are probably places where modern ML-like/Haskell-like languages can do more things with types than CL. I'd like to know those so CL's type system can be extended.
21:41:47
no-defun-allowed
Someone said I should start one then, but I don't know anyone who would go and I've got no money
21:42:06
aeth
The CL way to handle a new paradigm is to glue it to the existing Lisp language and pretend like it was there the whole time.
21:43:02
aeth
If ML-like/Haskell-like languages have something to offer as far as type systems go (and they almost certainly do), extend Lisp and keep the 60 year old tradition going. It worked with OOP.
21:43:57
aeth
(I'm not proposing a new standard. CLOS started out as several non-standard extensions to CL, not as part of the standard. It would probably take 5-10 years for it to be worthy of being standard.)
22:23:34
no-defun-allowed
frankly though, if you force your users to specify variable types without a good reason (it's absolutely not inferable, multiple dispatch exists in your lang) and you're doing static typing nowadays, you did something wrong
22:25:00
aeth
I don't think it's controversial that some languages are hard to learn than others. (Devil's advocate: You only have to learn a language once.)
22:25:31
AeroNotix
aeth: I wasn't being controversial. I was just throwing it out there as a jumping off point
22:26:38
aeth
johnjay: You'll find many name conflicts even with 'aeth'. I like that because in today's world if you use a unique name you'll find far too much too quickly.
22:27:00
AeroNotix
talking about name conflicts, to tag aeth it usually takes me 3-4 times not to tab complete to my self
22:27:08
pjb
aeth: that's wrong. you have to learn some languages each time you use them. For example C++.
22:29:58
aeth
AeroNotix: C++ is a language that's hard to *use*. One could argue that Haskell is a language that's hard to *learn*. But this is getting very off-topic.
22:30:15
AeroNotix
well it ties into the fact that CL is relatively easy to learn and easy to remember
22:30:52
AeroNotix
it all logically seems to fit together, designed flowing together as a cohesive unit
22:31:18
aeth
AeroNotix: There are probably lots of corners of CL that you don't know that you don't know.
22:32:30
AeroNotix
aeth: indeed, I'm absolutely sure of it. The metaobject protocol is something I've literally never used, ever, or even looked into.
22:32:45
aeth
Switching syntaxes quickly is the source of bugs even if you *know* all of the syntaxes thoroughly
22:33:51
johnjay
oh ok. i thought the idea of that post was that scott was just getting old and couldn't concentrate
22:35:05
aeth
I'd say the main problem with C++ is syntax inherited from C. For instance, pointers. People have trouble "learning pointers". Pointers aren't hard to understand if you can understand arrays (imo). C *syntax* for pointers is hard.
22:35:55
AeroNotix
johnjay: his immediate problem is that he has lost interest but the bigger problem is that, despite being a world renowned C++ expert for years (really, his books are great) he cannot easily read C++ and understand immediately what it does.
22:39:31
aeth
AeroNotix: REPL oriented languages like CL seem superior for this sort of thing in general, though. If I want to figure something out in C or C++ or Java, I have to write a skeleton file with all of the necessary boilerplate to get it working. In CL, it usually (but not always) can be done in the REPL.
22:41:05
aeth
(REPLs exist for all of those languages, but it's not going to help for several reasons. One, the language isn't really designed for REPL usage. Two, those are almost always interpreters that might behave differently in strange corner cases. In SBCL, the REPL just compiles it for you.)
22:43:21
aeth
What's great about SBCL is that I can disassemble it and see the generated, commented assembly! (DISASSEMBLE isn't guaranteed to work, and only SBCL comments it afaik.)
22:44:25
aeth
If there are two ways to write something, I sometimes write a foo and a bar with each approach, disassemble them, and see if there's a difference or not.
22:46:25
aeth
Is there a way to disassemble a method? I assume that it's a lambda stored with into an object created by defgeneric, or something close to that.
22:47:02
aeth
I think I've managed to get to the asm via the SLIME inspector before, but that's not ideal.
22:50:03
AeroNotix
When disassemble outputs the addresses of functions/constants, can I use those addresses somewhere to access the object via the pointer rather than the symbol? Always wondered this
22:50:55
aeth
AeroNotix: I don't think you can assume that addresses stay constant because of the GC unless it's an object intended for CFFI, in which case it will probably be at a fixed location to prevent problems on the C side.
22:51:45
aeth
(Although recompiling functions for that probably would be noticable so it probably doesn't happen.)
22:51:48
AeroNotix
If it's comparing constants, I'd assume it could keep those around in specific places
22:52:41
Bike
keywords aren't usually accessed from foreign code, so there's no big reason to specially keep them pinned
22:53:12
aeth
Bike: How do symbols generally work? It's intentionally unspecified, but I wouldn't be surprised if there's a general implementation strategy.
22:54:27
aeth
In my head I sort of treat symbols like global enums. So 'foo is really 'my-package::foo which is really 3456673 or something. And I assume that's resolved at compile time if possible (so (whatever :foo) is really working with a fixnum which I cannot directly access)
22:55:23
White_Flame
or at least, a slot "holding" a symbol should be indistinguishable from "holding" any boxed object
22:55:53
White_Flame
the only special handling that constrains symbols is the symbol-cons equivalence of NIL
22:56:05
aeth
White_Flame: so it's just a pointer to an address and usually the address is all that matters because you're mostly using it for EQ?
22:56:06
AeroNotix
aeth: strangely that's kind of how atoms work in Erlang (which keywords are analogous to)
22:56:34
Bike
aeth: occasionally the data in the pointer, such as pointers to the symbol-name, is useful
22:57:33
White_Flame
but it's usually a pointer to an object, not necessarily a pointer to an address
22:58:01
White_Flame
or are you asking about symbol-value bindings and how those are looked up, rather than the symbol object itself?
23:13:50
jasom
aeth: The way they are usually implemented is that :foo will be resolved to a pointer, but every time you have :foo appear in your code it gets resolved to the *same* pointer, so you can compare just by checking if the pointers are equal (no need to dereference them).
23:15:04
White_Flame
and if GC moves the :FOO symbol object on the heap, all pointers referring to it will be updated during stop-the-world
23:15:07
jasom
Bike: there are reasons to resolve symbols to an index in a table rather than a pointer, and it involves moving GC and hash-tables.
23:16:58
White_Flame
are the issues with symbols + GC + hashtables any different than normal objects + GC + hashtables? Presuambly you're talking about EQ hashtables
23:19:35
jasom
an eql hashtable that isn't indexed by a symbol or a number would be rare (maybe character?)
23:21:31
White_Flame
composite + interning -> eql hash table; composite -> equalp hash table I guess
23:22:44
jasom
right, and symbols are the most commonly interned object, so it might make sense to optimize the case of symbol hash tables.
23:23:25
White_Flame
maybe "interning" might be the wrong word here, but given (1 30 :foo), canonicalizing that to a specific EQ-able instance of that list, using that as a key
23:23:28
jasom
if you hash other composite objects like an equalp hash table, then your implementation is still correct, and you don't need to do any rehashing on GC
23:24:26
White_Flame
the one weakness I often hit is the lack of a caching structure for the hash of a composite
23:25:42
White_Flame
so all of this drives me towards implementing my own application-specific key & hashtable implementations :-P
0:08:54
cobax
Why is Lisp image-based? Why did it start this trend? What was this feature trying to solve?
0:14:19
aeth
cobax: Faster development time. There are other ways, but they came much later afaik. And most involve an IDE.
0:16:28
jasom
cobax: once you have a dynamic environment and automatic memory management, the idea kind of falls out naturally; I'm not sure if smalltalk or lisp did it first.
0:21:24
cobax
from stack overflow I found this bit, and I wonder if this was part of the motivation:
0:21:26
cobax
"There were at one time Prolog systems that saved "working memory" as disk images. It used to be common practice, especially when the OS system calls didn't do a good job with compression and memory-management of special data structures, which is why LISP and Smalltalk did it too."
0:24:58
cobax
Also, where can I read about what entails an "image" and how it is usually implemented, and a minimalist implementation of a lisp-with-image, for example?
0:25:03
jasom
cobax: old applications would do something similar; a document was actually just a memory dump of the data structures the application used.
0:25:21
cobax
I have Queinnec's book and many others but Queinnec doesn't touch on the image-based aspect of Lisp and it is otherwise very rarely discussed
0:25:55
aeth
Recompiling a graphical application while it is running and immediately seeing the changes is a magical thing. (Except, of course, that doesn't always work even in CL. Changes won't always be reflected. It depends somewhat on the architecture.)
0:25:57
jasom
cobax: usually there is a header and some metadata on top; most implementations also support some way of specifying functions to call upon startup too.
0:25:58
cobax
jasom: that is interesting, I wonder what best ways they found to keep the heap, in order to facilitate its serialization
0:26:28
jasom
cobax: if a compacting GC of some sort is used, you run that first and then the whole world is in contiguous memory
0:27:13
cobax
jasom: that makes sense to me, but I am still looking for some papers or hard reading. for instance, it's a bit magical that lambdas can be serialized, among other things
0:28:05
cobax
or does Lisp achieve ease-of-persistence because code is data? and so when it serializes the heap it's just plain old lisp code?
0:28:21
cobax
I have so many books on lisp compilers, they never cover this part, and it's fascinating
0:29:56
cobax
AeroNotix: I have all of Nils Holm's books, I have many old books on old Lisps, and many of the new ones such as "Interpreting Lisp" by Knott
0:31:19
cobax
so if anyone can point me to some good reading on image-based language implementation I'd appreciate it
0:33:32
no-defun-allowed
You are at a dead end of a dirt road. The road goes to the east. In the distance you can see that it will eventually fork off.
0:33:46
no-defun-allowed
The trees here are very tall royal palms, and they are spaced equidistant from each other. There is a shovel here.
0:39:45
no-defun-allowed
anyways, how could you write a long string with lots of embedded #"s in them?
1:42:12
White_Flame
cobax: it's always fun to read old Lisp machine manuals, you can get a sense of the scope of the utilities they had
1:45:20
johnjay
AeroNotix: ah ok. when the world renowned expert in X doesn't understand X that well
2:20:49
no-defun-allowed
(the hypothetical fight is an important question cause obviously whoever would win in a fight knows more about lisp and the two are correlated)
2:20:50
aeth
no-defun-allowed: I'd personally say the HyperSpec and anything covered by a de facto standard portability library (MOP, bordeaux-threads, CFFI, etc.)
2:25:03
no-defun-allowed
still of course xahlee knows everything about lisp and emacs and we must follow his intellectual thought
2:30:04
no-defun-allowed
for a while i thought emma-__ (mod of /r/emacs) and another emma (devout vim user) were the same person
2:44:13
AeroNotix
johnnymacs: a y combinator is a way to implement recursion using anonymous functions
2:47:05
johnnymacs
I do not know if in a non lazy langauge it will stack overflow. I also do not know if it has a clause for termination.
2:48:09
AeroNotix
johnnymacs: you're in #lisp, which is for Common Lisp. Common Lisp isn't (by default) lazy.
2:48:30
AeroNotix
secondly, the clause for termination is up to the functions being passed to and initially called by, the y-combinator.
2:49:07
johnnymacs
As long as there possibly is a clause for termination this answers my second question. My first question remains unanswered.
2:49:32
jcowan
When using symbols at run time, rather than to hold the values of globals, is it normal to use the symbol-value and symbol-function slots for anything?
2:50:10
johnnymacs
Are you saying that because common lisp does not require this that the y combinator will stack overflow?
2:50:35
johnnymacs
So the y combinator will only overflow if the function passed to it will cause an overflow.
2:50:39
AeroNotix
I am saying to write portable Common Lisp you cannot expect a program which requires TCO to work properly, to work properly.
2:51:20
jcowan
johnnymacs: But if you go over to the Scheme side of the Force, you don't have that problem. -)
2:51:45
White_Flame
if you look at the docs of your implementation, particularly around optimization declarations, you should see if they can enable it or not
2:52:31
White_Flame
if it's supported, it's usually at some speed level setting, not necessarily a separate declaration
2:52:32
AeroNotix
I really hate answers like this tbh. I wish we could all just agree that SBCL is the shiznit and all to use that
2:53:46
jcowan
I can understand not supporting it in a particular implementation, but why would support be selective in systems that do support it?
2:53:57
AeroNotix
jcowan: what do you even mean btw? I've been mulling it over since you posted it but I don't get why you mentioned "rather than to hold the values of globals"
2:54:17
AeroNotix
jcowan: I've never understood selective support either. I've brought it up a few times in here
2:54:32
jcowan
iow symbol slots hold the value of defun, defmacro, defparameter, etc, and at run time you can discover those values.
2:54:33
AeroNotix
The standard makes no recommendation either way on TCO, which makes it *even worse*
2:54:59
jcowan
But symbols can also be used as a pure data structure, in which case the p-list helps you associate auxiliary information with each symbol.
2:55:27
jcowan
You also have the symbol-value and the symbol-value slots: is it usual to use them in such applications?
2:56:43
jcowan
AeroNotix: The Java argument not to support it is that people want full stack traces, and stack traces are hard in the presence of TCO
2:57:05
jcowan
otoh, it's not uncommon to have hundreds of lines of stack trace in Java exceptions: who looks at those?
2:58:03
jcowan
If foo is global, then #"foo is (symbol-function 'foo) and foo is (symbol-value foo).
2:58:26
jcowan
But here I am talking about the use of symbols as pure data structures, not as part of the implementation of global variables.
2:59:35
AeroNotix
jcowan: do you mean to fill those slots with garbage only your program understands?
3:00:28
jcowan
Technically the function slot has to be filled with a function, but I don't know if anyone enforces that or not.
3:00:42
White_Flame
the only 3 fully accessible slot from the spec seem to be symbol-function, symbol-plist, and symbol-value
3:01:10
White_Flame
so the macro binding, etc, probably aren't directly available via normal/portable code
3:01:57
jcowan
but I don't know why you say symbol-name (and symbol-package for that matter) are not accessors
3:02:24
Oladon
Anyone have any suggestions for finding something similar to https://bugs.launchpad.net/sbcl/+bug/1654550 in Weblocks, where it's breaking something with the MOP somehow, but I'm not sure what method(s) it's defining that are breaking things? It's not the specific example in the link; that appears to have been fixed (based on grep), but I'm still getting that weird unknown pointer error, and I'm not sure the best way to track down the culp
3:04:00
White_Flame
"accessor" means you can read & write. "function" just means you can call it and it does something & returns something
3:04:59
White_Flame
there's nothing in the spec that requires symbols be objects with slots. It could create an integer per symbol, and have separate arrays for some symbol-* interfaces, and do other thigns with others
3:05:32
jcowan
I'm thinking about writing a symbol-and-package system for Scheme for runtime only. Of course it doesn't have to conform to CL, but I don't want to make it *gratuitously* different.
3:05:34
White_Flame
but yes, most will likely be structs, with some overrides to optimize NIL being both a symbol and sort of a cons cell
3:05:34
AeroNotix
Oladon: a bare sbcl shell doesn't exhibit the same behaviour. There's something missing from that bug report
3:06:10
Oladon
AeroNotix: They fixed that specific bug, but if you quickload weblocks and then try to make-instance something, you'll get the unknown pointer
3:06:28
jcowan
Still, it sounds like I can leave out all the machinery around the value and function slots; if you want those things, put properties on the p-list.
3:06:43
White_Flame
aeth: coming from 6502 home computer land, that was a very common data organization method, as you didn't have easily flexible full 16-bit pointers
3:07:07
Oladon
It looks like they do have an :around method defined on initialize-instance with ((obj composite)) as the first arg... wonder if that'd do it.
3:07:11
White_Flame
right, that's why I said "sort of a cons cell", so CAR/CDR of NIL can easily return NIL without type checks
3:07:16
jcowan
Historically NIL was stored at address 0 as a cons whose car and cdr slots pointed to 0, and punned with a symbol
3:07:53
jcowan
so e.g. the first two slots of a symbol were name and package, say, and then the logic for getting the name and package of NIL was special cased
3:09:00
White_Flame
aeth: btw, symbols probably also allocate an integer offset for themselves for a thread-local binding table, so you're not totally wrong
3:09:03
Oladon
AeroNotix: Nah, but seriously, I like a lot of its ideas, and in theory it should still run...
3:09:30
AeroNotix
Oladon: I'm playing with a few ideas in the repl now but don't expect much, I don't care about weblocks at all.
3:11:22
White_Flame
aeth: in SBCL, accessing a special variable means dereferencing a TLS offset from the symbol structure, reading that entry from the thread-local table, if that's unbound then hit the symbol-value slot of the symbol object itself
3:11:32
AeroNotix
Though, :around :before :after methods, as you suggested sounds like a sound place to start your debugging
3:11:57
Oladon
Yeah, just not sure where to go from there. So they've got an :around method on initialize-instance... now what? :)
3:13:48
Oladon
Eh, this is unlikely to be it... it's on a specific type of weblocks class: https://github.com/skypher/weblocks/blob/master/src/widgets/composite.lisp#L14
3:14:37
AeroNotix
https://github.com/skypher/weblocks/blob/master/src/widgets/composite.lisp#L4 always a good sign
3:16:22
Oladon
Just inspected #'print-object, and it looks like there /is/ a method being defined... but my grepping didn't find it D:
3:38:28
Xach
mfiano: is http://report.quicklisp.org/2018-09-11/failure-report/cl-sdl2-ttf.html#sdl2-ttf the same thing?
3:56:16
AeroNotix
Xach: there's no reason mfiano couldn't have tested all systems in quicklisp with the new release
3:57:45
AeroNotix
jcowan: the yo was just to tag you if you were interested in the outcome of mine and Oladon's pms
4:16:55
no-defun-allowed
https://matrix.org/_matrix/media/v1/download/matrix.org/VcDpibRxlVLRuDDvzEyxBMQO
4:25:17
beach
no-defun-allowed: When I lived in Auckland for a year, there were around 5 lispers within a radius defined by a 3-hour flight. Here in Europe, there are hundreds.
4:35:39
no-defun-allowed
when i lived in melbourne for 17 years, there were around 2 lispers within a radius i didn't really measure
4:47:37
drmeister
Hey - are there any lispers who use 'buildbot'? It's a Python continuous integration system. I just figured it out for building a Clasp CI system. I'm interested in comparing notes.
5:17:47
beach
MAKE-METHOD-LAMBDA says that the METHOD argument may be uninitialized. It doesn't say that about the GENERIC-FUNCTION argument, but it says that it might not be the generic function that the method will be used with, so I don't see what information MAKE-METHOD-LAMBDA could use about that generic function, other than its class.
5:19:15
beach
If I am allowed to pass an uninitialized generic function to MAKE-METHOD-LAMBDA I can solve the problem indicated by Pascal Costanza's article.
5:20:57
beach
For DEFGENERIC, the file compiler can just store the GENERIC-FUNCTION-METHOD-CLASS and the METHOD-CLASS arguments with the name of the generic function in the compile-time environment.
5:38:05
no-defun-allowed
okay bad idea time: it'd be interesting if CONSTANTLY could return multiple values
5:38:32
no-defun-allowed
so basically (defun constantly (&rest values) (lambda (&rest ignored) (multiple-value-list values)))
5:52:31
mfiano
Xach: Seems to be. For some reason library authors think it is good practice to assume transitive dependencies will always be present instead of writing a proper system definition.
5:54:18
mfiano
So that makes all 3 third-party cl-sdl2 addon libraries at fault assuming a dependency specified in cl-sdl2's :depends-on list will always be present. Impressive.
5:54:53
mfiano
Sadly I do not have commit access to repositories outside of the lispgames GitHub organization to fix that one.
5:58:21
mfiano
With cl-sdl2-ttf, it is even worse. It is directly calling trivial-garbage functions itself.
7:49:18
shrdlu68
shka_: Sorry, got disconnected. I haven't tried your btrie yet, but I tried cl-container's trees and the performance was sub-par to hashtable.
8:26:55
shka_
shrdlu68: simply make node with make-bit-trie, then use setf at-bit-trie to populate it
8:59:06
shrdlu68
shka_: Am I doing it right? https://gist.github.com/shrdlu68/6a4e624f3562c2bb81474827bb59edd3