<fiddlerwoaroof>
The only problem is that certain libraries insist on causing problems here: I go out of my way to avoid depending on osicat because of this
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
wxie has joined #lisp
froggey has quit [Ping timeout: 260 seconds]
froggey has joined #lisp
kingcons` has quit [Ping timeout: 260 seconds]
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
v88m has quit [Ping timeout: 272 seconds]
miasuji has quit [Ping timeout: 260 seconds]
v88m has joined #lisp
abhixec has quit [Ping timeout: 272 seconds]
ralt has quit [Quit: Connection closed for inactivity]
notzmv has joined #lisp
nicktick has joined #lisp
galex-713 has quit [Ping timeout: 272 seconds]
luckless has quit [Quit: luckless]
luckless has joined #lisp
abhixec has joined #lisp
rpg has joined #lisp
akoana has left #lisp ["Leaving"]
semz has quit [Ping timeout: 258 seconds]
luckless has quit [Quit: luckless]
luckless has joined #lisp
galex-713 has joined #lisp
semz has joined #lisp
shifty has joined #lisp
Grue`` has joined #lisp
mister_m has quit [Ping timeout: 260 seconds]
himmAllRight has quit [Ping timeout: 265 seconds]
Grue` has quit [Ping timeout: 265 seconds]
himmAllRight has joined #lisp
thmprover has joined #lisp
hsaziz has joined #lisp
slyrus_ has joined #lisp
luckless has quit [Ping timeout: 240 seconds]
miasuji has joined #lisp
luckless has joined #lisp
mindCrime has joined #lisp
bilegeek has quit [Quit: Leaving]
Oladon has joined #lisp
orivej has quit [Ping timeout: 246 seconds]
<charles`>
Does anyone else get a compile error on sbcl for defconstant after a image restart
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fiddlerwoaroof>
charles`: what does the error say?
<fiddlerwoaroof>
It sounds like a defconstant is being evaluated/compiled twice with values that aren't EQL
<charles`>
Yes it says constant NAME is being redefined from "string" to "string". I know it happens when I try to reevaluate the defconstant, but It sometimes happens after I restart the image
<fiddlerwoaroof>
It sounds like your startup sequence is evaluating a defconstant twice, but you aren't really providing enough context
Alfr_ has joined #lisp
Alfr has quit [Ping timeout: 268 seconds]
<beach>
Good morning everyone!
<charles`>
It is strange because it only happens sometimes
abhixec has quit [Ping timeout: 272 seconds]
Stanley00 has joined #lisp
frost-lab has joined #lisp
abhixec has joined #lisp
<fiddlerwoaroof>
morning beach!
vutral has joined #lisp
_whitelogger has joined #lisp
__jrjsmrtn__ has quit [Ping timeout: 260 seconds]
__jrjsmrtn__ has joined #lisp
madage has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
Oladon has quit [Quit: Leaving.]
madage has joined #lisp
rumbler31_ has quit [Ping timeout: 240 seconds]
wxie has quit [Ping timeout: 264 seconds]
shifty has quit [Ping timeout: 264 seconds]
shifty has joined #lisp
nicktick has quit [Ping timeout: 246 seconds]
nicktick has joined #lisp
wxie has joined #lisp
thmprover has quit [Quit: ...and miles to go before I sleep.]
rumbler31_ has joined #lisp
_whitelogger has joined #lisp
nicktick has quit [Ping timeout: 246 seconds]
nicktick has joined #lisp
andreyorst has joined #lisp
luckless has quit [Quit: luckless]
shifty has quit [Ping timeout: 246 seconds]
shifty has joined #lisp
luckless has joined #lisp
makomo has joined #lisp
luckless has quit [Client Quit]
luckless has joined #lisp
luckless has quit [Client Quit]
luckless has joined #lisp
miasuji has quit [Ping timeout: 260 seconds]
vutral has quit [Quit: Connection closed for inactivity]
luckless has quit [Quit: luckless]
waleee-cl has quit [Quit: Connection closed for inactivity]
marusich has quit [Quit: Leaving]
karlosz has quit [Quit: karlosz]
marusich has joined #lisp
abhixec_ has joined #lisp
luckless has joined #lisp
abhixec_ has quit [Client Quit]
mindCrime has quit [Ping timeout: 265 seconds]
narimiran has joined #lisp
makomo has quit [Ping timeout: 260 seconds]
luckless has quit [Quit: luckless]
luckless has joined #lisp
ralt has joined #lisp
andreyorst has quit [Quit: WeeChat 3.0]
andreyorst has joined #lisp
sauvin has joined #lisp
saganman has joined #lisp
hsaziz has quit [Quit: hsaziz]
dvdmuckle has quit [Quit: Bouncer Surgery]
galex-713 has quit [Quit: No Ping reply in 180 seconds.]
dvdmuckle has joined #lisp
galex-713 has joined #lisp
shifty has quit [Ping timeout: 260 seconds]
<ralt>
fiddlerwoaroof: are you sure this ends up building a static binary?
IPmonger has quit [Ping timeout: 264 seconds]
rgherdt has joined #lisp
IPmonger has joined #lisp
shka_ has joined #lisp
v_m_v has joined #lisp
<fiddlerwoaroof>
Yeah, that's the point of ASDF's static-program-op
saganman has quit [Ping timeout: 265 seconds]
<fiddlerwoaroof>
Sorry, CFFI's
<fiddlerwoaroof>
Hmm, I guess it's not completely statically linked
wxie has quit [Remote host closed the connection]
wxie has joined #lisp
mankaev has quit [Ping timeout: 272 seconds]
<ralt>
fiddlerwoaroof: right. See linux-packaging for something that uses static-program-op, with osicat that is statically linked as well.
<ralt>
What I'm playing with is linking sbcl to musl in order to get a full static binary.
<ralt>
But etimmons is basically 3 steps ahead of me.
<flip214>
I'd like to generate dwarf output for function start/end addresses in SBCL, so that perf can report the stack correctly
luckless has quit [Quit: luckless]
andreyorst has quit [Ping timeout: 265 seconds]
luckless has joined #lisp
hendursa1 has joined #lisp
jprajzne has joined #lisp
hendursaga has quit [Ping timeout: 240 seconds]
galex-713 has quit [Ping timeout: 272 seconds]
nicktick has quit [Ping timeout: 265 seconds]
heisig has joined #lisp
rogersm has joined #lisp
galex-713 has joined #lisp
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
liberliver has joined #lisp
mankaev has joined #lisp
v_m_v has quit [Ping timeout: 260 seconds]
wxie has quit [Quit: wxie]
wxie has joined #lisp
amirouche has quit [Ping timeout: 240 seconds]
amirouche has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
contrapunctus has joined #lisp
vaporatorius__ has quit [Read error: Connection reset by peer]
vaporatorius__ has joined #lisp
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
pve has joined #lisp
varjag has joined #lisp
orivej has joined #lisp
mankaev has quit [Ping timeout: 265 seconds]
v_m_v has joined #lisp
aartaka has joined #lisp
dhil has joined #lisp
jonathan| has quit [Ping timeout: 260 seconds]
aartaka has quit [Read error: Connection reset by peer]
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
wxie has quit [Ping timeout: 265 seconds]
v_m_v has quit [Ping timeout: 260 seconds]
v_m_v has joined #lisp
beaky has quit [Read error: Connection reset by peer]
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
beaky has joined #lisp
ljavorsk has joined #lisp
v_m_v has quit [Ping timeout: 260 seconds]
contrapunctus has left #lisp ["Disconnected: closed"]
jonathan| has joined #lisp
<ralt>
etimmons: I managed to build a static binary with musl but yeah, I'm back to the issue with the foreign symbols that your patch should help with.
<ralt>
one annoying thing is that sbcl recently stopped building the sbcl.o file with the _main symbol, though, so I had to build it manually.
<ralt>
otherwise I can get asdf:static-program-op to do most of the job for me.
<ralt>
(build it manually = cd src/runtime && make sbcl.o)
contrapunctus has joined #lisp
mankaev has joined #lisp
aartaka has joined #lisp
attila_lendvai has joined #lisp
mankaev has quit [Ping timeout: 272 seconds]
beaky has quit [Read error: Connection reset by peer]
beaky has joined #lisp
mankaev has joined #lisp
rumbler31_ has quit [Ping timeout: 246 seconds]
v_m_v has joined #lisp
birdwing has joined #lisp
ljavorsk has quit [Ping timeout: 265 seconds]
imode has quit [Ping timeout: 272 seconds]
mankaev has quit [Read error: Connection reset by peer]
mankaev has joined #lisp
beaky has quit [Read error: Connection reset by peer]
beaky has joined #lisp
hendursa1 has quit [Ping timeout: 240 seconds]
hendursa1 has joined #lisp
gxt has quit [Ping timeout: 240 seconds]
rumbler31_ has joined #lisp
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
galex-713 has quit [Ping timeout: 272 seconds]
makomo has joined #lisp
gxt has joined #lisp
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
makomo has quit [Ping timeout: 260 seconds]
v_m_v has quit [Ping timeout: 264 seconds]
edgar-rft has joined #lisp
galex-713 has joined #lisp
frodef` has joined #lisp
frodef has quit [Ping timeout: 246 seconds]
gaqwas has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 26.3)]
<pve>
I've been trying out ccl over the past couple of days and have to say it's really nice how my code just works even though the compiler got switched out.
<phoe>
that's the power of compliance™
<phoe>
(and portability libraries)
<pve>
I mean I had my goat and rain dance drums ready to go
<Xach>
I always feel a little bad when an implementation's list of compliance variations covers basic, specified functionality rather than extensions.
<Xach>
like CLISP's REQUIRE malarkey
<Xach>
(I feel less bad when it's an acknowledged, possibly low-priority bug rather than intentional "we know better" issue)
Bike has joined #lisp
<pve>
ccl's compile speed is also refreshingly snappy, which makes my ancient workstation happy
<phoe>
ccl has a very fast compiler compared to SBCL's
rumbler31_ has joined #lisp
<mfiano>
Usually attributed to not as many optimizations
<mfiano>
Though, SBCL fails at are transitive move instructions that their
<mfiano>
oops
<mfiano>
SBCl fails at removing some transitive move operations due to their SSA optimizations not being that great
<shka_>
phoe: both sbcl and ccl compile at warp speed given my low standards
<shka_>
C++, not even once
<shka_>
the only CL implementation that compiles slowly is ECL, but the plot twist is that it is not even ECL that is being slow
<shka_>
it is the GCC
<mfiano>
Been writing some LLVM and never realized how much better it optimizes simple stuff than SBCL
skapata has quit [Remote host closed the connection]
<mfiano>
See B2, BE, etc? Those are transitive move instructions that SBCL fails to remove properly
<shka_>
current CPUs can execute crappy code rather quickly
<shka_>
so the practical difference between good compiler and not so good compiler is closer then you would think
<shka_>
it is there though
<mfiano>
Rather quickly, adn quickly make a large difference in my domain :)
<shka_>
same
<shka_>
but what can I do?
<jackdaniel>
ecl's bytecodes compiler is lightning fast :) the generated bytecode not so much (it is a single-pass compiler)
<shka_>
jackdaniel: yeah, nothing ECL can really do better
<shka_>
maybe faster interpreter? but i have no idea how to even do that
<jackdaniel>
well, that's not true -- there are some things that could improve ecl compilation speed
<shka_>
ooooh
<shka_>
ok :-)
<jackdaniel>
interpreter is reasonably fast, it is that the compiled bytecode is not optimized
<shka_>
ok, got it
<shka_>
what about the compilation speed?
<jackdaniel>
one way for improving the compilation speed would be using libgcc instead of going through files (but that would be very much compiler-specific)
<shka_>
is that a low hanging fruit or is it complicated?
<shka_>
ok, got it
<jackdaniel>
it is not a low hanging fruit
<shka_>
mfiano: i honestly suspect that clasp can eventually become a really quick lisp implementation
<Bike>
right now our compiler is much slower than sbcl's, tho.
<phoe>
shka_: faster in compilation speed or faster as in performance of generated code
<mfiano>
In time. Good compilers require development effort and lots of funding
<Bike>
llvm does not have compilation speed as a priority, because as you said, C++
<mfiano>
Sadly we are limited in bioth of those regards
<shka_>
phoe: performance of generated code
<shka_>
Bike: well, I am actually atypically tolerant for a long compilations
<shka_>
my first serious project took 1 hour to compile
<shka_>
workflow was like: start compiling, go for a jog
<jmercouris>
I'm never quite sure how to indent with-slots
bendersteed has joined #lisp
<beach>
You should usually go for the indentation that Emacs+SLIME suggest. But their suggestions are not always great.
<beach>
In this case, there is no reason to indent lines 2-5 by 2 positions compared to "gobject".
<phoe>
(incf beach)
<beach>
And you may be able to save space by moving the beginning of the list to the next line.
<jmercouris>
hm it looks different on my screen
<jmercouris>
on my screen the g in gobject and the m in minibuffer are aligned
<jmercouris>
but this is in fact what Emacs+SLIME has done
<beach>
On your screen when you view the URL?
<jmercouris>
viewing the URL looks how you describe
<jmercouris>
viewing in my buffer looks how I describe
<beach>
Maybe you are using TABs?
<beach>
Don't do that.
<beach>
I see.
<jmercouris>
I have tabs disabled...
<jmercouris>
or at least they are supposed to be...
<travv0>
is that top line led by 2 spaces in your buffer?
<jmercouris>
travv0: not sure what 'led' means in this context
<beach>
jmercouris: Not related to your indentation, but if you have a list of that many slots, I think you have a design problem in your software.
<beach>
jmercouris: Past tense of lead.
<jmercouris>
beach: it is within intialize-instance where I am creating all of the objects
<jmercouris>
that are referenced in the slots
<travv0>
jmercouris: i just meant, are there two spaces at the beginning of the line before the opening paren
<jmercouris>
travv0: yes, there are
<travv0>
there's the difference then, those got lost in the copy/paste but there are 2 extra spaces on the rest of the lines
<jmercouris>
aha...
<travv0>
mystery solved
<beach>
Good catch!
<jmercouris>
I've moved them to the subsequent line, looks better, thanks
cosimone has joined #lisp
<pfdietz>
Now boring into test input generators. check-it; are there others?
birdwing has quit [Ping timeout: 258 seconds]
neirac has joined #lisp
<jmercouris>
pfdietz: you mean like fuzzy testing input generators?
<aeth>
adding to what beach said, the auto-indent of Emacs+SLIME only really breaks in a few places ime
<aeth>
1. advanced LOOP stuff (even with the added setting to make it indent loop properly), particularly with nested conditionals (usually, COND is better, but you do need to use LOOP's conditionals for optional COLLECT/etc. only on certain branches afaik)
<mfiano>
property testing
<mfiano>
pfdietz: cl-quickcheck is another
<aeth>
2. custom macros (although I think you can extend it) that do certain things, particularly ones that try to behave like FLET (with its own, special indentation rules)
<aeth>
(usually just using &body instead of &rest or vice versa is good enough for the right indentation)
<mfiano>
Indentation breaks the most with SLIME/Sly's indentation "lossage"
<mfiano>
Indentation codes are an extension of elisp's lisp-mode, and as such, indentation is only concerned with the operator's symbol-name, without package-name. As such, you may get the wrong indentation if you don't choose a macro name carefully for the state of your image.
rogersm_ has joined #lisp
<mfiano>
On Sly, you can use (slynk:print-indentation-lossage) to check the ambiguities. I'm not sure if SLIME offers a way
<jmercouris>
mfiano: I see, thanks for the information
<aeth>
mfiano: So what you're saying is that the lazy way to get FLET-style indentation for an FLET-style macro without having to extend Emacs would be to call it YOUR-PACKAGE:FLET instead of something else? (-:
<ralt>
shinohai: nah, etimmons is
<pfdietz>
jmercouris: yes, and also (if possible) test input reducer.
<mfiano>
I don't think that was what I was saying at all.
<pfdietz>
Something like a CL implementation of Python's Hypothesis would be very interesting.
<shinohai>
ty for link, was just poring over logs because that convo caught attention.
<shinohai>
Guess I need to search the ml, I find that very interesting.
<jmercouris>
pfdietz: isn't the SBCL team using some sort of fuzzer?
<jmercouris>
pfdietz: you may be able to ask them
<pfdietz>
I'll be sure to ask myself about that :)
galex-713 has quit [Ping timeout: 264 seconds]
<jmercouris>
lol
sjl has joined #lisp
<mfiano>
pfdietz: I once tried. The difficulty arises in reducing a generation down to the bare minimum, so you aren't presented with a failing test that is difficult to figure out why it failed.
<beach>
But, as usual, I did things in the reverse order compared to what most researchers would do, i.e., I came up with the technique before studying what already exists. And in fact, I still have no real idea what has been done in this domain, and I had to be told about how inline caches work.
<beach>
So if anybody knows some relevant existing techniques I should read about, please let me know.
<solideogloria[m]>
for some reason the prev-window function does not modify focus
<solideogloria[m]>
I can't figure out why
<solideogloria[m]>
it works when I don't use the function as you can see the commented code
charles` has joined #lisp
davd33 has joined #lisp
contrapunctus has left #lisp ["Disconnected: Replaced by new connection"]
contrapunctus has joined #lisp
Stanley00 has joined #lisp
kaun_ has left #lisp ["chalo"]
Stanley00 has quit [Ping timeout: 260 seconds]
galex-713 has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
contrapunctus has joined #lisp
isBEKaml has joined #lisp
galex-713 has quit [Ping timeout: 272 seconds]
galex-713_ has joined #lisp
<beach>
solideogloria[m]: I am not sure what your problem is, but do you want remarks on that code?
waleee-cl has joined #lisp
<beach>
solideogloria[m]: Oh, I think I see what you are asking.
<beach>
Setting focus inside prev-window will set the parameter of that function.
<beach>
solideogloria[m]: It works the same in almost all other programming languages.
<beach>
solideogloria[m]: But your code has other issues as well.
<beach>
To start with, you have a number of inexplicable blank lines. It is unusual for Common Lisp code to have blank lines inside a function.
<beach>
Then, you have an IF without an `else' branch. And since it is a form that is executed for side effect only, you should use WHEN instead.
<phoe>
solideogloria[m]: of course it modifies focus
<phoe>
your SETF calls modify the FOCUS local variable declared in line 1 of your paste
<phoe>
and likely nothing else
<beach>
Further, you are using EVENT as a Boolean in (WHEN EVENT....). In the LUV slides (page 13) by Norvig and Pitman, they explain that WHEN should be used only with Booleans, so I would write (UNLESS (NULL EVENT)...) instead.
<beach>
phoe: I think I just said that.
<phoe>
welp, yes
* phoe
hides
<solideogloria[m]>
The behaviour I expected was to modify the focus variable which events takes as an argument
<phoe>
you can't have that with a function
<beach>
solideogloria[m]: What programming language do you know that would work that way?
<beach>
Fortran I guess.
<beach>
And C++ if you have a & there.
<solideogloria[m]>
<beach "soli deo gloria: What programmin"> C ?
<beach>
solideogloria[m]: C doesn't work as you expected here.
<phoe>
either return a value that can then be set in EVENTS, or use a macro instead, or use a local variable that encompasses both of those functions
<phoe>
beach: it does, if you pass a pointer and do `*p = foo;`
<solideogloria[m]>
<beach "soli deo gloria: C doesn't work "> with pointers ofc
<beach>
phoe: But this code doesn't pass a pointer.
<phoe>
beach: yes
<phoe>
that's why it's not working :D
<phoe>
they could pass in a locative though, if they like this programming style
<phoe>
pass in a (lambda (x) (setf focus x)) with the FOCUS from EVENTS
<phoe>
and then funcall it with the value they want
<solideogloria[m]>
I could just write the setf in the event case at that point
<beach>
solideogloria[m]: Furthermore, (= focus 0) can be expressed as (zerop focus) which is more specific. And there is a general rule in programming that you should use the most specific construct that will do the job.
<solideogloria[m]>
<beach "soli deo gloria: Furthermore, (="> oh yeah, almost forgot about that
<phoe>
solideogloria[m]: yes, that would be even better
abhixec has quit [Ping timeout: 272 seconds]
<beach>
solideogloria[m]: Moreover, IF is a form in Common Lisp, so you can write (setf focus (if (zerop focus) (1- (length wins)) (1- focus)))
<solideogloria[m]>
that makes more sense
<solideogloria[m]>
didn't even think about that
<beach>
So, anyway, Common Lisp uses call-by-value just like most other programming languages.
isBEKaml has quit [Quit: leaving]
<beach>
The arguments to a function are forms, and they are evaluated. Then a copy of the value is given to the function as an argument, either in a register or on the stack.
<beach>
The main difference compared to C is that values in Common Lisp are references. So if you send a mutable object to a function, then mutating that object inside the function will have visible effects to the caller.
<beach>
But in this case, you are passing a number, and numbers are immutable, and the operation you are doing is not mutating the object anyway, just assigning to the parameter as we explained.
<beach>
But, we already saw it! What are you preparing?
hnOsmium0001 has joined #lisp
<phoe>
for the live chat with non-lisp people
saganman has quit [Quit: WeeChat 1.6]
<beach>
Oh! Nice!
<aeth>
From a C programmer perspective, CL is like a language where everything is &foo, except some of those are immutable (like e.g. numbers) and thus can probably be optimized by the compiler.
<jackdaniel>
does reading old books qualify as a "dead chat"?
<phoe>
jackdaniel: right, "synchronous" is a better word
<beach>
aeth: That is not true, and I think I just said the opposite.
<aeth>
C and C++ really have this strange sort of situation where they make you try to guess whether you should have some data structure be copied or not, which can get really fuzzy when it's at some sweet spot in size... so you can accidentally write slow code.
<Bike>
"everything is &foo" is kind of a confusing phrasing, since C++ uses that syntax for call-by-reference
<beach>
aeth: And I wish you would not confuse the hell out of newbies by bringing up the compiler optimization.
<aeth>
oh, hmm, I think I confused C and C++ then
<aeth>
see? That's the problem, forcing the programmer to think about this.
<aeth>
The compiler knows better.
<Bike>
well lisp is definitely not doing C++ call-by-reference
<beach>
Exactly.
<Bike>
you could say "everything is a pointer", but that's false, and also we don't do pointer operations in lisp
<aeth>
Rephrasing... In CL, everything is indirectly accessed via a pointer (* unless optimized), just not one that you can access.
<beach>
And in C, it would send the address of a variable the value of which can then be modified inside the function, and that is definitely not what Common Lisp is doing.
<beach>
aeth: I wish you would not confuse the hell out of newbies by bringing up the compiler optimization.
<beach>
aeth: You should distinguish between semantics and implementation tricks.
<Xach>
It's interesting to me that if you don't try to think about what it's "really" doing underneath, and aren't comparing it to something else, the semantics seem pretty easy to follow to me. But maybe I've just internalized it too much.
<phoe>
I find it very easy to think it from the places point of view
<phoe>
but the places point of view is not very popular :(
<jackdaniel>
everything is a pointer unless it is an immediate object seems to be a correct description to me -- and function aguments are passed as copies of said pointers
<aeth>
beach: The thing is, someone coming from C or C++ would have as thier first rection "that's slow" if you don't put a "optimizations can happen" asterisk.
<beach>
Xach: I think that simple view is what I am trying to communicate.
<aeth>
You don't have to explain the optimizations, you just say "compilers can optimize it"
<beach>
aeth: Most newbies here aren't sophisticated enough to see that, so I suggest you bring it up only when you see that reaction.
<pfdietz>
mfiano: the interesting part of Hypothesis (or the minimal version, Minithesis) is it gives a universal way of reducing interesting inputs, by recording the random bits used by the generator and replaying using those.
<beach>
jackdaniel: But that's an unnecessary complication for a newbie since the semantics are as if every argument is a reference.
<jackdaniel>
I was referring to what Bike said
<beach>
Oh, sorry.
<jackdaniel>
(in other words, I'm not trying to educate solideogloria[m])
<beach>
Got it.
<jackdaniel>
I agree with Xach: what lisp does is what lisp does is the best approach until you start writing a transpiler
<Xach>
an object with mutable state is the same in the caller or in the function being called. changes to its mutable state will be visible to anything that knows about the object. if there is no mutable state what's "really" happening does not matter.
<aeth>
In response to Bike... Everything is a pointer (that you can't directly access) unless optimized. So it's only false if you go into implementation details (although you can assume that at the very least, all fixnums have this optimization in any reasonable implementation)
<aeth>
Obviously too technical to say to newbies.
<Bike>
the fact that they're pointers IS an implementation detail
<Bike>
i just don't understand what the point of saying they're pointers is to a C programmer. we don't use them like C programmers use pointers
<aeth>
But it's an implementation detail that has to hold on the mainstream architectures unless heavily abstracted (like e.g. a CL that compiles to JS or something)...
<pfdietz>
It's better to say that mutable things in Lisp have object identity. Indeed, visible mutability is a way to define object identity.
<Xach>
i'm reminded of K&R 2nd ed, which tries in some cases to explain C in terms Pascal programmers would understand.
<beach>
That's why I use the term "reference" instead of "pointer".
<beach>
Bike: ^
gabot has quit [Ping timeout: 260 seconds]
gabot has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
attila_lendvai has joined #lisp
<beach>
solideogloria[m]: So I guess you are totally confused now. Sorry about that!
<beach>
solideogloria[m]: Unfortunately, it happens every time.
v_m_v has joined #lisp
<Krystof>
go not to IRC for advice, for they shall say both "nay" and "yea" and "well, actually"
<phoe>
one Lisp hacker says aye, another says nay
davd33 has quit [Quit: Leaving.]
<jackdaniel>
the best way to receive an answer to a question is to provide an invalid statement, then people will rush in to correct you :-)
v_m_v has quit [Remote host closed the connection]
v_m_v has joined #lisp
<aeth>
I guess part of this dispute is if you see Lisp as a Platonic algorithmic language that happens to be implemented in today's hardware (top-down), or as the most convenient way to abstract over the hardware (and OSes) that exists today (bottom-up). And it's kind of both. Especially Common Lisp, which makes a lot of concessions for performance and compatibility.
<aeth>
Something like Forth is clearly the latter and something that's pure FP is clearly the former. CL is in an uncomfortable middle ground.
<solideogloria[m]>
beach: should I use global variables in that code I sent earlier ?
<beach>
aeth: When a newbie is confused about the semantics, how experienced people think of it is beside the point. We just have to find the explanation that is the most appropriate so that the newbie can understand.
<phoe>
solideogloria[m]: not really
<phoe>
in general, use as few of them as possible
<beach>
solideogloria[m]: No, I don't recommend that. Use the return value instead.
<phoe>
(defun foo () (values 1 2 3)) and then (multiple-value-bind (x y z) (foo) ...)
<solideogloria[m]>
I mean in like general, not just that
<phoe>
in general use globals very, very sparingly
<solideogloria[m]>
events is getting those values from another function
<beach>
solideogloria[m]: In general you should avoid globals.
v_m_v has quit [Ping timeout: 260 seconds]
<aeth>
Some people use globals for configuration, which is reasonable. I restrict things a bit further, and don't really use (new) globals at all (with rare exceptions).
dbotton has joined #lisp
rogersm_ has joined #lisp
<aeth>
You don't want to use globals in general because they make threading harder and you might want to use threads one day. (There are a dozen other reasons, but this is the #1 reason today imo.)
<aeth>
Today's machines are 6 to 64 cores. You don't want to make threading hard.
abhixec has joined #lisp
hi_im_buggy has joined #lisp
<jeosol>
In the light of the global/no-global variable discussion, what is a better design to initialize the slots of a class with large number of slots, e.g., > 30, and still retain transparency. In one of my previous iterations, I had &rest and &key ..., in the lambdalist
<jeosol>
then it can start to get very hairy ...
gko_ has quit [Ping timeout: 260 seconds]
attila_lendvai has quit [Ping timeout: 264 seconds]
<aeth>
jeosol: Try using a component-based design? So instead of one object with 30 slots have one object with 6 slots that each contain an object with 5 slots?
<jackdaniel>
you may redefine the function later to provide different default values
<jackdaniel>
(unless you depend on the object itself, then initialize instance is of course the way)
<jeosol>
aeth: good point. something similar was suggested early when i started from comp.lang.lisp (maybe it was you). I have used that in certain places and significantly reduced the slots number,
<aeth>
I don't use c.l.l, but components are trendy.
<jeosol>
It's like a car, where tires, wheel, etc, can be their own objects.
<moon-child>
c.l.l?
<moon-child>
presumably not comp.lang.lisp?
<jeosol>
jackdaniel: thanks for that. So in the function initialize-slot will essentially, have as many slots as I have right?
<aeth>
moon-child: sorry, I thought it was clear from context, i.e. <jeosol> ... from comp.lang.lisp (maybe it was [aeth]) ... <aeth> I don't use c.l.l...
<jeosol>
moon-child: yes, I was referring to comp.lang.lisp and I think that's what aeth meant
<jackdaniel>
jeosol: that's up to you, it is the function you define
<jeosol>
ok.
<jackdaniel>
you may i.e provide otherwise clause that initializes the slot to :<unbound-but-not-really>
rogersm_ has quit []
<jackdaniel>
(using my "case" example)
<jackdaniel>
you could also define your own slot class, but that would be overkill given that you can use initform that way
rogersm has quit [Quit: Leaving...]
<jeosol>
jackdaniel: thank you for the suggestions
<jackdaniel>
sure
<jeosol>
Has anyone used/ or is using esrap reader? not sure dim is here
<dim>
I am
<jeosol>
basically, I'll like to go from a file of input data and then create my final object
<jeosol>
dim: hi
<dim>
been a long time I didn't hack esrap related things though, last time was a full Oracle PLSQL parser ;-)
<jeosol>
I remember, you pointed me over from comp.lang.lisp to look at pgloader code for an example
<dim>
sounds like the kind of thing I would do yes
<jeosol>
haha
<jeosol>
dim: well you did.
<dim>
hehe, well, did you find what you wanted to?
<jeosol>
dim: the pgloader example is still the best one to go to?
<VincentVega>
"In the LUV slides (page 13) by Norvig and Pitman, they explain that WHEN should be used only with Booleans, so I would write (UNLESS (NULL EVENT)...) "
<VincentVega>
beach: they make that particular suggestion w/ regards to AND/OR, not WHEN. (when smth ...) as a nil guard feels like a no-brainer, an idiom. Why be unnecessarily verbose, since it's only a question of preference?
<dim>
it's the only one I know well enough to comment, other examples might be better suited to your use case
<jeosol>
dim: I have a file for a 3rd partly software that I'd like to read and create objects as I read the file. Some of the objects are intermediate slots to a large final objects. For now, I do this process by hand, hence my large lambdalist question earlier
<dim>
well then you might find pgloader parsers useful indeed
<jeosol>
dim: I'd have to go back to it. The 3rd party software file uses include files, i.e., one file includes another file. I am thinking, I should first expand the whole thing, and then use esrap
<jeosol>
jackdaniel, dim: thanks guys. These examples should help me figure things out.
<ralt>
dim: hey, long time no see
<dim>
hey ralt !
<dim>
your distribution project looked nice, I might have to find it again and try it with pgloader... best would be to hook-it up somehow with GitHub and some CI system to produce binaries for a choice of platforms automatically, I suppose
<dim>
I wish I had time to invest in that
<ralt>
Yup, the gitlab repo has a CI example for that
<pfdietz>
I had a use for defglobal in sbcl, as a counter accessed by atomic-incf. Much faster than using explicit locks.
varjag has joined #lisp
<VincentVega>
pfdietz: you mean atomic-incf requires the variable to be global?
<moon-child>
aeth: oh, duh, I need to read better :P
<pfdietz>
I wanted a single counter, regardless of threading.
<VincentVega>
ah i see
amberglint has quit [Quit: Leaving]
dhil has quit [Quit: Leaving]
sauvin has quit [Read error: Connection reset by peer]
vmmenon has joined #lisp
rpg has joined #lisp
mister_m has joined #lisp
Lord_of_Life has quit [Read error: Connection reset by peer]
Lord_of_Life has joined #lisp
rumbler31_ has quit [Ping timeout: 264 seconds]
akoana has quit [Quit: leaving]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life_ is now known as Lord_of_Life
varjagg has joined #lisp
varjag has quit [Ping timeout: 240 seconds]
varjagg is now known as varjag
rumbler31_ has joined #lisp
saturn2 has quit [Ping timeout: 240 seconds]
luckless has quit [Ping timeout: 240 seconds]
luckless has joined #lisp
notzmv has quit [Remote host closed the connection]
hi_im_buggy has quit [Quit: WeeChat 3.0]
<heisig>
Is there a somewhat portable Lisp library for emitting memory barriers?
<Bike>
do any lisps besides sbcl have that?
<heisig>
I don't know.
<heisig>
I am trying to implement an algorithm based on a reference implementation in Java and I'm struggling to translate 'volatile' slots.
clone_of_saturn has joined #lisp
<Bike>
i'm not sure any implementations actually have something like volatile slots
<Bike>
which... iirc are modified sequentially consistently? i haven't stared at the JSR in a while
<Bike>
right yeah.
<Bike>
there's cas sometimes but not a way to mark reads and writes as necessarily atomic
liberliver has quit [Ping timeout: 264 seconds]
<Bike>
if there is a cas you could assume that it's SC and use it for both reads and writes, but that's kind of stupid looking
Lycurgus has joined #lisp
clone_of_saturn is now known as saturn2
nicktick has quit [Ping timeout: 240 seconds]
freshmaker666 is now known as greeb
makomo has joined #lisp
varjag has quit [Remote host closed the connection]
varjag has joined #lisp
miasuji has joined #lisp
<heisig>
Bike: Good idea, I'll give that a try. Maybe I can hide the CAS instructions behind wrapped slot readers and writers.
makomo has quit [Client Quit]
abhixec has joined #lisp
cosimone has quit [Quit: cosimone]
makomo has joined #lisp
makomo has quit [Client Quit]
mrios22 has quit [Ping timeout: 265 seconds]
makomo has joined #lisp
<alandipert>
is the issue here that typical CL thread conventions are per-thread bindings? and lack of a primitive like volatile to denote a mutable value across threads?
<Bike>
it's not really related to dynamic variables.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
<Bike>
i mean it is a little, but it's a deeper issue. the order of things across threads but outside of locks is not defined.
<heisig>
alandipert: I want to implement a fast, lock-free work-stealing deque so I need to enforce some ordering between slot reads and writes.
ebrasca has quit [Remote host closed the connection]
amb007 has quit [Read error: Connection reset by peer]
<Bike>
languages like java and C++ have spent a lot of effort writing standards for these "atomic" operations that we haven't
<moon-child>
yeah memory model spec was a big effort. And they still didn't even get it right :P
amb007 has joined #lisp
<Bike>
it is funny seeing all the C++ stuff that's like "there's also memory_order_consume. you shouldn't use it since it's broken"
lucasb has quit [Quit: Connection closed for inactivity]
<moon-child>
(that's more on c&c++ side; idk if there was anything wrong with java's memory model)
<pfdietz>
In the code I was referring to, in non-sbcl lisps explicit locks were used to access a slot with class allocation (which is a kind of non-special global).
sunset_NOVA has joined #lisp
<Bike>
i think java is fine. it also doesn't have sub-sequential-consistency like C++ does.
<Bike>
abandoning sequential consistency drops you straight into hell
amb007 has quit [Read error: Connection reset by peer]
<heisig>
I just wrote a macro to generate custom slot accessors, such that a memory barrier is emitted before each read, and after each write. That seems to have solved my problem.
amb007 has joined #lisp
terrorjack has quit [Ping timeout: 268 seconds]
rogersm has joined #lisp
frodef has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
andreyorst has joined #lisp
amb007 has joined #lisp
<alandipert>
i've only every studied java but they have the advantage of defining thread semantics, vs the endless bolting-on that seems to happen with c++ (my perception from a distance, nowhere near an expert at c++ myself)
izh_ has joined #lisp
<alandipert>
and my perception of CL is that it was carefully designed to accommodate likely designs without specifying any
<moon-child>
alandipert: c11 and c++11 got a proper memory model, like java
<Bike>
the lisp standard has no mention of threads or particular preparation for them whatsoever. bordeaux threads puts in some effort but nothing for atomics, and i don't think it actually defines a model anyway
terrorjack has joined #lisp
* alandipert
wonders about the origin of the per-thread binding semantic
<Bike>
that was something they agreed on when they came up with bordeaux threads, is my understanding
<Bike>
where "they" means whatever group that did that. it's more recent than the standard
vmmenon has quit [Quit: Leaving]
makomo has quit [Quit: WeeChat 2.9]
makomo has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
<ralt>
I would've thought the per-implementation thread APIs came before bordeaux threads
amb007 has joined #lisp
<Bike>
they do, yes, but there is a gulf between implementing something and defining the semantics for it.
<moon-child>
presumably there is at least *some* relationship between the spec and the preceding implementations, though; no?
<ralt>
the spec makes zero mentions of threads afaik
<Bike>
sure, but you can write code without fully defining all semantics for it. i expect that in at least a few implementations, before they were bordeaux threads "conformant" they hadn't put in any thought into how dynamic bindings interacted with threads
<moon-child>
ralt: I mean bordeaux
<Bike>
i don't think any lisp implementation currently defines what happens if you modify/read data from multiple threads simultaneously, or even says that doing so is undefined
makomo has quit [Client Quit]
<Bike>
several implementations have atomic operations including CAS but i don't think they have models of how they work
makomo has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
abhixec has quit [Ping timeout: 256 seconds]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
makomo has quit [Client Quit]
makomo has joined #lisp
Lycurgus has quit [Quit: Exeunt]
amb007 has joined #lisp
<Bike>
i mean really you have to define concepts like simultaneity. there are ones that are broadly accepted, of course, but it's good to be specific
amb007 has quit [Read error: Connection reset by peer]
<alandipert>
i suppose thread-local bindings don't require one to approach simultaneity, since the mutation is per thread?
makomo has quit [Client Quit]
<alandipert>
whereas something like volatile definitely does
amb007 has joined #lisp
<Bike>
yeah, it's fairly easy to define the semantics if you just have threads and locks
amb007 has quit [Read error: Connection reset by peer]
<Bike>
the dynamic binding stuff kind of isn't related to execution order. if you bind a dynamic variable in a thread, whatever value it had globally is irrelevant, so whether the binding happens before or after modifications of the global value from other threads is irrelevant
amb007 has joined #lisp
<Bike>
before or after or during
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
luckless has quit [Quit: luckless]
luckless has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
surabax_ has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
birdwing has joined #lisp
amb007 has joined #lisp
amberglint__ has joined #lisp
surabax has quit [Ping timeout: 256 seconds]
amberglint__ has quit [Client Quit]
surabax_ has quit [Ping timeout: 256 seconds]
rogersm has quit [Remote host closed the connection]
birdwing has quit [Ping timeout: 272 seconds]
abhixec has joined #lisp
andreyorst has quit [Ping timeout: 246 seconds]
todun has joined #lisp
abhixec has quit [Read error: Connection reset by peer]
<etimmons>
thanks for helping motivate me to finally get a personal site up and running
* phoe
crossposts to /r/Common_Lisp
<ralt>
and there was much rejoicing
<White_Flame>
frodef: (defun or-func (&rest args) (loop for arg in args when arg return arg)) ?
<White_Flame>
you can shortcut because all the args have been evaluated before the call
<frodef>
White_Flame: sure, or (some 'identity args)
<frodef>
.. or (loop for arg in args thereis arg)
<White_Flame>
yeah, lots of options. I thought SOME was out
* White_Flame
should sleep more ;)
dbotton has quit [Quit: This computer has gone to sleep]
<shinohai>
etimmons: Thank you very much, will read now.
<frodef>
White_Flame: nah, just figured there might be some or-func equivalent I'd missed.
aartaka has quit [Ping timeout: 260 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
<_death>
there can't be a straightforward functional equivalent since OR also passes along multiple values
<phoe>
there can be one, you simply ignore non-primary values
<phoe>
as with all function arguments
rogersm has joined #lisp
miasuji has joined #lisp
benjamindc has quit [Remote host closed the connection]
benjamindc has joined #lisp
zaquest has quit [Quit: Leaving]
rogersm has quit [Ping timeout: 246 seconds]
todun has quit [Quit: todun]
dbotton has joined #lisp
<ralt>
etimmons: isn't libdl available at runtime if you link against musl?
<etimmons>
"Sort of" it's a shim that does nothing but return errors (assuming you're statically linking)
<ralt>
annoying
<moon-child>
doesn't musl have its own dynamic linker? Why couldn't they leverage that and link it in too?
<ralt>
etimmons: so I if understand correctly, your patches are essentially (1) make --without-os-provides-dlopen work, and (2) provide this script to dump the lisp image's symbols to a file that you can then compile sbcl with?
<etimmons>
I think one of the reasons is that musl doesn't have a lot of interdependencies between the different libc components and it's very likely that static linking will prune chunks of libc
<etimmons>
And they don't want to deal with reloading those pieces dynamically if a library you later dlopen requires them
<etimmons>
ralt: correct
<ralt>
it's annoying to have to compile sbcl separately for every app :/
Steeve has joined #lisp
<etimmons>
I know... I think there could be a path forward, though. It'd require relaxing the requirement that build ids match between the runtime and core and rejiggering the code to gracefully fail in the presence of the stub libdl
rumbler31_ has quit [Ping timeout: 264 seconds]
<etimmons>
Or you could be overzealous with the libraries you link into the runtime (and overpopulate the linkage table)
<etimmons>
and then only rebuild the runtime when you want to shake out the unused symbols
<ralt>
can't you build a custom runtime from sbcl one's?
<ralt>
so you don't touch sbcl.core et al, you just increment from there?
cantstanya has quit [Ping timeout: 240 seconds]
rumbler31_ has joined #lisp
dbotton has quit [Quit: Leaving]
<etimmons>
Potentially. One thing in the way of that right now is you probably want to develop with :os-provides-dlopen, which can't be present when you build the static runtime. And rebuilding the runtime will change its build ID and it will reject your development core
imode has joined #lisp
<ralt>
no I mean making the runtime into a separate file altogether
pve has quit [Quit: leaving]
cantstanya has joined #lisp
<etimmons>
I don't think I understand what you're suggesting
<ralt>
I think we're talking past each other, yes
<ralt>
what's "your development core"?
<ralt>
the sbcl.core file?
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<etimmons>
In my ideal world we'd develop like normal with a dynamic SBCL runtime and then save-lisp-and-die (with :executable nil) that's my "development core"
<etimmons>
we'd then have a script that pulls the linkage info directly from the core and builds a static runtime
<ralt>
can you provide a stub dlopen() that looks in the static linkage table?
<etimmons>
and then the static runtime would load the "development core" so we don't have to compile the lisp code twice
<etimmons>
Hmmmmm. Probably. I get some feedback early on that was basically "don't build with :os-provides-dlopen and then stub out dlopen"
<etimmons>
But that stub was a no-op. Perhaps a severely restricted but still functional dlopen/dlsym would get a better reception
<ralt>
What I'm thinking is that if the fake dlopen() looks in a static table, and you can dump this static table with save-lisp-and-die, then you solve the problem, no?
<ralt>
I'm not sure if what I'm saying makes sense
<ralt>
Probably input from sbcl devs would be better.
<ralt>
hmmm
<etimmons>
Yes, but save-lisp-and-die can only dump the symbol names. You'll still need a core relink (and recompile of a single file) to get the other half of that table
<etimmons>
s/core relink/runtime relink/
<ralt>
actually
<ralt>
there's this sbcl.o file you can build
<ralt>
it has all the symbols
<ralt>
if you link it with the runtime, you end up with a static binary that supposedly has all the symbols and the other half of the table
<ralt>
but the current problem is that dlopen() will fail because it's the stub
<etimmons>
I'm definitely not a C developer (thank goodness) so it's definitely possible I'm missing something, but I don't see any way to support both dynamically loading foreign libs and creating a static executable without a relink of the runtime at a minimum.
luckless has quit [Quit: luckless]
<etimmons>
Yep, sbcl.o is simply the runtime linked together into an object file
luckless has joined #lisp
<ralt>
I'm not much of a C dev either, but as I understand it, you can do e.g. `gcc -static my-dynamic-runtime sbcl.o -o static-runtime`, no? as long as `my-dynamic-runtime` has a dlopen() that looks in itself first?
<etimmons>
Looking back at some of my other early feedback, there may be a way to reuse the core between the dynamic and static runtimes, so the Lisp code wouldn't have to be recompiled at least
<ralt>
do you have a link to that sbcl-devel thread?
<ralt>
as I understand it, the problem is that the symbols are actually linked into the executable with gcc, but sbcl insists on loading them for its linkage table, and is not succeeding because it uses dlopen(). In my naive mind, it means that making reinit() use another way in the case of static builds to find the symbol should be the right way.
rogersm has joined #lisp
<ralt>
and maybe it doesn't even need a linkage table on the C side if it's a static binary.
Steeve has quit [Quit: end]
rogersm has quit [Ping timeout: 246 seconds]
<ralt>
ok yeah, prefilling the table is what the shrinkwrap stuff is about
mathrick has quit [Ping timeout: 272 seconds]
<ralt>
which is what you wanted to avoid because of arm