jochens has quit [Remote host closed the connection]
jochens has joined #lisp
<elderK>
fiddlerwoaroof: :| urxvt is having some problem opening your URI
kajo has quit [Ping timeout: 250 seconds]
<elderK>
Ah, it's xdg-open that has the problem
jochens has quit [Ping timeout: 246 seconds]
dorketch has joined #lisp
makomo has quit [Ping timeout: 244 seconds]
pierpal has quit [Read error: Connection reset by peer]
kdas_ has joined #lisp
kushal has quit [Remote host closed the connection]
cmjones has quit [Ping timeout: 268 seconds]
<fiddlerwoaroof>
elderK: if I had to guess, you're not properly escaping # when you call xdg-open
<elderK>
I'm just relying on xdg-open itself, passed through from urxvt.
elderK has quit [Quit: WeeChat 1.9]
elderK has joined #lisp
<jcowan>
I'm still trying to get a list of all quicklisp projects. (ql:system-apropos "") returns only 73; using quickdocs with an empty search field returns only 0. What's the righteous way to do this?
<fiddlerwoaroof>
I wonder if ql also tracks the packages available in a release...
dorketch has quit [Quit: WeeChat 2.1]
<pfdietz>
The lisp packages?
<jcowan>
okay, created a shell script that repeatedly calls sbcl --disable-debugger --eval '(unwind-protect (progn <import ql> <load project>) (quit)'
<jcowan>
s/import/load
<pfdietz>
Or just load ql in your .sbclrc file
<pfdietz>
(load "~/quicklisp/setup.lisp") ;; my .sbclrc
<jcowan>
I did that, but I was using --script before and that doesn't load .sbclrc
<pfdietz>
Ah
Kundry_Wag has joined #lisp
<pfdietz>
Goodness. ql-dist::dependency-tree can produce a very large tree for some systems. Need a dependency-dag.
amberglint has joined #lisp
_whitelogger has joined #lisp
<jcowan>
or perhaps dependency-dcg
<pfdietz>
There are just 344 systems in the current ql dist that are not in the required-systems list of another system.
<pfdietz>
"roots" of the dependency graph
<pfdietz>
I don't think the graph can be cycliic?
<pfdietz>
That number was wrong, sorry.
<pfdietz>
4086 are not depended on by other systems.
Mr-Potter has quit [Ping timeout: 250 seconds]
<pfdietz>
Still wrong
Kundry_Wag has quit [Ping timeout: 244 seconds]
<pfdietz>
2234
<aeth>
pfdietz: Are you excluding test systems?
<aeth>
pfdietz: It might be better to use projects as the basic unit and see if there are any projects where every contained system in that project is not depended on by any external project's systems.
<fiddlerwoaroof>
using satisfies, you can specify random arbitrary types
<elderK>
Aye, but I was like, hoping I could do it without writing a predicate :)
<elderK>
Like, some way to denote it in the type system itself.
<elderK>
Well, you know what I mena :D
<fiddlerwoaroof>
yeah, i think you basically need to use vectors for that
_whitelogger has joined #lisp
orivej has joined #lisp
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nirved has quit [Ping timeout: 252 seconds]
robotoad has quit [Quit: robotoad]
wanz has joined #lisp
robotoad has joined #lisp
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
<elderK>
fiddlerwoaroof: :) So, what's a good way to check that like, all my stuff... uh, works when it should? :D
<elderK>
To test that I have eval-whens in the right place and such :)
kdas_ is now known as kushal
<fiddlerwoaroof>
the compiler will usually tell you, i think
<elderK>
I guess I could always make a test file, and compile-file that.
<fiddlerwoaroof>
well, the best way would be to start a fresh lisp and load your system
lmy9900 has joined #lisp
<fiddlerwoaroof>
the rule is fairly simple, though: every function a macro calls had to either be in a different file or in an eval-when
<fiddlerwoaroof>
different file from where the macro is expanded
<elderK>
Aye.
<elderK>
fiddlerwoaroof: It's just, well, I need to test that all the metadata I've gathered is availalbe at the appropriate time.
<elderK>
Running some tests now :)
<elderK>
>:) With ASDF at my side! :P
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lmy9900 has joined #lisp
<elderK>
Hm, that doesn't make sense.
<elderK>
I can load my system just fine. But, I'm loading it from the REPL.
<elderK>
Like, you know, typing asdf:load-system.
amberglint has quit [Quit: Leaving]
<elderK>
fiddlerwoaroof: :P Everything loads okay even if the things the macro calls, are not (:compile-toplevel)
<elderK>
:P I even forced the macro expansion in a :compile-toplevel eval-when, it still woriks.
<elderK>
:P Does ASDF do some kinda magic or something?
<fiddlerwoaroof>
the repl is a bit tricky because the functions are often already loadef
<elderK>
fiddlerwoaroof: I'm not sure how to test this. I mean, asdf:load-system from REPL works just fine, even if I kill the REPL and start fresh
<fiddlerwoaroof>
if you compile each function as you write it, they will all be available to be called: to really test this, you either need to use a fresh lisp process or delete-package on the package containing your definitions before loading the sustem
<fiddlerwoaroof>
forming a mental model of file loading was the trickiest part of learning CL for me
<elderK>
fiddlerwoaroof: If I start a fresh SBCL, I can successfully load my system using asdf:load-system, :force t
<elderK>
fiddlerwoaroof: The thing is, it doens't make sense that this succeeds. I've purposely made some stuff not available at compile-time. The macro should fail, but it succeeds all the same.
<fiddlerwoaroof>
are they in different files?
<elderK>
Yes
<fiddlerwoaroof>
yeah, each file is a compilation init
<fiddlerwoaroof>
unit that is
<elderK>
Okay. So, if I am populating a hash table in one compilation unit, does that mean all of that data is visible to the next, at compile time?
<elderK>
That's what I don't understand.
<elderK>
I haven't like, got any eval-when to say "Hey, I want this stuff available at compile-time."
<elderK>
Instances of classes are being stored in the hash table, btw.
<fiddlerwoaroof>
well, compile-time side effects are generally a bad idea
<elderK>
I'm also calling generics
<elderK>
Well, yes. But I need to verify that the types people are using for slots in a "binary structure" are actually "binary types."
<elderK>
That requires me to consult the hash table.
<elderK>
Point is, should this fail? AFAIU, it should.
<elderK>
Since populating that hash table is a runtime thing, at least, atm. It'll generate code to do that, rather than do it at compile-time.
<fiddlerwoaroof>
but, im pretty sure that once a file has been compiled and loaded, you can rely on the side effects have being run
<fiddlerwoaroof>
it's helpful to see if it also works in ccl
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lmy9900 has joined #lisp
<elderK>
Strange how CCL doesn't gimmie a verbose trace of the load process.
<elderK>
Even with :verbose t
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<elderK>
fiddlerwoaroof: Loading the system works fine on CCL.
<elderK>
(Starting fresh CCL process, requiring ASDF, then load-systeming my system, ensuring it is built)
<elderK>
I also repeated that same thing without :force t to load-system
NB0X-Matt-CA is now known as nonlinear
_whitelogger has joined #lisp
lmy9900 has joined #lisp
nonlinear has quit [Ping timeout: 246 seconds]
<elderK>
:P I removed all the eval-whens from my code, until I know I need them. I'm sure something will go wrong eventually and I'll need them :P
<beach>
Good morning everyone!
<elderK>
Morning beach!
buffergn0me has quit [Remote host closed the connection]
buffergn0me has joined #lisp
mathrick has quit [Remote host closed the connection]
Blukunfando has joined #lisp
SaganMan has joined #lisp
rippa has joined #lisp
zagura has quit [Ping timeout: 240 seconds]
Wojciech_K has quit [Ping timeout: 272 seconds]
SaganMan has quit [Quit: WeeChat 1.6]
Bike has quit [Quit: Lost terminal]
<aeth>
elderK: Easiest way to remove eval-whens is to put them in a separate file that's loaded first
<aeth>
elderK: Afaik you probably don't need an eval-when unless it's called unquoted in a defmacro (directly or indirectly, I guess) while being in the same file as that defmacro
<aeth>
Sometimes CCL needs eval-whens when no other implementation needs them. I think that's for constants used in macros
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
ggole has joined #lisp
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xkapastel has quit [Quit: Connection closed for inactivity]
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
mathrick has joined #lisp
<Necktwi>
finally got rid of those ghost windows they are due to # to ## redirects of some of my autojoin channels
ryan_vw has quit [Quit: WeeChat 2.3]
wanz has quit [Remote host closed the connection]
dale has joined #lisp
gravicappa has joined #lisp
mathrick has quit [Remote host closed the connection]
arescorpio has joined #lisp
<elderK>
aeth: That's the thing: The macro is using functions defined in the same file, and is not encountering any issues on either SBCL or CCL.
<elderK>
After some reading, this may be because I'm using the macro in another file.
angavrilov has joined #lisp
<elderK>
Still seems weird. The macro makes several function calls, these functions generate the expansion. These helper functions call other functions, to get information that has been accumulated in a hash table. It seems bizarre that I am not encountering problems.
mathrick has joined #lisp
<Necktwi>
when i set hide level the window keeps scrolling upon hidden msgs
Necktwi has quit [Quit: leaving]
nonlinear has joined #lisp
arescorpio has quit [Remote host closed the connection]
Necktwi has joined #lisp
sword has quit [Read error: Connection reset by peer]
Elephant454 has quit [Quit: ERC (IRC client for Emacs 26.1)]
Guest76455 has joined #lisp
nanoz has joined #lisp
_whitelogger has joined #lisp
lmy9900 has quit [Client Quit]
<aeth>
elderK: Yes, if you're not using the macro in the same file...
<aeth>
possibly undefined and you'll possibly see it come up in another implementation
nirved has joined #lisp
makomo has joined #lisp
<beach>
elderK: One thing that can bite you is that you have already loaded your system before, so the functions are defined. Then, when you recompile, no warnings will be issued. To check that you have no such problem, it is good to compile from a fresh instance of your Common Lisp implementation.
<aeth>
That's basically the only time my build can fail, if I was referring to stale functions (i.e. an old version pre-rename), or if I have a circular dependency, etc., that the image won't expose unless it's fresh
<beach>
elderK: It is unfortunate that one has to restart the system to do that, of course. In SICL, I plan to use a fresh first-class global environment for this purpose without having to restart the system. Current Common Lisp implementation have a single global environment, so they can't do that.
<ggole>
Won't you still have stale functions sitting around in data structures?
<beach>
What kind of data structures?
<ggole>
Uh, any kind?
<beach>
Sure, if someone makes a list of functions and put the list in a special variable, it will be around.
<ggole>
Perhaps I'm misunderstanding and the new environment won't include anything which can reference old bindings in that way.
<beach>
All I am saying here is that I can start the compilation from a fresh first-class global environment. This new environment will not contain any old definitions, so it will be obvious if a macro is referring to a function that does not exist at compile time. The compilation will generate a FASL as usual and that FASL can be loaded into the working environment (as opposed to a fresh one).
<beach>
Exactly. The new environment can be a pristine one, like when the Common Lisp system starts up.
<beach>
Maybe I am not able to explain this concept very well. :(
<ggole>
I don't see much difference from starting a fresh Lisp?
<ggole>
Except for things like threads, I suppose, which may continue running stale code?
<MichaelRaskin>
Immutable standard things are not reloaded?
<aeth>
at the moment you have to M-x slime-restart-inferior-lisp before pushing to git if you want to be polite and catch various stale environment bugs
<beach>
ggole: Sure. I keep thinking in terms of a Lisp operating system. Starting a fresh Lisp is to me like booting up a second version of your operating system. If you have things like editor buffers and such defined, they will not be present in the fresh system.
<aeth>
ggole: If you had first class environments, then *building* in a fresh environment will catch anything that you'd catch with a fresh Lisp image starting up, without having to kill the old running things
<beach>
MichaelRaskin: What is an "immutable standard thing"?
<aeth>
ggole: So you could run your IRC client and develop in the same Lisp image, and not have to bring your IRC client down when you want to test a fresh build/load to see if you had stale function bugs
<MichaelRaskin>
The function and methods and types defined in the Standard.
<ggole>
Hmm.
<beach>
MichaelRaskin: And what time are you referring to for this reload?
<flip214>
aeth: but the IRC server might not like the duplicated nicks ;)
<aeth>
ggole: of course the way to do it right now is to just run one Lisp per application and you know use like 100-1GB more RAM than you need to
<aeth>
s/100-/100MB-/
<aeth>
I hope you're not using 100-1GB (99 GB) of RAM
<beach>
MichaelRaskin: Again, I am sorry for being dense. I am notorious for not understanding what other people refer to. I guess I am unable to fill in the blanks.
<MichaelRaskin>
I thought that creating a new global environment would probably put them into this environment in a more efficient way than starting a new image
<beach>
MichaelRaskin: Yes, of course.
<beach>
MichaelRaskin: The standard objects won't be duplicated.
<MichaelRaskin>
Rest assured that I _know_ you ask in good faith, and I understand the value of making sure about the intentions.
<beach>
Thanks.
<MichaelRaskin>
(and about the details)
<beach>
If I didn't have *some* evidence to the contrary, I would consider myself stupid. :)
pierpal has joined #lisp
<makomo>
morning
<beach>
Hello makomo.
<makomo>
\o
dale has quit [Quit: dale]
dacoda has joined #lisp
v0|d has quit [Read error: Connection reset by peer]
<no-defun-allowed>
has anyone ever used cl's runtime compilation to write a JIT compiling emulator?
dacoda has quit [Ping timeout: 260 seconds]
solyd has quit [Quit: solyd]
<aeth>
no-defun-allowed: I don't see anything that prevents it
<no-defun-allowed>
gonna write a chip8 one for the hell of it, but i think at the very least i can (ab)use (compile nil _) to generate thunks for each instruction
doubledup has joined #lisp
<no-defun-allowed>
also, how can i tell when to jit? should i do it when the machine jumps into new code or wait a bit?
<ggole>
You could do either - usually a fair amount of code is cold, so it makes sense to avoid compiling it
<no-defun-allowed>
alright
shifty has joined #lisp
nika has joined #lisp
<jackdaniel>
no-defun-allowed: sjl wrote chip8 emulator with a fantastic blog post series explaning how it is made
<no-defun-allowed>
guess i'll save some time and fork that, it's very nicely written
solyd has joined #lisp
dddddd has quit [Remote host closed the connection]
random-nick has joined #lisp
Mr-Potter has joined #lisp
cage_ has joined #lisp
ym has quit [Remote host closed the connection]
ebrasca has joined #lisp
ebrasca has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
lmy9900 has joined #lisp
ebrasca has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
rozenglass has quit [Remote host closed the connection]
nikka has joined #lisp
nika has quit [Ping timeout: 268 seconds]
DGASAU has joined #lisp
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #lisp
heisig has joined #lisp
robotoad has quit [Quit: robotoad]
lmy9900 has joined #lisp
frgo has joined #lisp
hiroaki has joined #lisp
lmy9900 has quit [Max SendQ exceeded]
lmy9900 has joined #lisp
frgo has quit [Remote host closed the connection]
Mr-Potter has quit [Ping timeout: 268 seconds]
FreeBirdLjj has joined #lisp
shka_ has joined #lisp
varjag has joined #lisp
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shka_>
good day
<ebrasca>
shka_: hi
lmy9900 has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
cesdo has joined #lisp
<rk[ghost]>
err, if i have a list like '("hello" "my" "name" "is" "rk") and i want to apply a function with such as an argument that returns "hellomynameisrk" .. is that a fold ?
<rk[ghost]>
i presume i want to fold against something like (concatenate 'string ...)
<shka_>
eh, you should not to that
<shka_>
it is very inefficient
<ggole>
That's quadratic
<pjb>
(if (< (1+ (length list)) call-arguments-limit) (apply (function concatenate) 'string list) (reduce (lambda (a b) (concatenate 'string a b)) list))
<shka_>
rk[ghost]: if you want to do something like this, i recommend using either string stream or simply using format
<shka_>
format would be just one line
<pjb>
since list is often small and call-arguments-limit nowadays is often large, apply concatenate will often work.
<shka_>
(format nil "~{~a~}" input)
<shka_>
but not reduce + concatenate
<shka_>
reduce combined with concatenate is as ggole said: quadratic
<rk[ghost]>
ah, hm.
<rk[ghost]>
it don't have a big list, but i see what you mean for this case
<shka_>
i also think that format is shorter and easier to read
<rk[ghost]>
it just seems like a textbook use for a higher order function since i waht to "str" + "in" + "g" + "zzz" across a list..
<shka_>
so although i am not a fan of format, i think that in this case it is a good tool to use
<rk[ghost]>
aye aye.
<shka_>
reduce is great for numeric stuff
<shka_>
or for anything that is O(1) as a step
<_death>
(defun string-append (&rest strings) (apply #'concatenate 'string strings)) now (apply #'string-append list) if list is short
<rk[ghost]>
and since i mapped across the list to make it, thought reducing it back to single string seemed sensible..
<pjb>
well, instead of reduce, if you have a long list, you can do (make-array (reduce (function +) list :key (function length)) :element-type 'character) and then fill it with the strings in list.
<pjb>
This will probably be the faster.
<pjb>
Because only concatenate could do that.
<shka_>
yes, that would also work
<rk[ghost]>
right-o.. i will think on such once i go thru a sleep cycle.. 6am.. no sleep :P
<shka_>
rk[ghost]: good... night? :P
<rk[ghost]>
i was getting really strange errors after compiling my list
<rk[ghost]>
then i did a (car list) and everything worked right.. then i realized, doh.. i need to just jam the list in to one big string :P
<rk[ghost]>
the list is a list of html strings.. and i was trying to (write-to-string) the whole list.. which borked all the links XD
<pjb>
If you are writing it, then use format already!
<shka_>
yup
<pjb>
Do not concatenate it, format it to the output stream directly.
<shka_>
format is excellent tool in situations like this
<shka_>
even if i don't like it :P
kooga has joined #lisp
<rk[ghost]>
lemme see if it "just works"(tm)
<pjb>
or (mapc (function write-string) list) to the *standard-output*.
<rk[ghost]>
before i rest.
<shka_>
rk[ghost]: off to bed!
ym has joined #lisp
<rk[ghost]>
thanks for all the help everyone:) really appreciate _both_ answering my question (teaching me how to properly use reduce) and giving me a more elegant solution with reasonings
scymtym has quit [Ping timeout: 268 seconds]
<shka_>
quicklisp local-project compiled systems are not cached in any way?
vaporatorius has joined #lisp
puchacz has joined #lisp
nika has joined #lisp
<puchacz>
hi, is it possible in Slime REPL to check what functions or generic functions defined in my-package are used anywhere in my-package please?
<puchacz>
as a matter of fact I am interested in functions that are NOT used :)
<shka_>
hmmm
<shka_>
there is who-calls in sbcl
nikka has quit [Ping timeout: 246 seconds]
<puchacz>
shka: what package?
<puchacz>
sorry, shka_
<shka_>
i am trying, to find, i always use slime interface
<puchacz>
yes, I know Slime can do it for a single function or generic function
<puchacz>
if Slime can do it, so can we :)
<shka_>
yes, but it works with sbcl
<puchacz>
that's fine
<shka_>
ok
<shka_>
so swank has something called list-callers
<beach>
Here is a new version of our bootstrapping paper http://metamodular.com/bootstrapping.pdf taking into account valuable remarks by splittist. Also we added more material in order to make the entire procedure a bit more clear. We still have two months to the deadline, so there might be more changes, of course. This has been a morning of hard works, so I am about to take a break. I'll check the logs in case someone has further
<beach>
remarks.
scymtym has joined #lisp
<shka_>
beach: hello
<White_Flame>
beach: just formatting-wise, there's a weird right margin intrusion on page 6
vaporatorius has quit [Quit: Leaving]
<shka_>
beach: back in the ELS 2017 you had this talk on portable efficient sequence functions
<beach>
White_Flame: Thanks.
<shka_>
and approach based on generating optimized code branches depending on the data type
<beach>
shka_: Yes, I remember. :)
<shka_>
do you happen to have some tips on reducing memory usage during compilation when doing this?
<beach>
Not really, no.
<shka_>
ok, cool
<beach>
shka_: You might want to talk to heisig about it. He has agreed to work in the implementation.
<shka_>
hm, ok
<shka_>
i wrote macro for generating those code branches, and well it works
doubledup has quit [Remote host closed the connection]
<beach>
Of course. :)
random-nick has quit [Read error: Connection reset by peer]
<shka_>
but memory usage when compiling is brütal
<beach>
I know, yes.
<shka_>
still worth it imho
<beach>
Anyway, I am exhausted. I do need a break. Back later.
<shka_>
but i need new memory die for my laptop xD
<shka_>
beach: have a good day
<heisig>
shka_: I am running benchmarks at the moment to figure out the best strategy for SICL sequence functions.
<shka_>
heisig: fascinating
FreeBirdLjj has quit [Remote host closed the connection]
<heisig>
You can reduce the memory consumption A LOT if you reduce the number of entries in *special-array-information*.
zagura has joined #lisp
FreeBirdLjj has joined #lisp
kajo has joined #lisp
<adlai>
beach: STYLE-WARNING: definition 4.1 ("simple instance") is not referred to by the rest of the document.
<pjb>
ie. :file "asdf" seems to depend via a prepare-op on the system iolib/asdf itself…
<pjb>
(accoding to the asdf:load-system-definition-error)
<|3b|>
what asdf version?
robdog has quit [Remote host closed the connection]
<pjb>
"3.3.2.11"
<|3b|>
looks like either something wrong with your quicklisp, or something wrong with ql infrastructure fetching github releases, since you seem to have iolib 0.8.1, and 0.8.2 claims to fix problems with asdf 3.3 (and newest is 0.8.3, over a year old)
<|3b|>
or something odd with your asdf confifguration, does ~/quicklisp/dists/quicklisp/software/iolib-v0.8.3/ (or .2) exist?
<fe[nl]ix>
that's correct, 0.8.1 is quite old
<pjb>
Perhaps. I'll try to clean up and retry.
<|3b|>
looks like fetching things by github release seems to be working, so probably not ql server-side, i'd guess overly broad asdf search path
<|3b|>
(at least i have more recent releases of other things using that method)
<|3b|>
yeah, sounds like asdf is confused (unless you configured ql to pin versions)
<pjb>
Ok, I see what must be wrong. I configured asdf with my own walk of ~/quicklisp/.
<pjb>
Unfortunately, for ecl, it looks like I have to do that, since quicklisp prevents it to save executables…
<pjb>
I have to deal with it. (reverse (sort ..)) should do.
<|3b|>
doesn't ql have some way of dumping a list of systems for building executables without ql?
<jackdaniel>
yes, bundle-systems
<jackdaniel>
very useful utility
<jackdaniel>
when I build binaries I usually do exactly that
<jackdaniel>
(my life would be certainly happier, if ASDF had similar funcionality: dump compilation instructions to file so it may be loaded without ASDF in the image to build a binary)
<jackdaniel>
I would be certainly happier
<jackdaniel>
I'm not sure if life may be happy
cesdo has quit [Quit: Leaving.]
<beach>
adlai: Indeed, thanks!
Bike has joined #lisp
xkapastel has joined #lisp
shrdlu68 has joined #lisp
ted_wroclaw has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shrdlu68>
How do CL implementations deal with the W^X memory constraint?
Blukunfando has quit [Read error: Connection reset by peer]
<beach>
Wow, that's vicious. Together with ASLR, pretty soon they are going to prevent us from writing decent Common Lisp implementations.
<beach>
Only C++ will be allowed.
orivej has quit [Ping timeout: 272 seconds]
<pfdietz>
OpenBSD support in SBCL is already decayed; this will just mean the platform gets written off entirely.
<beach>
Wouldn't Java be impacted as well, with JIT and stuff?
<pfdietz>
I would think so.
<shka_>
what about julia? or any other dynamic language built on top of llvm for that matter?
<beach>
Note to self: In the CLOSOS specification, add W^X as an example (together with ASLR) of a kludge on top of a hack in order to make a broken model (i.e. UNIX) a bit safer, but also much harder to use.
<ggole>
W^X is OK, it doesn't prevent run-time compilation at all.
<beach>
Oh?
<ggole>
Just write to the memory all at once and then mark it executable.
<|3b|>
from what i've seen, most of them deal with it by saying "turn it off"
<beach>
ggole: Hmm, OK.
<beach>
|3b|: But the link suggests that it will be mandatory in OpenBSD.
<|3b|>
just need a separate heap for "executable" stuff, and a bit more work to GC it
<jackdaniel>
it won't affect interpreters though (because bytecode is treated like data)
<pfdietz>
What's the overhead for changing a page? Also, if you are compiling in small chunks, will you waste a lot of space in pages that need to be executable before they are filled?
<beach>
jackdaniel: Right.
<|3b|>
beach: yeah, possibly the status quo will change if openbsd users care enough to patch implementations when it is
dddddd has joined #lisp
<ggole>
It's iOS that is problematic here, as it doesn't allow user programs to change map permissions.
<White_Flame>
javascript is another major language with JIT performance requirements
<ggole>
If you compile in small chunks you could either use a new page or do make writable -> write the code -> make executable
<ggole>
There is some overhead.
<jackdaniel>
ECL won't be affected by this either, because it either works with bytecodes or with modules load from disk (with dlopen), so there is no code segment write whatsoever
<jackdaniel>
(or, of course, modules linked at binary compilation time)
<pfdietz>
For people writing CL, I suggest they do not depend on things defined in foo.lisp in order to compile things later in foo.lisp. Stick your macros and class definitions in another file.
<ggole>
There's another cute trick that might be useful: double map the pages, with one mapping writable and the other executable
<ggole>
I'm not sure what the interaction with caches is though.
<beach>
It sounds to me like W^X is so easy to circumvent that it won't fix the problem it is intended to solve, but it will make life harder for compiler writers.
nopolitica has joined #lisp
<ggole>
Well, normal programs don't do that sort of thing by accident.
<ggole>
Unlike freeing memory early, which they do all the time.
<ggole>
So there is some advantage - it is a mitigation rather than a solution.
<ggole>
The reasoning, I suppose, is that the solution - ditching C - would not be acceptable. Thus they do what they can.
<beach>
Yeah.
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
lmy9900 has quit [Max SendQ exceeded]
lmy9900 has joined #lisp
FreeBirdLjj has quit [Ping timeout: 245 seconds]
v0|d has joined #lisp
<pjb>
(incf beach) ; won't fix :-)
<pjb>
dlowe: could you /topic We've moved over to #clschool in #clnoobs ?
hiroaki has joined #lisp
<jcowan>
beach: gcc generates trampolines in certain conditions, so I don't think you have to worry about being completely locked down. Furthermore, a strict interpretation of W^X would make JIT impossible, and Java depends on it.
nirved is now known as Guest12326
<beach>
Still, it's depressing.
longshi has joined #lisp
nirved has joined #lisp
nopolitica has quit [Quit: WeeChat 2.2]
Guest12326 has quit [Ping timeout: 252 seconds]
Kundry_Wag has joined #lisp
shifty has quit [Ping timeout: 252 seconds]
longshi has quit [Quit: WeeChat 2.3]
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
razzy has quit [Remote host closed the connection]
<MichaelRaskin>
Double-mapping will probably not work; re-protecting memory as as RW -> RO -> RX seems to be the official recommendation and very unlikely not to be supportred. The problem they mitigate is overwriting already-executable page by buffer overflow.
orivej has joined #lisp
<jackdaniel>
so you may temporarily mark page RW, write, and bring it back to RX
<MichaelRaskin>
(will not work — at some point in future they will succeed in breaking it)
<jackdaniel>
but in this scenario it is an explicit action taken by the environment (not accidental thing)
<MichaelRaskin>
Note that strict W^X without run-time protection level chage will break userspace dynamic loader
<MichaelRaskin>
Forget Java, that would break glibc.
<jackdaniel>
so this is much brighter than we have painted it
FreeBirdLjj has quit [Ping timeout: 268 seconds]
trebor_home has joined #lisp
orivej has quit [Ping timeout: 244 seconds]
makomo has quit [Ping timeout: 250 seconds]
<White_Flame>
jackdaniel: "temporarily mark page RW" might be impossible in the future. allocate->RW->RO->RX->deallocate might be a one-way path
<beach>
Ouch!
<Bike>
seems like that would interfere patching jit.
<White_Flame>
well, any time you want to update a JIT compilation, you'd have to allocate a new page with its own permissions
<White_Flame>
in theory, that would be a fairly clean model
<Bike>
right
<White_Flame>
just potentially wasteful depending on how functions pack into those pages
<White_Flame>
oh, interfere patching, correct. It'd have to effectively be manual copy-on-write
* White_Flame
writes self-modifying code
* White_Flame
's computer bursts into flames
FreeBirdLjj has joined #lisp
<Bike>
sometimes thats how it be
<ggole>
I think only iOS is that restrictive
<ggole>
Or maybe some super locked down selinux systems
makomo has joined #lisp
<ggole>
I think there is some restriction on memory allocated with sbrk, too
<ggole>
That is, you have to use mmap to play these mapping games
McParen has joined #lisp
Kundry_Wag has joined #lisp
kyby64 has joined #lisp
Mr-Potter has joined #lisp
nika has joined #lisp
glv has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
Kundry_Wag has joined #lisp
solyd has quit [Ping timeout: 272 seconds]
elderK has quit [Ping timeout: 246 seconds]
nikka has joined #lisp
nika has quit [Ping timeout: 246 seconds]
rpg has joined #lisp
nanoz has quit [Ping timeout: 240 seconds]
kuwze has joined #lisp
Guest47970 has quit [Ping timeout: 252 seconds]
lonjil2 has quit [Ping timeout: 252 seconds]
glv has quit [Quit: Leaving]
hiroaki has quit [Ping timeout: 245 seconds]
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jibanes has quit [Ping timeout: 252 seconds]
lonjil has joined #lisp
rpg has joined #lisp
frgo has joined #lisp
frgo has quit [Read error: Connection reset by peer]
frgo has joined #lisp
rumbler31 has joined #lisp
graphene has joined #lisp
jfrancis has quit [Quit: Leaving]
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
Necktwi has quit [Client Quit]
Necktwi has joined #lisp
Necktwi has quit [Client Quit]
nika has joined #lisp
graphene has quit [Remote host closed the connection]
Necktwi has joined #lisp
Necktwi has quit [Client Quit]
graphene has joined #lisp
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nikka has quit [Ping timeout: 272 seconds]
Guest47970 has joined #lisp
<sjl>
no-defun-allowed: jackdaniel: cl-6502's 25-line JIT is also worth reading as inspiration
<shka_>
it is modular, neatly designed, i never figured out how to write my own modules (but i didn't have to)
<shka_>
cool thing is that you can use any part of it you want and ignore everything else
<p_l>
I recently did stuff in rails 5, and some of the stuff is still some of the better tooling I have ever used :O
<shka_>
well ok
<shka_>
i never did anything in RoR, but i tried radience and caveman2
<p_l>
But I do prefer lisp, so I'm thinking of looking what's the current landscape and either using something existing or using some lower layer stuff
<shka_>
i think that radience is better of those two
<p_l>
Caveman felt a lot like Sinatra did
<shka_>
well, if you find radience acceptable, i urge you to develop more modules for it
<shka_>
because i think that the whole design is very sound
megalography has joined #lisp
<p_l>
Which is very minimal, good-for-microservice kind of thing (Sinatra and thus Caveman, that is)
<shka_>
this very well may be the case
<shka_>
radiance is not minimal
doubledup has joined #lisp
<shka_>
but it is modular and stuff that it is built on is reusable
<shka_>
cl-ds is getting waaaaaaaaaaaaaaaaaaaay to big
<shka_>
and has crap in it that probably shouldn't be in it
<shka_>
anyway, i like what shimmera is doing in general
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
dacoda has joined #lisp
emar has quit [Ping timeout: 252 seconds]
ggole has quit [Read error: Connection reset by peer]
solyd has quit [Quit: solyd]
solyd has joined #lisp
McParen has left #lisp [#lisp]
solyd has quit [Quit: solyd]
Yaargh has joined #lisp
frgo has quit []
solyd has joined #lisp
Lycurgus has joined #lisp
frgo has joined #lisp
fikka has joined #lisp
jfb4 has quit [Ping timeout: 246 seconds]
kuwze has quit [Quit: Page closed]
fikka has quit [Ping timeout: 250 seconds]
slyrus1 has joined #lisp
slyrus has quit [Ping timeout: 240 seconds]
slyrus1 is now known as slyrus
anewuser has joined #lisp
eminhi has joined #lisp
jello_pudding has joined #lisp
gxt has joined #lisp
cage_ has quit [Quit: Leaving]
nirved is now known as Guest87399
Guest87399 has quit [Killed (niven.freenode.net (Nickname regained by services))]
nirved has joined #lisp
Yaargh has quit [Quit: Going offline, see ya! (www.adiirc.com)]
jello_pudding has quit [Quit: Leaving]
jellopudding has joined #lisp
jellopudding has quit [Remote host closed the connection]
jello_pudding has joined #lisp
puchacz has quit [Quit: Konversation terminated!]
zmt00 has quit [Ping timeout: 250 seconds]
Inline has quit [Read error: Connection reset by peer]
Inline has joined #lisp
scymtym has joined #lisp
<makomo>
hm, say there's a function F within file A and a macro M which uses F within file B. further, usages of the macro M appear within file C. assuming no EVAL-WHENs, in order to compile file C it has to hold that (1) we compiled file B and (2) we compiled and loaded file A. is this correct?
<makomo>
by "M uses F" i mean that M uses F to produce its expansion
fikka has joined #lisp
<makomo>
if the above is correct, does that mean we lose the possibility of compiling A, B and C in isolation (since now we need to actually *load* A to be able to compile C)?
<shka_>
you must ensure that macro exists if you want to expand it
<shka_>
and if function used for expansion was not found, macroexpand will fail
<shka_>
therefore, yes
<makomo>
is that dependency a bad thing? should one then wrap every DEFUN that's used at compile-time into an EVAL-WHEN? what about external system though? i guess we depend on them being loaded anyway so it's fine?
<makomo>
... external systems (which we don't control and can't change and wrap their DEFUNs)* ...
<shka_>
external systems seems to be fine
<shka_>
i never ran into issue in this case
<jackdaniel>
it is enough to load files a and b to compile c
<makomo>
i'm mostly wondering whether the fact that we have such "load-before-compilation" dependencies is bad or not
<jackdaniel>
i.e they do not have to be part of the resulting image
<shka_>
and this dependency is inevitability so you can only accept it :-)
<makomo>
jackdaniel: do we have to load B though? won't the macro be defined when B is compiled?
<jackdaniel>
why would it?
<shka_>
makomo: what jackdaniel's is saying i think is that you will need your function definition ONLY when you need it (during macroexpand)
<shka_>
also applies to the macro itself
orivej has quit [Ping timeout: 250 seconds]
<makomo>
jackdaniel: well i peeked at the expansion of SBCL's DEFMACRO and it is defined at compile-time
<makomo>
also, "If a defmacro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly."
gxt has quit [Ping timeout: 264 seconds]
<makomo>
(M above refers to top-level macros)
<makomo>
so by the above, it would be enough to just compile B, without loading it
gxt has joined #lisp
SaganMan has quit [Quit: WeeChat 1.6]
elderK has joined #lisp
<elderK>
Hey guys, quick question: When does it make sense to use a symbol's plist vs. an external hash table?
<shka_>
elderK: rarely or never
<jackdaniel>
you are right, it is enough to compile B to have macro visible
<elderK>
In my situation, I have a hash table that stores information about types and things. The symbol denoting hte type's name is the key of the hash table.
<jackdaniel>
s/visible/being available/
<elderK>
I was wondering if attaching type information, a structure instance, as a property on the types I define instead, would be better.
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<makomo>
jackdaniel: alright, so only A's left. so is this "loaded-before-compilation" dependency a bad thing?
<jackdaniel>
but it is enough to load file a before file b, you don't need to compile a
<shka_>
elderK: type names are not symbols
<jackdaniel>
systems are often defined that way, (either with :depends-on or with :serial t)
<makomo>
hm right. i'm looking at it through SBCL's eyes which compiles everything
<elderK>
shka_: So, the (deftype x () `(member foo)), x in this case is not a symbol?
<shka_>
secondly, it they would be just symbols, defgeneric and defmethod with eql specializer would be probably a better option
<elderK>
Even if I export that from a package?
<shka_>
elderK: (integer 0 42) is a type
<shka_>
(simple-array string (100)) is a type
<elderK>
shka_: Yes, but so is integer or unsigned-byte
<shka_>
yup
<jackdaniel>
so I don't think such dependencies are bad whatsoever
<shka_>
so it is either list or symbol
<shka_>
plists are just for symbols
<elderK>
Yes, so I'm talking about the type's name here. Is the type's name not a symbol?
<makomo>
jackdaniel: so assuming :serial t, not only does ASDF load them in that order, but it also compiles them in such a way that before compiling the file N, files 1, ..., N-1 have been loaded?
<shka_>
elderK: (integer 0 42) is a type...
<elderK>
shka_: I think I may not have explained my situation clearly here.
<shka_>
well, maybe
<makomo>
jackdaniel: i.e. it does compile A, load A, compile B, load B, ...?
<elderK>
shka_: I'll have to come back later and describe it in more detail. As it is, I have a hash table mapping symbols to type metadata.
<shka_>
elderK: anyway, if you really just need symbols, i recommend using generic functions
<elderK>
I've gotta run - but I'll be back to ask again some time :)
<jackdaniel>
makomo: that depends on what you tell asdf to do, it may only load them, or only compile them. my impression is that asdf sometimes does a random thing, but I didn't find any passage with (funcall (nth *funs*) (random 8)), so maybe I do not understand whole thing ,)
<elderK>
shka_: It's not the symbols I care about, it's the associated type information I store relating to them.
<shka_>
yup
<shka_>
exactly
<elderK>
shka_: You know the binary-types system?
<jackdaniel>
but more seriously: asdf constructs a plan which is more complicated than simple load/compile
<elderK>
I'm makign something similar to that.
<jackdaniel>
because some results are cached
<jackdaniel>
so you may only load fasl file
<shka_>
so (defmethod obtain-metadata ((type (eql 'my-swee-type))) ... is what i would do
varjag has quit [Read error: Connection reset by peer]
<elderK>
shka_: That isn't sufficient here :P The type metadata contains information I need :P
<jackdaniel>
but in principle it works like: if A depends on B, load B (or its compilation result) before A
<shka_>
elderK: well, you can return anything you want from here
<shka_>
and you can accept optional arguments for byte bit count and so one
<makomo>
jackdaniel: lol :D. right, it depends on what i want to do. whether ASDF will compile and then load the fasls if i tell it to LOAD-SYSTEM is a separate thing, so let's assume i'm doing COMPILE-SYSTEM
<jackdaniel>
makomo: given you are groking style issues, did you make some time to read about splicing?
<elderK>
shka_: I'm afraid I have to run. Please take a look at the linked binary-types thing to get a feel for well, what I'm talking about :D
<elderK>
Will be thinking about getting rid of the "metatypes" and just using eql.
<jackdaniel>
I don't know ASDF enough to describe without looking at source code what it does exactly when you compile-system
<makomo>
jackdaniel: not yet. sorry if it seems like i'm intentionally avoiding it since i'm asking all these questions, but i'm procrastinating and should be studying. however, asking these questions is different as i know that if i start analyzing that document, i'll waste too much time. :-)
<jackdaniel>
but I would suspect, that if there is dependency between two files, dependee is loaded before depending file is compiled
<elderK>
Have a great day (night) everyone!
<elderK>
shka_: Also, thank you for your input this far :)
elderK has quit [Quit: WeeChat 1.9]
<makomo>
jackdaniel: my first exam is tomorrow and the whole week is packed with them. i'll get to it on the next monday the latest!
fikka has quit [Ping timeout: 268 seconds]
<jackdaniel>
I think you overestimate time needed to read it, but I understand that exams are imminent
<makomo>
jackdaniel: right, that's what i'm wondering and what my assumption is as well
<makomo>
jackdaniel: oh, i did read it (quickly though), but actually writing an anylsis will take more time (i.e. (re)searching the standard and the like)
<makomo>
analysis*
<jackdaniel>
some bugs of ASDF are invisible when using SBCL because it is based on an image
<makomo>
and i know how it'll end if i start doing it before the exams :-)
<jackdaniel>
if you create binary on ecl on the other hand some dependencies which were available during compilation are not part of the resulting binary, and sometimes such binaries fail (that happens for instance if dependency on uiop is not expressed in asd file)
rpg has joined #lisp
<makomo>
jackdaniel: so basically there's a separate compilation and run-time environment. wouldn't the same happen if you restarted SBCL and tried to load a FASL which uses uiop (before actually loading uiop)?
angavrilov has quit [Remote host closed the connection]
phenoble has quit [Ping timeout: 245 seconds]
<jackdaniel>
it could, but program-op doesn't create fasl but a binary
knicklux has quit [Read error: Connection reset by peer]
<pjb>
minion: memo for elderK: notice that p-lists are faster than hash-table when they have fewer than 5-35 elements, depending on the implementation. Also, hash-tables have a size overhead that is way bigger than p-list. So if you need to put just one or two entries on thousands or millions of symbols, better use the symbol-plist. On the other ahnd, if you need to put thousands of entries on a few symbols, then better hash-tables.
<minion>
Remembered. I'll tell elderK when he/she/it next speaks.
shka_ has quit [Ping timeout: 268 seconds]
doubledup has quit [Quit: Leaving]
<pjb>
minion: memo for elderK: In both cases, if you attach attributes to symbols at compilation time, you must ensure that data is passed over to run-time if you need it at run-time. basically: (defmacro x (s) (setf (getf (symbol-plist s) 'your-attribute) 'your-value) `(progn (setf (getf (symbol-plist ',s) 'your-attribute) 'your-value) … ))
<minion>
Remembered. I'll tell elderK when he/she/it next speaks.
solyd has quit [Quit: solyd]
phenoble has joined #lisp
Mr-Potter has quit [Ping timeout: 246 seconds]
<aeth>
pjb: Using plists for an unspecified small number of elements just because they're slightly faster is a micro-optimization that this channel normally criticizes.
<aeth>
I did this: (defparameter *foo* (list :foo 42 :bar 43 :baz 44)) (defparameter *bar* (zr:hash-table* :foo 42 :bar 43 :baz 44)) (time (dotimes (i 1000000) (getf *foo* :baz))) (time (dotimes (i 1000000) (gethash :baz *bar*)))
<aeth>
And even this doesn't iterate enough to really get a noticable difference.
<aeth>
I keep adding zeros and sometimes the hash table is slower (up to 4x in one case) but they're usually about the same.
<aeth>
(SBCL)
<aeth>
At 10000000000 it looks like hash tables are slower 7.056 to 8.804 seconds
<aeth>
So 25% speed improvement in niche cases for something that either way takes about as much time as +
Guest47970 has quit [Ping timeout: 252 seconds]
<pjb>
aeth: Also notice above the words "depending on the implementation".
<pjb>
try: (room t)
<pjb>
sometimes the implementation gives the size of the hash-tables separately.
lnostdal has joined #lisp
<aeth>
SBCL doesn't appear to, but either way, I allocated one tiny object for each and was just accessing it.
<aeth>
The memory argument is a bit mixed. Conses will probably take up the least memory of a data structure for things like this, but they might not be together in memory, which is probably more important in today's software than being tiny overall.
<fiddlerwoaroof>
(this is for a scheme, but one could translate the code for CL)
<fiddlerwoaroof>
... or perform a similar experiment
<aeth>
fiddlerwoaroof: alist will add a bit more overhead, I think. At least, if you don't test that your plist is a proper one.
<fiddlerwoaroof>
Memory overhead
<Xof>
there's a neat thread between Erik Naggum and someone else about alist vs plist
<fiddlerwoaroof>
I think it's still the same number of pointer operations.
<pjb>
aeth: notice that it also depends a lot on the type of keys, and the hash function used by the hash-table.
<aeth>
Either way, we're talking about an operation that is about as fast as +
<aeth>
pjb: Yes, and SBCL's hash table is apparently not a particularly fast one
<pjb>
Otherwise, a-list and p-list are strictly equivalent on the time and space.
<fiddlerwoaroof>
An alist has an extra cons per element, right?
<pjb>
even considering cache, there's no significant difference.
<pjb>
fiddlerwoaroof: count again.
kajo has joined #lisp
<aeth>
plist is [key|-][value|-][key|-][value|...] and alist is [pointer-to-key-and-value-cons|-][pointer-to-key-and-value-cons|-][pointer-to-key-and-value-cons|...]
<aeth>
(Can't really properly do the alist without 3 lines)
<aeth>
(And imagine - is an arrow)
<fiddlerwoaroof>
Yeah, I guess they have the same number of conses
<aeth>
The issue is if they're allocated in a good way for iterating through them.
dale has joined #lisp
<aeth>
Also, plists will iterate by cddr and then check car and alists will iterate by cdr and then check caar, so that's another difference.
<aeth>
So I guess the compiler plays a role, too
varjag has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
<aeth>
(It looks like Xof's link talks about the latter)
solyd has joined #lisp
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eminhi has quit [Quit: leaving]
<pjb>
aeth: you don't usually index into plists or alists (no elt or nth).
rk[ghost] has quit [Ping timeout: 272 seconds]
random-nick has quit [Ping timeout: 272 seconds]
moei has quit [Quit: Leaving...]
<aeth>
pjb: Yes. I'm guessing the typical operations are (1) iterate over the entire alist/plist or (2) iterating over the alist/plist until you find a key that matches
jcowan has quit [Quit: Connection closed for inactivity]
<aeth>
pjb: so cddr iteration with car [and cadr], or cdr iteration with caar [and cdar] where the parts in brackets are only needed if either you're in case #1 or you matched in case #2
<aeth>
(Of course you'd use named accessors and I'd probably use destructuring-bind, rather than actually call those cxr functions)
Mr-Potter has joined #lisp
<fiddlerwoaroof>
I've also thought that you could dynamically optimize an alist or plist by always prepending the last entry you looked up
<fiddlerwoaroof>
That way, the high-probability entries will all be sorted towards the front
<pjb>
Indeed.
<aeth>
fiddlerwoaroof: that probably makes it slower than a hash-table, though
<aeth>
at least in SBCL
rumbler31 has joined #lisp
<aeth>
Remember, the hash table is only 25% slower and now you're slowing down the lookup of the alist/plist.
rumbler31 has quit [Remote host closed the connection]
Guest47970 has joined #lisp
shifty has joined #lisp
msb has joined #lisp
<aeth>
Here's a fun little program to see the day's time from a different perspective. (defun countdown () (multiple-value-bind (second minute hour) (get-decoded-time) (format t "~2,'0D:~2,'0D:~2,'0D" (- 23 hour) (- 59 minute) (- 59 second))))
<fiddlerwoaroof>
aeth: it would depend on the access patterns
Kundry_Wag has joined #lisp
<fiddlerwoaroof>
Think about it this way: there's a certain number N of elements where the O(n) lookup of an alist becomes slower than the O(1) lookup of a hash-table. If you have a dataset where < N elements constitute the majority of accesses, then an alist that begins with those elements will generally be faster than a hash-table.
<White_Flame>
I think the only speedup would be if you read the head multiple times in succession. Even if you're reading just the 2nd entry of the list, you still have to shuffle or cons to shift a new head
<White_Flame>
and that overhead would not be insignificant
<fiddlerwoaroof>
Well, my guess is the best way to do it would be to have a "training" period where you move accessed elements to the head and then freeze the list
Kundry_Wag has quit [Ping timeout: 272 seconds]
Guest47970 has quit [Ping timeout: 252 seconds]
<fiddlerwoaroof>
You'd probably also avoid reshuffling the list if the access is to one of the first N elements
solyd has quit [Remote host closed the connection]
<pjb>
also, about last: (cons (first *n*) (last *n*))
<pjb>
Ok, in this lisp image, there are 169 symbol-value that are hash-tables. Of those, 133 have only 1 entry.
<dim>
mmm, how do I pick a font in McCLIM where I can display ♣ and other characters?
<pjb>
Of course, there's one with 31000+ entries. Definitely a hash-table for that.
<pjb>
But for the 85% of them that have less than 6 entries, plists would be better.
<aeth>
pjb: when you're talking about comparing two operations that are approximately as fast as +, it's still a micro-optimization
<aeth>
To gain two seconds on my machine I needed to do it 10000000000 times.
Kaisyu has joined #lisp
<aeth>
"~r~%" says that's ten billion.
<aeth>
At that scale there's probably some fancy data structure that's optimal.
varjag has quit [Ping timeout: 250 seconds]
benjamin-l has joined #lisp
rpg has joined #lisp
<pjb>
aeth: try it with strings as keys for example.
<pjb>
Here are the types of the first key in those 196 hashtables: (character (simple-base-string 45) standard-generic-function ccl:compiled-lexical-closure function (simple-base-string 2) (simple-base-string 5) standard-class (simple-base-string 11) (simple-base-string 6) hash-table pathname ccl:process cons (simple-base-string 17) (simple-base-string 22) bit readtable (simple-base-string 21) (simple-base-string 13) (simple-base-string
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
<scymtym>
dim: best to ask in #clim. what i found is that i have to (setf mcclim-truetype::*truetype-font-path* #P"/usr/share/fonts/truetype/**/") after loading mcclim, but before doing anything with it. then i can use truetype fonts via (clim:make-text-style "EB Garamond Initials" "Regular" 24) where the "Regular" face must exist in the font
<scymtym>
when the *TRUETYPE-FONT-PATH* is properly set, the "Font Selector" demo should show all fonts and their respective faces
<scymtym>
but again, best to ask in #clim since jackdaniel and loke know a lot more