<ijp>gah, forgot about keyword arguments <davexunit>hmm, how does own 'chown' a symlink in guile? <davexunit>the 'chown' procedure seems to follow the link <davexunit>but I really want to set the permissions for the link itself <ota>Not all systems allow symlink owners, ditto modes. <ota>"chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions" <davexunit>well I can run 'chown 600 my-symlink' in a shell and it does the right thing <ota>From the Debian Linux man page. <davexunit>hmm, maybe it doesn't matter and I'm encountering another problem. <ota>anyway, you're talking about Guile here, so from a platform independence point of view, it is dubious to expect it to work. <davexunit>it's become obvious that the permission problem lies elsewhere ***michel_mno_afk is now known as michel_mno
<dsmith-work>Hmm. Whenever I ls -l on a symlink, the permissions are aalways lrwxrwxrwx <androclus>anyone here use guile for linear algebra or any work with matrices? <davexunit>androclus: I do some light linear algebra with guile in my game engine. <davexunit>you can use guile's array data type to create an MxN matrix <davexunit>I think a linear algebra module that used arrays in guile core would be nice. <davexunit>since I'm writing games and trying to avoid some GC overhead, I actually just use bytevectors and call C BLAS functions. :( <davexunit>which is less than ideal beause now I only get to work with one type of numbers: 32 bit floats <davexunit>a pure guile linear algebra module would have the wonderful Scheme numeric tower to use. <lloda>you can use typed arrays with BLAS & LAPACK. Bytevectors are for bytes :p <androclus>@davexunit thanks.. did you put in the racket link maybe because racket *does* have such a module? <davexunit>androclus: no, I meant to comment about racketcon but then didn't <davexunit>I wanted to say "racket con is shaping up to be quite cool" <ijp>it might do in math/ somewhere <davexunit>lloda: I actually do use typed arrays, but didn't want to get into details. <androclus>are there any linear algebra modules for any other scheme or lisp that you can think of which might be a good model for such a potential guile module? <mark_weaver>androclus: I would look at 'scmutils' which is used in "Structure and Interpretation of Classical Mechanics" among other things. <ijp>docs.racket-lang.org/math/index.html <mark_weaver>it is developed for MIT/GNU Scheme, but it has also been ported to Guile, with some missing functionality and surely not as good performance. <mark_weaver>that's the appendix in SICM (the book cited above) that briefly introduces scmutils. <mark_weaver>btw, one of the designers of scmutils is Gerald Sussman, co-inventor of Scheme itself. ***michel_mno is now known as michel_mno_afk
<gnusosa>Hi, is there any package to handle Git, or Git bindings? guile-git? <davexunit>gnusosa: not that I know of. is there even a git library? <davexunit>gnusosa: sweet jesus we need bindings for this <davexunit>is there a machine readable API specification that we can generate bindings from? <gnusosa>davexunit: I was thinking about working with this. <davexunit>the number of public API functions is staggering <davexunit>gnusosa: so I guess you can just read these html files in using guile's sxml modules <davexunit>since the signature is available, but not in a structured way. <davexunit>the table has the return type, function name, and arguments broken up <gnusosa>It's good to know that we have another implementation out there in Scheme <civodul>libgit bindings would be useful for "guix pull" <gnusosa>I just want to script certain actions of a git hook, and I'm horrified of going back to a shell script <gnusosa>So my first instinct was "how about scheme?" <davexunit>gnusosa: for a quick fix, you can wrap just the functions you need <davexunit>if you only need a few, it shouldn't be too hard to do. <gnusosa>davexunit: yeah, I'm working on that. <mark_weaver>on the subject of 'guix pull', I think it would be great if we could avoid having to precompile all of the package descriptions. this is not very scalable. <davexunit>I don't know what a better option is. if they are interpreted then searching the package list or other operations on the full package set become slow. <mark_weaver>maybe we could instead build some kind of index mapping package name to module, or something. <davexunit>but I sympathize with the desire to do *something*, since we spend so much of our time compiling package modules. <mark_weaver>our design should be able to scale to such a large number of packages, anyway. <davexunit>I'm just not seeing a potential fix that would be reasonable. the first 'guix package -A' I do will trigger compilations of every module. <davexunit>or anything operation that uses the find-packages procedure <mark_weaver>yeah, that's why I suggested some kind of index that could be built more cheaply, but I haven't thought it through. <civodul>mark_weaver: but i recently thought of a hack: abusing auto-compilation, which necessarily builds things in topological order :-) <mark_weaver>civodul: fixing #15602 would certainly help, but it still seems suboptimal to have to compile everything even if you're only using a small subset of packages. <civodul>well in a way yes, but OTOH it can detect issues and prevent "guix pull" from succeeding if there's something wrong <mark_weaver>civodul: there is no topological order, since our package modules includes a huge SCC. <civodul>but the problem is not with package modules themselves, IIRC <mark_weaver>a set of nodes in the directed graph such that you can reach any element of the set from any other element. <mark_weaver>it is sort of a generalization of the idea of a "cycle" <mark_weaver>not long ago I asked graphviz to draw the big SCC in our module dependency graph, and it was a huge complicated mess, way too big to draw on my screen and comprehend. <davexunit>is there anything that can be done to address that or is it just the nature of our work? <mark_weaver>well, the graph of package dependencies cannot have any cycles. the cycles arise because of multiple packages per module. <mark_weaver>moving to one package per module would solve the problem. <mark_weaver>yes, but cyclic module dependencies and the occasional breakage that's hard to debug is also pretty terrible :-/ <mark_weaver>especially since the breakage is extremely hard to predict. it is regularly caused by the patches that appear correct. <mark_weaver>bah, we've been talking about this on the wrong channel :-( <civodul>well module issues are relevant here ;-) ***karswell` is now known as karswell
<duud`>I just found http://snow-fort.org. It has dependency management, seems easy to use, every published library should work on an r7rs-implementation. I know guile doesn't support r7rs, I'm also not sure if it will, I also know there is guildhall, but I think I just share this here.