<kscarlet`>
Bike: I'm more concerned on the efficient implementation of a raw dispatch without any previous caching. I imagine this will be crucial for very dynamic code, e.g. creating subclasses in a inner loop
<Bike>
i don't know that anybody has worked on that.
<Bike>
code like that is very rare.
<no-defun-allowed>
Basically, every class gets a fixnum ID, then to dispatch, binary-search on the ID to find the appropriate method
<Bike>
well, worked on it much.
<Bike>
in particular, defining a class is almost certainly going to be slow in itself
<no-defun-allowed>
I made an implementation of that which dispatched on bytes for an interpreter, but it is single-dispatch and pretty static so it's probably not what you are looking for.
<kscarlet`>
single-dispatch is much much easier to deal with
mathrick has joined #lisp
<LdBeth>
And Cecil largely resembles CLOS
<kscarlet`>
i've read lots of paper on efficient dispatching, but none of them has MI&MD&call-next-method
<kscarlet`>
LdBeth: ok let me see
<LdBeth>
Some one I know in PL research field makes a comment on this like "no particularly innovative compiler technology demonstrated in the paper"
<kscarlet`>
LdBeth: so it's static
<kscarlet`>
Bike: for that memoizing vs update stuff, I have a idea to mem-protect a modified instance and update the instances on segfault and GC
<LdBeth>
kscarlet`: Cecil does dynamic dispatch, like CLOS
<Bike>
"memoizing vs update stuff"?
patlv has quit [Ping timeout: 260 seconds]
<kscarlet`>
Bike: because CLOS is interactive you need some wrapper/update stamp etc to make memoization work
<kscarlet`>
Bike: on updates
<Bike>
yes.
<kscarlet`>
Bike: to my understanding this is a major performance penality and also what that paper intend to optimize
<kscarlet`>
Bike: I'm thinking using mem protect to deal with update, thus make slot access/generic method even cheaper
<Bike>
well, the paper is based on the premise that re/defining methods and classes is rare and doesn't need to be optimized so much. and you only need to update instances when a class is redefined.
<kscarlet`>
that's also my premise
<Bike>
i thought you were defining classes in an inner loop.
<kscarlet`>
now i changed my context
<kscarlet`>
and i changed my mind
<Bike>
alright.
<Bike>
(updating an instance is also customizable with the update-instance-for-redefined-class function)
<kscarlet`>
what's the problem of this? limitations in signal handler and functions called by gc?
zooey has quit [Ping timeout: 240 seconds]
<Bike>
well honestly i don't think i understand exactly what you mean - are you saying that rather than letting instance updates be handled by clos per se, you put a trap on the slots' memory so that when they're accessed the updating stuff is done?
Oladon has joined #lisp
zooey has joined #lisp
<kscarlet`>
i mean putting a trap on the updated class object
<Bike>
slot access doesn't really need to touch the class object.
<kscarlet`>
well, then trap also need to be put on slot vector
<Bike>
like what i said?
<kscarlet`>
yes
<kscarlet`>
so no need checking when no update
<kscarlet`>
and handle update in the trap
<Bike>
right, i see.
<kscarlet`>
do u think this work
<Bike>
in beach's method this isn't necessary since checking for obsoleteness is part of the dispatch. for other algorithms it could be nice? that kind of trap isn't my expertise unfortunately.
<kscarlet`>
ok thx
thewrinklyninja has joined #lisp
thewrinklyninja has quit [Quit: Leaving]
jeosol has joined #lisp
madmonkey has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
Qudit314159 has joined #lisp
<beach>
Good morning everyone!
smokeink has quit [Ping timeout: 240 seconds]
smokeink has joined #lisp
Bike has quit [Quit: Lost terminal]
<Josh_2>
Mornin beach
<beach>
Josh_2: The general name of that programming style is "data-driven programming".
smokeink has quit [Read error: Connection reset by peer]
<beach>
It was mostly replaced by the more general concept of "object-oriented programming", but it can still be useful in some situations.
kscarlet` has quit [Ping timeout: 260 seconds]
supersaravia has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
oxum has quit [Read error: Connection reset by peer]
smokeink has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
saravia has joined #lisp
hhdave has joined #lisp
sindan has quit [Remote host closed the connection]
oxum_ has quit [Read error: Connection reset by peer]
oxum has quit [Read error: Connection reset by peer]
<pjb>
I'd use (write-line "Hello World!") rather than print…
oxum has joined #lisp
<Demosthenex>
ah, well it was still small. ;]
<no-defun-allowed>
And Common Lisp is not really a language you use for making "small" programs, since it is very interactive unlike others where you get no control over the process after you compile it.
<Demosthenex>
pjb: the discussion was over the number of system calls and binary sizes for just hello world
<Demosthenex>
not strictly hello world itself ;]
<pjb>
Demosthenex: then type make and ls -l
<no-defun-allowed>
So, a good number of the syscalls will be to set up the SBCL process and tear it back down.
<pjb>
or make test
<Demosthenex>
no-defun-allowed: i agree. i noted that in my comment to the article. the disassembled hello world procedure is only 50 bytes of assembly... but the image is 43 MB. startup time is pretty good though
<Demosthenex>
it's better than node! ;]
<no-defun-allowed>
However most programs are somewhat more complex than printing "Hello, world!" so I wouldn't be worried.
<Demosthenex>
wasn't, the OP article was about a comparison of hello world in many langs with a comparison of the syscalls and sizes. just interesting
<aeth>
Demosthenex: CL doesn't really produce executables in normal operation. For a light program you'd just use an existing CL image rather than something like save-lisp-and-die, which would be more for something big like a computer game or a web browser.
<pjb>
Demosthenex: notably:
<pjb>
-rwxr-xr-x 1 pjb staff 8432 May 5 2019 hw-c
<pjb>
-rwxr-xr-x 1 pjb staff 8696 May 5 2019 hw-ecl
<Demosthenex>
what i was curious about is did i miss something that could improve the CL score
stux|RC-only has joined #lisp
<pjb>
No significant difference between ecl and gcc!!!
<no-defun-allowed>
The only way to win is not to play, IMHO.
<pjb>
But clisp beats them flat: -rwxr-xr-x 1 pjb staff 2285 May 5 2019 hw-lisp-clisp-fas
<pjb>
It's an executable.
<no-defun-allowed>
Let the others mess about with shaving bytes, then ask them why they did when they ask you how to debug their mess.
oxum has quit [Remote host closed the connection]
mathrick has quit [Ping timeout: 265 seconds]
oxum has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
saravia has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 268 seconds]
Inline has quit [Read error: Connection reset by peer]
Inline has joined #lisp
sabrac has quit [Ping timeout: 260 seconds]
sabrac has joined #lisp
<Demosthenex>
i agree the lisp interpreter provides plenty of features, and it's cool to see that ecl is the same size =]
<White_Flame>
what's the asdf syntax for specifying an individual file in another subdirectory?
<jeosol>
pjb: do know have speed metrics, off your head, for clisp vs. SBCL. I use the latter mostly
<jeosol>
* do you have ...
<White_Flame>
(oh, nevermind, had bad syntax in there. plain slashes work)
<eeeeeta>
<pjb> No significant difference between ecl and gcc!!!
Necktwi has quit [Read error: Connection reset by peer]
<beach>
Demosthenex: It is usually not an interpreter.
<beach>
Demosthenex: To many people, when you tell them that Common Lisp is interpreted, they (rightly so) conclude that it must be slow.
<beach>
Demosthenex: The best way of avoiding such rumors is to tell them that most modern systems compile to native code, which is the case.
oxum_ has joined #lisp
oxum_ has quit [Read error: Connection reset by peer]
oxum has quit [Read error: Connection reset by peer]
oxum has joined #lisp
Qudit314159 has quit [Remote host closed the connection]
ahungry has quit [Remote host closed the connection]
narimiran has joined #lisp
<eeeeeta>
wait, does that ECL tiny binary contain code for calling eval
<eeeeeta>
I refuse to believe there's a complete Lisp interpreter in that thing
<beach>
Doesn't ECL come with a shared library?
<no-defun-allowed>
Yeah, I think ECL programs will link to a libecl somewhere.
<beach>
Just like C does (which explains the small binaries you get with C).
oxum has quit [Remote host closed the connection]
<beach>
A shared library is actually a good way to silence those who complain about large binaries.
oxum has joined #lisp
khisanth_ has quit [Ping timeout: 240 seconds]
<beach>
Not that it's important per se.
<eeeeeta>
ah right
<eeeeeta>
that makes much more sense
* eeeeeta
is used to Rust where stable ABIs aren't a thing and all of the stdlib is in the binary
<pjb>
eeeeeta: of course, ecl uses gcc. What's the point?
<eeeeeta>
pjb: well assuming ECL generates good C code, you're just comparing gcc to gcc :p
<beach>
eeeeeta: It is not that simple, given that Common Lisp is dynamically typed.
<eeeeeta>
hmmm
<eeeeeta>
well I wonder whether that example had type declarations everywhere or not
<pjb>
the point here is that there's a CL library, just like there's a C library. libecl is about the same size as libc. Other CL implementation statically link this CL library in the lisp images. clisp (fasls) and ecl don't.
<oni-on-ion>
ECL is indeed full lisp, and has shared lib
<pjb>
Why shared library were invented? For space saving! Why is there no pressure to share space in modern CL implementations? Because we are not space constrained anymore!
orivej has joined #lisp
<pjb>
oni-on-ion: even if you try to imagine a situation where this could be a problem it doesn't break: we're in a O(1) situation, not a O(n) one!
<pjb>
ie. there's a finite number of programs installed on a platform.
<eeeeeta>
but yeah, I am probably oversimplifying things here
<beach>
pjb: Unix-style shared libraries were invented in order to compensate for a particularly stupid operating systems. A lot more sophisticated techniques existed before Unix destroyed those techniques, and the knowledge about them.
khisanth_ has joined #lisp
<oni-on-ion>
hmm. arent they a good thing, .so ?
<oni-on-ion>
i vaguely remember the transition from .a in linux
<beach>
oni-on-ion: As you as it gets if Unix is all you have, sure.
<beach>
I mean, the knowledge is still around, of course, but generations of developers now think that Unix is the best thing since sliced bread, and that nothing better existed before.
<oni-on-ion>
nowadays we bundle everything into an app, like AppImage, Electron, any mobile apps...
<oni-on-ion>
i was looking at the Plan 9 editor today, Acme, briefly. and the Alef programming lang originally used to implement it
orivej has quit [Ping timeout: 265 seconds]
<beach>
As *good* as it gets. Sorry.
mangul has joined #lisp
<oni-on-ion>
its ok =) hmm.
<beach>
oni-on-ion: What is disturbing to me is that the Unix static linking was incredibly stupid, and then we invent a kludge like Unix-style shared libraries to somewhat compensate for that stupidity, and everybody thinks it is great.
<oni-on-ion>
what would be best, in your eyes ?
<beach>
I'll answer that differently by saying that Multics was way better than Unix.
<beach>
Developers today really need to read up on their history in order not to be duped by silly kludges.
<oni-on-ion>
10000% agree with that one.
<oni-on-ion>
going to check out the multics stuff
karlosz has quit [Quit: karlosz]
<beach>
Sure, but we can do even better today.
<oni-on-ion>
i am thinking we might have to. things are getting quite out of hand out there in the wild
<beach>
You might want to read metamodular.com/closos.pdf to get some ideas of what could be done.
<beach>
I really think we need to abandon this idea from the 1950s that we should always write code as if we have the entire physical machine available.
oxum_ has joined #lisp
<oni-on-ion>
ahh i see the multics dynamic linking -- i'd say also that is how i would imagine things to happen. that is how i imagine something like Genera to operate but i am not sure.
<beach>
I thing Genera is very different.
<oni-on-ion>
beach, ahh, yeah =) i will actually load that pdf and read it. apologies for not having done so yet
<oni-on-ion>
well, the idea of multics where files and processes are in the same "space"
<beach>
Dynamic linking like that is needed only when this silly programming model is a must.
<oni-on-ion>
that is a big point of confusion/complexity for any modern OS
<beach>
That's not quite true about Multics.
<beach>
It had no files. It had "segments" that behaved like primary memory.
<beach>
But it did have processes, but more course-grained than those of Unix.
<beach>
So, Multics had the same problem as Unix, in that you can't send a pointer across process boundaries.
oxum has quit [Ping timeout: 258 seconds]
<oni-on-ion>
eh yeah, that is what i meant
<oni-on-ion>
hmm.
<beach>
So I am not advocating a return to Multics. I am advocating something like Genera, except also safe and multi-user.
oxum has joined #lisp
oxum has quit [Remote host closed the connection]
<beach>
But then, people need to abandon this silly idea from 60 or more years ago, that we should program as if we have access to the physical machine, with its RAM starting at address 0, and with the call stack fully accessible.
oxum_ has quit [Read error: Connection reset by peer]
oxum has joined #lisp
<White_Flame>
the Mill CPU has an interesting model of pointer-passing in a single-address space with process-style but heirarchical memory protection
<beach>
That's not what we have done though. We invented shared libraries. Then we invented ASLR to compensate for the silliness of shared libraries.
<beach>
White_Flame: Interesting.
<beach>
I think we can do well with existing hardware though, if we just abandon this silly programming model that has caused so much problems.
<beach>
s/much/many/
<lieven>
the AS400 had also some neat ideas. kind of the anti unix. nothing is a stream of bytes. everything is a typed object.
<White_Flame>
sure, but you might fight against the hardware performance-wise, but as long as the functionality is transparently supported in the environment, the speed can come later
<beach>
lieven: Definitely.
<White_Flame>
yeah, streams of bytes is a real big complaint of mine as well
<beach>
White_Flame: On the contrary, my proposal makes context-switches unnecessary, so things will be much faster.
<beach>
Recent research is moving I/O to user space to compensate for context-switch slowness, making the system even more complicated and less safe, all in order to preserve the silly programming model.
<beach>
So it is yet another kludge to avoid questioning the silliness of this model.
scymtym has quit [Ping timeout: 260 seconds]
<lieven>
well, even the chip designers have to do this since it's been found impossible to teach random programmers to write working large scale parallel programs
<lieven>
so we have underneath a large amount of ALU's and then a layer that pretends it's just one CPU
<lieven>
and then came spectre and the like
<oni-on-ion>
hmmmm
<beach>
Indeed. Processor manufacturers are working hard to make people believe that they are still making PDP-11s.
shifty has quit [Ping timeout: 258 seconds]
<beach>
The amount of silicon real-estate that is costing is staggering.
<beach>
Not to mention the energy it costs to run the thing.
<jackdaniel>
eeeeeta: libecl is around 3.5MB after stripping and it has full common lisp environment at your disposal
<jackdaniel>
compiler to C is another 500KB
* eeeeeta
not bad meme
<eeeeeta>
okay my Rust 200MB binaries are starting to look a tad ridiculous now
<eeeeeta>
although that's all due to monomorphization, probably
<lieven>
probably not something they've put a lot of effort in
<eeeeeta>
no
<lieven>
there's no reason something like a tree shaker couldn't be written for Rust
<jackdaniel>
sorry, compiler is 1.1MB after striping
<eeeeeta>
well they do thinLTO
<eeeeeta>
and LTO is pretty much a tree shaker AIUI
<eeeeeta>
it's not unused stdlib code that's the problem though
<no-defun-allowed>
They make unpolymorphic code from every possible type fed to polymorphic code?
<eeeeeta>
yep
<lieven>
yeah
<no-defun-allowed>
WHY?
<lieven>
at source level even if I understand correctly
<no-defun-allowed>
I'm pretty sure every ML-ish compiler spits out polymorphic code.
<eeeeeta>
optimizing for runtime performance
<eeeeeta>
you can use trait objects for dynamic dispatch though
<ebzzry>
Why are alist items dotted lists?
<pjb>
ebzzry: because they are not.
<ebzzry>
Or, why are dotted lists used most frequently?
<pjb>
ebzzry: they are pairs of (key . value).
<pjb>
dotted lists are not used frequently at all, because they make one more special case to test when processing them!
<ebzzry>
pjb: hm
* no-defun-allowed
recalls a significant part of Appel's compiler book was about how to make polymorphic data layouts and code
<beach>
ebzzry: What would you have liked for them to be instead?
<ebzzry>
Does PAIRLIS only create dotted lists?
<pjb>
ebzzry: no, it only creates proper lists. Because alists are proper lists!
<ebzzry>
beach: nothing special. I was just wondering that a common use of alist is with dotted lists.
<ebzzry>
Indeed.
<pjb>
ebzzry: but you're wrong: there is no dotted list in an a-list (unless you put one yourself there).
<pjb>
ebzzry: a-lists are PROPER lists of pairs!
<ebzzry>
pjb: Yes, you are correct.
<beach>
ebzzry: If the data items are proper lists, the alist items will be proper lists as well.
<ebzzry>
alists are proper lists of pairs.
<beach>
ebzzry: But the CDR of each pair may be a proper list.
<beach>
ebzzry: In which case, no dotted lists are involved.
<ebzzry>
Is it faster to get v, when the structure is (k . v) instead of (k v)?
<eeeeeta>
yes
<eeeeeta>
you follow 1 pointer instead of 2
<ebzzry>
eeeeeta: by a factor of how much, in estimate?
<eeeeeta>
uh, 2??
<pjb>
:-)
<ebzzry>
;-)
<beach>
ebzzry: Of course. One is (CDR x), the other one is (CAR (CDR x)).
hhdave has joined #lisp
<ebzzry>
I have always wondered about it but never tested it. :-)
ArthurStrong has joined #lisp
jprajzne has joined #lisp
gravicappa has quit [Ping timeout: 258 seconds]
orivej has joined #lisp
<White_Flame>
ebzzry: in modern systems, the memory bandwidth and cache pressure is probably going to be more constraining than the raw CPU clocks
<ebzzry>
White_Flame: hm
<beach>
I second that.
mingus has joined #lisp
lavaflow has quit [Ping timeout: 265 seconds]
varjag has joined #lisp
hhdave has quit [Ping timeout: 258 seconds]
cyraxjoe has quit [Ping timeout: 260 seconds]
cyraxjoe has joined #lisp
scymtym has joined #lisp
lavaflow has joined #lisp
lavaflow has quit [Ping timeout: 258 seconds]
william1_ has joined #lisp
oni-on-ion has quit [Quit: Quit]
<eeeeeta>
now the question is whether the Lisp implementations allocate cons cells close to one another to avoid horrible CPU cache performance
hhdave has joined #lisp
william1_ has quit [Ping timeout: 268 seconds]
william1_ has joined #lisp
<White_Flame>
eeeeeta: there's 2 aspects: initial allocation, and GC relocation
<White_Flame>
initial allocation is a purely linear bump pointer (within a slab allocation)
<eeeeeta>
ah right
<eeeeeta>
okay, that shouldn't be too bad
<White_Flame>
GC would tend to walk a list and place items in order, but it depends on if it does the CAR first or CDR first
rippa has joined #lisp
slyrus__ has joined #lisp
slyrus_ has quit [Ping timeout: 268 seconds]
<beach>
I advocate a sliding collector so that objects allocated together stay close.
<beach>
But I don't think that's what most Common Lisp implementations do, probably because the sliding GC algorithm, as described in the literature, is inefficient. That's why I had to improve it. :)
<beach>
Furthermore, traditional copying collectors will promote anything that is live, whereas the sliding collector can be made to promote in strict order of age. That way, there is less risk that a promoted object will die soon after garbage collection.
paul0 has quit [Remote host closed the connection]
paul0 has joined #lisp
ArthurStrong has quit [Quit: leaving]
jfb4 has quit [Ping timeout: 258 seconds]
libertyprime has joined #lisp
jfb4 has joined #lisp
reg32 has joined #lisp
<reg32>
Hi, is roswell something that IS REALLY used by the CL community?
<Shinmera>
what are you actually asking?
<reg32>
I am investing some time recently in trying to resolve some roswell bugs
<reg32>
I am just trying to understand if I am wasting my time or not
<Shinmera>
some people use it, some do not.
<reg32>
it's pretty a strange project
<pjb>
I don't even know what it is. Is it some kind of UFO simulator?
<reg32>
there is a C frontend that just donwloads a CL runtime, parses command line paramenter adn then delegates all the rest to LISP code
<Shinmera>
pjb: It's an implementation manager
<reg32>
but logging is a mess
<reg32>
in the C code error are not managed properly
<Shinmera>
supposed to allow you to easily install any implementation on a supported platform.
<reg32>
and also since most of the business logic in the end is implemented in CL also having a C trigger is really questionable
<reg32>
if it is for the sake of having an executable that could have been done simply with a full CL implementation
<reg32>
the point at which I am now
<Shinmera>
Well the C part of "just" downloading an implementation is the primary reason for itss existence, if I remember correctly.
<reg32>
the pity is that
<reg32>
the C part doesn't properly manages errors
<reg32>
and logs are completely incosistent
random-nick has joined #lisp
<Demosthenex>
looks like python's virtualenv?
<reg32>
yes it's something like python virtualenv
<reg32>
but with only one environment at a time I guess
<Shinmera>
? roswell allows you to install any number of implementations.
<reg32>
so I am really tempted to heavily refactor the C part
<reg32>
yes Shinmera
<reg32>
but my understanding is that you can have only a single "environment" per each CL implementation
gxt has quit [Ping timeout: 240 seconds]
<reg32>
with virtualevn you can have multiple environments for the same python implementation
<Shinmera>
ah, ok
gxt has joined #lisp
<reg32>
before doing that I would like to understand whether it is worth the effort
<Shinmera>
only you can answer that for yourself.
davepdotorg has joined #lisp
<reg32>
for me it's a matter of people impacted
jfb4 has quit [Ping timeout: 240 seconds]
<reg32>
if my work is not going to have an impact
<reg32>
it's not interesting
jfb4 has joined #lisp
shifty has joined #lisp
larme has joined #lisp
larme has quit [Client Quit]
larme has joined #lisp
EvW1 has joined #lisp
<TMA>
reg32: I personally do not use it, because it failed to work for me. (on microsoft windows that is)
Frobozz has joined #lisp
<TMA>
reg32: I have seen it used in continuous integration scripts for some lisp projects
<reg32>
TMA did you file a bug on the github repo?
<reg32>
In fact I am trying to fix stuff that don't work on Windows
shifty has quit [Ping timeout: 258 seconds]
<reg32>
Windows is too much negleted and this, in my opinion, damages the popularity of CL
<TMA>
reg32: no. I do not file bug reports. Either I am able to fix it myself or I do not bother others
<reg32>
ok
shifty has joined #lisp
oxum_ has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
oxum_ has quit [Read error: Connection reset by peer]
<TMA>
reg32: my remark was intended as a data point for you about the popularity, nothing more
<reg32>
ros init
<reg32>
ros install sbcl with the release I just pasted above?
oxum_ has joined #lisp
oxum_ has quit [Read error: Connection reset by peer]
<TMA>
reg32: wait a second, I'll try
<reg32>
on Windows obviously
oxum_ has joined #lisp
larme has quit [Quit: WeeChat 2.3]
oxum has quit [Ping timeout: 268 seconds]
larme has joined #lisp
larme has quit [Client Quit]
<TMA>
reg32: it is downloading sbcl. it appears to be hung on the second line of [##########################################################################]100%
<reg32>
wait
<reg32>
it takes a lot of time
<reg32>
you shall wait until it ends
<reg32>
either with an error or with a success
<reg32>
it will fill your home with about 1GB of software
<reg32>
including 7zip
<reg32>
msys
<reg32>
sbcl sources
<reg32>
build artifacts
<reg32>
let it go for at least 15 minutes
larme has joined #lisp
<TMA>
ok
nullniverse has quit [Quit: Leaving]
oxum has joined #lisp
oxum has quit [Remote host closed the connection]
oxum has joined #lisp
mangul has quit [Remote host closed the connection]
mangul has joined #lisp
oxum_ has quit [Ping timeout: 265 seconds]
v88m has quit [Ping timeout: 268 seconds]
reg323 has joined #lisp
EvW1 has quit [Ping timeout: 248 seconds]
reg32 has quit [Ping timeout: 260 seconds]
jonatack has quit [Quit: jonatack]
shifty has quit [Ping timeout: 265 seconds]
shifty has joined #lisp
<edgar-rft>
roswell takes so long on windows that reg32 gave up to wait for an answer :-)
<TMA>
from the log file it seems to wait about 12 minutes for each samba drive before progressing to the next drive
<TMA>
as I have interrupted it after the second, I do not know whether it would finish afterwards
<galdor>
funny thing is that the problems comes from PRINT-IDENTIFIER which really wants to find a XML namespace associated with the package of the symbol P
<galdor>
it does not find one
<galdor>
and therefore GET-PREFIX (seriously, why would you use such an accessor name) fails because there is no method for NIL
<galdor>
so yes, bad code, you could probably patch it fairly easily to signal an error indicating that there is no XML namespace associated with the package
<galdor>
but s-xml isn't maintained
<duncan_bayne>
galdor: That makes sense. Oddly that example is straight from the s-xml docs, so I'd assumed I was doing the Wrong Thing
<galdor>
and it's GPL
reg323 has quit [Ping timeout: 260 seconds]
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
shifty has quit [Ping timeout: 265 seconds]
shifty has joined #lisp
oxum has quit [Read error: Connection reset by peer]
oxum has joined #lisp
reg32 has joined #lisp
<eeeeeta>
man, ECL is actually slow
<eeeeeta>
to compile, that is
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
hhdave has joined #lisp
oxum has quit [Remote host closed the connection]
smokeink has quit [Quit: Leaving]
jmercouris has joined #lisp
ggole has joined #lisp
duncan_bayne has quit [Ping timeout: 258 seconds]
<jmercouris>
most succinct way to do conditional assignment?
<jmercouris>
I have something like (defun search (string case-sensitive-p) ...)
<jmercouris>
I want to transform string ONLY if case-sensitive-p
<jmercouris>
I am using a (let ((string (if case-sensitive-p string (lowercase-function string))))...)
<jmercouris>
I can't remember what the actual loewrcase-function is, that is just pseudo code
shifty has quit [Ping timeout: 268 seconds]
shifty has joined #lisp
<jmercouris>
string-downcase for future readers...
<jmercouris>
anyways, that's not the essence of the above question, feedback appreciated!
<jmercouris>
normally I would not write code like this, but I am translating some parenscript
<phoe>
the additional binding ensures that the original variable is not overwritten, which is important for debugging
oxum has joined #lisp
pfdietz6 has joined #lisp
<jmercouris>
I would like to understand setf a little bit more
<jmercouris>
I understand that it is a macro that *does the right thing* for assignment
<jmercouris>
is it bad to setf arguments supplied to a function?
<jmercouris>
I feel like I have read that before somewhere
<pfdietz6>
It's fine to setf the arguments to a function. That seems like a silly rule not to, from some functional programming puritan.
<jmercouris>
perhaps it is something I internalized a long time ago without giving it due diligence
<jmercouris>
in that case beach's form is the most succinct and obvious
<jmercouris>
thank you for the information everyone
<pfdietz6>
The easiest way to use setf is to define setf functions, although perhaps not the most efficient.
nirved has quit [Ping timeout: 252 seconds]
<pfdietz6>
You can make those setf functions generic, which is quite nice.
<pfdietz6>
How can I get access to the common-lisp.net GitLab? I want to fork Alexandria there.
<jmercouris>
hm, OK
nirved has joined #lisp
<phoe>
jmercouris: a function argument is just Yet Another Variable Binding
<phoe>
pfdietz6: ask on #common-lisp.net
<pfdietz6>
k thx
<phoe>
jmercouris: as with any other variable binding, you can mutate it, so setfing it is possible
<beach>
pfdietz6: I have been known to say that it's a bad idea to assign to parameters. But it is not for the reasons you cite. It is purely a question of ease of debugging. If your Common Lisp implementation overwrites the parameter, it is harder to understand how the function was called in the first place.
<phoe>
^
<phoe>
that's why I introduced the additional (let ((string string)) ...) binding
<phoe>
if you overwrite the original parameter, it's gone from the stacktrace
<beach>
It could be. I guess it depends on the implementation.
<jmercouris>
phoe: I see!
<beach>
jmercouris: I am telling you this from experience, where I have spent time staring at backtraces, not understanding how on earth a function could have been called the way the backtrace indicates.
<beach>
... only to understand that the parameter was assigned to in the function body.
atgreen_ has quit [Quit: Leaving]
<pfdietz6>
Hmm, ok.
<jmercouris>
Ahhhh :-D
<jmercouris>
The lisp debugger, especially when it is invoked during some ASDF operation, is still quite a mystery to me
<jmercouris>
I can't seem to reason about the traces
<jmercouris>
I'll expand the elements, look, and there's a ton of gobbledygook
<jmercouris>
sometimes it works for me though, so I must be getting better :-D
EvW has quit [Ping timeout: 245 seconds]
hhdave has quit [Ping timeout: 258 seconds]
hsaziz has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
wxie has joined #lisp
<pfdietz6>
Good grief, this is user-hostile.
oxum has quit [Remote host closed the connection]
hsaziz has quit [Ping timeout: 265 seconds]
<phoe>
pfdietz6: it's to avoid spambots, it seems. clnet has had a big problem with those for a while.
<pfdietz6>
And yet, GitHub doesn't need any of this?
oxum_ has joined #lisp
mingus has quit [Remote host closed the connection]
bitmapper has joined #lisp
kscarlet has joined #lisp
<pfdietz6>
Welll that exceeded my annoyance threshold. Maybe I'll try again sometime when I'm not so annoyed. What an exercise in unnecessary nonsense.
<phoe>
pfdietz6: GitHub has it optional, whereas clnet gitlab has it mandatory.
EvW has joined #lisp
<pfdietz6>
The spambots were hitting the wiki pages, right?
<phoe>
GitLab itself.
oxum_ has quit [Remote host closed the connection]
<phoe>
You can possibly ask ehuelsmann about the details.
gravicappa has joined #lisp
z147d has joined #lisp
oxum has joined #lisp
kscarlet has quit [Remote host closed the connection]
<galdor>
I'm not even sure there is anyone with any exclusive official claim on Common Lisp in general
ym has quit [Quit: Leaving]
shifty has quit [Ping timeout: 258 seconds]
shifty has joined #lisp
libertyprime has quit [Quit: leaving]
<phoe>
there isn't
<phoe>
also CLF is alive, they just haven't updated their website in MOST-POSITIVE-BIGNUM years
<phoe>
...oooooh, *that* kind of dead
<phoe>
their website is gone altogether
<phoe>
galdor: "we", as in, #common-lisp.net
<galdor>
this kind of dead stuff is depressing
<phoe>
yes, it is
<galdor>
anyway there's no real point in using a common-lisp gitlab account when you can use github/gitlab/whatever and librelist, without having to jump through the hoops
<galdor>
do not take it the wrong way, I just started using CL recently, and I'm trying really hard to convince myself it's not a stupid decision and I'm not wasting my time
<galdor>
*started again
shifty has quit [Ping timeout: 240 seconds]
shifty has joined #lisp
reg32 has quit [Remote host closed the connection]
<jackdaniel>
people who are interested to use non-profit gitlab instance (instead of for-profit popular alternatives) are in their right to do so. nobody forces you to keep your code on cl.net gitlab (in fact afaik most projects are kept on github)
<galdor>
of course
kscarlet` has joined #lisp
learning has joined #lisp
kscarlet has quit [Ping timeout: 260 seconds]
atgreen has joined #lisp
makomo has joined #lisp
kscarlet` has quit [Remote host closed the connection]
kscarlet` has joined #lisp
FreeBirdLjj has joined #lisp
EvW has quit [Ping timeout: 248 seconds]
_jrjsmrtn has joined #lisp
Bike has joined #lisp
__jrjsmrtn__ has quit [Ping timeout: 260 seconds]
oxum has quit [Remote host closed the connection]
<pfdietz>
I wanted to use common-lisp.net gitlab so I could fork and then issue pull requests. I don't suppose there's a way to do that to cl-net from github, is there?
shifty has quit [Ping timeout: 258 seconds]
count3rmeasure has joined #lisp
<eeeeeta>
pfdietz: I mean, you could do it the old-school way: clone the repo, upload it to a new repo on github, do your changes, send them a patch via email
<pfdietz>
The specific project was Alexandria, which as far as I can tell has its official repo on cl-net.
shifty has joined #lisp
<eeeeeta>
or open an issue or something with "please pull from this repo"
<pfdietz>
To open an issue on cl-net I need to log in to cl-net, right?
<eeeeeta>
oh yeah
<eeeeeta>
that is a problem
oxum has joined #lisp
* eeeeeta
suspects that people who are savvy enough to use self-hosted git alternatives will probably also be able to accept email patches, though
<eeeeeta>
I don't know whether they would, but http://git-send-email.io/ would be helpful if that were to be the case
cosimone has joined #lisp
oxum has quit [Remote host closed the connection]
oxum has joined #lisp
<dlowe>
I've accepted an email patch before and it wasn't a big deal
oxum has quit [Read error: Connection reset by peer]
<patlv>
morning everybody, I want to use CL as an embedded DSL for a product I'm developing, I'm wondering what's the best way, use the full sbcl, by locking functionalities that I don't need/want if it's at all possible, or implement a lisp in lisp with only the functionalities that I need
oxum has joined #lisp
hhdave has joined #lisp
<dlowe>
the latter
<dlowe>
another third option is to write a translator from your dsl-lisp to common lisp
<patlv>
yes good point
brown121408 has quit [Remote host closed the connection]
<dlowe>
a fourth option (and one that I don't much use of) is to use lambda chaining to build up a sequence of code
brown121408 has joined #lisp
<dlowe>
lemme find you an example because it's hard to explain
<eeeeeta>
patlv: or use Embeddable Common Lisp (ECL)
<patlv>
the thing is the security needs to be very tight, I don't want users to be able to do anything they want
<patlv>
especially IO related stuff
<eeeeeta>
oh right, got you
<eeeeeta>
in that case, writing your own DSL does sound like the way to go
LiamH has joined #lisp
<patlv>
yes indeed, I hoped there was an easier way
<beach>
patlv: Is this an existing product or a new one?
<patlv>
beach: a new one
<beach>
Then why not write the entire thing in Common Lisp?
<beach>
It solves many problems.
<patlv>
that's the case, it's all CL
<beach>
Oh, sorry, misunderstood.
<beach>
And why can't Common Lisp be your DSL?
<eeeeeta>
14:38:21 <patlv> the thing is the security needs to be very tight, I don't want users to be able to do anything they want
<eeeeeta>
beach: ^
<beach>
I saw that, but what is it that they are not allowed to do and why?
<patlv>
yes, the engine is in CL, and that's why I wished there was a way to just import client scripts and eval them one way or another, but I'd need to be able to completely sandbox it
<beach>
OK, so the language itself would be OK, but you just want to restrict some functionality?
<patlv>
all IO stuff, writing on disk, network, anything that can be used to use mess things up
<beach>
Sure.
mathrick has joined #lisp
<patlv>
bach: yes, exactly, I want the language without anything else basically
<beach>
patlv: It seems clothespin needs to do exactly the same thing as you do.
<beach>
It is pretty hard to sandbox Common Lisp. What I suggested to him was to use the Cleavir front end to translate the source code using first-class global environments to an AST, and then to translate the AST to Common Lisp that accesses only that first-class global environment.
<beach>
patlv: I know what I am suggesting sounds complicated, but almost all the components are in place. All that is needed is a fairly simple translator from ASTs to Common Lisp. And I am pretty sure that technique could be documented in a paper to submit to ELS.
<beach>
... since many people want sandboxing and it is pretty hard to accomplish.
<beach>
But I can see why you would be put off by the external dependencies. So never mind. I might just try this myself.
Lord_of_Life_ has joined #lisp
<dlowe>
If you want a sandbox, I feel that a language runtime is the wrong place for it
<dlowe>
because it won't protect you from all classes of malicious attack
<beach>
dlowe: Can you elaborate on that?
<dlowe>
Like CPU/memory consumption attacks, or rowhammer, or spectre
<beach>
And what approach would protect from those?
<dlowe>
almost nothing :D don't run user code
<phoe>
For DoS, some sort of time and memory constraints put on the user program. For Rowhammer and Spectre, see the respective mitigation techniques.
<dlowe>
You can get close with VMs and quotas
Lord_of_Life has quit [Ping timeout: 260 seconds]
Lord_of_Life_ is now known as Lord_of_Life
<dlowe>
you'd also need to make sure that they can't hit storage outside of the sandbox
efm has joined #lisp
hhdave has quit [Ping timeout: 260 seconds]
Lycurgus has joined #lisp
<patlv>
yes, I'll run those user scripts in cgroups, so here my fear with using "eval" is that they use it for spamming or DOS etc
slyrus_ has joined #lisp
<dlowe>
oh, right, letting them access network ports also enables all sorts of mischief
<patlv>
exactly, all IOs basically
<dlowe>
I really think a dsl is the way to go. A whitelist of operations instead of a blacklist.
<dlowe>
You'd also have to cut out all the FFI functionality so that a program couldn't set up its own syscall functions
<patlv>
dlowe: absolutely
<patlv>
dlowe: the tempus code you sent is very nice
<patlv>
I'm gonna test it, but could definitely be what I need
gigetoo has quit [Ping timeout: 240 seconds]
slyrus__ has quit [Ping timeout: 268 seconds]
gigetoo has joined #lisp
lucasb has joined #lisp
<Shinmera>
It's a catch-22. As soon as it's turing complete there's security problems, and if it's not turing complete it's almost useless.
eschulte has joined #lisp
<Lycurgus>
turing complete = security hole
<patlv>
the way I see it but maybe i'm too optimistic, the base language, without imports + only a set of functions they can use inside the language, should be pretty tight
<patlv>
right?
<phoe>
I mean, you need to solve the issue of people running the equivalent of (loop) inside your code
<phoe>
to avoid denial of service attacks
papachan has joined #lisp
<TMA>
I totally concur with Shinmera's assessment. I remember an old version of mediawiki (wikipedia's wiki software) that would not have its templates turing complete because the depth of expansion was limited to I think seven. without that limitation it would be useful but DoS prone
<phoe>
that's all about Turing completeness
<Shinmera>
patlv: In effect you'll be fine because your service will probably not be popular enough to catch the attention of people who are really serious about finding security vulnerabilities.
<dlowe>
Shinmera: I disagree about uselessness. Turing complete languages are commonly used when a lesser complexity language would work just fine
<Shinmera>
That's not a guarantee, but hardware-level exploits and shit about breaking out of multiple levels of virtualisation and runtime encapsulation shows it's just a really really hard thing.
<patlv>
shinmera: definitely
<Shinmera>
Really really hard to secure, I mean.
<dlowe>
fortunately, unless you've got state-level actor problems, it's probably not a problem in practice
<Shinmera>
dlowe: I meant in the context of what appears to be a service to run arbitrary code.
<dlowe>
yes
<patlv>
yes, there' no way to make sure they won't find an exploit at the OS level even
Lycurgus has quit [Quit: Exeunt]
jprajzne has quit [Quit: Leaving.]
learning has quit [Remote host closed the connection]
karswell has quit [Remote host closed the connection]
patlv_ has joined #lisp
karswell has joined #lisp
TwoFinger has joined #lisp
patlv has quit [Ping timeout: 265 seconds]
shangul has quit [Ping timeout: 240 seconds]
pjb has quit [Remote host closed the connection]
kscarlet` has quit [Ping timeout: 258 seconds]
shangul has joined #lisp
pjb has joined #lisp
shangul has quit [Remote host closed the connection]
shangul has joined #lisp
stux|RC-- has joined #lisp
stux|RC has quit [Ping timeout: 265 seconds]
karlosz has joined #lisp
shifty has quit [Ping timeout: 258 seconds]
smazga has joined #lisp
shifty has joined #lisp
karlosz has quit [Quit: karlosz]
count3rmeasure has quit [Quit: Leaving]
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
rumbler3130 has joined #lisp
antepod has joined #lisp
EvW has quit [Ping timeout: 260 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
green` has joined #lisp
green` has quit [Remote host closed the connection]
atgreen has quit [Quit: Leaving]
karlosz has joined #lisp
oxum_ has joined #lisp
oxum_ has quit [Remote host closed the connection]
jebes has joined #lisp
oxum has quit [Ping timeout: 265 seconds]
gareppa has joined #lisp
cosimone has quit [Quit: Terminated!]
stux|RC-- has quit [Quit: Aloha!]
oxum has joined #lisp
stux|RC has joined #lisp
cosimone has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
cosimone_ has joined #lisp
cosimone has quit [Read error: Connection reset by peer]
hhdave has joined #lisp
varjag has joined #lisp
oni-on-ion has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
lavaflow has joined #lisp
v88m has joined #lisp
EvW1 has joined #lisp
davepdotorg has quit [Remote host closed the connection]
davepdotorg has joined #lisp
davepdotorg has quit [Ping timeout: 260 seconds]
hhdave has quit [Ping timeout: 265 seconds]
count3rmeasure has joined #lisp
slyrus__ has joined #lisp
dorapan has joined #lisp
<dorapan>
hello
aindilis` has joined #lisp
aindilis has quit [Ping timeout: 265 seconds]
slyrus_ has quit [Ping timeout: 260 seconds]
aindilis` has quit [Remote host closed the connection]
<beach>
Hello dorapan.
dorapan has quit [Quit: leaving]
aindilis has joined #lisp
brown121407 has joined #lisp
patlv has joined #lisp
brown121408 has quit [Ping timeout: 260 seconds]
brown121408 has joined #lisp
brown121407 has quit [Ping timeout: 260 seconds]
patlv has quit [Remote host closed the connection]
<no-defun-allowed>
the Genera convention forbids anyone from sending code of such mind-rotting on IRC
<oni-on-ion>
or %percent% or #hash#
<oni-on-ion>
(defvar m_pszTItle "a title") -- member, pointer, string, zero-terminated. was a MFC thing =)
<oni-on-ion>
ah _death got it. i think lp is long pointer ?
<_death>
yes.. and sz is asciiz string (ascii nul-terminated string)
<oni-on-ion>
yep.
william1_ has quit [Ping timeout: 268 seconds]
<oni-on-ion>
mentioned it. personally... i think namespaces are enough. and local bindings (let)
<no-defun-allowed>
hmm, where did I put that Lisp program that was "improved" by Hungarian notation
<oni-on-ion>
to avoid not having any fancy characters in symbols
<oni-on-ion>
admittedly i do like camelCase and ThisCase
<no-defun-allowed>
):
<oni-on-ion>
it takes advantage of how my teenage brain was wired for scope and other invisible constructs from C days
<oni-on-ion>
can a symbol be a namespace? i mean... can namespaces then be recursive if their names are symbols?
* no-defun-allowed
cannot remember where she put that code
<no-defun-allowed>
it was in a picture, preceded by instructions to "rewrite a program to use camel case or Hungarian notation, then post the improved program" then had "We don't do that here" at the end
<oni-on-ion>
aw i want to see it. lmk if you happen to come across it
<no-defun-allowed>
I could make a new one. It was just some code I had to rewrite a pattern (for pattern matching) into a set of tests.
<oni-on-ion>
nah dont do it for me, i've got enough unconventional ideas =P
<no-defun-allowed>
The scary thing was that was mandated by the education board here.
<oni-on-ion>
interesting; applying notations to any ole lang ?
<no-defun-allowed>
Supposedly it was to support schools which still used some variant of BASIC, so no one else got to learn anything more like object-oriented programming or higher order functions.
<vivit>
no-defun-allowed: you forgot to put "my" in front of everything
<no-defun-allowed>
Ow.
<oni-on-ion>
)=
<no-defun-allowed>
Anyways, there's probably something more on-topic to discuss while I figure out what I wrote.
Frobozz has quit [Read error: Connection reset by peer]
<vivit>
Can you tilde-escape newlines in docstrings like you can in format strings?
<no-defun-allowed>
Not really.
<no-defun-allowed>
You can use #.(format nil "string goes here~<Newline>more string") as a documentation string, but that's using a format string to produce the documentation string.
TMA has quit [Ping timeout: 246 seconds]
akoana has joined #lisp
efm has quit [Ping timeout: 268 seconds]
skidd0 has joined #lisp
efm has joined #lisp
TMA has joined #lisp
Odin- has joined #lisp
LiamH has quit [Quit: Leaving.]
<jasom>
oni-on-ion, _death, apparently using symbols to name packages was considered at some point a long time ago, but considering that the parent package often wanted to use symbols from the child package, but the child package would have to be declared second is was considered unergonomic
learning has joined #lisp
<oni-on-ion>
jasom, ahh, that is a good reason . (fwiw where haskell solves with exported symbol lists like in CL, and ocaml with its parametric module system.)
<oni-on-ion>
another question... (in-package #:so-and-so) converts the symbol to a string then?
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jasom>
(in-package FOO) can be any of 1) the string name of the package 2) a string designator for the name of the package 3) the package object itself.
efm has joined #lisp
<jasom>
FOO can be any of those 3 rather
<oni-on-ion>
aha. thank you very much
<jasom>
so (in-package some-name) (in-package :some-name) (in-package "SOME-NAME") and (in-package #.(find-package "SOME-NAME")) should all get you in the same package.
wxie has joined #lisp
<jasom>
The read-time side-effects are different though.
<phoe>
only in the last case
<phoe>
the first three are equivalent
<jasom>
phoe: no, they aren't. The first two intern symbols in the current package and KEYWORD respectively
<oni-on-ion>
that inspires me another question. what if, let's say ... package A, package B. inside package A is symbol X which resolves to package B <or string>. can we do (in-package X) ?
<phoe>
oh! you mean that, yes
<phoe>
there's also (in-package #:some-name) then
<phoe>
oni-on-ion: nope, the macro syntax prevents it.
<jasom>
oni-on-ion: no, because the package name is not evaluated
<phoe>
you can however manually (setf *package* (find-package :cl-user)) if you want to play with that
<oni-on-ion>
ahh right. considering the first example (in-package some-name) is what i feared, that it was macro
<oni-on-ion>
phoe, hmm =)
<jasom>
or you could just write a macro: (defmacro in-package* (x) `(in-package ,x))
<jasom>
nevermind, that won't work for the same reason
<oni-on-ion>
i like that one -- oh
* jasom
is tired
<jasom>
I'm going to go get some caffeine before talking any more
<oni-on-ion>
essentially i am looking to avoid mylisp-subsystem-section-specificpackage kind of naming. symbols can get quite long winded enough as it is
skidd0 has left #lisp ["WeeChat 2.7"]
wxie has quit [Ping timeout: 265 seconds]
vivit has quit [Ping timeout: 240 seconds]
efm has quit [Ping timeout: 268 seconds]
random-nick has quit [Ping timeout: 268 seconds]
<jasom>
oni-on-ion: you can look at how e.g. asdf does things. UIOP has some tools for automatically re-exporting symbols from some packages, and it uses the notation of main-package/subpackage:symbol-name and the public api is completely exported from main-package.
orivej has quit [Ping timeout: 260 seconds]
karlosz has quit [Quit: karlosz]
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
efm has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]