brokkoli_origin has quit [Ping timeout: 255 seconds]
brokkoli_origin has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
slyrus has quit [Ping timeout: 252 seconds]
jweeks has joined #commonlisp
josrr has quit [Remote host closed the connection]
slyrus has joined #commonlisp
X-Scale has quit [Quit: Client closed]
X-Scale has joined #commonlisp
slyrus has quit [Ping timeout: 264 seconds]
synchromesh has quit [Quit: WeeChat 4.0.5]
<beach>
yottabyte: The problem I was referring to was the creation of a pure Lisp environment that craigbro thought was unsolved, so I mentioned Genera.
<beach>
yottabyte: And I mentioned that Genera is not adapted to modern use, because it is a single-user system where the user can do anything. Today, with all kinds of malware, that would not be a good idea.
synchromesh has joined #commonlisp
<aeth>
the way to do it is simple: a top-down approach where you write portable software because that solves the problem of not having any software, and even if no one uses the whole OS, they at least use some of it
<aeth>
unfortunately, that means a web browser is the most important part and the monopolist does not make it easy to make your own web browser, adding lots of mostly-useless features to make it hard to compete while constantly breaking compatibility with other browsers on its top websites
<aeth>
so it's simple, but not easy
<aeth>
So imo a modern Lisp system should probably use HTML and self-document itself in HTML. Even if that HTML engine can't run outside websites, it may eventually bloat into doing so one day.
slyrus has joined #commonlisp
synchrom1 has joined #commonlisp
kevingal_ has quit [Ping timeout: 255 seconds]
pfdietz has joined #commonlisp
synchrom2 has joined #commonlisp
synchromesh has quit [Ping timeout: 256 seconds]
synchrom1 has quit [Ping timeout: 256 seconds]
slyrus has quit [Ping timeout: 264 seconds]
slyrus has joined #commonlisp
slyrus has quit [Ping timeout: 240 seconds]
danse-nr3 has joined #commonlisp
rtypo has quit [Ping timeout: 264 seconds]
slyrus has joined #commonlisp
decweb has quit [Ping timeout: 255 seconds]
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 268 seconds]
slyrus has quit [Ping timeout: 264 seconds]
wacki has joined #commonlisp
slyrus has joined #commonlisp
slyrus has quit [Ping timeout: 252 seconds]
genera_ has joined #commonlisp
danse-nr3 has quit [Ping timeout: 240 seconds]
genera has quit [Ping timeout: 268 seconds]
slyrus has joined #commonlisp
istewart has quit [Quit: Konversation terminated!]
slyrus has quit [Ping timeout: 255 seconds]
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
craigbro has joined #commonlisp
jonatack has joined #commonlisp
jon_atack has quit [Ping timeout: 264 seconds]
jon_atack has joined #commonlisp
decweb has joined #commonlisp
jonatack has quit [Ping timeout: 264 seconds]
semarie has quit [Quit: WeeChat 4.2.2]
semarie has joined #commonlisp
edgar-rft has quit [Quit: don't waste your life by reading this]
decweb has quit [Ping timeout: 256 seconds]
slyrus has joined #commonlisp
jon_atack has quit [Ping timeout: 264 seconds]
slyrus has quit [Ping timeout: 252 seconds]
jweeks has quit [Remote host closed the connection]
pfdietz has quit [Quit: Client closed]
slyrus has joined #commonlisp
jonatack has joined #commonlisp
slyrus has quit [Ping timeout: 264 seconds]
amb007 has quit [Read error: Connection reset by peer]
<ixelp>
virtio-gpu: Hard-code the resolution to 1024x768 · froggey/Mezzano@8555ca2 · GitHub
nickiminjaj has quit [Client Quit]
<Shinmera>
... I mean it has to display something you know
<hayley>
What counts as a GPU driver - does it have to do acceleration or just talk to a framebuffer?
<Shinmera>
mezzano talks to fbs fine
<hayley>
Right.
<Shinmera>
but if you scan up in the log what I was talking about was obviously acceleration
<yottabyte>
gotcha. yeah, I'm not familiar with OSes enough, but I see what you mean now
<hayley>
My log cut off just before that, so I better read the Tymoon log.
<froggey>
there's enough virtio-gpu support to use qemu's virgl 3d acceleration
<hayley>
Okay, using a framebuffer doesn't need humongous code!
<yottabyte>
totally unrelated, with hunchentoot, does anyone know how to define an endpoint like users/{userId}? getting parts from the url path. I've read about quri and puri, but I'm not exactly sure how to integrate them with hunchentoot. moreover, perhaps I'm having to do too much manual stuff in using hunchentoot, but I'm using it because it was pretty much the only one I could get up and running
<yottabyte>
I pretty much just want to write a rest api. just returning json to the frontend
<yottabyte>
it won't be serving any html (I think)
<Shinmera>
froggey: use in what sense? are the GL API calls exposed somehow?
<Shinmera>
or is this a different GL than OpenGL :v
skeemer has joined #commonlisp
<froggey>
Shinmera: virgl kinda-sorta exposes OpenGL to the guest
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
random-nick has quit [Ping timeout: 264 seconds]
slyrus has quit [Ping timeout: 264 seconds]
kevingal has quit [Ping timeout: 255 seconds]
chomwitt has joined #commonlisp
chomwitt has quit [Ping timeout: 256 seconds]
King_julian has quit [Ping timeout: 255 seconds]
random-nick has joined #commonlisp
slyrus has joined #commonlisp
<yottabyte>
in slime, how do I load the entire file/buffer?
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<craigbro>
muscle memory says C-c C-k
<craigbro>
that should compile and load file
<yottabyte>
ty, worked
<craigbro>
also C-c C-l will load
<yottabyte>
is that what you typically do when you open a file when you're developing?
<yottabyte>
what's the difference between compile and load and loading?
slyrus has quit [Ping timeout: 268 seconds]
<craigbro>
yah, it's so ingrained in my brain it's nearly automatic
<craigbro>
one will run the compiler and load the results, the other just evals
<craigbro>
in terms of impact on system, not much difference (some impls will always compile when loading)
<yottabyte>
gotcha
<craigbro>
when you start setting optimization options and the like, it can make a difference
<yottabyte>
and when you're quickloading dependencies, do you just have those at the top, before your defpackage, or what?
<craigbro>
my brain is wired for C-c C-k as oppens to C-c C-l for reasons I cannot recall
<craigbro>
I honestly am just getting back into CL, when I last wrote alot, no quicklisp, only asdf
<craigbro>
so I guess I'll find out in the next couple months as I write some more CL
<yottabyte>
okay
<craigbro>
that seems a reasonable approach for a simple project tho
puke has joined #commonlisp
slyrus has joined #commonlisp
<beach>
One might use the file compiler which has slightly different semantics than EVAL does.
<beach>
yottabyte: The first thing to do during development is to let ASDF load your project according to the system definition.
<beach>
yottabyte: Otherwise, you will have to do that manually to get dependencies right.
<beach>
yottabyte: So you should not have Quicklisp dependencies in your Lisp files.
<yottabyte>
so are you saying like ql:quickload is something I would do in my repl, just to get it installed, then I would import the packages in my defpackage?
<beach>
C-c C-k compiles and loads the file, so that uses file-compilation semantics I guess.
<beach>
C-c C-l uses LOAD.
<beach>
... so no file compiler.
<paulapatience>
yottabyte: Yes
<yottabyte>
I see
synchromesh has quit [Read error: Connection reset by peer]
synchromesh has joined #commonlisp
slyrus has quit [Ping timeout: 264 seconds]
<beach>
yottabyte: What paulapatience said, but what do you mean by "import the packages in my defpackage"?
<yottabyte>
like (defpackage :server (:use :cl :hunchentoot :yason))
<beach>
I highly recommend you :USE only the COMMON-LISP package, and use explicit package prefixes for the others.
<beach>
yottabyte: You can use package-local nicknames to make the package prefixes shorter if you prefer.
<yottabyte>
can you tell me what you mean?
<beach>
Instead of :USE :HUNCHENTOOT and then in your code you use some symbol FOO from the HUNCHENTOOT package, you do not :USE :HUNCHENTOOT and instead do HUNCHENTOOT:FOO with a package prefix, or H:FOO if you define H to be a package-local nickname for HUNCHENTOOT.
slyrus has joined #commonlisp
szkl has joined #commonlisp
danse-nr3 has quit [Ping timeout: 264 seconds]
<yottabyte>
how do I have access to the package hunchentoot though? it just finds it when I do hunchentoot:foo?
<beach>
yottabyte: And what you described is not referred to as "import" but as "use". IMPORT is a different operation.
<beach>
yottabyte: If the hunchentoot system was loaded into your Common Lisp image, then the hunchentoot package was defined in the process.
mgl_ has quit [Ping timeout: 256 seconds]
<yottabyte>
gotcha
<yottabyte>
so I made another package, should I not :use that, either?
slyrus has quit [Ping timeout: 256 seconds]
<beach>
I highly recommend you do not :USE any package other than the CL package, or perhaps one that you are intimately familiar with and that you control. But even that is questionable.
<beach>
yottabyte: :USE does not "find" any packages. A package is either in your image or it isn't. It is in your image when a DEFPACKAGE form defining it was loaded. So when the hunchentoot system was loaded, a file containing (DEFPACKAGE #:HUNCHENTOOT...) was likely loaded. That makes the package exist in your image.
<yottabyte>
gotcha, and it was probably in my image because I quickloaded it
<beach>
Correct.
<yottabyte>
but I only need to do that once, once it's there, I can use it forever?
<beach>
Quickload loads an ASDF system into your image and that system will contain code to define one or more packages.
<beach>
Each time you start a new Common Lisp image, you need to use either Quickload or ASDF:LOAD-SYSTEM to make your image contain the code of your project.
<beach>
That's why we recommended starting your development cycle that way.
<yottabyte>
and each time I start slime, that's a new CL image
<beach>
Yes.
* beach
vanishes in order to fix dinner for his (admittedly small) family, and will be back tomorrow.
<yottabyte>
okay, thanks for the help beach!
<yottabyte>
I have to do some reading about the asdf load system and stuff, but it's really starting to come together
danse-nr3 has joined #commonlisp
louis77 has left #commonlisp [#commonlisp]
occ has quit [Ping timeout: 264 seconds]
slyrus has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 264 seconds]
slyrus has quit [Ping timeout: 255 seconds]
pranav has quit [Remote host closed the connection]
X-Scale has quit [Quit: Client closed]
slyrus has joined #commonlisp
X-Scale has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
d4ryus has quit [Ping timeout: 252 seconds]
d4ryus has joined #commonlisp
msavoritias has joined #commonlisp
waleee has joined #commonlisp
slyrus has quit [Ping timeout: 264 seconds]
amb007 has quit [Ping timeout: 255 seconds]
nybble has joined #commonlisp
amb007 has joined #commonlisp
slyrus has joined #commonlisp
slyrus has quit [Ping timeout: 256 seconds]
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
phoe has quit [Ping timeout: 260 seconds]
phoe has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
slyrus has joined #commonlisp
cage has joined #commonlisp
msavoritias has quit [Ping timeout: 252 seconds]
ocra8 has quit [Read error: Connection reset by peer]
slyrus has quit [Ping timeout: 272 seconds]
ocra8 has joined #commonlisp
awlygj has quit [Quit: leaving]
ocra8 has quit [Ping timeout: 240 seconds]
ocra8 has joined #commonlisp
slyrus has joined #commonlisp
anticomputer_ has joined #commonlisp
anticomputer has quit [Ping timeout: 260 seconds]
szkl has quit [Quit: Connection closed for inactivity]
slyrus has quit [Ping timeout: 256 seconds]
mgl_ has joined #commonlisp
ym has joined #commonlisp
slyrus has joined #commonlisp
bland has joined #commonlisp
<bland>
Is there a standard library for Unix sockets? Doesn't look like usocket supports AF_UNIX
reb has quit [Ping timeout: 240 seconds]
reb has joined #commonlisp
mgl_ has quit [Ping timeout: 264 seconds]
slyrus has quit [Ping timeout: 264 seconds]
<Shinmera>
I don't think so, but you could pilfer swank, I think that has a unix sockets mode
<yitzi>
cl-unix-sockets
<yitzi>
An amazingly creative name.
pranav has joined #commonlisp
<bland>
just looked it over-- the asdf system calls gcc during build and does not appear to have Windows support-- think I might have to roll my own here-- thanks for tracking that down, though!
<yottabyte>
and :depends-on would be everything that I've used quicklisp for across the 2 packages?
<kanuba>
Systems are in no way related to packages. Packages are in no way related to files. Systems care about files.
<kanuba>
So depends-on the systems you intend to use for your system. Think about multiple systems when you think about distribution of your code
<yottabyte>
but in that cookbook, foobar and alexandria are packages, aren't they? I mean I guess foobar is also a file
<kanuba>
Most of the time, systems have a single package of the same name.
<kanuba>
Packages are just a means to namespace. They don't contain anything but symbols. Not files, or code, or what have you.
<kanuba>
A package is similar to what you would call a symbol table during the compilation of traditional languages. In Go(lang), a package is similar to that of CL, and a module is similar to that of a CL system. In Julia(lang), it is the opposite, with modules being more like CL packages, and packages being more like CL systems. Most languages though, do not namespace symbols like CL does, or even
<kanuba>
expose the symbol table of the compiler.
<kanuba>
Nothing stops you from having 1 package for all files, or multiple packages for 1 file, in CL.
<kanuba>
Again, packages just contain symbols.
<yottabyte>
I see
<kanuba>
Systems are not part of the language proper (the ANSI standard), but are provided purely through a library (asdf).
<kanuba>
Packages are very much a part of the language though.
<yottabyte>
wow
slyrus has joined #commonlisp
<yottabyte>
when I build the system with C-c C-k, I get a fasl file, do I gitignore that?
<kanuba>
It is advisable to, since it is meaningless to other users, even if using the same CL implementation.
<skin>
Yeah
X-Scale has quit [Quit: Client closed]
<kanuba>
That is not "building them system" though. It is calling COMPILE-FILE.
<kanuba>
asdf systems are actually never compiled, but loaded.
bjorkintosh has quit [Remote host closed the connection]
<skin>
TIL
<kanuba>
At least not by asdf itself. You could invoke the compiler as part of the load process
<yottabyte>
so if I download some repo from github that has a system defined in a .asd file, and I load the system, if I don't have its dependencies, say like "alexandria", will it automatically get them for me, or do I need to quickload them (or something) one by one?
<skin>
yeah, quicklisp or ocicl
<yottabyte>
wow. it would be nice if something just did that for me
<bland>
QL does do that for you
slyrus has quit [Ping timeout: 260 seconds]
<yottabyte>
oh
<yitzi>
ASDF's default LOAD-OP load the compiled product of COMPILE-OP. So yes, ASDF compiles systems because that is prerequisite of loading.
<kanuba>
What I meant that, was that asd files are only ever LOADed, never COMPILEd. You can exploit this and store variables you never want in the compile cache, by writing code in the asd file to do so.
<yitzi>
Yes, the ASD file is only LOADed, but the components are usually COMPILEd.
<yitzi>
And putting code in the ASD that your package depends on is not good. ASD files are loaded even before or when ASDF:LOAD-SYSTEM has never been called.
<yitzi>
I have seen plenty of systems do it, but you should not be modifying *features* or stuff like that in the ASD.
varjag has joined #commonlisp
<thuna`>
I tried to revamp the way LOOP is indented in SLY. It's semi-working right now. If anyone wants to try it out your feedback would be appreciated: https://github.com/joaotavora/sly/pull/642
<yitzi>
Are you really putting the first form after DO on its own line?
josrr has joined #commonlisp
<thuna`>
yitzi: The provided snippet doesn't make it look great but with "when (here's something I used to botch) do (here is a body) (here's more body)" it makes more sense to have both compound forms as their own lines
<kanuba>
I disagree
<paulapatience>
I always line up the forms beside the DO, even if there are more below
<kanuba>
It makes more sense to indent the second in accordance with the first, which should be on the same line as DO
<yitzi>
Yeah, that is not a style that is anywhere I have seen. The ANSI spec shows a specific layout for DO
<thuna`>
The additional indentation matters in places. Regardless, this is a simple example used to demonstrate the problem.
<kanuba>
That is much more expected. Vertical space is a resource, too, discounting the fact that it just reads easier.
<thuna`>
yitzi: That is a single example where keeping the first compound form on the same line as `do' does not have the problem of the line being too long
<yitzi>
The do is like a &body form
<thuna`>
In https://0x0.st/Xc_I.txt if you believe the second `when ... do' is better then the first then you are of course free to do so but I disagree vehemently.
<paulapatience>
Just put DO on the line after WHEN
<kanuba>
I disagree with DO being hidden in the same line as WHEN, to be fair. So yes, I agree that the second is better, if I ignore that fact.
<paulapatience>
That's the most common style in my expeience
<zyd>
thuna`: i take full credit for sending you into this loop indent rabbit hole
<zyd>
:^)
<yitzi>
Yeah, no one has ever defined miser newline in LOOP. That is the actual issue.
slyrus has joined #commonlisp
subhuman has joined #commonlisp
<thuna`>
zyd: Haha, I'll be here for a while, I'm afraid :)
<yitzi>
And typically primary forms are indented 4 spaces if they don't fit on the line. DO with a space is shorter, which is why it isn't done.
<thuna`>
4? Body forms are indented by 2, not 4, and same-line-as-do is 3
<yitzi>
I meant that body forms are lined up.
<yottabyte>
bland: it appears to not work for me. I put depends on cl-bcrypt in my asd, it loads fine, then I go to C-c C-k my file that has calls to cl-bcrypt, and it gives me a compilation failure error saying Package CL-BCRYPT does not exist.
<yottabyte>
idk if this is the common strategy though. load the asd file, then the files one by one/
<thuna`>
And while adding a newline before DO is indeed the right thing to do in this situation, an indenter can't say "just don't do this", it needs to have *some* opinion on what the indentation should be, and I hope my example demonstrates that this is tricky
<yitzi>
thuna`: and the primary form in PROG1 is kept on the same line, if it can't then it is indented by 4.
<thuna`>
yitzi: That falls under &special indentation, not &body, which is how I conceptualize DO being
scymtym has quit [Quit: Application exit]
<yitzi>
Ok. You've got your opinion.
<kanuba>
It would be quite annoying for something like (destructuring-bind (...)\newline<2spaces>\newline<2spaces>). Code would become so much more difficult to read.
synchromesh has quit [Read error: Connection reset by peer]
<kanuba>
(the first should be 4)
slyrus has quit [Ping timeout: 256 seconds]
synchromesh has joined #commonlisp
<thuna`>
Yes, the first line is still 4. DESTRUCTURING-BIND has two &special indented forms, followed by &body, DO is like PROGN, in that it only has &body
<_death>
yottabyte: likely you don't want to "load the asd file", but your system, i.e. (ql:quickload "mysystem") which loads the asd file in order to get a system definition and load the dependencies.. you would also have your file mentioned in the system definition so that it loads it for you as well
<yottabyte>
wow, okay, I'll try that. is that all you do every time and then you do don't need to manually load all of the individual files? you can just start calling functions?
<kanuba>
yottabyte: Right, taking into consideration package qualifiers.
<_death>
yottabyte: yep.. also if you have third party code that you tend not to change and takes a long time to load or that you want to always be around, you can save an image to a file and tell sbcl to use that via command line option.. you then need to maintain the image whenever you change or update this third party code
<_death>
yottabyte: but your system should still mention all dependencies regardless