IRC channel logs
2023-01-11.log
back to list of logs
<old>For graphics, I use sshfs. Probably not the best solution I agree, but it does allow me to continue my reading of PDFs <old>I remember having a good experience with TigerVNC also. I think it's available on Guix I might try it <Aurora_v_kosmose>haugh: Technically, nothing prevents using TRAMP with ControlMaster. Or rather, that's what it does by default. <Aurora_v_kosmose>akirakyle: Regarding Emacs & TRAMP, you might also be interested in detache? <akirakyle>haugh and old, yeah I almost ended up with similar setups when my "scientific computing" involved needing to run stuff remotely, but now that I can do the majority of stuff locally, I've gotten spoiled by the "scientific notebook" which I use org mode for. And it's really nice to have all the images inline in a document, rather than using an <akirakyle>external viewer since then it reads more like a scientific paper with inline figures rather than one where you have to reference the appendix for every figure which quickly gets very annoying <akirakyle>But I realize that for different applications, different workflows work better. I'm just happy that emacs supports both <akirakyle>Well actually I'm not super happy with how emacs supports images and other rich content, which i guess is part of why I'm here on #guile playing with g-golf <Aurora_v_kosmose>My main grievance with Emacs' image support has to do with animated gif & webp. <Aurora_v_kosmose>Static webp is fine if you enable image conversion & add "webp" to the image-file-name-extensions list... <daviid>akirakyle: copy/saving/running your pango example, segfault, and the 1st message is https://paste.centos.org/view/fdc97591 - asking before investigating because you said it works for a while, then segfault, here it doesn't sart <daviid>i haven't changed anything yet :) <akirakyle>daviid: Yes, that example runs for me and when I just ran it again, it didn't even crash <akirakyle>I think the first message may indicate we're on different gtk4 versions <akirakyle>Since iirc the gtk devs moved GskPangoRenderer to be private somewhat recently <daviid>akirakyle: i actually wantd to make a few suggestion, coing stuyle wise, and one would be never use upstream names in your own class prefix names :) <akirakyle>daviid: Yeah I now realize how that can be disastrous <daviid>the 2nd, don't call gtk-* subclass(es), any subclasses, <buffer>, if you are short of name, call them <my-widget> <daviid>i am gona change that here, let's see <akirakyle>daviid: Yeah I guess I used that name since I'd like to start building a text buffer widget, but really I should've used like my-text-view <daviid>buffer is by far too co notated, and a widget is _not_ a buffer anyway .... let's try to avoid confusion 'to start with' ... <daviid>i think my local gtk vesion should run the example fine, let me try some changes ... <daviid>akirakyle: also, in your .emacs file, adding a few (put ... 'scheme-indent-function i) might be good <daviid>let me paste mine, it's far from complete, guix has a more complete list (but lacks guile-cv stuff ...) <daviid>*guilers much better them myself at this exercise ... <daviid>ok, now it works here to, but it doesn stop when the text 'disappear' , is this expected? <akirakyle>daviid: Yes, I just have the text translate off to infinity <akirakyle>daviid: I guess it might make a fun example to have it bounce around the window or something <daviid>akirakyle: it myght become a g-golf example if we clean it (too many global variables :)) and if the text bounces against the widget 'walls' ... <daviid>akirakyle: yeah, if you could do that ... <akirakyle>sonunds good :) yeah global vars become helpful in the repl but not my usual style <daviid>let me paste my changes 1st (far from as i wish, but ... a start) <daviid>akirakyle: you might wana try dimfi, everywhere you use format ... <akirakyle>daviid: Yeah I'll start using that for debugging print <akirakyle>daviid: also the other thing I need to figure out is the x and y values being passed to the draw-glyphs-vfunc being wrong which is what the previous minimal example I sent was for debugging <daviid>akirakyle: now i am gona focus on the other bug - as this example work, i can use it as a ref ... <akirakyle>those x and y values are necessary for getting multiline text right <daviid>akirakyle: one think that occured to me is in the other snipset, you didn't call gtk-init (and there is no app 'activate either, that could be a reason? <akirakyle>daviid: I stripped all that away to get the most minimal thing to debug, it's still there with all the gtk stuff as you can see in this example with translating text. <daviid>and i think that deep down pango rendring needs a display, pixel size .. maybe <akirakyle>Yes thats the SCALE to convert between pango units and pixels <daviid>but to debug, i need a working 'something' <daviid>ok, can you paste a minimal 'working' snipset, that would help me <akirakyle>The one I previously posted is the minimal example that illustrates the incorrect x and y values being passed. It happens independent of gtk. <akirakyle>This is why I think it might be a difficult thing to debug <akirakyle>It could also be an issue in conversion to scm integer types <akirakyle>Which is why I was starting to try to get gdb running, so I could tell if it was happening in pango or g-golf <daviid>akirakyle: but, this same vfunc, it works in the text-transform 'big example', no? i am confused in uderstanding what works and what does not work ... also, anything needing gsk needs a gtk-init call (imo) <daviid>gtk-init does a all bunch of things, including knowing what backend is available on your machine .. <akirakyle>daviid: It does not in the in the text-transform, I work around it by zeroing the offset (offset (graphene-point-init (graphene-point-alloc) 0 0)) <akirakyle>But the format call should show very large negative values being passed to x and y in the vfunc <akirakyle>So I'm essentially overriding where pango is telling draw-glyphs-vfunc to put that text, and this works because it's only one line of text <daviid>akirakyle: so, in the 'big' example, those values are also not correct? <akirakyle>Also I'm gonna need to sign off here, probably for the night, so no worries daviid about looking into this more since I think it does start to dig deeper into the pango code, which I'm somewhat familiar with at this point <daviid>also, why do you use global vars there? my-text-node <akirakyle>Also I have some preliminary messing around that maybe inclines me to think its in pango <akirakyle>daviid: The idea is for the app to keep around the my-text-node rendernode reference so that the text doesn't need to be re-rendered to transfrom it (just create a new transform node with the text node as a child) <daviid>unrelated to our tracking, but imo, you should not use (any) globals, and render nodesa are immutable <akirakyle>daviid: Yes, in the end this state should be attached to the widget, it's just easier for debugging to make it global, but especially since the render nodes are immutable, it's safe to make them global just so they don't get unref'ed <daviid>those are being copied by the gsk engine, you may immediately gc them ... after they have been append-* snapshot ... <daviid>and as you use set!, you also 'immidiately' loose them ... <daviid>i can't find the draw-glyphs documentation <count3rmeasure>just wanted to duck back on and say thank you again for the help, cannot overstate how much I appreciate it <akirakyle>daviid: Yes I understand that, I probably should've emphasized that that example I sent was just a very quick and dirty, get this to work and I was excited that it did. Yes you *can* unref them after being appended to snapshot, but you don't have to, and once you loose a reference to the rendernode, you'll have to regenerate it. The idea with <akirakyle>keeping around the text render node is the same as what is currently done for gtk's text-view widget, so to avoid doing extra work when the text moves around since laying out text can be quite costly <akirakyle>daviid: The reason for all the objects in pango involved in getting text onto screen from the context, to layout, to renderer, to render node is to have many layers of caching so that most common operations on text can be done efficiently <daviid>akirakyle: with all you said, it still seems to me you are creating new nodes, now text ... every tick, but i may have missed some caching ... never mind, i'll clean it here (no pun, just learning as cleaning ...) <daviid>also, just saying, why calling g-string-new, and you don't free it ... just define the scheme string wouldn't be ok? <daviid>i still try to understand this draw_glyph :) <daviid>the doc says 'Draws a single glyph with coordinates in device space.' but your vfunc doesn draws anuthing? <old>whereiseveryone: What's the status on this meeting for Guile's debugger workgroup? <daviid>sneek: later tell akirakyle, here is 'my locally cleaned' and simplified version (which i did to understand and browse some of the doc while doing ... no pun) - https://paste.rs/9rs.scm - i nedd to double check, but i don't think there is a g-golf bug, it would be nice if we could try using a C similar snipset (which i won't write :)) <daviid>sneek: lalter tell akirakyle, the only important change i made is when calling set-text, you can't pass string-length (as it expects a utf8 string length in bytes), instead, you should (always) pass -1 <sneek>akirakyle,, daviid says: the only important change i made is when calling set-text, you can't pass string-length (as it expects a utf8 string length in bytes), instead, you should (always) pass -1 <daviid>sneek: later tell akirakyle the only important change i made is when calling set-text, you can't pass string-length (as it expects a utf8 string length in bytes), instead, you should (always) pass -1 <daviid>sneek: later tell akirakyle i posted and asked in #gnome-introspection, we'll see, i don't think they will answer, but worth trying - <daviid>sneek: later tell akirakyle meanwhile, as it is only called once, and from it we really only use the font instance, why is it important for you? i think you said somethig about this, but i didn't understand ... <old>sneek: later ask whereiseveryone What's the status on this meeting for Guile's debugger workgroup? <old>Anything with the words Guile in it sounds interesting tbh <sneek>I've been running for 8 days <sneek>This system has been up 11 weeks, 16 hours, 4 minutes <civodul>dthompson: thanks for your feedback on bytevector-slice! <dthompson>I use bytevectors a lot for all my linear algebra game stuff. <dthompson>and now I'm wondering how I might further improve performance by using a memory arena for vectors/matrices <dthompson>I'd have to refresh my memory if f64s would work okay given tag bits and stuff <dthompson>but a lot of gpu-side stuff uses single-precision floats typically <civodul>so that use case would benefit from the fact that bytevector-slice preserves the "element type" <civodul>as in (bytevector-slice (make-f32vector ...) ...) <dthompson>civodul: yeah there's other parts of the bytevector api that lose that info which can be surprising. <dthompson>f32vector-ref on a bytevector made with make-bytevector still works fine <civodul>so you can do unaligned f32vector-ref in practice, right? <dthompson>ah right, bytevector-ieee-single-native-ref and friends <old>Is it possible to allocate a byte vector on some given boundary? <dthompson>not that I know of. you just ask for so many bytes and you get it from somewhere. <old>hmm. would be nice to ask for alignment <old>page/cache or others <old>something like posix_memalign <dthompson>it's probably aligned to something but I don't know enough about the gc/allocator to tell you <old>for real performance critical code you want your stuff to be aligned correctly to avoid false sharing and others bottleneck <dthompson>earlier I was talking about alignment to the start of the bytevector <old>I often have to pass to C procedure when I do that since I don't know either :/ <old>Yes I saw. Sorry to have interject like that, it's not everyday we talk about bv here to I took the opportunity :p <old>civodul: Do you think it would be possible to have something à la posix_memalign for bytevector? <old>make-bytevector/align ALIGN LEN [fill] ? <dthompson>would it make sense for that to even be exposed in scheme or should the allocator just handle that behind the scenes? <civodul>GC allocations are 64-bit-aligned currently, IIRC <old>enough for alignment of any native types that's fair <old>dthompson: Do you propose to do an allocator that would create a bytevector and return a sub-bytevector of it that is correctly aligned? <dthompson>old: I have no proposal. I don't really know what I'm talking about. :) <mwette>three cheers for bytevector-slice: hoorah, hoorah, hoorah <sneek>akirakyle, you have 4 messages! <sneek>akirakyle, daviid says: here is 'my locally cleaned' and simplified version (which i did to understand and browse some of the doc while doing ... no pun) - https://paste.rs/9rs.scm - i nedd to double check, but i don't think there is a g-golf bug, it would be nice if we could try using a C similar snipset (which i won't write :)) <sneek>akirakyle, daviid says: the only important change i made is when calling set-text, you can't pass string-length (as it expects a utf8 string length in bytes), instead, you should (always) pass -1 <sneek>akirakyle, daviid says: i posted and asked in #gnome-introspection, we'll see, i don't think they will answer, but worth trying - <sneek>akirakyle, daviid says: meanwhile, as it is only called once, and from it we really only use the font instance, why is it important for you? i think you said somethig about this, but i didn't understand ... <akirakyle>daviid: This example doesn't try to implement a pango renderer, just uses the snapshot api to get a text-node and caches it so it doesn't have to be re-rendered every frame <daviid>C experts, those familiar with libguile and the ffi, i'd appreciate practicle help for this: <daviid>to get 'access' to the libguile (foreign.c) - static ffi_cif *\n make_cif (SCM return_type, SCM arg_types, const char *caller) ... - from g-golf, from scheme, just like make-c-struct ... but it would be make-cif, which would return a ffi_cif* <daviid>i am not familiar with libguile, and g-golf does not use libguile either (of course, otherwise i'd be falinliar :)), and i wish the solutin 'on a plate' :) anyone? <daviid>i have a 'naive' ffi-cif maker in g-golf, but i suspect it only works on full moon days :):) or iow, i susect there is/are some bug in it -- why not reuse the excellent guile's one anyway ...