IRC channel logs

2023-01-10.log

back to list of logs

<daviid>sneek: later tell akirakyle ok great! about the constant, g-golf does not import them by default, but you can import those you'd need, let me give an example
<sneek>Okay.
<daviid>sneek: later tell akirakyle in (g-golf hl-api glib) at the end of the module, you'll find an example that imports the GLib PRIORITY_* constant (needed by g-idle-add and g-timeout-add*) and 'artificially(i manually) pretend' they are a <gi-enum> instance, then i also manually defined the ensure-priority procedure, usd in the above defs ...
<sneek>Okay.
<daviid>sneek: later tell akirakyle i'd be curious to know in which situation you need any of those, my experience is that we generally define those in scheme 'anyway' (like pi, or mouse button numbers ... (though GdkEvent management drastically changed in between gdk-3.0 and gdk-4.0 and i still have to play with them in gdk-4.0, so missing a bit of experience here ...))
<sneek>Will do.
<daviid>sneek later tell akirakyle - if from your experience i see it would benefit other users, i may import 'indispensable' constants 'on-demand' (as g-golf does not depend on any typelib, it would require a specal mechanism ...)
<sneek>Will do.
<daviid>sneek: later tell akirakyle it occurs to me there is an example in the manual, though i will probably move that section somewhere else in the manual, here it is - file:///home/david/gnu/g-golf/git/doc/g-golf.html/Import_005f.html#gi_002dimport_002dconstant
<sneek>Got it.
<sneek>akirakyle: Greetings :D
<akirakyle>botsnack :)
<sneek>Welcome back akirakyle, you have 5 messages!
<sneek>akirakyle, daviid says: ok great! about the constant, g-golf does not import them by default, but you can import those you'd need, let me give an example
<sneek>akirakyle, daviid says: in (g-golf hl-api glib) at the end of the module, you'll find an example that imports the GLib PRIORITY_* constant (needed by g-idle-add and g-timeout-add*) and 'artificially(i manually) pretend' they are a <gi-enum> instance, then i also manually defined the ensure-priority procedure, usd in the above defs ...
<sneek>akirakyle, daviid says: i'd be curious to know in which situation you need any of those, my experience is that we generally define those in scheme 'anyway' (like pi, or mouse button numbers ... (though GdkEvent management drastically changed in between gdk-3.0 and gdk-4.0 and i still have to play with them in gdk-4.0, so missing a bit of experience here ...))
<sneek>akirakyle, daviid says: - if from your experience i see it would benefit other users, i may import 'indispensable' constants 'on-demand' (as g-golf does not depend on any typelib, it would require a specal mechanism ...)
<sneek>akirakyle, daviid says: it occurs to me there is an example in the manual, though i will probably move that section somewhere else in the manual, here it is - file:///home/david/gnu/g-golf/git/doc/g-golf.html/Import_005f.html#gi_002dimport_002dconstant
<akirakyle>daviid: Thanks! Sorry I guess I missed that. I'm trying to do text rendering using pango, so I was trying to get the SCALE constant https://docs.gtk.org/Pango/const.SCALE.html
<mfiano>Morning, Guile
<akirakyle>daviid: Idk why I pointed to gdk, just that it seemed like the library with the most constants, but hopefully I'll be getting into all the gdk event stuff at somepoint in the future if all this experimentation goes well :)
<daviid>akirakyle: np!
<daviid>akirakyle: (g-irepository-find-by-name "Pango" "SCALE") => $8 = #<pointer 0x55b337039ca0>
<daviid>(gi-import-constant $8)
<daviid>$9 = 1024
<daviid>$10 = "SCALE"
<daviid>akirakyle: the manual is in 'permanent' construction, but one of the thing i am doing is moving and rewriting the 'G-Golf High Level API' (a bad name actually :)) subsection to/under 'G-Golf Valley', and those gi-import* did make it yet ...
<akirakyle>daviid: Yup got it!
<akirakyle>daviid: And that sounds like a good change since I actually read through "Using G-Golf" but only very quickly skimmed the "Core Reference"
<daviid>akirakyle: yeah, users shouldn't have to read the core stuff ... i'll get there, it's an on going process ... tx
<akirakyle>daviid: calling functions that "return" a GString via expecting the caller to provide a pointer to one is pretty awkward. I guess this is where one would start to write a guile high level api that wraps this sort of thing up in a better interface?
<akirakyle>daviid: I'm playing with callbacks and now I'm not sure what's going wrong. Here's a minimal example: https://paste.centos.org/view/a3bfccd7
<akirakyle>The error I get is g-golf/hl-api/callback.scm:170:27: In procedure g-golf-callback-closure-marshal: Zero values returned to single-valued continuation
<lloda>a12l: if you only use zero lower bounds in arrays (which I recommend) then array-dimensions is better than array-shape.
<oenone>old: nah, I was just playing with using libguile in C++, so more C-ish than C++. Mostly to learn how to embed Guile, and maybe use it as replacement for Lua in a C++ project. Lua is used through C bindings, too (at least in this project), so that might be good enough.
<mfiano>There needs to be more oenone's in this world. I am sick of configuring all my applications with Lua.
<oenone>:3
<oenone>if I use-modules something, all of its exports become visible in my environment (since there are no namespaces). if multiple modules export something with identical name, I'd guess the last one wins, since it hides the previous one, right? are there naming conventions to prevent stuff like this happening on accident? like, prefixing the exports with the module name? Or should I better use @ or #:prefix
<ft>I use #:prefix in cases where collisions are possible.
<mfiano>seconded
<ft>Not sure if there are very established conventions.
<lloda>you can use prefix or selectively import only the symbols you want from a particular module
<lloda>conventions wouldn't solve this problem bc sometimes libraries just define the same names on purpose
<lloda>like srfi-43 vs srfi-whatever the other vector srfi is
<mfiano>I find #:prefix makes for more easily understandable code to those reading it (usually me later)
<oenone>ok, thanks for the input
<dirtcastle>I assume everybody here use emacs and geiser. I have added the guix root directory in the geiser load path. is there a way to make geiser open the file where the object is defined? mine opens only if it is in the same file.
<dirtcastle>if that’s still not enough, Geiser can jump, via M-., to the symbol’s definition. A buffer with the corresponding file will pop up, with its point resting upon the identifier’s defining form. When you’re done inspecting, M-, will bring you back to where you were."
<dirtcastle>from geiser's manual
<mfiano>I use both emacs/geiser and vim/conjure. Apart from that, it isn't very clear to me what you are asking about.
<dirtcastle>how to go to symbol definition in an another file. will geiser search through all the imported module and open the file amd go to object definition? mfiano
<mfiano>I do M-.
<mfiano>and M-, to go back
<old>dirtcastle: The symbols has to be imported I think
<mfiano>Yes they do. The guile repl has to be aware of the definitions before it can jump to them.
<mfiano>geiser*
<mfiano>Every command you enter, including geiser-edit-symbol-at-point, happens in the context of the current file's namespace. In guile's case, it parses the define-module form.
<old>and it does not work well everytime unfortunatelly
<mfiano>True
<old>I can jump correctly to one syntax rule in my project. sometime it jump at the top of the file instead of the line with the define
<old>For a symbol I have: Wrong type argument: listp, :f
<mfiano>There is a section in the manual about cases where there may be ambiguities such as with syntax
<old>So I often just to a projectile grep instead
<old>s/to/do
<mfiano>it's totally possible that geiser lost track of the buffer vs disk changes. This isn't an easy problem to solve for every edge case. Even CL's decades old SLIME has the same problem in certain cases.
<mfiano>I think most Lispers know the drawbacks of interactive development and restart the process before committing etc to see if things still work.
<old>maybe I don't know the internal details of geiser to speculate. But from my experience in C with gtags, I could always jump to definition without any problem
<old>Sad that it does not work well for Scheme
<old>But if you're used to grepping like I am, then everything else is just fancy tool
<old>It helps if the project is grep friendly though
<mfiano>I use project.el aware rg often, yes.
<old>fortunatelly, Scheme is grep friendly since `define' must be used for definition!
<Aurora_v_kosmose>There's dumb-jump that works well with Guile.
<ArneBab>dumb-jump is pretty cool, but it has been integrated into xref (and somehow within xref it doesn’t work as well for me as when it was standalone)
<Aurora_v_kosmose>Has it? I'm still using an older Emacs so I don't know.
<dsmith-work>{appropriate time} Greetings, Guilers
<old>Hi dsmith
<jackhill>What's recommended for literate programming with Guile (or Scheme more generally)? https://wingolog.org/archives/2004/07/25/literate-programming-with-guile-lib is what I was able to turn up with a web search
<a12l>What's the difference between the hash-*; hashq-*; and the hashv-* procedures?
<dthompson>a12l: they use different equality tests. hash-ref, for example, uses equal?. hashq-ref uses eq?. hashv-ref uses eqv?
<mfiano>I like that. It sure beats CL's way in my opinion.
<dthompson>it's a little awkward. I wish the hash table itself stored this information.
<mfiano>In CL, the generality is in the getter
<mfiano>That is, you specify the equality test in the constructor.
<a12l>dthompson: Thanks! I'm looking currently in the ref manual about the differences between the equality procedures
<mfiano>The general rule is the longer the name the less specific it is
<mfiano>eq? for example will basically compare memory addresses on a sane implementation afaiu
<mfiano>There's actually a famous article by one of the Common Lisp designers that explains why there are so many equality predicates in CL (and Scheme), if you're interested for a short read.
<mfiano>a12l: ^
<a12l>mfiano: That sounds a bit interesting, sadly the short description in the ref manual didn't help much
<mfiano> http://www.nhplace.com/kent/PS/EQUAL.html
<mfiano>"There is no uniquely determined equality function for complex structures--there are only arbitrary ones."
<a12l>mfiano: Thanks!
<mfiano>Basically, one cannot possibly know how to copy, compare, etc an abstract data type.
<mfiano>A list can be used to represent data, but the context of that data determines how these operations should be defined.
<a12l>What does the line "Hash tables are currently only compared as per eq?, so two different tables are not equal?, even if their contents are the same." (from ref manual) mean?
<mfiano>like, should copying a list just copy the memory address, so you have shared access to a pair? should it copy just the outer level? or recursively? what about non-pair aggregate elements like vectors when it encounters them deep in the structure?
<daviid>sneek: later tell akirakyle here is a commented example that works - https://paste.rs/dWR.scm
<sneek>Will do.
<a12l>mfiano: I don't think I'm able to understand what you or what the ref manual says here
<mfiano>a12l: It means that two variables are eq? to each other if they point to the same hash table object.
<mfiano>THat is, hash tables must be the same memory to be considered identical.
<mfiano>which is what eq? is defined to do...check "identity"
<a12l>So there's no difference currently between the hash-*; hashq-*; and the hashv-* procedures?
<mfiano>There is.
<mfiano>What you just asked about is comparing hash table objects themselves. Not their key lookups.
<a12l>Now I'm confused.
<mfiano>The whole structure
<a12l>Ah, okey
<a12l>Thanks, got confused
<a12l>But now I have a problem, because then I can't use hash maps as I intended.
<mfiano>So if you store a hash table as a key in a hash table, you will want to use the associated eq? equality hash table lookup function
<a12l>What is currently the preferred data structure for multisets/bags?
<a12l>I looked at associated lists, but the order of their elements matter (which is important in my case that they aren't)
<mfiano>srfi-113 probably
<mfiano>i haven't tried anything like it though
<mfiano>a12l: Are you new to Scheme?
<a12l>mfiano: When I look at the guile src repo I can't find 113 in the `/module/srfi` directory. Does that mean that srfi-113 isn't implemented in Guile?
<a12l>mfiano: Yes, and new to lisps in general
<mfiano>Good, I don't feel alone here anymore. But, I come from Common Lisp... and I feel like a baby trying to crawl for the first time in Scheme.
<mfiano>Guile might not implement 113. You'll have to check the manual, or find a portable implementation to install.
<mfiano>There also might be a more suitable alternative for Guile.
<mfiano>Maybe someone smart like dthompson may know.
<haugh>That's right, it just hasn't been implemented. It's a Request For Implementation, after all. Often the sample implementation will work for me, but you'll probably need to write a Guile module definition and obviously stash the directory in a convenient load path.
<mfiano>Thanks for the insight
<a12l>haugh: Do you know any way to emulate bags/multisets with data structures currently available in Guile?
<a12l>E.g., is there a comparison procedure that don't mind the order of elements in a list, just if the list contains the element or not?
<mfiano>You can always use goops to write generic functions.
<haugh>check out memq and member, also SRFI-1's member implementation allows a custom equality predicate
<mfiano>But one alternative solution is to sort the list by some known algorithm before storing it as a key, like lexicographically.
<haugh>I don't know of any native structure that enforces unique elements, but if you want to implement something performant I'd probably start with vlists, which provide constant-time access
<mfiano>It may be a bit slow, but it can be abstracted away easily.
<a12l>I don't care about performance for this problem, I just want to store the number of times a letter or symbol occur in a string; and then compare these "multisets" against other multisets to see if their are anagrams of each other.
<haugh>oh just use an alist
<a12l>And then sort the alist after I'm finished, similar to how mfiano suggested?
<haugh>they're hilariously slow but very convenient because they compose with the pattern matcher and all the list hacks. You could either sort the result or query individual keys
<a12l>Thanks for the help haugh!
<haugh>This advice is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<dthompson>mfiano: I'm not up to date on where portable srfi implementations are, mainly because I have a few core srfis that I use and I don't find myself needing others. 113 definitely isn't in guile core.
<dthompson>but usually the srfi's have reference implementations available
<mfiano>I was curious if there was a more idiomatic guile solution to 113
<mfiano>A quick browse through the manual and existing projects didn't turn up anything interesting
<mfiano>Not that I have a need for it. I was just curious on a12l's behalf
<akirakyle>.
<sneek>akirakyle, you have 1 message!
<sneek>akirakyle, daviid says: here is a commented example that works - https://paste.rs/dWR.scm
<akirakyle>daviid: Thank you!! That's awesome, now that I've got an "animated" square going, hopefully that'll soon become gpu accelerated text rendering :)
<dthompson>mfiano: I looked it up since I didn't know what it was. looks potentially useful, however the reference implementation seems lacking. if you want to use the purely functional API then each operation involves copying an entire hash table. no data sharing.
<haugh>SRFI-1 has this lset thing, first time I've looked at it
<dthompson>list sets are fine for small sets
<mfiano>eww
<haugh>we established performance was a non-issue
<dthompson>ah then yeah just use a list!
<mfiano>Yeah, I can't recommend something like that yet though.
<dthompson>you can get so much mileage out of regular lists and association lists with the benefit of cheap persistence.
<old>lset are great
<dthompson>guile has a specialized persistent, functional data structure used in the compiler implementation called an intset.
<Aurora_v_kosmose>GOOPS would allow for extending lset operations to various other sequence types.
<dthompson>a general purpose set structure stored as a tree would be nice. I'm sure there's already a scheme implementation of one.
<old>Since you're there dthompson, the other day I was thinking if there was a good implementation of a quadtreed/octotree for collision checking of entities in video game
<dthompson>old: I'm not completely happy with my implementation but I have a quadtree.
<dthompson> https://git.dthompson.us/chickadee.git/tree/chickadee/data/quadtree.scm
<old>oh sweet
<dthompson>I haven't done much 3D so no octree at this time
<old>Why aren't you happy with it?
<old>API? Performance?
<mfiano>There's a lot of edge cases to consider when quad/octrees are used for spatial partitioning dynamic games, as opposed to static image quantization
<mfiano>I am not happy with mine either, so I feel the pain.
<dthompson>old: I'm not *unhappy* with it but I think there's some performance improvements that could be made, though when I benchmarked a long time ago it seemed that hash table operations were taking up a lot of the time.
<dthompson>I've long had a suspicion that guile could use an optimization pass over its hash table implementation.
<a12l>I'll wait learning about GOOPS after getting more comfortable with the more general scheme stuff
<haugh>I have been playing cat and mouse with goops for months now
<dthompson>a12l: that's a good idea. keep it simple.
<a12l>Do you people have any tips that explains the quote do? When I use the quote mark I'm usually unsure if I'm doing it right or not
<old>dthompson: From my reading of the internal of hashtable in C, every access is protected by a standard mutex.
<a12l>Or is it just an alias for list?
<old>It would be nice to have a read-write mutex instead so that readers are not impacted as much
<dthompson>old: ah that would add quite a bit of overhead
<old>For a quadtree, you usually construct it at the begining of the frame with possible a single writer. Then you can read it in parallel with lots of reader
<old>Having that mutex is a real pain
<old>same for assets cache (image, sounds)
<old>Lots of read, few write
<haugh>@a12l https://www.gnu.org/software/guile/manual/guile.html#Expression-Syntax
<haugh>I strongly recommend installing the Guile manual in texinfo format. If you don't use emacs, you can read it with the standalone info(1) browser, which would let you type `i quote <cr>' to get to the section linked above.
<a12l>Thanks!
<Aurora_v_kosmose>Emacs is however a superior info browser to the standard info browser.
<akirakyle>I really wish info was better though, like proportional fonts and reflowing paragraphs, stuff that the html versions have
<count3rmeasure>how does one install the guile manual in texinfo form, for the record? I'll be offline most tomorrow and I'd love to use emacs to browse it instead of a webbrowser
<Aurora_v_kosmose>Emacs might have reflowing, just not enabled by default.
<Aurora_v_kosmose>I know WoMan has that feature.
<akirakyle>IIRC it's a limitation of the info format itself
<akirakyle>Yeah and re-flowing in WoMan doesn't always look very good
<Aurora_v_kosmose>I have sadly noticed that.
<Aurora_v_kosmose>On the other hand, much longer than 160 cols gets unpleasant to read, so I can just split the monitor in half & have two manuals open instead.
<akirakyle>Yeah, it's just when trying to use proportional fonts, reflowing becomes a must
<akirakyle>Also I hate how hierarchical texinfo manuals can be, like often I just want one big buffer that I know how to efficiently search and jump around in rather than having to figure out/remember how to do all that using info's own interface
<akirakyle><end rant>
<dthompson>in emacs you can search the whole manual with the usual C-s/C-r key commands
<Aurora_v_kosmose>I think dthompson means for something more like bookmarks.
<Aurora_v_kosmose>erh, akirakyle
<akirakyle>Yes, but I can't use swiper/consult-line to do it
<akirakyle>I find having a whole buffer full of the relevant lines very helpful since it gives context to each search result
<Aurora_v_kosmose>I think it might be interesting to store per-manual lists of points the user is interested in and provide a read-completed prompt to find them back.
<Aurora_v_kosmose>Or perhaps storing region + point, for context
<akirakyle>Honestly I've been meaning to just convert the raw texinfo into org mode as my format-of-choice
<Aurora_v_kosmose>That's certainly an idea.
<Aurora_v_kosmose>Arguably it's a more powerful format.
<akirakyle>Yeah and being able to just fold headings or narrow/widen would be killer, and there's always org-element to automate stuff
<Aurora_v_kosmose>It's also more readable in an unprocessed state.
<akirakyle>It'd be awesome if someone with the perseverance could take up the project of replacing texinfo with org as the gnu documentation format of choice since at least rms is open to the idea
<Aurora_v_kosmose>It might be nice to make org somewhat less implementation-defined though. Texinfo is a relatively standard format.
<akirakyle>Yeah, I think it would involve defining some very restricted subset of org that would be allowed for manuals so that that's feasable
<akirakyle>Many have tried and continue to try to re-implement org parsing in other languages, but it's really really tricky
<Aurora_v_kosmose>It's a moving target, for one.
<old>akirakyle: This is why I often open the one page HTML info manual instead. So I can Ctrl-f quickly
<old>Would be nice to have the same in text so I can grep
<daviid>count3rmeasure: what distro? just install the doc? or if manually installed, ten make install-info [or install-html, or even install-pdf]
<Aurora_v_kosmose>I wonder if there isn't a way to just extract the full text of the info manual for completing-read searching.
<daviid>Aurora_v_kosmose: tere is an ascii versiob of the manual
<count3rmeasure>daviid: its Kali, I've never installed an info document before, sorry for the newb question, I have info installed
<daviid>count3rmeasure: you prob ave to install guile doc
<daviid>Aurora_v_kosmose: https://www.gnu.org/software/guile/manual/guile.txt
<count3rmeasure>thank you for the response, appreciated
<akirakyle>old: yes I pretty much do the same, and often in eww so I can use all my favorite emacs stuff
<Aurora_v_kosmose>daviid: Right, but that doesn't preserve the benefits of the structure from the texinfo. It'd be nice to have the benefits of both.
<akirakyle>I know I said <end rant> but I can't help myself. Another thing that browsing the info html in eww gives me over the emacs info browser is that imenu "just works" and I find consult-imenu just so darn helpful
<Aurora_v_kosmose>imenu in html? What function you using for eww buffers? It just gives me an error that the default function won't work.
<akirakyle>oops, I forgot it actually doesn't just work, I had some stuff in my init that hooks imenu up to html headings
<akirakyle>I grabbed it from here: https://github.com/alphapapa/unpackaged.el#eww-imenu-support
<Aurora_v_kosmose>Ah, thanks.
<akirakyle>daviid: any experience debugging g-golf under gdb?
<akirakyle>I'm getting a vfunc called with very unexpected arguments and was gonna try to step through the calls in pango to see if I couldn't figure out where those unexpected values were coming from
<daviid>akirakyle: i nearly never use anydebuer, i stop tink look at te code, use dimfi (peek) ... i nearly ave zero db experience
<akirakyle>daviid: what's dimfi?
<daviid>my kb is nearly dead - sorry for the spelling errors, while not using my external kb ...
<daviid>it is like peek pk, try itit isin-olf
<daviid>*in g-golf
<akirakyle>daviid: thanks, that looks handy, although maybe not for this bug which I think might be a pango bug, hence I'm trying to use gdb
<daviid>akirakyle: prob a bug in g-golf ... if you paste a snipset ... i'll look at it
<count3rmeasure>silly cons syntax question, I'm curious why this list isn't getting values added to it, line 6 is the expression https://dpaste.com/8HPGHNK6U
<count3rmeasure>I've tried quoting both the list and the line variable and neither is doing the trick, so I'm just posting it like this
<count3rmeasure>the myPort is an actual file port defined further up in the file
<akirakyle>daviid: Thanks for being willing to take a look, although I have a feeling this might be a kinda obscure bug (of course there's always the possibility I'm doing something stupid) https://paste.centos.org/view/e30f99fe
<daviid>akirakyle: i'll try, but later ... i am surprised you want to subclass a renderer though ... but i have zero pango reperience as well ...
<daviid>i would first try to just use pango and pango-cairo, and the provided reneders of gsk ...
<daviid>and (make <gsk-pango-renderer>) is highly probably not doing what you think it would ...
<akirakyle>daviid: Well the hope is to use gsk's textnode to render text to screen since that takes care of packing and uploading all the glyph textures to a gpu. There's the gskpango render implementation, but unfortunately it's all private and does a lot of css stuff that I don't want or need. The only interface to it is through the gtksnapshot, and that
<akirakyle>adds a layer of complexity that I don't think I need either
<daviid>try to not subclass and use the gsk renderer new constructor provided by upstream lib. try something from the demo that works in C and you may copy ...
<akirakyle>I don't think I can though since it's all private
<akirakyle>I've actually successfully gotten the gsk-pango-render I defined to render text, it's just the x y coordinates it's being passed are wrong
<akirakyle>So it looks like this should actually work
<akirakyle>I can send you an example that renders animated text on the gpu in a little bit, which is actually technically quite impressive that this works well!
<old>akirakyle: What's your experience with eww? Does it work great in a terminal?
<akirakyle>old: idk, I haven't run emacs in a terminal in many years
<old>I spend 90% of my time attach to a tmux session through ssh. Anything that has bad terminal support is not something I want
<old>oh okay
<old>I guess it can work okay for wikipedia and info manual
<akirakyle>I used to live like that, but then migrated to doing as much as I could locally and remote stuff using tramp and never looked back
<old>But anything else is probably unusable
<daviid>akirakyle: not sure i can help, except if there is a g-golf bug, but as i said, (make <gsk-pango-renderer>) is nearly 100% 'wrong'
<old>I would, but tmux session is just so much powerful
<akirakyle>daviid: why?
<old>that and terminal emulator in emacs are not really great
<daviid>because it is not calling upstream constructor
<akirakyle>old: vterm is pretty good and works for everything I actually need a terminal for
<old>I often do more than editing file. So emacs is not enough. Which is why a good terminal is required
<old>Right. I could try it again to see if has improve since last time I used it
<akirakyle>daviid: I don't think that code snipped would work if it wasn't though, since draws-glyphs is called from the default implementation of pango renderer's draw-layout function
<akirakyle>daviid: Here's an example that moves text across the screen and if I'm understanding all the code in gsk that's being called, this should all happen "on the gpu" https://paste.centos.org/view/dda03548
<daviid>akirakyle: i don't know, maybe - too many unknown on my side
<akirakyle>It does crash at some point and I'm not totally sure why, but from my pov its a really powerful proof of concept for some ideas I have
<daviid>akirakyle: i'll try it but later, have to concentrate on somewthing else - that it crashes is scary ... i'll try later, tx for the snipset
<akirakyle>daviid: thanks for all help so far, I'm pretty excited about all this!
<daviid>akirakyle: welcome - crashes mean memory alloc/gc clashes between g-golf and upstream 'things', they are the most difficult bugs to debug ... some took me months of investigations ... be aware :)
<akirakyle>daviid: Yup :) but so far debugging this stuff in guile has been a breath of fresh air compared to doing similar debugging in python with cython
<count3rmeasure>bumping before I log off for the day, I know its not too interesting, but I'm struggling to find the syntax (or whatever) error thats keeping this list from getting cons'd https://dpaste.com/8HPGHNK6U
<count3rmeasure>line 6, fwiw
<akirakyle>count3rmeasure: From my quick glance at it, I think (cons line myListofStrings) does effectively nothing
<akirakyle>it returns a cons but you don't do anything with it
<akirakyle>You probably meant something like (set! myListofStrings (cons line myListofStrings))
<count3rmeasure>so its a misunderstanding in the cond form
<akirakyle>Or, just append
<count3rmeasure>append!!!! ahhhhh! thank you
<count3rmeasure>yes, append is exactly what I meant
<akirakyle>Or sorry its actually not what you want in the sense that it won't mutate myListofStrings
<akirakyle>So you'll still need to use some function with side effects (they have ! and the end of their names)
<count3rmeasure>yeah, that's what I'm looking for, to update myListofStrings with a line from this file
<count3rmeasure>thank you so much for explaining this to me, I sincerely appreciate your time
<akirakyle>fwiw, the more functional way to do this might be to (define (opFile port myListofStrings) ...) then return myListofStrings
<count3rmeasure>which is what I was originally trying to do but hitting different errors
<count3rmeasure>oh I see, you mean pass in myListofStrings into the procedure, that I *was not* trying to do, but will now
<akirakyle>yeah (opFile port (cons line myListofStrings))
<akirakyle>for the recursive call
<count3rmeasure>yep, following you now
<haugh>old, emacs users will never understand what it means to be terminal-centric. I applaud your openness and the spirit of debate but it's hopeless
<akirakyle>indeed, for me the thing that really pushed me out of the terminal was wanting support for images and trying to work over high latency ssh tunnels
<haugh>images belong on the web and high latency ssh tunnels are why we learn to do everything over a remote multiplexer sesion
<akirakyle>In the context of scientific computing, where images are plots that I want to have next to my code, I prefer if they don't belong on the web because then you end up with jupyter notebooks which suck
<akirakyle>Also how does remote multiplexer session help with high latency connections? I find it impossible to interact with something when I need to wait a second between keypress and display?
<haugh>Very, very broadly speaking: I have a browser (web or pdf) on the left and a tmux client on the right. I edit text on the right and the browser (usually) updates the generated multimedia automatically. There are many good things about a terminal multiplexer and you don't have to use tmux (check out byobu or zellij) but one of the many, many benefits is that it syncs fluidly over a laggy remote session. Combine that with ssh multiplexing
<haugh>(ControlMaster) and you'll never think about terminal lag again.
<haugh>From this perspective, Jupyter (and most web-based literate programming) is an attempt by the browser side to take over the controller role. From this perspective, Emacs is an attempt to replace both.
<haugh>just realized we're doing this in #guile, sorry if too offtopic
<haugh>But I have butted heads with guile folks over emacs before. The manual explicitly recommends emacs which grinds my gears.
<old>akirakyle: I use mosh for high latency
<old>I was able to ssh into work while using the train in Germany. Which had very poor wifi connection
<old>I could also connect to home in Canada without trouble. Mosh use UDP and predict stuff from your keystroke to hide the latency