<merazi>
beach: Ooh! I didn't knew about that convention :P
<merazi>
Then... Good morning!
<beach>
merazi: Are you new here? I don't recognize your nick.
<merazi>
Yes, I'm fairly new
<beach>
Welcome to #commonlisp. What brings you here?
<merazi>
I'm learning Scheme, a lisp implementation (I know it's not the same as Common Lisp), and I wanted to be part of the lisp community.
<beach>
Great!
<beach>
What made you choose Scheme over Common Lisp?
<merazi>
SICP
<merazi>
A friend sent me the book
<beach>
I see.
<merazi>
Yeah
<merazi>
That's my story, nice to meet you! :)
<beach>
You too. So have you done any programming before in any other languages?
<merazi>
Yes, but just Java, C and Python
<beach>
That's not bad.
<merazi>
I'm not a professional programmer but I have some experience with those languages
<beach>
I see.
<beach>
merazi: I should tell you, usually #commonlisp is fairly lively, but this is Sunday morning in Europe, and many people here are Europeans with families, so it is a bit slow during the weekend.
<merazi>
That's completely understandable, I won't be here 24/7 but I'll hang out occasionally.
<beach>
Sure.
<jcowan>
merazi: Not to steal you away or anything, but there is a #scheme channel as well as the #lisp channel, which is about all the Lisps.
<merazi>
I'm already in the #scheme channel and... *click* Now I am in the #lisp channel as well :)
CrashTestDummy has joined #commonlisp
asarch has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 240 seconds]
<beach>
That dictionary entry says how a conflict should be resolved when an imported symbol conflicts with an existing inherited symbol, and when it conflicts with a symbol that is present.
<beach>
But what about this scenario: A new symbol conflicts with a symbol that is present, but the present symbol is a shadowing symbol, and there are external symbols in the used packages that would conflict if it weren't for the fact that the present symbol is a shadowing symbol.
<beach>
So here is my question: Should a conflict be reported that contains also the inherited symbols? If not, what happens if the user uninterns the present symbol? Should the new symbol also be a shadowing symbol right away, or should a new conflict be reported?
<beach>
I am leaning toward not including inherited symbols in the conflict report and to make it shadowing if the present symbol is a shadowing symbol.
srhm has quit [Quit: Konversation terminated!]
torbo has joined #commonlisp
merazi has quit [Quit: merazi]
Mandus has quit [Ping timeout: 272 seconds]
Mandus has joined #commonlisp
asarch has quit [Quit: Leaving]
torbo has quit [Remote host closed the connection]
ggoes has quit [Quit: WeeChat 2.3]
ggoes has joined #commonlisp
Mandus has quit [Ping timeout: 256 seconds]
Mandus has joined #commonlisp
gaqwas has joined #commonlisp
White_Flame has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
White_Flame has joined #commonlisp
kpoeck has quit [Ping timeout: 246 seconds]
derelict has joined #commonlisp
PinealGlandOptic has quit [Quit: leaving]
Lord_of_Life has quit [Ping timeout: 272 seconds]
Lord_of_Life has joined #commonlisp
selwyn has joined #commonlisp
dsk has quit [Ping timeout: 240 seconds]
d4ryus has quit [Quit: WeeChat 3.2]
d4ryus has joined #commonlisp
derelict has quit [Ping timeout: 252 seconds]
selwyn has quit [Read error: Connection reset by peer]
<beach>
Many issues have a line "TODO: check other implementations." where the behavior of other implementations should go.
<beach>
Also please indicate whether you are in favor of the issue in question.
<moon-child>
doesn't everybody have easy access to the free implementations?
<beach>
They do, which is why I think it is easy to help out here.
<beach>
But we are also interested in the commercial implementations of course.
<moon-child>
hahha, how did I miss prog2-return-value
<moon-child>
this is great
<beach>
Some of the issues have been transferred from (I think) Cliki to WSCL. This one was transferred by Bike.
<beach>
The PROG2 copy-paste error is quite well known.
<moon-child>
yeah, I saw it was dated to 2004, which was why I was surprised I had never heard about it
<beach>
Yes, I see.
<shka>
what? prog1 and prog2 are identical? :D
<beach>
shka: yes, maybe you prefer to make an "issue" that PROG2 should be deprecated since there is an operator doing the same thing. :)
<shka>
i have no idea, i am yet to process this mistake :D
blihp has quit [Ping timeout: 265 seconds]
Guest39 has joined #commonlisp
<Alfr>
PROG2 shouldn't be deprecated, as its second form is mandatory thus not redundant to prog1. But fixing the description of result-2 (under Arguments and Values) for consistency could be considered.
<beach>
I was making a joke about deprecating it, as the smiley indicates.
<Alfr>
I know.
<Alfr>
I was thinking about the following fixup: result-2---the primary value resulting from the evaluation of first-form.
<beach>
Adding return values would be a major change to the standard.
<beach>
That's why implementations are not allowed to add specific return values.
<Alfr>
beach, what do you mean? clhs already uses the name result-2 for the only value of prog2.
<beach>
Oh, I guess I misunderstood.
scymtym has joined #commonlisp
<beach>
Alfr: So you are suggesting making PROG2 identical to PROG1?
<Alfr>
Except that its second argument would be mandatory.
lotuseater has joined #commonlisp
<Alfr>
Going for the least amount of change there, i.e. keep the Description intact. ;)
<Alfr>
It isn't a serious proposal anyways apart from keeping prog2 alive. I think there is a know better fix for that.
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
<pjb>
beach: there are arguments to deprecate prog2. For example, there's no multiple-value-prog2, only a multiple-value-prog1 :-)
nij- has joined #commonlisp
waaron has joined #commonlisp
Guest63 has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
random-nick has joined #commonlisp
CrashTestDummy has quit [Ping timeout: 276 seconds]
Guest63 has quit [Quit: Client closed]
igemnace has quit [Remote host closed the connection]
edgar-rft has quit [Remote host closed the connection]
edgar-rft has joined #commonlisp
cage has joined #commonlisp
kenanb has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
domovod has joined #commonlisp
<scymtym>
deprecate all three and generalize to MULTIPLE-VALUE-PROG-NTH N FORM* where N is evaluated. i'm sure there will be no negative impact in terms of ergonomics or performance
<nij->
What are some pros and cons between McCLIM vs cl-cffi-gtk?
CrashTestDummy3 has joined #commonlisp
CrashTestDummy has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 250 seconds]
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
CrashTestDummy2 has joined #commonlisp
kenanb has left #commonlisp [ERC (IRC client for Emacs 27.2)]
<scymtym>
that's hard to answer in general. GTK has gpu acceleration, more complete text and font support, more supported platforms and probably looks more appealing to many users. McCLIM works without foreign libraries, has the presentation and command sub-systems, is easy to extend due to the stratified design and has a specification. but again, advantages and disadvantages will depend on the use-case
CrashTestDummy has quit [Ping timeout: 268 seconds]
amb007 has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 256 seconds]
scymtym has quit [Ping timeout: 272 seconds]
<lotuseater>
a friend of mine said McCLIM looks old but I more tend to use the term "baroque"
scymtym_ has joined #commonlisp
<beach>
lotuseater: So here is what bugs me. People would rather spend a lot of time and energy debugging FFI solutions that serve only their own projects, and complain about the looks of McCLIM, rather than spending a small amount of time making McCLIM look the way they would like it to, thereby providing a better solution for the entire community.
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
domovod has quit [Quit: WeeChat 3.2]
yitzi has joined #commonlisp
<contrapunctus>
lotuseater: there's been some lovely art from the Baroque era, is that a compliment? 😏
tyson2 has joined #commonlisp
jans has joined #commonlisp
tyson2 has quit [Client Quit]
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 240 seconds]
ming has joined #commonlisp
peterhil has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
akoana has quit [Quit: leaving]
lisp123 has joined #commonlisp
<jmercouris>
I talked to jackdaniel about improving the appearance of McCLIM at some point
<jmercouris>
It seems a lot of the appearance is hardcoded
<jmercouris>
IE it is not enough for a designer to come up with some new bitmaps
<jmercouris>
Things must be programmed to make it look good
srji has quit [Quit: leaving]
srji has joined #commonlisp
<beach>
Yeah, we wouldn't want anybody to write any code, now would we?
<shka>
beach: are you being sarcastic or sincere?
<beach>
The former.
<beach>
The grammatical structure of the sentence makes that clear to a native speaker. Sorry about that shka.
<shka>
well, arguably, styling of application should be at least semi code independent
<beach>
So, there is some coding to be done to make that happen.
<shka>
heh, it seems to be always the case
<beach>
I am not sure what the message is here. The initial creators of McCLIM didn't take into account the necessity for everything to be just bitmaps, so therefore, since coding is required to make it look the way we want, we should all give up and use gtk instead?
* beach
is clearly in a rotten mood today.
<shka>
beach: we should consider
<shka>
how to retrofit mcclim to fulfill the new requirements
<shka>
if at all possible
<pjb>
Also, it's an impossible task. Apple is not in the computing business, it's in the fashion business. The look WILL change every year! If you try to follow, you are only wasting resources that would be better spent elsewhere.
<pjb>
I'd just use garnet…
<beach>
Or gtk.
<pjb>
It's already a lot of works to follow the changes in X…
<shka>
uh, i would rather not use GTK
<pjb>
beach: or indeed, defer the work to some other team.
<beach>
I should be quiet. I am afraid I will say something I will later regret.
<pjb>
The more bland the look anyways, the faster and the better. We can compete on other things, such as ergonomics and smarts.
<lisp123>
is it possible to build a bridge between any Lisp GUI system and the default GUI tools of each OS?
<lisp123>
I think CAPI works directly with Cocoa for example?
<shka>
lisp123: high effort required for maintenance
<shka>
also, anything C is not exactly standard in lisp
<shka>
so technically possible, but not realistic
<shka>
or practical
<shka>
anyway, i think that right here, right now, CLIM is the best option to write GUI
<lisp123>
shka: thanks, I guess its too time consuming so hasn't really happened. Its very hard to go up against Apple (in particular) due the amount of money & time they spend on design - and anything that doesn't follow the native look on MacOS will look off to some degree
<beach>
lisp123: There are great advantages to a GUI toolkit written entirely in Common Lisp.
<lisp123>
but as pjb said, UI design is fashion, so will _alawys_ change each year
<shka>
and CLIM is quite fun to use
<_death>
you don't need to use gadgets.. you can draw everything by yourself
<beach>
McCLIM is a great library. That's why complaints make me in such a rotten mood.
<lisp123>
beach: I was more thinking if its possible to keep everything but using the end visual components of a native system
<beach>
lisp123: In order to avoid FFI, you would then only be able to reuse the bitmaps.
<beach>
lisp123: And jmercouris told us that McCLIM is not structured that way.
<lisp123>
beach: oh I see, I misread his comment as I thought it mean its not enough to only reuse bitmaps, but required more
cage has quit [Ping timeout: 265 seconds]
CrashTestDummy3 has joined #commonlisp
<beach>
Exactly, you can't just plug in new bitmaps into McCLIM the way it is now structured.
<lisp123>
fair enough
<beach>
So, in order to reuse the native look without FFI, all you can do is copy their bitmaps, but that's not currently enough.
<_death>
that's only the look.. the bigger issue is the feel
<beach>
I think the people complaining about McCLIM looks haven't really seen the great advantages that presentations and a dynamic programming language give in a toolkit.
<lisp123>
(p.s. not complaining :-) ) - out of curiousity, why not just go down the FFI route
<beach>
I will take those advantages any day over the latest visual fads.
<beach>
lisp123: Because it always results in a debugging nightmare, as you can see from the numerous cries for help here, when people are lost.
CrashTestDummy2 has quit [Ping timeout: 258 seconds]
<shka>
beach: the problem is that no matter how cool is to program applications using McCLIM, there is distinction between nerd software and normal people software
<lisp123>
beach: ah thanks, understood
<shka>
looks are not important for programming tools
<beach>
shka: Yes, I understand.
<shka>
but they are of significant importance for commercial, mass software
<beach>
Oh, and commercial mass software is what all the #commonlisp participants who complain about McCLIM are into?
* beach
really should be quiet.
<shka>
please, some of us have bills to pay
<beach>
But Common Lisp is totally useless for commercial software anyway, as I understand it. So I don't see the problem.
<beach>
Just use the native GUI toolkit with the language it was meant for.
lisp123_ has joined #commonlisp
<shka>
why is CL useless for commercial software?
<beach>
I should be quiet. It was another sarcastic remark.
<shka>
right
<shka>
well, that's how it is, i can write prototype in McClim, and it will be fun, but there is no way in hell that boss would allow it go to the user with the company logo slapped on
<shka>
as silly, as it sounds...
<beach>
I am not getting my message across here I think.
<shka>
i guess
lisp123 has quit [Ping timeout: 255 seconds]
<beach>
My message is that there is A LOT of collective energy spent in debugging FFI solutions. I think the effort to make McCLIM look like the native toolkit would be WAY LESS than the collective wasted effort we witness here on a regular basis.
<shka>
oh, totally agreed
lisp123 has joined #commonlisp
<beach>
Yet, people choose FFI all the time, complain about McCLIM, and then come here and cry because they can't figure out the FFI stuff, thereby wasting other people's time too.
<shka>
however, what about being able to style it independently of the host toolkit?
<beach>
What about it?
<shka>
well, from my point of view, making mcclim look and feel exactly like native toolkit is not exactly required
<_death>
it's a simple matter of programming
<beach>
Excatly.
<beach>
Exactly.
<beach>
SO SOME PROGRAMMING MIGHT BE NEEDED. JUST F*ING DO IT!
<beach>
shka: Not directed to you personally.
<shka>
i don't have anything to add at this time
<beach>
shka: Let me make that very clear. I was not addressing you here. I don't consider you one of the complainers.
<shka>
ok
lisp123_ has quit [Ping timeout: 268 seconds]
derelict has joined #commonlisp
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
mariari has quit [Quit: WeeChat 3.2]
<beach>
So how do you use bitmaps to draw things with varying size like scroll bars?
<beach>
I suspect I am the one responsible for the initial McCLIM scroll bars, and if so, I very likely used code to draw it, as a function of the size.
mariari has joined #commonlisp
<beach>
So how does a typical GUI toolkit with themes draw scroll bars?
<_death>
they can use small bitmaps representing the corners and such
<beach>
I see, and something repeating for the middle?
<_death>
yes
<beach>
Makes sense.
* eta
played around with the clim-listener once and found the experience generally quite janky
<eta>
perhaps due to xwayland issues?
<_death>
in DOS days everyone wrote their own GUI libraries.. you'd deal with the myriad of drivers or VESA etc.. each would have different look and feel, kind of like today's websites
<eta>
I also suspect it's an acquired taste, as in you have to familiarize yourself with the paradigm (which isn't what your OS GUI looks or feels like either)
<pjb>
But nowdays, they'll use vertorial images for the various resolutions. Possibly shadowed by "optimized" bitmaps for the most common resolutions.
<_death>
many great tools from that era had look and feel tuned to match the tool's functionality
<beach>
eta: Part of the problem with the listener is the input editor, which is DREI and which was extracted from (first) Climacs. We are (slowly) working on Second Climacs that we hope will be much better.
<beach>
On the other hand, I suspect gtk doesn't have a Common Lisp listener at all.
<eta>
point is, I think it's entirely reasonable to want to write a GTK+ app
<eta>
(like, actually GTK+, not something themed to look like GTK+)
<shka>
nah, gtk is horrible nowadays
<beach>
eta: For its excellent listener?
* eta
quite likes it
<eta>
beach, no, having a listener isn't important to me
<eta>
none of the apps that I use daily work that way :p
<beach>
eta: Oh, I thought that's why you brought it up.
<_death>
the listener could've been more extensible, so that people could independently write their own command tables and they could all be used by the listener's user without much effort
<eta>
beach, I'm trying to provide a bit more nuance to your opinions on the GTK+ "complainers" being terrible and no good :p
<beach>
I see.
<_death>
eta: when you get used to a listener pane being available, you find more and more uses for it.. essentially it gives you the best of both worlds (GUI and command line)
<eta>
_death, sure, I've been meaning to play with CLIM for a while :)
cage has joined #commonlisp
<_death>
I wouldn't use clim for everything, of course, but it seems more underused than overused
<shka>
clim is fun
<shka>
highly recommended
<shka>
is is tailored for lisp and it shows
shka has quit [Quit: Konversation terminated!]
<lisp123>
would it be difficult to embed a McClim screen into an Emacs buffer?
shka has joined #commonlisp
<lisp123>
since they both use lisps of various forms
<beach>
lisp123: lukego did something like that.
<lisp123>
beach: nice, I will search for it (the main reason I ask is context switching, the dream is to have everything in one window and Emacs does that a lot but cannot handle GUI well)
<beach>
lisp123: My plan is to make Second Climacs so much better than Emacs for editing Common Lisp code that it will be irresistible to Common Lisp programmers.
<lisp123>
Nice :D A good text editor is very important IMO - there's a lot of applications for text manipulation, now I'm using a lot of Emacs APIs to do some funky stuff
<beach>
Right, Emacs has lots of packages and modes for many things.
<beach>
But it's Common Lisp capabilities are mediocre, despite SLIME.
<lisp123>
But (to play devils advocate), is that a limitation of Emacs or of features not in SLIME?
<lisp123>
Since its not too hard to pass data between Emacs & the CL image
<lisp123>
unless all the global variables and how Emacs does things, makes it too cumbersome to control it via slime
<beach>
Oh, sure, you can accomplish anything you want, but the fact that everything has to be encoded in a wire protocol makes it very hard to write and maintain such a thing.
<lisp123>
Ok, fair enough - I see from that perspective. Plus its a very large dependency one would *ideally* avoid in a pure CL environment
<_death>
with a more sophisticated clim listener you could easily do Bret Victorish things
recordgroovy has quit [Ping timeout: 265 seconds]
<lisp123>
_death: whats 'bret victorish'? google came up with a school board trustee's home page, so probably something else :D
<_death>
lisp123: see for example explorable explanations section
<lisp123>
_very_ cool
<_death>
a while ago I looked into using cells with clim.. it basically worked, but all I remember now is that it needs further exploration
<beach>
Don't tell the author of cells that.
<shka>
hmmm, cells + clim
<shka>
this... has some potential
<_death>
I think CLIM gadgets had some missing (or unexposed) interfaces for doing things
<_death>
e.g., when you move a slider you don't necessarily get notified until mouse button up (iirc).. also, clim needs a sensible way to do debouncing
<beach>
What is "debouncing"?
<_death>
beach: it basically means setting a timer to do the action, rather than doing it immediately, and readjusting if necessary (the user is not yet idle)
<beach>
I see. Thanks.
<_death>
beach: this could alleviate obvious problems like "jumpy" highlighting because of nested presentations
<beach>
OK.
<jmercouris>
beach: my plan is to make Nyxt an irresistible editor
<jmercouris>
So you have some competition :-)
<lisp123>
jmercouris: can't wait for nyxt to take over the world :-)
<beach>
jmercouris: So I understand. I applaud multiple efforts.
<lisp123>
Need a working Mac version soon though
<lisp123>
I instaleld it on a linux within a VM, but the rendering of fonts by the VM wasn't good enough (since I have a largish screen), then tried Macports & Home brew, but wasn't so easy
<lisp123>
Best would be App Store, but I'm sure many have mentioned that already :-) I think you will find a lot of love from the MacOS community
cage has quit [Read error: Connection reset by peer]
cage has joined #commonlisp
<jmercouris>
I know, I was a macOS user myself, it’s just so frustrating dealing with the APIs
<lisp123>
Yeah its annoying how macOS is similar to linux but still the gap is far and many things don't port over nicely
dsk has joined #commonlisp
silasfox has joined #commonlisp
dsk has quit [Ping timeout: 252 seconds]
scymtym_ has quit [Ping timeout: 272 seconds]
<lotuseater>
beach: yes
<lotuseater>
contrapunctus: of course it's a compliment :)
<lotuseater>
looks isn't everything (but what sells)
<lotuseater>
or "aren't"
silasfox has quit [Ping timeout: 252 seconds]
ming has quit [Ping timeout: 240 seconds]
<lotuseater>
jmercouris: are there plans for also bringing nyxt to ARM (I mean eg raspberry pi)? and I can imagine it has a smaller footprint in memory than firefox or chromium
ming has joined #commonlisp
<jmercouris>
lotuseater: if there is demand, we will do it
<lotuseater>
hehe, I just thought about what I would need
<lotuseater>
but this is one excellent example for me how to deploy such a big application to various platforms
<lotuseater>
the thing is the SBCL on pi is just vesion 1.4.6 or so o_O even in apt, but I installed nix package manager so this oldish debian pkgs is not my problem where i need newer software releases
blihp has joined #commonlisp
silasfox has joined #commonlisp
dsk has joined #commonlisp
<lotuseater>
jmercouris: is there some need for more contributors?
<jmercouris>
lotuseater: indeed there is
<jmercouris>
You can join us on #nyxt and we can talk about it there
waleee has joined #commonlisp
ming has quit [Remote host closed the connection]
jans1 has joined #commonlisp
jans has quit [Ping timeout: 265 seconds]
jans1 is now known as jans
zacts has joined #commonlisp
<ecraven>
hm.. I remember looking at an article that talked about how to implement compile-time unit (as in m, s, m/s, ...) checking in Common Lisp, but can't find it any longer :-/ does anyone happen to know it?
<JeromeLon>
I have a (declaim (optimize ...)) at the top of each file in my asdf system. This is suboptimal, I would like a shared directive (in package.lisp for example). I couldn't find what the compile-time semantics are for declaim when using multiple files: declaim stuff should be global, but the compiler focuses on a single file that is not even loaded. What is the right way to share a declaim between multiple files?
<lotuseater>
JeromeLon: wouldn't it work with that around-compile option in the asd file?
<JeromeLon>
lotuseater: that sounds perfect! the doc for around-compile even mentions "proclaiming consistent optimization settings"
<lotuseater>
:)
<JeromeLon>
lotuseater: thanks!
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<pjb>
JeromeLon: you should not declare optimization in library (or published application) code.
<pjb>
JeromeLon: let the user set his own optimization.
<lotuseater>
but have a look on how it is on the implementation you use
<pjb>
Doing that is treacherous and make make the user lose days in debugging!
<JeromeLon>
pjb: so, what is the right way to do it? declaim something and then call load-system? will my declaim be used (assuming nobody did what you are guarding me against)?
<aeth>
ime, what I'd want to do is optimize specific functions
<aeth>
there's plenty of times where that would make sense with math libraries
<pjb>
JeromeLon: put your optimization declaration in your rc file. Change it depending on what you want to do (eg. if you want to generate a fast executable, you can rais speed, by default, you will be debugging).
CrashTestDummy2 has joined #commonlisp
<aeth>
imo... if what you're doing isn't math, you probably don't want to optimize it at all; if it is math, I'd optimize per-function (perhaps with a macro to automate it)
<pjb>
bugs can occur in any function, so don't put optimization in the source files.
<aeth>
Optimizations can also make a difference with CASE stuff...
<aeth>
pjb: It's not a universal, though. There are cases where you absolutely want to have optimizations in the source files, directly. But essentially only for math libraries.
<aeth>
i.e .You don't want to have the user force (near-)universal optimizations just to get efficient math
<JeromeLon>
oh, but I don't want to optimize at all, I just want (debug 3)
<pjb>
you would have to wrap them in a lot of checks. Most of the time, that would defeat the purpose.
<aeth>
oh, debug 3? Absolutely don't force that on users!
<JeromeLon>
I want to force it on myself
<aeth>
yeah, then pjb is right
<pjb>
Indeed, let them put what they want in their rc file.
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
<JeromeLon>
ok, let me reformulate my question: I am writing a system that consists of a lot of files. What do I have to do to have all the debug capabilities at all time while developping?
<JeromeLon>
pjb: just to be clear: I eval this on the repl just before load-system, and all the compiling will use it from that point on?
<pjb>
JeromeLon: that would work, too.
<pjb>
Yes.
<pjb>
optimization levels are global.
<JeromeLon>
perfect, thanks!
jans1 has joined #commonlisp
<lotuseater>
i should never answer stuff anymore :/
jans has quit [Ping timeout: 255 seconds]
jans1 is now known as jans
<pjb>
lotuseater: it's good to have different opinions!
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
makomo has quit [Quit: WeeChat 3.0.1]
<lotuseater>
pjb: i don't see it as opinion but lack or naiveness of my "knowledge"
<pjb>
lotuseater: it's by trying to answer, that you learn more.
<lotuseater>
beach advised me once more there's one thing to improve: practice!
<lotuseater>
and one learns more from failure than else
<pjb>
Of course, you may have to do some research to answer the questions.
yitzi has quit [Quit: Leaving]
<lotuseater>
that with the around compile came to my head cause i saw it in some libs
<pjb>
I don't know this option in asdf, but it's possible that it's useful, indeed.
<pjb>
Note however that there's no conforming API to inspect the optimize declaration, and not all implementations provide one.
<pjb>
So it would be hard to do an around-compile function that would save and restore the optimizations.
shka has quit [Ping timeout: 250 seconds]
scymtym has joined #commonlisp
<jcowan>
fwiw I think that skinnability has become an important part of UI design. But that can wait for OClim rather than McCLIM, I suppose.
<scymtym>
_death: sliders have a "drag callback" which is called immediately
mister_m has quit [Remote host closed the connection]
mister_m has joined #commonlisp
zacts has quit [Quit: zacts]
hineios has quit [Ping timeout: 265 seconds]
hineios has joined #commonlisp
Oladon has quit [Quit: Leaving.]
CrashTestDummy3 has joined #commonlisp
<lotuseater>
jcowan: so Oclim shall be a next version of McCLIM?
<jcowan>
Yes. Mac/Mc is a prefix to Irish and Scottish surnames originally meaning "son of", whereas "O" means "grandson/descendant of".
<lotuseater>
cool to know
CrashTestDummy2 has quit [Ping timeout: 265 seconds]
IPmonger has joined #commonlisp
<lotuseater>
one of beaches repos is also about CLIM3 as i remember
IPmonger has quit [Remote host closed the connection]
<jcowan>
My own surname is a clipped form of Irish "Mac Eoghain", son of "Eoghan", "Owen", or "John", though my father was Thomas and not John.
Inline has quit [Quit: Leaving]
<jcowan>
His father, however, wrote his name "John Cowan" but pronounced it more like "Shawn a-Cawn".
<lotuseater>
ahh
Inline has joined #commonlisp
<lotuseater>
here in germany the most common surnames are something like "Müller" or "Meier" for also historical reasons
Oladon has joined #commonlisp
<jcowan>
Yes. Germans didn't go in for patronymics for whatever reason, unlike Jews, Scandinavians, the English, and the Welsh.
<jcowan>
(exceptions being on the borders, like Ostfriesland and Holstein)
<lotuseater>
I fond it interesting that some jewish surnames are very german but one can predict they're more used in jewish families
<waleee>
jcowan: we Swedes have a mix, patronymics is lower than 50%
<lotuseater>
nice waleee you're from sweden :) a friend of mine is travelling atm there with a camper
<jcowan>
Mendelssohn is a very good example
<lotuseater>
jcowan: thx i thought about one but nothing came to my mind
<waleee>
the rest of the surnames would sound jewish in German I guess (heavily nature-inspired)
<jcowan>
Invented by Austro-Hungarian bureaucrats, who could be paid to give you better ones.
<waleee>
eg I don't think any in the Swedish soccer-team has a -son name
<waleee>
well one
<jcowan>
"So what name did you get?" "Schweisshund." "Whaaat? Didn't you pay him enough?" "My friend, you have no idea how much I had to pay for that W!"
<lotuseater>
or "Goldberg"
<lotuseater>
hahah
<lotuseater>
to your "Schweisshund"
<jcowan>
Well, wouldn't that be a mountain full of gold ore?
<lotuseater>
something like that yes
<jcowan>
Better a sweaty dog than a shitty one.
<lotuseater>
my surname is that of a german town without the last two chars, has nothing to do with each other, but sometimes useful to say for one to write it down correctly :D and also not so often which is good
<lotuseater>
look up this REALLY funny and weird town names :D
mister_m has quit [Remote host closed the connection]