<beach>
asarch: Since you have two lists, I think you may have to use INTERSECTION with some appropriate :KEY and :TEST arguments.
<beach>
asarch: Or you can loop over all elements in *users* and check each one.
<moon-child>
beach: I think intersection does not guarantee which of its inputs it uses to make the output
<moon-child>
'The result list may share cells with, or be eq to, either list-1 or list-2 if appropriate'
<beach>
moon-child: Why are you telling me this?
<asarch>
Thank you! Thank you very much! :-)
<[w]>
lol
lisp123 has quit [Remote host closed the connection]
s-liao has quit [Ping timeout: 256 seconds]
semz_ has joined #commonlisp
semz has quit [Ping timeout: 260 seconds]
waleee has quit [Ping timeout: 245 seconds]
asarch has quit [Quit: leaving]
<mfiano>
Bike: Reading the spec for *-D-C, it doesn't seem to matter which parameter I specialize in a :AFTER method, PREVIOUS, CURRENT, or both. Is this correct?
Rue has joined #commonlisp
<Bike>
i mean it depends on what you're doing, right
<Bike>
if you care about updates from one class specifically to another class you need to specialize both. if you care about updates from one class to anything you only specialize on that.
<mfiano>
I thought one is just a copy of the other, a they would both always be instances of the same direct class
<mfiano>
s/a/and/
<Bike>
No, previous is the copy, and it is a direct instance of whatever class the instance being changed used to have
<Bike>
And then current is the original, and its class is the new class
<mfiano>
Ah
<mfiano>
Ok, now it makes better than perfect sense :P
<Bike>
perfecter
s-liao has joined #commonlisp
aeth has quit [Ping timeout: 256 seconds]
aartaka has joined #commonlisp
<mfiano>
Bike: Unfortunately, this seems to have the same bad behavior as SHARED-INITIALIZE for me.
Fare has quit [Ping timeout: 256 seconds]
aeth has joined #commonlisp
Rue has quit [Quit: WeeChat 3.4]
Rue has joined #commonlisp
<Bike>
well, i mean, it's gonna be called once for each time you call change-class
<mfiano>
Right, but I'm specializing on the new class
<Bike>
so if it's being called twice, you're calling change-class twice
<mfiano>
Yet the second invocation is not for this class
<Bike>
what?
<mfiano>
Ok let me try to explain a little better
<mfiano>
The method in the above gist, should _only_ SETF those slot values to the supplied initargs when CHANGE-CLASS's NEW-CLASS-NAME argument matches that of the class I'm specializing on. In the printout, the CAR of the list in the printed represenation is that class name.
<Bike>
can you also print (class-of current) to verify that?
<mfiano>
As you can see, the second invocation, called CHANGE-CLASS with 'SRGB as the new-class-name. I want to ensure that this method is not invoked then.
<mfiano>
Sure
<mfiano>
updated gist
<Bike>
okay, so the mop stuff is not helping clarity here. im wondering if there isn't something weird going on such as the actual color-storage3 class object being used both times but its list of mixins changing.
<Bike>
like, change-class doesn't know or care about class _names_, you know?
<mfiano>
Here is the call site:
<mfiano>
updated with definition of #RGB
<mfiano>
#'RGB
<Bike>
and (find-class 'color-storage3) and (find-class 'srgb) are different things?
<mfiano>
c0/c1/c2 initargs update the instance correctly when the first mixin is added with #'MIX, but after the second one, the instance has been reset to the default state.
<Bike>
like, what you're describing here is your implementation not dispatching correctly, which is a deep enough problem that it seems unlikely
<mfiano>
Updated gist with printout of previous as well
<mfiano>
The problem is with the mixin system. I see the issue. Trying to find a solution is hard.
<mfiano>
Look at the definition of #'MIX from the gist I made in the other channel
<mfiano>
The new class is a union with the real new class prepended
<mfiano>
Which makes sense. I want to change the class to be an anonymous class containing all the previous classes as superclasses, plus the additional new class.
<mfiano>
Which makes *-D-C hard or impossible to use to do what I want here :/
cjb has quit [Quit: rcirc on GNU Emacs 29.0.50]
s-liao has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
Bike has quit [Quit: Connection closed]
mon_aaraj has joined #commonlisp
lisp123 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
s-liao has quit [Ping timeout: 256 seconds]
notzmv has quit [Ping timeout: 260 seconds]
lisp123 has quit [Ping timeout: 250 seconds]
Oladon has joined #commonlisp
Fare has joined #commonlisp
attila_lendvai has joined #commonlisp
pingpongball has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
ksu has joined #commonlisp
pingpongball has quit [Quit: Client closed]
Lord_Nightmare has quit [Ping timeout: 250 seconds]
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
attila_lendvai has quit [Ping timeout: 250 seconds]
pingpongball has joined #commonlisp
Cymew has joined #commonlisp
spiaggia has joined #commonlisp
<mfiano>
Hmm, for once I don't know if anything built-in can help me here, and I don't have any good ideas for how to do the plumbing myself.
<mfiano>
Been sitting here thinking about it for over an hour and I got nuthin
semz_ is now known as semz
Oladon has quit [Quit: Leaving.]
pranavats has left #commonlisp [Error from remote client]
Fare has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
pingpongball has quit [Quit: Client closed]
kathe has joined #commonlisp
<kathe>
good morning everyone. :)
<kathe>
off-topic coming up;
<kathe>
i use [setxkbmap -option "ctrl:swapcaps"] to swap control and caps-lock keys.
<kathe>
would anyone here know what options to pass to swap "function" and "alt" keys?
<kathe>
sorry about that, but i had no where else to go.
<moon-child>
kathe: I do not know. I expect you would be more likely to get a response in a forum dedicated to X. I will note: the 'fn' key is usually handled in firmware or similar
<kathe>
moon-child: thanks for the note about firmware.
pingpongball has joined #commonlisp
[w] has quit [Quit: zzz]
pranavats has joined #commonlisp
<mfiano>
Ok I finally see how to wipe up all this blood with the MOP
<mfiano>
Sounds like a job for tomorrow
<mrcom>
mfiano: update-instance-for-different-class is going to match as long as current is color-storage3 **or a subtype**, right?
<mfiano>
Yes. There is a bit of anonymous class MOP stuff going on that doesn't make what is going on very obvious, but yes.
<mrcom>
mfiano: Is ... (previous (current (eql color-storage3)) &key ... what you want?
Fare has joined #commonlisp
<ksu>
/part
ksu has left #commonlisp [End of Transmission Block]
<mfiano>
That isn't valid syntax. EQL value must be quoted, and I'm specifically looking for a class, not a value.
attila_lendvai has joined #commonlisp
<spiaggia>
What makes you think that EQL value must be quoted?
<mrcom>
clhs says its (eql _form_)
<mfiano>
They must evaluate to something, whether that be QUOTE or not.
<mfiano>
There is no binding cor COLOR-STORAGE3
<mfiano>
It is a symbol denoting the name of a class
<mrcom>
Oh.
<mfiano>
I sometimes use Sharpsign number to refer to values here, but that's besides the point.
pve has joined #commonlisp
<mrcom>
And _form_ is only evaluated when the method is defined.
<mfiano>
The problem here is that the new-class argument passed to CHANGE-CLASS is always going to be a an anonymous class whose direct superclasses include the previous class plus one more additional class. I would have to disassemble the direct superclass list to see which class was just added.
<mfiano>
That information is not provided explicitly to UPDATE-INSTANCE-FOR-DIFFERENT-CLASS as in normal circumstances.
<mfiano>
Basically this mixin system is creating (and memoizing when new) anonymous classes containing a list of superclasses.
<phoe>
fe[nl]ix: I'll try
<phoe>
:D
<attila_lendvai>
i wonder why i don't see many users of cffi/c2ffi... are people aware of how easy it is to generate FFI's with those tools?
<mfiano>
I would assume the answer has to do with the ultimate goal of a Lisp OS, or a pure Lisp stack for those less ambitious people.
<spiaggia>
Maybe people prefer to write Common Lisp code?
<Shinmera>
I've written a lot of wrappers and I don't like the dependencies and style of code these autogenerators produce, so I just write them by hand.
<phoe>
attila_lendvai: oh? what are they using as alternatives to cffi? implementation-specific stuff?
Fare has quit [Quit: Leaving]
<attila_lendvai>
phoe, cffi/c2ffi is a subsystem of cffi. this kinda answers my question... :) people are not aware of it
<phoe>
attila_lendvai: write a nice article describing it and post it somewhere public
Algernon69 has joined #commonlisp
<attila_lendvai>
Shinmera, cffi/c2ffi generates pretty much the exact same names as they are in the C namespace (it generates into an empty package, and even retains the upper/lower case of symbols).
<mrcom>
mfiano: Or maybe I'm not groking "no binding for color-storage3"
<attila_lendvai>
Shinmera, then you can add a foo/fancy package that lispifies it as you see fit
<phoe>
so not unlinke cl-autowrap
<phoe>
I've seen it used several times
<attila_lendvai>
phoe, yes, like cl-autowrap, but c2ffi is using clang as a lib to parse the code and extract the metadata for the FFI
<mfiano>
mrcom: There's a few solutions, that being one of them. A couple others are, checking the supplied-p argument for the initargs supplied, and also doing a doing some set theoretical operations on the direct superclass list to see exactly which class was added.
<mfiano>
I am undecided as of yet.
<phoe>
attila_lendvai: so, again, not unlike claw :D
<Shinmera>
attila_lendvai: I'm fine doing thinsg the way I am
<phoe>
Shinmera:... and yet you complained about me not using documentation-utils :(
<Shinmera>
phoe: "complain" is a bit strong of a word for my reaction there
<mrcom>
define-method-combination -- there *had* to be a usecase for it.
<mfiano>
mrcom: what do you mean about it?
<mfiano>
Of course there is
<attila_lendvai>
phoe, didn't know about claw, it looks like something very similar. sadly, cffi/c2ffi predates it by several years, feels like duplicate effort.
<mrcom>
Custom combination that bases match against class equality rather than subtype matching
<Shinmera>
does c2ffi work well with C++?
<mfiano>
No
<mfiano>
That's what claw tries to solve, with a C shim
<mfiano>
Also c2ffi/autowrap author left Lisp a few years ago
<attila_lendvai>
Shinmera, not sure, i never looked into wrapping C++ libs. it does deal with #define macros properly.
<Shinmera>
there you go then.
<mrcom>
Random question: Anybody familiar with J.A.R Williams? My wife knew a "Dr. JAR", but as an artist. Same person?
<attila_lendvai>
whatever can be done for wrapping C++, c2ffi and the cffi/c2ffi infrastructure is fully qualified to be a comfortable framework for it.
vegai has left #commonlisp [#commonlisp]
notzmv has joined #commonlisp
<Shinmera>
Idunno man I feel like if someone embarks on the journey of writing something like claw they'd have already checked c2ffi and deemed it not usable enough.
<phoe>
borodust: I'm curious about c2ffi now
kathe has quit [Quit: Leaving]
<attila_lendvai>
Shinmera, your imagination is rather constrained then. claw seems to be a fun project (looks like it does the c2ffi part also in CL). i can easily see myself embarking on that project 20 years ago, regardless of what else is available.
<Shinmera>
...
<Shinmera>
whatever you say bro
<attila_lendvai>
luis, do you think it's appropriate to mention claw in the CFFI readme?
MajorBiscuit has joined #commonlisp
Algernon91 has joined #commonlisp
artchad has joined #commonlisp
spiaggia has quit [Quit: ERC (IRC client for Emacs 26.3)]
Algernon69 has quit [Ping timeout: 256 seconds]
shka has joined #commonlisp
silasfox has joined #commonlisp
kagevf_ has quit [Ping timeout: 240 seconds]
wacki has joined #commonlisp
artchad has quit [Read error: Connection reset by peer]
<attila_lendvai>
any ideas what else the CFFI readme should mention besides claw and cl-autowrap?
aartaka has quit [Ping timeout: 256 seconds]
<phoe>
I think that c2ffi, claw, and cl-autowrap are the prominent wrapping libs
<mfiano>
"It is best to write a pure Lisp solution before considering this library"
<phoe>
:D
silasfox has quit [Quit: WeeChat 3.4]
<attila_lendvai>
considering that each of us only has a limited time on earth, that is so much not true...
<attila_lendvai>
let alone when a project has no specification, and the only "API" is a binary blob...
terrorjack5 has joined #commonlisp
copec has quit [Ping timeout: 268 seconds]
antoszka has quit [Ping timeout: 268 seconds]
antoszka has joined #commonlisp
froggey has quit [Remote host closed the connection]
copec has joined #commonlisp
<mfiano>
As Lisp programmers, we are paving the way for future generations to stand on our shoulders. Let's leave the footguns and bitrot where they belong.
pingpongball has quit [Quit: Client closed]
Arcsech has quit [Ping timeout: 268 seconds]
nworb has quit [Ping timeout: 268 seconds]
loke[m] has quit [Ping timeout: 268 seconds]
linjian has quit [Ping timeout: 268 seconds]
Duuqnd has quit [Ping timeout: 268 seconds]
prov[m] has quit [Ping timeout: 268 seconds]
opalvaults[m] has quit [Ping timeout: 268 seconds]
mgxm_ has joined #commonlisp
froggey has joined #commonlisp
dieggsy has quit [Ping timeout: 268 seconds]
terrorjack has quit [Ping timeout: 268 seconds]
mgxm has quit [Ping timeout: 268 seconds]
|smlckz| has quit [Ping timeout: 268 seconds]
easye has quit [Ping timeout: 268 seconds]
lieven has quit [Ping timeout: 268 seconds]
terrorjack5 is now known as terrorjack
lieven has joined #commonlisp
Arcsech has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #commonlisp
froggey has quit [Read error: Connection reset by peer]
froggey has joined #commonlisp
cosimone has joined #commonlisp
artchad has joined #commonlisp
prov[m] has joined #commonlisp
|smlckz| has joined #commonlisp
cosimone has quit [Ping timeout: 260 seconds]
loke[m] has joined #commonlisp
<borodust>
phoe: in the beginning of times, :claw was using c2ffi and actually started as a fork of cl-autowrap with https://github.com/rpav/cl-autowrap/pull/83 merged (it was named bodge-autowrap at the time)
<attila_lendvai>
hi borodust! you may want to mention that blog post in the claw readme.
* attila_lendvai
is revising the CFFI Readme
dieggsy has joined #commonlisp
<borodust>
once i was deep in wrapping C++, another feature bubbled up that required patching (or extending, i should say) of llvm/clang so i ended up with custom llvm/clang xD
<borodust>
but i dream someday i push that patch upstream, it's straightforward, just exposes more of C++ features through libclang C interface
<borodust>
attila_lendvai: my another dream is writing :claw documentation :D it's too early to mention or promote it anywhere
<phoe>
borodust: thanks!
<borodust>
atm i'm working on super secret project that showcases in a useful way what can be done with alien-works (framework based on C/C++ foundation glued to lisp with :claw), then i'll go back to :claw release plans
<borodust>
i wanted to do that before ELS hits, but i guess that was a bit too optimistic
<borodust>
for historians, previous claw repository is here: https://github.com/borodust/claw-legacy there you can see the rich history it has that goes back to cl-autowrap and c2ffi ;p
<attila_lendvai>
borodust, does that mean that i shouldn't mention claw in the CFFI readme? or with a word that it's beta?
<borodust>
heh, master branch still uses c2fii
<borodust>
attila_lendvai: i think, it's better not to link it yet
aartaka has joined #commonlisp
s-liao has joined #commonlisp
lispy has joined #commonlisp
occ has quit [Ping timeout: 256 seconds]
<lisp123w>
phoe: Your suggestion on LW HUG is interesting. The downside is if things break on LW, people will invariably complain to LW and they may not want to deal with that
<phoe>
lisp123w: break on LW, what do you mean? if a library breaks on LW, then the first question is whether the library itself is OK
<phoe>
and if the library itself is OK, then the question is whether the LW CI edition is used correctly
<lisp123w>
They are already relatively hands off because they have limited time and spending on paid projects (I dare not ask them for help)
<phoe>
and if it is used correctly, it means that LW gets a decent bugticket
<phoe>
yes, I can imagine - that's why I asked about feasibility from the business point of view
<lisp123w>
Break in the sense, there is something in LW that isn't ANSI compliant / different to how other implementatiosn do it
<phoe>
well, they can mark it as WONTFIX in the worst case, and then compatibility libraries can try to work around this quirk
<phoe>
the real question is about discovering these quirks in the first place in LW as it is right now
<lisp123w>
It would be net beneficial for LW users to have better tested libraries for their implementation
<phoe>
yes, that's my main point
<lisp123w>
unrelated, but we should do a crowd funding to get Clozure Associates to build a Cocoa Backend for CLIM...
<lisp123w>
(I think Clozure Associates did most of the GUI work for LW for Mac, they are the experts in that area)
<phoe>
lisp123w: that could be done, I guess - try contacting them about the idea and open a fundraiser somewhere if they're interested
ski has quit [Ping timeout: 250 seconds]
phantomics has quit [Excess Flood]
pingpongball has joined #commonlisp
phantomics has joined #commonlisp
conjunctive has quit [Ping timeout: 260 seconds]
ski has joined #commonlisp
conjunctive has joined #commonlisp
karlosz has quit [Quit: karlosz]
pingpongball has quit [Client Quit]
victor_ has quit [Ping timeout: 250 seconds]
blacked has joined #commonlisp
victor_ has joined #commonlisp
notzmv has quit [Ping timeout: 250 seconds]
<phoe>
minor announcement: CLISP installable via `ros install clisp-head` has working and somewhat tested package-local nicknames now
drmeister has quit [Ping timeout: 245 seconds]
drmeister has joined #commonlisp
IUSR has quit [Ping timeout: 250 seconds]
<phoe>
at least on Linux, I'm working out the OSX stuff with roswell maintainers
IUSR has joined #commonlisp
<lisp123w>
Hurray for CLISP
<lisp123w>
I reached out to Clozure, expect it to way too expensive (if they are interested at all), but you never know if you never ask :)
<phoe>
OK
<beach>
You could also ask Turtleware.
occ has joined #commonlisp
<lisp123w>
beach: I'll do that too
kathe has joined #commonlisp
<kathe>
hello again. :)
<kathe>
is phoe around at the moment?
<phoe>
kathe: I'll check
<phoe>
yes, he seems to be
<kathe>
:D
<kathe>
phoe: have you had time to give serious thought to a mop+clos book after you're through with the current one?
<phoe>
kathe: thought, yes; realization, it'll need to wait until 2023 at least
<phoe>
CLR2 must take priority
<kathe>
phoe: that's great news. i'll eagerly await the mop+clos book. :)
<phoe>
note that this isn't a commitment
<kathe>
yes. i acknowledge. :)
<phoe>
just a note that such a thing will start in 2023 or later
<kathe>
but the mere thought that it "might be" a possibility is exciting enough. :)
<phoe>
and then will take time to get finished!
<kathe>
i am assuming "if" you take it up, you might finish it by 2026~2027.
<kathe>
anyone here has worked through the algorithms book by domkin?
<kathe>
also, what is the real intent behind 'paip'? it can't be just 'ai'!
<blacked>
In defining like some default parameter for keyed function, why we give like this `((:c 10))`?
<blacked>
Like for this (defun foo (&key a b ((:c 10))) (format nil ": ~d\n :~d\n :~d " a b c) )
<kathe>
cursory reading leads me to think 'paip' teaches good programming "practice".
<lisp123w>
kathe: Less reading / discussing CL, and more writing CL would be a suggestion
<kathe>
would that assumption be correct.
<kathe>
lisp123w: i am working towards all those slowly.
<phoe>
blacked: lambda lists require &key to be present for keyword parameters
<phoe>
oh wait, you're asking a different thing
<kathe>
lisp123w: that's why i'm here only occasionally.
<phoe>
why doesn't (&key (c 10)) work?
<lisp123w>
kathe: That's great to hear :)
<kathe>
lisp123w: reason to ask about 'paip' is that's it's so huge and requires some knowledge of calculus (which i've forgotten).
<phoe>
blacked: &key ((foo bar)) means a different thing - it separates the keyword parameter that becomes the API from the variable name that is used internally
<phoe>
see e.g. (defun foo (&key ((:bar baz) nil barp)) (list baz barp))
<phoe>
and then (foo :bar 42)
<blacked>
aumm i'll understand it :/
<phoe>
blacked: okay, a little bit more detail then
<phoe>
(&key c) defines a keyword parameter that is accessible like (... :c ...)
<phoe>
(&key (c 42)) adds a default value for it, 42
<phoe>
(&key (c 42 c-provided-p)) adds another boolean variable that is true only if :C is provided, and false otherwise
<lisp123w>
kathe: I'm reading PAIP now as my fingers hurt and I need to take a break. I think its a luxury in 2022, so would recommend working on actual projects & reading PCL if you need particular details on CL
<lisp123w>
One learns more from their own mistakes, so best not get caught in a 'paralysis by analysis' trap and get coding :)
<kathe>
lisp123w: i agree. thanks for remind me. :)
<blacked>
:) @phoe thanks , @lisp123w right.
<phoe>
blacked: in all of the above cases, C is both the variable name and the source for the name of the generated keyword, :C
<blacked>
yes i understand, i think practicing will fit it more
<phoe>
and you can separate these by wrapping C in another pair of parenthesis and providing both the symbol that will name the keyword argument and the variable that's used internally
<phoe>
(&key ((:c c))) is equivalent to (&key (c)) is equivalent to (&key c)
<phoe>
but you can do (&key ((:some-really-long-keyword c) ...)) to have a long API keyword and a shorter variable name for use in the function body
<phoe>
which is a niche use case, but nonetheless useful sometimes
<lisp123w>
kathe: As an example, PAIP introduced the concept of data driven programming in Chapter 2, where the rules of an algorithm are separated out away from hardcoded conditional statements like COND and stored as data. A great idea, but one that I uncovered myself from trial and error so when I read it, it makes much more sense / sticks with me longer as I have gone through the pain of changing hardcoded functions in the past.
<kathe>
lisp123w: okay.
<kathe>
gotta go now. bye all.
kathe has quit [Quit: Leaving]
<lisp123w>
Ah he left. Was going to say: 'Dang' from Hacker News had a great quote, which I paraphrase: There's a natural balance between simple, ugly code and elegant, well abstracted code - start off by writing whatever comes to mind, and as you start repeating yourself, you will naturally start abstracting away, coming up with a better approach
s-liao has joined #commonlisp
<lisp123w>
I find that helped me a lot, because CL can have too much expressivity at times so one gets stuck trying to find the perfect solution. I'll shut up now :)
<phoe>
they say, make it work, make it right, make it fast
<phoe>
the fourth step I love to add is, make it beautiful
<phoe>
yes, CLOS (Common Lisp Object System) is pretty powerful
<splittist_>
and putting the operator first allows multiple operands (* one-number another-number yet -another-number-without-repeating-the-operator)
<phoe>
the first difference you'll see compared to C++/Java/similar OOP systems is that classes don't have methods, generic functions have methods
<phoe>
and that allows for easy multiple dispatch
<blacked>
whoa. i heard that multiple dispatch system , when i was learning julia
<blacked>
later left julia, and learning this if i get some interest :)
domovod has quit [Ping timeout: 260 seconds]
<blacked>
phoe, "classes dont have method" cool, in CLOS, :) i'll be there soon
<phoe>
blacked: sure; this channel can get busy at times, #clschool is a good place to ask more basic questions all the time though
domovod has joined #commonlisp
<blacked>
ok :)
euandreh has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
Lord_of_Life has quit [Ping timeout: 256 seconds]
Lord_of_Life_ has joined #commonlisp
mon_aaraj has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
molson__ has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
blacked has quit [Remote host closed the connection]
Alfr has quit [Ping timeout: 240 seconds]
lispy has quit [Quit: O/]
OlCe has joined #commonlisp
Algernon91 has quit [Ping timeout: 245 seconds]
aartaka has quit [Ping timeout: 256 seconds]
xsperry has joined #commonlisp
rotateq has joined #commonlisp
random-nick has joined #commonlisp
kevingal has joined #commonlisp
kevingal has quit [Ping timeout: 256 seconds]
kevingal has joined #commonlisp
scymtym has quit [Remote host closed the connection]
Brucio-92 has quit [Remote host closed the connection]
dlowe has joined #commonlisp
lisp123 has joined #commonlisp
<artchad>
borodust, I found a neat way to separate my own project, from projects I've pulled from the internet.
igemnace has quit [Quit: WeeChat 3.4]
mon_aaraj has quit [Ping timeout: 256 seconds]
<artchad>
I just symlinked ~/Common-Lisp to ~/.local/share/common-lisp/source . There I put all the downloaded projects, which I load via asdf. In ~/quicklisp/localprojects I'll keep my own personal projects.
<artchad>
I still have to test how it works though.
mon_aaraj has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
OlCe has quit [Ping timeout: 256 seconds]
dec0d3r has joined #commonlisp
scymtym has joined #commonlisp
notzmv has joined #commonlisp
occ has quit [Ping timeout: 256 seconds]
<artchad>
Oh, actually I can just quickload them, because quicklisp seems to use asdf:*central-registry*
<artchad>
I came up with thise solution. I just call this function whenever I want the downloaded projects to be visible.
<artchad>
Is there a smarter way of managing your local projects and downloaded projects separately?
Brucio-4 has joined #commonlisp
occ has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
<artchad>
sm2n: I tried compiling you :scanner project, but I get the following error:
<artchad>
COMPILE-FILE-ERROR while compiling #<cl-source-file "quicklisp" "package">.
<artchad>
;;; ** Unable to find include directoryAn error occurred during initialization:
<artchad>
Could you help me with that. I would love to have a nicer interface for scanimage. Currently I'm using shell scripts, which is kinda meh.
OlCe has joined #commonlisp
OlCe has quit [Ping timeout: 256 seconds]
azimut_ has quit [Remote host closed the connection]
azimut has joined #commonlisp
aartaka has joined #commonlisp
Algernon91 has joined #commonlisp
lispy has joined #commonlisp
s-liao has joined #commonlisp
s-liao has quit [Client Quit]
s-liao has joined #commonlisp
tyson2 has joined #commonlisp
s-liao has quit [Client Quit]
pranavats has left #commonlisp [Error from remote client]
MajorBiscuit has quit [Quit: WeeChat 3.4]
igemnace has joined #commonlisp
lisp123 has joined #commonlisp
MajorBiscuit has joined #commonlisp
pranavats has joined #commonlisp
lisp123w has left #commonlisp [ERC (IRC client for Emacs 26.3)]
lisp123 has quit [Ping timeout: 256 seconds]
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
dec0d3r has quit [Quit: Leaving]
dickbar__ has joined #commonlisp
Bike has joined #commonlisp
waleee has joined #commonlisp
<borodust>
artchad: 👍whatever works best for you works best for you
<artchad>
I think I've solved the issue in an ok way.
<artchad>
I can just call (add-asdf-dirs) and they will be available.
<artchad>
interesting is that asdf:*central-registry* doesn't include ~/.local/share/common-lisp/source nor ~/common-lisp by default.
<artchad>
although the docs say that those directories will be checked.
<Bike>
the asdf central registry is only a backwards compatibility thing. you're supposed to use the newer config mechanism now, and that's what asdf uses for those directories probably
<artchad>
what's the "newer mechanism"?
<artchad>
I didn't thoroughly read the documentation.
<artchad>
That looks complicated. I'll stick to my tape code. hehehe
MajorBiscuit has joined #commonlisp
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #commonlisp
<Josh_2>
Good afternoon
jeosol has quit [Ping timeout: 256 seconds]
aartaka has quit [Ping timeout: 268 seconds]
<artchad>
good afternoon fellow big brained programmer
<White_Flame>
artchad: most people use quicklisp nowadays, and symlink their project trees from ~/quicklisp/local-projects/ to make them visible
<White_Flame>
(well most people use quicklisp. not that necessarily most people use its local-projects dir over asdf)
<White_Flame>
but it uses that filesystem artifact to maintain their default visibly loadable projects
<artchad>
but localprojects is loaded before dists
<artchad>
that caused issues for me already a few times.
<artchad>
it's a waste to time to try and figure out why something failed, just to realize that a system in local-projects contains a system with the same name, as the one pulled from quicklisp prior.
<artchad>
that's why I'm making sure all the things I clone go into a separate directory, which is not visible by default
<artchad>
only when I start a repl and explicitly want to play around with someone elses code, then I make sure quicklisp can find it.
<frgo>
Hi guys. I have been away a bit - so please excuse me jumping right to an issue I couldn't resolve for the last couple of days: c2ffi on ARM64. I am trying to build cl-sdl2 and it fails misrably on my NVIDIA Jetson Xavier NX (being an ARM64 6-core CPU). Anybody here with experience c2ffi on ARM64?
<White_Flame>
artchad: ah, ok. I have some loader scripts in my .sbclrc as well, for pulling in things with their own static libraries
Posterdati has quit [Read error: Connection reset by peer]
<artchad>
or do you think that's something c2ffi specific?
<frgo>
artchad: Thx. Well, that's part of the mystery. Is it c2ffi, or clang or ?
<frgo>
mfiano is the maintainer of cl-sdl2, so I'll try to contact him.
<phoe>
this actually seems like a problem in the arm_neon sources of clang
<phoe>
like, the real error seems to be in /usr/lib/llvm-12/lib/clang/12.0.0/include/arm_neon.h:1730:47 and not anything that includes that file
Posterdati has joined #commonlisp
<frgo>
phoe: Yes, agreed. Maybe worth trying plain old gcc... I am digging deeper.
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
morganw has joined #commonlisp
Xach has quit [Ping timeout: 268 seconds]
Xach has joined #commonlisp
<frgo>
Yeah, well - GCC. No. c2ffi is clang=based. Silly me.
aartaka has joined #commonlisp
Xach has quit [Changing host]
Xach has joined #commonlisp
treflip has joined #commonlisp
aeth has quit [Ping timeout: 256 seconds]
<_death>
frgo: I don't use this architecture, but vector operations table at https://clang.llvm.org/docs/LanguageExtensions.html seems to suggest that clang does not support C-style cast for neon vector types
Algernon91 has quit [Read error: Connection reset by peer]
Algernon91 has joined #commonlisp
wyrd has quit [Remote host closed the connection]
wyrd has joined #commonlisp
jeosol has joined #commonlisp
Algernon91 has quit [Ping timeout: 268 seconds]
<phoe>
SAL9000: that's dumping a literal function into a FASL
<phoe>
might not work
<phoe>
in particular functions are not externalizable
<Bike>
i don't think dumping functions works on any implementation. i would be interested if one could do it
<phoe>
again, you could try to (load-time-value (lambda () v)) to work around this problem, but, sike, we are using load-time-value
<SAL9000>
good point, I didn't think about fasl
<phoe>
which is the problem we started with
<SAL9000>
I guess you're back to gensym + hashtable then :<
<SAL9000>
trivial-load-time-value?
<phoe>
Bike: pure functions should be dumpable fine, closures would be the real pain
<White_Flame>
well, there can be pure closures, too
<phoe>
yes, but then there are things like (let (x) (lambda () x) (lambda (y) (setf x y)))
<phoe>
you can't really dump one without the other
<Bike>
phoe: translating a runtime function object into a description of a function object is nontrivial
<White_Flame>
right, that's a mutating closure
<Bike>
plausibly doable, but nontrivial
<phoe>
right
<Bike>
you also have constants to worry about, for instance
<phoe>
why worry? they are supposed to never change™
<White_Flame>
as they say in math, variables don't, and constants aren't ;)
<Bike>
i mean, they could themselves not be dumpable
<SAL9000>
but hey at least we aren't in bizarro C++ land, where const doesn't always mean constant (i.e. const qualifier on pointers)
<phoe>
oh - right
<White_Flame>
SAL9000: you just need a constception, const * const * const int
<SAL9000>
*shudder*
<Bike>
constants could also influence dumpability in weird ways. like, if you have (lambda () (if t 0 #.(non-externalizable-object))), whether that could hypothetically be dumped depends on how much optimization the compiler does.
<Bike>
though that's also true with some closures.
<borodust>
frgo: generally speaking though, most of SDL2 is fairly portable, so you can take any bindings and use them
<borodust>
unless you want to access very OS-specific parts of SDL2
<borodust>
btw, those are bindings generated by :claw ;p
<frgo>
borodust: Ho ho - cool! Thx for the pointer. Yes, I am interested in the bindings.
mayuresh has joined #commonlisp
<mayuresh>
good morning everyone. :)
<borodust>
so, what i mean, you can take cl-sdl2, rename one of the .json (linux one to be more or less safe) to the architecture of yours and be done with it
kevingal has quit [Ping timeout: 250 seconds]
<frgo>
borodust: Yep, thx. That's clear.
<frgo>
So, for the record: _death 's advice worked. I will compare results with the android output.
<borodust>
ahh, i guess, i need to read better next time, i thought there's a problem with c2ffi
<phoe>
I assume it survives garbage collection if the symbol is used inside BODY
occ has joined #commonlisp
Rue has quit [Quit: WeeChat 3.4]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
Rue has joined #commonlisp
lisp123 has joined #commonlisp
<sm2n>
artchad: what did you do?
<jasom>
phoe: it should, otherwise macros using gensym wouldn't work
<phoe>
jasom: yes
<phoe>
thanks!
<jasom>
biggest downside is you can't declare the type of it; some magic with cl:the might let you get around it
<artchad>
sm2n: I just ran the build script.
<artchad>
installed ecl and ran the build script.
<sm2n>
you have quicklisp installed?
<sm2n>
wait, it says "unable to find include directory"... how did you install ecl?
silasfox has quit [Quit: WeeChat 3.4]
<sm2n>
if you look at the .build.yml it lists all the dependencies needed on alpine linux
<sm2n>
alpine doesn't make all the dependencies for ecl necessary for building as necessary dependencies by default
<sm2n>
so I think that may be your issue if you are on a similar distro
<sm2n>
remember that ecl needs a C compiler to work
<sm2n>
(Also, the only reason I used ecl is because I was running it on a very old raspberry pi short on ram, feel free to try another implementation, everything but the build scripts should be portable, and I developed on sbcl)
<artchad>
sbcl --script should work right?
<artchad>
I'll try that.
<sm2n>
you would need to call main, but yes
<artchad>
yeah, ok, now the error comes from lisp. progress is being made.
<artchad>
Symbol "MAKE-BUILD" not found in the ASDF/INTERFACE package.
<sm2n>
oh, as I said, the build.lisp is ecl-specific
<sm2n>
I don't have build support for anything but sbcl right now
<artchad>
I'm figuring out right now.
<sm2n>
make-build is an ecl extension to asdf
<artchad>
oh
<artchad>
rip
<sm2n>
err
<artchad>
maybe I could use that save-lisp-and-die thing
<sm2n>
s/for anything but sbcl/for anything but ecl/
<sm2n>
yeah, that would be what you want
mon_aaraj has joined #commonlisp
<sm2n>
something like (progn (ql:quickload :scanner) (save-lisp-and-die "scanner" :toplevel #'scanner:main :executable t)) I think
<sm2n>
won't work in progn actually, because scanner package doesn't exist yet
<sm2n>
but as separate toplevel forms should be fine
<artchad>
ok, that worked
<artchad>
just had to (export #:main) inside package.lisp.
<sm2n>
ah, right
<artchad>
ye, I didn't see the point of the progn, so I just didn't use it.
<sm2n>
hmm, main returns instantly so I think it will just immediately close
<sm2n>
you probably have to write a function like I have in build.lisp
<sm2n>
with bt:join-thread
<yottabyte>
how can I check if every element in a list is in another list? I know I can iterate over the list and do find, but I imagine there's a simpler way
<artchad>
I got an internal server error when I tried to scan an image with 300DPI color.
<artchad>
hmm
<artchad>
then I would have to get the main thread and remove that element from the list
<sm2n>
hmm? I thought I fixed that, maybe I forgot to push it?
<sm2n>
artchad: that's what REMOVE would do
<Bike>
besides the fact that trying to join all threads might be weird if some library you don't expect made threads, this isn't totally safe, since it's possible another thread gets created just after all-threads returns.
<sm2n>
Bike: right, but in this case we know only hunchentoot is running
<fe[nl]ix>
trying to join with (bt:all-threads) is not going to work
<fe[nl]ix>
if anything, because you end up joining with the thread running the REPL
<sm2n>
fe[nl]ix: What would you suggest? (It does seem to work in this case, but hunchentoot uses bordeaux-threads under the hood and it's the only thing running, so that may be why)
<Josh_2>
What thread are you trying to join?
<Josh_2>
The hunchentoot one?
<sm2n>
yeah, the usecase is that an executable is produced, and it only has hunchentoot in it, but the hunchentoot event loop isn't on the main thread, so without some way of blocking, the application just immediately closes
<White_Flame>
you could also use alexandria's plist-to-alist
<White_Flame>
*plist-alist
<lisp123>
White_Flame: Pairlis would be the same as the first one no?
<White_Flame>
ah I guss so
<Josh_2>
sm2n: there is also a means for exiting correctly, on sbcl I believe its a list @ sb-ext:*exit-hooks*
<White_Flame>
it's also not hard to have a LOOP construct grab 2 elements at a time
* artchad
fiddling around with udev rules
<White_Flame>
(loop for (k v) on '(k v k v ...) by #'cddr collect (cons k v))
<sm2n>
Josh_2: oh, hmm, I'm not sure that's actually better
<sm2n>
the sbcl manual says that thread spawning is prevented _after_*exit-hooks* are run
<sm2n>
so you still have the same issue
<Josh_2>
The previous link I used is how I handle deployed executables with SBCL
etiago- has quit [Ping timeout: 240 seconds]
<Josh_2>
I have many websites that use the method listed in the cookbook
etiago has joined #commonlisp
lispy has quit [Remote host closed the connection]
<sm2n>
I'm not saying it doesn't work, I'm just saying I don't think that's theoretically clean in all cases either
<sm2n>
(using *exit-hooks*)
<Josh_2>
exit-hooks is for when the executable is told to shutdown by a init system
<Josh_2>
I just thought it would be useful to share
<Josh_2>
the executable shutting down immediately is solved by searching for a thread named hunchentoot and joining it
<sm2n>
yeah, I understand
<lisp123>
White_Flame: thanks for that
<White_Flame>
or (loop while list collect (cons (pop list) (pop list)))
<lisp123>
that one is best <3
<White_Flame>
I noticed that plist-alist does nreverse at the end. I like how COLLECT avoids that
<lisp123>
I did something similar with a recursive function, but that rads much better
<White_Flame>
right, for (k v) traverses 2 elements in, and then by #'cddr re-traverses 2 elements redundantly
<lisp123>
I'm anti-alexandria, everyone should write their own functions (or copy from others on IRC :D)
<White_Flame>
eh, I've been moving to alexandria, though I still have my utils lib
<White_Flame>
just there's been a lot of overlap
<lisp123>
Yeah I assume Alexandria covers a lot of common utils functions
karlosz has quit [Quit: karlosz]
mister_m` is now known as mister_m
dlowe[x] has joined #commonlisp
<dlowe[x]>
I have a question about lparallel on sbcl - let's say I set up a bunch of tasks (> number of workes) each calling cl:read-line on a socket stream. Can it successfully negotiate all the I/O or is it going to block weirdly?
dlowe[x] has joined #commonlisp
dlowe[x] has quit [Changing host]
<sm2n>
huh, Josh_2, that is apparently not reliable on ecl
<sm2n>
I think bt:thread-name is returning a symbol in some case
<sm2n>
yup
<sm2n>
fe[nl]ix: is that supposed to happen?
<jasom>
phoe: A new static-let that I *think* is more efficient, and also lets you specify the type. Modifying it to instead parse declarations for the &body form to set the type is an exercise left up to the reader: https://plaster.tymoon.eu/view/2908#2908
jealousmonk has joined #commonlisp
<Bike>
maybe you should have (the ,type ,init) instead of just ,init for the initial set
lisp123 has quit [Remote host closed the connection]
jealousmonk has quit [Remote host closed the connection]
jealousmonk has joined #commonlisp
dlowe[x] has quit [Remote host closed the connection]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<phoe>
locally special? hmmmm
<phoe>
I actualy want to figure out what kinds of assembly all these compile into
<phoe>
jasom: I've posted both in the serapeum issue, thank you
<phoe>
(along with Bike's suggestion)
<yottabyte>
suddenly, I'm getting these errors in emacs: Debugger entered--Lisp error: (void-function ql:quickload), any idea what's going on?
rain3 has joined #commonlisp
<yottabyte>
I'm doing C-x C-e to run the current line (I do this all the time in slime)
<Bike>
yottabyte: that is the error you would get if you tried to evaluate (ql:quickload whatever) in elisp.
<Bike>
make sure you're in slime mode
<yottabyte>
that did the trick... don't know how I entered elisp mode
<yottabyte>
up until now, whenever I opened a .lisp file, it was using slime-mode and sbcl, etc.
<Guest74>
EdLangley[m]: That doesn't work for me. I don't want to load every colour library in existence just to provide support for the one colour library the user is using.
lisp123 has joined #commonlisp
<Guest74>
hm, all the scanner talk has reminded me I haven't submitted my networked sane lib to quicklisp.
<EdLangley[m]>
Guest74: none of my suggestions were “load every colour library in existence”
<Guest74>
Xach: What's the procedure to submit a library? The quicklisp.org website's front page hasn't been updated since 2016.
<Bike>
you submit an issue on github
<lagash>
Guest74: sane? like, printing? or was that scanning?
<Xach>
Guest74: you can submit an issue on github, or send an email if you like.
<Guest74>
Ed: to define a method the colour library has to be loaded.
<sm2n>
Guest74: What does your library do?
<sm2n>
(the SANE one)
<EdLangley[m]>
Guest74: yes, and my suggestions all involved defining multiple systems, each of which only depends on one colour library
<EdLangley[m]>
So the user just loads the system my-system/colour-library
lisp123 has quit [Ping timeout: 240 seconds]
<EdLangley[m]>
Or you use ASDF-SYSTEM-CONNECTIONS to solve the problem
<Guest74>
lagash: sm2n: it's a backend for scanning over the network. I use it to scan on my local scanner so I don't have to touch foreign stuff, it's all lisp.
<Xach>
EdLangley[m]: asdf-system-connections introduces problems also, at least for quicklisp
<Guest74>
Ed: you said so that one library would load them all, Perhaps I misinterpreted. Anyways, I hate slashes in package names.
<sm2n>
Guest74: Nice
<sm2n>
Unrelatedly, I would also recommend my-system/colour-library
<EdLangley[m]>
Guest74: for better or worse, ASDF has decided that sub-packages use slashes
<EdLangley[m]>
You can do multiple .asd files to workaround this.
<Guest74>
nope, won't do it. I dislike it extremely.
<Guest74>
sm2n: I should mention it's only the implementation of the protocol. My frontend for it isn't in a finished state. Works fine at the repl though.
<sm2n>
I see, is the repo public?
<sm2n>
artchad: I added sbcl build support, and should've fixed the issue you had.
<artchad>
which issue concretely?
<sm2n>
"internal server error"
<Guest74>
https://github.com/JMC-design/nsane I should probably add links to how to actually get sane to serve a scanner over the network. I swear that was the hardest part of writing it.
<sm2n>
Right, that's why I gave up and wrote a webapp :)
<Guest74>
Xach: so issue under quicklisp-client? I ask because I don't see any such issues, i guess you delete them? I wonder why this isn't written anywhere.
<Guest74>
sorry, there was a flurry of posting and I didn't see it.
<Bike>
not a problem
<etimmons>
Xach: what issues does asdf-system-connections present for quicklisp?
scymtym_ has joined #commonlisp
shka has quit [Ping timeout: 256 seconds]
Brucio-4 has quit [Ping timeout: 268 seconds]
scymtym has quit [Ping timeout: 250 seconds]
<_death>
etimmons: I guess because it uses asdf to load the system, rather than quicklisp, so if the project is not yet installed you'd get an error
<etimmons>
_death: That sounds reasonable
<_death>
etimmons: thinking about it some more, I think the case could be that you have A and B that are installed (as well as their dependencies), and you load project C.. C notices A and B are loaded and tries to load C-AB, but then C-AB depends on D which may not be installed.. if that's the issue quicklisp could probably know about C-AB and install the dependencies, but then it assumes A, B, and C-AB will be used, which is not certain
epony has quit [Quit: QUIT]
<phoe>
quicklisp could work around it by assuming that A, B, and C-AB *might* be used, and downloading all of them
<phoe>
but that's the difference between "will" and "might"
pranavats has joined #commonlisp
<_death>
phoe: that's what I meant
<phoe>
OK, I understood you well then :D
<etimmons>
That all makes sense. I'd also be interested if there any any specific issues that crop up when building the dist (i.e., figuring out what triggers C-AB to be loaded)
<phoe>
I don't think Quicklisp has that sort of information, or can easily get it without also parsing system-connections stuff
<phoe>
in case of ASDF's :depends-on, things are very simple
<_death>
maybe it's also possible to add a hook to asdf-system-connections to do that
<_death>
or even to asdf
<etimmons>
I ask partly because this issue comes up fairly regularly and the existing solution is rather nasty. So I wonder what a nice way of doing it would look like
<phoe>
so that it automatically augments the loaded systems' depends-on? or uses ASDF's kinda-deprecated :weakly-depends-on?
<etimmons>
And am trying to figure out all the issues with asdf-system-connections
<_death>
with a hook you wouldn't need to perform any static analysis
<etimmons>
I think weakly-depends-on is slightly different, IIRC
<EdLangley[m]>
Asdf-system-connections works, iirc, by adding a system and an :after method to operate
<_death>
such analysis wouldn't help you much anyway
<EdLangley[m]>
When a system is loaded, the after method checks if the prerequisites of any connections are met and then loads the system in the connection.
<Guest74>
Which all makes it so much easier to tell the user if you want to use colours from some-library just load mylibrary-some-library first. Just kick that responsibility down the road.
<EdLangley[m]>
Although, it’s been a while since I’ve looked into this.
<EdLangley[m]>
IMO, ASDF should provide this functionality
<etimmons>
asdf-system-connections adds an after method on (operate t t)
<etimmons>
which is, ugh
<EdLangley[m]>
Yeah, that’s what I said :)
<EdLangley[m]>
That’s necessary for it to work
<EdLangley[m]>
But also, shouldn’t be done by something that’s not part of ASDF
<etimmons>
Yeah, I was just clarifying its method isn't specialized on anything.
<etimmons>
And yes, I think ASDF should provide this functionality too
<EdLangley[m]>
I sort of prototyped a solution that involved adding an emacs-like hook feature to ASDF
<EdLangley[m]>
ASDF, in general, is annoyingly opaque when it comes to introspection: a lot of the classes and operations it defines contain no information about the operation being performed.
gaqwas has joined #commonlisp
<jeosol>
Good morning guys
<jeosol>
Could use some brainstorming and get some advice. I have e functions I call in sequence fa() - prepare input file, fb() - run simulation, fb() - read results. fa() and fb() are very fast, but fb() is compute intensive can take 3 seconds, 30mins, 1 hour depend on input.
<jeosol>
I am trying to run everything on remote machine when need to get some progress back. If I run everything in blocking mode, it works fine, but I don't know what stage fb() is at.
<jeosol>
I have now instrumented the code to run fb() in background and then I send request to check the status of the log file which reports back the progress of the computation (e.g., time step in finite difference simulation)
cjb has joined #commonlisp
<jeosol>
My setup up works, then craps out for long jobs (socket closed, etc) - trying to rethink if there is a less problematic and cleaner way to set this up.
artchad has quit [Read error: Connection reset by peer]
<jeosol>
The remote machine is running SBCL and hunchentoot (I only use SBCL ...)
shka has joined #commonlisp
mon_aaraj has joined #commonlisp
<Josh_2>
Are you using a remote lisp image?
fitzsim has quit [Ping timeout: 250 seconds]
<fe[nl]ix>
sm2n: I don't think I've ever seen thread-name returning a symbol
<sm2n>
fe[nl]ix: ecl appears to always do it for some system threads
<sm2n>
as far as I can tell
<sm2n>
in particular I'm always getting SI:TOP-LEVEL and SI:SIGNAL-SERVICING