<dbotton>
has issues but works :) Click builder then new panel and tools properties to play around a bit
lisp123 has quit [Ping timeout: 268 seconds]
<dbotton>
the ability to eval code is off to run the rendered gui
Algernon69 has quit [Remote host closed the connection]
mason0 has joined #commonlisp
Algernon69 has joined #commonlisp
aartaka has joined #commonlisp
Algernon69 has quit [Ping timeout: 240 seconds]
paule32_ has joined #commonlisp
mason0 has quit [Quit: CGI:IRC]
mason0 has joined #commonlisp
<White_Flame>
dbotton: are there layout tools, or all absolute placement/size?
paule32__ has joined #commonlisp
s-liao has joined #commonlisp
Spawns_Carpeting has quit [Quit: WeeChat 3.3]
paule32 has quit [Ping timeout: 260 seconds]
<mfiano>
tools -> properties opens an empty window for me
robin has joined #commonlisp
paule32_ has quit [Ping timeout: 268 seconds]
paule32 has joined #commonlisp
paule32__ has quit [Ping timeout: 240 seconds]
Spawns has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
<dbotton>
They are empty till you place a control
<dbotton>
For now pixel placed
<dbotton>
Ie absolute
<dbotton>
Eventually will build in various layouts
s-liao has quit [Ping timeout: 256 seconds]
<mfiano>
I see, pretty cool, but the input lag is absolutely killing me.
<dbotton>
What is amazing is how quick I was able to put this together and the way I can build it out while it is running. I love lisp
<dbotton>
I took some shortcuts like using borders for handles etc
s-liao has joined #commonlisp
<dbotton>
I now have to figure out round trip code back to gui building as want a Delphi like experience
<dbotton>
Then will get rid of the glitches and kludges
<dbotton>
Also mfiano tool meant to run local is really designed for internet
<dbotton>
Sorry not designed for internet
<dbotton>
Thanks for feedback!!!
<beach>
Good morning everyone!
<beach>
jcowan: We use that clause to determine that conforming code can not observe whether the generic function has been called, so we can avoid calling it in some situations.
s-liao has quit [Quit: Client closed]
lisp123 has joined #commonlisp
<lisp123>
dbotton: Nice work, you are very productive!
<lisp123>
dbotton: Have you considered implementing some of the CLIM GUI paradigms into CLOG? In particular, presentation types where there is a link between the object on screen and an underlying lisp object, both for output to display (which most declarative GUI frameworks do these days) but also for input from user (which I'm not aware of any other GUI platform doing)
semz has quit [Ping timeout: 260 seconds]
semz has joined #commonlisp
Oladon has joined #commonlisp
makomo has quit [Ping timeout: 256 seconds]
lisp123 has quit [Remote host closed the connection]
igemnace has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
lottaquestions has quit [Ping timeout: 240 seconds]
tyson2 has quit [Remote host closed the connection]
igemnace has joined #commonlisp
aeth has quit [Ping timeout: 245 seconds]
s-liao has quit [Quit: Client closed]
aeth has joined #commonlisp
<blihp>
I'm having a problem with package exports not being available in cl-user... is there a way to show what was exported as a sanity check?
<beach>
blihp: What does "not being available" mean?
<blihp>
There is no class named COMMON-LISP-USER::FOO
<beach>
Well, exporting symbols is not enough.
<beach>
You need to type P:FOO if FOO is exported form that other package P.
<beach>
s/form/from/
<blihp>
doh... so what do I need to do to import the exported symbols to cl-user? I tried use-package but it complains about name conflicts for my distinct class/method names.
<beach>
... because you would typically get a lot of conflicts.
<blihp>
any pointers on the correct way to do things are appreciated. I'm trying to use existing quicklisp packages as a guide and it's rough going.
<beach>
Just type the package prefix.
karlosz has joined #commonlisp
<beach>
So what is it that you are doing? You have a package that you defined yourself, and you are exporting some names from it, and now you want to test some functions with names in that package?
<blihp>
so no widely used way to easily import a subset of symbols into another package (i.e. since you're saying import isn't recommended)
<beach>
Yes, there are ways, but those ways are error prone.
<blihp>
I have what is quickly growing into a collection of packages and I mainly would like to be able to import a common set of symbols (i.e. class and method names only, typically) into another package to avoid needing to prefix the names
<beach>
You can always define your own "test" package, and import both the CL package and your own package. Then (IN-PACKAGE #:TEST) will let you type the names without a package prefix.
<beach>
If you want to do that, then :USE in your DEFPACKAGE should work.
<beach>
But I am telling you, it is error prone.
<blihp>
ok, so just don't try to do it in cl-user due to name conflicts
<beach>
It is a much better idea to use package-local nicknames, so that you can type a short package prefix.
<beach>
Then the person reading your code can immediately see from which package the symbol originates.
<beach>
And there is no risk of conflict if more than one of the packages you want to use export symbols with the same name.
<blihp>
fair enough, I'll give your suggestion a shot.
<blihp>
same advice when superclass and subclass reside in different packages?
<blihp>
i.e. getting undefined function SUPERCLASS-PKG::FOO from the subclass
<blihp>
(err, that should have been SUBCLASS-PKG::FOO)
<hayley>
Undefined function?
<blihp>
yes, for a slot reader
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
<beach>
blihp: Classes and functions don't reside in packages. Only symbols do.
<beach>
blihp: You need to refer to the correct symbol.
Oladon has quit [Quit: Leaving.]
<blihp>
OK, now I'm confused. If from cl-user I try to instantiate foo-class I get an error (no class named COMMON-LISP-USER::foo-class) but if I prefix it pkg:foo-class it works. But now you're telling me it's not in the package?
<beach>
Symbols are in packages, and classes have symbols as names, but classes are not themselves related to packages.
<beach>
When you type (MAKE-INSTANCE 'FOO-CLASS) and you are in the CL-USER package, you referring to a symbol FOO-CLASS in the CL-USER package.
<beach>
It could have CL-USER as its home package, or it could be imported from some other package.
<beach>
If it is not imported, then the symbol you are referring to is CL-USER:FOO-CLASS.
<blihp>
ok.. I think I'm following so far
<beach>
But if you were in a different package, say P when you did (DEFCLASS FOO-CLASS...) then the name of the symbol naming the class is P:FOO-CLASS, so you must refer to it if you want to find the class.
<beach>
Similarly, if you are in a package Q when you define a subclass of FOO-CLASS, then you need to type (DEFCLASS SUB (P:FOOL-CLASS) ...)
<blihp>
ah, I hadn't prefixed the superclass name
<beach>
If you type (DEFCLASS SUB (FOO-CLASS) ...), then FOO-CLASS will refer to a symbol in Q.
<beach>
It's all about symbols.
<beach>
You always need to refer to the correct symbol.
<blihp>
ok... my previous work with my own packages was over a decade ago and pretty much everything was in a common package which obviously made life simpler
<beach>
Simpler to create, but a nightmare to maintain if overdone.
<blihp>
in this instance, I know this is quickly going to blow out to a fair number of classes so I'm trying to separate things from the beginning to minimize rework
<blihp>
(i.e. I'm using a fair number of external packages, I'm attempting to create some nicer class wrappers of some of the functionality in my superclass package that I can than use in my subclass package(s))
<blihp>
one of the main ones I'm working with is gtk... *not* a fun framework
attila_lendvai has quit [Ping timeout: 268 seconds]
rain3 has joined #commonlisp
rain3 has quit [Client Quit]
Cymew has joined #commonlisp
shka has joined #commonlisp
<blihp>
so in the superclass I needed to define my accessors along the lines of: :reader superclass-pkg::get-foo ... then things seem to work from an accessor standpoint. This seems rather strange... is there no way (i.e. a global flag perhaps?) to have the accessors default to the package they are defined in or am I doing something backwards?
<beach>
What you are doing is the right way.
<mfiano>
You seem confused about the Lisp Reader
<blihp>
I'm apparently confused by the default behavior as it relates to classes in packages
<beach>
blihp: Classes don't reside in packages.
<mfiano>
A symbol, when it is read for the first time is interned into the current package. Packages, are essentially lookup tables for symbols.
<beach>
blihp: Only symbols do.
<blihp>
beach: sorry for the bad terminology on my part. What I'm referring to is the general grouping of symbols related to the class, including accessor names. I'd expect them all to default to the current package.
<beach>
blihp: You need to change your expectations.
<blihp>
lol... apparently.
<blihp>
however, I would argue that this is kind of missing the point on Lisp's part re: OO (yes, I know it's not really OO in terms of the implementation but I am surprised it isn't faking it better)
<beach>
Common Lisp does not implement "classic" object-orientation.
<mfiano>
class[-centr]ic :)
<beach>
blihp: Traditional object-oriented languages confuse encapsulation and other aspects of object-oriented programming such as inheritance. Common Lisp have separate mechanisms for those. The package system takes care of encapsulation.
<beach>
blihp: That way, you can, for instance, have two slots in a class with names (i.e. symbols) from two different packages.
<mfiano>
and SBCL will finally no longer issue a pointless warning about such
<beach>
blihp: If you currently expect traditional object-orientation from Common Lisp, you truly need to change your expectations.
<beach>
mfiano: Happily, yes.
<mfiano>
I think COmmon Lisp as a whole is very easy to grasp once you understand the phases of compilation, and most particularly the Reader.
<beach>
Yes, the basic mechanisms in Common Lisp are quite simple.
<blihp>
beach: I'm really not... I do understand that, for example, methods aren't actually part of the class as it's just a slot-holder
<mfiano>
Packages and symbols make a whole lot more sense, and this confusion vanishes.
<mfiano>
I think this is where blihp needs to spend more time.
<beach>
blihp: Well, with utterances such as "this is kind of missing the point on Lisp's part", it seems you still expect something that isn't there.
<beach>
blihp: In reality, traditional object-orientation is missing the point, because of this confusion. And that might be why traditional object-orientation is falling out of fashion.
<blihp>
beach: OK, guilty as charged on that front.
anticomputer has quit [Ping timeout: 276 seconds]
attila_lendvai has joined #commonlisp
anticomputer has joined #commonlisp
<beach>
blihp: The problems people seem to have with traditional object-oriented programming are not present in CLOS, and they seem to be largely due to this confusion.
<blihp>
depends on what you mean by 'traditional' OO. I've spent a lot of time in both Smalltalk as well as other interpretations of OO. (i.e. C++/Java/Python/Javascript etc.)
<beach>
Yes, all those confuse encapsulation with other mechanisms.
* mfiano
thinks even languages with methods disassociated from classes, but still have arity overloading miss one of the main points of OOP, completely: protocols.
<beach>
Plus, most of them are restricting generic dispatch so a single argument.
s-liao has joined #commonlisp
<beach>
... which is so prevalent that they even have special syntax for it. Go figure!
<jackdaniel>
there was a very good post written by naggum about oop
<blihp>
Smalltalk has protocols, they've just been neglected and abused to the point of becoming meaningless.
<jackdaniel>
let me see if I can find it
<beach>
blihp: As I recall, Alan Kay largely copied the Simula way but saw object-orientation as being the communication between objects located on different computers. In such a setting, message passing and encapsulation seem reasonable. But it was never reasonable to copy that idea for objects residing not only on the same computer, but in the same address space.
perrierjouet has joined #commonlisp
<beach>
blihp: So the "traditional object-oriented" programming languages impose unnecessary restrictions. And that is probably a large part of the reason for the widespread disappointment with that style of object orientation. Again, Common Lisp has none of those issues.
<hayley>
It is reasonable to encapsulate and use message passing in the same address space, in order to allow for fault tolerance (c.f. Erlang).
<jackdaniel>
it has some very good points that partially overlap with things said here
<jackdaniel>
blihp: ^
<hayley>
If one object/process/thread/&c crashes, it cannot cause much collateral damage, and you can just replace the crashed thing.
<jackdaniel>
it also emphasizes a difference between clos and smalltalk oop (and why what c++ does is not what smalltalk does)
<beach>
blihp: Respecting traditional encapsulation at the same time as creating a maintainable class hierarchy often results in very complex code. Again, equivalent Common Lisp code can be much simpler.
attila_lendvai has quit [Quit: Leaving]
attila_lendvai has joined #commonlisp
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
CrashTestDummy has quit [Quit: Leaving]
<blihp>
One thing I'm not understanding is how these arguments relate to my original issue: having to force symbol names into the package they are defined in. What benefit is there to doing so that I'm missing?
igemnace has quit [Remote host closed the connection]
<beach>
You are missing the idea that encapsulation is orthogonal to the rest of object orientation.
<jackdaniel>
if you just want to import symbols to cl-user, then type i.e (import 'clim:sheet "CL-USER")
<jackdaniel>
you export from package and import to package
<beach>
jackdaniel: *sigh* Early on, blihp told us that this idea generated conflicts, which triggered the entire discussion.
frodef_ has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
frodef has quit [Ping timeout: 260 seconds]
<jackdaniel>
I see, then I won't interfere
gaqwas has joined #commonlisp
<blihp>
please interfere, I'm trying to understand.
<jackdaniel>
blihp: you may have multiple symbols with the same name, but they can't reside in the same package, that's why you have conflict
<jackdaniel>
to avoid such conflicts you should use package accessors (or carefuly import symbols to your package if that's your thing) - conflict means that in cl-user is another symbol with the same name - that's why you can't import
<jackdaniel>
but I'm sure that others explained that above (I haven't read full backlog yet)
<blihp>
I get that part of it, which pushed me into explicitly prefixing the package name. The part that's still throwing me for a loop is why I have to explicitly prefix the package for symbols that I would expect to be defined in the same package.
<beach>
blihp: The Common Lisp implementation can't possible know what you want and change its semantics accordintly.
<jackdaniel>
if they are defined in the same package you are in then you don't have to prefix them and you shouldn't
Posterdati has quit [Ping timeout: 256 seconds]
<beach>
*accordingly
<jackdaniel>
do you have some code that shows what you are trying to do?
<blihp>
jackdaniel: please read above... that's exactly what I had to do.
<blihp>
I can whip up an example... where should I post it?
<beach>
blihp: The package of a particular symbol is determine way before any Common Lisp operator such as DEFCLASS is executed. It is determined when the code is read, ans mfiano pointed out.
<jackdaniel>
blihp: plaster.tymoon.eu
<beach>
s/ans/as/
<beach>
blihp: To conform to your expectation, the entire computation model of Common Lisp would have to be altered. Therefore, it is easier for you to change your expectations and understand how the Common Lisp computation model works.
<jackdaniel>
you probably forgot to put in-package somewhere at some point
<jackdaniel>
that's good that you've cleared this up for yourself :)
karlosz has joined #commonlisp
<mfiano>
jackdaniel: You're the C/CFFI expert I need to speak with
<jackdaniel>
oh, I didn't know that this is my area of expertise, but I'll do my best!
<blihp>
still not cleared up, now I've got to dig around as see what/how else I might have messed up (it looks like I've got the correct in-package at the top of each file)
<jackdaniel>
mfiano: mind that I'm on and off until 11, I may have lags with responses
<mfiano>
For CFFI:FOREIGN-ARRAY-TO-LISP, if I know the pointer contains elements of the foreign "long" type, and I want a specialized array, what should I pass as :element-type? I don't know if there is a correct answer, as my reading suggests "long" in C99 means "at least 32 bits"
<jackdaniel>
isn't that just :long ?
<jackdaniel>
cffi defines mappings from c types to lisp types
<jackdaniel>
some are backend specific, some are shared
<mfiano>
:element-type of :long results in specialization of T
Algernon69 has joined #commonlisp
<jackdaniel>
ah, element type in make-array-args (as rest args)
<mfiano>
THat is why I was under the assumption I needed a Lisp type there, as I am creating a Lisp array, and '(signed-byte 64) for example works
<jackdaniel>
yes, that's basically what you should do (if the representation is the same)
<mfiano>
Which?
<mfiano>
I'm confused, because the C standard doesn't give an upper bound on the width of "long"
<jackdaniel>
between "C long" and (signed-byte 64)
<jackdaniel>
yes, it is platform (and compiler!) specific
<jackdaniel>
lisp wouldn't know unless you tell it
<mfiano>
So then any Lisp type I supply would be wrong
<mfiano>
(possibly)
<jackdaniel>
there is foreign-type-size at least in principle
<jackdaniel>
hm, perhaps there is a way in cffi to convert c type to lisp type and vice versa, I just don't know
<mfiano>
There is, with the transform generic functions...but in this case I just needed to know that it was 64 as foreign-type-size returns 8 (bytes)
<mfiano>
Thanks a lot man
<jackdaniel>
I don't feel that I was very helpful but sure ;)
<mfiano>
Well anything is helpful to me. I am a total C/CFFI newbie and I dove into the syscall deep end
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
<jackdaniel>
when I'm unsure about cffi I'm usually read things in tests/
<mfiano>
Ah good idea. I just implanted the whole manual into my head yesterday.
<mfiano>
One thing that saddens me is that the groveller doesn't seem to work correctly on FreeBSD
<mfiano>
It calls out to /bin/cc and that returns exit code 127. Perhaps it is assuming gcc flags or something. BSD isn't too wild about GNU tools :)
attila_lendvai has quit [Quit: Leaving]
<pjb>
mfiano: you could provide a small C function that would return the size of the type: int size_charbits(void){ return CHARBITS;} int size_long(void){return sizeof(long);} and use that to declare `(signed-type ,(* (size_charbits) (size_long)))
attila_lendvai has joined #commonlisp
<mfiano>
No thanks. I'll stick between my parens.
<pjb>
mfiano: of course, this only report the problem to your choice of C compiler and options to compile this little size library, vs. the target library…
<pjb>
mfiano: indeed, my advice: just say no to ffi.
<mfiano>
I'm writing very OS and libc implementation-specific code, anyhow.
<jackdaniel>
either way portable code should always use types like uint64_t (all available since c99)
<mfiano>
I'm wrapping code that was probably written in the 70's and hasn't changed much. It is nightmarish.
<jackdaniel>
there is an interesting situation, where unsigned long has different representation between unix32bit and unix64bit, and windows64bit represents tit the same as unix32bit (for compatibility :)
Krystof has joined #commonlisp
<mfiano>
Anyway, I should get to bed. Thanks all
random-nick has joined #commonlisp
lisp123 has joined #commonlisp
<mfiano>
Turns out I don't really want a specialized array anyway as it's only an intermediate value. I need a list of lists, as my API expects to be able to destructure the inner lists: these are statistic counters for each of my CPU's: https://i.lisp.cl/zdkHlq.png
jackdaniel is now known as candlejack
<mfiano>
the ugly part works anyway. get the same results from userland tools. off to bed :)
lisp123 has quit [Ping timeout: 240 seconds]
kuao has quit [Quit: Connection closed for inactivity]
nature has joined #commonlisp
Alfr has quit [Remote host closed the connection]
Alfr has joined #commonlisp
rotateq has joined #commonlisp
blihp has quit [Quit: Leaving]
waleee has joined #commonlisp
s-liao has joined #commonlisp
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
<Nilby>
mfiano: One could (make-array 10 :element-type `(signed-byte ,(* 8 (cffi:foreign-type-size :long)))) but to avoid copying you might cffi:with-pointer-to-vector-data on implementations that support it.
<Nilby>
The only way I know not to use FFI is to run on Mezzano or Genera.
gaqwas has quit [Ping timeout: 240 seconds]
* hayley
continues to idly wonder if a CL "unikernel" would be a good way to grab attention for CLOSOS development.
karlosz has quit [Quit: karlosz]
<Nilby>
hayley: I tried doing a unikernel with bsd rumpkernel and sbcl, and sadly it's still FFI as well as being lots of problems. Now I'm just focused on eliminating everything above the kernel. But I do hope someone would work it out better than me.
<hayley>
I mean that the "kernel" would be written in CL too, but it would be just enough to run Hunchentoot or something.
<hayley>
So, a single-user system without any new user-facing design. The system might still use a traditional filesystem, or it might persistent memory, I don't know.
<Nilby>
The heroic froggey already did it, but also: the minimum of graphics cards and usb is a nightmare.
<hayley>
No graphics cards, and no USB then.
<hayley>
You'll get a 80x25 terminal and you will enjoy it(tm).
<Nilby>
I love command line and tui, but can you even buy a machine with a non-usb serial port anymore?
<hayley>
Yep. I just had to buy a little "breakout" board, which connects to a header on the motherboard and provides the right connectors on the case.
<Nilby>
I'm getting closer to a Lisp busybox every day I don't get distracted.
<Nilby>
hayley: sounds fun. I would run a repl off of JTAG if necessary
<Duuqnd>
My motherboard seems to have some kind of serial interface on it (I'm guessing it's JTAG)
<Duuqnd>
Or perhaps it's the same connector that was just mentioned, I really should read before I type.
<hayley>
I would suspect this sort of connector, given that it is not embedded hardware.
<hayley>
FWIW you can also buy PCI cards with more serial ports (but it turned out I really just needed the internal connector exposed for my application). Scared the hell out of the guy working at the computer parts store.
<Duuqnd>
What do you think he was more scared about, the fact that they still sold it or that you needed it?
<hayley>
The latter.
<hayley>
I had soldered up an OPT2LPT board (which is a breakout board for the YM3812 sound chip over parallel printer port, like the Ad Lib card is a breakout board over ISA port), and got it playing some music.
<Duuqnd>
Wouldn't that be OPL2LPT?
<hayley>
Yes, usually the OPL2LPT is the OPL2LPT.
<Duuqnd>
Well, you wrote OPT above
<Duuqnd>
That's why I asked
<hayley>
Oh, whoops.
<hayley>
I managed to miss the typo twice then.
<Duuqnd>
But yeah, I've heard of those printer port AdLibs and have considered getting one at least a few times
<candlejack>
it is not a type then but rather subcioncious urge to create opt2lpt board
<hayley>
I suspect it'd be the easiest "modern" sound card to interface, sadly.
<Nilby>
that evokes the rather harsh sound memory of my friend's musical dot matrix printer, which I think could handle general midi through some kind of soundblater parallel port rig
nature has quit [Remote host closed the connection]
<Duuqnd>
In terms of easiest to get sound out of, maybe a resistor ladder DAC on the printer port would be even easier
<hayley>
I think those have been made commercially, actually. Off to #lispcafe still...
lisp123 has quit [Remote host closed the connection]
mingus has joined #commonlisp
treflip has quit [Quit: good night ✨]
<Guest74>
? what is x?
<Guest74>
what is foo? bar?
<White_Flame>
case has an implicit OR when given a list of keys, since it's doing EQL tests
<White_Flame>
*a list of keys in a single clause
<White_Flame>
oh, "selected by matching the test-key on the basis of its identity", so more EQ
varjag has joined #commonlisp
<Guest74>
i think rotateq: might be thinking of cond
<Guest74>
though that still doesn't make sense.
mingus has quit [Ping timeout: 256 seconds]
<candlejack>
rotateq: I think that you have confused case with typecase
<candlejack>
for example (and integer (eql 42)) is a type specifier
Oladon has quit [Quit: Leaving.]
pdietz has quit [Quit: Client closed]
Guest74 has quit [Quit: Connection closed]
Algernon91 has quit [Read error: Connection reset by peer]
<Alfr>
White_Flame, it's eql not eq.
Colleen has quit [Remote host closed the connection]
Colleen has joined #commonlisp
<rotateq>
ack! i hate it when my head throws around things ^^ thanks people
<rotateq>
guest74: it does, just you have to use imagination :)
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
<pjb>
rotateq: as White_Flame said, (mapcar (lambda (x) (case x ((and foo bar) '(do-this)) ((or foo bar) '(do-that)))) '( and foo bar baz)) #| --> ((do-this) (do-this) (do-this) nil) |#
<rotateq>
i apologize
<pjb>
No problem. Now just go code review all your code for ANDs and ORs in your CASEs.
<rotateq>
right, of course
<pjb>
And indeed, as candlejack said, TYPECASE takes type specifiers. But you better order them correctly. (subtypep '(and t1 t2) '(or t1 t2)) so ANDs before ORs.
<pjb>
While CASE can jump to the right branch immediately, TYPECASE has to test each type. (but since they're known at compilation time, some optimization is still possible).
<rotateq>
yes sorry i also had that in mind
<rotateq>
sometimes by accident violating my own rules to be reminded by you smart people :3
<semz>
Amusingly enough, an OR in a CASE would almost work since CASE can take a list of objects. (or foo bar) matches 'foo and 'bar (but also 'or...)
<pjb>
In lisp of course. But I don't have the code around.
<Alfr>
semz, and what about (and ..)? x is in some superposition state? xD
<rotateq>
of course! what else?
<pjb>
Alfr: it would do the same as with or, but accept AND instead of OR.
<semz>
Alfr clearly this is important for (and nil ()), what with being a symbol and a list at the same time and all
<rotateq>
maybe i would ask you the next days again for the COMEFROM code of you
<semz>
Jokes aside, I *have* been bitten by (case foo (nil ...)) before.
<Alfr>
pjb, please don't take that question of mine above seriously.
<Alfr>
semz, yeah, and all will work out nicely unless you look at it.
theothornhill has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Everything has joined #commonlisp
mason0 has quit [Quit: CGI:IRC (Session timeout)]
gaqwas has joined #commonlisp
Inline__ has joined #commonlisp
Inline has quit [Read error: Connection reset by peer]
edgar-rft has quit [Remote host closed the connection]
gaqwas has quit [Read error: Connection reset by peer]
gaqwas has joined #commonlisp
edgar-rft has joined #commonlisp
pdietz has joined #commonlisp
Inline__ is now known as Inline
Algernon91 has joined #commonlisp
pve has quit [Quit: leaving]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
frgo has quit []
<pdietz>
CASE uses eql, not eq. Specifically, it sees if the value and a key in a clause are the "same", which is defined to be eql.
<pdietz>
It would be very strange if it used eq, as this would be terribly underspecified on numbers and characters.
<rotateq>
hah yes
Everything has quit [Quit: leaving]
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
NotThatRPG has joined #commonlisp
attila_lendvai has quit [Ping timeout: 256 seconds]
theothornhill has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 268 seconds]
gaqwas has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
notzmv has quit [Ping timeout: 252 seconds]
lisp123 has quit [Ping timeout: 245 seconds]
notzmv has joined #commonlisp
varjag has quit [Ping timeout: 240 seconds]
shka has quit [Ping timeout: 240 seconds]
aartaka has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
Guest74 has joined #commonlisp
<Guest74>
candlejack wouldn't jackfrost be more appropriate?
hisacro has quit [Ping timeout: 240 seconds]
hisacro has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
igemnace has quit [Ping timeout: 256 seconds]
mason0 has joined #commonlisp
aartaka has joined #commonlisp
Algernon91 has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
<NotThatRPG>
Trying to get ITERATE to test with clisp (why do I bother?) and when i try to build it with ASDF I get this: "ITERATE build failed with an error: TRANSLATE-PATHNAME: replacement pieces ((:DIRECTORY "Users" "rpg" "lisp" "iterate") "package" "fas" :NEWEST) do not fit into #P"/Users/rpg/lisp/iterate/test/cache/**/*.*"a" which ... I have no idea what it means.
igemnace has joined #commonlisp
Jing has quit [Remote host closed the connection]
Jing has joined #commonlisp
<NotThatRPG>
My guess is that clisp implements MERGE-PATHNAMES in some different way than other lispen
s-liao has joined #commonlisp
<semz>
I know :absolute and :relative, but :directory seems weird to me.
<NotThatRPG>
I answer my own question -- clisp pukes unless I also supply `:version :wild` because ... pedantic
<NotThatRPG>
Because in 1990 there were still filesystems with versioning.