<Josh_2>How can I find out what type an object is? <davexunit>Josh_2: there isn't any single procedure you can call to get the type of any object. <davexunit>instead you'd ask questions about the data: (if (number? x) ...) <davexunit>however, using guile's OOP system (GOOPS) will create a class hierarchy for all the core data types. <davexunit>and then you could do things like (eq? (class-of 999) <number>) <daviid>str1ngs: sorry about the debug info display, I just pushed a fix, please pull .. <daviid>janneke: tx, but i found that msys2 has a guile 2.2.6 package already - i couldn't test it yet, i still do not have access to a win machine, so i don't know if it works 'fine', if it is a 64bits verion, and if t has threads ... but here https://packages.msys2.org/base/guile <chrislck>fwiw upgrading guile-in-gnucash from 2.0 to 2.2 has solved lots of problems <daviid>chrislck: ok, do you happen to know if it is 64bits? and does it has threads? <daviid>chrislck: that sounds like a miracle :), saying this because unless i missunderstood, till very recently, those tryig to make this work on win reported that it was not working ... <daviid>i don't know how to check if it is a 64bits version <chrislck>kudos probably belong to the msys2 guys :) <daviid>yes, but i beleive he/she is picking spk121 patches, or other patches maybe, because for sure out of the box guile wouldn't compile on w64 ... so i've been told, all this is very far from my domain and knowledge, i'm just very happy it works fine, and better if 64bits, but that don't know (yet) <davexunit>yeah guile needs patching to compile with mingw <daviid>davexunit: are you using these msys2 package then? <davexunit>I've experimented with using guix to compile guile for windows using mingw in the recent past, though <daviid>saying msys2, but they say it is a rewrite of msys and depends on cygwin, not mingw (?) <davexunit>I got what seemed to be a working guile 2.2, but I didn't run any serious workloads on it. <davexunit>32-bit guile 2.2, that is. 64 bit was causing me trouble. <davexunit>daviid: neat! maybe I could borrow some of their patches. <daviid>"... At its core is an independent rewrite of MSYS, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 ..." <davexunit>I want to continue using mingw because I can cross-compile my executables from linux with guix <davexunit>the naming is confusing. mingw-w64 is a different project from mingw. seems to have superseded it. <davexunit>but it can produce both 32 and 64 bit executables <daviid>yes, all these names are very confusing for me, especially because so far i can only read about, not testing yet :) <daviid>could be mistaken, but it did seems to me mingw-w64 is quite a lot better then mingw, don't know <daviid>by all mean, the fact that one can install msys2 and that's it, after that just use pacman commands, is a must <daviid>and they have an imressive list of packages ... <davexunit>for myself, I'd like to produce binary bundles of software from linux that people can just unzip and run on windows. <daviid>davexunit: i understand, but you could as well 'produce' an msys2 package, maybe, from guix ... <daviid>will guix run o win one day, is it possivble i mean? <amz3>what do you think about a nanopass framework for guile? <daviid>davexunit: i had some doubt because of the guix daemon <davexunit>there would surely be some porting issues to sort through <davexunit>but I don't think there's anything making it an impossible task <daviid>i understand it's far from the guix objective in the first place, but if it did exist, i would have used it instead of msys2 of course ... <jcowan>So write a Linux kernel in Guile, and then it will run on Windows <jcowan>or wait for better Win32/WSL integraton <jcowan>Which is surely coming, now that Docker on Windows (as opposed to Windows programs running in Docker containers) is switching to WSL2. <daviid>jcowan: i think guix pack is already able to produce 'something' that runs on win, but guix itself ... that would be another story :) <daviid>and guix pack is order of mag better then docker ... <jcowan>but guix pack has only userland binaries, right? <daviid>others would know ... i'll let them answer that <jcowan>ah, you say guix pack -f docker and then you get a docker image instead of a tarball ... nice <davexunit>if guix was going to run on windows it would be "native" as in no WSL <jcowan>So you could only package native Win32 apps? <davexunit>the packages supported on windows would be cross-built for windows <davexunit>each package object can say which systems it supports and can do different things depending on which system it is being built for. <daviid>davexunit: you could cross build for mingw-w64, couldn't you? <davexunit>that's exactly what I've done trying to make my own guile builds for windows <jcowan>Makes sense, although sometimes you'd want to containerize programs that are not cross-platform, e.g. when doing Windows-specific devops. <davexunit>as opposed to the base package management tool <daviid>str1ngs: while writing a tiny <closure> example for you, i found a bug in g-golf :), fixed and ushed it, please pull and make ... <daviid>str1ngs: one thing to mention, till i find the time to document, is about the type - #:return-type and #:param-types - which must either one of the %g-type-fundamental-types or <gi-enum> instance, a <gi-flag> instance, or <gobject> subclass instance <daviid>wrt to the last three, you have a few examples for each i the test-suite <daviid>str1ngs: I am saying this, because of the confusion (maybe) with the fact that when usig the ffi, we need to pass the value of the type, not the symbol, and some type names are equal ... but this has nothing to do with glib/gobject and closures ... hope i'm clear :), not sure, ping me if not ... <str1ngs>daviid: example closure works well. and thanks for fixing the g-import output issue. ***cehteh is now known as google
***google is now known as cehteh
<str1ngs>nly: direct work on nomad has slowed down abit. but indirect work is still active. mainly in the form of qtwebengine/guix . How are things with you?\ <nly>i did read the mail :) thanks for carrying it forward <nly>i am a bit distracted with other things <str1ngs>nly: no worries, I figured you were working some other interesting things :) <nly>i found a problem with toggle-tabs, mouse clicking on tabs does not switch the current-buffer <nly>not sure, why it's happening <str1ngs>I'm aware of why it does this and implemented a fix <str1ngs>basically if you click a tab, there needs to be a signal that switches to that tabs emacsy buffer <str1ngs>things are different on the g-golf branch. so it could be a regression. <str1ngs>mainly the issue is the tab control, needs to be aware of its emacsy buffer someone <str1ngs>for the non gtk branch I have a private GObject struct member that holds the controls emacsy buffer. for reference. <str1ngs>ideally though g-golf is still highly experimental to use <str1ngs>err not g-golf the g-golf branch I meant. :( <nly>still, pretty solid :) <str1ngs>g-golf is working great. it's our branch that's not complete yet. just to clarify <str1ngs>sneek: later tell nly. this looks really interesting <sneek>I could be wrong, but sneek is a good bot