kevingal has quit [Remote host closed the connection]
random-nick has quit [Ping timeout: 245 seconds]
akoana has left #commonlisp [#commonlisp]
etimmons has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 244 seconds]
Lord_of_Life has joined #commonlisp
hineios has quit [Ping timeout: 272 seconds]
hineios has joined #commonlisp
whosit has quit [Ping timeout: 272 seconds]
dbotton has quit [Ping timeout: 272 seconds]
Krystof has quit [Ping timeout: 272 seconds]
blizzard has quit [Ping timeout: 272 seconds]
tyson2 has quit [Remote host closed the connection]
blizzard has joined #commonlisp
Josh_2 has quit [Ping timeout: 245 seconds]
trokotech has quit [Ping timeout: 244 seconds]
trokotech has joined #commonlisp
_death has quit [Ping timeout: 272 seconds]
karlosz has quit [Quit: karlosz]
mindCrime has quit [Ping timeout: 264 seconds]
blizzard has quit [Ping timeout: 272 seconds]
blizzard has joined #commonlisp
<beach>
Good morning everyone!
taiju has quit [Ping timeout: 268 seconds]
taiju has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 264 seconds]
Lord_of_Life_ is now known as Lord_of_Life
Bike has quit [Quit: sleep]
karlosz has joined #commonlisp
<hirez>
morning beach
<hirez>
well, night here :P
<hirez>
it was 110 degrees F today here in the southwest states. Hows the weather on the other side of the pond.
<beach>
Colleen: weather in Bordeaux
<Colleen>
Weather in Bordeaux: Partly Cloudy at 13°C, 100% humidity, 1km/h wind, 1023hPa pressure.
<beach>
Max 27°C today they say. Quite nice.
<hirez>
100% humidity
<beach>
High humidity is not unusual here. But that does sound a lot.
<hirez>
hah, that isn't too bad 80 deg in freedom units at 100% humidity seems kind of muggy though
<beach>
I think the figure is wrong.
<beach>
87% says one site. That seems more likely. And more normal here.
<hirez>
bordeaux huh. Never heard of it. You can tell how cultured I am. Looking at a map it seems adjacent to a river of some kind so the high humidity makes sense.
<beach>
I take it you don't drink wine. Oh well.
<hirez>
hah, now that you mention it...
<hirez>
I guess I didnt make the connection!
<beach>
Yes, here in France we have many places named after famous food and drink :)
<moon-child>
is it not the other way around? :P
<beach>
Nah! :)
<hirez>
I believe it. My girlfriend is an amateur chef that refuses to open a shop. She studies from french cookbooks.
<hirez>
Oh hey dassault is based out of bordeaux
<hirez>
thats sweet
<hirez>
big fan of their work
<hirez>
the rafale block B was a beautiful jet
<beach>
Seems you need to come visit some day.
<beach>
I'll make a "magret de canard" for your girlfriend. Served with a "Pessac Léognan" red wine.
<beach>
And a "Fois gras de canard" for starters with a sweet white wine from the Pyrenees.
<beach>
Anyway, I'll stop the off-topic stuff now.
<hirez>
I am trying to pass a lambda into the sort function. I need to preload the lambda with a start point to do angular sorting.
<hirez>
howeer it seems the function namespace is messing me up
<hirez>
when I let bind the function it (as expected) wont let me pass it into sort with #'my-func
<hirez>
(if you're wondering this is the preamble code for graham's scan - a famous algorithm for computing the 2d convex hull in O(nlogn))
taiju has quit [Ping timeout: 245 seconds]
taiju has joined #commonlisp
<White_Flame>
hirez: get rid of the #'
<White_Flame>
sort-func is a plain variable, holding a function object. just pass that value to sort
<White_Flame>
you don't have a function named SORT-FUNC
<hirez>
I see, I have a variable bound to a function, and not a function.
<hirez>
so #' is only for uh...named functions?
<White_Flame>
if you had (let ... (defun sort-func ...)), or (labels ((sort-func ...)) (stable-sort ...)), then you would use #'sort-func
<White_Flame>
correct, #'foo is a reader macro for (FUNCTION FOO)
<hirez>
I see, I am weak on the reader macro which explains my folly here.
<hirez>
I appreciate the help. Porting this stuff over is teaching me a lot very quickly
<White_Flame>
right, the lambda object directly gives you the function object value, and you don't need to look it up by function name somewhere to extract the function objec from some (my-sort ...)-callable named functino
<White_Flame>
*lambda expression
<hirez>
Oh I see, so you can sort of think of #' as a nice macro to "extract" the function from the definition table
<White_Flame>
and yeah, trial by fire is a very memorable way to learn ;)
<hirez>
otherwise it would be treated as a variable in the sexp
<White_Flame>
DEFUNs are global function definitions, FLET/LABELS are local function definitions
<White_Flame>
so there's not strictly a "definition table"
<White_Flame>
yep
<hirez>
I see, yeah it was mostly just a convenient way to think of it. I suppose "extract the function from the known function labels" would be more accurate.
<White_Flame>
this is the nature of a "lisp-2" vs a "lisp-1", if you've seen those terms
<hirez>
actually yeah I was curious
<hirez>
what is lisp2 vs lisp1
<White_Flame>
a lisp1 lets you do (let ((foo (lambda ...))) (foo 1 2 3)) directly
<White_Flame>
BUT, that means your variable names and function names collide
<White_Flame>
so you can't do (let ((list '(1 2 3))) ...) because that would override the CL:LIST function!
<White_Flame>
this is how CL allows you to do (let ((list (list 1 2 3))) ...)
<White_Flame>
with the variable named LIST and the function named LIST not colliding
<White_Flame>
and why Scheme has to do the equivalent of (let ((lst ...)) ...) to avoid collision
<hirez>
Ah I see, so there's a function namespace and variable namespace in lisp2 and in lisp1 they are the same
<White_Flame>
correct
<White_Flame>
there are way more namespaces in CL (like 7+), but those 2 are the main ones in this respect
<hirez>
this explains the purpose of #' clearly
<White_Flame>
cool :)
<hirez>
much appreciated! This channel has been an incredible resource.
<flip214>
the difference between #' and ', at least
<hirez>
is #' read "function-quote"
<flip214>
or perhaps #' vs. symbol-value, though this isn't right because of lexical bindings either
Cymew has joined #commonlisp
Krystof has joined #commonlisp
karlosz has quit [Quit: karlosz]
<beach>
edgar-rft: Surprising! Thanks!
<beach>
hirez: Also, there is no such thing as "a lambda" in Common Lisp. There are anonymous functions that are typically created from the compilation of a "lambda expression". In many other languages, anonymous functions are a recent invention, so they gave them the name "a lambda", but in Common Lisp, they are not a big deal, and in fact, DEFUN can very well expand to a lambda expression.
skyl4rk has quit [Ping timeout: 244 seconds]
skyl4rk has joined #commonlisp
contrapunctus has left #commonlisp [#commonlisp]
danieli has quit [Ping timeout: 244 seconds]
danieli has joined #commonlisp
contrapunctus has joined #commonlisp
borodust has quit [Ping timeout: 272 seconds]
borodust has joined #commonlisp
sm2n has quit [Read error: Connection reset by peer]
sm2n has joined #commonlisp
jdz has quit [Ping timeout: 272 seconds]
jdz has joined #commonlisp
ceblan has quit [Ping timeout: 244 seconds]
ceblan has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 252 seconds]
trocado has quit [Ping timeout: 245 seconds]
pve has joined #commonlisp
blihp has quit [Ping timeout: 250 seconds]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
karlosz has joined #commonlisp
Fade has quit [Ping timeout: 272 seconds]
silasfox has joined #commonlisp
esb has quit [Quit: Using Circe, the loveliest of all IRC clients]
v88m has quit [Ping timeout: 264 seconds]
esb has joined #commonlisp
esb has left #commonlisp [#commonlisp]
v88m has joined #commonlisp
esb has joined #commonlisp
adeht has joined #commonlisp
adeht is now known as _death
jan-magnus has quit [Ping timeout: 272 seconds]
heisig has joined #commonlisp
jan-magnus has joined #commonlisp
jan-magnus has quit [Ping timeout: 264 seconds]
random-nick has joined #commonlisp
pve has quit [Quit: leaving]
domovod has quit [Quit: WeeChat 3.1]
tyson2 has joined #commonlisp
yewscion has joined #commonlisp
zacts has joined #commonlisp
cage has joined #commonlisp
jan-magnus has joined #commonlisp
selwyn has joined #commonlisp
<pjb>
beach: it's the opposite. Here in France, there are many foods named after their place of origin!
<pjb>
Nobody would go and name a new town "Pizza Quatre Saisons"!
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #commonlisp
gty has quit [Quit: Client closed]
Oladon has quit [Quit: Leaving.]
<jcowan>
White_Flame: I wish CL people would stop spreading the error about not being able to use `list` as a variable in a Lisp-1. The only time you can't do that is if you want to call the global function `list` in the same scope.
<jackdaniel>
jcowan: but that's the point of that illustrative example
<dsk>
(let ((list (list 1 2 3))) list) actually works fine in Scheme, so it's not the best example.
<splittist>
I guess most times one wants a variable named list would not include use of the function list. On the other hand, a large proportion of the times you would use the function list you would want a variable that is a plain list. OTOH, this comment is probably longer than the amount of Scheme I have written in anger.
<jackdaniel>
dsk: the point of the example with list is that you can't do: (let ((list (list 1 2 3))) (list '(3 2 1) list))
<jackdaniel>
of oucrse that's not a big problem, you may rename the variable to lst
<jackdaniel>
course*
<dsk>
jackdaniel: Yes, that example illustrates the point :)
<jackdaniel>
looking at things from the other side of the wall: schemers take pride in macro "hygiene" (and claim that cl macros are inferior), but avoiding organic macro pitfails is easy with gensyms and once-only operators while cl macros are much "natural" to use (at least to me)
<jackdaniel>
s/much/much more/
<Inline>
ja
<Inline>
ok but where is the namespace of the macro ?
<Inline>
i had issue with that
<dsk>
Yes, normal DEFMACRO macros are much easier to write and debug than e.g. syntax-case ones.
<dsk>
IMO.
<jackdaniel>
Inline: macros are in the same namespace as functions but are treated differently by the compiler
<Inline>
apart from that i find that when you are on a DSL level of cl those macros don't work anymore when the DSL doesn't allow for it
* jackdaniel
doesn't understand
<Inline>
i can't use reader macros in mcclim listener for example for some reason
<Inline>
they work ok on the normal terminal
<jackdaniel>
my confusion is even deeper now
<jcowan>
It is, but it's contrived. 90% of the time there is no collision
<jcowan>
In addition, the gensym solution is only half hygienic: it protects the caller from the macro, but does not protect the macro from the caller
<jackdaniel>
jcowan: in practice cl macros are just fine and easier to use, so one could turn the table and say, that "hygiene is contrived. 90% of the time there is no [need for protection] and the remaining parts are easy to fix"
<jcowan>
Do you mean "easier to write"?
<jackdaniel>
no, use is a more broad statement
<jackdaniel>
either way, all these arguments boil down to "mine is better because it is miner"
<jcowan>
Mostly yes.
<jcowan>
But if you are going to do advocacy, it's important to understand what you are advocating against (as we see in politics)
<jackdaniel>
I wouldn't attempt such wasteful thing as advocacy (or politics); I'll get better back to work ;)
<pjb>
edgar-rft: strangely, I'm not surprised :-/
blizzard has quit [Ping timeout: 244 seconds]
jan-magnus has quit [Quit: leaving]
igemnace has quit [Quit: WeeChat 3.1]
mingus has joined #commonlisp
<scymtym>
the limitations or macro lambda lists seem like a bigger practical downside of the CL macro system to me
igemnace has joined #commonlisp
<scymtym>
*limitations of
<pjb>
scymtym: what limitation? Macro-functions take whole forms, they can analyse the lambda list as they wish!
<pjb>
(defmacro foo (&whole form &env environment) (do-whatever-you-want form environment))
Inline has quit [Quit: Leaving]
Inline has joined #commonlisp
<scymtym>
pjb: yes, but for syntax expressed in the macro lambda list, there are several benefits. for once, a user can more easily introspect the syntax of the macro. also, the implementation can do a better job of reporting syntax errors without the need for the macro writer to use WITH-CURRENT-SOURCE-FORM or something similar. an example of syntax that cannot be expressed in a macro lambda list is the "options" syntax that is used in
<scymtym>
DEFGENERIC, DEFCLASS and other places
unyu has quit [Ping timeout: 244 seconds]
<scymtym>
pjb: note that i didn't say CL macro were limited. i said macro lambda list have limitations
<edgar-rft>
pjb: Modern humans once came from Africa, where Pizza/Nigeria obviously is the place where the Italians came from.
unyu has joined #commonlisp
<flip214>
why, is there a place called Spaghetti as well?
<Inline>
i think that is somewhere in China
<Inline>
lol
<pjb>
edgar-rft: :-)
<pjb>
scymtym: Yes, I understood. For functions, we also have &rest arguments, and specific parsing. It's obvious that lambda-lists have a restricted grammar and cannot parse any language. (I like to write my command options/arguments parsing using sophisticated (english-like) grammar, but it's not the unix concise style for command options).
<pjb>
scymtym: it's clear that LOOP lambda-list cannot be parsed by the standard mechanism…
<pjb>
scymtym: but it wouldn't be efficient, or easy to use, if each operator definition had to provide a grammar for its arguments parsing. We want a limited set here. (but lisp is smart in allowing general parsing thru &whole or &rest).
<scymtym>
pjb: sigh. i know that things are the way they are for a reason. i'm not going to debate this further
Bike has joined #commonlisp
waleee has quit [Ping timeout: 272 seconds]
waleee has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
<White_Flame>
jcowan: that wasn't advocacy, but just explanation
<White_Flame>
along with an advantageous example of what you can do in a lisp1 that you can't do in CL
<nick3000>
Does lisp have anything like C++ const variables? I'd like to declare a global constant object that would cause an error if an attempt was made to modify it.
<Bike>
clhs defconstant
<nick3000>
I find if I use defconstant I can still modify the object using incf/decf for example.
<nick3000>
That's an example, MACHINE-WORD is a sequence of bytes in a VM, I'd like to not be able to incf/decf.
<Bike>
mm, it's undefined behavior to modify constant data, not an error
<nick3000>
Okay.
contrapunctus has left #commonlisp [#commonlisp]
<Bike>
there's no operator that makes it an actual error. since in lisp we don't have everything compiled at once like in C, there would have to be a runtime tag of some kind on constant objects, and every modifying operation would have to check it
<nick3000>
Right
<beach>
I have always wondered how static languages do things like that. Do they put the object in read-only memory?
<nick3000>
Yes
<Bike>
that said, implementations tend to warn when you compile code that modifies constant
<Bike>
s
<nick3000>
A section of memory is declared to the kernel to not be modifiable.
<nick3000>
And in addition there are compile-time checks.
<beach>
Right.
<beach>
Maybe I should do something like that in SICL. There is nothing preventing me from having a separate read-only global heap.
<Bike>
the C and C++ standards mandate the compiler output a diagnostic message if you have code that could modify a constant. i don't know if t here's any requirement on the runtime
<Bike>
and of course you can do const_cast and stuff
<beach>
Bike: That's precisely the reason for my asking.
<Bike>
oh yeah, here we go. "Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior. "
contrapunctus has joined #commonlisp
<beach>
Bike: That's C++?
<Bike>
yes. i don't know about C. i don't think C has anything like const_cast, so it may be impossible to construct code that modifies a const object unless you do other standard violating things like out of bounds pointer arithmetic
<beach>
I thought so. So it's not guaranteed in those languages either.
<beach>
So the answer to nick3000 is that C++ doesn't have such a thing either.
<nick3000>
Well practically speaking as a day-to-day C++ programmer, you get a segfault.
<nick3000>
Not sure what the spec says.
<beach>
But that was what I am interested in.
<Bike>
it says undefined behavior, at least according to cppreference, which is usually alright
<nick3000>
But I have many many times done stuff like that in C/C++ and you will get a segfault.
<beach>
What the spec says, that is.
<_death>
Bike: you shouldn't modify const objects in either case.. there is a distinction between const objects and const references/pointers
<Bike>
i suppose the difference is that I think the C++ standard mandates a warning of some kind
<Bike>
in the compiler, i mean
<beach>
Bike: Right, but that has to be undecidable in general.
<Bike>
sure
<_death>
Bike: so if you have a const reference to a nonconst object, you can use const_cast in C++ and an ordinary cast in C
<jcowan>
same story in C, it just doesn't use "const_cast". If x is a cnst int, then (int)x is a version that has cast away constness, and if you mutate it, boom, dragons out your nose.
<Lycurgus>
or time spent with valgrind, unless you know what ur doing
silasfox has joined #commonlisp
<Lycurgus>
which ain't that hard with C i would think but apparently not
<_death>
jcowan: in C, the following has well defined behavior: int foo = 42; const int *bar = &foo; *(int *)bar = 24; /* now foo == 24 */
<jcowan>
Yes, if the const int is underlyingly an int, you're fine. I was talking about the case where you have a "native" const int and you cast it to be an int.
<jcowan>
const int i = 42 can in principle but i in the ROM.
<_death>
jcowan: in C, you can only get into trouble that way when casting pointers :)
<jcowan>
s/but/put
yitzi has joined #commonlisp
Fade has joined #commonlisp
<_death>
if you had const int foo = 42; then int *nonconst_bar = (int *)bar; is still OK, but *nonconst_bar = 24; gives way to the demons
<_death>
nick3000: in Lisp, defconstant is basically for simple objects like symbols and numbers.. what it says is that the binding should not be changed
<nick3000>
Right, I was just hoping for something like in C/C++ where _much_ of the time, if you modify it, somehow, things come crashing to a halt, mostly as just an additional stupid-check.
<pjb>
defconstant is a compiler hack. It says that the compiler may use the value literally, as immediate value in the generated code.
<_death>
nick3000: if we want to prevent modification, we use documentation to tell the user not to do that.. if we want to go further (prevent accidental modification) we can simply hide the object and provide a controlled interface to it, that allows only read
<pjb>
Since most lisp values are references, it doesn't make sense to put them as immediate values in the generated code (an address?!).
selwyn has joined #commonlisp
Josh_2 has joined #commonlisp
<pjb>
So it applies only to numbers and symbols, and even, most numbers cannot be stored as immediate value (no processor I know support complexes or bignums as immediate value in the code!)
<nick3000>
Okay thanks pjb and _death.
<pjb>
So I'd say that for the programmer, defconstant is not very useful. The only feature that could perhaps be used, is that you cannot bind (locally) a constant variable. But I find it more a bother than an advantage.
<jcowan>
Freedom of binding is a Lisper's right!
<pjb>
For example, I define the ASCII control codes as constants. So now I cannot do (let ((ht (make-hash-table))) …) anymore :-/
<pjb>
I might s/defconstant/define-symbol-macro. for them…
pve has joined #commonlisp
<jcowan>
But I'm happy with (defconstant table = '((us . "United States) (de . "Germany") ...))
<pjb>
define-symbol-macro is more interesting. You can do lexical global variables with them, and all kind of magic, and you can shadow them in a local lexical binding.
<pjb>
jcowan: until there's a new country, or some country doesn't use it's standard abbreviation.
Lycurgus has quit [Quit: Exeunt]
<pjb>
jcowan: for example, I noticed that Mongolia doesn't use its iso3166 cod in sports, but another abreviation…
<jmercouris>
Just not sure how to make the leap to highlighting
<jmercouris>
How do I associate a found symbol to something in the form to highlight
<jmercouris>
I would need to look through the form and find the same symbol
<beach>
You mean, you need to find the source location of it?
<jmercouris>
Almost
<jmercouris>
Just the location within the form
<jmercouris>
Maybe I’ll give up and just do a dumb regex for now
<yitzi>
I suggest the excellent Eclector.
<jmercouris>
Aha
<beach>
That's why we plan to use Eclector's capability of producing CSTs (which contain source information).
<yitzi>
I don't syntax highlighting in common-lisp-jupyter, but I do use eclector for symbol completion and inspection.
<jmercouris>
I see
<beach>
That's great!
<jmercouris>
For that it could be quite useful
<beach>
Eclector is a very fine library.
<jmercouris>
beach: how long until you can produce a CST?
<jmercouris>
Also what does CST stand for?
<beach>
Concrete Syntax Tree. Eclector can do that out of the box.
<jmercouris>
I see
<beach>
But it's not enough.
<beach>
You also need a code walker.
<jmercouris>
Hm
<jmercouris>
The plot thickens
<beach>
My plan was to use Cleavir for that, but it looks like scymtym is going to do some work, and I don't know his plans.
<jmercouris>
I’ll look around the source
<jmercouris>
And see if I can figure something out
<jmercouris>
Thanks for the tips
<beach>
Sure.
<beach>
There is other stuff you need to think about though...
<beach>
If you use the reader, you may encounter errors.
<beach>
Like non-existing packages, premature end-of-file, etc.
<beach>
Then if you use a code walker, you may get errors from it with respect to special forms.
<beach>
And if someone writes cl::hello, you may want to prevent the symbol from being created in the Common Lisp package.
<beach>
So the plan is to configure Eclector to not intern symbols in the normal host packages, and to have Eclector recover from various reader errors.
<jmercouris>
Right
<jmercouris>
Sounds incredibly challenging
srhm has joined #commonlisp
<beach>
It is. That's why it's taking time. :)
<beach>
Plus, a paper we wrote documents the use of the reader incrementally, so that you don't have to re-read the entire buffer after each keystroke.
<beach>
That's another challenge.
<beach>
Luckily, that one is taken care of.
mns has left #commonlisp [Leaving]
<beach>
jmercouris: I did start using Nyxt today. Not yet exclusively, though. Still learning.
<blihp>
beach: are you able to use it from your default setup (I assume lisp/slime)? It was giving me all kinds of problems until I just started a sbcl instance just for it from the command line
<blihp>
(err, I meant to say emacs/slime)
domovod has joined #commonlisp
<beach>
Thanks scymtym.
<scymtym>
sure
<beach>
blihp: "it"?
<beach>
scymtym: Wow, nice demo!
<beach>
blihp: Nyxt you mean? I just started it from the command line.
<beach>
Josh_2: Yes, I see. I'll start by learning to use it I think.
<beach>
scymtym: What code walker are you using?
<scymtym>
beach: mostly just the expression syntax library. combined with code to track the current package and other state in a chain of environment objects
<jcowan>
Symbols and especially packages are the things that make `read` hard.
<beach>
scymtym: Will that be enough, or do you plan to improve it later?
<beach>
jcowan: We solved that problem. Or rather, scymtym did.
srji has quit [Quit: leaving]
<jcowan>
is that inherent to Eclector, or is it separable?
<beach>
It's part of Eclector.
<jcowan>
Is there a writeup somewhere of how it works?
<beach>
Solving the problem requires an implementation of the reader algorithm that allows client code to configure what happens when a token is about to be processed. And that's what Eclector is.
srji has joined #commonlisp
<scymtym>
beach: i hope it will work for my purposes
<beach>
Great!
<scymtym>
jcowan: let me find the presentation-ish explanation i made
<beach>
scymtym: I am very impressed by the demo. It seems you are getting close.
<scymtym>
beach: thanks. i have a plan at least. i ultimately want to combine the incremental parsing of Second Climacs with the s-expression parsing and environment stuff
amk has quit [Read error: Connection reset by peer]
amk has joined #commonlisp
zacts has quit [Quit: bbl]
srji has quit [Remote host closed the connection]
contrapunctus has left #commonlisp [#commonlisp]
contrapunctus has joined #commonlisp
<jmercouris>
beach: nice! That’s cool! Hopefully you won’t cringe too hard when you look at our code :-D
v88m has joined #commonlisp
contrapunctus has left #commonlisp [#commonlisp]
* shka
opens the source code of nyxt
waleee has quit [Ping timeout: 244 seconds]
contrapunctus has joined #commonlisp
* shka
proceeds to screech *UNACCEPTABLE*
<shka>
jmercouris: it is not that bad
<shka>
but master was broken yesterday
<shka>
and that guix package crashes
<shka>
but I've seen worse lisp code
<shka>
much worse
yewscion has quit [Remote host closed the connection]
yewscion has joined #commonlisp
<jcowan>
I once saw code in which a 100 element array was initialized to 0 with 100 assignment statements. Written by a consultant.
<jcowan>
We fired his ass
<aeth>
at least he knew what an array was
<aeth>
a0 = 0; a1 = 0; a2 = 0; ...
yewscion has quit [Ping timeout: 245 seconds]
<_death>
unrolling in his grave
<yitzi>
Did you ask him where he learned how to do that? I would just die if said he copy-pasted it.
<knusbaum>
Hi, everyone. I'm playing with implementing a very simple swank server, but I'm having trouble finding good documentation about the various RPC calls.
dbotton has joined #commonlisp
<phoe>
knusbaum: curious question, which language are you writing for?
<knusbaum>
My current issue is that SLIME seems to call swank:autodoc with a bunch of previous buffer contents including prompts. I'm not sure how to tell emacs that the previous buffer contents should be ignored.
<knusbaum>
phoe: I'm writing this for my own lisp.
<phoe>
knusbaum: OK
<phoe>
how to tell *emacs* though?
<phoe>
that's slime, the elisp side
<knusbaum>
Whichever SWANK client. I'm currently using emacs to test.
<phoe>
if you want to write a swank server, ideally you should not need to modify slime
<phoe>
oh, I see
<knusbaum>
No, Emacs/SLIME is issuing an RPC call I consider "weird", and I assume that's because I'm doing something wrong on the server side.
<phoe>
how is slime configured? slime-fancy?
<phoe>
maybe the client loads a bunch of contribs that the server does not support
<knusbaum>
That could be. From (swank:connection-info) I return :modules ("SWANK-ARGLISTS" "SWANK-REPL" "SWANK-PRESENTATIONS")
<knusbaum>
And I'm not receiving any relevant RPC calls to the server that are unhandled.
<phoe>
still, regarding all the various rpc calls, I don't know of any good documentation that isn't "ask a person knowledgeable in the topic"
<knusbaum>
That's why I'm wondering if I need to be sending other requests to the client like (:clear-prompt) or something.
<knusbaum>
Yeah, haha.
<phoe>
and the latter would be, I guess, asking luis and/or Joao who is knowledgeable in the ways of slynk/sly
<knusbaum>
Is SLIME/SWANK active anymore, or is slynk/sly the way to go now?
<phoe>
yes it is
cage has joined #commonlisp
<phoe>
slynk has simply diverged too much functionally to be merged back into slime
<phoe>
(since that's where joao asked me to point people to if they have any kind of sly questions, and I guess that questions about the rpc protocol are borderline on-topic there)
<knusbaum>
Thanks very much, phoe.
pve has quit [Ping timeout: 245 seconds]
pve has joined #commonlisp
srhm has quit [Quit: Konversation terminated!]
srhm has joined #commonlisp
pve has quit [Ping timeout: 245 seconds]
pve has joined #commonlisp
cage has quit [Remote host closed the connection]
shka has quit [Ping timeout: 272 seconds]
loke[m] has quit [Quit: Bridge terminating on SIGTERM]
dieggsy has quit [Quit: Bridge terminating on SIGTERM]
katco has quit [Quit: Bridge terminating on SIGTERM]
loke[m] has joined #commonlisp
akanouras has joined #commonlisp
katco has joined #commonlisp
Gnuxie has joined #commonlisp
dieggsy has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 252 seconds]
Lord_of_Life has joined #commonlisp
knusbaum has quit [Remote host closed the connection]
rudi has quit [Quit: rudi]
karlosz has joined #commonlisp
akoana has joined #commonlisp
tyson2 has quit [Ping timeout: 252 seconds]
waleee has quit [Ping timeout: 245 seconds]
Lycurgus has joined #commonlisp
esb has joined #commonlisp
waleee has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
aeth has quit [Read error: Connection reset by peer]
aeth has joined #commonlisp
tyson2 has joined #commonlisp
rgherdt has quit [Ping timeout: 264 seconds]
pve has quit [Quit: leaving]
mindCrime has quit [Ping timeout: 245 seconds]
yewscion has quit [Remote host closed the connection]
yewscion has joined #commonlisp
dsk has joined #commonlisp
trocado has joined #commonlisp
mindCrime has joined #commonlisp
aeth has quit [Quit: ...]
aeth has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
mindCrime has quit [Read error: Connection reset by peer]
mindCrime has joined #commonlisp
yewscion has quit [Ping timeout: 244 seconds]
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
mindCrime has quit [Ping timeout: 244 seconds]
raeda_ has joined #commonlisp
mindCrime has joined #commonlisp
raeda has quit [Read error: Connection reset by peer]
kevingal has quit [Remote host closed the connection]
mindCrime_ has joined #commonlisp
mindCrime has quit [Ping timeout: 250 seconds]
blihp has joined #commonlisp
neirac has quit [Ping timeout: 268 seconds]
franco has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]