<str1ngs>hello daviid, tried all of the tests with gtk4 all the gtk 4 examples work okay. anything specific I should test? <daviid>str1ngs: oh, nice! so guix has gtk4 then, great - no, if those example work, well at least guix users may use g-golf ... <str1ngs>daviid: not quite yet. I'm working off of a staging branches with ML patches. <str1ngs>also is this avoidable? (gi-import-by-name "Gtk" "Window" #:version "3.0") <str1ngs>wonder if you could just use clutter. or is there no way to avoid using gtk as a dependancy? <daviid>str1ngs: no, tyhose tests that require a specificversion,require a specific version ... <daviid>str1ngs: so, the build shouldn't run any test and not depend on gtk,nor clutter ... <str1ngs>I was wondering if you can avoid using Gtk in the tests. clutter is not as bad IMHO. but if it can't be avoided that's understandable <str1ngs>daviid: I think for guix it's okay to skips tests then in regard avoiding pulling in multiple version of gtk WDYT? <daviid>who installs g-golf shouldn't need any lib, except glib, gobject and gi <str1ngs>these are here for tests. if we skip the tests we don't need to pull in gtk or clutter. simplifies things <str1ngs>maybe I could just remove hl-api.scm for the tests. so we don't miss everything. <str1ngs>ahh nice ;; (define %libgdk (dynamic-link "libgdk-3")) is not used anymore :) <apteryx>interesting; I got my thing working to collect forked process output via a pipe in mcron, and it works well by itself, but when run inside with Shepherd, which does its own fork + redirection of the service process (mcron), the output becomes garbled. It's as if there was some kind of echo effect, with the same output getting added multiple times per flush. <apteryx>So these are all related process: parent (shepherd) -> mcron -> job, but I find it strange that doing some stdout & stderr redirection to a pipe at the level of mcron/job has some effect at the level of shepherd/mcron. <apteryx>if you have clue, I'm interested :-) <apteryx>hmm, apparently in C we can't duplicate a file descriptor using dup2 multiple times; I believe this is what is happening here (stderr and stdout are duplicated at the level of Shepherd & mcron) <apteryx>Hmm, OK, so as soon as I simply redirect output to a file with > in the shell, I can reproduce the same behavior. I've leared that duplicating the stdout & stderr file descriptors in a program with dup2 is not a good idea. <apteryx>(unless that program is not expected to be used by a user directly, perhaps) <apteryx>I wonder if there are viable alternatives to dup2? The requirement is to have the ability to capture the output of a child process to post-process it (annotate it with some metadata), and ideally this should be resilent to whatever redirection may happen in a managing process. <daviid>str1ngs: yes, i got rid of the dependency to libgdk-3 quite a while ago, so that users may choose to work with the gtk version of their choice ... achieving that goal wasn't that easy ... See the 'II. Using G-Golf - Working with GNOME - Events' section for more on this (as a user) ... <apteryx>ah, it appears it was just this :-) calling (flush-all-ports) before forking fixed it <apteryx>bah... not in shepherd. the output is completely suppresed now. <apteryx>nevermind, it appears to work after all, but there's another glitch that made me thought it wasn't. <str1ngs>daviid: nice I think I can also substitute tests that import Gtk. so we can get as much test converge on guix as possible. nice thing is (unit-test) uses the test prefix. <daviid>str1ngs: don't spend any time on this, my advice ... rather, just make sure that who updates the guixpackage does run the tests, but who installs don't ... <str1ngs>well the test are run at build time either the tests work there or the do not. <daviid>str1ngs: i will get rid of the clutter tests dependency, but gdk/gtk[/gsk] unlikely ... we'll see (i will see :) <daviid>str1ngs: more imprtant is to fix, if possible, the guix 'bug' with that respect ... <daviid>anyway, i won't work on tests now ... <str1ngs>I think these test show case the bug so might be good idea to investigate. don't make any changes that take time for now. <str1ngs>for guix we can disable tests with the understanding why. I do run tests locally with guix and test with nomad which is non trivial. <str1ngs>daviid: interesting I don't run into this guix bug at runtime right now. only build time during tests. not really and issue with the tests. kjust wondering if the added dependencies are pulling causing differ cluttters and gtk's <daviid>i don't think so, it really is 'a guix bug' ***sneek_ is now known as sneek
<apteryx_>is it possible to specify in a format string which positional arg to be used for a given format specification? <apteryx_>the use would be to tell the users of a program "you may provide your own format string to control the output; the arguments applied to format are x, y and z", and then documenting the feature of (ice-9 format) to use if they'd prefer a different ordering. <apteryx_>hmm, ~@ seems about left padding instead of right padding, no? <apteryx_>~* and ~:* can be used to skip (jump) positional args, but that seems ackward to use <apteryx_>I'd like something like ~N<format> where N is the positional argument position <leoprikler>i think you need such a thing for pure i18n anyway <lloda>i think i would just let users pass f(x y z) -> string <lloda>programming in ice-9-formatese isn't pleasant <apteryx_>lloda: the nice thing about a format string is that it can be easily provided from the CLI <apteryx_>and safer than evaluating a sexp string, I reckon <apteryx_>so yeah, (format #f "~2@*~a ~1@*~a ~0@*~a" 1 2 3) --> "3 2 1" <apteryx_>it's a bit of a mouthful, but that'd be an edge case anyway <apteryx_>yikes, I thought (ice-9 format) could handle date formatting directly, but it seems not? <apteryx_>I was expecting something like some modifier to introduce a srfi-19 format in the mix <apteryx_>the CLI will have to be --date-format=X --log-format=Y ;-) <apteryx_>I tried (catch 'bad-date-format-string [...]) but that didn't catch it *apteryx_ is forever a noob with the exception mechanism of Guile <chrislck>apteryx_ not your fault. you should learn read guile source. srfi-19.scm says it's 'misc-error you need to catch <chrislck>(catch 'misc-error (lambda () (validate-date-format "~O")) (lambda args (display "bingo"))) <apteryx_>misc-error? OK, that seems narrowly better that (unless (false-if-exception (validate-date-format "~O")) do-something) :-) <apteryx_>and good advice, I'll try to get more proefficient at that <apteryx_>Geiser seems helpful, when the code is Scheme. I could probably set it up to track C sources as well. <apteryx_>ah, the srfi-19 source has in comment above time-error: ;; FIXME: should this be something other than misc-error? ^^ <apteryx_>is it possible to capture standard error via with-output-to-string É <apteryx_>instead of trying to capture the error message, I went with just checking the exception key <apteryx_>vijaymarupudi: oh, I hadn't realized with-error-to-string was a thing <apteryx_>but sometimes a simple way to capturing both would be handy, is there a facility for this too? <vijaymarupudi>I don't know of one that does both, but you can make your own version with set-current-output-port and the -error equivalent <manumanumanu>vijaymarupudi: sorry, havent been online in 2000 years. nice work on nectar <manumanumanu>Then you can just define renderers for most structured data as sxml-folds. <manumanumanu>and the HTML-renderer will be 20 rows of code, because it handles all escaping for you <manumanumanu>whoa! I have been hunting a bug for some time and I have not been able to figure one certain case out. Turns out: confusing hashq-ref and hashv-ref works sometimes. <manumanumanu>is there any reason the native ones haven't been deprecated in favour of something sane? Sure, hash-tables are common enough that deprecating the canonical interface is bound to make people upset, but maybe for a future guile-4? <vijaymarupudi>manumanumanu: I wasn't aware of sxml at the time I made the library, also it was a learning exercise <manumanumanu>you should have a look! next time it will save you a bunch of tree folds :) <vijaymarupudi>I'm planning to expand it soon once I have time, maybe then I might base it on sxml! <vijaymarupudi>The documentation is a bit spotty the last I've looked at it <manumanumanu>racket might add some small utility functions, but I haven't found any yet. ***vijaymarupudi_ is now known as vijaymarupudi