<mason>
beach: I think you'd be doing the community a service by finishing that Land of Lisp review.
<mason>
Down side, this'd be like submitting a patch fixing code that's not in fact free software.
<beach>
I totally agree. The problem is that there are so many more things that would benefit the community if I finish them.
<mason>
That too.
<beach>
In the past, I have suggested that some members of the community take on some of the other tasks on my list, but there are no takers, which I perfectly understand. Everyone is busy with other things. Some people are working on the list of suggested programming projects, which is good, but at this pace, it will take a very long time.
<beach>
And, as I have pointed out in the past, the problem is not money. I am sure we could gather up a reasonable amount of money if that would help. But the problem is that there are very few people who are both qualified and available.
<mason>
Mm, I'm not there yet in terms of being qualified, but I feel like it's inevitable since I've decided this is the way I want to go with the kids' learning.
<masinter>
beach: what's on your list?
<beach>
mason: Sure, that's a good thing. So not only will you be qualified, but we will have two more young people! :)
<mason>
Programming is programming, so I figure it's just a matter of my finding a style I like and becoming a chameleon, and otherwise writing out algorithms as normal.
<mason>
What's funny is that I've been dabbling since the early 80s when a friend sent me a copied magazine article about Lisp. I am a tenured newbie.
<beach>
Interesting.
<masinter>
it's not clear yet what your goal is ultimately
<mason>
masinter: I think he wants to invigorate the community by making good tooling available.
<masinter>
I have the same problem
<mason>
Not that beach can't better answer himself, but I wanted to share an outside perspective.
<beach>
masinter: I think I wrote that on the page in question; a complete Lisp OS.
<beach>
masinter: If there is anything that is not clear, I would like to know, and I'll try to clarify.
<masinter>
there were a couple of lisp operating systems with half of those things
<masinter>
interlisp and genera
<mason>
masinter: How much early Lisp stuff was properly free software?
<mason>
Lisp predates the concept and the formal licensing.
<beach>
masinter: I know. And as I have also pointed out, Genera would not be a good thing to connect to the Internet.
aartaka has joined #commonlisp
<mason>
Anyway, I'll be back. Must go AFK a bit, shocking though the concept is.
<masinter>
just from a software engineering point of view, people will have trouble seeing the end of the tunnel... are there some things that will be valuable by themselves even if nothing else is?
<beach>
masinter: Two things: First, I am a researcher, so I don't care much what people think. My goal is to demonstrate the feasibility of such a thing. Second, yes, lots of the things I suggest would be very useful in a more traditional IDE for Common Lisp.
<masinter>
if you want people to help, it helps to care what they think
<beach>
Then I have to decline the help I guess.
<masinter>
we already demonstrated the feasibililty of a entirely Lisp OS, 30 years ago
<beach>
Good to know.
<masinter>
so your goal must be greater
<beach>
Yes.
raeda has quit [Ping timeout: 246 seconds]
weary has joined #commonlisp
raeda has joined #commonlisp
Guest74 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<weary>
beach: > but there are no takers
<weary>
don't some of those examples have prior (CL) art, though?
<beach>
weary: The "no takers" referred to my suggestions for maintaining independent repositories of modules that were initially developed as part of the SICL project, such as LOOP and FORMAT.
<beach>
weary: What "examples" do you refer to that have prior art?
<beach>
Like I said, there are some people working on the list of suggested programming projects.
<masinter>
i'd love to have a conforming implementation of LOOP
<Guest74>
Does anybody know anything about lispscript and where to find it?
<beach>
masinter: SICL LOOP currently has a problem with the AND LOOP keyword. Otherwise, it is more conforming that the one used by most implementations.
<masinter>
i was hoping it would only use cLTL1
<beach>
Oh, no. SICL modules use the full Common Lisp language, for reasons that I think I explain in many places.
igemnace has joined #commonlisp
rainthree has joined #commonlisp
<weary>
beach: what immediately came to mind was the assembler, but i'm not so sure after reading your blurb on your ideal, so i waive the whole thing
<beach>
Of course.
<weary>
masinter: isn't a big problem with cltl1 as a target that cltl1 implementations tended to be somewhat inconsistent?
<beach>
Most people think of an assembler as taking some assembly-language input and creating an object file. But those things are so Unix-y, which is what I am trying to get away from.
<weary>
what's your take on comfy?
ttree has quit [Ping timeout: 244 seconds]
<beach>
weary: Can you elaborate on that question, and tell whom it is for?
<masinter>
weary: CLTL1 let you write portable code if you were very careful
<weary>
beach: it was henry baker's idea of what an assembler should be. i thought it was pretty interesting.
<masinter>
weary: i dont know anything about comfy
<weary>
(and the question was for you, beach)
<beach>
I also don't know about comfy.
<weary>
oh, interesting. i'll see if i can find the paper; i probably have it somewhere on my disk or in a search engine archive.
<weary>
masinter: what's very careful look like, with those old implementations?
<masinter>
weary: don't do anything that "is an error"
<rotateq>
akoana: Don't know if he's around now and hope it's okay if I answer: "SICL implements Common Lisp".
<akoana>
rotateq: ah, thanks!
<rotateq>
So you have a corecursive acronym like with GNU.
<beach>
akoana: It used to not mean anything, but phoe decided on "SICL Implement Common Lisp".
<akoana>
beach: thanks, I see :)
<edgar-rft>
Spark-Ignited Common Lisp
<beach>
minion: What does SICL stand for?
<minion>
Schlenter Inestimability Common Lisp
<White_Flame>
Such an Interesting Choice of Language
mrcom has quit [Quit: Leaving]
mrcom has joined #commonlisp
* akoana
mistakenly thought of an allusion to the Système international d'unités
<beach>
I never thought about that connection.
karlosz has quit [Ping timeout: 246 seconds]
<akoana>
hmm, I probably got a victim of pareidolia :)
* Nilby
thinks pareidolia is a great ability, not a malady
<ecraven>
hm.. so one lineage of pretty printing is gprint/pp/xp, but are there any successors of GRIND too? or is pp just superior to that?
treflip has joined #commonlisp
treflip has quit [Remote host closed the connection]
treflip has joined #commonlisp
totoro has quit [Ping timeout: 265 seconds]
<beach>
ecraven: Is your question just about computing history, or do you have any other reasons for it?
karlosz has joined #commonlisp
yewscion has joined #commonlisp
karlosz has quit [Ping timeout: 244 seconds]
karlosz has joined #commonlisp
<ecraven>
I want to write a pretty-printer for some variants of Lisp ;)
<ecraven>
(at this point zetalisp, interlisp, Scheme)
<beach>
Oh, OK. So Inravina won't work then.
<ecraven>
well, it might, with changes.. that's why I'm looking into how pretty-printers work ;)
<beach>
I see.
<ecraven>
this description of GRIND seems interesting, but from what I've gathered this is not the approach that all the current pretty-printers take? https://dspace.mit.edu/handle/1721.1/5797
karlosz_ has joined #commonlisp
<beach>
The Common Lisp pretty printer is specified in some detail. The description was very hard to understand for me when I first read it, but it's there.
<ecraven>
is the *effect* specified, or the actual algorithm used to lay out the text?
<phantomics>
A while ago I was looking into the indent algorithm used by Emacs for Lisp text, but there don't seem to be many docs outside the Emacs source itself
<ecraven>
ah, that picture looks familiar, either the gprint or the pp paper
<beach>
ecraven: yes, it's from one of those.
<beach>
phantomics: In my opinion, what Emacs does (or even slime-indentation) is not a good thing to emulate.
karlosz has quit [Ping timeout: 244 seconds]
<phantomics>
beach what do you think is preferable?
<beach>
Something that understands the code a bit.
<beach>
I have given this example several times, but here goes. Try typing (let ((hello<NEWLINE> and see where the cursor ends up. Now try (let ((prog1<NEWLINE> instead.
karlosz_ has quit [Ping timeout: 244 seconds]
<phantomics>
Different places, I see
<beach>
Emacs has no way of figuring out that PROG1 is not a Common Lisp operator here, but a lexical variable.
<phantomics>
Right, I have noticed stuff like this before
<beach>
And there is not a whole lot of things you can do to fix the problem.
<beach>
The fundamental idea is broken.
<ecraven>
I've been thinking this about auto-completion too... if I auto complete foo inside (let ((foobar 1)) (foo| it really isn't black magic to expand that to foobar...
<phantomics>
Slime has some ability to infer things from macro definitions, the &body tag for example will influence indentation of macro args
<beach>
ecraven: The technique we (me and scymtym) are (very slowly) working on would work.
<phantomics>
To fix it you'd need some advanced syntax analysis; that's that you're working on?
<beach>
Yes.
<beach>
The buffer is read using READ (in the form of a highly configured Eclector), and then submitted to something that resembles the first phases of a compiler.
<beach>
READ is the only true syntax analyzer that works for Common Lisp.
<ecraven>
beach: anything I could read about that technique?
<beach>
There is an ELS paper about using READ. Let me see if I can find it...
<phantomics>
Makes sense, creating a parallel analyzer would be a colossal undertaking with a moving target
<ecraven>
yea, that's what I was thinking, you need to actually analyze the full form, not just look at the s-expression symbols
<beach>
phantomics: Incremental is good enough. Parallel is not a requirement.
<phantomics>
By parallel analyzer I mean something that is not actually the Lisp reader but infers meaning from Lisp forms like a kind of partial reader
<phantomics>
You would have to build a highly complex system that follows the functionality of the reader, it would be a ton of work to upkeep
<beach>
phantomics: We are pretty confident we know how to do it.
<phantomics>
As you described, using the reader itself makes sense because it's already built to read Lisp code
<rotateq>
Hopefully people who use "modern" IDEs won't think again they had it all the time with their live compilers.
<beach>
Maybe scymtym can give you links to some of his demos.
treflip has quit [Ping timeout: 246 seconds]
<beach>
phantomics: Exactly.
<phantomics>
Aside from that, beach I've seen you mention the goal of creating a new Lisp IDE a few times, I'm interested to know some of the ideas behind it if you have a minute
<phantomics>
Since I've done some work of my own in the direction of novel Lisp IDEs
<beach>
rotateq: The situation is simpler for most programming languages. They may have reserved words, and they probably don't have reader macros or arbitrary read-time evaluation.
<rotateq>
phantomics: Ah you mean Second Climacs?
<beach>
phantomics: Sure, I have time.
<phantomics>
Is that what the project is called? Second Climacs?
<beach>
That (or something similar) would be the editor part of the IDE.
<beach>
And Clouseau would be the inspector part.
<rotateq>
beach: Indeed, so they don't really (have to) distinguish read and compile time, but everything has its price to pay in the long run.
<beach>
Then there is the debugger, the backtrace inspector, etc.
<beach>
rotateq: Are you saying we can't do it?
<rotateq>
Right, a better debugger is needed, as you've mentioned at some point.
<rotateq>
beach: Of course not! :o
<beach>
And as I have written in another paper.
<beach>
It is not that a "better debugger" is needed. It is that a "debugger" is needed, as opposed to a "backtrace inspector when things already go wrong".
<beach>
So Second Climacs already does the incremental READ thing. But I need to figure out how to compute indentation in a reasonable way. I am still working on that. When that is done, Second Climacs should already be better than Emacs for editing Second Climacs code. But I am busy with other things right now.
<phantomics>
I'll need to build those .tex docs to see all the features, but my impression is that you're modeling the UI after Emacs and the main areas you're focused on developing are concerned with better interactive development, is that accurate?
<phantomics>
My main concern with incremental READ is that it may cause perceptible delays for indenting some lines due to the complexity of the reading process
<beach>
phantomics: I want to make the user interface flexible enough that you can make it look like VIM if you like. But I can't work on everything, so I have been working only on the part that looks sort of like Emacs.
<rotateq>
phantomics: And with McCLIM, which does some things differently than Emacs.
<beach>
phantomics: I don't think you need to worry about that, given our incremental technique. Plus, you can read a huge file these days in a very short time, should that occasionally be required.
<beach>
phantomics: But yes, I am not attempting to make an Emacs clone. I want to concentrate on the experience of editing Common Lisp code.
yewscion has quit [Read error: Connection reset by peer]
<ecraven>
beach: can your reader read comments? I sometimes wonder whether the old (* ..) that interlisp uses for comments wasn't preferable, in that it would *survive* the reader :)
<beach>
Stuff that is currently in Emacs, such as "magit", should preferable be written as independent CLIM applications anyway.
<phantomics>
My project to create a new CL development interface is Seed, if you've seen it, and its aim is to create a new, more universal way of interacting with CL code
<ecraven>
beach: well, emacs is "the operating system", so with a lot of squinting they *are* applications ;)
<beach>
ecraven: Of course. Eclector was designed to be able to read material that is usually skipped.
<ecraven>
thanks, I'll look at eclector too ;)
<beach>
phantomics: I have not seen it. Sorry.
<beach>
What is special about it?
<phantomics>
My takeaway from the current state of CL UX is that it needs a more flexible interaction paradigm, my answer to this was to create a "navigational interface"
<phantomics>
Seed is also intended to be frontend-agnostic, its initial implementation was as a web application
<phantomics>
It has the ability to present a graphical interface to code structures; code can be presented in a tree-grid format as well as having spreadsheets serving as the frontend for arrays on the backend
<phantomics>
It's built around the concept of "atomic identity," where a component seen on the frontend corresponds to an atom or form on the backend. Forms can have special interface rules associated with them
<beach>
That sounds very different from what we have. I would have to try it out to determine whether it is something I would want to use.
pve has joined #commonlisp
<phantomics>
One simple example of a special interface rule is a system I wrote to generate CSS web styles. The atoms that specify colors like "#FFFFFF" are presented as color pickers on the frontend where you can click and get an RGB color picker
bilegeek has quit [Quit: Leaving]
karlosz has joined #commonlisp
<phantomics>
The other aspect of this is that as much of the interface as possible is designed to use navigational commands
<phantomics>
For example, you can use directional keys to move around in the code. If you hold down the 'C' key, that puts you in clipboard mode. Pressing C→ copies highlighted text to the clipboard, and pressing C← pastes an item from the clipboard into the buffer. Having as many commands as possible mapped to navigational concepts I find more intuitive than the many arbitrary commands in Emacs
<beach>
Maybe you could create a presentation for the Online Lisp Meeting, where you show how it works?
<phantomics>
Something I'd like to try with the new edition is an ncurses frontend. Would be fun to implement with April, way faster than a web app and accessible over SSH
treflip has joined #commonlisp
<beach>
Thanks!
karlosz has quit [Quit: karlosz]
aartaka has quit [Ping timeout: 256 seconds]
ttree has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
kpoeck has joined #commonlisp
<ecraven>
phantomics: thanks, that sounds interesting ;)
random-nick has joined #commonlisp
lucie22 has joined #commonlisp
lucie22 was banned on #commonlisp by ChanServ [lucie22!*@*]
lucie22 was kicked from #commonlisp by ChanServ [Banned: spamming links]
irc_user has quit [Quit: Connection closed for inactivity]
trokotech has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
trokotech has joined #commonlisp
sander has quit [Quit: So long! :)]
sander has joined #commonlisp
causal has quit [Quit: WeeChat 3.5]
dBc has joined #commonlisp
tyson2 has joined #commonlisp
lisp123 has joined #commonlisp
Guest97 has joined #commonlisp
<Nilby>
I really like phantomics' structure editing approach. It elides the whole problem of the code having errors. But I note that you still need the old fashioned free-form text editing for entering comments/docstrings.
orestarod has joined #commonlisp
<phantomics>
Something I may not have shown in that video is that there is a special commenting mode for Seed, comments are a kind of metadata a form can have
szos has joined #commonlisp
<Nilby>
also maybe you have enough requisite charisma to be a "lisp cult" leader, and get coding followers :)
<beach>
phantomics, ecraven: That last link from scymtym shows what Second Climacs can do in terms of incremental analysis, though I think most of that code is not in the repository.
scymtym has quit [Ping timeout: 246 seconds]
Brucio-61 has quit [Ping timeout: 244 seconds]
<phantomics>
beach: I see, interesting, the Inkscape video?
<Josh_2>
Good mornin'
Guest97 has quit [Remote host closed the connection]
Guest97 has joined #commonlisp
scymtym has joined #commonlisp
Bike has joined #commonlisp
VGaranja has joined #commonlisp
<Guest74>
phantomics: I think we should have a term protocol that you can write your interface to. Then you don't have to be tied to some C library, which could still be used if you implement the protocol for it, or someone can do pure lisp and output escape sequences, while someone else can implement it for a gui.
<phantomics>
Guest74: Talking about ncurses? It may not actually be necessary
<phantomics>
Basically, what I need for terminal interfaces is 1) a way to find the dimensions of the screen and 2) a way to register pressed keys
<Guest74>
ncurses definitely isn't necessary. Just saying we should have a term interface that is easy to write to and can output to many targets both on console and gui.
cage has joined #commonlisp
<phantomics>
My use of ncurses via April basically completely bypasses all of its features like menu display, etc. I do all the generation of character graphics using April and just output those to the screen
cage has quit [Remote host closed the connection]
<phantomics>
Something I have yet to confirm about ncurses is whether reassigning characters in part of the screen causes all the characters onscreen to be rewritten under the hood
<beach>
phantomics: I don't know what Inkscape is.
<Guest74>
so you just use the basics? LIke clearing screen and positioning? That'd be the easiest part of the protocol.
<beach>
I am sure you are right, but what I wanted you to see was the interactive parsing of Common Lisp text.
<beach>
s/interactive/incremental/
<phantomics>
Nilby: but when it outputs changes is it able to overwrite just certain characters in the middle of the screen?
<phantomics>
beach: Saw it, neat how it can diagnose problems with rational and complex numbers
<Nilby>
phantomics: yes
<Nilby>
phantomics: sometimes it has move the cursor there first of course
<Guest74>
I really dislike when an editor will change the colour of a bunch of code just because I place an open " | or some such on the line above.
epolanski has joined #commonlisp
<beach>
phantomics: Sure, but that's just what a compiler does. The important thing here is that the compiler is run at typing speed. No need for C-c C-c before seeing it.
<phantomics>
Nilby, I see, it's as if you moved the cursor there and entered the new characters. To replace ncurses I would need to implement that logic then, April could make it relatively straightforward
<phantomics>
Apart from that, would just need a way to find the screen dimensions and register typed characters
<Nilby>
phantomics: unfortunately it's a bit tricky, because terminals a weird especially with unicode
<Nilby>
s/a/are
<phantomics>
And ncurses has logic to handle all those cases
<Nilby>
phantomics: it mostly works
<Guest74>
I was thinking of a stream interface, but the only way I could think of sending commands over that is using ascii escape sequences.
dmc00 has joined #commonlisp
<Guest74>
i.e. I don't see why *terminal-io* can't actually be io on terminals.
<Nilby>
Guest74: you can have terminal object which is a stream but has more methods
<Guest74>
true. but for just outputing to a real term the controls are going to be used anyways.
<Nilby>
Guest74: my *standard-output* can print in color and clear the screeen
<Nilby>
Guest74: not necessary
<Nilby>
Guest74: what is a real terminal? it can be in lisp
<Guest74>
a real terminal would be like a real physical terminal.
<Guest74>
but it doesn't matter what the term is since that would be the whole point of a protocol to deal with terms.
<Nilby>
heh. does anyone have such a thing? i gave mine away years ago
<Nilby>
a vt100 is actually very horribe
<Guest74>
I just think it would be nice to have a protocol so that when someone want's to make a simple program they don't have to try and figure out how to choose from the the piles of software trying to figure out what's modern, updated, dead, and they're program doesn't have to die whenever the library they chose dies.
<Guest74>
s/they're/their/
vats has joined #commonlisp
<Nilby>
Guest74: i agree, but who's going to work out what of the at least 3 lisp terminal protocols i know of. i'm not good at that and worse i don't want to have to worry about coordination/review to add a method to my protocol
<Guest74>
like all things based on generics you can add whatever you want for your own personal use.
<Guest74>
I think that a term protocol should allow anything that has to do with io and control of terms.
<Guest74>
There's a few ffi term libs and a few that output escape sequences, and then some windowing stuff from at least two people.
<Guest74>
I'm a believer in mechanism, not policy.
rainthree has quit [Ping timeout: 240 seconds]
<mfiano>
Happy weekend everyone! Any interesting projects being worked on? I'm trying to polish up my command line application for release.
vats has quit [Ping timeout: 250 seconds]
<Guest74>
welp, it was 'interesting' that I thought an "ascii" format from adobe would be simple to implement. they really led me on with the easy AFM format.
rainthree has joined #commonlisp
<contrapunctus>
mfiano: what application is that?
<mfiano>
A fairly niche backup program that replicates incremental changes of ZFS snapshots to N target machines, with configurable retention policies.
cage has joined #commonlisp
<contrapunctus>
I see...I've been working on my CLIM code browser prototype.
<Josh_2>
Sounds cool mfiano
<beach>
Guest74: Are you using "term" to mean "terminal"?
<mfiano>
Thanks. It's fairly complex and I've been running it on a test subnet of VMs for a few days to get it ready.
<Guest74>
beach: correct
<beach>
At first I thought you were referring to terms as in expressions. Confusing.
<mfiano>
Distributed networking applications have all sorts of edge cases to work out.
<beach>
Why not use "terminal" instead?
<phantomics>
Guest74, there are ncurses binding libs like croatoan, but I think what Nilby's looking for is a terminal interface that's mostly Lisp without needing to depend on a large C library
<phantomics>
I've been working on a technique to drastically speed up operations on arrays
<Josh_2>
mfiano: is this a commercial application?
<Guest74>
beach: term is generally understood when talking about terminals.
<mfiano>
Josh_2: No
<Nilby>
i already have a terminal interface, but it sadly requires re-writes of a number of the obsolete portions of CL
<Josh_2>
FOSS?
<mfiano>
All my code is always MIT-licensed to be used in any scenario.
<Guest74>
phantomics: you can have all lisp with zero c library. but my point is, if we have a protocol to write to it doesn't really matter which library anybody uses to implement the protocol.
<phantomics>
mfiano, did you say that some of your challenges with game engine design in the past came from operations like real-time matrix math being slow?
<Josh_2>
phantomics: if that is the case maybe the new SB-SIMD would solve that
<phantomics>
Josh_2: SIMD is the fastest for some cases doing just simple arithmetic. But if you're doing more complex array transformations, there's actually a faster way, since SIMD array transforms, no matter how fast, require intermediate data to be written into memory
<Josh_2>
zoom zoom
<Josh_2>
I know nothing about these things :sunglasses:
<Guest74>
maybe a visual interface to apl with floating icons of all the symbols with tooltips of what they mean that you can just drag and drop might help sell it.
<mfiano>
phantomics: No, the math can be written very efficiently. The problems start to appear in very large games with thousands of objects that need to have physics computations applied to them each frame. If you needs are not that complex, CL is in my opinion the best language for writing very architecturally complex applications such as a game engine. The problem with game engines is there are too
<mfiano>
many, because people try to write a general-purpose game engine, which doesn't really work in practice. A game engine is nothing more than a set of design choices that someone made for you and affects the flow of data between the CPU and GPU, which is very application-specific. I am of the opinion that a game engine should be born out of a specific game idea, not a one-size-fits-all approach.
<Guest74>
This is why my choose your own adventure game engine is like 30 lines of code.
<phantomics>
mfiano: From what I've seen, most of the major game engines take a kitchen sink approach and end up with all kinds of weird non-deterministic behavior. Raylib looks like an interesting alternative and has a CL binding, though very little has been ported to it from the Raylib examples
<mfiano>
It took me a long time to figure that out, though to be honest, I was never really interested in making a game; I wrote engines mostly to learn about the concepts and complex architectural design.
<mfiano>
And because I don't have a game idea, nor do I want to make a game, I have stopped working on game engines. I am more interested in graphical mathematics and algorithm visualizations.
<mfiano>
I am very much opposed to using raylib, or any foreign code unless it is absolutely necessary (interfacing with hardware on a non-Lisp operating system)
shka has joined #commonlisp
<Nilby>
mfiano: i think the game industry agrees with you. like you wouldn't want to use a mmorpg engine for a tapper game
<mfiano>
I think writing a game in portable COmmon Lisp opens up a lot of possibilities and protects your code from moving target languages.
<phantomics>
Voxels are fun and can apply to both games and math. Would you then favor using something like CEPL/varjo to build shaders directly?
lisp123 has joined #commonlisp
<Nilby>
if only Unity was based on Mirai
<phantomics>
Nilby: the game industry has done the opposite, they've standardized a small set of hyper-complex engines that they use for almost any project unless there's some incredibly compelling reason to do differently
<mfiano>
I don't want to offend anybody, but I don't think either of those libraries work well. varjo in particular parses glsl-spec by the same author to produce its shader code, and that specification is very inconsistent/wrong with the actual specifications in places.
<mfiano>
With complex shader programs, it will generate incorrect code and you will spend a long time debugging problems.
<phantomics>
Indie games aren't immune, thus we get sidescrolling pixel games written in Unity with massive executables and high CPU usage
<mfiano>
I ended up hand-writing a correct and machine-readable GLSL specification in s-expression form for anyone wanting to make a compiler though; I just never got around to it.
<phantomics>
mfiano: I see, is there anything you suggest to quickly get some kind of simple game/realtime graphics going with CL that doesn't depend on a bunch of FFI?
lisp123 has quit [Ping timeout: 244 seconds]
kpoeck has quit [Quit: Client closed]
<mfiano>
I would recommend using SDL2 for interfacing with I/O devices, since it is widely portable and has a stable API. It uses hardware rendering, but if you want more, you can use it simply for its OS-independent native GL-context window handling, in addition to cl-opengl, but I think that part eliminates the "quickly" requirement.
<mfiano>
You can use SDL2 alone and nothing else, to create hardware-accelerated games.
<mfiano>
Very quickly if I might add.
orestarod has joined #commonlisp
<mfiano>
And you get gamepad, sound, etc for free with no other external foreign code. The sad truth is, you need a foreign code when interfacing with I/O devices in an operating system-agnostic way or not. The benefit of SDL2 is it handles all I/O devices on a wide variety of operating systems, and has a very stable API.
Guest97 has quit [Remote host closed the connection]
<mfiano>
I would also direct you to my math library https://github.com/mfiano/origin, though it lacks good documentation, but anyone familiar with linear algebra should be able to understand it.
Guest97 has joined #commonlisp
<mfiano>
It is highly efficient. Infact, it is identical in performance to FFI binding math-fu, Google's SIMD-optimized math library.
<mfiano>
On SBCL that is, which generates efficient code for Origin. I am not sure if this is due to the FFI overhead, but speed is very similar between the two. Origin is very complete and very fast.
<phantomics>
Neat, does origin do any lazy evaluation/operation accumulating? I've tried a bit of cl-sdl2
<mfiano>
No it doesn't close over state to do that. The funcalling overhead would cost in performance. It uses raw specialized arrays for everything, and has a non-consing and consing API. Typically you would pre-allocate your storage and use the mutable API during calculations.
<mfiano>
There are no standard-classes or structs for the math operations.
<mfiano>
There is also its sister project https://github.com/mfiano/gfxmath, which uses generic functions and classes, for when performance is not as much of a concern, but I can't recommend that library yet as it hasn't been battle-tested. Origin has been used in many successful projects for the last 10 years or so, both by me and others.
<phantomics>
Ok, does that mean when doing a matrix operation, like A+B×C-D, that the output of each stage of that operation is written into memory? So in other words, the two intermediate stages between the input and output will need to be written into memory?
<mfiano>
The api is:
<mfiano>
(origin.vec3:+ a b) or (origin.vec3:+! out a b), to mutate a or b, you could do (origin.vec3:+! a a b)
<phantomics>
Ok, so it can either output to a new array or overwrite an existing array
<Josh_2>
How I start game dev in lisp?
<mfiano>
It can, I think I just explained how.
Guest97 has left #commonlisp [#commonlisp]
<phantomics>
But that means that if I do multiple arithmetic ops in sequence, each of those ops _must_ write to memory, is that right?
<mfiano>
THe ! suffixed operators overwrite an existing array. The non-! suffixed operators create a new array.
<mfiano>
You could do (let ((out (m3:id)) (some-op out! a b) (some-other-op! out x y)). In the end, OUT has the value
<mfiano>
err
<mfiano>
You could do (let ((out (m3:id)) (some-op! out a b) (some-other-op! out x y)). In the end, OUT has the value
<phantomics>
But just to clarify, each of those some-op! calls involves writing the elements of the array into memory correct?
<mfiano>
Isn't that what a destructive operator implies; mutating an existing object reference in memory?
<mfiano>
Maybe I am confused by your wording.
<phantomics>
What I've been working on is a lazy evaluation mode for April that composes successive array transformations into a single function. Array elements are passed through the chain of functions without needing to write the intermediate stages into memory. Only the input and output are present in memory.
<phantomics>
I was wondering if you'd considered cases like this. Your origin only does arithmetic, not transformations, but you can do thing like this:
<mfiano>
Yes, well performance comes at a cost.
<mfiano>
The trade-off I made was in favor of performance.
<phantomics>
1+5-3×M
<mfiano>
I have not.
<phantomics>
Compose that to (+ 1 (- 5 (* 3 x))) and apply that function to each element of the array
<mfiano>
I prefer code that reads like math in a math text book, and origin maps well to that.
<mfiano>
It has convenience macros to aid in this too.
<phantomics>
That way, you don't write the intermediate stages into memory. SIMD can certainly be fast but the von Neumann bottleneck adds a lot of time
kpoeck has joined #commonlisp
<mfiano>
Origin is not a general-purpose linear algebra library. Matrices are square and of a finite fixed number of dimensions, each in their own package.
<mfiano>
It is designed for game development where performance is of utmost concern.
<Nilby>
Hmmm. I wonder if one could use compiler macros to do some automatic composing of prefix code
<mfiano>
Lazy evaluation and composition conflicts with that goal.
<mfiano>
Nilby: That would be pretty implementation-specific I would think.
<contrapunctus>
Josh_2: /join #lispgames 🙂️
<Nilby>
Why? It would think it would be more math library specific
<Josh_2>
Yes but I have 0 experience with game dev
<mfiano>
Nilby: Compiler macros may decline to expand.
<phantomics>
Composition will decrease performance? Is it faster to do memory writes for every operation rather than use a composed arithmetic function that can reduce the number of memory writes?
<mfiano>
and you'd likely want access to ClTL2 environments there, which implies a portability library for the implementations that support that extension.
<Bike>
if you're only doing linear algebra type transformations in a fixed dimensional euclidean space you can compose everything into a matrix and thus only do one memory write, right?
<Nilby>
mfiano: true, but if you're making both the library and the macros, you can know when they can expand and not. just like sbcl's notes tell you when it can't do the fast pasth
<mfiano>
phantomics: I can't answer that. There are many ways to write a compiler. Writing an efficient compiler is a difficult task, even for something so narrowly-scoped.
<mfiano>
I think time is better spent using an efficient game math library that exists.
<mfiano>
If you don't need a general-purpose linear algebra library that is.
<mfiano>
If you do, Julia is around the corner :ducks:
<mfiano>
Nilby: what I was referring to is this quote from the standard: "no language processor (compiler, evaluator, or other code walker) is ever required to actually invoke compiler macro functions"
<mfiano>
I shy away from implementation-specific code, so that is not for me.
dBc has quit [Quit: leaving]
<Bike>
relying on them would make your code nonportable, but you don't have to do that. you can just put them in as a bonus that improves performance on some implementations but otherwise has no effect
<mfiano>
Yes, but if we're talking about the purpose of composing math functions in the quest for performance, it is not worth it over mutability that is portable. At least that's my opinion.
<Bike>
oh, i see. since your operations don't actually return the output vector you can't write them composed like you can with the standard destructive functions
<mfiano>
The architecture and semantics of the functions the compiler macros optimize would be different than not using them.
<mfiano>
and that trade-off results in worse performance in the portable case.
<Bike>
like you can't write (some-other-op! (some-op! out a b) x y), which would still be in terms of mutation but also be rewritable with compiler macros
<mfiano>
I have been down this road years ago. Perhaps I didn't try hard enough, but the added code complexity and all the architectural challenges was not worth it for me. Origin was designed for portable performant code for the specific use-case of writing games.
azimut has joined #commonlisp
<mfiano>
Anyway, I'm not really interested in discussing this further. There are many math libraries for Common Lisp, and each has their advantages and disadvantages. I won't discourage anyone from coming up with a new implementation; infact I encourage it. I just don't really need anything more myself, and I should get back to my other project now.
<mfiano>
(I would also consider such a PR for Origin if anyone is up to wading through 10k+ lines of code)
<mfiano>
I think it was 14k last time I checked. I forgot.
Bike has quit [Quit: Connection closed]
<mfiano>
Which standard stream special variable is preferred for write-only log messages to a terminal application? *terminal-io* seems very implementation-specific, so I am considering just *standard-output*. Any suggestions?
<Guest74>
debug-io?
notzmv has quit [Ping timeout: 258 seconds]
<mfiano>
"The value of *debug-io*, called debug I/O, is a stream to be used for interactive debugging purposes."
<mfiano>
Not exactly for end-user application output.
tyson2 has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 250 seconds]
aartaka has joined #commonlisp
frgo has joined #commonlisp
dra has joined #commonlisp
mrcom has quit [Remote host closed the connection]
mrcom has joined #commonlisp
mrcom has quit [Remote host closed the connection]
yewscion has joined #commonlisp
mrcom has joined #commonlisp
mrcom has quit [Remote host closed the connection]
mrcom has joined #commonlisp
<mfiano>
I guess a better question would be, what would be a good way to direct output to either Unix fd0 when running as a dumped executable image, but not include things that would otherwise be written to the REPL in SLIME/Sly? I am writing a trivial, special-purpose logging module for my application, and would like the "trace" level to only show up in the REPL during an interactive development
<mfiano>
environment, levels greater than trace to be appended to a file, and "info" or greater written to Unix fd0. To be specific, I would like to use standard-output differently dependent on if I am in Emacs or if I am running an executable core.
jealousmonk has joined #commonlisp
orestarod has quit [Ping timeout: 244 seconds]
Posterdati has quit [Remote host closed the connection]
mrcom has quit [Remote host closed the connection]
mrcom has joined #commonlisp
tyson2 has joined #commonlisp
rainthree3 has joined #commonlisp
rainthree has quit [Ping timeout: 244 seconds]
ttree has joined #commonlisp
aeth has quit [Ping timeout: 255 seconds]
Posterdati has joined #commonlisp
treflip has quit [Quit: I slep]
karlosz has joined #commonlisp
jolby has joined #commonlisp
Lord_of_Life has quit [Read error: Connection reset by peer]
Lord_of_Life has joined #commonlisp
tyson2` has joined #commonlisp
tyson2 has quit [Ping timeout: 258 seconds]
prokhor has quit [Ping timeout: 240 seconds]
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #commonlisp
<mfiano>
Any format wizards around?
<mfiano>
How can I right justify text with "~a"? Like if I have "Some message: ~a: foo", with argument being either "blah" or "blahblah", I would want it to print:
<mfiano>
Some message: blah: foo
<mfiano>
or
<mfiano>
Some message: blahblah: foo
<mfiano>
So the #\: is aligned at the same column.
<rotateq>
mfiano: When I do (format nil "~10@a" 'foo) I get it aligned right.
<rotateq>
Or I would have said I bet Nilby knows the answer for format magic again from memory. :)
<mfiano>
I suppose I need to do it as another argument so I can figure out the longest "word"
<mfiano>
Rather than a constant directive argument
<rotateq>
Yeah or you give another in between produced control-string as an argument to the ~? directive.
<mfiano>
Ah ~v
<mfiano>
(format nil "~v@a" 10 'foo)
<rotateq>
Oh sure, that one I haven't really used yet.
aartaka has quit [Ping timeout: 276 seconds]
aartaka has joined #commonlisp
epolanski has quit [Quit: Connection closed for inactivity]
<rotateq>
mfiano: but the 'v' isn't a standard thing, or is it?
<rotateq>
Thanks, so I can burn that too into my brain cells. :)
tyson2` has quit [Remote host closed the connection]
<Guest74>
I wish there was a more elegant way to use the same ~v multiple times.
<mfiano>
Yeah the prefix parameter substitution characters are only mentioned in passing, and not documented in the list of directives, because, well, they aren't directives.
karlosz has quit [Ping timeout: 250 seconds]
aartaka has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
kpoeck has joined #commonlisp
orestarod has joined #commonlisp
aeth has joined #commonlisp
rainthree has joined #commonlisp
vassenn has joined #commonlisp
rainthree3 has quit [Ping timeout: 246 seconds]
rainthree has quit [Ping timeout: 255 seconds]
flip214 has quit [Read error: Connection reset by peer]
aartaka has quit [Ping timeout: 240 seconds]
azimut_ has joined #commonlisp
aartaka has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
flip214 has joined #commonlisp
gaqwas has joined #commonlisp
VGaranja has quit [Remote host closed the connection]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
waleee has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Oddity has joined #commonlisp
Bike has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
vassenn has quit [Remote host closed the connection]
irc_user has joined #commonlisp
Dynom has quit [Quit: WeeChat 3.5]
azimut_ has quit [Ping timeout: 240 seconds]
azimut has joined #commonlisp
tyson2 has joined #commonlisp
cosimone has quit [Remote host closed the connection]
<mfiano>
In the debugger, is there a way to restart from a given stack frame with some SLIME magic, if I only have RETRY (current frame) and ABORT restarts available to choose from?
<mfiano>
I would like to recover from this error by rewinding one frame and retrying
<mfiano>
Otherwise I may be in for some pain
cosimone has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<mfiano>
Ah in Sly it is sly-db-restart-frame
orestarod has quit [Ping timeout: 260 seconds]
rotateq has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
random-nick has quit [Ping timeout: 276 seconds]
random-nick has joined #commonlisp
<Guest74>
welp, it's upside down and I'm missing a bit because they'll start a new path relative to where one finished off and I don't yet have a function to return the last point on a path, but at least this shows the parsing, decryption, parsing, decoding and translating are mostly working. https://imgur.com/a/Uiu8bzt