smurfrobot has quit [Remote host closed the connection]
nowhere_man has joined #lisp
<xificurC>
(if 'some-test (progn (require :foo) (foo:bar))) is this valid?
dddddd has joined #lisp
<xificurC>
sbcl seems to disagree with me. Probably it needs to compile and execute the require before understanding foo:bar?
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
<beach>
xificurC: Why would you want to do something like that?
<beach>
xificurC: The FOO package needs to exist when the reader reaches FOO:BAR, or else an error will be signaled.
<beach>
xificurC: Why not make sure the FOO module is always loaded beforehand?
<beach>
[I am assuming the package FOO is defined by the module FOO]
<xificurC>
beach: building a script that will be called from the command line. When you write ./command foo xyz I need to load package foo. When you write ./command bar xyz I might need to load bar or some other packages
<xificurC>
of course this is not set in stone and I can slice things as I wish but I would like to have a toplevel script that dispatches appropriately
epony has joined #lisp
<xificurC>
think of git and its commands being separate CL packages
wigust has joined #lisp
<xificurC>
I could call a defined function and the requiring of a package would register it somewhere for the function to find it but that means foo needs to know about something above it
<beach>
Sorry, I don't use Common Lisp that way, so I haven't thought about the kludges that might be require to make it work.
uint_ has joined #lisp
epsyloN has joined #lisp
mrSpec has joined #lisp
asedeno has joined #lisp
ioa has joined #lisp
rme has joined #lisp
Guest23105 has joined #lisp
PyroLagus has joined #lisp
froggey has joined #lisp
terrorjack has joined #lisp
Tordek has joined #lisp
cibs has joined #lisp
dcluna has joined #lisp
mbrock_ has joined #lisp
cmatei has joined #lisp
isoraqathedh has joined #lisp
abeaumont has joined #lisp
voidlily has joined #lisp
ccl-logbot has joined #lisp
exit70 has joined #lisp
tobel has joined #lisp
lin_ has joined #lisp
msb has joined #lisp
larme has joined #lisp
l1x has joined #lisp
johs has joined #lisp
gendl has joined #lisp
adulteratedjedi has joined #lisp
lieven has joined #lisp
esthlos has joined #lisp
terrorjack has quit [Max SendQ exceeded]
exit70 has quit [Max SendQ exceeded]
Guest23105 has quit [Max SendQ exceeded]
atchoum has quit [Ping timeout: 260 seconds]
<beach>
But if you want to write FOO:BAR in your code, the package FOO needs to exist when that code is read.
<xificurC>
beach: do you mean you don't use it like I'm describing or you don't write scripts that would be run from the command line?
<beach>
If you don't want to do it that way, you may have to do something like FIND-PACKAGE, then INTERN, then SYMBOL-FUNCTION.
<shka>
beach: both package and symbol
<xificurC>
beach: I could (funcall (symbol-value foo:bar)) :)
<xificurC>
symbol-function
<beach>
xificurC: That code can not be read by the reader if the FOO package does not exist.
<shka>
or just function
giraffe has joined #lisp
_cosmonaut_ has joined #lisp
<scymtym>
xificurC: you could make that work using (uiop:symbol-call '#:PACKAGE '#:SYMBOL) but if you want something like git, it seems better to dump everything into a single executable file ahead of time
giraffe is now known as Guest18867
<beach>
xificurC: I don't write scripts in Common Lisp.
<beach>
xificurC: If you write FOO:BAR in your code and try to compile it, then the READ function will first read it. When READ sees FOO:BAR, it looks for a package named FOO. If that package does not exist, an error will be signaled.
<beach>
xificurC: So you can't even COMPILE your code unless the FOO package has been created.
<beach>
xificurC: So, the code that reads (funcall (symbol-value 'foo:bar)) [note the quote] can not even be read by the compiler unless the package FOO exists.
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<xificurC>
interesting
<beach>
xificurC: What scymtym is suggesting is basically a shorthand for what I suggested, i.e, find the package with that name, find the symbol with that name in that package, find the function with that name, call it.
pierpal has quit [Read error: Connection reset by peer]
<xificurC>
I'll just require it in the toplevel for now. This is a habit taken from the previous version of this tool (written in python)
beizhia has quit [Quit: ERC (IRC client for Emacs 26.1)]
<shka>
hmmm
<White_Flame>
Even consider this, at the toplevel: (when <test> (require :foo)) (when <test> (foo:bar))
<shka>
this does not sound like a good idea to be honest
<White_Flame>
the 2nd expression would fail to read if the <test> wasn't true
<White_Flame>
your source code breaks if the packages aren't available, basically
<xificurC>
White_Flame: well sure, but that's like saying (progn (let ((x 1)) (+ x 1)) (+x 10)) breaks
<xificurC>
of course there's scope involved
<White_Flame>
no, it has nothing to do with lexical scope
<xificurC>
White_Flame: i'm not saying it does
<White_Flame>
it has to do when the side effects of creating a package take place, vs READing source code
<beach>
xificurC: That's a very different mechanism.
<makomo>
morning
<xificurC>
eh, I'm not saying it's the same thing, just that you have to think of the consequences and structure your code
<White_Flame>
I don't know if you can get away with #+ style omission of an entire source code term if that term contains unreadable symbols
<White_Flame>
probably, now that I think about it, for platform specifics
<shka>
makomo: hello
<White_Flame>
so your (if <test> ...) would be #+test instead
<xificurC>
as I said this is a common concept in python, loading a package only when needed
<xificurC>
but I don't want to write python :)
<White_Flame>
python doesn't read source code the way lisp does
<makomo>
xificurC: lazily loading packages?
<beach>
Loading is such a 20th-century concept.
<shka>
beach: and what should we do now?
<beach>
Assume everything is always is (virtual) memory.
<beach>
But then, our current operating systems are so 20th century.
<White_Flame>
but CL still requires ahead of time dependency declaration
<White_Flame>
which is basically a load
<beach>
Unless everything is always loaded.
<White_Flame>
which means your .rc file is performing loads
hhdave has joined #lisp
<beach>
Only if you are using a stupid OS like Unix.
<White_Flame>
do you just mapc over your QL dist and load everything?
<beach>
Otherwise, you wouldn't have a .rc file.
marusich has quit [Quit: Leaving]
<beach>
What I am saying is that we have these problems because we insist on using OS technology from the 1960s.
<White_Flame>
sure, including CL's model
<xificurC>
interpreting is a much simpler concept than compiling
<White_Flame>
but loading also might have initialization side effects, which make it a very decisive call
<beach>
Common Lisp has some features that allows it to run on 1960-style operating systems, but it would do much better as an operating system in itself.
<beach>
xificurC: What made you mention interpretation and compilation?
<White_Flame>
CL doesn't have a nice clean notion of "load" and dependency. It only has things to mutate its image on command
<antoszka>
beach: You mean Genera-style?
<beach>
xificurC: Seem like unrelated concepts.
vlatkoB has joined #lisp
<antoszka>
beach: With CL all the way down?
<beach>
antoszka: If you like, yes.
<antoszka>
(like the turtles)
aindilis has quit [Ping timeout: 240 seconds]
aindilis` has joined #lisp
<xificurC>
beach: my initial example question
<White_Flame>
another practical issue is the flat namespace for packages, which doesn't scale
<White_Flame>
so yeah, CL would need a lot of changes to clean up such issues; it's not just the OS
<beach>
xificurC: I don't recall your asking anything about interpretation vs compilation.
<White_Flame>
(although the influence from ye olde OSes certainly had a hand in the design)
<xificurC>
uiop:symbol-call works, but feels very hackish :)
<White_Flame>
when you need to hack, use EVAL ;)
loli1 has quit [Ping timeout: 248 seconds]
<xificurC>
beach: I was comparing to python, which would load such code fine
<shka>
White_Flame: not enough in his case
<beach>
xificurC: Still not related to interpretation vs compilation.
<shka>
because he needs to speculate on read time
<xificurC>
beach: how come?
<shka>
xificurC: you don't have issue with interpreter or compiler, you simply don't understand how reader works
<beach>
xificurC: Why would it be?
<White_Flame>
(when test (eval (read-from-string "lol lisp source code with read-time-unknown packages")))
<shka>
packages are implemented on the reader level
<shka>
White_Flame: yes, exactly
<shka>
but it won't work
<shka>
obviously
pierpal has joined #lisp
<shka>
xificurC: seriously, give yourself a favor and read this guide i pasted
<xificurC>
I will, thanks
<shka>
literally everyone starting with lisp is getting this wrong
<beach>
xificurC: Your question had to do with loading systems (that create packages) at run-time. Compilation and interpretation have to do with how programs are executed. The two are orthogonal concepts.
lumm has joined #lisp
<shka>
anyway, if beach is not using CL for scripting, it may suggest that scripting in CL is not a good idea :P
<antoszka>
shka: which guide did you paste? my favourite noob-lisp article (the complete idiot's guide)?
<aeth>
White_Flame: nothing scales indefinitely. packages scale OK except for nicknames, though.
<shka>
antoszka: yup
pierpal has quit [Read error: Connection reset by peer]
<shka>
antoszka: same you gave me waaaaaaaaaay back :-)
<White_Flame>
xificurC: think about your source code, as it is read. What are the symbols in the source code '(if test (require :foo) (foo:bar)) if the requirement is not loaded yet, before the form is executed?
<antoszka>
xificurC: I second the link that shka pasted, it was the *most* revealing CL text I read :)
<aeth>
xificurC: Even if it was interpreted it would still fail because it's read time, as shka said. As in, foo:bar becomes something else before an interpreter would get to it.
<xificurC>
shka: I'd rather put some effort into making it work with CL than keep using python
<beach>
White_Flame: I can fix the namespace problem with first-class global environments.
<antoszka>
shka: Yeah, it's excellent.
<White_Flame>
beach: yep, and I do like those ideas. But they are changes to CL, and old OS technology isn't 100% to blame
<White_Flame>
aeth: packages dont' scale great if every library in existence is always loaded all the time
<beach>
White_Flame: Oh, sure. By the way, first-class global environments do not alter the Common Lisp language, nor even extend it, any more than a library does.
<White_Flame>
*package names
<aeth>
xificurC: for instance, think about a literal read eval print loop, i.e. (loop (print (eval (read foo)))
<aeth>
White_Flame: If you count multiple versions of the same thing, then yes
<aeth>
They don't scale to 2, then
pierpal has joined #lisp
hhdave_ has joined #lisp
<shka>
beach: sadly, i can't simply run SICL
<shka>
and i don't know when i will can
jmercouris has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
hhdave_ is now known as hhdave
<White_Flame>
before you can run SICL, you must learn to walk SICL
<shka>
White_Flame: :D
<shka>
honestly, i don't even know how lisp future will look
wheelsucker has quit [Ping timeout: 245 seconds]
fikka has quit [Ping timeout: 244 seconds]
<shka>
if anybody could write blog post about that, it would be awesome
<shka>
something like Common Lisp 2025
smurfrobot has joined #lisp
<White_Flame>
2025: FOLLOW CLHS, CHANGE NOTHING
<White_Flame>
3025: FOLLOW CLHS, CHANGE NOTHING
<White_Flame>
etc
<White_Flame>
:)
trittweiler_ has joined #lisp
<White_Flame>
at some point, re-commoning Racket, Clojure, etc into a Common² Lisp would be interesting
fikka has joined #lisp
<shka>
Common Common Lisp
isBEKaml has joined #lisp
sjl has joined #lisp
sjl has quit [Ping timeout: 244 seconds]
pierpal has quit [Remote host closed the connection]
<xificurC>
shka: read it, useful, thanks
<xificurC>
everything is a freaking rocket in CL. No cars or bicycles, just rockets
<shka>
nah
<shka>
it ist just slightly different
<shka>
but if you think about it, it is hard to find other way to do things
<shka>
at least correct
<xificurC>
afaik picolisp doesn't do autointerning
<shka>
neither clojure
<White_Flame>
it's the same sort of namespacing that many languages have. it's just that other languages don't have first-class symbols
<shka>
but autointerining is not that important to be honest
<xificurC>
White_Flame: yes but (symbol-function 'foo:bar), I really expected that to work
<White_Flame>
what is 'foo:bar if there is no foo?
<beach>
xificurC: If that worked, you would have a very slow Lisp system.
<xificurC>
wouldn't think it's the reader's job to find that out
<White_Flame>
in C++, what is int x = foo::bar if there is no foo?
Batmode has quit [Quit: Leaving]
<White_Flame>
(or whatever its syntax is)
<xificurC>
I thought the symbol's function slot will be fetched at runtime
<xificurC>
which it is
<White_Flame>
then look up the symbol at runtime
<White_Flame>
which is perfectly doable
<White_Flame>
granted, it's a utility that isn't built in as a single function call; not sure if alexandria exports something like that
<xificurC>
I'll just have to remember it's the reader's job to work out the packages
<shka>
xificurC: exactly
<White_Flame>
it's the reader's job to turn a source code string into source code lists
<White_Flame>
and those lists contain symbol instances
<White_Flame>
(and yes, not just lists blah blah)
<xificurC>
there's uiop:find-symbol* which states "also works well when the package is not present"
<White_Flame>
there you go
<beach>
xificurC: If that worked, the system would have to store the package name and the symbol name. Whenever you need to call it as a function, it would have to find the package, then find the symbol in the package, then find the function that has that name.
<xificurC>
beach: that's what I was expecting
<beach>
xificurC: That might be what Python does, which is perhaps why Python is a few orders of magnitude slower than Common Lisp.
<White_Flame>
and that means you can't use it directly as a value
<beach>
xificurC: Well, Common Lisp was designed for high performance applications. Not for scripting.
<White_Flame>
if it had some sort of syntax, it would be (if test (funcall '#?foo:bar)) if #? meant runtime resolution of symbols
<shka>
beach: that being said, it CL can do all sorts of things
<xificurC>
beach: I really don't want to discuss what python does, I just gave an example of a language I know accepts that
<beach>
shka: Sure.
<shka>
i made document markup out of lisp ^_^
<xificurC>
I loathe python probably even more than js
<makomo>
i'm currently using python and the dreadful opencv library :^(
<shka>
xificurC: i think you simply need to switch your paradgim
<shka>
maybe instead of trying to run scripts, simply make self contained executable?
<White_Flame>
you should probably choose which file to load based on which libraries are there, not try to manage it per-expression
<shka>
using save-lisp-and-die
<xificurC>
shka: I'm switching paradigms all the time. from bash to python to CL to clojure to java to ...
<White_Flame>
iunless it's very localized and rare
<White_Flame>
what is the context around this runtime decision anyway?
<shka>
instead of spaghetti of script files, you will just have one executable
<xificurC>
save-lisp-and-die means I'm moving away from scripting to compiling
<xificurC>
White_Flame: context? what do you mean
<shka>
xificurC: to be honest you are compiling no matter what if you are using sbcl
<White_Flame>
what is the code trying to accomplish?
<makomo>
White_Flame: lazily loading packages, i think
<xificurC>
shka: yes but from scripts. If you change a .lisp file and save it you're done
<beach>
xificurC: You need to learn about compilation vs interpretation, because you are still confused about that.
<xificurC>
White_Flame: it's supposed to be a wrapper around a bunch of other tools
<White_Flame>
give me a specific. Why is that sort of test & call being made?
<White_Flame>
a specific situation
igemnace has joined #lisp
<shka>
xificurC: well, then automate edit lisp and build executable part
<shka>
at this point it is just a matter of convinience
<xificurC>
White_Flame: if git was a bunch of scripts then `git log` needs different things than `git tag`
<xificurC>
loading everything will have a different overhead to loading only what's needed for the particular command
<beach>
Yes, loading it only when you need it will be much slower.
<xificurC>
beach: compared to having one precompiled blub
<beach>
Yes.
<xificurC>
at which point editing will be much slower
<makomo>
tradeoffs everywhere
<beach>
xificurC: What?
<shka>
hardly
<shka>
xificurC: you can even connect to a running process and update code as it runs
<TMA>
xificurC: you should implement both variants and measure it -- performance is not much amenable to guesswork
<White_Flame>
I don't get the problem. If you want to minimally load things, and simulate a bunch of independent scripts, then have a .lisp file per thing you want to do, with the central launcher loading one of them. Each one would pull in its own dependency
<White_Flame>
which basically _is_ a bunch of independent scripts :-P
<xificurC>
as an example - I used anki on my work pc one time and wanted to download a deck from within it. I got a handshake failure because we have a MITM certificate. Anki gives no options to handle this of course. So I checked what is it written in - python; searched for the correct file, edited it, saved, restarted, done
<White_Flame>
I guess your launcher could also set a feature, and wrap each functionality in its own toplevel #+foo (progn ...)
<xificurC>
White_Flame: yes I was just thinking about that. Even more small files but would solve this problem
<beach>
xificurC: Sure, if you think editing files to fix bugs is going to be a more frequent activity than running the code, then you should choose that model.
<White_Flame>
but that feature-based one might be fiddly with managing read-time vs when the feature is set
SaganMan has quit [Quit: WeeChat 1.6]
<xificurC>
beach: it's not just that. The tools we use are included in every project as a git submodule. If I keep it as a pile-of-files I'm done. If I save-and-die 50MB or bigger images I have a new problem
<beach>
What problem would that be?
<beach>
The expensive 50MB disk space?
<xificurC>
distributing
<xificurC>
versioning
<xificurC>
handling different versions per project
<White_Flame>
source vs binary shouldn't affect versioning
<White_Flame>
it's an orthogonal problem
<xificurC>
true, still every project might need to use a different version
<xificurC>
especially in the beginning when changes are many and often breaking it's a big burden to maintain all of this
<White_Flame>
but in any case, loading fasls is quite fast. I suspect there's a good amount of overlap in the dependencies between the different things you're launching, and it wouldn't be expensive at all to just load in the union at the beginning, so all source code has the libs available
Ven`` has joined #lisp
<White_Flame>
if your tools are big enough to seaprate into separate .lisp files, then just selectively load one of those
<White_Flame>
and keep the dependencies in them
<White_Flame>
(keep the calls to load the dependencies in the individual lisp files, that is)
skeuomorf has joined #lisp
<xificurC>
thanks for the tips guys, I really appreciate it
hjek has joined #lisp
damke_ has joined #lisp
damke has quit [Ping timeout: 244 seconds]
aindilis` has quit [Remote host closed the connection]
glv has joined #lisp
smurfrobot has quit [Remote host closed the connection]
energizer has quit [Quit: Leaving]
phenoble has joined #lisp
<xificurC>
after reading about shadowing I'm still confused. I have a package with (defpackage :foo (:shadow #:arg) ...) and when I try to use-package it I get name-conflict with sb-debug:arg. I thought saying (:shadow #:arg) I'm saying "if someone uses me I want my symbol to be used"
<White_Flame>
if someone uses both foo and sb-debug, which arg should win?
pierpal has joined #lisp
<White_Flame>
also, export means if soembody uses you, they see that symbol.
<White_Flame>
not shadow. that overrides imports
trittweiler_ has quit [Ping timeout: 244 seconds]
<xificurC>
White_Flame: I'm exporting arg and I want it to override sb-debug:arg
<White_Flame>
that's up to the importing package, not up to foo
<White_Flame>
also, arg is a terrible symbol name to export, given how generic it is
<beach>
xificurC: I strongly recommend you don't USE packages other than the COMMON-LISP package.
<xificurC>
so foo doesn't need the declaration, it would need it only if it was using another package that would have arg exported?
<White_Flame>
if foo wants to decalre its own symbol, and it's using something which already defines it, then you want foo to locally shadow it
<White_Flame>
that's common for the concept of shadowing in most languages
_cosmonaut_ has quit [Ping timeout: 240 seconds]
<xificurC>
White_Flame: so how can I import it so that it overrides?
<beach>
xificurC: I strongly recommend you not import symbols and instead use explicit package prefixes.
<White_Flame>
as beach said, best not to :use
<xificurC>
beach: maybe if I tell the story you can tell me how you'd do it :)
<beach>
xificurC: When you USE a package, you commit yourself to future modifications to that package. You are not protected from the author of that package exporting a new symbol in a future release, and that symbol causing a conflict.
<xificurC>
we are building a whole bunch of docker images. There's Dockerfiles now and I want to substitute them (or get before them) with a small CL library that copies its commands and generates a Dockerfile from it. That gets me a step ahead and I can easily extract some data from it
<beach>
xificurC: Just don't USE. Instead, when you refer to an exported symbol in a different package, use an explicit package prefix.
<xificurC>
so my colleagues will be writing dockerfile.lisp files that will look like e.g. (from "ubuntu") (arg :foo) (copy "data/" "/data/") ...
<beach>
xificurC: It doesn't matter what use case you have. Just don't USE any package other than COMMON-LISP (which we know will not change in the future). Whenever you refer to a symbol BAR in the package FOO, instead of USE-ing FOO and writing just BAR, don't use FOO and write FOO:BAR instead.
<White_Flame>
if you want all utilities exposed that you wrote, then that code should be in-package foo
<White_Flame>
or make a simple package that uses it, sort of like cl-user uses cl
<xificurC>
beach: I didn't expect you to tell me my use case is fine for USEing, I wanted to ask if there's another *good* way of achieving the same result
<beach>
xificurC: Oh, I don't understand your use case. I was just telling you how to avoid the conflicting symbol problem, and how to make your application safer in the process.
<beach>
White_Flame: Actually, it is even better to have a separate package (say FOO) that only contains the exported symbols, and to have a package (say FOO-IMPLEMENTATION) that contains all random symbols introduced by code for the symbols in FOO.
<beach>
White_Flame: Common Lisp itself does that, as does CLIM.
pierpal has quit [Ping timeout: 256 seconds]
damke_ has quit [Ping timeout: 244 seconds]
<xificurC>
beach: why does that matter if the exported symbols are the same?
<beach>
White_Flame: I guess that's what you meant when you mentioned CL-USER.
<beach>
xificurC: It doesn't matter that much.
damke_ has joined #lisp
sjl has joined #lisp
<beach>
xificurC: The thing about not USE-ing is more important.
<makomo>
beach: what about the iterate library for example? the recommended way to use the library is to USE the package
<White_Flame>
package nicknames help keep the syntactic burden low
pierpal has joined #lisp
<beach>
makomo: I am sorry to hear that.
<makomo>
well, indeed :-)
<White_Flame>
bt:make-thread instead of bordeaux-threads:make-thread, for instance
<makomo>
i've asked about it here before, and i was told that just USE-ing the package is the way to go
<beach>
makomo: I am very sorry to hear that. :)
<makomo>
because the library uses symbols within its own package for iteration clauses, etc.
<makomo>
hah :-)
<xificurC>
beach: i was about to USE the package just before falling off the edge, as in (use :foo) (run-from-foo some-args) and that's the end of the file
<makomo>
beach: so for example (iterate:iterate (for ...)) won't work
<makomo>
you have to do (iterate:iterate (iterate:for ...)), etc.
<beach>
makomo: Indeed.
<makomo>
and that obviously gets out of hand very very quickly :'(
<makomo>
beach: i really like the first-class global environments idea. has it been implemented anywhere yet or is an implementation in progress?
<makomo>
especially because of the sandboxing issue
<White_Flame>
package local nicknames are also highly relevant here
sjl has quit [Ping timeout: 245 seconds]
kushal has quit [Read error: Connection reset by peer]
zooey has quit [Write error: Connection reset by peer]
<makomo>
hm, could a restricted reader achieve the same thing as FCGE (first-class global environments :-)) regarding the sandboxing issue?
kushal has joined #lisp
zooey has joined #lisp
<beach>
makomo: Cleavir uses the protocol. For SICL bootstrapping, the global environment is indeed an instance of a standard object that implements the protocol. Since Cleavir uses the protocol, so does Clasp and now the new CLISP compiler as well.
<makomo>
for example, you want to forbid the usage of EVAL/COMPILE, the #. read macro, etc.
<makomo>
the issue regarding #. would obviously be handled in the reader i guess, so it's not very relevant
<beach>
makomo: But I think they use a very simple instance where the methods trampoline to their own global environment.
_cosmonaut_ has joined #lisp
ssake has joined #lisp
<makomo>
beach: CLISP uses cleavir or just the fcge idea?
<beach>
makomo: karlosz is implementing a new Cleavir-based compiler for CLISP as a Google Summer-Of-Code project.
<jmercouris>
beach: How does that work exactly? does google interface with you directly or what?
<makomo>
oh wow!
<jmercouris>
did some student approach you to work on it?
<makomo>
beach: and who's the mentor? you?
<White_Flame>
#. is already disablable via *READ-EVAL*
<makomo>
White_Flame: yeah, true
<beach>
makomo: jmercouris No, CLISP is a GNU project, and the FSF is apparently pre-approved as a GSoC organization.
<jmercouris>
White_Flame: quick update, I've gotten 7 survey responses so far, collecting them is difficult
<jmercouris>
Ah, interesting, I did not know that
<beach>
makomo: As I understand it, the FSF is the mentor organization.
<jmercouris>
No wonder Clisp sucks
<beach>
jmercouris: karlosz suggested it himself and it was approved.
<makomo>
beach: ah i see. right, makes sense since it's a gsoc for clisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beach>
jmercouris: What do you mean by "No wonder Clisp sucks"?
<makomo>
^^^ i'm also interested lol :-)
<jmercouris>
I mean that any project sponsored by GNU seems to suffocate
<beach>
jmercouris: That is truly unfair.
<makomo>
i don't really see that
<beach>
jmercouris: It is also off topic.
<jmercouris>
Yeah, it is off-topic, indeed, sorry
<makomo>
beach: and about my fcge vs. restricting the reader question (in the context of the sandboxing issue)?
<_death>
personally, I :use :cl and sometimes packages that I have under my control, and use :import-from for others.. whether to do that or use package prefix depends on the interface exported, but usually I go for the former
<beach>
makomo: I don't think it will work.
<beach>
I think karlosz idea is brilliant. It will improve CLISP, but it will also improve Cleavir, so everyone will benefit. For instance, he is working on SSA conversion that we haven't bothered with very much so far.
<jmercouris>
beach: are you using Cleavir for linting?
<makomo>
i see
<beach>
jmercouris: No, not really.
<makomo>
beach: it won't work because restricting the reader doesn't handle all of the cases or?
<jmercouris>
beach: what is your main use case?
<beach>
makomo: Right.
<beach>
jmercouris: For Cleavir?
<jmercouris>
beach: yes
<p_l>
beach: damn, maybe it will dislodge some stupid in CLISP and breathe new life into it
<beach>
jmercouris: Compiling SICL.
<jmercouris>
That makes sense, I was going to guess that
<beach>
p_l: I hope so.
<jmercouris>
but better to ask than assume
<p_l>
beach: I once looked into some of the memory management code, I remember running away in horror
<beach>
Recall that a major reason for Cleavir is to attempt to cut down on the global maintenance burden of free Common Lisp systems. If more free Common Lisp systems use the Cleavir compiler, then the hope is that there will be less implementation-specific code to maintain.
<jmercouris>
p_l: I'm curious, why would we want to renew another implementation?
<beach>
p_l: Oh, heh!
<beach>
jmercouris: Every implementation has its specific features.
<p_l>
jmercouris: multiple implementations that are kept compatible *strengthen* the community
<p_l>
IMO
<jmercouris>
are there any "killer" clisp specific features?
<beach>
jmercouris: CLISP has arbitrary-precision floats for intstance.
<beach>
instance.
<makomo>
beach: hmm, i'm trying to think of such an example -- maybe a macro constructing the symbol in a sneaky way or something? you could still take care of it by doing extra checks after reading, i.e. reading everything, macroexpanding it and then checking, perhaps?
<p_l>
if they aren't kept compatible, the opposite happens (look at Scheme)
<beach>
makomo: Very hard.
<makomo>
beach: but i think then you'll have to do codewalking, right? and that isn't really portable
<p_l>
if there's *no effort to provide compatible separate implementations*, bad shit happens (Python)
<jmercouris>
I guess that would be useful for mathematical and engineering purposes
<p_l>
jmercouris: also to keep code sane
<beach>
makomo: That, and you would still have a hard time.
<jmercouris>
p_l: what do you mean?
<makomo>
beach: hm, right
<p_l>
jmercouris: having a healthy ecosystem of multiple implementations gives more pressure to write portable code
jameser has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jmercouris>
Oh, I see what you are saying
<jmercouris>
a sort of "capitalisic" view of the software eco system
<beach>
makomo: You would have to recognize attempts to do intern and fdefinition and funcall.
<p_l>
jmercouris: enough that you end up having companies that explicitly take different implementations for their specific quirks and write compatible code
<makomo>
beach: hm yeah, a *LOT* of sneaky stuff
<p_l>
jmercouris: for example ITA Software, iirc, used both SBCL and CCL, because CCL was much faster in compiling but SBCL had higher final performance, so CCL handled web code for example
<jmercouris>
p_l: wait a second, I thought you couldn't count on compiled code to work between different implementations?
<p_l>
jmercouris: separate processes
<jmercouris>
Okay I see
<makomo>
beach: i've noticed that you rarely include pdfs in your repositories, i.e. leaving it to the reader to compile the documents from latex. is this a valid observation or did i just stumble upon a few such repos?
<beach>
makomo: That's a correct observation.
<makomo>
i wanted to say that having already compiled pdfs would be much better imo
<makomo>
not sure what your rationale is, but it's much much easier to just click a pdf than to (1) clone the repo, (2) fetch the latex deps, (3) build the pdf
<beach>
makomo: For the same reason I don't have FASLs.
<jmercouris>
p_l: do you have a blog?
<jmercouris>
maybe you have written about this stuff?
<p_l>
not at the moment, unfortunately
<beach>
makomo: I often publish the PDFs on metamodular.com
<makomo>
beach: i thought that might be it, but in my mind the two aren't really comparable
<jmercouris>
makomo: or you could just read the latex files
<beach>
makomo: Which one are you looking for?
<p_l>
jmercouris: I've been trying to get one started, but it would be probably more DevOps oriented because it would exist to troll for contracts
<makomo>
they are both products of the build system, sure, but the pdfs are something that should be readily available imo
<makomo>
it's a huge convenience
<makomo>
beach: nothing in particular, but i noticed it just now when i went to see the SICL docs
smurfrobot has joined #lisp
<jmercouris>
makomo: would you include compiled binaries within your git repository?
<makomo>
jmercouris: without the nice links and stuff? no way
<makomo>
jmercouris: i just said why i don't consider the two to be the same at all
<p_l>
jmercouris: ... that's a tricky question, sometimes you actually should include them...
markoong has joined #lisp
<makomo>
i agree with not including binaries such as fasls in your git repo, because they're implementation specific, blah blah
<makomo>
but a pdf is a pdf, a *portable* document format
<jmercouris>
I generally prefer not to include them
<makomo>
anyone can open read a pdf, no matter what system they're on
<jmercouris>
pdf is portable so long as adobe chooses to make a reader
<p_l>
makomo: better option would be to provide a quick and easy way to publish them from repo
<makomo>
browsing a git repo through the web interface and having the convenience of just clicking on a pdf is great IMO
<jmercouris>
you can reverse engineer pdf, but ultimately adobe controls the specification
<jmercouris>
latex is something else entirely
<jmercouris>
I agree with the decision not to include PDFs
<makomo>
jmercouris: they do, but that hasn't stopped people making a lot of pdf readers
<p_l>
jmercouris: there's PDF and PDF
<p_l>
for example, there's ISO standard for PDF
<p_l>
and surprise, it's actually followed
<jmercouris>
really? that I did not know!!
<jmercouris>
that is actually quite useful to know
<p_l>
jmercouris: it's crucial among other things for the print industry
<jmercouris>
I feel slightly better about using them then
<p_l>
the spec was free of charge since 1993, but in 2008 it was passed on fully to ISO
<p_l>
with patent license
smurfrobot has quit [Ping timeout: 240 seconds]
<p_l>
(meaning Adobe won't pursue patents it owns for PDF-related code)
<makomo>
p_l: what did you mean by "publish"?
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<p_l>
makomo: imagine a CI task that builds the docs and publishes it on a static site
wigust- has joined #lisp
<makomo>
p_l: oh like that, yeah that's an option i guess, but it's much more work to do than just leaving a compiled pdf in the repo
<xificurC>
is mcclim "production ready"?
Kaisyu has quit [Quit: Connection closed for inactivity]
<makomo>
beach: oh yeah, i actually wanted to read the ILC-2014 paper, do you have that one available somewhere?
<makomo>
i haven't actually opened the tex files to check the contents, heh, sorry
<makomo>
yeah, i have that one, never mind
Kevslinger has joined #lisp
<beach>
makomo: It's the only paper I have written on first-class global environments.
<makomo>
mhm
<beach>
Thanks for the typo reports. I'll fix.
smurfrobot has quit [Ping timeout: 244 seconds]
<makomo>
beach: instead of pushing the pdfs into the repo, you should perhaps set up an index of the pdfs you host on metamodular, organized by projects or similar
<beach>
makomo: Sure. The problem is that there are SO many things that I should do.
<makomo>
SICL/Papers/ has a lot of good stuff and you can't read any of it without compiling it yourself. call me lazy, but i like being able to browse around a project's github repo and inspect the docs within my browser
BillyZane has quit [Ping timeout: 244 seconds]
<beach>
makomo: I'll think about it.
<makomo>
beach: yeah, true, i understand that. :-( thanks for considering it
<beach>
Thank YOU for suggesting it.
<makomo>
:-)
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
Ven`` has joined #lisp
araujo has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
Ven`` has quit [Read error: Connection reset by peer]
<p_l>
beach: what if someone set you up a system for this?
pierpal has joined #lisp
Ven`` has joined #lisp
<White_Flame>
given that one might describe something beneficial as "the bomb", does that mean you're someone who will set us up the bomb?
<p_l>
i.e. something that would build PDFs from your repos and publish them without any work from you?
<makomo>
p_l: i thought of the same thing, but where would it be published?
SaganMan has joined #lisp
<makomo>
would one have to pay for hosting or could one just use something like github pages?
<p_l>
makomo: for el-cheap version, in the same github account using github pages
<makomo>
right
pierpal has quit [Client Quit]
pierpal has joined #lisp
<makomo>
well, that would be quite nice actually
smurfrobot has joined #lisp
kuwze has joined #lisp
Ven`` has quit [Read error: Connection reset by peer]
Ven`` has joined #lisp
smurfrobot has quit [Ping timeout: 244 seconds]
_cosmonaut_ has quit [Ping timeout: 256 seconds]
pierpal has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 256 seconds]
aaaahh has joined #lisp
pierpal has joined #lisp
pierpal has quit [Client Quit]
Ven`` has quit [Read error: No route to host]
pierpal has joined #lisp
Ven`` has joined #lisp
<beach>
p_l: That would be fantastic!
smurfrobot has joined #lisp
damke_ has quit [Quit: quit]
fikka has joined #lisp
aaaahh has quit [Ping timeout: 276 seconds]
pierpal has quit [Ping timeout: 248 seconds]
damke has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
fikka has quit [Ping timeout: 248 seconds]
Ven`` has quit [Read error: No route to host]
Ven`` has joined #lisp
<p_l>
I'll take a look later over your repos, you keep them all on github or also in some other places?
<p_l>
Then we could set up some CI (circle-ci is free for open source projects, for example)
<beach>
They are all on GitHub.
<beach>
I wouldn't mind creating some structure on metamodular.com since I own it.
_cosmonaut_ has joined #lisp
<beach>
But I think I need help with the mechanisms of publishing after modifications to some documentation.
<p_l>
beach: ultimately it's a question of how to push the changed documents, i.e. how to provide access to the server
<beach>
I suppose so, yes.
<p_l>
with CI we can easily integrate that for example every commit to "master" will result in a build and push
<p_l>
or depend on tag
<beach>
Sounds good to me.
Cymew has quit [Remote host closed the connection]
Cymew has joined #lisp
fikka has joined #lisp
Cymew has quit [Ping timeout: 255 seconds]
damke_ has joined #lisp
pierpal has joined #lisp
damke has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
pierpal has quit [Quit: Poof]
EvW has joined #lisp
pierpal has joined #lisp
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has quit [Ping timeout: 255 seconds]
TCZ has joined #lisp
fikka has joined #lisp
pierpal has quit [Ping timeout: 268 seconds]
__rumbler31 has joined #lisp
Domaldel has joined #lisp
__rumbler31 has quit [Remote host closed the connection]
zooey has quit [Ping timeout: 250 seconds]
zooey has joined #lisp
dddddd has quit [Remote host closed the connection]
sjl has joined #lisp
damke has joined #lisp
sjl has quit [Ping timeout: 276 seconds]
pierpal has joined #lisp
damke_ has quit [Ping timeout: 244 seconds]
isBEKaml has left #lisp [#lisp]
Ven`` has joined #lisp
smurfrobot has joined #lisp
pierpal has quit [Ping timeout: 260 seconds]
smurfrobot has quit [Ping timeout: 256 seconds]
sz0 has quit [Quit: Connection closed for inactivity]
damke_ has joined #lisp
schjetne has quit [Ping timeout: 245 seconds]
rpg has joined #lisp
schjetne has joined #lisp
damke has quit [Ping timeout: 244 seconds]
xristos has joined #lisp
hjek has quit [Ping timeout: 268 seconds]
Folkol has joined #lisp
jfrancis has quit [Ping timeout: 244 seconds]
sjl has joined #lisp
jfrancis has joined #lisp
Ven`` has quit [Read error: Connection reset by peer]
sjl has quit [Ping timeout: 276 seconds]
Ven`` has joined #lisp
pierpal has joined #lisp
mparashar has joined #lisp
__rumbler31 has joined #lisp
<xificurC>
(asdf:load-system :foo) and therefore (require :foo) writes compilation output to *standard-output*. Giving :verbose nil to asdf:load-system still does it. Why isn't this information going into stderr?
<tyrese>
i'm just messing around with lisp to learn a little bit more about it
<pjb>
and link to chapter 22.
<jmercouris>
pjb: not matrixes?
<pjb>
what are matrices?
<jmercouris>
pjb: when you say 2d array, you mean lists, right?
<jmercouris>
you don't really mean arrays?
Cymew has joined #lisp
<jmercouris>
or do you mean make-array?
<jmercouris>
are there performance implications?
<pjb>
If I meant lists, I would have said lists.
dcluna has quit [Ping timeout: 276 seconds]
<pjb>
Yes, accessing pixels in a 2D array is O(1).
<pjb>
If you want it slower, like O(n*m), use lists of lists.
<jmercouris>
lol
<pjb>
Note that for some algorithms, you may prefer to use vectors instead of 2d arrays.
<pjb>
With a rowBytes parameters, and possibly a rectangle in the middle of the array.
smurfrobot has quit [Ping timeout: 256 seconds]
dcluna has joined #lisp
<pjb>
For example, the spacewar game is played on a torus, so it's advantageous to use a vector, so that when you draw the meteorites on the side of the screen, they are automatically drawn on the other side (one row below, but this is not perceptible in general).
fikka has joined #lisp
jfrancis_ has joined #lisp
rumbler3_ has joined #lisp
Kundry_Wag has joined #lisp
xaotuk1 has joined #lisp
rumbler31 has quit [Read error: Connection reset by peer]
jfrancis has quit [Read error: Connection reset by peer]
zmt00 has quit [Read error: Connection reset by peer]
LiamH has quit [Read error: Connection reset by peer]
bjorkintosh has joined #lisp
bjorkintosh has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 244 seconds]
xaotuk has quit [Remote host closed the connection]
xaotuk1 is now known as xaotuk
<jmercouris>
I have no idea what you are talking about honestly
<jmercouris>
spacwar game?
<jmercouris>
s/spacwar/spacewar
LiamH has joined #lisp
dcluna has quit [Ping timeout: 244 seconds]
Kundry_Wag has quit [Remote host closed the connection]
<pjb>
Of course, the original was programmed on a vectorial screen, so it was different, but the following ones that were programmed on raster screens used that trick.
<rpg>
Quick question: the gitlab docs say that it's possible to do a squash merge to accept a merge request. But on cl.net I don't see this option. Anyone know how to use it? Or is this feature unavailable on cl.net?
vlatkoB has quit [Remote host closed the connection]
fikka has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
nullman has quit [Ping timeout: 240 seconds]
nullman has joined #lisp
fyodost has joined #lisp
rixard has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
Kundry_Wag has joined #lisp
rixard has quit [Client Quit]
hjek has quit [Ping timeout: 245 seconds]
fikka has joined #lisp
pfdietz has joined #lisp
isBEKaml has quit [Ping timeout: 240 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
mindCrime has quit [Ping timeout: 260 seconds]
isBEKaml has joined #lisp
isBEKaml has quit [Changing host]
isBEKaml has joined #lisp
trittweiler_ has quit [Ping timeout: 256 seconds]
nickenchuggets has quit [Read error: Connection reset by peer]
nickenchuggets has joined #lisp
nickenchuggets has joined #lisp
nickenchuggets has quit [Changing host]
natrys has quit [Ping timeout: 240 seconds]
<aeth>
So in some quick tests, typep on a member type can be really fast in SBCL.
<Bike>
it drops to a bunch of eql tests, i think
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<aeth>
member typep is faster than find in a sequence, at least for characters (where the sequence is a string) and unlike the latter it can be entirely resolved at compile time (find will iterate even if everything's constant)
<aeth>
about 10x faster iirc
jsjolen has joined #lisp
hjek has joined #lisp
smurfrobot has joined #lisp
natrys has joined #lisp
energizer has quit [Quit: Leaving]
Folkol has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
pierpa has joined #lisp
shka_ has quit [Ping timeout: 260 seconds]
Patzy_ has joined #lisp
jfrancis_ has quit [Ping timeout: 240 seconds]
smurfrobot has joined #lisp
schjetne has joined #lisp
varjag has joined #lisp
energizer has joined #lisp
Patzy_ has quit [Quit: WeeChat 2.1]
Patzy_ has joined #lisp
smurfrobot has quit [Ping timeout: 268 seconds]
Patzy_ has quit [Client Quit]
Patzy has quit [Quit: leaving]
Patzy has joined #lisp
cage_ has quit [Ping timeout: 248 seconds]
smurfrobot has joined #lisp
schjetne has quit [Ping timeout: 240 seconds]
energizer has quit [Disconnected by services]
energizer has joined #lisp
energizer has quit [Remote host closed the connection]
energizer has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
energizer has quit [Remote host closed the connection]
papachan has quit [Quit: WeeChat 2.1]
Patzy has quit [Quit: WeeChat 2.1]
Patzy has joined #lisp
smurfrobot has joined #lisp
robotoad has quit [Ping timeout: 240 seconds]
smurfrobot has quit [Ping timeout: 256 seconds]
LiamH has quit [Quit: Leaving.]
robotoad has joined #lisp
Bike has quit [Ping timeout: 260 seconds]
sjl has quit [Quit: WeeChat 2.0.1]
jsjolen has quit [Ping timeout: 256 seconds]
smurfrobot has joined #lisp
dacoda has joined #lisp
<dacoda>
Hello!
<dacoda>
I had a question about Common Lisp
<dacoda>
I was wondering if it was possible to create an array displaced to another array of a different type
<dacoda>
For example, if I have one array of '(unsigned-byte 8) and I wanted to displace another array of '(unsigned-byte 16), is this possible?
<dacoda>
Otherwise, how can I re-use the data of the first array while interpreting it as 16-bit integers?
<MichaelRaskin>
I wouldn't expect this to work well, given that many implementations «tag» the data to keep track of types
jmercouris has joined #lisp
<MichaelRaskin>
I guess with FFI you can achieve unsafe aliasing
<dacoda>
Hahahaha, that would be an interesting way around it! Just have a C function that takes in a uint8_t buffer and casts it to a uint16_t buffer, eh?
<dacoda>
I'm using it for a little toy script, and if that's the solution, I might as well write it in C
smurfrobot has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
Well, FFI has functions for direct manipulation of foreign memory, no need for the C function.
Kundry_Wag has quit [Remote host closed the connection]
<dacoda>
Oh, no way! That would be awesome
<dacoda>
We talking the CFFI package or something else?
<MichaelRaskin>
Note that you give up any and all Common Lisp safety when you do foreign memory manipulations by hand…
<MichaelRaskin>
CFFI is a good wrapper around the native FFI implementations, yes
<dacoda>
Yes, that's acceptable, for this particular use case I'm rather sure about the data
Folkol has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dacoda>
Okay, I'm gonna take a look into that :D
<aeth>
You can also abuse inline assembly if you don't want to be portable.
<aeth>
CFFI is probably easier.
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
schjetne has joined #lisp
<MichaelRaskin>
subsections 7.2/7.3 in CFFI manual
pjb has quit [Read error: Connection reset by peer]
xaotuk has quit [Ping timeout: 260 seconds]
<aeth>
ah, I see, with-pinned-objects should behave similarly (but it isn't used in static-vectors)
jfrancis has quit [Ping timeout: 260 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
schjetne has quit [Ping timeout: 248 seconds]
FreeBirdLjj has joined #lisp
sz0 has joined #lisp
Bike has joined #lisp
blackwolf has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
FreeBirdLjj has quit [Ping timeout: 260 seconds]
shangul has quit [Quit: sudo rm -rf /usr/*]
pierpal has quit [Read error: Connection reset by peer]
sjl has joined #lisp
<dacoda>
Ahhh, in any case
<dacoda>
That was interesting
<dacoda>
Thanks a lot for your help :D
<dacoda>
Have a good rest of your day :)
robotoad has quit [Quit: robotoad]
random-nick has quit [Ping timeout: 276 seconds]
fikka has quit [Ping timeout: 265 seconds]
loli has quit [Quit: WeeChat 2.1]
<aeth>
You should probably use static-vectors because it's portable, but... I'm not sure if its implementation method in SBCL is better than yours and what the various drawbacks are.
fikka has joined #lisp
karlosz has quit [Remote host closed the connection]
loli has joined #lisp
karlosz has joined #lisp
__rumbler31 has quit [Ping timeout: 256 seconds]
atr3y0 has joined #lisp
karlosz has quit [Ping timeout: 260 seconds]
xaxaac has quit [Quit: Leaving]
fikka has quit [Ping timeout: 256 seconds]
jmercouris has quit [Ping timeout: 260 seconds]
robotoad has joined #lisp
ZombieChicken has joined #lisp
fikka has joined #lisp
robotoad has quit [Quit: robotoad]
fikka has quit [Ping timeout: 260 seconds]
schjetne has joined #lisp
fikka has joined #lisp
Ven`` has joined #lisp
dented42 has joined #lisp
schjetne has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 256 seconds]
robotoad has joined #lisp
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 265 seconds]
smurfrobot has joined #lisp
smurfrobot has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
fikka has joined #lisp
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]