thecoffemaker has quit [Quit: So long and thanks for all the fish!]
choegusung has quit [Ping timeout: 258 seconds]
torbo has quit [Remote host closed the connection]
kaftejiman has quit [Remote host closed the connection]
EvW has quit [Ping timeout: 260 seconds]
random-nick has quit [Ping timeout: 240 seconds]
bsd4me has joined #lisp
nicktick has joined #lisp
bsd4me has left #lisp ["Leaving"]
dilated_dinosaur has quit [Ping timeout: 246 seconds]
EvW has joined #lisp
prite has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 258 seconds]
Bike has quit [Quit: Lost terminal]
chiota has quit [Quit: leaving]
Oladon has quit [Quit: Leaving.]
edgar-rft has joined #lisp
chiota has joined #lisp
Oladon has joined #lisp
choegusung has joined #lisp
choegusung has quit [Quit: leaving]
Necktwi has quit [Ping timeout: 265 seconds]
gko_ has joined #lisp
jonatack has quit [Ping timeout: 240 seconds]
jonatack has joined #lisp
Necktwi has joined #lisp
snowyfox has quit [Ping timeout: 240 seconds]
wsinatra_ has joined #lisp
bg__ has joined #lisp
bilegeek has quit [Ping timeout: 260 seconds]
Jesin has quit [Quit: Leaving]
EvW has quit [Ping timeout: 240 seconds]
Jesin has joined #lisp
georgiePorgie has joined #lisp
georgiePorgie has quit [Client Quit]
mangoicedtea has quit [Quit: Leaving]
rumbler31 has quit [Remote host closed the connection]
elxbarbosa has quit [Remote host closed the connection]
dyelar has quit [Quit: Leaving.]
terpri has quit [Ping timeout: 240 seconds]
mrcom has quit [Ping timeout: 265 seconds]
renzhi has quit [Ping timeout: 240 seconds]
wsinatra_ has quit [Quit: WeeChat 2.9]
mrcom has joined #lisp
terpri has joined #lisp
brj has quit [Ping timeout: 240 seconds]
brj has joined #lisp
Alfr_ has joined #lisp
Alfr has quit [Ping timeout: 260 seconds]
rumbler31 has joined #lisp
Jeanne-Kamikaze has joined #lisp
<beach>
Good morning everyone!
elxbarbosa has joined #lisp
<markasoftware>
hi
Necktwi has quit [Ping timeout: 240 seconds]
Necktwi has joined #lisp
Alloc has quit [Ping timeout: 260 seconds]
Alloc has joined #lisp
u0_a199 has joined #lisp
paul0 has joined #lisp
gravicappa has joined #lisp
_paul0 has quit [Ping timeout: 265 seconds]
Jeanne-Kamikaze has quit [Quit: Leaving]
u0_a199 has quit [Quit: WeeChat 2.9]
akoana has quit [Quit: leaving]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
Lord_of_Life_ is now known as Lord_of_Life
_oldtopman has quit [Ping timeout: 272 seconds]
ggole has joined #lisp
shangul has joined #lisp
terrorjack has quit [Ping timeout: 240 seconds]
<beach>
Today, for my daily exercise, I watched the first half of a presentation by Brandon Rhodes, entitles "Python as C++'s limiting case", given at code::dive 2018. It reminded me of something I frequently repeat, namely "People spend a lot of time and energy to avoid learning Common Lisp."
<beach>
This presentation also reminded me of the sorry state of the fields of computing, programming, and software engineering.
terrorjack has joined #lisp
cgay_ has joined #lisp
splittist_ has joined #lisp
mpontillo_ has joined #lisp
thonkpod_ has joined #lisp
mgsk has quit [Ping timeout: 240 seconds]
mpontillo has quit [Ping timeout: 240 seconds]
FennecCode has quit [Ping timeout: 240 seconds]
voidlily has quit [Ping timeout: 240 seconds]
bg__ has quit [Ping timeout: 240 seconds]
cgay has quit [Ping timeout: 240 seconds]
gravicappa has quit [Ping timeout: 240 seconds]
thonkpod has quit [Ping timeout: 240 seconds]
splittist has quit [Ping timeout: 240 seconds]
splittist_ is now known as splittist
cgay_ is now known as cgay
gravicappa has joined #lisp
mpontillo_ is now known as mpontillo
<aeth>
The most disappointing part of modern software seems to be design. Every time there's a new update that changes the design, usability and feature discoverability go way down. Most recently, with Firefox for Android.
kopiyka has quit [Ping timeout: 240 seconds]
RagnarDanneskjol has quit [Ping timeout: 240 seconds]
voidlily has joined #lisp
mgsk has joined #lisp
RagnarDanneskjol has joined #lisp
<aeth>
Minimalism has gone too far, for at least 5 years now.
Oddity_ has quit [Ping timeout: 240 seconds]
ggoes has quit [Ping timeout: 240 seconds]
<aeth>
And any feature that telemetry shows is uncommonly used will eventually get removed, no matter how useful it is
Alloc has quit [Ping timeout: 240 seconds]
save-lisp-or-die has quit [Read error: Connection reset by peer]
jello_pudding has quit [Ping timeout: 240 seconds]
tfb has quit [Ping timeout: 240 seconds]
lonjil has quit [Ping timeout: 240 seconds]
<beach>
Well, I was mostly referring to the time and energy spent by the developers, project leaders, etc. But maybe this minimalism trend is due tot he fact that their tools are so complex that they can't do otherwise.
ggoes has joined #lisp
ggole- has joined #lisp
vutral has quit [Ping timeout: 240 seconds]
yonkunas has quit [Ping timeout: 240 seconds]
yonkunas has joined #lisp
jgodbout has quit [Ping timeout: 240 seconds]
elflng has quit [Ping timeout: 240 seconds]
tfb has joined #lisp
alandipert has quit [Ping timeout: 240 seconds]
lonjil has joined #lisp
jgodbout has joined #lisp
midre has quit [Ping timeout: 240 seconds]
vutral has joined #lisp
ggole has quit [Ping timeout: 240 seconds]
gko_ has quit [Ping timeout: 258 seconds]
alandipert has joined #lisp
FennecCode has joined #lisp
lottaquestions_ has joined #lisp
midre has joined #lisp
jbgg_ has joined #lisp
elflng has joined #lisp
_Posterdati_ has joined #lisp
jibanes has quit [Ping timeout: 240 seconds]
Posterdati has quit [Ping timeout: 240 seconds]
lottaquestions has quit [Remote host closed the connection]
jbgg has quit [Ping timeout: 240 seconds]
bilegeek has joined #lisp
jello_pudding has joined #lisp
elxbarbosa has quit [Quit: ERC (IRC client for Emacs 27.1)]
jibanes has joined #lisp
<aeth>
beach: Well, cutting features seems to be incredibly common these days, so perhaps the issue is maintaining software.
space_otter has quit [Remote host closed the connection]
Alloc has joined #lisp
<beach>
That's part of what I was referring to. The hypothesis was that, in order to simplify their work (design, first-time development, maintenance), since their main tool (i.e., the programming language) makes their task so hard, they need to cut down on the features.
ecbrown has joined #lisp
<beach>
What was so "interesting" about this presentation was that the speaker took features of C, C++, Perl, Awk, JavaScript, etc. and for each one stated why it was problematic. Then he pretended to design a new and improved scripting language that fixed the problem. It so happened that the fix was exactly what Python does.
<beach>
However, what he failed to mention was that Lisp had fixed these problems ages ago, and in a better way than Python does. Too bad that his fixes are going to result in a scripting language rather than a general-purpose programming language like Common Lisp.
<beach>
I mean, I think he failed to mention that, not as a deliberate omission, but by simple ignorance. Hence my analysis about the sorry state of the fields of computing.
bocaneri has joined #lisp
<aeth>
Doesn't Python have odd scoping rules?
<ggole->
It has function scope.
<aeth>
Scope was solved by Scheme in 1975.
Alloc has quit [Ping timeout: 246 seconds]
<aeth>
So only C has an excuse there
<beach>
I thought scope was solved by Algol60.
<ggole->
Arguably earlier in Algol, which had entirely sane lexical scoping rules
<beach>
Exactly.
<aeth>
hah
<aeth>
Well, I guess the concept was at least "popularized by" Scheme
Alloc has joined #lisp
<ggole->
Actually C's scoping rules (for variables) are also fine, that's not really the part of C that is bad
<aeth>
C/C++ let you do a { /* foo */ } i.e. brackets with no preceding keyword, and it behaves not too unlike a LET
<aeth>
Of course, I would've never even bothered to try before I learned Lisp
<beach>
aeth: That's still local scope.
<beach>
aeth: Keyword or {, same thing.
mrcom has quit [Read error: Connection reset by peer]
<beach>
aeth: I would not attribute popularizing scoping rules to Scheme. Pretty much every language invented in the spirit of Algo60 got it right. Like Simula, Pascal, etc.
narimiran has joined #lisp
<beach>
aeth: And, when I programmed in C, I considered local scope to be an important tool for limiting the portion of the code where variables are in scope. It is (or should be) an important tool for every developer in every language. But, again, ignorance strikes in the field of computing.
ecbrown has quit [Remote host closed the connection]
shka_ has joined #lisp
<beach>
I vividly recall teaching this tool to students in 1988, and I had to justify it by telling them about compiler design, because they were convinced that, if a variable were introduced inside a loop, then it somehow needed to be "created" for each iteration, thereby slowing down the code.
<beach>
And this necessity is part of the reason why I think every serious developer must know about compiler technology, computer architecture, and programming-language design.
<beach>
If they don't know about those things, they are going to make incorrect guesses, and the code is going to reflect those guesses in so many negative ways.
<no-defun-allowed>
My C++ lecturer told us that not having to zero initialise variables makes C++ programs faster than other languages. I suppose data flow analysis wasn't invented that long ago...
<beach>
... which only goes to show that ignorance is not limited to students and developers.
<beach>
Kildall's PhD dissertation on the subject dates from 1972.
<aeth>
DISASSEMBLE does a good job attacking false assumptions of "if I put this variable here it'll slow down my code" since often you'll see absolutely no difference.
<no-defun-allowed>
That's probably about the time the people who wrote the programming curriculum for high schools here are stuck in.
wsinatra has quit [Quit: WeeChat 2.9]
<beach>
no-defun-allowed: Heh!
<no-defun-allowed>
aeth: I demonstrated that to be false by writing two programs, one with `int foo = 0; foo = 3;` and one with `int foo = 3;` You only needed to use -O1 to convince GCC to remove the redundant initialization.
<ggole->
There's a bit of truth in that allowing uninitialised parts of arrays can avoid work
<aeth>
no-defun-allowed: GCC and variables, yes... arrays in $random_language, maybe not
<ggole->
The 'variables' makes me suspect that the person didn't actually understand that
<no-defun-allowed>
Yeah, arrays and objects are where that is less obviously true, but from memory, allocating arrays of objects on the stack would still call the default constructor in C++.
<MichaelRaskin>
Then in many cases asking for an array of size where this matters might include getting more pages from OS, which come pre-zeroed for security reasons
<beach>
Oh, Frances E. Allen has a paper from 1969.
<ggole->
There's a bunch of hard-to-remember rules about initialisation, since it's C++
<aeth>
MichaelRaskin: then clearly, use a less secure OS, for performance reasons
<aeth>
what we need is DOS, but for x86-64
toorevitimirp has joined #lisp
<aeth>
(we don't)
<no-defun-allowed>
I hear the curriculum plan that started this year is less FUBAR, fortunately.
<MichaelRaskin>
«Compilers lie. CPUs lie even more. GPUs reject the notion of truth.»?
<no-defun-allowed>
Or was that the textbook? I remember the teacher and I looked at the draft of something to do with this year's curriculum and we were both very relieved to read it.
brj has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
(Either way, that's not my problem now, but 1972 is about where it is. You can stick data together with records and one-dimensional arrays, and if you go to a good school, you even get some objects.)
<aeth>
technically, everything's an object
<no-defun-allowed>
Anyways, what's the most straightforward way to define a method that has a specializer that's only available when the defining form is evaluated? Something like (let ((value ...)) (defmethod foo ((bar <value goes here>)) ...))
mrcom has joined #lisp
<no-defun-allowed>
ENSURE-METHOD doesn't know anything about the lexical environment, which is less than ideal. Do I go about reimplementing that?
<beach>
aeth: What makes you think that everything is an object?
<no-defun-allowed>
Er, but then you can't compile the lambda form in the appropriate lexical environment. /me sighs and sticks to EVAL.
<beach>
no-defun-allowed: What implementation?
<no-defun-allowed>
Just using closer-mop on SBCL now.
<beach>
no-defun-allowed: Normally, the method function should be evaluated in the scope of the DEFMETHOD form.
<beach>
Oh, but that's not the method function is it.
<beach>
It's the specializer.
<no-defun-allowed>
Oh wait.
<aeth>
beach: not everything is an object?
<aeth>
because that's the terminology I learned...
<no-defun-allowed>
I've never really messed with specializers, but can I do (let ((x ...)) (defmethod foo ((bar (eql x))) ...))? CLHS on DEFMETHOD suggests I can.
<beach>
aeth: That's right, and I often repeat that fact. Affirmations like that, when examined, really turn out to mean only "every object is an object".
<aeth>
beach: what isn't an object?
<beach>
Define the context, and I'll tell you. Common Lisp?
<aeth>
special forms, maybe?
<no-defun-allowed>
aeth: Are you an object?
<aeth>
yes, in CL
<beach>
Then a comment is not an object. A place is not an object.
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
<beach>
Those are just two examples. I think I can find several others.
<beach>
A type is not an object.
<aeth>
I can't deny that a comment is not an object. Does this mean that "everything is an object", which is very frequently published, is false?
<beach>
Yes, it is false. Always has been.
<beach>
And I repeat that frequently.
<MichaelRaskin>
A comment doesn't even exist from code point of view, though. In the AST where comment is representable, the comment is typically represented by an object
<aeth>
What makes a type not an object?
<beach>
aeth: It is described by a type specifier, but that type specifier is not the type. But it doesn't matter. I have already found two counterexamples.
<beach>
An "exceptional situation" is not an object.
<beach>
I could go though the glossary if you like.
<aeth>
my worldview has already been shattered today
<MichaelRaskin>
It's arguable how different is from saying a physical neutron is not a Common Lisp object
<beach>
MichaelRaskin: "neutron" is not mentioned in the Common Lisp standard, or at least not in the normative part.
<beach>
"comment" and "place" both are, though.
<aeth>
MichaelRaskin: good idea, we need a "neutron" UI framework to compete with Electron
mrcom has quit [Ping timeout: 265 seconds]
<no-defun-allowed>
"Electron should have been called the top quark based on its size"
brj has joined #lisp
<MichaelRaskin>
I am pretty sure «everything is an object» is limited to «everything fully representable»
holycow has joined #lisp
<holycow>
join #python
<no-defun-allowed>
Think I'll pass. (did you miss the /?)
<aeth>
everything "first class", perhaps, but there might be some things that aren't "first class" that are objects
<beach>
aeth: Thank you. Now you are only epsilon away from "every object is an object"
<holycow>
lol, yes sorry
<beach>
Here are some more: "exit point", "block", "character case", "compiler",
mrcom has joined #lisp
<aeth>
well, a compiler is a collection of objects
<no-defun-allowed>
What do you think of the return value of BYTE? That's an object, but one of implementation-dependent representation, which frequently borrows some other type.
<MichaelRaskin>
Compiler is a meta notion anyway
<beach>
MichaelRaskin: Which means that it is not an object, which is what I said.
<aeth>
MichaelRaskin: I mean, a compiler isn't an object just like you're not an atom
<MichaelRaskin>
Which means its status is closer to «computer» than to «integer»
<no-defun-allowed>
I guess I just stated that it's an object. Oh well. Would be nice if it wasn't frequently a cons or an integer or something that didn't really tell you if it is in fact a byte specifier.
<White_Flame>
a bit in a bitvector is not an object
ldbeth has joined #lisp
<ldbeth>
good afternoon
<White_Flame>
a type is not an object
<no-defun-allowed>
Hello ldbeth.
<beach>
I already mentioned "type".
<White_Flame>
ah, k
<beach>
But the point is that it is not the case that "everything is an object".
CrazyEddy has joined #lisp
<White_Flame>
right, it's just interesting to try to enumerate the non-object ones
<beach>
Oh, you have a lot of work in front of you. :)
<beach>
Just go through the glossary and look at all the nouns.
<beach>
"file system"
<ldbeth>
you can try to describe everything as an abstract object specified by their behavior though
<markasoftware>
if i want to support declarations in the `body` of my macro, is there a better alternative to wrapping it in an unnecessary `(let () ,@body)` ?
<markasoftware>
if the immediately surrounding form otherwise is not one that supports declarations (in this case, progn)
<MichaelRaskin>
Actually, you now convince me that everything is an object
<aeth>
comments?
<beach>
aeth: "comment" was the first thing I mentioned.
<MichaelRaskin>
Everything assignable to a variable, sure, but _that_ clarification is _really_ not news to me
<aeth>
beach: yes, I was reminding MichaelRaskin
<MichaelRaskin>
I did not forget
<beach>
MichaelRaskin: Like I said, it boils down to "every object is an object".
<White_Flame>
I think that places & types are probably the most interesting, directly representable, non-objects
<MichaelRaskin>
Assignable to a variable being the same as an object is an informative claim
<White_Flame>
many of these other things are notions about the code
<MichaelRaskin>
They are describable, not representable
<MichaelRaskin>
In-model and external-view notions being different is a distinction too trivial to discuss
<White_Flame>
right, there's a direct source code representation which implies the thing, but is not the thing
<MichaelRaskin>
Not representable, because, say, equality is undecidable
ldbeth has quit [Quit: rcirc on GNU Emacs 26.3]
ldbeth has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
<beach>
aeth: Perhaps what you mean was "Every Common Lisp datum is an object"?
orivej has joined #lisp
<beach>
meant
jonatack has quit [Quit: jonatack]
pve has joined #lisp
<aeth>
beach: should that be the concise response next time someone says "everything is an object"?
<beach>
I basically already responded that. From the vocabulary: "object n. 1. any Lisp datum.", so we have now reached "every object is an object".
<beach>
TADA!
tumdum has quit [Remote host closed the connection]
tumdum has joined #lisp
<MichaelRaskin>
Note that «everything one can assign to a variable is an object in Common Lisp OOP system» is the same claim and holds even without lisp isolationism
tobias_ has quit [Quit: Leaving]
zxcvz has joined #lisp
ldbeth has quit [Quit: ERC (IRC client for Emacs 26.3)]
_Posterdati_ is now known as Posterdati
notzmv has quit [Ping timeout: 240 seconds]
hendursa1 has joined #lisp
rumbler31 has quit [Ping timeout: 240 seconds]
hendursaga has quit [Ping timeout: 240 seconds]
Inline has joined #lisp
Oladon has quit [Quit: Leaving.]
tuz_ has joined #lisp
jonatack has joined #lisp
<jackdaniel>
I would be more concerned if some objects were not objects
<aeth>
I'd file a bug if that was the case in ECL
<aeth>
It would be fun to have an OBJECTP that always returns T
jonatack has quit [Ping timeout: 258 seconds]
<jackdaniel>
I mean that it is problematic from the classical logic perspective
<no-defun-allowed>
What if you manage to weasel out whatever the unbound representation is?
jonatack has joined #lisp
<no-defun-allowed>
Today I was greeted by "The value #<unbound> is not of type FIXNUM" in my test suite.
<jackdaniel>
the only way out is to say, that objects do not exist :)
<MichaelRaskin>
jackdaniel: that would _also_ contradict «some objects are not objects»
ralt has joined #lisp
<jackdaniel>
true
<jackdaniel>
exists and not exists
zaquest has quit [Quit: Leaving]
<jackdaniel>
so there is no way out I suppose
<phoe>
no-defun-allowed: is that ABCL?
<no-defun-allowed>
phoe: SBCL; it does have an "unbound" value.
<no-defun-allowed>
#.sb-pcl:+slot-unbound+
<phoe>
ah yes, the value of (sb-kernel:make-unbound-marker)
<edgar-rft>
Re: CLHS Glossary "object n. 1. any Lisp datum." - The Oxford Dictionary defines "datum" as "fact or piece of information" what means that Lisp objects are not restricted to Lisp data types.
retropikzel has joined #lisp
iAmDecim has joined #lisp
<no-defun-allowed>
Is the Oxford Dictionary prescriptive of American English?
igemnace has quit [Quit: WeeChat 2.9]
iAmDecim has quit [Ping timeout: 240 seconds]
<beach>
It is Oxford, Alabama.
<no-defun-allowed>
So it is.
<edgar-rft>
Okay, I agree that for USAian education standards Wikipedia would be more appropriate.
zaquest has joined #lisp
X-Scale has joined #lisp
theothornhill has joined #lisp
mangul has joined #lisp
cosimone has joined #lisp
<theothornhill>
What is a good way to use own tools in common lisp? Right now I just use save-lisp-and-die, then alias that executable.
<theothornhill>
or do people live in the repl, loading systems etc as they go?
shangul has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
I would say living in the REPL is more common.
<theothornhill>
Seems a little slow to run small utilities that just produce some info, say like some weather info from an api etc
<no-defun-allowed>
What do you mean by tools though? Would you have any reasonable interface that isn't the shell?
<no-defun-allowed>
In that case, then that probably would be a good choice.
<theothornhill>
By tools I mean the unixy I/O style small apps. The ones where you don't need a living image, when it is "done"
gargaml has joined #lisp
mrcom_ has joined #lisp
mrcom has quit [Ping timeout: 265 seconds]
toorevitimirp has quit [Ping timeout: 240 seconds]
random-nick has joined #lisp
<edgar-rft>
theothornhill: I usually use Emacs Lisp for small-n-dirty shell programming gimmicks, Common Lisp always inculudes the entire compiler and lots of other stuff in its executables.
hendursa1 has quit [Remote host closed the connection]
<no-defun-allowed>
The one command line program I have written uses the compiler.
<jackdaniel>
not /always/, i.e in ecl libcmp.fas is loaded only after the compiler is invoked for the first time
hendursaga has joined #lisp
<jackdaniel>
(you may build everything into ecl so it is always loaded as an option)
<edgar-rft>
thanks for the info, and please built lots of money into ecl to that I can load it as an option :-)
<jackdaniel>
I don't think that anyone would tell you *not* to use ecl for small-n-dirty shell programming gimmics, but I don't know what is a nature of your job
<edgar-rft>
I first wanted to suggest using C instead of Lisp but I hadn't thought aboout the option that ecl uses C under the hood
<edgar-rft>
what is just one more reason to use ecl more often :-)
ralt has quit [Quit: Connection closed for inactivity]
<theothornhill>
Yeah, I've used elisp and c for that previously (and still do). Perhaps its not the best fit for cl anyways
dilated_dinosaur has joined #lisp
bilegeek has quit [Quit: Leaving]
cosimone has quit [Quit: Quit.]
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
<edgar-rft>
theothornhill: One of the reasons why Unix and its "small and simple" philosophy was created was to overcome the "monolithity" of programming environments like Lisp (at that time). So it's not really a surprise that Common Lisp and the Unix shell are not best friends. But ecl shows that there *are* people who care about the interoperability between C (Unix) and Lisp.
nicktick has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
I thought it was to kludge around having small address spaces.
toorevitimirp has joined #lisp
<no-defun-allowed>
But I guess that's a similar concern.
<edgar-rft>
According to Dennis Ritchie C is the most inappropriate language to write big programs in :-)
<edgar-rft>
...but this is #lisp not #c...
<theothornhill>
Yeah, makes sense
narimiran has joined #lisp
save-lisp-or-die has joined #lisp
jonatack has quit [Ping timeout: 240 seconds]
frgo_ has joined #lisp
nicktick has joined #lisp
frgo has quit [Ping timeout: 244 seconds]
bitmapper has quit [Ping timeout: 264 seconds]
Necktwi has quit [Ping timeout: 265 seconds]
nicktick has quit [Ping timeout: 264 seconds]
Necktwi has joined #lisp
mangul is now known as shangul
EvW1 has joined #lisp
seok has joined #lisp
theothornhill has quit [Ping timeout: 264 seconds]
jonatack has joined #lisp
Alloc has quit [Ping timeout: 256 seconds]
hendursaga has quit [Quit: hendursaga]
hendursaga has joined #lisp
adip_ has joined #lisp
Alloc has joined #lisp
alfonsox has joined #lisp
ralt has joined #lisp
renzhi has joined #lisp
holycow has quit [Quit: Lost terminal]
EvW1 has quit [Ping timeout: 244 seconds]
notzmv has joined #lisp
alfonsox has quit [Ping timeout: 245 seconds]
adip_ has quit [Quit: Lost terminal]
retropikzel has quit [Ping timeout: 240 seconds]
Lord_of_Life has quit [Read error: Connection reset by peer]
Lord_of_Life has joined #lisp
<grewal>
fwiw, for small tools like that I've had luck using a long running lisp image in the background and writing a tiny script that passes command line args through a pipe
mangoicedtea has joined #lisp
<grewal>
If you have enough tools, you can turn it into a busybox-like sort of thing where the image contains all the tools and it dispatches based on the name used to invoke it
_jrjsmrtn has quit [Ping timeout: 265 seconds]
__jrjsmrtn__ has joined #lisp
alfonsox has joined #lisp
Inline has quit [Ping timeout: 240 seconds]
gargaml has quit [Ping timeout: 240 seconds]
gargaml has joined #lisp
Alloc has quit [Ping timeout: 258 seconds]
Alloc has joined #lisp
seok has quit [Remote host closed the connection]
orivej has joined #lisp
<MichaelRaskin>
Me, I just have a prebuilt image with the tools I want to invoke, and pass it '--eval'. Start-up overhead is quite low
ldbeth has joined #lisp
ldbeth has left #lisp ["ERC (IRC client for Emacs 26.3)"]
nicktick has joined #lisp
Alloc has quit [Ping timeout: 260 seconds]
Alloc has joined #lisp
retropikzel has joined #lisp
ym has joined #lisp
retropikzel has quit [Client Quit]
wsinatra has joined #lisp
kingragworm has joined #lisp
kingragworm has quit [Remote host closed the connection]
krid has joined #lisp
krid has quit [Ping timeout: 256 seconds]
mangul has joined #lisp
shangul has quit [Ping timeout: 264 seconds]
shifty has quit [Ping timeout: 265 seconds]
liberliver has quit [Ping timeout: 260 seconds]
cosimone has joined #lisp
brj has quit [Ping timeout: 240 seconds]
brj has joined #lisp
gko_ has joined #lisp
liberliver has joined #lisp
bsd4me has joined #lisp
mseddon has joined #lisp
bsd4me has left #lisp [#lisp]
bitmapper has joined #lisp
CrazyEddy has quit [Ping timeout: 265 seconds]
theseb has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
paines has joined #lisp
<paines>
hi
<beach>
Hello paines.
<beach>
paines: Are you new here? I don't recognize your nick.
<paines>
beach, well, I use irc every now and then. haven't been here in ages
<beach>
I see.
<beach>
What made you come back?
<paines>
probles :-p
liberliver has quit [Ping timeout: 272 seconds]
<beach>
"problems"? Ouch!
<paines>
I am fiddeling around with a smaller project which uses SDL2 and now I am wondering why I cannot call a function which seem to be there, sdl-set-hint\
mangoicedtea has quit [Quit: Leaving]
<beach>
I am afraid that's not my cup of tea. I am guessing that it also involves FFI, yes?
<paines>
yes
<beach>
Definitely not my cup of tea then.
<beach>
Sorry.
<paines>
beach, no worries. thanks anyway
<paines>
I figured it out ;) Looks like it's important to be in the right environment :D
frgo_ is now known as frgo
ralt has quit [Quit: Connection closed for inactivity]
theseb has left #lisp ["Leaving"]
renzhi has quit [Ping timeout: 258 seconds]
Necktwi has quit [Ping timeout: 258 seconds]
Necktwi has joined #lisp
Bourne has quit [Ping timeout: 258 seconds]
iAmDecim has joined #lisp
cpc26 has joined #lisp
Aurora_v_kosmose has quit [Ping timeout: 240 seconds]
<wsinatra>
quit
wsinatra has quit [Quit: WeeChat 2.9]
cpc26 has quit [Remote host closed the connection]
wsinatra has joined #lisp
Aurora_v_kosmose has joined #lisp
Necktwi has quit [Ping timeout: 265 seconds]
paines has quit [Ping timeout: 240 seconds]
toorevitimirp has quit [Ping timeout: 258 seconds]
Oladon has joined #lisp
Necktwi has joined #lisp
alfonsox has quit [Remote host closed the connection]
iAmDecim has quit [Ping timeout: 265 seconds]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 258 seconds]
edgar-rft has quit [Quit: Leaving]
Lord_of_Life_ is now known as Lord_of_Life
<jcowan>
beach: I don't think it's correct to say Python is not a general-purpose programming language. "Scripting language" is basically a way of saying "language I don't like"
<jcowan>
If gcc had a compile-and-go option, C would be a scripting language.
<jcowan>
Indeed, that is not strong enough: there are, it seems, many C interpreters, so C is indeed a scripting language.
jeosol has joined #lisp
<scymtym>
maybe saying /cpython/ is a scripting /environment/ would be more accurate since it ticks several of the boxes: cannot make (afaik) standalone binaries, does not compile to native code, is effectively single-threaded and arguably executes slower than "non-scripting languages". but i agree that "scripting language" is not a very useful way to categorize languages or even implementations
<jcowan>
There's a number of tools that let you create Python standalone files. The CPython interpreter is bundled in with necessary .pyc and .so/.dll files, and everything just gets set up.
<jcowan>
Fortran has parallelism but not concurrency
<jcowan>
Compiling into native code has the problem that it is neither portable nor stable. Larceny Scheme compiles into 32-bit x86, for which you have to load special libraries on Linux, and I expect support for them to rot over time (already WSL1 does not have it). Fortunately it also compiles to C in a version known as Petit Larceny.
Oddity_ has joined #lisp
<p_l>
jcowan: it's possible to make a stable binary on linux - it's the Glibc that doesn't want to cooperate
<p_l>
(Go for example makes binaries that depend only on kernel being above certain version when you use certain command line flags)
Oddity__ has joined #lisp
yitzi has quit [Read error: Connection reset by peer]
jeosol has quit [Remote host closed the connection]
mrcom_ has quit [Ping timeout: 265 seconds]
mrcom_ has joined #lisp
Oddity_ has quit [Ping timeout: 260 seconds]
liberliver has joined #lisp
Bourne has joined #lisp
jeosol has joined #lisp
<White_Flame>
"scripting" tends to indicate that its primary behavior is to invoke behavior of other things outside the script
<White_Flame>
while "programming" tends to indicate defining the primary behavior in the code itself
<White_Flame>
while those definitions still exist on a gradient, I think that's likely the common intention of those terms
<p_l>
Then Python is heavily biased towards scripting
<White_Flame>
if what you're doing is managing calls to external C libraries, then probably yeah
<White_Flame>
while Lisp is kinda weak at scripting, because of its strong focus on its own image
<p_l>
Well, anything else can quickly hit performance limits that result in red-eyed sysadmin going all BOFH on you
<White_Flame>
(although obviously you can do programming in python and scripting in CL)
* p_l
was the sysadmin in one case
<jcowan>
The last few jobs have involved programming in Python and occasionally scripting in bash.
<jcowan>
s/The/My
Necktwi has quit [Ping timeout: 240 seconds]
Necktwi has joined #lisp
cosimone has quit [Quit: Quit.]
<beach>
jcowan: I was just quoting the presentation I saw.
mangul is now known as shangul
abhixec has joined #lisp
<beach>
I was under the impression that the term was used by the creator of a language to mean "I hav no intention, or not enough knowledge, to make it fast enough for general use."
Aurora_v_kosmose has quit [Ping timeout: 240 seconds]
* beach
vanishes until tomorrow morning.
cosimone has joined #lisp
yitzi has joined #lisp
mseddon has quit [Read error: Connection reset by peer]
space_otter has joined #lisp
Necktwi has quit [Ping timeout: 240 seconds]
Aurora_v_kosmose has joined #lisp
mokulus has joined #lisp
EvW has joined #lisp
Oladon has quit [Quit: Leaving.]
Necktwi has joined #lisp
shangul has quit [Ping timeout: 258 seconds]
gko_ has quit [Ping timeout: 264 seconds]
<jasom>
I agree that scripting is primarily about automating external tools. The bourne shell is the clasic example of a scripting language. This actually gells with beach's definition because if you spend 90+% of your time in external tools then there really isn't a point in making the language fast enough for general use.
<p_l>
jasom: that's core proposal of Python, pretty much
<p_l>
any time you have more pure-python work, it's PITA
<p_l>
on a completely unrelated note, python exception handling is hilariously bad
ym has quit [Quit: Leaving]
yitzi has quit [Read error: Connection reset by peer]
ecraven has quit [Quit: bye]
ecraven has joined #lisp
kikuchi has joined #lisp
liberliver has quit [Ping timeout: 260 seconds]
Lycurgus has joined #lisp
mrcom__ has joined #lisp
mrcom_ has quit [Ping timeout: 265 seconds]
twocats has joined #lisp
theothornhill has joined #lisp
Oladon has joined #lisp
jurov has joined #lisp
jurov_ has quit [Ping timeout: 265 seconds]
jeosol has quit [Remote host closed the connection]
abhixec has quit [Ping timeout: 240 seconds]
shka_ has quit [Ping timeout: 246 seconds]
<jcowan>
p_l: What's bad about Python exception handling other than only having termination semantics?
<p_l>
jcowan: I don't know if it's just the library I'm using, or the exception system itself, but nested exceptions, or specifically, when you catch an exception inside exception handlers, lead to very hairy failures
<p_l>
which, in my case, lead to "robot not moving, production stopped"
<jcowan>
But if the inner exception is coming from C or something, then who knows.
<p_l>
jcowan: it's all Python code, and to be honest, pretty ugly :/
<jcowan>
"This building is pretty ugly and a little big for its site."
mrcom__ has quit [Ping timeout: 265 seconds]
mrcom__ has joined #lisp
theothornhill has quit [Ping timeout: 258 seconds]
<p_l>
jcowan: I might have been tempted, at times, to reimplement it in CL
kikuchi has quit [Quit: WeeChat 2.3]
<p_l>
but there wasn't even time to study the spec
<p_l>
and the server side implementation (which I don't control) appears to be flaky
shifty has joined #lisp
paines has joined #lisp
narimiran has quit [Quit: leaving]
Alloc has quit [Read error: Connection reset by peer]
Alloc has joined #lisp
<grewal>
The more I use python at work, the more tempted I am to write an implementation of python in cl
<p_l>
I nearly rewrote a noticeable chunk of a product in DAYJOB[-5] in *anything compiled*... but I was too sleepy from fighting python over night to do so
<p_l>
when I got back to wakefulness I removed the alert
* grewal
wonders if he loads the python source code in ecl, would it just work?
<p_l>
no...?
<aeth>
grewal: don't start on it yet
<aeth>
grewal: there are a bunch of these projects going on right now (not Python, though, but I think there's at least one ancient Python in CL, probably Python 2) so it's probably best to wait until some common code gets moved into libraries
<p_l>
there's at least three projects that do "access python libs from CL"
<aeth>
However, cl-python is the one that uses the approach that grewal would want and that's essentially abandoned, is only Python 2 (afaik), and uses the LLGPL (NEVER license your code under a license that isn't FSF and OSI approved! NEVER!)
space_otter has quit [Remote host closed the connection]
<aeth>
library #2, burgled-batteries, also looks inactive, but since it's not a complete reimplementation of a living and actively-developed language that would have needed quite a bit of work to keep up, it could just be stable.
nicktick has quit [Ping timeout: 240 seconds]
<aeth>
For those unfamiliar with Python, a Python 2 in 2020 (cl-python gives no indication which Python it is even though it should have; its tests use Python 2 syntax, though) basically means it will run no current Python code, but it could be useful to help rewrite a ton of "legacy" Python into CL.
akoana has joined #lisp
mrcom__ has quit [Ping timeout: 265 seconds]
gravicappa has quit [Ping timeout: 240 seconds]
ggole- has quit [Quit: Leaving]
<grewal>
aeth: the documentation for cl-python says it was targetting 2.7.1
<aeth>
This is... quite possibly the most important piece of information and should have been in the readme instead of a string in a manual you can only find if you search for it.
<drmeister>
It's being actively developed and it's a way to run Common Lisp code from python
mrcom has quit [Ping timeout: 265 seconds]
Inline has quit [Ping timeout: 258 seconds]
Inline has joined #lisp
EvW has quit [Ping timeout: 240 seconds]
rumbler31 has joined #lisp
EvW has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 240 seconds]
anewuser has joined #lisp
<phoe>
beach: I got a YouTube comment on Creating a Common Lisp implementation (Part 2) saying "Thanks for this series! The not covered topics are really interesting. Consider touching them in the future.
<phoe>
so I guess that is one voice that wants more
<aeth>
For those not following #sbcl apparently a lot of code uses NIL for an invalid default value, which SBCL has (afaik) started complaining about. The type-correct alternative is ERROR, but this is often not done because ERROR will quickly pollute your swank/slime API with useless information if you e.g. have 8 mandatory &key arguments with a declared type that doesn't permit NIL.
<aeth>
If I'm understanding the problem correctly.
<phoe>
aeth: care for an example?
<phoe>
you mean in struct definitions, or...?
<aeth>
I think it's in everything except struct definitions at the moment? But SBCL intends to check everything for that now.
<aeth>
so instead of seeing &key (foo (error 'your-full-package-name/conditions:whatever :details "foo bar baz" :variable 'your-full-package-name/foobar::quux)) ...
<aeth>
you'd just see &key (foo (error))
<aeth>
Unless you set *arglist-show-full-errors* to T, which shouldn't be the default
<phoe>
aeth: I'd prefer &key (foo (error ...))
<phoe>
but (error) is also good
<aeth>
oh, that could work, too
<phoe>
I mean, (error) signals an error, but it's a PROGRAM-ERROR because the required arg is not provided
<aeth>
Is anyone familiar enough with swank to be able to modify this? Or would I have to dig into it to try? This is going to affect quite a few packages that will now have to change invalid NILs to ERRORs
<phoe>
but I'd rather have (error ...) to signal that there's actual args in there that have been elided for readability
<aeth>
And I don't think my example of the problem, which currently is just &key (foo nil), is an exaggeration
<aeth>
currently just &key foo actually
wxie has joined #lisp
<Gnuxie[m]>
what do you mean by uses nil for an invalid default value? default value for what? why's it wrong?
wxie has quit [Client Quit]
mokulus has quit [Ping timeout: 264 seconds]
<aeth>
Gnuxie[m]: the shortest thing I can think of is (defun foo (&key foobar) (declare (type integer foobar)) (1+ foobar)) which should (but is not guaranteed to!) error if called as (foo) instead of (foo :foobar 1)
<aeth>
Gnuxie[m]: But it's one of those things that, when seen in a short example, you'd wonder why anyone would do that, but it could easily happen if someone designed a function API with, say, 10 arguments, some mandatory.
wsinatra has quit [Ping timeout: 265 seconds]
<Gnuxie[m]>
oh ok, so this is specific to people declaring things as not null without realising?
<aeth>
Gnuxie[m]: the right thing to do is something more like this: (defun foo (&key (foobar (error "FOOBAR is a required argument"))) (declare (type integer foobar)) (1+ foobar))
<aeth>
Gnuxie[m]: But a lot of people will explicitly rely on things being NIL as an invalid type because they don't want to take, like, 4 lines or something in SLIME
<Gnuxie[m]>
ohhhh
<aeth>
Emacs will expand the minibuffer, but it still is pretty annoying, and the only time that ever really happens is with a lot of ERRORs in keys
<aeth>
When you as the user probably only care that it will error by default, i.e. required argument
<aeth>
Gnuxie[m]: But SBCL is starting to detect this sort of UB... Idk if it has gotten to this one in particular, but it might have.
<Gnuxie[m]>
I see, thanks for explaining that
mrcom has joined #lisp
<aeth>
So this is a case of SBCL finally doing the right thing (warning on UB), but the tools encouraging the wrong thing (it really doesn't take many keys for those ERRORs to be really, really annoying in SLIME).
wsinatra has joined #lisp
mangoicedtea has joined #lisp
<aeth>
And on top of that, I think that SLIME translates DEFCLASS :initarg/:initform pairs into keys like this. At least in SBCL, it looks like it does, which is pretty smart of it, because it's working off of (make-instance 'foo ) instead of just a function API.
<aeth>
Gnuxie[m]: e.g. (defclass foo () ((foobar :initarg :foobar :initform (error "This is a mandatory slot."))))
<aeth>
Gnuxie[m]: and then type (make-instance 'foo ) and see the error show up
<aeth>
But, again, the error could be incredibly verbose, but the user probably only cares that it is an error.
<White_Flame>
huh, I remember getting errors/warnings of this sort of thing a while ago already
Mawile has quit [Read error: Connection reset by peer]
<White_Flame>
(re the NIL thing)
<White_Flame>
as in a few years ago. It must have only been supported in a few places and is spreading now. IIRC, it was struct slots that bit me
<aeth>
Well, it was first noted about 4 hours ago in #sbcl in the lines starting with:
<aeth>
< Xach> hmm, failures with latest (ish) sbcl from git - another increase in type derivation strictness i think? http://report.quicklisp.org/2020-08-29/failure-report/claw.html#claw is one example, many seem to be due to slots with a declared type but a NIL initform.
<aeth>
So, I guess it was?
Lycurgus has quit [Quit: Exeunt]
jcowan has left #lisp [#lisp]
<aeth>
(If that's just the SBCL from git, it might not be in a release yet)
<phoe>
just from git I guess
<aeth>
So then a patch to swank to hide ERROR verbosity and an update of all library code with invalid default NILs will happen before anyone really notices it.
ralt has joined #lisp
<aeth>
I guess I'm going to have to compile the latest SBCL and see which parts of my code break (probably more than I expect)
brj has quit [Ping timeout: 246 seconds]
tsrt^ has joined #lisp
brj has joined #lisp
bilegeek has joined #lisp
shifty has quit [Ping timeout: 258 seconds]
jw4 has quit [Read error: Connection reset by peer]
jw4 has joined #lisp
Jesin has quit [Quit: Leaving]
cosimone has quit [Ping timeout: 240 seconds]
<rumbler31>
reason why I'm procrastinating my python homework, I'm busy trying to import functools and read the docs on the reduce because I miss lisp and want to run a higher order function on an array
<rumbler31>
instead of just iterate the damn thing
paines has quit [Ping timeout: 240 seconds]
<ralt>
python is not really a language for higher order functions.
<ralt>
you could use recursion though.
Jesin has joined #lisp
luna_is_here has quit [Ping timeout: 240 seconds]
lisper29 has joined #lisp
Alfr_ has quit [Remote host closed the connection]
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
random-nick has quit [Ping timeout: 240 seconds]
rumbler31 has quit [Ping timeout: 240 seconds]
mathrick has quit [Ping timeout: 256 seconds]
wsinatra has quit [Ping timeout: 256 seconds]
luna_is_here has joined #lisp
mathrick has joined #lisp
_whitelogger has joined #lisp
<aeth>
Wow, I was getting really excited by the changes in the latest SBCL, but, no, unfortunately it still does not check :type in default optimization levels in DEFCLASS, e.g. (defclass foo () ((%foobar :initarg :foobar :initform nil :accessor foobar :type fixnum)))
<aeth>
It will now warn that NIL isn't a fixnum, but it won't actually stop you from doing (make-instance 'foo :foobar "hello") thus keeping :type absolutely useless on the implementation that 90% of people use
<aeth>
(it will also not give any indication that the type is incorrect if you setf foobar)
<no-defun-allowed>
I think that the latest SBCL broke decentralise2 dispatch maybe (but it's fair because I mixed compilation/evaluation environments). That was fun.
<aeth>
well, it broke cl-autowrap, which was fun, because I had to override it with the git version so I could even test to see if anything new showed up in my game engine when I loaded with :verbose t (nothing did)
<no-defun-allowed>
No, I don't think SBCL changed anything for that to happen, but it did happen, and I can't complain really.