IRC channel logs
2023-01-06.log
back to list of logs
<ArneBab>old: I use org-mode for writing the lecture, so I can put all this setup and ceremony in the appendix and still have fully executable code. <old>I see. I wish I could have had courses like that <flatwhatson><dthompson> I am making UIs for this, though, sort of like Smalltalk's Morphic framework <mfiano>Really appreciate you helping figuring out my problem immediately nobody else could seem to figure out. <mfiano>Spending 3 days just trying to get modules loaded correctly was a bit much for me... <dthompson>flatwhatson: we'll see if I ever get it done! <flatwhatson>yeah i think there's a gap in materials for on-boarding devs, particularly ones who are experienced in other languages and want a sophisticated multi-project workspace <mfiano>Thanks for the idea to document my progress so I can write up a guide some day. <dthompson>... maybe if I can ever get this damn schemeish -> glsl compiler working I'll go back to the UI stuff... <dthompson>well this will be its own thing but yeah that's the basic idea <mfiano>It's genius how it handles shader stages <mfiano>Oh it most definitely is, and Baggers himself mentioned on stream that half way through its design he didn't even know that he was writing a compiler because he never did before. <dthompson>for me the key features I want are type inference, nested functions (with the restriction that there can be no free variables), and multiple return values. <mfiano>why no free variables? doesn't that limit closures? <mfiano>varjo actually fakes HOFs. You can actually pass lambdas around :) <dthompson>yeah I saw that. I don't know if I want to go that far. <mfiano>and it is so very useful in GLSL <dthompson>it's a feature I'll explore if I encounter a situation where it would be beneficial. <mfiano>To be quite honest, after many years of OpenGL, for the last year I've been really happy with SDL ever since it got FRect support. <mfiano>I don't have the time for 3D anyway. <mfiano>I mostly do little 2d algorithm visualizations and generative art stuff <mfiano>ACTION doesn't know when FRect support actually happened, just when he noticed it. <mfiano>I would probably abstract over the two APIs with GOOPs though. I'm not concerned with the minor performance hit for the number of calls I'd typical use. <dthompson>the biggest reasons I want a language that compiles to glsl are: 1) easily embed the code in scheme files without using string literals 2) compile to many GLSL versions 3) have data about inputs and uniforms without having to grovel opengl for it. <mfiano>Being able to dispatch on specific array types like <u8vector> is...what I've wanted for so long <mfiano>Yes I know, it's a main reason I'm here right now :) <mfiano>The biggest advantage in my honest opinion was omitted. <mfiano>Well it falls under #1. By having the unit of macro expansion by a glsl function, you can mix and match scheme calls in different shaders...even different stages. <mfiano>Massive code re-use and organization possible <flatwhatson>you might be able to implement basic closures in GLSL by making them "explicit environment passing" style and using a global array of structs to hold the environment for each call <flatwhatson>but yeah this might be getting into "crazy" territory ':) <dthompson>I'd be concerned about shader performance suffering as a result. <dthompson>I don't want to pay a performance penalty for having a nicer language to write shaders with. <dthompson>so I'll stick fairly close to what GLSL lets you do easily <mfiano>Yeah, and I don't think closures make total sense. <dthompson>multiple return values can be supported in an efficient way, I think. <mfiano>That's getting into turning a parser into a full-blown compiler, too... <flatwhatson>if you want to do something like a (map (lambda (x) (+ x y) ...) then environment capture wouldn't be necessary <mfiano>Well a parser and simple source to source translation into something with a block level symbol table and everything <flatwhatson>also you can't take a function pointer in GLSL so that limits the ability to keep closures as values anyway <dthompson>some restricted set of things might be possible <dthompson>for now I'll be happy to have something that looks kinda schemey that isn't full of mutation and type declarations. <mfiano>I have something you may very much like <dthompson>"ad hoc polymorphism" as the ML people call it, is something I'm trying to have because GLSL has function overloading. <dthompson>and achieving that is a little tricky. gonna keep trying, though. <mfiano>It is the only of its kind afaik. varjo's is just completely wrong and shaders break because of it. <mfiano>It's just sexps. So use it in guile! <dthompson>glsl stuff aside, here's a funky program that fails baby's first type inference: '((lambda (f) (if (f #t) (f 1) (f 2))) (lambda (x) x)) <mfiano>That supports every single GLSL version, and every feature is annotated with versions. <dthompson>I'll have to give that a run sometime. thank you! <mfiano>(You don't want to know how long it took me to cross-analyze like 8 different standards documents to find the differences) <mfiano>It hasn't been useful to me yet, so hopefully it wasn't 2 months wasted :) <dthompson>it looks like it will be a useful reference for when I need to generate code for many glsl versions. <mfiano>I think I realized just how much work it'd be after it took that long just to canonicalize the data for the not-even-written-yet parser, and it'd only fix the 1% of varjo programs that don't work. <mfiano>and decided not, because i'm a lisper, and we folk dont work together with others. <mfiano>which is a dumb pattern. i'm always willing to <dthompson>I think a lot of us in guile land work together :) <mfiano>seams like a lot of nice chatter about what everyone is up to <mfiano>in CL it's like everyone doing their own thing, reinventing their own wheels <flatwhatson>i think having a monument like guix to gather around helps with that <mfiano>I sense a blog post coming sometime this year. Something something about how I was really a Schemer all along, and all my complaints about CL were already solved just across the fence. <mfiano>Makes me look dumb, but hey. Life is learning. <dthompson>I'm signing off for the night. nice chats all! <mwette>I have coded in a number of languages. Scheme is my total fav' <epony>interesting, can you do a singe feature personal favourite from Scheme and/or your comparison criteria summary? <mfiano>Can anyone recommend any notable modules builtin or otherwise that may be useful for writing shell scripts in guile? <mfiano>I am looking for everything and anything one might use for the general shell script. <flatwhatson>mfiano: ports and pipes are the main tools for system interaction <mfiano>Thanks. I see popen used a lot. Seeing what that is about now <flatwhatson>also depending on your use-case, "ftw" ie. file tree walk <mfiano>any third pary libries containing useful utility libraries for doing common higher level operations than system() ? <mfiano>sorry, missing key strokes apparently <flatwhatson>guix provides a number of helpers which are commonly used in packaging scripts <flatwhatson>otherwise it's quite normal to cobble together some project-specific helpers from the super-powered primitives that come with guile <mfiano>I imagine pipelines will be much smaller not having to shell out to stupid things like coreutils 20 times per line <flatwhatson>historically, scsh was pretty popular library for writing shell scripts in scheme, but it's kind of died out <flatwhatson>parts of it have been absorbed into guile proper, but it's almost certainly worth further mining efforts <flatwhatson>i think there are at least two abandoned historical ports of scsh from scheme48 to guile :) <mfiano>Cool thanks...what about any libraries that are essential to debugging/everyday guile dev, like stuff you would include in your ~/.guile ? <mfiano>ACTION hasn't looked anywhere really except flatwhatson and dthompson's repos <flatwhatson>honestly i don't reach beyond what comes with guile's repl. it's worth exploring the built-in commands under ,help <mfiano>Yep I am aware of all that, ok thanks. <mfiano>I try to use ,d a lot, but 90% has no docstrings :( <flatwhatson>yeah, geiser does a better job by linking functions with their info docs <mfiano>didn't set geiser up yet. using conjure to connect to `guile --listen` with vim <flatwhatson>highly recommend getting comfortable browsing the manual and using index lookups <mfiano>the manual has been my bible so far while i finish read TSPL4 <mfiano>Ok, so I'm going to ask the question I've been meaning to ask for over a week. A rumor I heard a long time ago about scheme. <mfiano>Is it possible, in Emacs, to compile an individual macro while a render loop is running, such that any side effects to global state will be seen by the running code? I heard that Scheme is not as good for incremental interactive programming like this, due to something about some philosophy about preventing the image from getting out of sync with the code or something. <flatwhatson>in principle yes, in practice there can be some caveats <mfiano>I assume such caveats would be things like goops class precedence being immutable by default <flatwhatson>a big one is inlining by guile's compiler might cause things you expect updated, to not be <flatwhatson>redefining a record type creates a *new* type which isn't compatible with the previous version <mfiano>That's understandable. They are probably stack allocated structs in C. <mfiano>My end game is to have an interactive graphics coding sandbox, where I can just code and C-c C-c to see stuff. Comes in handy for subtle color changes and things that you can't compare with the couple second disconnect from restarting, or switching to the repl to run something after every minor edit. <mfiano>That's what I do in CL. I'm not sure how doable this would be in Scheme. <flatwhatson>that's an explicit design goal of dave's prototype engine catbird <mfiano>Hmm, how do I pass environment variables to a command that I `exec`? <mfiano>Trying to finalize my guile wrapper... <mfiano>I want to replace the current process with the command `bar`, but with FOO=1 prefixed <mfiano>`exec FOO=1 bar` doesn't work. It's been years since I had to figure this stuff out. <mfiano>ACTION wonders if he needs a wrapper for his wrapper :/ <daviid>mfiano: i think you need to export, before the exec guile ... call, then getenv should see it <mfiano>What if I only want to variable visible to the process that is executed? <daviid>you export in the script itself, i meant to write <mfiano>Ok I'll play around some more, thanks. <flatwhatson>particularly the environ procedure to capture and set the current environment <flatwhatson>iirc there was some discussion of a with-environment helper to simplify this use-case <mfiano>Perfect. Making progress here. Ever see a snail move before? <mfiano>I just have to set up geiser-mode. I have a fallback plan for everything. first guix alternative incase that ever breaks, now vim alternative :) <mfiano>With a little luck I could be starting to write Guile code today <mfiano>daviid: does g-golf support ewmh attributes? <mfiano>I would like to make a small borderless, buttonless window that spans the length of my screen and docks to one of the edges, reserving space for the root window, like various panels/status bar X11 applications <daviid>mfiano, i use the gnome desktop, where you may definitely have decoration less border less windows <mfiano>I do not use a desktop environment <mfiano>I rely on individual applications to comply with desktop standards <mfiano>I am talking about root window reservation <daviid>i think that windows decoration and borders are 'wm' (and maybe composer) 'sensitive', hence i can only tell you that gnome 'listens' to the no-decoration parameter when used, you'd have to try using your window manager - it should work, creating a decoration less border less window and calling 'fullscreen' ... iiuc <mfiano>THe window manager is what responds to EWMH properties that client windows may have set by their applications <daviid>i thought you were refering to the ewm, emacs window manager :) <mfiano>No the desktop standard I said :) <daviid>g-golf will do what the gnome upstream lib you are using offer/does - i am not familiar with this side of EWMH protocol identifiers and if gnome respect thse, you may ask in #gnome <mfiano>Oh, I thought it was just for GTK, not gnome DE <daviid>g-golf is stricktly for gnoe libraries <mfiano>Ok sorry to waste your time. I haven't used GNOME is more than 20 years :) <mfiano>Well it's a GIMP library, which is independent of GNOME. It's GNU <daviid>you may use gnome libraries on any desktop, even on the mac or windows, you don't need to use a gnome destop ... <mfiano>I guess our definition of "gnome libraries" differs is all :) <daviid>it is not independent of gnome, it is the main gnome lib, out of many others ... <mfiano>I consider it the GIMP toolkit. Nowhere does it say it is a gnome library. It is used by gnome like any other application may do so, yes. <daviid>mfiano: fwiw 'G-Golf is a tool to develop fast and feature-rich graphical applications, with a clean and recognizable look and feel. Here is an overview of the GNOME platform libraries, accessible using G-Golf.' - <mfiano>Yes those are libraries installed on a GNOME platform <daviid>the title of the page: An overview of GNOME platform libraries. <mfiano>Yes, you are reading too literal. <mfiano>Curious, is English your native language? <mfiano>Let me think how to describe this ambiguous language we are diagreeing over. <daviid>mfiano: please, talk to the gnome team, not me :) <mfiano>The GNOME team is correct, though. There is nothing to talk about with _them_. <daviid>gtk, as libadwaita, and all others, are GNOME libraries <mfiano>Can you define the phrase "GNOME library"? <mfiano>Ok, that is only one definition. The definition I was using is the one I am assuming the GNOME website is using, which is not that one. <mfiano>It is a library that is built by GNOME" <mfiano>English is ambiguous. Context is key. <mfiano>Now you can see why I was confused by your description lacking context :) <mfiano>well, I was genuinely curious. I guess I will not ask anymore about it then. <daviid>mfiano: the link i posted says: Libraries - An overview of GNOME platform libraries. User Interfaces - GNOME’s user interface libraries ... GTK, libadwaita ... the left part of the menu also says 'platform components ...' fwiw, that was my last attempt to convince you to change your perception that gtk is not a gnome library :) <mfiano>I'm back. Had to step away for a breather. <mfiano>It's looking like maybe I can code some guile after lunch. <mfiano>I have a couple dozen shell scripts to port over. Some that were written very long ago, and some that should never have been written in a scripting language, but all of which would be perfect for interactive programming with support for various programming paradigms. I want to retire from real shell scripting from good. Is this possible? :shrug: <mfiano>I figure those will be small isolated practice runs learning Scheme. <lilyp>From personal experience, interactive programming is nice for experiments, but not so nice if you want to build actual software <mfiano>That has not been my experience. Infact, like dthompson, I (and a few others I work with) have a game engine we have been developing for about 10 years that allows completely interactive game design, just by redefining our various DSLs in Emacs with C-c C-c, but which does not affect a deployed game in any way (actual software) <mfiano>Maybe this is different in Guile and there is something preventing this from being the case? This is what I was asking about earlier. <mfiano>This is what I was talking about earlier with flatwhatson <mfiano>This is getting mysterious. I want to know why lilyp thinks that, because it may be related to the old rumor I heard. <lilyp>I don't think this is anything unique to Guile. In fact, my personal experience comes on one hand from Emacs and on another from hearsay about R. <lilyp>One pretty easy way to declare Emacs bankruptcy is to interactively develop your init.el. You will have references to variables that used to be there, but then when you restart Emacs are no longer there. <lilyp>I think the big takeaway here is to run your produced software through some checks before committing, which is good practice anyway (as is version control in general) <mfiano>I think the first thing I did was git init, create a gitignore, and a pre-commit hook to run the tests beforehand. <mfiano>Ok, it looks like my crazy shell scripts and environment are cooperating with Guile now. I can finally start writing some code! <mfiano>Quick question abut the module resolution algorithm: If I were to do (use-modules (foo)) and somewhere on my %load-path I have a directory "foo" at the root, does Guile look for some default file, or do I always have to construct the spec to map to a file? <civodul>mfiano: Guile doesn't look for some default file under foo/ <civodul>it looks for foo.scm, but not just ".scm": any of the extensions in %load-extensions <mfiano>Ok, I knew the last part and I was pretty sure about the first part, thanks. Thanks rules out my idea anyway to clean up my scripts, so I will head out for the night. Thank you everyone. <lilyp>guile has no __init__.scm and if it did, you'd get (foo __init__) <stis>civodul: did you see my exploration of one shot continuations? <civodul>stis: no, i didn't; do you have a pointer? <stis>I get 2Million normal iterations in guile, with a modified guile I get 55Million. Python 3 does 30-35Million <stis>the modified verison using one shot continuations <stis>The comparison is with the python-on-guile and with or without one shot conts <civodul>stis: so the goal is to avoid copying the stack on abort and when invoking a continuation, right? <civodul>i don't see how that's specific to one-shot continuations though <stis>what I mean is that it this cont cant be run twise <stis>but maybe that's the wrong termonloligy <stis>it's just adds separate stacks and avoid copying <stis>If you like I can try publish the modified guile I have <stis>It's hard to get it stable though, although I can run some tests <civodul>i understand what "one-shot" means, but i don't understand how the linked-stack trick is specific to one-shot continuations <stis>civodul: because when yo reinstate it, and run it the stack is modified (you do not copy the stack). So when you execute it again it's not the same continuation as the world has moved on <stis>but the object can be called multiple times, that's true <stis>Anyway I find it interesting that those perfroms so well compared to delimited continuations <civodul>well these are delimited continuations, no? <stis>It'd actually better to view is as green threads but delimited continuations with their own stack may be an ok interpretation <stis>I got JIT working and VM I not exceptions over the boundaries though and similar no working delimited continuation yet <graywolf>When would I use load and when primitive-load? <lilyp>snek later tell graywolf the canonical example of (primitive-)load is reading user configuration – i.e. when you can't rely on the module system to do what you want. As for the differences between the two, consult the manual and experiment <lilyp>sneek later tell graywolf the canonical example of (primitive-)load is reading user configuration – i.e. when you can't rely on the module system to do what you want. As for the differences between the two, consult the manual and experiment <old>sneek sometime forget things <stis>x = (x for x in range(100000000)) <stis>print(sum(f(f(f(f(f(f(f(x))))))) <stis>this one is always 2s in python-on-guile but much much slower on python3 <stis>print(sum(1 for x in range(1000000000))) <stis>interestingly, this takes 1.6s in python-on-guile, but 27.9s on python3 <mwette>stis: are you quoting from stock guile or with your own updates (e.g., modified prompt)? <stis>the yield stuff needs a modified guile, but the last speedup does not involve any generators and that is stock guile <stis>guile3 is wicked fast atm <mwette>got it, thanks, and nice to see such results <stis>that is toolized and can be used as a general dispatching tool. <stis>let me know if you want it as a library of it's own <stis>line 1547: (define-type-dispatcher (iprin1 exp flags pstate) x ... <stis>not C speed but still pretty good <daviid>old: wrt to your earlier guile built-in fixnum procs, iiuc - 7.6.2.21 rnrs arithmetic fixnums <akirakyle>daviid: I think I might be running into another g-golf bug <akirakyle>daviid: I'm trying to build on the drawing example, but I think there may be something with how gsk render nodes are not actually gobjects <daviid>akirakyle: ... All GskRenderNodes are immutable, you can only specify their properties during construction. - i will look into your paste slightly later today ... <akirakyle>daviid: Yep I've been reading through the gsk docs and source code. I can successfully get stuff to screen using Gtk Snapshot but am running into these issues when trying to work the rendernodes directly <old>daviid: fixnum+/carry nice thanks <Aurora_v_kosmose>I don't see the format specifics mentioned anywhere, just that procedures have such a property. <daviid>akirakyle: it's a bug in g-golf, it might take a little while for me to fix it, i am on it, but don't hold your breath :) - will ping you when i have some news... tx for the report <akirakyle>daviid: sounds good! Thanks for taking a look! <stis>these one shot continuations should be able to speed up fibers! <dthompson>Aurora_v_kosmose: guile docstrings can have texinfo markup in them <dthompson>though I've never actually done that myself... <Aurora_v_kosmose>dthompson: Ah I see. I've seen quite a bit of it in Guix and some functions when queried from the REPL with ,documentation function-name <dthompson>Aurora_v_kosmose: yeah I think there is some subset of the markup that is acceptable. <dthompson>I *should* use texinfo docstrings but I'm stuck in the past before guile did this automagically <dthompson>I swear I read something about it somewhere... <dthompson>I'd go looking but I'm trying to wrap up computering for the day :) <Aurora_v_kosmose>It seems to do some additional magic. other than just processing texinfo in docstrings. (module-stexi-documentation (srfi srfi-1)) spits out the Commentary: block of comments verbatim as well. <mwette>some stuff in (system repl describe)