<sneek>Welcome back daviid, you have 1 message. <sneek>daviid, str1ngs says: thanks for the reply. no rush on gtk-css-provider-load-from-data I just wrote a typlelib function types supported by g-golf for now. thanks for the details. <daviid>str1ngs: I hope to work on this soon, but I have been and still am 'less available' these days, due to a move - which takes an awful lot of time ... - but I hope to be back to 'normal' working hours soon, let's see :) <daviid>str1ngs: I really want to solve this 'missing array type' in g-golf, obviously, and i will be nice to count on you to test :) <str1ngs>daviid no problem, because I have still have a nomad typelib I can work around small issues no problem. also I have this patch for guile-cairo. it might be of interest to you. http://paste.debian.net/1128080 <daviid>str1ngs: ok, i hope wingo will find some time to answer soom - I really can't look at this now, but thanks, will try to look at this later ... <daviid>str1ngs: did you look at how thigs are passed between guile-cairo and guie-clutter? <str1ngs>not really because I'm only using g-golf with nomad. the main take away it g-golf and guile-cairo seem compatible with this patch. <daviid>str1ngs: it would be nice to port the clock exaple I wrote using guile-clutter - but using g-golf ... <str1ngs>I'll just email to guile-user for posterity. I ended up using graphviz instead because it was better for mapping class hierarchy. <str1ngs>do any g-golf clutter signals take CairoContext *cr at all? <daviid>but I wish I can port all my clutter examples using g-golf ... <str1ngs>actually do you have any working g-golf clutter examples. maybe I can port my cairo example to clutter <daviid>str1ngs: have to look at my 'old' code <daviid>str1ngs: i don't, i have guile-clutter examples, which I posted a while ago <str1ngs>last time I used clutter was when I make a image viewer that worked on desktop and android. yet android <daviid>str1ngs: no, guile-clutter, not g-golf (yet) <str1ngs>I can just translate a C clutter example to g-golf. the API is easy to reason <daviid>str1ngs: no C pleas, pure scheme only <daviid>all these old examples are pure scheme code <str1ngs>the examples are not clickable are the in the source tree? <daviid>str1ngs: but you could just read the code and see if it works with g-golf <str1ngs>okay no problem I will clone. but first I need to see if any of the clutter API takes CairoContext *cr. if so my patch should work for that too <daviid>(I can do that to of course, but i'd rather complete g-golf ...) <daviid>str1ngs: guile-clutter is difficult to install, i warn you, but if you follow the steps, very well, then it's ok ... becasue it neeeds an old version of clutter, the cherry pick a patch ... and unfortunetaly, no guixers ever build a package for guix ... <daviid>str1ngs: but you might as well skip guile-clutter and wite the example using g-golf <str1ngs>okay but is it worth installing guile-clutter. can't I just the code as reference and port say the clock to g-golf? <daviid>str1ngs: i'd try to 'port' to g-golf by just reading the code and write it using g-golf ... <daviid>all these are very small examples ... <str1ngs>right no problem. and I've used clutter before so not that hard to reason. it mainly uses lower glib primitives then gtk really. with actor model <daviid>when sing g-golf, in order to see the stage on the screen, you need to set an env variable, let me find it for you <daviid>str1ngs: the clock is the only one that uses guile-cairo - i'd like to see what you think, and why you need to patch guile-cairo ... <str1ngs>its possible the patch is not needed, but I did'nt see anything that exposed converting CairoContext *cr. to guile-cairo's smob SCM <daviid>str1ngs: you need to set this env var <daviid>str1ngs: librem 5 phone yes, but android i doubt we can <str1ngs>I was thinking of getting a pinephone might be a cheaper alternative. <daviid>str1ngs: i really want to invest in debian based phone <daviid>i'm sure the guix folks will port guix to the librem 5 phone <daviid>just a matter of time - meanwhile, i need to copete g-golf and get it stable ... <str1ngs>ise librem 5 the best option for debina? <daviid>str1ngs: i think so, but not a specialist, by far <daviid>i don't want android, and i don't want firmware, so i think th e oly option today is the librem 5 phone, but happy to be proved wrong ... <str1ngs> pinephone is pretty open. and should run Debian Mainline based on the wiki <str1ngs>it's just not as expensive hardware as librem 5 <str1ngs>it seems pretty open, but you have to really read the fine print <daviid>str1ngs: actually, clutter 'scripts' examples are here <daviid>but each depend on 'upper dir' series of modules ... <daviid>str1ngs: yes, all depend on clue <daviid>*all grip clutter examples depend on (grip clutter examples clue) <str1ngs>okay, let me first try a simple clutter application with cairo. just basic. then see what I can to do create an example using clue. but this relies alot on porting grip to g-golf yes? <daviid>str1ngs: yes, i agree with you, and first, just a stage with s simple exmaple that do not even use cairo <daviid>str1ngs: here out to get a stage on screen <drakonis>i was wondering what it was because i spotted its inclusion on nomad <daviid>drakonis: nomad is 'just' an example, g-golf should allow you to build any modern gnome app using guile scheme, any <daviid>drop this any where, i.e. clutter-stage.scm, then chmod a+x clutter-stage.scm, then ./clutter-stage.scm <daviid>str1ngs: before ileave :), i added support for motion events, two days ago ... gdk-event-motion>, gdk-event-motion:time, gdk-event-motion:state, gdk-event-motion:coords ... see the log and the doc, maybe yu'd like that in nomad, don't know ... <str1ngs>drakonis: thanks for the feed back we are working on a website. could use some help with artwork and graphic design though. this is the current site though it's more of a blog then a site right now. https://www.nongnu.org/nomad/ <drakonis>you might want to take a bit of inspiration from guile, guix and next's pages <str1ngs>drakonis: and to be fair nomad is still very alpha. so a website is pretty premature <str1ngs>I like guil's artwork etc. but my primary focus is developing nomad. <str1ngs>our current alpha release does not even contain g-golf so we have a ways to go yet. <str1ngs>sneek later tell daviid, thank you I would start with this example. <rlb>Anyone seeing dynamic-link "file not found" errors in 3.0 as compared to 2.2? So far I'm not sure what's causing it, but commenting out a single call inside a function (that's not called via the init function) "fixes" the problem... (this is via load-extension if it matters). ***nly is now known as veere
***veere is now known as nly
<lloda>rlb: I use load-extension and haven't seen this <lloda> it's funny that Guile has 3 different hash table implementations <jcowan>lloda: Your average large C program probably has 10 hash-table implementations, all more or less buggy (see Greenspun's Tenth Rule) <nly>(define *assoc* `((nly . something))) <nly>(assoc-remove! *assoc* 'nly) <lloda>still I think Guile's native should be the best of them all, and that doesn't appear to be the case. <nly>$11 = ((nly . something)) <nly>i thought things ending with a bang! will set! stuff <lloda>b/c it makes a lot more sense to pass hash/assoc when you create the table like rnrs does and not when you look it up like Guile's native hashtables do <lloda>nly: they might, but they don't necessarily do <lloda>srfi-1 explains this I think <lloda>'It is allowed, but not required, to alter cons cells from the alist parameter to construct the result' <lloda>i.e. the result of the function is the return value, not the modification of the parameter <nly>trips me up all the time. <lloda>if it's the other way (result through the argument) they would return unspecified, but I do agree it's not obvious <nly>ah, crap i wanted to show you the bot lloda <nly>lloda by any chance do you know about sneek's source? <jcowan>lloda: There is no particular reason why Guile's original hash tables should be better than what came along later; on the contrary. <lloda>they should be updated or replaced so they are better <sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ 2.3.0-darcs ***sneek_ is now known as sneek
<nly>do you know the whereabouts of sneek's sources? <nly>would you like to make it public? :P <dsmith-work>nly: I'd like to, but there is a lot I'd need to do. Like figure out how to install it and stuff. <dsmith-work>I don't even remeber how I created the db. I've just been copying it around for years. <nly>just toss it over the fence, haha. Janneke was also looking for it. <nly>that would be helpful, i think <dustyweb>wingo: btw, another crossover episode if you're interested (and it's not too much a distraction). I plan on porting Goblins to Guile once I get some more stuff done in the reference (Racket) implementation so I can get Racket <-> Guile programs speaking through it. <dustyweb>in general I think it shouldn't be too hard to get them communicating <dustyweb>and ocap isolation may (mayyyy) be a bit easier in guile mostly, with one exception possibly <dustyweb>one thing that I pshaw'ed early on in Racket and as I went more into ocap stuff I'm like "oh dang this is important" from Racket is immutable cons cells <dustyweb>since cons cells are everywhere in scheme programs, it's an easy place to introduce surprises. but it seems like retrofitting immutable cons cells into guile in a clean way could be hard. <wingo>dustyweb: in your context, it not sufficient to just not expose set-car!, reverse!, etc? <wingo>i mean you don't expose pointer->scm either, right? <wingo>there's always unsafe primitives below <dustyweb>ok, that alleviates one thing I've been mulling over then :) <dustyweb>I guess I just wasn't thinking very clearly about the restricting those as "low-level primitives" <dustyweb>when phrased that way, obviously that's correct. <dustyweb>anyway, I plan on doing the port not too far in the future but I'd like to get the main reference implementation in a nice place so I don't have to keep adjusting two things in parallel <dustyweb>I have learned a lot from the ocap community in the last couple of years <dustyweb>and would like to bring that back over to guile-land <dustyweb>wingo: I also don't remember if I said it to you directly, but I think Guile is in a great place right now, and 3.0 is really thrilling. <dustyweb>really excited/happy with the stuff that's happening. <drakonis>what's next for guile now that 3.0 is out? <drakonis>i mean, feature wise, after fixing all the bugs <drakonis>cant fix them all but can sure as hell try tho ***hunzelstrunz_ is now known as hunzelstrunz
<dsmith-work>Oo. I'd like to eventually see native compilation. Binary ELF executables. <jcowan>It would simplify deployment, but there are better ways to approach that. Otherwise AOC has no real advantages over JIT, and sometimes it is disadvantageous. <rlb>lloda: thanks -- and yeah, it's fine for one of my shared libs, but not the other. <rlb>...the one that fails fails with the "file not found" error -- though I can see that it does open the correct shared lib, mmap some bits, and then move on. <rlb>If I comment out the one function call (inside another function) it's fine. I wondered if maybe I was missing a -lfoo that's now needed but guile-config doesn't supply -- didn't see anything obvious via ldd, but plan to revisit. <rlb>hah, that's where I saw the open/mmap, etc. <rlb>i.e. it does open the right shared lib, and then abandons it. <rlb>I think that function call is an indirect internal recursion, but no idea why that would matter yet... <dsmith-work>There is a long standing issue with shared libs. Even though the file is found, if there is an error in the init func (or something like that) it is still reported as "not found". <rlb>Thanks -- I'm pretty sure that function wasn't being called by the init function (I'd pared it down to almost nothing while testing), but I'll double check. <dsmith-work>The message is the confusing part. And IIRC it's not a Guile message. <rlb>Imagine it's just the sys_errlist (perror) value for dlopen or something -- though I suppose we could consider eventually (if we don't already) having a way to ask guile to at least be more verbose wrt load-extension, etc. if we might be able to say something more helpful. ***apteryx_ is now known as apteryx
***apteryx is now known as apteryx_
***apteryx_ is now known as Apteryx