IRC channel logs
2019-09-02.log
back to list of logs
<str1ngs>daviid: no goop slots. I'm just using the NomadWebView to initialize signals and some struct members. maybe it's an issue with my typelib. I'll try to see if I can replicate without using the GObject inheritance <daviid>if you debian paste a ,backtrace #:full? #t, i could look at it and see if it gives me some ideas of possible causes <str1ngs>daviid: will do, just been a little busy I'll have something later today or tomorrow. <daviid>str1ngs: it's ok, but it will only take a min to paste a full trace ... up to you <rlb>I'll likely mark it as unresolved again. <str1ngs> daviid: your intuition was right. If a goops class that inherits a gobject class has a slot it will cause this error. I'll paste my simple case <daviid>right, i'm working on this now ... <str1ngs>no problem, I apologize for just being able to report this now <str1ngs>and I realized I'm using goops slots here due to the inheritance. so you were right to begin with <daviid>it's ok, i did suspect and was already working on this problem, will fix asap <daviid>str1ngs: a series of fixes actually, make sure you pull and have this commit 04be8f13cd6369f58103f647ab2075bbb39b044b on your local clone before you try again ... <lloda>how do I write a fender that a thing in macro args is a literal string <lloda>I have this for define-inlinable + case-lambda <lloda>but the parts commented out don't work <lloda>they work in the repl, but I get tree-il errors if I try it in a module <lloda>I also use in a bunch of places (define x (let-syntax ... (case-lambda ...))) which I guess won't work with this macro :-( <wingo>lloda: (string? (syntax->datum #'x)) <wingo>not sure if that answers the question tho <wingo>i think (define-syntax x (let-syntax ... (inlinable-case-lambda ...))) should work fine fwiw <lloda>wingo: that works I guess, but not if x needs to be a function depending on context. Or I don't understand. <wingo>lloda: yeah i guess that sounds about right <wingo>incidentally, i had OK luck making "folder" macros <wingo>i.e. instead (or in addition to...) of trying to inline some kind of fold function, <wingo>instead do (define-syntax-rule (foo-folder f) (case-lambda (() nullary-body...) ((x) unary-body...) (args generic-body...))) <wingo>so you invoke via ((foo-folder +) x) <wingo>or you can (define-inlinable (foo-fold f arg ...) ((foo-folder f) arg ...)) <g_bor>This is a first prototype, and comments are very welcome. <g_bor>I've seen the comment in the source file of string-contains-ci :) <civodul>it could be useful to write the scanner of the Guix GC <civodul>but there's the 'guile-daemon' branch, which reepca has been contributing to <lloda>wingo: hmm, I'll have to think about it <g_bor>Oh, yes. I am aware of that effort. <g_bor>Do you know about the status of guile-daemon? <g_bor>civodul: Next on my roadmap is netlink :) <civodul>g_bor: re guile-daemon, i'm afraid reepca might be waiting on feedback from me :-/ <civodul>basically it +/- allows you to build derivations <civodul>there were architectural issues that we discussed a while back and we got stuck there <g_bor>Do you know why recv-from! is so blocking? It's specially noted in the docs. <civodul>that had to do with how to disentangle client code of (guix derivations) with lower-level code <civodul>but i think that should be easier now <civodul>i guess recvfrom is blocking unless your fd is O_NONBLOCK, no? <g_bor>Also, would the reconfigure tolerate the blocking, or should I set up some select? <g_bor>civodul: that's fine, but the docs notes that all threads are blocked... <civodul>"reconfigure" as in "guix system reconfigure"? <civodul>i guess the netlink library should rather be non-blocking <g_bor>On a GNU/Linux system recvfrom! is not multi-threading, all threads stop while a recvfrom! call is in progress. An application may need to use select, O_NONBLOCK or MSG_DONTWAIT to avoid this. <g_bor>civodul: ok, I also believe that would be better <lloda> where does autoconf look for share/aclocal/guile.m4? <lloda>what is the recommended practice re GUILE_PKG? it looks wrong to me that you have to tell autoconf where guile is <civodul>'aclocal' is the thing that looks for guile.m4 <civodul>it looks for it in "standard locations" plus ACLOCAL_PATH <lloda>so you have to set ACLOCAL_PATH <lloda>this is orthogonal to PKG_CHECK_MODULES([GUILE] ...), right? one or the other? <civodul>PKG_CHECK_MODULES is a macro that comes from pkg.m4 (pkg-config) <lloda>right, that's not a problem for me because I use the system pkg-config, but I don't use the system Guile <lloda>so is GUILE_PKG recommended over PKG_CHECK_MODULES or the other way around? <civodul>it allows you to specify which major version(s) you're looking for <roelj>What's the Content-Type for S-expressions when either requesting or serving S-expressions over HTTP? <rekado_>text/x-script.guile or text/x-script.scheme perhaps? <roelj>rekado_: Well, S-expressions are not Guile or Scheme-specific, right? <rekado_>these are the MIME types for Guile or Scheme scripts. <rekado_>does the content type matter much at all? <roelj>rekado_: Well, I'm building an API that can return JSON, XML or S-expressions. The "Accept" header can be used to specify the format to return. <roelj>So I'm looking for what's most used for S-expressions.. *wingo still very pleased about 10x improvement on mbrot <Tirifto>Hello! I have a question: Is there a standard format for writing Guile (or, more generally, Scheme) documentation? I'm thinking kinda like there is POD for Perl, which can be used for both code documentation (in between code) and separate manuals, and then exported to PDF or HTML or whatever. <Tirifto>(Comments for code and Texinfo for manuals, I guess? :P) <wingo>there's docstrings too, and module commentaries, but there's not a standard literate-programming thing <Tirifto>Also… if I want my Guile Scheme program to communicate with an IRC server, would the way to go be to find a library in C and make Guile talk to that? I haven't ever really done anything similar, so I don't know if there's any recommendation on that. <str1ngs>lloda: if you don't use the system guile, you can add the local guile.pc directory path to PKG_CONFIG_PATH <str1ngs> guile-2.2.pc directory path to be more specific <Tirifto>nly: Ah, thanks! Skimming the tutorial, looks like 8sync handles the connection and communication with the server? Neat! <lloda>str1ngs: thanks, I had done that already. The problem is that autoconf doesn't find guile.m4 where GUILE_PKG is defined, so it's not enough to tell pkg-config, you have to tell autoconf. <lloda>maybe autoconf could use pkg-config to find all packages that define autoconf macros or something <nly>tirifto, yes. it has a module for irc <Tirifto>nly: Perfect! I'll give it a try. :) <str1ngs>lloda: I use AC_CONFIG_MACRO_DIRS([m4] in configure.ac and then autoreconf -i should install m4 file there and look there. but for guile you might need to set ACLOCAL_PATH as for it to install. I personally just copy guile.m4 the m4 directory and add it to version to control. <lloda>str1ngs: ACLOCAL_PATH is what I was missing, once I fixed that everything worked. I'd copy guile.m4, but it wasn't my package. <daviid>lloda: i think, with some work that i don't know when i could find the time yet ..., that i should be able to use newra in guile-cv, and get a pointer to the low level f32 vector(s) when i need to call 'my' C procs, right? <lloda>daviid: that would be excellent <daviid>but is it feasable, as i think it is? <daviid>i mean can i 'impose' on newra that it stricktly work with the loe level data to be f32vectors? <lloda>right now newra is just like Guile's array system, it's all by mutation, it doesn't create arrays <lloda>so just as you do (bytevector->pointer (shared-array-root array)) you'd do (bytevector->pointer (ra-root ra)) <daviid>lloda: i don't use gule-'s array system <daviid>i use f32vectors, just that and always that <lloda>I imagined so, but using f32vectors as underlying arrays is also supported by Guile's system <lloda>Guile's arrays aren't container types, they are just thin wrappers above bytevectors or vectors or w/e <daviid>ok, i cloned it, how do i install it? <lloda>you copy the mod/newra folder somewhere in your Guile load path <lloda>map.scm takes a loooong time to compile <lloda>in fact travis-ci is now failing b/c Guile sits more than 10min compiling and travis-ci thinks it's hanged :p <daviid>lloda: buti don't use travis here anyway right? <lloda>no, it's just for the badge on notabug/github <daviid>it'be nice to autotoolchain it no? <spk121>lloda: on travis-ci, there is a 'travis_wait' wrapper script that you can use to tell it to not give up <lloda>I hoped to get to a point where it was just flat out better than Guile's array system so I'd switch for my own progras <lloda>it's not there yet, it's faster for some stuff and slower for other stuff <lloda>and it's not as fast as writing your loop by hand using f32vector, although I think it can be done <daviid>actually i thought it was already as fast as writing my own loop by hand using f32vectors <lloda>I have a small benchmark in sandbox.scm where a fold over a 10m element array takes 1.5s on newra and 0.5 to 0.8s using a raw loop with f64vector-ref, depending on how you write it <lloda>which considering newra doesn't unbox the + or anything, it's not so bad <daviid>ah, that's quite a big factor, for guile-cv i mean, it would have quite a big impact <lloda>I don't think you could use to replace something that works right now <lloda>I'm a heavy user of Guile arrays which are slower than hand loops and even I am not doing that <lloda>one big advantage is it's all Scheme <lloda>so you can Ctlr-C anything and it will sto <lloda>I still think truncating is necessary, anyway <lloda>anyway I think I'll get there, sooner if I get help, but I'll get there one way or another <daviid>lloda: one problem is that guile-cv images are lists, width height n-chan f32-chan-0 ... f32-chan-n-1 and i do't think i want to change that, so maybe i did speak to fast :) <lloda>and each f32-chan-i is an f32vector? <daviid>i hope guile-3.0 will truncate both repl and raised exception outputs by default, and offer a 'toggle-from/to-full-printing/truncated-printing, using a column (a guile variable, not an ENV var, or not only a guile env var), then we can set the column to -1 (full-printing) or something else ... <daviid>n-chan is the number of channels <daviid>lloda: those accessors are for users, i do everything by had in guile-cv code, and most in C <lloda>daviid: if I was doing that without knowing anything else, then an image would be an array of rank 3 with shape [nchan height widht] and you'd get each channel with (ra-from img i), or all the channels at one point with (ra-from #t x y), and so on <lloda>if you need to keep memory order always fixed and the type is always the same, then probably newra or Guile arrays aren't necessary <daviid>lloda: yes, i don't thnk they are necessary, and it seems it would be a lot more wotk then i thought to move to newra, but i'll still keep an eye on it :) <lloda>the main audience is people who would like to do matlab-ish or numpy-ish or modern fortran-ish things in Guile, interface to C, but be able to handle arrays at a higher level eventually, APL/J style is my goal <daviid>lloda: in that same file, the last i pasted the link for, a bit below, you can see the linear algebra 'machinery', which calls C ... just for curiosity ... but contructive critiques welcome of course <daviid>lloda: yes, that's why i thought moving to newra, people could do octave-ish (and not using matlab :):)) ... in guile-cv (in guile) <daviid>then we can rewrite octave using newra, and guile-cv can use everything people would develop on top of newra ... <daviid>:) rewriting octave usig newra would only take a few years, given a few top notch delvloper :):) <lloda>how many of those do you know who'd volunteer :D <daviid>lloda: another far reachable goal would be to have newra/guile to use GPU, transparently <lloda>but octave wouldn't exist if its language wasn't close to the m-language <lloda>daviid: you can do those things in clojure iiuc, so it's mostly glue code, just as it is in numpy <lloda>it's a lot of work to have an ecosystem like that, anyway <lloda>I want to do one thing first, then think about the next <lloda>daviid: which like did you have the C interfacing at? in the link you posted <daviid>clojure is not good, kawa is a lot better, but kawa doesn't have much 'traction', just a few 'likers'... so it has a lot fewer libs <lloda>yes, the ecosystem is a separate thing <daviid>and then it is incompatible with our plbn to 'conuer' the planet using guile and it doesn't have goops either ... <lloda>I mean I don't think python is very good, but it's popular and it has everything <lloda>I see, you've written wrappers in C <lloda>I think I'd prefer to use the ffi going forward, and call C libraries directly <lloda>not have to write anything custom in C <lloda>if the thing you want to do in C doesn't exist in C, then sure, you need to write it yourself <lloda>but most low level C stuff already exists in one form or another <daviid>lloda: you'd find a few linear algebra funcs, but it would like hunderds, thousands of image processong procs, and the list gorws by hunderds every day <lloda>but you could write the image library in C and get help from everyone who isn't invested in Guile, and then use it from Guile without writing custom C code just for Guile <daviid>vigra only has half of what guile-cv offers, just as an example <daviid>tough it has also things i still need to bind <lloda>I think the ffi could be extended <lloda>for example when gfortran gets the ISO compatibility array descriptor, you could call a fortran 2008 function from the ffi passing arrays directly without having to dig inside for the strides & stuff <daviid>for a single maintainer - imagej has about 5000 developers <lloda>daviid: that's better than using libguile.h, right? <daviid>oh yes, i wouldn't want to use libguile.h, that would be terrible <daviid>at lest i can switch back ti gile anytime, when our aot gives us f32 proc perfs <= C ... one day ... i know someone is working on it :):) <daviid>i beleive my sepration, in guile-cv, is very clean indeed <daviid>and the C level does things usualy C folks don't do, like accepting any number of images (in their arg 'list') <lloda>C is the ground we have for good or ill <lloda>guile-2.2 is so slooooow omg <civodul>lloda: been using 2.9 for too long? :-) <lloda>I hope all the distros & dependents switch quickly this time