Spawns_Carpeting has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Spawns_Carpeting has joined #lisp
Oladon has joined #lisp
pbaille has joined #lisp
igemnace has joined #lisp
imode has joined #lisp
pbaille has quit [Ping timeout: 265 seconds]
psilotorp has joined #lisp
cpape` has joined #lisp
wooden_ has joined #lisp
cpape has quit [Read error: Connection reset by peer]
wxie has quit [Remote host closed the connection]
wooden has quit [Read error: Connection reset by peer]
mseddon1 has quit [Quit: Ping timeout (120 seconds)]
zigpaw1076132 has quit [Quit: Ping timeout (120 seconds)]
f4r5983 has quit [Quit: Ping timeout (120 seconds)]
mseddon1 has joined #lisp
zigpaw1076132 has joined #lisp
f4r5983 has joined #lisp
CrashTestDummy3 has quit [Quit: Leaving]
psilotorp has quit [Ping timeout: 250 seconds]
atw` has joined #lisp
atw has quit [Ping timeout: 260 seconds]
atw` is now known as atw
scymtym has quit [Remote host closed the connection]
pbaille has joined #lisp
karlosz has joined #lisp
CrashTestDummy has joined #lisp
Spawns_Carpetin- has joined #lisp
Spawns_Carpeting has quit [Ping timeout: 240 seconds]
pbaille has quit [Ping timeout: 252 seconds]
CrazyPython has joined #lisp
jnewton has joined #lisp
mindCrime has joined #lisp
scymtym has joined #lisp
silasfox has quit [Ping timeout: 260 seconds]
silasfox has joined #lisp
hiroaki has quit [Ping timeout: 260 seconds]
terpri has quit [Remote host closed the connection]
nij has quit [Quit: #archlinux]
hiroaki has joined #lisp
CrazyPython has quit []
hiroaki has quit [Ping timeout: 260 seconds]
jnewton has quit [Ping timeout: 240 seconds]
perrier-jouet has quit [Quit: WeeChat 3.1]
perrier-jouet has joined #lisp
patlv has joined #lisp
notzmv- is now known as notzmv
gzj has joined #lisp
gzj has quit [Remote host closed the connection]
gzj has joined #lisp
perrier-jouet has quit [Quit: WeeChat 3.1]
akoana has left #lisp ["Leaving"]
patlv has quit [Remote host closed the connection]
patlv has joined #lisp
jeosol has joined #lisp
monolithic has quit [Remote host closed the connection]
actuallybatman has quit [Ping timeout: 252 seconds]
patlv has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #lisp
gzj has quit [Remote host closed the connection]
gzj has joined #lisp
terpri has joined #lisp
actuallybatman has joined #lisp
actuallybatman has quit [Client Quit]
actuallybatman has joined #lisp
zulu-inuoe has quit [Read error: Connection reset by peer]
mindCrime has quit [Ping timeout: 252 seconds]
actuallybatman has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 265 seconds]
prxq_ has quit [Ping timeout: 252 seconds]
prxq has joined #lisp
nij has joined #lisp
mindCrime has joined #lisp
<beach>
Good morning everyone!
<beach>
atw: The CLOSOS specification calls for automatic persistence, so nothing explicit needs to be done. As with other persistent systems, it is handled by checkpointing. There is a chapter discussing the possible techniques.
Oladon has quit [Quit: Leaving.]
Oladon has joined #lisp
patlv has joined #lisp
frost-lab has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
jnewton has joined #lisp
gzj has quit [Remote host closed the connection]
gzj has joined #lisp
actuallybatman has joined #lisp
<pjb>
I'd favor batteries for DRAM…
<beach>
pjb: Jim Goodman made the same observation when I told him about checkpointing.
<pjb>
In laptop, this is already done to implement suspend mode.
<pjb>
So we could just ask to have the feature also on desktops and servers.
<beach>
I kind of agree, but you still need checkpointing, which became clear to me when I forgot to put my laptop on a charger one day.
<pjb>
Usually it lasts more time. from one week to one month.
<pjb>
But indeed, when the battery goes low, the laptop hibernates (saves the RAM to disk).
<beach>
But with a battery, checkpointing can be greatly simplified I think.
<pjb>
Definitely.
<pjb>
And we avoid the risk of losing a few minutes or seconds of transactions.
<beach>
That too. Also, we need to plan for persistent primary memory.
<beach>
It shouldn't be far in the future now.
<pjb>
The thing is that then we require a system that doesn't crash (damaging the memory contents).
silasfox has quit [Ping timeout: 260 seconds]
<pjb>
It looks like that we may have to integrate a computer platform eventually, specifically optimized for CLOSOS or lispos…
<beach>
You mean adapt the hardware?
silasfox has joined #lisp
<pjb>
I mean that some modification to some motherboard may be required, so we may have to negociate with a vendor, or design our own.
<beach>
What I would like to se is a system like CLOSOS used in things like smartphones, in which case, the smartphone makers will do the adaptation.
<beach>
*to see
<pjb>
Other components are concerned too, such as disk controllers. You want to ensure that data stored in the disk controller buffers is stored to persistent media when a power off event occurs.
<pjb>
beach: indeed, laptops, tablets and phones already have the required hardware.
<beach>
Definitely! Disk caches inside disk modules can be evil.
<beach>
pjb: And thanks for the link to DDR5.
npfaro has quit [Remote host closed the connection]
actuallybatman has quit [Ping timeout: 268 seconds]
<beach>
I find myself having mixed reactions to all those "toy Lisp" projects we learn about regularly. On the one hand, I think they are great, because they are going to be a way for the creators to learn about Lisp, programming-language design, compiler techniques, etc. On the other hand, I think that they are a gigantic waste of time, because the time could be spent on maintenance of some existing real Common Lisp implementation.
hypercube has quit [Ping timeout: 245 seconds]
long4mud_ has joined #lisp
long4mud has quit [Read error: Connection reset by peer]
mindCrime has quit [Ping timeout: 252 seconds]
actuallybatman has joined #lisp
patlv has quit [Ping timeout: 245 seconds]
jnewton has quit [Ping timeout: 245 seconds]
nij has left #lisp ["#lisp"]
pbaille has joined #lisp
<jcowan>
returning "the same value" for setq must mean returning a value eql to the input.
choegusung has joined #lisp
<jcowan>
as opposed to eq
aeth has quit [Ping timeout: 240 seconds]
<pjb>
beach: existing implementation have to move in a specific direction; it may be difficult to experiment with them. Also, most implementations are not modular enough.
<Bike>
"same" is defined in the glossary to mean eql. i don't think the description of setq uses the word though.
<pjb>
since this exclude sicl, yes, more people should participate ;-)
<pjb>
jcowan: it's not possible return values that are EQ, since immutable lisp objects can be copied willy-nilly and not be EQ anymore.
aeth has joined #lisp
<pjb>
jcowan: but there's still a difficulty. With SETF, we can mutate the place with a value that is different from the argument to SETF.
elderK has joined #lisp
<pjb>
jcowan: and SETF says: "results---the multiple values[2] returned by the storing form for the last place, …"; this is different than for SETQ. For example, we could write (setf (double x) 2) (assert (= 1 x)) I understand that this setf should return 1.
pbaille has quit [Ping timeout: 252 seconds]
<beach>
pjb: I guess you are right about existing implementations.
<pjb>
(but it could be anything really, it depends on the storing form).
waleee-cl has quit [Quit: Connection closed for inactivity]
oni-on-ion has joined #lisp
jnewton has joined #lisp
<jcowan>
Scheme doesn't have this problem, because the setq and setf analogues return a single unspecified value
Oladon has quit [Quit: Leaving.]
choegusung has quit [Quit: leaving]
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
actuallybatman has quit [Ping timeout: 245 seconds]
psilotorp has joined #lisp
mindCrime has joined #lisp
actuallybatman has joined #lisp
<Bike>
i thought scheme didn't even have eq. shows what i know
psilotorp has quit [Ping timeout: 250 seconds]
<beach>
Maybe we could persuade some of the creators of those "toy Lisps" to create the Bootstrap Common Lisp (BOCL) that I have been thinking about off and on.
<beach>
I mean BOCL is itself a "toy Lisp" in that performance is not (supposed to be) an issue.
actuallybatman has quit [Ping timeout: 252 seconds]
mindCrime has quit [Ping timeout: 265 seconds]
<fe[nl]ix>
beach: do you mind writing down your ideas ?
jnewton has quit [Ping timeout: 265 seconds]
<beach>
Not at all. Do you mean here and now?
narimiran has joined #lisp
<fe[nl]ix>
I was thinking of a blog post or a doc on github
<beach>
I can work on that. Let me see what I have so far...
<pjb>
Well, the control codes are not in the basic-char set… only the 95 printable characters, and #\newline are needed ;-)
<beach>
fe[nl]ix: That's actually a pretty decent description of the idea.
<beach>
Let me know if you need more substance.
<pjb>
beach: I would avoid void*; while it's a common trick used in C to implement genericity, a lot of behavior around void* is implementation specific.
<oni-on-ion>
sizeof size_t
<beach>
pjb: Yeah, maybe that won't be necessary since the plan is for every Common Lisp object to be represented as a pointer to a header object.
<pjb>
beach: basically, we could use a union.
<beach>
But that won't be necessary either.
<beach>
And with no tag bits, no fishy bit manipulation of pointers is required either.
<pjb>
exactly.
<beach>
But, yes, the "rack" may have to be a union.
<pjb>
beach: for bocl, we can implement in C only a kernel, and use it to implement the rest in lisp, like lisp500.c uses a lisp500.lisp to complete the language.
<pjb>
beach: notably there exist CLOS and LOOP implementations written in CL, so we don't have to implement anything in C for them.
Bike has quit [Quit: Lost terminal]
<beach>
pjb: Sort of. There is no desire to implement in C what could be implemented in Common Lisp on top of a C kernel. But I think it is a mistake to "bolt on" CLOS after the fact, the way it is usually done with PCL derivatives.
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
<beach>
In fact, the idea of having every object represented the same way is to use standard objects for everything, so we need the concept of a class from the start.
orivej has joined #lisp
long4mud_ has quit [Quit: WeeChat 3.0.1]
long4mud has joined #lisp
<beach>
But, for instance, for the reader, I think it would be best to implement a reader in C that has very limited capabilities, so that it is used only to read further source code, like Eclector for instance.
<beach>
It is a very interesting mental exercise that I think has not been tried too much, i.e., forget about performance, and do the simplest thing possible.
<beach>
Like calling every function with the static environment, the dynamic environment, and a list of arguments.
<beach>
That convention will simplify lots of stuff.
oni-on-i_ has joined #lisp
oni-on-ion has quit [Read error: Connection reset by peer]
pbaille has joined #lisp
oni-on-i_ is now known as oni-on-ion
<moon-child>
beach: in that case, eclector cannot use any of the features not implemented by the c reader
<beach>
Well, Eclector would not have to be the first thing to be read in.
<moon-child>
pjb: void* can round-trip any object pointer, and intptr_t (which is suitable for implementing fixnums) can round-trip any object pointer. So I don't see anything wrong with using intptr_t
<moon-child>
beach: so a 3-level reader? That would work
<beach>
No, why?
<beach>
The primitive C reader could be used to read in other code that Eclector needs.
<beach>
Once enough code has been read, Eclector can be read.
<moon-child>
I mean, eclector can not use any reader features that the c reader does not implement
Lycurgus has joined #lisp
<beach>
I guess that's true, sure.
<beach>
So the C reader would have to implement all the reader features needed by Eclector.
<beach>
And we put pressure on scymtym to use as few reader features as possible. :)
aartaka has joined #lisp
<beach>
Today is Monday here, and Monday mornings are chaotic around here. I'll be mostly off for the next hour or so, but I'll read any additional thoughts about this subject when I get back.
igemnace has quit [Ping timeout: 260 seconds]
ravndal has quit [Quit: WeeChat 3.1]
ebrasca has joined #lisp
ravndal has joined #lisp
oni-on-ion has quit []
shka_ has joined #lisp
shka_ has quit [Client Quit]
shka_ has joined #lisp
frost-lab has quit [Ping timeout: 268 seconds]
undvrainbowvita8 has quit [Quit: EXIT]
undvrainbowvita8 has joined #lisp
rgherdt has joined #lisp
<MichaelRaskin>
Does Eclector need to be written using minimal reader features in the source code, or is it enough if it is written normally but keeps working after a read/print roundtrip? Although the difference is probably moot anyway, as reader conditionals are not to be used either way.
gaqwas has quit [Ping timeout: 265 seconds]
<pjb>
moon-child: all right. However, the first thing you see in bocl sources, is a (void*)1 :-)
<moon-child>
right
<moon-child>
I was proposing using intptr_t instead of unions, because it seems simpler
<moon-child>
(void*)1 is ick
<pjb>
beach: the C reader needs to implement the reader features needed to read a version of the eclector sources.
<pjb>
beach: we can read the sources of eclector with a full CL reader, and print them. This removes a lot of special reader macro uses. We can print them to even more crude sexp forms.
<moon-child>
doing that necessitates a preexisting cl implementation for bootstrapping, though
<pjb>
moon-child: to write the bootstrapping CL implementation. Which we have.
<pjb>
We're not in 1960!
<moon-child>
the bootstrapping cl implementation should not depend on the existence of another cl implementation
<moon-child>
I think implementing the basic reader macros--#x #' ' etc--in c is relatively trivial. So long as eclector does not define its own reader macros
jnewton has joined #lisp
<pjb>
intptr_t and uintptr_t 1- only ensure roundtrip with void* (not with eg. char*), and 2- These types are optional.
mindCrime has joined #lisp
<moon-child>
1- void* can roundtrip char*, so we can just say (intptr_t)(void*)&character; 2- it's not _strictly_ standards-complicant, but I think you will be hard-pressed to find a platform that doesn't have an integer type that can round-trip void*
gzj has quit [Quit: Leaving]
igemnace has joined #lisp
<moon-child>
(void* is not guaranteed to roundtrip function pointers, but--again--I don't think there are any platforms where it matters in practice)
jeosol has quit [Ping timeout: 240 seconds]
<pjb>
moon-child: ok, I was wrong, 6.3.2.3 point 1 ensure that we can use void* to store any pointer type and round trip it.
<pjb>
(in ISO/IEC 9899:201x eg n1570.pdf of course).
<moon-child>
of course! :)
* moon-child
, perhaps somewhat shamefully, is more familiar with the c spec than the hyperspec
<pjb>
Well, I prefer to check the standard, because we may have surprises.
<MichaelRaskin>
moon-child: this is simply using an existing CL implementation for editing… the re-printed code is still human readable and usable on any architecture
hiroaki has joined #lisp
<moon-child>
MichaelRaskin: yes, but I think that, conceptually, the code should stand on its own. The documentation talks about having as a goal not only portability, but a complete and clear expression of cl semantics
<pjb>
But eg in ISO/IEC TR 18037 n1169.pdf (embedded C), pointers are segregated into addressing spaces and may not be casted across addressing spaces. But I assume we won't try to use bocl on an embedded controler.
<moon-child>
consider e.g. an imaginary scenario: all the binaries are gone, and we have only a c compiler from which to recreate everything
<Nilby>
Why not just cross-compile?
<moon-child>
pjb: right. Another consideration: if bocl depends on bdw, it can be no more portable than it. And I'm certain bdw depends on being able to reinterpret pointers as integers
<MichaelRaskin>
As the re-printed code is human-readable and architecture-independent, it would not be counted as a binary
<moon-child>
no, but it's hardly source code either
<pjb>
Well, yes, if we already have such a dependency.
zaquest has quit [Read error: Connection reset by peer]
frost-lab has joined #lisp
jnewton` has joined #lisp
loskutak has joined #lisp
jnewton has quit [Ping timeout: 252 seconds]
jnewton` has quit [Ping timeout: 240 seconds]
jnewton` has joined #lisp
cranium_ has joined #lisp
TK__ has joined #lisp
<beach>
The current BOCL sources should not be taken seriously. I haven't given much thought to the implementation strategy.
<beach>
moon-child: thanks for the pull request.
<moon-child>
You're welcome. Have you thought about the execution strategy--bytecode vs tree-walk?
<beach>
Nope.
<beach>
I agree with moon-child that BOCL should not depend on any other Common Lisp implementation. In important reason for BOCL is to address the issues of people who are convinced that everything needs to be bootstrappable from C. And using the output of some transformation is not a good plan. The source should be source according to the definition by the FSF.
ukari has quit [Remote host closed the connection]
ukari has joined #lisp
<beach>
moon-child: Merged! Thanks again!
<pjb>
beach: my argument is that we can use CL implementations to produce the bocl sources. And this includes to produces derivations of CL sources that we want to use.
<pjb>
beach: then half my sources are not sources, since I use lisp (notably emacs lisp) to produce them (when they're not lisp sources, that I can generate with lisp macros).
pve has joined #lisp
<pjb>
but there are a lot of systems that are written not in C, that have a translator to C, that is used to bootstrap them on C-only platforms. The generated C sources (which are not really sources, therefore) are distributed to bootstrap on those platforms.
<pjb>
It's a good strategy. Why wouldn't sicl have a backed that would generate C code instead of native code?
<pjb>
+n
<beach>
pjb: Yes, I understand your argument.
<pjb>
Notably, C and the platforms are also moving targets; there are changes to the C standard every 10 years or so. Platforms may evolve faster (standard libraries, etc). So if instead of having a bootstrap C program that needs to be maintained manually, we have a way to generate the C code, it may be easier to update the C code generator to keep the bootstrap C sources uptodate.
<pjb>
(that said, bocl would be interesting in itself, as a minimalistic CL implementation).
mindCrime has quit [Ping timeout: 265 seconds]
silasfox has quit [Ping timeout: 268 seconds]
pve has quit [Ping timeout: 240 seconds]
pve has joined #lisp
silasfox has joined #lisp
<beach>
Again, I understand your argument. But the very chance of doing it this way resulting in its rejection as a bootstrapping platform is what is important to me.
<beach>
Otherwise, we would just generate C code as a backend from SICL, as you pointed out.
<pjb>
Both options are possible, they're not exclusive.
<beach>
Indeed.
skapata has quit [Remote host closed the connection]
<moon-child>
I wonder if a more sensible bootstrapping measure would be to implement a simple cl subset in c, and then use that subset to build an _interpreter_ for real cl
anticrisis has quit [Read error: Connection reset by peer]
<moon-child>
this avoids the issue of needing to implement the complete semantic model in c (a language in which it would be somewhat annoying to work with)
<beach>
That's an idea.
aartaka_d has joined #lisp
<beach>
I think we are all unfamiliar with this mindset, so there are probably ideas that nobody thought of.
aartaka has quit [Ping timeout: 240 seconds]
muyinliu has quit []
<Gnuxie[m]>
Iirc Squeak has a description for an interpreter then generates the c code for an interpreter
<Gnuxie[m]>
So you could go a step further and potentially skip the writing of c part completely
<Gnuxie[m]>
Oh wait I didn't read the whole discussion
<phoe>
if I understand correctly, then we need something that only requires a C compiler - so, in theory, pjb's idea about generating C code could possibly work
<phoe>
once this code is generated, it's standalone and doesn't need CL anymore in order to be built
<beach>
phoe: You are not understanding correctly.
<phoe>
OK, what do I miss?
<beach>
That generated C code doesn't qualify as "source code".
hendursaga has quit [Ping timeout: 240 seconds]
<phoe>
yes, it won't really be source code
<phoe>
though it fits the description of "I need to be able to compile it on a machine that only has a C compiler"
<beach>
Look, I am writing a Common Lisp implementation in pure Common Lisp, so I am not the one with the argument that requires BOCL. But I know that there are some people who want to bootstrap Common Lisp from "C source code only", and BOCL is an attempts to make life easier for people with that requirement.
Codaraxis_ has quit [Quit: Leaving]
<beach>
The idea is that (as the README says) the pain of writing a Common Lisp implementation in something other than Common Lisp would then be concentrated to BOCL, and others could go on with their lives.
<beach>
But the pain will be more tolerable in BOCL than in other Common Lisp implementations, because of the different requirements in performance, user friendliness, etc.
<beach>
*is an attemp
<beach>
t
<phoe>
to be frank, I don't think most of them manually inspect and read the C source code that gets generated, so in theory you could order SICL to dump C code, wrap it in a tar.gz, make a release, and call that a solution - when they unzip the archive on a machine only with a C compiler and build it, they get a CL implementation, which is what they want
<beach>
*sigh*
<phoe>
to most of them, it won't really matter that this C code is spaghetti compiler output, it'll matter that it buiilds.
hendursaga has joined #lisp
<beach>
phoe: Oh, I know of creators of Common Lisp implementation who would not consider using BOCL if its "source code" were generated.
<beach>
phoe: So basically, you are saying "beach, stop that silly project and do something else instead"?
<phoe>
beach: of course I'm *not* saying this
<beach>
So, I have decided that I think that there are people who would like to bootstrap Common Lisp from C source code (using FSF's definition). And I think BOCL is an interesting idea because of the unique requirements. I think it is interesting to imagine where these requirements would take us. Maybe BOCL will never happen, and maybe there aren't any people like that. It is still interesting to me.
<phoe>
sure, the problem is pretty interesting
<beach>
And it is fine with me if people think I am wrong. These people should just not contribute to BOCL. But please don't try to convince me to abandon the idea. It is pointless. The idea will remain in my head.
<phoe>
where in the world did I try to convince you to abandon the idea
<Nilby>
I think catering to "only a C compiler" people, who can't compile ECL, or CLisp, or even qemu and an old binary and cross-compile, doesn't seem to serve much purpose. It doesnt seem to have much hindered other CLs.
<beach>
phoe: People suggesting that generated C code is OK as part of BOCL are suggesting that I abandon the fundamental premise of BOCL that it use only "C source code" according to FSF's definition.
<Nilby>
Provding a clean, verifiable chain of code from machine to CL might be useful, but is a different requirement.
<beach>
Nilby: OK, let me explain a bit further....
<phoe>
OK, but how in the world did you put an "I" in there? I wasn't even thinking of you when I made the statement that generated C code would build on a machine with only a C compiler
<beach>
Nilby: ... and please don't tell me that I am "wrong" because I might very well be. I still think it is an interesting mental exercise...
<phoe>
sure, it won't fit the FSF requirement and therefore solves a different problem
<beach>
Nilby: So my idea is that there are several Common Lisp implementation written in some language other than Common Lisp, like C or C++...
jnewton` has quit [Ping timeout: 240 seconds]
<beach>
Nilby: I know that it is painful to write a Common Lisp implementation that way, so there is a lot of code in those Common Lisp implementations that is hard to maintain, and certainly more code than there has to be.
<beach>
Nilby: And some people writing Common Lisp implementations that way think that it is important to bootstrap from just C.
<beach>
Nilby: So my idea is to make life easier for such people (who may not exist), by concentrating the pain in one Common Lisp implementation, so that they can improve their code by writing more of it in Common Lisp.
<beach>
Nilby: That thinking of min obviously excludes the use of an existing Common Lisp implementation written in C like Clisp or ECL, or ...
<beach>
Because those implementations are written with other objectives in mind, like safety, performance, user friendliness.
jnewton` has joined #lisp
ljavorsk has joined #lisp
<Nilby>
I'm just afraid another CL in C will distract from a better CL in CL. I might be intersting to observe how Dylan was bootstrapped, once from CL, another time from C. But the C version was effeectively thrown away.
<beach>
phoe: Oh, I apologize. I implicitly thought you were talking about BOCL.
<beach>
Nilby: You can rest assured that I will not replace SICL by BOCL.
<Nilby>
Okay. That's good. :)
<phoe>
beach: nope, I was talking about the similar but different problem of bootstrapping CL only from a C compiler, not about BOCL and your assumptions about it
<phoe>
sorry for the confusion
<beach>
phoe: Got it. Again, I apologize.
<phoe>
me too, sorry
<phoe>
in particular, pjb's idea about the ability to build SICL from generated C sources got me pretty interested
<beach>
Here is another piece of information...
niflce has joined #lisp
<beach>
Currently, we use SBCL to bootstrap SICL. But in the past, I have had to abandon some bootstrapping strategies because of limitations in SBCL.
<phoe>
clearly pjb's idea is no BOCL, but it does remove one piece of the chain (intermediate CL implementation) in exchange for another (SICL/Cleavir backend for generating C code that also deals with all the C quirks)
<Nilby>
I have some bias because I wish I could get back my time spent working on Dylan and Scheme in C.
<beach>
Those limitations exist because of the trade-offs made by SBCL. It tries to optimize performance for typical application programs. And bootstrapping SICL is very different from typical application programs.
<beach>
So the idea of having a Common Lisp implementation without such trade-offs, even if it is dog slow, is an attractive one.
<phoe>
performance? you mean that bootstrapping became infeasible because it was slow on SBCL?
<beach>
Now, we ran out of "immobile space".
<phoe>
ooooh, so that sort of limitation
<beach>
And, yes, bootstrapping times were very long, but that's not a showstopper. Just inconvenient.
heisig has joined #lisp
<beach>
And I strongly suspect we will run into different limitations when we try to bootstrap SICL on other existing Common Lisp implementations. Just because of the unusual use case.
<beach>
Nilby: I am guessing Dylan and Scheme are very different from BOCL; I am thinking they have the same objectives as Clisp and ECL, and other Common Lisp implementations written in C, namely to be usable for application programming.
<beach>
Nilby: That difference in mindset changes everything.
rogersm has joined #lisp
<Nilby>
beach: Actually there was a slow Dylan interpreter in C "Mindy", just for bootstrapping a real compiler.
<beach>
I see. I am sorry you wasted a lot of time on it.
<Nilby>
Some troubles seem to be persistant. On Multics lisp had to be built out of an existing lisp for performance reseasons, even though the compiler was in PL1.
<Nilby>
It seems like Squeak did something akin to what pjb was suggesting.
<Nilby>
Interesting reference in that Squeak link: "Babel—A Translator from Smalltalk into CLOS"
quanta[m] has quit [Quit: Idle for 30+ days]
<beach>
My initial strategy for BOCL was to define many objects as static C structures. But I now think it might be more maintainable to generate those structures at start-up time.
<beach>
That way, arbitrary code can be invoked to generate the objects.
<pjb>
Nilby: that said, in the current version of Squeak, it seems the sources of the VM are not included (I can't find "VMConstruction-Interpreter", and "VMConstruction-Translation to C" in the Browser).
<loke[m]>
<daphnis "what cl library should one use t"> cxml
<engblom>
phoe: Thanks!
<daphnis>
thanks!
<engblom>
phoe: That also seems to be a reimplementation of Clojure rather than bringing some Clojure features to CL. I was thinking about something that would provide functions and macros from Clojure to CL. For example loop[] recur, spit/slurp, etc
<engblom>
So more like a library with familiar functions/macros from Clojure rather than a reimplementation
<phoe>
doesn't make much sense to me - we have CL analogues of all those
<phoe>
loop recur is done via cl:loop most of the time, spit/slurp are alexandria:{read,write}-file-into-{byte-vector,string}
phao has joined #lisp
<phoe>
you can write clojure in CL, but the question is why - it won't be idiomatic which means that you'll get into issues when going multiplayer with your code
<phoe>
s/into/{into,from}/
<phoe>
s/into/welp I mixed them up but you know what I mean/
<phao>
Hi... I know this is kind of a vague question, but I don't really know how to ask it any better. Is common lisp good for numerical work (in the sense of scientific computing, computing mathy objects, like ode, pde solvers, interpolation, digital image processing, statistics-stuff, etc)?
daphnis has quit [Ping timeout: 252 seconds]
daphnis has joined #lisp
zaquest has joined #lisp
<phoe>
phao: I know that ACL2 is written in Common Lisp, and I know multiple libraries for doing mathy stuff that you mentioned
xenon- has joined #lisp
<jackdaniel>
phao: common lisp has optimizing compilers, so if you put enough effort into your program then it will be very performant (numerically)
<phoe>
there's also maxima, also written in CL - ACL2 is more suitable for logic programming than math IIRC
<engblom>
Also maxima (and thus also wxmaxima) is written in lisp.
<loke[m]>
engblom: wxmaxima is written in C++
<jackdaniel>
usually (for straight-forward algorithms) common lisp program will be around 5x slower than equivalent c++ program and around 50x faster than equivalent python3 program
<jackdaniel>
I took these numbers from my magical "I-think-so" hat, so you may trust them
<loke[m]>
wxmaxima talks to a backend Maxima instance (maxima is of course CL)
<engblom>
loke[m]: I have seen it pull in some lisp as a dependency, so are you sure?
<engblom>
Ah, ok
<loke[m]>
engblom: I'm a contributor to both Maxima and wxmaxima. Yes I'm sure.
<engblom>
loke[m]: Your explanation makes sense, because if it usises maxima as backend, then a lisp is needed there.
<loke[m]>
I'm working on a pure CL graphical frontend to Maxima which runs in the smae CL image as Maxima itself. It allows me to integrate more closely with the low-level functionality of Maxima.
frost-lab has joined #lisp
<loke[m]>
For example, animation can iteratively run Maxima expressions to recompute variables. This is not possible in mxmaxima.
<engblom>
loke[m]: Nice, I am looking forward to that! While I do not use wxmaxima daily, I use it several times a year when doing some calculations.
<phao>
jackdaniel, about that "I-think-so" hat of yours (hehehe) -- How would you compare the kind of performance you get off of common lisp with what you get out of java?
amb007 has quit [Read error: Connection reset by peer]
<loke[m]>
engblom: Yes. For now. I want to move it to something that is not github
<engblom>
loke[m]: Because of ms?
amb007 has joined #lisp
Lycurgus has quit [Ping timeout: 252 seconds]
<jackdaniel>
I don't know, I haven't programmed in Java for years and it is constantly improved
<jackdaniel>
probably in the same ballpark :)
amb007 has quit [Read error: Connection reset by peer]
<loke[m]>
engblom: well, maybe.
<phao>
Ok. Well, thank you =)
amb007 has joined #lisp
<daphnis>
how does one get the output of a shell command into a string?
amb007 has quit [Read error: Connection reset by peer]
<jackdaniel>
technically speaking programming languages are neither fast or slow - it is a domain of the language implementation; in practice though some language specifications prohobit certain types of optimization or make them harder
<loke[m]>
daphnis: that depends on which library you use to run commands.
<daphnis>
pjb: thanks, this is simpler than the other run-program
niflce has quit [Ping timeout: 252 seconds]
phao has quit [Quit: Leaving]
Dyedefra has joined #lisp
daphnis has quit [Ping timeout: 260 seconds]
daphnis has joined #lisp
arduo has joined #lisp
jnewton` has quit [Ping timeout: 240 seconds]
jnewton` has joined #lisp
daphnis has quit [Ping timeout: 265 seconds]
rem1hacker5 has quit [Ping timeout: 265 seconds]
frost-lab has quit [Quit: Connection closed]
niflce has joined #lisp
ebrasca has quit [Remote host closed the connection]
xkapastel has joined #lisp
daphnis has joined #lisp
S3dgw has joined #lisp
patlv has joined #lisp
Bike has joined #lisp
patlv_ has joined #lisp
pfdietz has joined #lisp
patlv has quit [Ping timeout: 240 seconds]
daphnis has quit [Ping timeout: 252 seconds]
kevingal has joined #lisp
daphnis has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #lisp
patlv_ has quit [Quit: Leaving]
patlv has joined #lisp
daphnis has quit [Ping timeout: 265 seconds]
daphnis has joined #lisp
<beach>
engblom: phoe asked you a question that I would also like to see the answer to, namely why would you want to write Clojure in Common Lisp. If you want to write Clojure, why not just use Clojure rather than Common Lisp?
<beach>
engblom: Also, did you see my answer to your inquiry about updating the Common Lisp "specification"?
<engblom>
beach: Both things are actually related. Clojure is the first Lisp dialect I have used and I noticed how much shorter my source code became. It looks like it was designed to be as practical as possible for the programmer, making things like shared resources, tail recursion without blowing stack, etc possible. The bad thing with Clojure is how it is depending on Java and how slow it is to start up. It is not
<engblom>
that I need to write Clojure in Common Lisp, but if there would be a single library that is having a bit more of modern functionality I would appreciate it.
daphnis has quit [Ping timeout: 252 seconds]
<engblom>
beach: I actually want to use CL because of how much faster it starts up on RPI.
daphnis has joined #lisp
<engblom>
beach: First I was wondering if there is a process of updating the specification, then as I got the answer that there is no such process I begun thinking that maybe someone has created a library that does this thing: providing more modern functionality.
<phoe>
the functionality is mostly already in there, just available as libraries
<phoe>
CL has the upside where programmers can easily extend the language themselves, and lots of lispers use that to full extent
<phoe>
so you don't need an updated language specification to be able to e.g. use arrow macros or pattern matching
<jackdaniel>
and lots of lispers use that to the extent of their cognitive horizont* mop i.e is underutilized
<phoe>
you just (quickload :arrows) or (quickload :optima)
<phoe>
and yes, what jackdaniel said - we definitely need more MOP usage and promotion
<jackdaniel>
let me start my "google browser" tha removes its caches after each run
<phoe>
s/MOP study group video/CL study group video where people discuss the MOP/
<jdz>
jackdaniel: I only watch youtube videos with mpv.
orivej has quit [Ping timeout: 240 seconds]
<jackdaniel>
I had a google account, but got cut from it by the behemoth itself for no clear reason; good ridding ,) sorry for the offtopic
<jackdaniel>
phoe: I'll watch it in spare time, thanks.
<beach>
engblom: Yes, I am beginning to understand. You would rather write Clojure, but you are using Common Lisp because it is faster. I think that's a horrible idea in general, i.e., to use idioms from one language when writing code in a different one. Plus, this channel is about Common Lisp itself, and, like phoe, I think most people prefer to use it as it is.
<jackdaniel>
while common lisp (as a language) is not very opinionated, there is something what one could call a 'consensual common lisp programming style' - involving clos and not well aligned with functional programming
<phoe>
I think it'll be better overall to learn the CL idioms and use them in CL - much less total overhead for you and other lispers this way, especially since you can expect most of the clojure idioms to be either identical (sans the name) or mostly equivalent in CL
<jackdaniel>
that said some programmers create libraries not following the 'consensus', i.e fset or series; some programmers have unique styles that i.e rely heavily on macros or on closures
<phoe>
jackdaniel: consensual? is that the proper word you're looking for?
<phoe>
oh yes, it is
* phoe
derp
<cranium_>
is there a resource about this "consensus", i.e. the do's and don'ts of CL?
<jackdaniel>
people will be quick to correct you if you do not follow it ,-)
luckless_ has quit [Quit: luckless_]
<jackdaniel>
that said _imo_ the language is bigger than that and there is certainly a place on #lisp for subcommunities that come up with "foreign" concepts
<jackdaniel>
(but this probably inhibits the use of most of the accumulated wisdom carried by the community)
<cranium_>
Google's CL guide links norvig.com/luv-slides.ps, perhaps that is somewhat of a start.
daphnis has quit [Ping timeout: 252 seconds]
<engblom>
beach: Yes, it is true that I like Clojure, but still I am not against learning how to do CL programming. As it has already been pointed out by phoe serveral times, the functionality is in libraries, I was just wondering if there is a ready library collection for people coming from Clojure.
<engblom>
For a beginninger it is a difficult task to find all those libraries that are spread out all over github and who knows where. Those that phoe has mentioned I have put into a text file so I can find them later when needed.
<beach>
engblom: Well, it seems you are asking for a library that has functionality that already exists in Common Lisp, but with different syntax. That's the part that is not a good idea.
daphnis has joined #lisp
<phoe>
engblom: regarding "for people coming from Clojure", I don't think such a thing has been created
<phoe>
as in, I have never seen a complete manual that lists and/or indexes all the differences and all the similarities
<beach>
engblom: Programming languages are like natural languages in that respect. You should learn the idioms of the language you are using. It looks strange (and people won't understand you) if you use "foreign" idioms.
<beach>
engblom: Imagine the day you need help with debugging some of your code. You expose it here, but it is full of Clojure idioms. Clearly, fewer people would be able to help you then.
<phoe>
but I haven't seen something designed specifically for clojure programmers who want to learn CL. might be good to create it, as long as someone has the will, time, and competences to do that.
<jackdaniel>
interesting fact: clojure was initially written in common lisp as a transpiler to java; I remember seeing that old source code somewhere
<Nilby>
You can mutate CL into something quite Clojure-like, but then you might be programming in a language that has a smaller community than both. But it's that's what you like, then why not? When people say "modern" it seems like it's more style than substance. I think it's worth it to try the CL style.
<engblom>
beach: Regardless of what impression you have of me, I still enjoy working with CL, so it is not like I hate it and slowly I will learn how to do things the CL way. It is only when the CL solution seems to be more verbose that I wish I had some stuff from Clojure (like arrows).
<engblom>
phoe: Thanks, I will look at those
waleee-cl has joined #lisp
<phoe>
engblom: wrt arrows, as I said, (ql:quickload :arrows) and you have them - the only verbosity is that you need to add an ASDF dependency in your system and then (:use #:arrows) or (:import-from #:arrows #:-> #:->> ...) as appropriate
hypercube has joined #lisp
<phoe>
wrt other Clojure idioms, I guess we can look for their CL equivalents and/or counterparts on demand
<Bike>
you can also put the load into your init file so you don't have to do anything before using them in the repl
<engblom>
phoe: Yes, and I have this information about arrows stored in a text file, so that part is solved.
<jackdaniel>
or save-your-lisp-and-die after loading the "base stuff" and put it in /usr/bin/cl-oh-jure
<phoe>
engblom: good; if you find anything more, then let me/us know, and possibly we could try to use those questions to e.g. make a CL Cookbook article that lists those things for Clojure programmers who want to try CL
<engblom>
One thing I wonder: how do you do recursion without blowing the stack? Or do you simply replace the recursion with some other kind of loop construct?
<phoe>
engblom: usually the latter
<jackdaniel>
usually cl programmers aim at iteration
<splittist>
Or you make the changes at the editor/source level, so your code is really idiomatic CL, but you write it with editor macros that mimic clojure (until you don't need to).
<jackdaniel>
that said most implementations have tail recursion on way or other (i.e under certain optimization settings)
<phoe>
most implementations perform TCO only when they are instructed to, so if you compile your code with e.g. full debuggability then there is no TCO (because it does not preserve debug stack information)
* splittist
imagines clojippy "It looks like you're trying to ..."
<jackdaniel>
s/on way/one way/
* phoe
imagines cl-ippy - the most annoying CL system
rpg has joined #lisp
<rpg>
Does anyone know -- does clisp ship without ASDF? I was surprised that `(require :asdf)` doesn't work on the clisp install I got from brew...
<phoe>
s/when they are instructed to/on proper optimization settings/
<phoe>
rpg: where does brew get its CLISP from?
<jackdaniel>
rpg: you may configure clisp to build with asdf, but the option is disabled by default (afair)
<engblom>
phoe: How do I instruct sbcl to do TCO?
* phoe
fires up the SBCL manual
<jackdaniel>
rpg: that said, last time I've checked clisp had ASDF 2.24
<phoe>
default optimization settings should be good enough for TCO
<rpg>
Ah. Brew probably builds with the default. I'm feeling kinda cranky about this, maybe I will just drop clisp from the ITERATE CI/CD.
* phoe
fires up SBCL manual
<rpg>
The whole 14 year old release isn't warming the cockles of my heart, either.
<phoe>
5.3.4 - "The elimination of tail-recursive frames can be prevented by disabling tail-recursion optimization, which happens when the debug optimization quality is greater than 2."
<phoe>
so TCO is performed as long as (optimize (debug 2)) or less is in effect
<jackdaniel>
clisp is unique in many conforming ways, so it may show interesting regressions in your software
<phoe>
(the default for DEBUG is 1)
<phoe>
jackdaniel: I chuckled at the restart
nullx002 has quit [Remote host closed the connection]
undvrainbowvita8 has quit [Quit: EXIT]
rwcom60280385034 has joined #lisp
xenon- has joined #lisp
silasfox has quit [Quit: WeeChat 3.1]
<engblom>
phoe: When I try (defun factorial (n) (if (= n 1) 1 (* n (factorial (- n 1))))) it will blow the stack if I give it 100000, even if I wrap (optimize ... ) around it.
<fe[nl]ix>
beach: the idea for BOCL looks good, but have you considered taking an existing implementation, like XCL, and simplifying it ?
S3dgw has quit [Ping timeout: 252 seconds]
Bourne has quit [Ping timeout: 240 seconds]
<_death>
engblom: in this definition, the factorial call is not a tail call
pve has quit [Quit: leaving]
<cranium_>
because of the multiplication?
undvrainbowvita8 has joined #lisp
<phoe>
yes
<flip214>
engblom: you'll need a recursive call with an accumulator parameter
<phoe>
(defun factorial (n) (labels ((helper (n i acc) (if (= n i) acc (helper n (1+ i) (* i acc))))) (helper n 1 1)))
<phoe>
no stack blown, just my emacs choked on printing the output
<_death>
phoe: factorial of 100000 is huge.. unlikely to terminate any time soon
<phoe>
so (time (progn (factorial 100000) nil)) gives me 2 seconds
<phoe>
_death: huh?
<splittist>
I sometimes wonder if slime needs a "About to print out EleventyBillion characters - are you sure? Y/n" facility
<phoe>
but it just terminated for me
<flip214>
phoe: is it faster to multiple the bigger numbers first?
<phoe>
oh woop, I got an error - s/=/</ in my code
<phoe>
flip214: no idea, you go into bignum territory very quickly anyway
<engblom>
_death: I tried also in Clojure and it will also blow the stack with the way I first defined it.
<engblom>
phoe: Yes, that solution works well with SBCL, I tried it.
<beach>
fe[nl]ix: No I hadn't considered that. I imagine every implementation has profound design decisions that are contrary to the main idea of BOCL. I may be wrong of course.
<beach>
contrapunctus: I took most of your changes. Thanks again.
<beach>
minion: Please tell engblom about updating the Common Lisp standard.
<minion>
engblom: please look at updating the Common Lisp standard: See http://metamodular.com/Common-Lisp/updating-the-standard.html for an explanation why it is not likely that there will be a revised Common Lisp standard, why a revised standard is most often not needed, and sometimes not even desirable.
<engblom>
This actually gives CL an edge over Clojure in this case as one do not need to use (recur).
<phoe>
engblom: but note that if you (declare (optimize debug)), you'll blow the stack
<engblom>
minion: Thank you, I was given that one earlier too.
<minion>
np
<phoe>
and some people actually restrict the SBCL compiler policy to only produce code with high debug and safety
<beach>
engblom: I updated it according to the suggestions of contrapunctus.
<beach>
engblom: No profound changes though. No need to read it again.
cosimone has joined #lisp
<_death>
phoe: your factorial is off by one.. but you're right that it's not as huge as I thought.. I just have (debug 3) which disables tail call elimination and so sbcl crashes
<Nilby>
But why does factorial 100000 have those weird patterns in it?
<phoe>
_death: yes, I just fixed it
<phoe>
off by one errors strike again
<flip214>
phoe: in a quick test, going from big numbers down uses 12% more CPU cycles and conses more... because bignums are reached faster, I guess
<lotuseater>
oh yes, or if in a mathematical book/paper one uses indexing starting from 1 ^^
<phoe>
but, in order to accomodate people and implementations who explicitly *disable* tail call optimizations, it's safer to write imperative code rather than heavy recursion - even tail recursion
niflce` has joined #lisp
<phoe>
and there are people who do that, e.g. _death and phoe
<flip214>
phoe: recursion with TCO might give you the _same_ assembler code as a manual loop
<beach>
It is even worse than that. Code that is artificially converted to be tail recursive is usually much harder to understand than the iterative version.
<phoe>
flip214: yes
rwcom60280385034 has quit [Ping timeout: 246 seconds]
mrchampion has quit [Ping timeout: 252 seconds]
niflce` has quit [Client Quit]
<contrapunctus>
beach: happy to help ^^
niflce` has joined #lisp
homonyms has joined #lisp
niflce has quit [Ping timeout: 240 seconds]
mrchampion has joined #lisp
Lycurgus has quit [Quit: Exeunt]
<engblom>
0
<jackdaniel>
mniej niz zerooo, mniej niz zeroo
<engblom>
jackdaniel: That zero ended up there by mistake, I must have been typing in wrong window at some point.
<jackdaniel>
sure, I've automatically started singing a (very old) polish rock song
<pfdietz>
Computing factorial by bisection is faster. 100000! takes 0.392 s when I do that.
<_death>
pfdietz: alexandria has that iirc
<Bike>
yeah, it's with a general binomial coefficient computer.
<beach>
jackdaniel: By Proletaryat I hope.
<Bike>
"For even better results it should be possible to use prime factorization magic, but Nikodemus ran out of steam."
<Bike>
but then your recursion depth is log2 n, or something, instead of n, and it's not as obvious a compiler optimization question
daphnis has joined #lisp
<loli>
that bisect function looks fun, the general technique can be had with any associative operator, though it seems specific to bignums here, wonder if you can put branch prioriteis that reduce to big-num checking in this case for that
niflce` has quit [Ping timeout: 252 seconds]
ckapos has joined #lisp
kevingal has quit [Remote host closed the connection]
<jackdaniel>
checking for fixnum (as it is) will be usually fast thanks to the immediate object tagging (optimization technique)
<pfdietz>
Not only do you get fewer bignums, but the bignums are smaller. The sum of the number of bits in the bignums at each depth is log n!.
<pfdietz>
Vaguely reminiscent of computing the nth Fibonacci number in O(log n) arithmetic operations.
<jcowan>
it's the same underlying principles.
<jcowan>
Of course in languages like C and Java, you just grab a table of values of these functions less than 2^63, and you have O(1). Only in languages with automatic promotion to bignums do any such algorithms make sense.
johnjay has quit [Ping timeout: 260 seconds]
homonyms has quit [Remote host closed the connection]
aeth has quit [Ping timeout: 265 seconds]
<Bike>
or just up to 20, since otherwise the result won't fit in 64 bits. so easy
<jcowan>
Right, that's why I spoke of values
aeth has joined #lisp
<rpg>
If there are any other ITERATE fans out there, I just created a 1.5.1 that has a bunch of modest bug fixes.
zooey has quit [Remote host closed the connection]
zooey has joined #lisp
<pfdietz>
We use iterate. Thanks.
yoonkn has quit [Read error: Connection reset by peer]
<Bike>
oh, whoops
<pfdietz>
I have a branch of iterate I need to have merged back into master. It makes iterate work with a modified version of cover. Someday.
sloanr has quit [Read error: Connection reset by peer]
sloanr has joined #lisp
jlf has quit [Ping timeout: 245 seconds]
irc_user has joined #lisp
Nilby has quit [Ping timeout: 245 seconds]
dyelar has joined #lisp
<flip214>
rpg: thanks! would it be possible to also provide some compat with CL-WHO with ITERATE, eg. by loading an ITERATE+CL-WHO system that's included with ITERATE?
daphnis_ has joined #lisp
<daphnis_>
how does one use lquery to get the text of <span class="foo"> ?
<rpg>
flip214: Maybe.... I'm not familiar with CL-WHO myself. It might be more appropriate to make a "cl-who/iterate" system and keep everything with the "cl-who" system, if you can get buy in from the cl-who developers. Otherwise there's no reason you couldn't make a "iterate+cl-who" that is free-standing and that :depends-on both iterate and cl-who.
<rpg>
Bundling a bunch of stuff with ITERATE is probably the wrong thing, unless we want to set up contribs for it.
<rpg>
But testing would be an enormous PITA, because it would require *forward* dependencies, which is why I think it would be better to keep this either with cl-who or freestanding.j
igemnace has quit [Ping timeout: 260 seconds]
igemnace has joined #lisp
jeosol has joined #lisp
Lycurgus has joined #lisp
ebrasca has joined #lisp
mindCrime has joined #lisp
aartaka_d has quit [Read error: Connection reset by peer]
aartaka has joined #lisp
Lycurgus has quit [Quit: Exeunt]
srhm has joined #lisp
ckapos has quit [Ping timeout: 265 seconds]
<splittist>
daphnis_: with a combination of has-class and text ? (something like [untested] (lquery:$ *doc* "span" (has-class "foo") (text)) (which will give you all the text of all spans of class "foo", I think).
froggey has joined #lisp
<daphnis_>
splittist: thanks! it may be that #'combine is required
<splittist>
daphnis_: it depends what you want
mindCrime has quit [Ping timeout: 240 seconds]
kevingal has joined #lisp
<daphnis_>
splittist: well, without (text) ((and combine)) i get T; with what you suggested i get: ``there is no applicable for the generic function .. text when called with arguments (T)
<daphnis_>
s/applicable/& method/
am1no has joined #lisp
<splittist>
daphnis_: fair enough (: I guess I meant to say "span.foo" (text)
Bourne has joined #lisp
cage_ has joined #lisp
skapata has joined #lisp
cammie has joined #lisp
CodeOrangutan has quit [Quit: Leaving]
jnewton` has quit [Ping timeout: 260 seconds]
imode has quit [Ping timeout: 240 seconds]
droideqa has quit [Quit: Connection closed for inactivity]
actuallybatman has joined #lisp
jnewton` has joined #lisp
vaporatorius__ has quit [Quit: Leaving]
Vaporatorius has joined #lisp
Vaporatorius has joined #lisp
Vaporatorius has quit [Changing host]
silasfox has joined #lisp
thrashdin has joined #lisp
thrashdin is now known as aun
actuallybatman has quit [Ping timeout: 265 seconds]
<aun>
why dont find and find-if return 2 values (same as say gethash) as it would make sense? That frustrates me.
<Bike>
i dunno. on a list you can use member instead.
<aun>
well yeah but on arrays...as you know I m covering stl so It looks like I have to reimpl find from the ground
Demosthe1ex is now known as Demosthenex
ljavorsk has quit [Ping timeout: 240 seconds]
aun has quit [Quit: Connection closed]
Sheilong has quit [Quit: Connection closed for inactivity]
hiroaki has quit [Ping timeout: 260 seconds]
<rpg>
Does clisp have a funny way of loading files? Does anyone know? I have files that even SBCL will load that mention late in the file symbols in packages that don't exist until the first half has been executed, that clisp is erroring on.
jnewton` has quit [Ping timeout: 246 seconds]
<rpg>
I was wondering if clisp is running the full file through the reader before evaluation, instead of reading and evaluating as it goes.
hiroaki has joined #lisp
sm2n_ has joined #lisp
sm2n has quit [Ping timeout: 240 seconds]
sm2n has joined #lisp
sm2n_ has quit [Read error: Connection reset by peer]
aartaka_d has joined #lisp
luckless has joined #lisp
aartaka has quit [Ping timeout: 240 seconds]
sm2n has quit [Ping timeout: 260 seconds]
luckless has quit [Client Quit]
<etimmons>
rpg: I think it's the `-c -l` in the clisp options.
<etimmons>
That's making it do compile-file and the load-system has no compile time effect
<etimmons>
removing those I still get an error, but the new error makes me think it's at least trying to load the system
<rpg>
etimmons: When I try to take that out I get GNU CLISP: -l without -c is invalid
jnewton` has joined #lisp
sm2n has joined #lisp
<etimmons>
No -l needed
<etimmons>
`lispscript [argument ...] - load script, then exit`
sm2n has quit [Excess Flood]
sm2n has joined #lisp
sm2n has quit [Read error: Connection reset by peer]
<etimmons>
rpg: Yep, that's what I got too. No easy solution for that from me.
<rpg>
I am not sure whether `:here` works in Fare's DSL. If so I think I have this.
luckless has joined #lisp
sm2n has quit [Ping timeout: 260 seconds]
<etimmons>
Speaking of pathname issues, I recently ran into another. looks like UIOP's various wildcard pathnames don't have the same semantics across implementations.
<etimmons>
Haven't had the time to figure out if that's an impossible ask, implementation bugs, or UIOP bugs, though.
Jesin has quit [Quit: Leaving]
luckless has quit [Quit: luckless]
silasfox has quit [Quit: WeeChat 3.1]
pbaille_ has joined #lisp
<rpg>
etimmons: It's happening inside the processing of output translations. Beyond that :shrug:
monolithic has joined #lisp
pbaille has quit [Ping timeout: 240 seconds]
anticrisis has joined #lisp
pbaille_ has quit [Remote host closed the connection]
pbaille has joined #lisp
<etimmons>
rpg: My issue is with cl:directory / uiop:directory*. I'll open an issue once I investigate it a bit more.
cammie has quit [Remote host closed the connection]
klltkr has joined #lisp
notzmv has quit [Ping timeout: 240 seconds]
pbaille_ has joined #lisp
<rpg>
etimmons: Thanks!
jnewton` has quit [Ping timeout: 260 seconds]
terpri has quit [Remote host closed the connection]
<pfdietz>
rpg: if you could look at https://github.com/pfdietz/iterate (master) there are some changes I'd like merged into iterate. Or.. where do I send a pull request?
<rpg>
That's on gitlab, so if you would prefer to post a patch to an issue, that would be ok. I don't know how well gitlab and github play together.
gaqwas has joined #lisp
gaqwas has joined #lisp
silasfox has joined #lisp
luckless has quit [Quit: luckless]
<pfdietz>
Ok.
luckless has joined #lisp
masp has quit [Quit: Konversation terminated!]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
TK__ has quit [Remote host closed the connection]
terpri has quit [Ping timeout: 250 seconds]
terpri has joined #lisp
frgo has joined #lisp
mathrick_ is now known as mathrick
andreyorst has quit [Ping timeout: 240 seconds]
silasfox has quit [Read error: Connection reset by peer]
hypercube has quit [Ping timeout: 260 seconds]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jnewton` has quit [Ping timeout: 260 seconds]
klltkr has joined #lisp
klltkr has quit [Client Quit]
klltkr has joined #lisp
klltkr has quit [Client Quit]
irc_user has quit [Quit: Connection closed for inactivity]
klltkr has joined #lisp
klltkr has quit [Client Quit]
am1no has quit [Ping timeout: 268 seconds]
Bourne has quit [Ping timeout: 265 seconds]
sloanr has quit [Ping timeout: 240 seconds]
aeth has quit [Ping timeout: 265 seconds]
shka_ has quit [Ping timeout: 268 seconds]
aeth has joined #lisp
jnewton` has joined #lisp
daphnis has quit [Ping timeout: 265 seconds]
daphnis_ has quit [Ping timeout: 240 seconds]
cage_ has quit [Quit: rcirc on GNU Emacs 27.1]
ebrasca has quit [Remote host closed the connection]
jnewton` has quit [Ping timeout: 265 seconds]
loskutak has quit [Ping timeout: 240 seconds]
hjudt has quit [Ping timeout: 268 seconds]
hjudt has joined #lisp
aartaka_d has quit [Read error: Connection reset by peer]
aartaka has joined #lisp
imode has joined #lisp
mrchampion has quit [Ping timeout: 260 seconds]
jnewton` has joined #lisp
amk has quit [Ping timeout: 240 seconds]
amk has joined #lisp
mrchampion has joined #lisp
orivej has joined #lisp
Nogodda has joined #lisp
narimiran has quit [Ping timeout: 240 seconds]
surabax has quit [Quit: Leaving]
jnewton` has quit [Ping timeout: 268 seconds]
nij has joined #lisp
pbaille_ has quit [Remote host closed the connection]
pbaille has joined #lisp
heisig has quit [Quit: Leaving]
pbaille has quit [Ping timeout: 252 seconds]
notzmv has joined #lisp
Nogodda has quit [Ping timeout: 240 seconds]
czer00 has quit [Remote host closed the connection]
cranium_ has quit [Quit: Leaving]
mindCrime has joined #lisp
gaqwas has quit [Ping timeout: 240 seconds]
pbaille has joined #lisp
arcmutex has joined #lisp
f4ctur4cion has joined #lisp
pbaille has quit [Ping timeout: 260 seconds]
aeth has quit [Ping timeout: 240 seconds]
arcmutex has quit [Quit: Connection closed]
aeth has joined #lisp
pbaille has joined #lisp
karlosz has quit [Ping timeout: 268 seconds]
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
hypercube has joined #lisp
patlv_ has joined #lisp
rgherdt has quit [Ping timeout: 260 seconds]
froggey has quit [Ping timeout: 252 seconds]
mindCrime has quit [Ping timeout: 240 seconds]
froggey has joined #lisp
psilotorp has quit [Remote host closed the connection]
f4ctur4cion has quit [Ping timeout: 252 seconds]
psilotorp has joined #lisp
<Josh_2>
Theres some writing somewhere about design patterns, maybe by Norvig, saying that design patterns are a consequence of poor flexibility in the language, something like that
<Josh_2>
does anyone have a link? I'm tryna send it to a friend
jnewton` has joined #lisp
kevingal has quit [Remote host closed the connection]