jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/> | News: ELS'22 this Monday (2022-03-21), see https://european-lisp-symposium.org
antonv has quit [Ping timeout: 252 seconds]
beach` has joined #commonlisp
beach has quit [Ping timeout: 258 seconds]
Alfr has quit [Quit: Leaving]
saura has quit [Ping timeout: 276 seconds]
ec_ has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 258 seconds]
Lord_of_Life_ is now known as Lord_of_Life
X-Scale` has joined #commonlisp
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
<char[m]> Is there a way to have the initial-value form of a deparameter not be evaluated until runtime?
ttree has quit [Quit: Leaving]
ttree has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
<pjb> char[m]: this is the case. try (macroexpand-1 '(defparameter *foo* (+ 1 2))) to verify.
Alfr has joined #commonlisp
<pjb> char[m]: now, strictly speaking, it's evaluated while loading the fasl file (or the lisp source file), so this is not exactly run-time. But to make it evaluated at run-time, you would have to put the defparameter form in a non-toplevel place, which would defeat it.
<pjb> char[m]: ie. if you want stricly what you wrote, then use defvar and setf: (defvar *foo*) (defun main () (setf *foo* (+ 1 2))) (main)
jmes has quit [Remote host closed the connection]
saura has joined #commonlisp
<char[m]> pjb: a was afraid that would be the answer. Why doesn't eval-when work for this?
<pjb> char[m]: what do you mean. As I said, this is already the case.
<pjb> Try it! (defparameter *foo* (print 'hi)) (compile-file "foo.lisp") and no print. (load "foo.fasl") and it will print HI
<pjb> char[m]: otherwise, if you mean strict run-time, then use defvar and setf. It should be obvious.
<pjb> You cannot expect operators to do things they're not designed to do.
<char[m]> It runs when I use assf:program-op. I guess that is because it has to load it into the core.
jolby has quit [Quit: Client closed]
<pjb> char[m]: ok, if that's a problem, then indeed, you will need defvar+setf in an initialization function in main.
<pjb> char[m]: this is typical, when you want to allocate foreign resources in the initialization form.
Bike has joined #commonlisp
saura has quit [Ping timeout: 256 seconds]
waleee has quit [Ping timeout: 260 seconds]
bilegeek has joined #commonlisp
saura has joined #commonlisp
beach` is now known as beach
<beach> Good morning everyone!
hide-difference has joined #commonlisp
ns12 has quit [Quit: bye]
ns12 has joined #commonlisp
<mason> beach: o/
akoana is now known as Erroneous
Erroneous is now known as akoana
asarch has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
asarch has quit [Quit: Leaving]
saura has quit [Ping timeout: 258 seconds]
ec_ has quit [Ping timeout: 240 seconds]
karlosz has joined #commonlisp
hayblender has joined #commonlisp
karlosz has quit [Ping timeout: 276 seconds]
Bike has quit [Quit: Connection closed]
rainthree has joined #commonlisp
pranavats has joined #commonlisp
<hayblender> Does anyone have suggestions for docs/books/blogs/etc re: building software in dynamic langs (lisp in particular)? I've only been able to find Peter Norvig's slides for "design patterns in dynamic languages" thus far.
akoana has quit [Quit: leaving]
hide-difference has quit [Ping timeout: 252 seconds]
<beach> hayblender: I am not sure sure there are many techniques that apply to all dynamic languages.
<beach> Besides, there are not many dynamic languages around.
<beach> For Common Lisp, there are several good books like PCL, PAIP, etc.
perr_ has quit [Ping timeout: 240 seconds]
<beach> minion: Please tell hayblender about PCL.
<minion> hayblender: have a look at PCL: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<beach> minion: Please tell hayblender about PAIP.
<minion> hayblender: PAIP: Paradigms of Artificial Intelligence Programming. More about Common Lisp than Artificial Intelligence. Now freely available at https://github.com/norvig/paip-lisp
<beach> The latter mentions AI, but it's just a good programming book.
<beach> hayblender: If you can be more precise about what you are looking for, maybe we can give you more specific answers.
<hayblender> Thanks for those recommendations!
<beach> Pleasure.
<hayblender> So, I should admit that what I'm looking for is a bit vague at the moment, even to me
<beach> I fully understand.
<hayblender> I'm coming from a Java background (~7yrs). There are many books on design patterns which describe relationships either in terms of types of behaviour (as part of a type, of course)
<beach> Also, I took "dynamic language" to mean what we usually mean by it, i.e., a language with semantics defined as a sequence of interactions in an executing image.
<beach> ... as opposed to, say, a "dynamically typed" language.
perr_ has joined #commonlisp
<hayblender> The strucutre of progammes relies a lot on types to guide what is and isn't possible. When compile time checking of types isn't part of the usual workflow (ignoring type hints for the moment) I guess the programmer needs other principles/patterns for controlling complexity
<beach> I see, so you were talking about dynamic typing, as opposed to something else?
<hayblender> Typed programming is so popular right now that I feel there's a lost or hidden are of software construction that works differently to this. But I don't know how to access it!
<hayblender> Yes, apologies for that - dynamic as opposed to static typing
causal has quit [Quit: WeeChat 3.5]
<beach> For structuring code, a good technique is to use a "protocol" which is a generalization of an "interface" and which is a collection of types (usually classes) and functions (usually generic functions). Such protocols have documented semantics that can (but doesn't have to) be verified at run time.
<beach> hayblender: Are you from down under?
<hayblender> I'll check out protocols, thanks for that.
<hayblender> Yes, from Sydney
<beach> Heh.
perr_ has quit [Ping timeout: 258 seconds]
perr_ has joined #commonlisp
<beach> I guessed that from "programmes" and "different to". :)
* beach is getting good at dialects; even written ones apparently.
<beach> hayblender: Anyway, I take it you are new here, so welcome to #commonlisp.
rotateq has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
<hayblender> Indeed I am, thanks for the welcome!
<hayblender> Here's a dialect test: where is the term "outwith" commonly used?
<beach> So is the plan to actually learn Common Lisp, or just to gather information about dynamic typing?
<beach> Never heard that one.
<hayblender> The latter, learning Common Lisp.
<beach> Great!
<hayblender> I'm one of those people that over-analyse things to begin with so I'm currently in the "information collection" phase (which is usually long for me)
<beach> So #commonlisp is not really for newbie questions, but they are tolerated. If you ask too many trivial things too often, you may be asked to go to #clschool.
<beach> That's fine. More general questions are fine here. But we don't really do language comparisons.
<hayblender> "outwith" commonly used in Scottish English as a synonym for "beyond" or "outside this"
<beach> Thanks. I'll try to remember that. I was going to guess either Ireland or Scotland.
<hayblender> Got it, thanks for that background.
<beach> Sure. Good luck with your learning project.
<hayblender> I guess it's there in the channel intro text too, oops :)
<beach> Oh, and #commonlisp is pretty strict with sticking to the topic. But you will receive warnings before anything bad happens to you.
<beach> hayblender: The main thing with Common Lisp is not so much dynamic typing. In the beginning, you can mainly forget about types entirely. Instead, the main difference is that it is "dynamic". Meaning that there is no clear distinction between read time, compile time, and run time.
<beach> You can redefine a class after some instances have been created, and the semantics of that are well defined. And you can add and remove methods at run time, which is fortunate because run-time is what you use when you develop and modify code.
<beach> Common Lisp allows type declarations, but it is a common mistake by people coming from statically typed languages to overuse type declarations.
<beach> And, the Common Lisp language standard allows for Common Lisp implementations to ignore type declarations, so you can't count on them playing the role they do in static languages.
<beach> s/static/statically typed/
<hayblender> beach: to take your usage of "dynamic" - in my mind it evokes an idea of an operator being constantly present to interact with the system. I suppose that this is only really the case during development and when making changes.
<hayblender> When reading things like this I always think to myself "But I won't be there to change the method or remove it!"
<beach> Right. The developer usually has an idea of "execution time" for an application, and the application then typically doesn't really do things like remove methods.
<beach> But since software development in Common Lisp is just a matter of invoking different operators with respect to some executing image, then there is no distinction.
<beach> But some applications may invoke the compiler, for instance, perhaps to create more efficient code. And the system itself silently invokes the compiler in some situations.
<hayblender> I understand what you're saying, but I think there's an experiential element I'm missing here. Probably some experimentation on my end is in order.
<hayblender> I appreciate you taking the time to explain these things!
<beach> Sure, it will become obvious over time.
Cymew has joined #commonlisp
saura has joined #commonlisp
frgo has quit [Ping timeout: 244 seconds]
ttree has quit [Ping timeout: 240 seconds]
rainthree has quit [Ping timeout: 246 seconds]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
attila_lendvai has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
aartaka has quit [Ping timeout: 276 seconds]
MajorBiscuit has joined #commonlisp
bilegeek_ has joined #commonlisp
aartaka has joined #commonlisp
saura has quit [Ping timeout: 258 seconds]
bilegeek has quit [Ping timeout: 255 seconds]
shka has joined #commonlisp
hayblender has quit [Read error: Connection reset by peer]
jmdaemon has quit [Ping timeout: 258 seconds]
aartaka has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
cross has quit [Quit: Lost terminal]
ttree has joined #commonlisp
aartaka has quit [Ping timeout: 276 seconds]
aartaka has joined #commonlisp
kagevf has quit [Ping timeout: 240 seconds]
aartaka has quit [Ping timeout: 255 seconds]
bilegeek has joined #commonlisp
aartaka has joined #commonlisp
bilegeek_ has quit [Ping timeout: 255 seconds]
ttree has quit [Read error: Connection reset by peer]
pve has joined #commonlisp
kagevf has joined #commonlisp
genpaku has quit [Ping timeout: 272 seconds]
antonv has joined #commonlisp
genpaku has joined #commonlisp
rotateq has joined #commonlisp
mal1 is now known as lieven
aartaka has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
<White_Flame> I know they're gone already, but the existence of "design patterns" is an indication that the language does not have sufficient tools of abstraction, and thus aren't really relevant to more flexible languages
<rotateq> Oh, that's a good reason I could give next time it comes up, if I'm allowed. :)
<rotateq> Like with say those Nassi-Shneiderman diagrams for "structured" programming. Not really high level of abstraction possible.
<beach> What about things like we mentioned the other day about conditional caching? As in, define a primary method that computes a value, and an :AROUND method specialized to the root class that checks for cached value and conditionally invokes (CALL-NEXT-METHOD). Could that be considered a kind of design pattern for CLOS?
<jackdaniel> I'd say "yes"; there are numerous design patterns in Common Lisp
<jackdaniel> i.e when writing a macro using with-gensyms and once-only to avoid known pitfalls for not doing that
<rotateq> beach: Maybe it could, but I would see it more as a technique to avoid unnecessary work in the long run. And didn't look really into those patterns yet, which doesn't mean it's not on my list.
<beach> Wait, didn't Norvig write something with a title like "design patterns for highl-level languages" or something similar?
<rotateq> And as you said it's memoization suited for the specific situations.
<rotateq> Yes he did.
<beach> But maybe he mainly wrote that they aren't needed like White_Flame says?
<rotateq> Iirc the result was 16/23 of those patterns are doable in default with CLOS.
<beach> I vaguely remember that part. But did he introduce some others?
<rotateq> I would have to re-read it too.
MajorBiscuit has quit [Ping timeout: 244 seconds]
<jackdaniel> "Design Patterns in Dynamic Languages" - https://norvig.com/design-patterns/design-patterns.pdf
<beach> Thanks!
<jackdaniel> sure
<mfiano> Can I I somehow format a float with ~F to insert comma characters like I can with ~:D, or do I have to split the input into integers with one of the multiple return value division operators?
<mfiano> I see. I would have liked to easily format 1234.5678 as "1,234.57". But, that requires mixing parameters from two different directives, which is not possible.
<pjb> White_Flame: well, IMO design-pattern = macro. So you're right, absence of (usable) macro = insufficient tools of abstraction.
<pjb> (even if some design-patterns include out-of-computer elements and so are quite informal).
<mfiano> Oh design patterns. I better not speak on this topic.
<pjb> (defmacro foo () (if (yes-or-no-p "Should we foo?") `(call-foo) 'nil))
<rotateq> The funny thing is in the main book about it CLOS is mentioned a few times too.
<pjb> You can also include informal, and out-of-the-computer elements in CL macros with I/O :-)
<rotateq> So the person who said to me in beginning of the year "whaat you don't know those? so you can't know about OO" can never really have read it.
<mfiano> Sigh
<mfiano> I'll give in.
<rotateq> mfiano: Sorry, I see padchar for ~F, this is what you want, right?
MajorBiscuit has joined #commonlisp
<White_Flame> pjb: right, it's a pattern because the programmer has to continually reimplement that concept in code over and over again, instead of having the ability to reify it into a utility or library
<pjb> White_Flame: Mac, the programmer ;-)
<mfiano> Design patterns are nothing more than "master programmer advice" of users of deficient object oriented languages, passed down to novice programmers. The main problem with them, is that they are "patterns"; every programmer knows you can't dish out a general solution to every problem, but that each problem requires a solution tailored for that specific problem. Indeed, in CL with a superior
<mfiano> object oriented system, the MOP, and with macros, these are not needed.
<rotateq> White_Flame: There are people who call this "non plus ultra" way of doing stuff.
<rotateq> And a sane and consistent language design from the start. :)
<mfiano> Design patterns sell books. That is all. They are completely pointless even in the deficient languages they are used in, for the reason I mentioned above.
Dynom has joined #commonlisp
<mfiano> Maybe I should have said "every competent programmer", instead of "every programmer".
<White_Flame> "every true scotsman"
<jackdaniel> I don't know, it is hard to abstract away a concept. you either hold a singleton object or not.
<ck_> ScotsmanFlyweightObserver
<pjb> mfiano: perhaps we could collect our macros into books and sell them too?
<mfiano> pjb: Good idea, as long as it doesn't turn out like Let Over Lambda :)
kg7ski has quit [Ping timeout: 276 seconds]
<rotateq> pjb: So much crap books out there. How many Java or Python books alone exist repeating all over and over? (no serious question)
kg7ski has joined #commonlisp
<mfiano> Welcome to the new age of programming: https://img.mfiano.net/TOSYUh.png
treflip has joined #commonlisp
<beach> I remember going in to the bookstore in Lille with a reputation of being the best in the country for science and technology. So I went to the floor labeled just that, but didn't find any computer books. So I asked, and the answer was that they are under "Multimedia". I didn't have the presence of mind to ask why biology books weren't under "Hunting and fishing".
<mfiano> Taxonomy is hard.
<beach> Indeed.
<jackdaniel> we should iterate over this and construct a superior label "Unimedia", as faster and less resource-hungry :)
rodicm has joined #commonlisp
<mfiano> THat would be unimedium :)
<mfiano> Which is both awful and redundant :)
<jackdaniel> multimedia - a set of "multi"-entities
<mfiano> But I like your joke
<jackdaniel> unitmedia -a set of "uni"-entities
<jackdaniel> s/unit/uni/
<jackdaniel> (like a library of manh books, where each focuses on a single aspect)
MajorBiscuit has quit [Ping timeout: 240 seconds]
<mfiano> I'm trying to come up with a name for a module that includes a logging system/protocol, method implementations of the protocol that generate log messages, and a dependent single condition type. The condition type throws a wrench in any good names I can come up with, and these components are all tightly coupled. There is only a single condition because this is not an interactive
<mfiano> application/library; it is designed to be run as a standalone end-user command line application.
<pjb> beach: the difference between a library and a bookstore, is that the bookstore caters to buying customers, while the library may cater to science.
<beach> Right, so "Hunting and fishing" ought to sell more than "Biology".
<pjb> mfiano: so log6 is free. Try (quick-apropos "log")
<pjb> beach: yes. They sort the books in function of what the customers ask.
<mfiano> The worst part about programming for me is architecture, but good architecture is natural for me, it's just that any good architecture makes it very hard to name things, so I'm often left balancing good architecture with good names.
<mfiano> This is my constant battle. I may be alone.
<pjb> When you enter a library the first time, the librarian -teaches-> you how to use the scientifically established index to find the books.
<jackdaniel> I'm naming my variables with letters of alphabet, starting from 'a'
<jackdaniel> when they are all exhausted, I'm adding a second letter, i.e 'aa'
<jackdaniel> and so on
<pjb> jackdaniel: you can do better in lisp, and use digits: \1 \2 \3 …
<mfiano> I appreciate the light humor, but I am serious. I strive to write good software and this always gets in the way.
rainthree has joined #commonlisp
<jackdaniel> meaningful names are important, but fussing too much about them (to the extent of compromising the architecture) may be worse than following my humoruous way of naming variables
<pjb> mfiano: journal seems to be free, as is carnet-de-bord et.
<pjb> c
<rotateq> yeah, symbols can contain good meaningful information to give additional intent
<mfiano> pjb: I have no idea what you are talking about.
<pjb> a log is a journal (en) or carnet de bord (fr).
<pjb> so you can use those names to name a library implementing a log system or protocol.
<pjb> Or you can use more imaginative and indirect names.
<pjb> Or follow the serie and name it log6.
<pjb> I'd use com.mfiano.cl.log or something like that.
<mfiano> a log is also a log. That is not my point. It's when a component is tightly coupled to a module that it shouldn't belong in, but decoupling it makes for worse architecture in subtle ways.
<pjb> Some people dare to call their module after their girlfriends names. Call it Daphnee.
* mfiano gives in and chalks it up to good developer documentation required.
dre has quit [Remote host closed the connection]
<pjb> mfiano: that's why systems, packages or modules names are used as namespaces and in general, not used to qualify the names of the objects inside them.
<pjb> So this question doesn't have to impact a good name you can find for your condition.
<mfiano> I think that is orthogonal to the problem, but okay.
frgo has joined #commonlisp
cage has joined #commonlisp
frgo has quit [Remote host closed the connection]
<mfiano> In other news, if nobody has heard yet, I requested zstd core compression support in SBCL, and it landed the same day. zlib compression support was removed entirely because zstd compresses faster, decompresses faster, and results in significantly smaller core images.
<pjb> Can zstd still unzip my old files?
<mfiano> zstd doesn't "unzip".
MajorBiscuit has joined #commonlisp
frgo has joined #commonlisp
<pjb> mfiano: then why is zlib removed entirely???
<mfiano> I already mentioned.
MajorBiscuit has quit [Ping timeout: 244 seconds]
<pjb> mfiano: you gave some reasons for, but backward compatibility is a big reason against. Why do sbcl maintainers think about?
<mfiano> That's a question for them.
MajorBiscuit has joined #commonlisp
scymtym has quit [Remote host closed the connection]
zachel has quit [Quit: DIsconnected: v7+nano]
zachel has joined #commonlisp
aartaka has quit [Ping timeout: 244 seconds]
Brucio-61 has quit [Quit: Application exit]
MajorBiscuit has quit [Ping timeout: 246 seconds]
aartaka has joined #commonlisp
aartaka has quit [Ping timeout: 258 seconds]
bilegeek_ has joined #commonlisp
bilegeek has quit [Ping timeout: 255 seconds]
bilegeek_ has quit [Client Quit]
<kaskal> I know it is distressing, but I have to create some bindings of a c++ library, what is the best way to go about it richt now in cl? do you have any useful pointers ?
aartaka has joined #commonlisp
random-nick has joined #commonlisp
<kaskal> that looks nice, I'll take a look, apparenty you need libclang but only for generating, so I can compile with intel compiler
aartaka has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
<pjb> kaskal: my advice is to write a C API for the C++ library, and FFI the C API. If for some reason, it's impossible (eg. the C++ API requires creating C++ classes), then use clasp or ecl++. Clasp is a CL implementation designed for C++ FFI. https://github.com/clasp-developers/clasp ecl++ is ecl compiled with a C++ compiler, so you can link C++ and CL code togehter. (eg. c-inline will let you write C++ code to access your API).
aartaka has quit [Ping timeout: 244 seconds]
<contrapunctus> kaskal: what C++ library is this, if you don't mind telling?
aartaka has joined #commonlisp
scymtym has joined #commonlisp
Brucio-61 has joined #commonlisp
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #commonlisp
aartaka has quit [Ping timeout: 244 seconds]
aartaka has joined #commonlisp
<mfiano> Is it possible to have a (SETF NAME)-named method that sets the slot value of a slot, without supplying a value parameter in the lambda list? In this particular case, the value is a boolean obtained by a uiop:run-program process call that would be inside of the method body, so there is nothing to supply except the class to operate on.
<mfiano> I would like a slot with a reader method of the same name, and an external method accessor for setting the value, without actually supplying the value to set in the call to the method.
<semz> I don't think so. Why must it have the name (setf name)? And how would this be used? (setf foo bar baz quux name)?
<mfiano> If not, which seems to be the case after testing, are there any other tools I can use to accomplish this? I have never looked into define-setf-expander and defsetf
<semz> Actually better example of the problem this'd cause: (setf foo bar name baz quux)
<mfiano> I can give an example
<semz> erm, (name x), not name, in both examples
<semz> but you get the point
<semz> But why does it have to be a setf method? What's wrong with e.g. check-connectable?
<semz> afaict this isn't really a place to begin with
<mfiano> Style preference mostly. I use CHECK-* methods for sanity checking, not for actually side-effecting what it is checking.
<mfiano> It is only by convention that SETF-named functions set a place. In this case, there is a place, but not a value. Point being, the value in a SET-named function can be used for other purposes than side-effecting. This is only an alternate name for a function, and doesn't have to set anything at all.
<mfiano> SETF-name*
frgo has quit [Ping timeout: 260 seconds]
hayblender has joined #commonlisp
tyson2 has joined #commonlisp
X-Scale` has joined #commonlisp
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<Shinmera> refresh-connection-state
<Shinmera> literally anything but setf.
<mfiano> I agree now that I thought about it.
aartaka has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
<kaskal> contrapunctus this is a tensor contraction engine https://github.com/cyclops-community/ctf, I do not mind at all, I have hat experience with using ecl and compiling with c++ and so on, this would maybe also work, probably, but it would involve in this case quite a lot of boilerplate I think
MajorBiscuit has joined #commonlisp
<kaskal> pjb I already did something like this, the thing is that I got a little bit scared about ergonomics and such. I have to link also libstdc++ and so on, I ended up doing something like having to push everything under the sun into the cffi:*foreign-libraryy-directories* variable, which is ok I guess using autoconf and so on
<pjb> kaskal: it really depends on the design of the API. When you write a library with an API you want to use in multiple language, it's best to export/publish only functions with simple signature, and avoid types, #define, etc. eg. int count_foos(); int get_foo(int index); void set_foo_bar(int foo_index, int bar_value); etc.
<pjb> Then you can interface with any language without difficulties.
<kaskal> pjb I agree, but scientific computing is full of heartbreaking examples when it comes to APIs... :s
<pjb> Hence the suggestion to write a C API wrapper. Hide the broken hearts behind facades.
<kaskal> 👍 I'll probably do this because is the most portable, and since I just want to use it and not wrap their whole broken API, I can just wrap what I need. I still need to add a whole lot of stuff to the cffi:*foreign-library-directories*, like also libmpi,
<pjb> mfiano: the first parameter of a (setf foo) function is a value. You can ignore it, but when using it: (setf (foo x) value) you need to provide a value. So you probably will want a normal method (defmethod set-foo ((x object)) (setf (slot-value x 'foo) (compute-the-value)))
<pjb> kaskal: or you may link a umbrella library containing all the dependencies.
<Guest74> Does anybody remember who was working on OpenType Fonts?
<kaskal> yes, I'll have to do some experimenting. by the way I also wanted to ask, does cffi also support static libraries in linux ?
<pjb> Guest74: we have logs in /topic
<Guest74> I remember thinking the specification was overly complicated when I skimmed it a long time ago.  But apparently it's just type-1 stuffed inside ttf.
<Guest74> pjb: always the dispenser.
<pjb> kaskal: well, you'd have to statically link your libraries with your lisp kernel. You cannot dlopen a static library. But all the symbols available in the executable are accessible to CFFI without the need for a library reference.
<pjb> kaskal: (cffi:defcfun clock :int) (list (clock) (sleep 2) (clock)) #| --> (19411565 nil 19411835) |#
<pjb> including functions in libc.
<kaskal> yes, I undrestand, I could do easily this with ecl@c++, but I think for sbcl it would be a pain, becausee I'd have to compile sbcl in some supercomputing center somewhere, and sofar I have only had a stress-free experience in that regard with ecl with intel compilers and gcc alike
Th30n has joined #commonlisp
<Guest74> I'll probably have to restructure things so can use all the same mechanisms for PFA PFB CFF CFF2, but hopefully this means we get access to almost all vector font formats soon.
<pjb> kaskal: now, theorically, it would be possible. But in practice it would be a big mess, since you would have to deal with name mangling, which is C++ compiler specific! You could write the same name manging/unmangling in CL, and parse the C++ vtables and other structures to access C++ libraries with CFFI. It would break as soon as a new (or new version of the) C++ compiler is used…
<kaskal> yes, I see. the C wrapping is really the best option, it involves some boilerplate and autotools mockery but it is quite sane. Your insights were very helpful thank you so much
<pjb> kaskal: well, depending again on the C++ library and what you want to do, clasp may be a good solution too. It was developped by Christian Schafmeister for his work on bioinformatics. https://drmeister.wordpress.com/2014/07/
<pjb> He's a chemistry professor who writes software to design molecules.
<scymtym> Guest74: i have done some opentype work
<kaskal> yes I know him, the only thing is that I need gcc and intel compiler, and also some other compilers, and as far as I understand from them they focus only on clang because of libclang
<Guest74> scymtym: Yes, I just saw a video from 2 years ago.  Seems like you're pretty much done.
<kaskal> I don't know if it would be possible to use the intel compiler and clasp, somehow generating bindings or object files with clang and then compiling the c++ code with clang (pjb) maybe if some clasp person is here can clarify this
<scymtym> Guest74: i don't think one can ever be done with otf since they keep adding stuff, but i have a good chunk of the basics covered
<scymtym> Guest74: and yes, they put a binary encoding of type-1 programs into ttf tables
<pjb> kaskal: clasp uses llvm, so I guess it can be compiled with clang https://github.com/clasp-developers/clasp
<rotateq> I still wonder if the kernel of SBCL could be compiled with CompCert, but I'm not experienced with it.
<kaskal> yes, but can it only be compiled with clang? or can I also compile the c++ code with gcc or something? For scientific computing it is quite important to be able to use intel compilers... that would be my problem
<Guest74> scymtym: So when do we get to use it?  Not sure there's anything else to talk about if it's mainly done.
<kaskal> I know them, he never mentions if they only support clang or not, as far as I remember pjb
<pjb> kaskal: there's #clasp
<scymtym> Guest74: i hope to get back to the library soon but i can't make any promises
<pjb> That said, ecl can already be compiled with gcc and with clang, so perhaps it would be easy to port it to icc?
<Guest74> scymtym:  Well, what is it lacking that needs to be done?
<rotateq> Hm or to tcc.
<kaskal> pjb I havee compiled ecl with several versions of icc, out of the box, ecl ROCKS!
<scymtym> Guest74: cleaning up, getting the protocols straight, documentation. the structure is a bit messy at the moment since i originally intended to extend zpb-ttf but that turned out impractical
<Guest74> scymtym: and what did you want to change about randr?Just curious as I think CLX is mainly a dead end.  And just for the record, I never said it mostly didn't work. I said it used to be complete and I uploaded what I managed to recover from a crashed harddrive.  I couldn't verify anything as I was homeless and hoped someone would take a look at
<Guest74> it...8 years ago.  hrm, 8 years ago and homeless again.  This is not a good trend.
<Guest74> scymtym: I guess I  can't help with then if it's getting your head straight :)
kathe has joined #commonlisp
<kathe> hello everyone. :)
<jackdaniel> hey
<kathe> is there any book explaining "expert systems" using common lisp for exposition?
<rotateq> Hi kathe :)
<scymtym> Guest74: sorry to hear that and sorry if i incorrectly characterized the state of the randr extension. the changes i made are mostly 1) separate package for the extension 2) fixes for the unfinished, duplicated or dysfunctional macro stuff 3) completion of some incomplete features
<rotateq> Yes in PAIP by Norvig there is a chapter on that.
<kathe> rotateq: thanks a million. also, is there any book just about expert systems?
aartaka has quit [Ping timeout: 246 seconds]
<rotateq> kathe: Hmm, let me see in my CL folder ...
<Guest74> scymtym: ah, so not really changing it?  I was torn between returning structs or specified lists/values. mainly because I kept thinking clx should be about the protocol and not follow xlibs path.
<rotateq> There is an AI Algorithms book with CL, Java, Prolog.
<beach> kathe: I believe the (old) series of books "the handbook of artificial intelligence" has a volume on expert systems.
<rotateq> kathe: And I have here one "Natural Language Processing in Lisp".
<scymtym> Guest74: there are some changes. the new package alone is a pretty big one which would, for example, affect stumpwm. i also changed some of the structures. i can make a preliminary state available somewhere if you are interested
<beach> kathe: Volume II it seems.
aartaka has joined #commonlisp
<Guest74> scymtym: sure.  While I mainly think clx is a dead end, I don't think X11 is.
<kathe> beach: thanks for that. :)
<beach> Pleasure.
<kathe> dang, vol2 isn't available on amazon. only vol1 and vol3. :(
<Guest74> so I'm still wondering about api presentation.
<kathe> rotateq: i could not find the book you suggested.
<beach> kathe: You can come here and pick it up if you like. :)
<scymtym> Guest74: right. improving clx is a mid-term solution
<rotateq> Okay, but I bet the others contain already enough material to start.
<kathe> beach: sure, thanks. but, alternatively, I could paypal you the shipping.
<kathe> :)
<rotateq> beach: Oh you have some copies around?
<beach> kathe: It is not about the money. It's about the tedious work to wrap it and go to the post office.
<kathe> beach: sorry. didn't mean to offend you.
<beach> Guest74: Perhaps you would be interested in creating an improved CLX? I have logn wanted a more CLOS-y version and with good, documented support for the Xrender extension.
<kathe> thought you were kidding, so i joined in.
<beach> kathe: I am not offended.
<Guest74> scymtym: I keep thinking that when I have some spare time I'll take a good look at the internals again and see what needs to be ripped out to support modern extensions properly.
<beach> rotateq: Yes, I bought the three volumes many decades ago.
<jackdaniel> I'm waiting for someone to pick up the idea of macroexpanding xml protocol definitions from xcb
<rotateq> beach: I've seen on monday CLtL2 for 35€, but still must buy it. ^^
<beach> jackdaniel: That's a good idea!
<Guest74> beach: it's been on my mind. mainly producing a pipeline library for exchanging structured data over sockets and then reusing a lot of the work from clx.
<beach> rotateq: I have 2 copies of that one. And of Keene's book.
<jackdaniel> beach: sure, and it reappears from time to time. I think I've mentioned that on #clim in 2017 or something, then it was independently mentioned by other people; 1M flies can't be wrong as they say
<rotateq> Ohh, Keene would be good to have in print too, this often helps me concentrating.
<beach> jackdaniel: It rings a bell, yes.
hayblender has quit [Ping timeout: 256 seconds]
<jackdaniel> (because, truly, debuggin clx is a fool's errand)
<jackdaniel> debugging*
Bike has joined #commonlisp
<Guest74> beach: the problem is finding a solution to deal with the crap the maintainers came up with to add more extensions. Changing location of length in the protocol, changing the size of the index over the wire depending on the event, adding new events of different sizes with the id's of old events, both of which can be sent, so try and guess which one
<Guest74> you get.   There's lots of conditionals based on data stored in arbitrary locations so how do you create a sane protocol to deal with that?
<kathe> i gotta go. thanks beach and rotateq. :)
kathe has quit [Quit: Leaving]
<Guest74> then there's things like, how do I pass a FD over a socket in Common Lisp?
<beach> Guest74: Yeah, I can imagine.
<jackdaniel> passing file descriptor over the socket? why would you do that over a WIRE protocol
<jackdaniel> or, even, how?
<Guest74> Hey, it's X.
azimut has joined #commonlisp
<jackdaniel> I don't feel enlightened
<Guest74> this was when they realized. Hey, we're on the same desktop, why are we sending images over sockets.  Just mmap some memory, devise a complicated solution to negotiate a fd transfer over the wire, wait for the right moment, and then send the fd over the socket.
<jackdaniel> I'm not aware of such functionality in the x11 protocol
<jackdaniel> sure, the whole "wire" architecture is suboptimal; wayland indeed gives you a handle and lets you work with this context on the "process side", but that's not x11
<Guest74> I'm trying to find kps post on it.
<jackdaniel> and after you send image to x11, then you may reference the pixmap on the server side by id (just like other resources)
<Guest74> maybe it's not pitman, who's the x11 guy I always confuse with kent pitman?
<jackdaniel> keith packard?
<Guest74> the shared memory extension was so that you can update the pixmap by just writing to the data you have in memory.  It was much faster than sending changes over the wire.
<Guest74> that's the one!
<scymtym> as far as i am aware, both x and wayland send file descriptors through sockets. wayland requires this while it is an extension for x, i think
<Nilby> Guest74: same way you pass an fd over a socket in every other language: sendmsg system call, or on some os you can just send an integer because of /proc/<pid>/fd/
<jackdaniel> I see, and it works with posix shared memory?
<scymtym> jackdaniel: at least the wayland one, yes. i assume the x extension is similar
<jackdaniel> interesting, thanks
* scymtym needs to go
<Guest74> the x11 extension uses mitshm
<jackdaniel> OK, thanks for the reference, I'll read it later (I need to go too)
<jackdaniel> cl-trivial-cffi-shmem ;)
Brucio-61 has quit [Ping timeout: 255 seconds]
scymtym has quit [Ping timeout: 272 seconds]
rotateq has quit [Remote host closed the connection]
<phantomics> Hi everyone, a question: does assigning functions to slots in an object have any particular effect on variable scoping inside those functions? I'm having a problem where a locally-assigned dynamic variable inside a function assigned to an object slot expresses its global dynamic value when the function is called
scymtym has joined #commonlisp
<semz> Isn't that normal dynamic variable behavior?
<phantomics> I haven't yet been able to write a minimal reproduction of this bug, so it seems to be caused by a combination of complex factors
<phantomics> semz: The creation and use of the object happens entirely inside the scope where the dynamic variable is given a local value. Before this I wasn't using objects but was instead wrapping the function with the dyn var reference inside a bigger function and I didn't see this problem
Th30n has quit [Quit: bye]
<beach> phantomics: There is no changes to the semantics of a function depending on where it is stored.
Bike has quit [Quit: Connection closed]
Bike has joined #commonlisp
<Bike> yeah, if you're seeing the function use the global value that's because that's the binding in place at the point the function is called.
<beach> phantomics: I suspect your issue is unrelated to where the function is stored. It sounds like the fairly common confusion that special variables can be closed over.
Brucio-61 has joined #commonlisp
<phantomics> Ok, this is a strange one. Something at some point is causing the locally-assigned value to no longer apply
<phantomics> beach: Is there an example of closure over such a variable that wouldn't work? It worked when I was feeding the function to anther function that composed into something more complex
<beach> I am not sure what you mean by a locally-assigned value that doesn't apply. I mean if you do (defun f (...) (setf *var* <mumble>).... *var*) then certainly *var* retains its value.
<beach> phantomics: Special variables can not be closed over.
<beach> phantomics: So (let ((*var* <mumble>)) (lambda (...) *var*)) won't close over *var*.
<beach> So when the function being defined that way is called, it's the binding in place when the function is called that is used, as Bike said.
<phantomics> It's like: (defvar *var* 10) (defun f (...) (let ((*var* (symbol-value '*var*))) (setf *var* 5) (+ *var* 5)))
<Bike> and you're seeing a result other than 10?
<beach> (let ((*var* (symbol-value '*var*))) ...) should be the same as (let ((*var* *vsr*)) ...) no?
<beach> Oops, (let ((*var* *var*)) ...)
WBarends has joined #commonlisp
<Bike> should be, if the variable is actually globally proclaimed special
<beach> Right.
<jdz> Yes, and there's no point looking up the value since the new binding is immediately assigned a new value.
<beach> phantomics: Why did you decide to use SYMBOL-VALUE in one form?
<mfiano> It seems there is some confusion as to what a special variable is.
<beach> jdz: That too.
<phantomics> The symbol-value form was needed in April to fix some bug, I don't recall exactly what the problem was. This code is intended to emulate how April works
<Bike> well, the bug might be relevant, like if the variable isn't actually globally proclaimed special for example
<Bike> unless you're actually seeing that small case failing i suspect the issue is with something specific to the actual code
<beach> Oh, yes, then *var* may very well be a lexical variable.
<phantomics> The value of *var* is intended to by 5 when it gets added to 5, and with this sample code that is what happens. However, in my case something different happens
<phantomics> The variables in this case are globally proclaimed special
<mfiano> And where/how do you actually define that variable globally?
<mfiano> Please don't say with SETQ/SETF
<beach> phantomics: Then I don't see how April, or any other application for that matter, could alter the fact that *var* and (symbol-value '*var*) are equivalent.
<phantomics> The variable in question is part of an April software package and is defined when a package is created
<mfiano> How is it defined?
<mfiano> and in what environment?
<Bike> phantomics has written a compiler into common lisp. i think they know basic aspects of how special variables work. i think they are doing something complicated and weird in service of that compiler that is causing the problem.
<Nilby> phantomics: as you may know, sbcl warns when you put earmuffs on a local var. i'm guessing you're using symbol-value when you don't want to
<jdz> Another possibility is that the *var* in question is a different variable altogether (like not imported from the intended package).
<phantomics> I may have figured this out... local aliasing of dynamic variables is time-dependent
<Bike> what does that mean?
<mfiano> What even does it mean to local alias a dynamic variable?
<Bike> is multithreading involved? because that makes the special variable semantics more complicated.
<phantomics> The new system I'm implementing defers computation until later, it's a lazy evaluation system. If the function is assigned and then called later, that local alias may not apply anymore
<beach> phantomics: What is a "local alias"?
<Bike> that's what i said earlier. the special bindings in effect will be whatever bindings are in place _when the function is called_
<phantomics> (defvar *var* 10) (let ((*var* (symbol-value '*var*))) (setf *var* 5) (+ *var* 5)))
<mfiano> Bike: I think the lack of proper Common Lisp terminology says otherwise. I cannot understand any of this, and my questions have gone unanswered.
<phantomics> That's what I mean by a local alias. Within the (let) scope, *var* has a temporary binding
livoreno has joined #commonlisp
<phantomics> mfiano: then what do you call it?
<beach> phantomics: It will always have a temporary binding, no matter when that LET form is evaluated. So it is not time dependent.
<mfiano> Binding a special variable.
<Bike> it's not really an "alias" given that it's the same name
<mfiano> A special variable is a stack of bindings, simply put.
<beach> phantomics: And if replacing (symbol-value '*var*) by just *var* changes the result, then it is the case that *var* is not proclaimed special.
<phantomics> mfiano: as for the definition and assignment, these variables are listed in a (proclaim (list 'special ...)) form, then they are assigned initial values with (set (intern var-name space-name) value)
<mfiano> beach: Which is why I asked them how and where it is defined.
<phantomics> Right, it's stack of bindings, and using a (let) like that creates a binding that applies within that context
<mfiano> Correct, assuming it is actually special, and that function's body does not call other functions referencing the variable.
<beach> Within that dynamic context, yes, if the variable is special.
cage has quit [Remote host closed the connection]
<beach> phantomics: Seriously, if replacing the SYMBOL-VALUE call changes things, that should be a clue.
waleee has joined #commonlisp
cage has joined #commonlisp
<mfiano> Yes. If you have to use symbol-value, it is not special.
<mfiano> So back up and figure out why that is the case. Your above code would be a no-op for the symbol-value rebinding
<mfiano> If it were truly special.
<phantomics> I'll try removing that and seeing what happens, don't recall what it was introduced to fix.
rainthree has quit [Ping timeout: 248 seconds]
waleee has quit [Ping timeout: 255 seconds]
<mfiano> I'd urge you to put comments in your code, especially for hacks like this that solve a problem. The need to use symbol-value is rare, and it should raise a flag that something needs to be fixed. So comment, and then comment your comments.
waleee has joined #commonlisp
<mfiano> I know this doesn't help you now. I remember helping you solve April problems about a year ago and wished there were more comments.
<scymtym> phantomics: how are the variable names expressed in the PROCLAIM form? the initial values are set via (set (intern …) …) which suggests (but does not strictly imply) that the symbols naming the special variables do not exist before the initial values are set, that is in the PROCLAIM form
<phantomics> I removed it, causes some problems for certain variable bindings. I'll track those down. There are lots of comments in April but some things were put in for reasons I didn't think to comment
<phantomics> scymtym, it's done like this: (PROCLAIM (LIST 'SPECIAL (INTERN "*SYSTEM*" "APRIL-WORKSPACE-TESTSPACE") (INTERN "*BRANCHES*" "APRIL-WORKSPACE-TESTSPACE")))
<phantomics> followed by forms like this: (SET (INTERN "*BRANCHES*" "APRIL-WORKSPACE-TESTSPACE") NIL)
aeth has quit [Quit: Reconnecting]
aeth has joined #commonlisp
<scymtym> phantomics: i see. that doesn't seem problematic per se, maybe unusual
<mfiano> Interning twice is unusual.
ec_ has joined #commonlisp
<phantomics> Would it be better to do: (SET 'APRIL-WORKSPACE-TESTSPACE::*BRANCHES* NIL)
<mfiano> The reader interns a symbol into the current package the first time it is read.
<mfiano> Subsequent reads, or interns, have no effect.
<mfiano> Unless you uninterned it in the meantime.
* semz suspects this is macro output
<phantomics> Best not to explicitly intern at all then? These proclaim and set forms are created by a macro
<phantomics> Correct semz
<scymtym> (setf april-workspace-testspace:*branches* nil) would reduce the likelihood of errors the most since the compiler would then ensure that all spelling of names match and the necessary declarations are in place
<phantomics> Oh, here's why I don't intern them
<phantomics> Before these forms, the macro does (MAKE-PACKAGE "APRIL-WORKSPACE-TESTSPACE")
<phantomics> At the time of macroexpansion, the package doesn't exist yet so I can't do an (intern) within the macro
<mfiano> You can use FIND-SYMBOL in that case.
saura has joined #commonlisp
* Nilby thinks phantomics' code is impressive and well commented.
<mfiano> It sounds like it is more than the last time I saw it
<mfiano> I admit, it's been at least a year since I've helped them fix some bugs
<scymtym> phantomics: assuming the macro outputs more code then you showed, is it possible that some of the forms are not at the top-level and therefore not evaluated in the order we assumed for the simplified examples?
<phantomics> scymtym, here is the full output of the workspace creator: https://dpaste.com/2ZJJWHE2G
<scymtym> phantomics: thanks, looking
<Bike> those proclaims aren't top level, so yeah, that could get hairy.
<Bike> though i guess this could be wrapped in eval-when
<phantomics> mfiano, are you saying I should do: (SET (FIND-SYMBOL "*BRANCHES*" "APRIL-WORKSPACE-TESTSPACE") NIL)
<mfiano> I'm not sure. I don't know enough about the code.
<Bike> using intern is fine.
<phantomics> Bike: is that because the proclaim is inside an (if) and (progn)?
<mfiano> I would recommend you to use declaim at the toplevel. Have your macro expand to a PROGN form
<mfiano> (or proclaim if you need)
<Bike> phantomics: because it's in an if. progn preserves toplevelness. also, proclaim is just a function that has no compile time side effects anyway, declaim is what has those.
livoreno has quit [Ping timeout: 255 seconds]
<phantomics> Ok, I'll see about doing that. I could put the declaim at the top, outside of the (if) form. Whether or not the package already exists there should be no problem with declaiming
<phantomics> So before the declaim I could create the package if it doesn't exist, then do the declaim
<mfiano> You could do (progn (make-package ..) (declaim ..) (if ...))
<scymtym> Bike: but if the problem was (make-workspace "foo") (defun bar () (let ((foo::*system* …)))) within the same file, that should have failed to even READ since the FOO package would not exist after compiling the first form
<Bike> true.
<phantomics> We'll see if this affects the specific problem I had, there's probably something more to it
<mfiano> Good luck!
<Nilby> I find that things like uiop:symbol-call with uninterned or keywords have more utility than I would like.
Cymew has quit [Ping timeout: 246 seconds]
antonv has quit [Quit: Client closed]
<phantomics> Also, here is an example of a strange occurrence I found: https://dpaste.com/DVWXBL8GR
<phantomics> The "left" function prints a value, returning that same value. I have the output of the function printed before and after it's added to an object slot
ec_ has quit [Ping timeout: 240 seconds]
<mfiano> Ignoring the problem for a minute, I would recommend never to use single branch IF expressions. It messes with my brain. Also use NULL instead of NOT here.
<phantomics> In both cases, the returned output is 0, however the printed output becomes 1 after the function is assigned to an object slot
<Guest74> mfiano: I'm still looking for an else clause.
<mfiano> Guest74: Haha I was too
<Bike> is this through the lazy evaluation system, or are you actually doing (funcall function) versus (funcall (slot-value object whatever))
<Bike> because if it's through the lazy evaluation system you should say that
<phantomics> What do you suggest then, (or)?
<Bike> when
<mfiano> WHEN
<phantomics> Bike: the example in the paste is not through the lazy system, it evaluates before the lazy stuff happens
waleee has quit [Quit: WeeChat 3.5]
<Bike> okay. well, i mean, you haven't really provided enough information in this paste to reproduce or even to really understand what happens. how is op-compose called? how is its result called?
szkl has joined #commonlisp
<Bike> the problem is not that the function is being put in an object. the problem is that the dynamic context it's called in changes.
<phantomics> I know there's a lot of missing stuff here, the system at work is immense and I haven't yet been able to write a minimal repro (my attempts don't run into the bug).
<Bike> putting the function in an object may _facilitate_ it being called in a different dynamic environment, but in itself it changes nothing
<phantomics> Bike: that's what I was thinking... the lazy system calls the function later, so it must be getting called in a different environment
<scymtym> something can't be right with the output. i would have to be "0 (:ll 0)" not "(:ll 0) 0" for (print (list :ll (funcall left 0)))
<scymtym> (irregardless of the actual 0, 1 or whatever values)
<phantomics> Good point, the left function doesn't actually contain a print, it references an April macro called (a-out) that does the printing
<scymtym> sorry but the many moving parts make it hard to understand what the observed suspected incorrect behavior is
<phantomics> There's something funny with the timeline, and my understanding of special var bindings is that they're time-dependent, isn't that right? When the end of their context is reached, the value that was placed on the stack is discarded and the value beneath is in use again
<beach> Correct. But I think we have determined that your variables aren't special.
<Bike> time-dependent isn't the word i'd use, but yeah.
<mfiano> I wouldn't say that is time-dependent
<Bike> scymtym is right. there are way too many things happening for us to get a handle on what is happening.
<phantomics> scymtym, I know, appreciate the effort. Like I said, haven't been able to create a minimal repro yet, somewhere in those moving parts is the cause of the problem
<phantomics> It's time-dependent in a way that lexical variables aren't is my understanding. After the program reaches the end of the context, the value on the stack is discarded and invocations referring to it will get the value beneath
<phantomics> I'll make the vars special for real and go from there
<beach> The term is "dynamic extent".
<beach> It is in the glossary.
paul0 has joined #commonlisp
rotateq has joined #commonlisp
ec_ has joined #commonlisp
cage has quit [Remote host closed the connection]
waleee has joined #commonlisp
<mfiano> Am I correct in assuming that, because conditions are not specified to be implemented in terms of standard-object, that I can't specify handler-bind handlers that are all the same generic function whose methods are specialized on a condition type?
ec_ has quit [Ping timeout: 240 seconds]
<mfiano> Ah yes, CONDITION's direct superclass is T, so methods will not do period.
<beach> How does that follow?
<Bike> it's not because they're not standard objects, but rather because condition types aren't specified to be classes.
<semz> You can specialize on structure classes, so you should be able to specialize on conditions as well afaict
<Bike> however, i don't think any actual implementations do not make condition types classes.
<semz> oh
aartaka has quit [Ping timeout: 246 seconds]
<beach> I can't remember now, but I think they kind of have to.
<mfiano> semz: structure-class is derived from standard-object.
<Bike> yeah, there's some kind of funkiness there, but either way i'd say that treating condition types as classes is fine
<mfiano> or more directly, CLASS
santiagopim has joined #commonlisp
frgo has joined #commonlisp
aartaka has joined #commonlisp
kaskal- has joined #commonlisp
<Bike> for specialization, i mean. using make-instance and stuff will be hairier
<beach> Right.
<semz> Oh I see, I checked structure-object by accident
<beach> mfiano: Specializing to a structure class is different from specializing to STRUCTURE-CLASS.
kaskal has quit [Ping timeout: 246 seconds]
<mfiano> Indeed.
<beach> The AMOP uses the preposition "on" for the relation between a method and a generic function, and the preposition "to" for specialization. Just a reminder. I think it would be good to follow that example.
aartaka has quit [Ping timeout: 248 seconds]
frgo has quit [Ping timeout: 248 seconds]
<Nilby> a class browswer works on conditions in every lisp i've tried
anticomputer has quit [Remote host closed the connection]
<mfiano> It works in every known implementation, but one cannot write conforming code by writing for all (current) implementations.
<beach> I need to re-read the standard with respect to conditions to figure out why I concluded that condition types must be classes.
aartaka has joined #commonlisp
<beach> "Condition reporting is mediated through the PRINT-OBJECT method for the condition type in question..." ... "is equivalent to (defmethod print-object ((x c) stream) ...).
<beach> How could that be possible if C is not a class?
<semz> Note however: "Conforming code must observe the following restrictions related to conditions: […] * The :report option of define-condition, not defmethod for print-object, must be used to define a condition reporter."
<beach> It doesn't say: "would have been equivalent to ..., had it been the case that C is a class."
<beach> Ah, good catch.
<jackdaniel> for example number class precedence list does not have "class"
<jackdaniel> "number"
waleee has quit [Ping timeout: 248 seconds]
<beach> jackdaniel: It would be an instance of CLASS, not a subclass of it.
<semz> WSCL? :p
<beach> Yeah.
<beach> semz: Maybe that was my main reason to think they must be classes. I need to read further I guess.
<jackdaniel> wouldn't then condition be an instance of CLASS?
<mfiano> jackdaniel: But CONDITION is not a system class, and NUMBER is.
<jackdaniel> system classc/may/ be of type built-in-class
anticomputer has joined #commonlisp
<jackdaniel> but yeah, it is a class
<beach> jackdaniel: If condition types were classes, then CONDITION would be an instance of (a subclass of) CLASS.
<mfiano> A condition is only a TYPE.
<rotateq> At one point I thought system-class is a standard symbol too.
<beach> Just like NUMBER is an instance of a (subclass of) CLASS.
<beach> rotateq: Now you know.
Dynom has quit [Quit: WeeChat 3.5]
orestarod has joined #commonlisp
<rotateq> beach: Yes but it's not yet completely clear to me.
<beach> rotateq: "system class" just means that the implementation has a choice.
<mfiano> I will admit, I think WSCL needs to clear some of this stuff up: "A hierarchy of condition classes is defined in Common Lisp."
<mfiano> Yet that is the only occurence I can find of conditions being classes.
<beach> Oh! Where?
<mfiano> clhs 9.1
<rotateq> Thanks.
<mfiano> "Conditions are generalized instances of the class condition"
<beach> mfiano: THANK YOU!
<mfiano> But the page for CONDITION doesnot specify if it is a system class or builtin class, only that it is a type.
<semz> http://www.lispworks.com/documentation/HyperSpec/Issues/iss049_w.htm might be of interest too (note that it's only draft status)
<beach> A cleanup is definitely needed.
<Bike> some of the define-condition page is weirdly copied from defclass. for example the slot syntax has :writer, :accessor, and :allocation
<mfiano> Ha
<jackdaniel> probably define-condition predates defclass
<Bike> none of which are actually described in the text
<beach> Yet more clues.
<jackdaniel> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node339.html (the specification still mentions slots, readers and accessors
<jackdaniel> )
<mfiano> This is too muddy for me to make any assessment. Definitely needed for WSCL
<jackdaniel> does it matter for non-mean implementations that try to implement the standard in a way that is meant to break programs?
<semz> How diverse are CLOS implementations in practice anyway? I can see a need for implementation voodoo for stuff like storage-condition, but is there any implementation that-- what jackdaniel asked.
<Bike> i don't think there's any sensible reason to implement condition types not as classes, but that may as well be written down somewhere clearly
waleee has joined #commonlisp
ec_ has joined #commonlisp
<jackdaniel> it is certainly meaningful for language lawyers, but not much for implementors nor programmers I suppose
<mfiano> Well this was enlightening. I definitely learned something anyway, like every dive into the standard :)
<rotateq> mfiano: A big ocean to discover. :)
<jackdaniel> otoh, what is meaningful, is that some implementations (cough sbcl) does not implement condition class as a standard class ,)
<beach> jackdaniel: That's normal.
<mfiano> I think a lot of my issues with the standard, sans these ambiguities, can be fixed by making it a single document. LW and their HyperSpec scatters related pieces of knowledge distant from each other.
<beach> jackdaniel: The instances can still be subclasses of STANDARD-OBJECT.
<mfiano> I might try using dpANS more
<Catie> Isn't the HyperSpec just the ANSI standard broken into individual web pages by section?
<beach> Er, you know what I meant.
<mfiano> More or less, yes
<jackdaniel> beach: the inconveniance is that you can't reliably use make-instance and folks and you are obligated to use make-condition
<beach> Sure.
<beach> Same with structs.
ttree has joined #commonlisp
<jackdaniel> yes, but while I can think of reasons why structs are are not standard classes, I can't think of a reason for conditions to be that way (except maybe for bootstrapping procedure ,)
rainthree has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 246 seconds]
<mfiano> "The metaclass of the class condition is not specified. Names of condition types may be used to specify supertype relationships in define-condition, but the consequences are not specified if an attempt is made to use a condition type as a superclass in a defclass form."
<mfiano> Another mention of conditions being classes, and relevant to this discussion.
<beach> I think it would be better to specify that MAKE-INSTANCE works on instances of CONDITION-CLASS than to insist that CONDITION-CLASS be a subclass of STANDARD-CLASS.
<Bike> definitely some odd bits. like, conditions are sorta immutable maybe. does change-class work? probably not. can you redefine a condition class? probably
<beach> mfiano: Yet more clues. I knew I had accumulated evidence for this idea.
<mfiano> Before I looked into it, I was under the impression that, according to the standard, conditions were not classes at all. Now I know that is clearly not the case, but what kind of class is left a mystery.
tyson2 has quit [Remote host closed the connection]
<mfiano> I guess all that matters for my original question is that they are classes though.
frgo has joined #commonlisp
<mfiano> and not types, as the page for CONDITION specifies.
<mfiano> Well they are types because all clases are types, but you get what I mean.
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
<jackdaniel> sure, you could do that. then you could specify a few things about shared-initialize, reinitialize-instance and half of things specified as part of standard-class
<jackdaniel> that's why I'm saying that subclassing standard-class makes more sense (unless there is a tangible reason to not do that?)
<Catie> I have a vague recollection that it was for historical reasons
<Catie> Hmm, but I can't find what I was thinking of. It very likely was something else then
rodicm has quit [Ping timeout: 258 seconds]
<jackdaniel> either way that ship has sailed in 1994 ,)
Josh_2 has quit [Remote host closed the connection]
Josh_2 has joined #commonlisp
Josh_2 has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 258 seconds]
aartaka has joined #commonlisp
kaskal- has quit [Quit: ZNC - https://znc.in]
kaskal has joined #commonlisp
waleee has quit [Ping timeout: 248 seconds]
<Guest74> Catie: I recall the same thing.  That it was that way in some lisp os or something.
genpaku has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 276 seconds]
waleee has joined #commonlisp
aartaka has joined #commonlisp
genpaku has joined #commonlisp
kaskal has quit [Quit: ZNC - https://znc.in]
kaskal has joined #commonlisp
aartaka has quit [Ping timeout: 248 seconds]
genpaku has quit [Quit: leaving]
aartaka has joined #commonlisp
genpaku has joined #commonlisp
karlosz has joined #commonlisp
kaskal has quit [Ping timeout: 244 seconds]
ns12 has quit [Quit: bye]
ns12 has joined #commonlisp
Guest74 has quit [Quit: Connection closed]
tyson2 has joined #commonlisp
aartaka has quit [Ping timeout: 258 seconds]
jolby has joined #commonlisp
kaskal has joined #commonlisp
aartaka has joined #commonlisp
szkl has quit [Quit: Connection closed for inactivity]
saura has quit [Ping timeout: 276 seconds]
morganw has joined #commonlisp
kpoeck has joined #commonlisp
analogsalad has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
saura has joined #commonlisp
rainthree has quit [Ping timeout: 248 seconds]
treflip has quit [Quit: i slep]
tyson2 has quit [Remote host closed the connection]
kiki_lamb has quit [Remote host closed the connection]
karlosz has quit [Ping timeout: 244 seconds]
analog_salad has joined #commonlisp
analogsalad has quit [Ping timeout: 240 seconds]
analog_salad is now known as analogsalad
analogsalad has quit [Quit: bye]
rodicm has joined #commonlisp
perr_ has quit [Ping timeout: 256 seconds]
kpoeck has quit [Quit: Client closed]
rodicm has quit [Quit: Leaving]
perr_ has joined #commonlisp
ec_ has quit [Ping timeout: 240 seconds]
azimut has quit [Ping timeout: 240 seconds]
kpoeck has joined #commonlisp
rotateq has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
causal has joined #commonlisp
tyson2 has joined #commonlisp
azimut has joined #commonlisp
igemnace has quit [Ping timeout: 258 seconds]
kpoeck has quit [Quit: Client closed]
dra has joined #commonlisp
mrvdb has joined #commonlisp
Guest74 has joined #commonlisp
azimut has quit [Remote host closed the connection]
trokotech has quit [Read error: Connection reset by peer]
azimut has joined #commonlisp
scymtym_ has joined #commonlisp
Brucio-61 has quit [Ping timeout: 255 seconds]
scymtym has quit [Ping timeout: 276 seconds]
Brucio-61 has joined #commonlisp
perr_ has quit [Ping timeout: 244 seconds]
jmdaemon has joined #commonlisp
attila_lendvai has quit [Ping timeout: 246 seconds]
perr_ has joined #commonlisp
dra has quit [Quit: Leaving]
<jasom> Anyone used sbcl for windows under wine recently? It crashes when installing quicklisp for me with 0178:err:seh:call_stack_handlers invalid frame 6A696C37766D6DEE (0000000000032000-0000000000230000)
karlosz has joined #commonlisp
prokhor_ has quit [Remote host closed the connection]
prokhor_ has joined #commonlisp
morganw has quit [Remote host closed the connection]
karlosz has quit [Ping timeout: 258 seconds]
pve has quit [Quit: leaving]
shka has quit [Ping timeout: 248 seconds]
random-nick has quit [Ping timeout: 255 seconds]
ebrasca has joined #commonlisp
orestarod has quit [Ping timeout: 248 seconds]
X-Scale has quit [Ping timeout: 256 seconds]
jolby has quit [Quit: Client closed]
genpaku has quit [Quit: leaving]
X-Scale has joined #commonlisp
bilegeek has joined #commonlisp
igemnace has joined #commonlisp
Jach has quit [Ping timeout: 240 seconds]
dlowe has joined #commonlisp
dre has joined #commonlisp
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
dlowe has quit [Remote host closed the connection]
kaskal- has joined #commonlisp
karlosz has joined #commonlisp
kaskal has quit [Ping timeout: 240 seconds]
cosimone` has quit [Remote host closed the connection]
cosimone` has joined #commonlisp
snits has joined #commonlisp
Oladon has joined #commonlisp