<saturn2>
maybe it doesn't matter since this rule only applies "during the dynamic extent of the signaling process"
Psybur has quit [Read error: Connection reset by peer]
Psybur has joined #commonlisp
<saturn2>
and running out of memory again while handling a storage-condition just means the world ends anyway
<semz>
Are conditions themselves guaranteed to survive the signalling process? If they don't, one could reuse the space. Doesn't deal with OOM during the OOM handler but arguably this is a major user fuckup.
<semz>
If they aren't*
<Nilby>
IIRC some lisp machines had a memory reserve for handling out of memory conditions, and also the firmware could save a restartable image if things got really bad
taiju has joined #commonlisp
Qwnavery has joined #commonlisp
taiju has quit [Ping timeout: 252 seconds]
taiju has joined #commonlisp
Psybur has quit [Remote host closed the connection]
Psybur has joined #commonlisp
icer has joined #commonlisp
icer has quit [Client Quit]
lottaquestions has quit [Ping timeout: 250 seconds]
icer has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
Psybur has quit [Remote host closed the connection]
tyson2 has quit [Remote host closed the connection]
taiju has quit [Read error: Connection reset by peer]
taiju has joined #commonlisp
srhm has quit [Read error: Connection reset by peer]
john__ has joined #commonlisp
srhm has joined #commonlisp
gaqwas has quit [Ping timeout: 265 seconds]
ggoes has joined #commonlisp
Skyfire has quit [Quit: brb]
Oladon has joined #commonlisp
karlosz has joined #commonlisp
Jach has joined #commonlisp
Bike has quit [Quit: Lost terminal]
prxq has quit [Ping timeout: 252 seconds]
taiju has quit [Ping timeout: 260 seconds]
prxq has joined #commonlisp
karlosz has quit [Ping timeout: 252 seconds]
waleee has quit [Ping timeout: 260 seconds]
<beach>
Good morning everyone!
CrashTestDummy2 has joined #commonlisp
CrashTestDummy has quit [Ping timeout: 265 seconds]
elderK has joined #commonlisp
doyougnu has quit [Ping timeout: 252 seconds]
Qwnavery has quit [Quit: WeeChat 3.3]
semz has quit [Ping timeout: 252 seconds]
Qwnavery has joined #commonlisp
lotuseater has quit [Ping timeout: 246 seconds]
<bitspook[m]>
Good morning!
dre has joined #commonlisp
<beach>
Hello bitspook[m].
semz has joined #commonlisp
igemnace has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
jealousmonk has quit [Quit: ERC (IRC client for Emacs 27.1)]
icer has quit [Quit: WeeChat 2.8]
igemnace has joined #commonlisp
wilfred has joined #commonlisp
Oladon has quit [Quit: Leaving.]
taiju has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
igemnace has joined #commonlisp
Nilby has quit [Ping timeout: 260 seconds]
elderK has quit [Quit: Connection closed for inactivity]
taiju has quit [Read error: Connection reset by peer]
taiju has joined #commonlisp
karlosz has joined #commonlisp
pve has joined #commonlisp
<pjb>
semz: good question (reuse of conditions). 1- we can signal the same condition several times. 2- most condition classes in the standard don't have slot writers (therefore in a new situation, there's no standard API to mutate it, but nothing prevents an implementation to have and do it). 3- usually, conditions are not collected, ie. if a condition was mutated, this would have no consequence, because nobody keeps references to old conditions.
<pjb>
semz: so in the spirit of the standard, it would be best if the condition was pre-allocated, but not reused. It could be allocated when the garbage collector can free enough memory for it. But it would be preferable to allocate a new one each time it's signaled.
<pjb>
while conditions are not usually collected, this is something that is perfectly conceivable: you could keep reference to old conditions in an object-oriented logging system.
* Alfr
thinks hes shouldn't read in reverse order.
<pjb>
Alfr: thank you. Indeed. The problem is that the code that signals a condition cannot know when the handling of the condition is finished. It's definitely not when we're out of a handler-bind, but even not when we're out of a handler-case. For example, the handler could store the condition (with the situation that led to its signaling embedded in it), and process it later.
<pjb>
So indeed, conditions can be pre-allocated, but they should be used for a single situation.
<pjb>
semz: ^
<pjb>
semz: note that when a storage-condition occurs, the condition object is not the only object that needs to be allocated. We may also need to allocate some string (error message), some bignum (memory size, etc), and some other temporary object. Therefore it's probably best managed by reserving some memory zone where to allocate those objects, at the level of the memory manager.
<pjb>
the handler of the condition will also need some memory to work.
gxt has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
gxt has joined #commonlisp
<greyrat>
I am trying to write a one-off "macro" without using an actual macro. But `eval' seems to evaluate its input in the global scope. How do I do this idiomatically?
<beach>
greyrat: Please use a paste site for more than one line of code.
<moon-child>
greyrat: 'macrolet', perhaps
<CodeBitCookie[m]>
greyrat: you could use http://ix.io
<beach>
greyrat: You can't really do that. You can't turn a name into a lexical variable.
<beach>
greyrat: And that's for good reasons.
<greyrat>
I didn't use a pastebin because it takes two seconds for the site to load for me, so I really don't like opening webpages when I don't have to. I'll use pastebins in the future.
<moon-child>
you should be able to configure your text editor to automatically post some region to a paste site
<greyrat>
moon-child: indeed, emacs suggested using a paste site to me. :D
<greyrat>
beach: What are the good reasons?
<moon-child>
performance
<moon-child>
the compiler is less constrained if it is not required to be able to dynamically materialise a location for a given variable
<beach>
greyrat: What moon-child said. If that were possible, the compiler could not apply certain optimizations, such as eliminating dead variables.
<moon-child>
eliminating dead variables doesn't matter _that_ much--just a bit of extra stack space. But any sort of constant propagation or type analysis would be completely killed
<beach>
Sort of. If the variable is in a register, it may have to be spilled if it is considered live.
<moon-child>
sure. But that's still minimal compared with the other costs
<beach>
Indeed.
<beach>
Just pointing out that it is more than "just a bit of extra stack space".
<moon-child>
fair enough
waleee has joined #commonlisp
<hayley>
One trick I've done (which I think is a bit famous for happening frequently in SBCL sources) is to write a form like (macrolet ((frob-it () code-generation-stuff-here)) (frob-it)).
<hayley>
I recall one person wrote a macro for this pattern, and called it ETOUQ (backwards QUOTE).
<greyrat>
Okay, I wrote a macro. Is there any way to "map" the macro on a list? Sth like `(mapcar #'to-int '(year month day))' where `to-int' is a macro.
<moon-child>
put the mapping in your macro
<moon-child>
(macrolet ((stuff () `(progn ,@(loop for ... in ... collect `(setf...))))))
<moon-child>
(could make it a parameter. (defmacro stuff (&rest vars) ... iterate over vars) (stuff year month day)
gxt_ has joined #commonlisp
gxt has quit [Remote host closed the connection]
<greyrat>
moon-child: Thanks. This seems awfully redundant and non-composable though. Why can't there be a general way to iterate a macro over symbols?
<beach>
greyrat: There is, but it will just return a list of forms.
X-Scale` has joined #commonlisp
<moon-child>
greyrat: we've already established that this is 'one-off'. Why should it need to compose?
<moon-child>
(And, I don't see why it is redundant)
<moon-child>
(in fact, I don't entirely see why it composes much worse than any other solution. But.)
X-Scale has quit [Ping timeout: 252 seconds]
<greyrat>
moon-child: I would need to repeat the boilerplate for iterating over multiple arguments in ALL my oneoff macros, which is a lot of repetition.
X-Scale` is now known as X-Scale
<moon-child>
you can easily write a macro for writing one-off macros. Beyond that, it seems likely to me there is an alternate organization that would work better, but without looking at the code I cannot supply it
<greyrat>
moon-child: Can I write a macro that expands `(macro-iter some-macro a b c)' to `(progn (some-macro a) (some-macro b) ...)'? I guess this should be doable, and will resolve my problems.
<moon-child>
sure
<moon-child>
(defmacro ctmap (m &rest args) `(progn ,@(loop for arg in args collect `(m ,arg)))) or some such
<moon-child>
err, `(,m ,arg)
<moon-child>
(the irony of a parameter named 'args' is not lost on me :)
waleee has quit [Ping timeout: 260 seconds]
selwyn has joined #commonlisp
<greyrat>
moon-child: Is it possible to add optional keyword arguments to the macro, while taking all other args into a list? Sth like this:
<pve>
I remember being a bit annoyed at the verbosity of accessing slots when I started lisping. I don't really feel that way anymore, but it was a nice exercise nonetheless.
<lukego>
Hey does anyone know the backstory on CLML? https://github.com/mmaul/clml. It's a machine learning library for Common Lisp that looks surprisingly (?) nice?
<hayley>
.oO(BANNED from the Common Lisp Object System gang)
cage has joined #commonlisp
Krystof has quit [Ping timeout: 268 seconds]
cosimone has joined #commonlisp
cosimone` has joined #commonlisp
cosimone has quit [Ping timeout: 252 seconds]
<lukego>
pve: WITH-SLOTS is my coping mechanism
<beach>
Even better is to ignore slots and use WITH-ACCESSORS.
<lukego>
pve: oh, that syntax looks super duper interesting
<lukego>
pve: I would totally use that if it can be added to an SBCL program without weird side effects like messing up debug info (I have no idea if that's a thing, just not sure how invasive switching readers is)
<lukego>
being a dweeb I would be tempted to introduce new unicode characters for backwards compatibility
<pve>
lukego: to be honest, I don't know how invasive it is either
<lukego>
seems like there's a lot of interest in using eclector in applications, and a lot of uncertainty about what the implications might be
<pve>
lukego: when you say "debug info", what do you mean specifically?
<lukego>
I don't mean to be specific :) I am mostly just wondering if there are surprising consequences of switching the reader out or not. but okay SBCL has a lot of "source location" machinery for mapping machine code back to a path through the program e.g. to make 'v' work in the SLIME debugger
<lukego>
and I wonder if some of the machinery to make that work is in the standard SBCL reader and if so whether swapping it out would break stuff
<pve>
lukego: ok, but I should point out that in my example the reader is only changed on a per-file basis. So it is not an all-in situtation.
<lukego>
still, I'm looking at this imagining using it pervasively in all my application code :)
Skyfire has joined #commonlisp
<beach>
lukego: Yes, I think source information will be lost since it is specific to the SBCL reader. Eclector uses a different (better) system called Concrete Syntax Tree, but that's optional, and incompatible with the SBCL evaluator.
<beach>
... unless scymtym implemented an SBCL-specific option for that, of course.
<lukego>
good to know, thanks!
<beach>
Sure.
<beach>
Of course, there is no longer any particular reason for a Common Lisp implementation to use an implementations-specific reader, so perhaps you can convince the SBCL maintainers to use Eclector instead. :)
<pve>
lukego: At least I'm able to jump to location from the debugger, and M-. to functions, so I don't know if much has changed.
* beach
makes another futile attempt to cut the collective maintenance burden of maintainers of Common Lisp implementations.
<hayley>
beach: You miss every shot you don't make!
<beach>
Oh, maybe SBCL patches the raw S-expressions from the file position.
<beach>
In which case, the source information is NOT lost.
<beach>
hayley: True.
<beach>
Well, no, it can't really do that for nested expressions can it?
<lukego>
beach: well you have people wanting your stuff now, it just might takes us a while to figure out how to use it :)
<beach>
lukego: Yes, that's a good start. Though, I insist that Eclector is no longer part of "my stuff". It is almost entirely the creation of scymtym.
<beach>
... which is probably a good thing because he writes better code than I do.
<pjb>
greyrat: you cannot access the lexical scope with a macrolet as you envision. The problem is that macros are expanded at compilation-time, but your loop is evaluated at run-time.
<pjb>
greyrat: you need to put the loop inside the macrolet.
<beach>
pve: So thanks for exposing your interesting experiments to the general public!!!
<greyrat>
pjb: Thanks!
amb007 has quit [Ping timeout: 252 seconds]
<pve>
beach: hehe, no problem, it's been fun trying it out
<beach>
I can very well imagine. Eclector is a great program.
<beach>
I have had a lot of fun with it myself.
<pve>
beach: I think you're right regarding nested expressions, btw
<greyrat>
How do I loop on a list of lists? In the ith iteration, I want to have a list of all the ith elements.
<beach>
At the very least, we should try to convince the SBCL maintainers to allow the use of Eclector as an optional reader for things like COMPILE-FILE.
<pjb>
greyrat: if the number of lists is less than call-arguments-limit (minimum = 50) - 1 then: https://termbin.com/t8nd
<greyrat>
pjb: thanks. What if it's bigger than that? Should I iterate on the index itself manually?
<pjb>
greyrat: certainly not on the index, since that would automatically multiply the complexity by n!
<pjb>
greyrat: you can replace some by every if you want to stop on the shortest list, instead of the longuest. mapcar and the other map functions in CL stop on the shortest.
<greyrat>
:thumbs-up:
Krystof has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
igemnace has joined #commonlisp
wilfred has quit [Quit: Connection closed for inactivity]
attila_lendvai has joined #commonlisp
lottaquestions has joined #commonlisp
lotuseater has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
<greyrat>
Using sly, how do I see the stdout of the evaluation? `sly-eval-print-last-expression' inserts them in the current buffer, but I want to see them in a new buffer. (Of course, I can write my own wrapper around sly, just asking to see if there is already a ready solution.)
igemnace has quit [Remote host closed the connection]
scymtym has quit [Ping timeout: 265 seconds]
<greyrat>
How do I get an optional variable that can also be `nil'?
<rotateq>
you mean in the lambda list of a function?
<rotateq>
or please specify :)
<greyrat>
I think i found the answer: (defun foo (mandatory &optional (optional1 nil optional1-supplied-p)) ...)
<rotateq>
yes but the initial value and the predicate are also optional ;)
<rotateq>
if you don't need the predicate, then (defun foo (x &optional y) ...) is totally good
<rotateq>
but sometimes you want the intention when y stays being a list, so (defun foo (x &optional (y '())) ...)
<rotateq>
or a list values are pushed to or whatever
<greyrat>
Yeah, cl is quite good. Now I wonder if this works in elisp, too. :))
<rotateq>
i won't count on it
<rotateq>
some days ago someone in #clojure said, in elisp the else clause for IF has implicit progn and concerned that a `cool feature` but it's not good at all and inconsistent
<lisp123>
rotateq: It may look strange but there's nothing bad about it, saves a user from having to write out the progn for it
<rotateq>
of course it is, such an inconsistency even with this elementar operator is bad
<lisp123>
There are inconsistencies in most languages
<rotateq>
but after all, it's mostly for programming your emacs, so
<rotateq>
and this justifies more?
<lisp123>
Well it saves the progn, its just that we are used to the symmetry on the CL side (which I think is better)
<lisp123>
After all RMS did write the GNU compiler so I don't want to throw stones at elisp too much :)
<rotateq>
after all they can't be thrown in the same pot anyway
cosimone` has quit [Ping timeout: 252 seconds]
<lisp123>
Yes, but one can equally say its too strong to say its "not good at all"
<lisp123>
Its different
<rotateq>
and symmetry breaks might be good in nature and physics, to have some matter be left over
<rotateq>
i said the "design" of the IF is not good at all and not all of it in general
<lisp123>
I'm referring to the IF statement - some may like it
<rotateq>
is ok for me
<lisp123>
+1
<rotateq>
you mean 1+ :P
<lisp123>
:P
scymtym has joined #commonlisp
john__ is now known as gaqwas
lisp123 has quit [Quit: Leaving...]
Qwnavery has quit [Ping timeout: 252 seconds]
Qwnavery has joined #commonlisp
Qwnavery has quit [Client Quit]
luna-is-here has quit [Ping timeout: 264 seconds]
luna-is-here has joined #commonlisp
luna-is-here has quit [Client Quit]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
dre has quit [Ping timeout: 252 seconds]
tyson2 has joined #commonlisp
Psybur has joined #commonlisp
cosimone has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
Posterdati has quit [Read error: Connection reset by peer]
<pve>
Is eql the default test for set-difference?
<semz>
pjb: Good point with the logging system. Keeping a bit of memory around specifically for these situations is starting to seem like the only real solution...
<semz>
at least it's a rather simple one at that
Josh_2 has quit [Remote host closed the connection]
Lycurgus has joined #commonlisp
<pve>
lukego: It occurs to me that if we relax the readtable that "forwards" to eclector a bit, then jumping to location ("v") from the debugger will take me to the correct (nested) form.
<pve>
so we basically let sbcl read lists "natively", but let eclector read the atoms
<yitzi>
pve: Are you trying to let SBCL handle source code tracking?
<pve>
yitzi: yes, othewise it will only jump to the top-level form
<rotateq>
pve: better provide an explicit test that fits your situation
<pve>
rotateq: the page for intersection says that EQL is the default, but set-difference says nothing, that's why I was wondering
<yitzi>
pve: What are you trying to accomplish by using Eclector in this way? Just curious.
<rotateq>
yes, I've checked for myself the latter
<pve>
yitzi: just checking it out at the moment, to see what kind of fun stuff can be done
<rotateq>
pve: and now more explicit what I asked myself, for what the heck :test-not was by hysterical raisin
<beach>
rotateq: How did you check it?
<rotateq>
beach: I meant I just "checked" the site, meant reading it. Nothing more.
<beach>
OK.
semz has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
semz has joined #commonlisp
<yitzi>
pve: I use it in common-lisp-jupyter if you are curious to do code inspection, code completion, code reading & compilation in clasp, and recreating source code maps for sbcl, cmucl, ecl and ccl.
<beach>
pve: The information is in meaning of "satisfying the test".
<pve>
I seem to remember that some page somewhere said that unless otherwise stated, a test defaults to eql, but I could have been dreaming
<pve>
beach: :) that's the one
<rotateq>
beach: Do you know how the :test-not worked? (as it is said being deprecated)
<pve>
yitzi: that sounds pretty cool
<beach>
rotateq: It is widely accepted these days that all those "deprecated" instances should be ignored.
<rotateq>
OK.
<beach>
So :test-not is just the negation of :test.
<rotateq>
I see, now it makes more sense to me.
<beach>
Great!
<rotateq>
pve: And I had to recall that under EQL the comparing of two strings gives NIL, even if they have the same content.
<beach>
rotateq: Not always. The compiler can sometimes optimize so that two strings become one.
<pve>
yitzi: so you can read *everything* with eclector, and still jump to location works for nested expressions?
<rotateq>
Okay, so that's would be good, but I wouldn't count on it in the first place.
<pve>
rotateq: that's already ingrained in me by now :)
<rotateq>
good, I try to stick up ^^
<rotateq>
beach: How does SICL do it?
<pve>
yitzi: or I guess I'm asking if that is what "recreating source code maps" means
<beach>
rotateq: Strings? I don't remember. I suspect we don't coalesce at the momennt.
<beach>
*moment
<yitzi>
pve: There are several areas where Eclector is being used and some parts where the implementation reader is used. I'll give you a basic explanation...
<rotateq>
Ok not important, assuming they aren't equal in memory would be fine.
<beach>
Yes, never assume that.
<beach>
... unless you are sure, of course.
<rotateq>
Like using SCHAR rather than CHAR when it's clearly of type SIMPLE-STRING and the index given isn't out of bounds.
<rotateq>
Or CHAR over AREF.
<yitzi>
pve: reading and evaluation uses the implementation's reader and compiler. Implementations vary on what they report as the "source code location" though. I need line and column references to make the debugger work. For clasp I use an enhanced gray-stream under their eclector reader. For SBCL, CMUCL, ECL and CCL I use eclector to recreate a map from the implementation's source references to line/column if needed. For code inspection/completion I
<yitzi>
use eclector with a custom client that does not intern symbols and keeps the package names separate so I can do inpection and completion on those also.
selwyn has quit [Read error: Connection reset by peer]
<pjb>
greyrat: I don't know about sly, but in slime, C-u prefix will make slime-eval-last-expression insert the result in the current buffer.
<pve>
yitzi: thanks for the explanation, that sounds really interesting
<pve>
also super complicated
<pjb>
greyrat: emacs lisp is somewhat different, and indeed, on &key and &optional
<pve>
complicated as in hard, I mean
<pjb>
greyrat: but there's (require 'cl) and defun* that behaves more closely to cl:defun.
<yitzi>
pve: no problem. And yes, it is kind of mess but having a debugger in Jupyter makes it so.
<pjb>
rotateq: emacs lisp being to program emacs is not a reason why emacs couldn't include a full fleshed Common Lisp; ancien lisp machines contained several different lisps. and there is a Common Lisp implementation in emacs lisp that worked before (ironicallyh) lexical binding was introduced to emacs lisp (emacs-cl); lexical
<pjb>
this could be revived, or another CL implementation could be ported to emacs lisp; perhaps sicl? Or we could also integrate ecl as an emacs lisp plugin, now that they exist.
<beach>
pve: For the SICL reader, we do the same thing as yitzi with the Gray streams. We have Eclector configured to create concrete syntax trees, and that's what the first pass of the compiler accepts.
Lycurgus has quit [Quit: Exeunt]
<beach>
pve: And for the purpose of bootstrapping, we may have to configure Eclector so that it does not intern symbols in the host package system.
<yitzi>
clasp does essentially the same thing and as a result writing REPL that preserved source references for Jupyter was very easy compared to the other implementations. Looking forward to SICL!
<beach>
Heh, thanks.
<beach>
You are already using parts of if, since Eclector is definitely a SICL-related project.
<beach>
I mean, it started life as the SICL reader, and was then extracted and greatly improved by scymtym.
<rotateq>
pjb: definitely. Green Spuns rule applies :)
<pve>
beach: ok, and concrete syntax trees contain the source code location data?
<beach>
Yes.
<beach>
It wraps S-expressions in standard objects that contain source information.
<yitzi>
beach: Well, that is true. And trust me, that is a big deal because there is a lot of tasks in common-lisp-jupyter that would be very difficult without eclector.
<pve>
beach: ok, I'm still a little unsure what part Gray streams play in all this
<beach>
yitzi: I can very well imagine.
<beach>
pve: They supply the source information in a way that the client wants.
<beach>
pve: For example, in SICL, the source information is a quadruple: start line, start column, end line, end column.
<beach>
Eclector queries the stream for source information. By default the FILE-POSITION is used, but with a Gray stream, the client can choose the format.
<beach>
Client code defines a Gray stream class, and method on the relevant Eclector method that queries for source information, specialized to that Gray stream class.
selwyn has joined #commonlisp
selwyn has quit [Remote host closed the connection]
<beach>
Actually, SICL is even more special. It reads the entire file contents into memory first, and then characters are read from the memory representation.
<pve>
beach: ok, I need to check those out in a bit, thanks!
<beach>
It does this so that the source code of the compilation unit is associated with the compiled code, in the form of a vector of strings.
Oladon has joined #commonlisp
<pve>
thanks yitzi too
<beach>
That way, the file can go away, and we still have source location in the backtrace inspector.
<beach>
Unlike SBCL, where the directory belonging to Krystof can not be found on my machine.
jealousmonk has joined #commonlisp
X-Scale` has joined #commonlisp
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
cosimone has quit [Remote host closed the connection]
lottaquestions has quit [Ping timeout: 260 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<scymtym>
that's strange. references to SBCL sources are stored with logical pathnames. i thought there was no mapping to physical pathnames unless SB-EXT:SET-SBCL-SOURCE-LOCATION is called
shka has joined #commonlisp
shka has quit [Client Quit]
<beach>
I am sure I have seen this pathname reference, but I can't remember the situation now.
luna-is-here has joined #commonlisp
shka has joined #commonlisp
<scymtym>
maybe something went wrong with a release
<beach>
That's possible.
lisp123 has quit [Ping timeout: 265 seconds]
gioyik has joined #commonlisp
<lukego>
pve: oh wow, is that example the whole implementation? I assumed the eclector extension was in another file but maybe that's it there near the top?
<pve>
lukego: yeah, the implementation is in another castle, but I think I could package the examples up into something easily loadable (and useable)
dra has joined #commonlisp
<pve>
lukego: the slots-and-accessors-test example depends on the eclector-access system (which in turn depends on eclector) and also the files symbol-patterns.lisp and slots-and-accessors.lisp in the examples dir
dra has quit [Client Quit]
dra has joined #commonlisp
lisp123 has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
amb007 has quit [Ping timeout: 250 seconds]
char has quit [Ping timeout: 252 seconds]
tophullyte has joined #commonlisp
nature_ has joined #commonlisp
nature_ has quit [Client Quit]
gioyik has quit [Ping timeout: 276 seconds]
selwyn has quit [Read error: Connection reset by peer]
akoana has joined #commonlisp
amb007 has joined #commonlisp
Nilby has joined #commonlisp
molson_ has joined #commonlisp
gioyik has joined #commonlisp
molson__ has quit [Ping timeout: 252 seconds]
mariari has quit [Quit: WeeChat 3.2.1]
mariari has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
yewscion has quit [Ping timeout: 260 seconds]
cosimone has quit [Ping timeout: 260 seconds]
selwyn has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
gioyik has joined #commonlisp
char has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
lisp123 has left #commonlisp [Leaving...]
gioyik has joined #commonlisp
brettgilio has quit [Quit: Leaving...]
brettgilio has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
amb007 has quit [Ping timeout: 265 seconds]
<Krystof>
beach: what, you deleted it!?
<jackdaniel>
:)
selwyn has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Psybur has quit [Remote host closed the connection]
gioyik has joined #commonlisp
tyson2 has joined #commonlisp
Oladon has quit [Quit: Leaving.]
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
scymtym has quit [Ping timeout: 252 seconds]
kakuhen has joined #commonlisp
attila_lendvai has quit [Ping timeout: 250 seconds]
terrorjack has joined #commonlisp
shka has quit [Ping timeout: 265 seconds]
White_Flame has quit [Remote host closed the connection]
White_Flame has joined #commonlisp
cage has quit [Remote host closed the connection]
scymtym has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
taiju has quit [Ping timeout: 260 seconds]
lisp123 has joined #commonlisp
<lisp123>
Anybody use CMUCL on MacOS?
taiju has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 260 seconds]
Lord_of_Life_ is now known as Lord_of_Life
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
<rotateq>
did you also try CCL, lisp123?
<lisp123>
rotateq: Yes, I got that working. My brain hurted trying to install CMUCL so I gave up
kakuhen has joined #commonlisp
<rotateq>
as long as you don't think it's just about you
<rotateq>
i mean that it didn't work out yet
<lisp123>
rotateq: Perhaps. Next up is LispWorks if I can save up enough money to try it out (outside of the Personal Edition), and perhaps AllegroCL too
<lisp123>
My goal is to have them all nicely installed, then switch between each in Emacs with (setq inferior-lisp-program ....)
<rotateq>
as you like it
<rotateq>
i see, but don't hop around too much
<lisp123>
Indeed :) I'm just procrastinating, better get back to something more productive
<rotateq>
like getting to know the thing itself better :)
<rotateq>
even wanting to be aware of the things *one* of the main implementations provide is immense
dra has quit [Ping timeout: 250 seconds]
<rotateq>
and ACL and LW then come with so much stuff on top
<lisp123>
That would be a productive idea :P
<rotateq>
just random thoughts of mine
<rotateq>
as always
<rotateq>
and you don't have to use the commercial ones to offer paid work
<lisp123>
Yes
<rotateq>
you have luck if your customer is getting what you tell him why you choose the thing itself in contrast to most competitors, trusts you and says "OK". so you don't have to tell him even more "oh and because of this and that better this implementation"
<lisp123>
Most customers I guess wouldn't care what language is used
<rotateq>
this can be stated in short if real user documentation is provided
<rotateq>
right, because they don't have an overview, so trust is of much worthness (you could tell them basically anything)
<lisp123>
I guess they pay the developer to choose something appropriate
<rotateq>
yes the payment will include that you do it to your best believing (justified by clear facts and some metrics). and thinking in the long run
<lisp123>
Indeed
<rotateq>
that kind of freedom often goes hand in hand with confidence, and confidence is grown by experience and experience is grown by practice
<lisp123>
Hardest part is getting the customers, but we are going off topic now :)
<rotateq>
yes
<rotateq>
I think you're maybe about going to sleep.
<lisp123>
You read my mind, nights :)
lisp123 has quit [Quit: Leaving...]
shka has joined #commonlisp
Nilby has quit [Ping timeout: 252 seconds]
Oladon has joined #commonlisp
gaqwas has quit [Ping timeout: 252 seconds]
shka has quit [Ping timeout: 252 seconds]
dre has joined #commonlisp
rotateq has quit [Quit: ERC (IRC client for Emacs 27.2)]
pve has quit [Quit: leaving]
Psybur has joined #commonlisp
lotuseater has quit [Quit: ERC (IRC client for Emacs 27.2)]