<madsy>Does churning #t and #f through scm_to_int32() yield 1 and 0? <mark_weaver>or alternatively 'scm_to_bool'. 'scm_to_bool' will only accept #t or #f. 'scm_is_true' will return 1 for anything that's not #f, following the Scheme convention. <madsy>Yeah I settled for scm_to_bool <didi>Does guile have an sexp-based regexp? <didi>dsmith-work: Hum, I think I've never used it. <didi>The "package thingy", I mean. <didi>Also, what is "irregex"? <dsmith-work>"This SRFI provides a library for matching strings with regular expressions described using the SRE "Scheme Regular Expression" notation first introduced by SCSH, and extended heavily by IrRegex." <didi>`guild' is not being too helpful. It asks me to input commands for help but doesn't seem to list them. <didi>dsmith-work: Thanks. Tho then I assume there is no such thing inside guile's distribution. <didi>Is anyone working on one? <mark_weaver>didi: I'm going to add SRFI-115 when it's finalized. <didi>mark_weaver: No no, I didn't. <didi>I'm excited to see it happening. <mark_weaver>yeah, sexp-based regexps are definitely the way to go. <mark_weaver>didi: in the meantime, you can install guildhall and use irregex. there are probably some minor differences, but I doubt it would be hard to port whatever you write for irregex to use SRFI-115 when it's built in to guile. <didi>mark_weaver: Thank you, but as I don't have a pressing need for this nor I know how to use guildhall, I'll wait for your implementation of SRFI-115. <davexunit>mark_weaver: just tried out the REPL server with guile-2d. looks good! <davexunit>didn't get to see the movie because there was a giant line with people that showed up hours in advance, so I went to bonchon and tested the coop repl server instead. :) <mark_weaver>cantstanya: #guix is probably a better place, but the primary devs are asleep now (european time) ***Fuuzetsu is now known as Guest63073
***Guest63073 is now known as Fuuzetsu`
***Fuuzetsu` is now known as Fuuzetsu
***Fuuzetsu is now known as Guest75490
<zRecursive>wish somebody could build guile-2.0.9 for freebsd. there is only 1.8.8 in freebsd repo :( <mark_weaver>zRecursive: someone has prepared a Guile 2 port for FreeBSD, and plans to get it upstreamed after 2.0.10 is released. <mark_weaver>zacts_: what's the status of getting your new bdw-gc-pthreads package into freebsd? ***Fuuzetsu` is now known as Fuuzetsu
<zacts>mark_weaver: hey, yeah. I'm working on it. I had a bit of homework catch up with me, but I should have a devel/boehm-gc-pthreads PR ready to submit in a day or so. (don't know how long it will take to be included in the ports tree). <zacts>but I am working with another FreeBSD ports developer on this also. <zacts>I'm aiming for having everything imported by the timeframe you gave me for the guile-2.0.10 release <zacts>working with both upstream FreeBSD and upstream guile which are you guys.. :-) <zacts>devel/boehm-gc is currently a problematic unmaintained port. I'm working directly with kwm on #bsdports @ irc.efnet.org on this. <zacts>zRecursive: you can help if you wish! do you have FreeBSD-10 installed? <zacts>(even if just testing the ports in an ezjail) <zacts>ah, that's ok. I'll try to get some patches / diffs / and shars ready tonight. <zacts>ok, yeah. I will do what I can to get my ports ready by the time guile-2.0.10 is out. <zacts>zRecursive: if you like you may /msg me anytime, to be updated on progress. <zRecursive>What is the best way to determine whether or not "xxxxxx" is in a file with data as "****** aa bb cc\\n ******dd ee ff\\n ..." ? ***zRecursive is now known as zRecursive{away}
<nalaginrut>zRecursive{away}: try grep (and please ask Guile relative questions) <LRN>i don't really use guile though, so this is mostly of academic interest <LRN>well, to have it as a dependency <mark_weaver>sorry, I don't mean to be nosy. you needn't answer, I'm just curious. <LRN>for gnutls, i think :) And it turned out that gnutls needs popen which is removed by --disable-posix, so effectively i've got nothing out of guile. Although maybe there are other packages that use guile, i just didn't pay attention <LRN>I know for sure that autogen (the binary) requires guile, and there are packages that use autogen <LRN>So this is not entirely useless (unlike Ada) <mark_weaver>the interesting thing is that a long time ago, you sent me a build script you used to build guile on windows, and you didn't pass --disable-posix in that script. <mark_weaver>but I think maybe you added it because things weren't working as well on windows back then. <mark_weaver>(mainly we've benefitted from improvements in gnulib) <LRN>yes, i think --disable-posix was a direct result of you guiding me in debugging guile hangups back in the day <LRN>currently i don't care enough about guile to do anything about this. Maybe if guix project devs figure out how to make it W32-compatible, i'll give it a thought <mark_weaver>guix certainly won't be targetting windows at all, but we'd like to support windows better. it seems that madsy is interested and willing to help, so maybe there will be progress now. ***zRecursive{away} is now known as zRecursive
***forgottenwizard is now known as ZombieChicken
<wingo>good morning/evening, mark_weaver :) <zacts>I think guix is a great project. <mark_weaver>zacts: did you see my message earlier about the new tarball with hopefully better windows support? <zacts>mark_weaver: I'm skimming backlog now <zacts>I can test that in a windows vm if you want <zacts>(I currently have to use winblows for a course I'm taking "Intro to computers") <zacts>It's required! I hate it, but oh well.. <zacts>mark_weaver: anyway, I do have an 'it works!' boehm-gc-pthreads and guile-2.0.9/guile-2.0.10 port on FreeBSD <zacts>I'm about to email it to my ports mentoring dude. <mark_weaver>zacts: oh, I'm sorry, I got mixed up. I meant to tell madsy about the patches, not you. <mark_weaver>zacts: nevermind about the windows. don't waste your time on it. <zacts>\\o/ - less windows usage for me <mark_weaver>zRecursive was wanting the FreeBSD Guile-2 package also. <zacts>mark_weaver: yep, I chatted with him a bit. <zacts>mark_weaver: sent an email to my ports mentor.. <zacts>with the patches for initial progress with guile. next we are going to clean up the patches, and then submit to the ports mailing list. <taylanub>zacts: FYI third-person pronouns are acceptable as gender-agnostic pronouns in English. (And then there's made-up ones but not many people recognize them so it can cause confusion.) <zacts>taylanub: I'm a native speaker, but often type fast.. <zacts>taylanub: his/her when I don't know. ^_^ <mark_weaver>taylanub: I'm a native speaker too, and I think your statement is not really true. <mark_weaver>well, I'm sure that the average male finds it acceptable to use male pronouns by default, but that's not saying much. <zacts>I usually say "him or her" or "they"/"them" <taylanub>Oh uh, I didn't mean third-person .. what's the correct term .. they/them/their <zacts>my English teacher 'corrected' my use of they/them/their to 'his or her' <mark_weaver>there are a lot of different opinions on this topic. <taylanub>(Looks like I'm the only non-native speaker here ATM, after all. :P) <mark_weaver>civodul: is a non-native english speaker, but you wouldn't know it. his written english is better than most native speakers I know :) <civodul>i guess you could tell it when you hear me though ;-) <mark_weaver>well, yes, you have a noticeable accent, that's true :) <mark_weaver>and actually, not worth the effort for you anyway. there are more important things to work on. <taylanub>BTW a macro-wrapper for my bytestructures is difficult after all. :( On ref/set operations, I'll need either to expand to code that makes n record-field references for a compound descriptor of depth n (e.g. (1)vector of (2)struct of ... (n)uint32) because the bytevector-ref/set procedure to be called is found in the deepest descriptor (uint32 in our example), or find some alternative to injecting procedures into macro output (like <taylanub>introducing top-level gensyms that get bound to the correct objects at program start). <wingo>taylanub: make the macro define a macro <wingo>project name not really chosen yet <taylanub>I'll take a look but, the goal in my case is to re-use the procedural implementation as much as possible. I'd like it to use the same "bytestructure descriptor" objects for both implementations. <taylanub>Otherwise I think the problem would be mostly solved if I changed my descriptor objects to work on the syntax domain and save identifiers naming procedures, instead of procedures themselves. <wingo>you could define a syntactic implementation and use it to generate a procedural implementation. <civodul>we need the packed struct thing in core Guile at some point *wingo going to try to compile figl's particle demo inner loops to assembly today :) <taylanub>I think bytestructures generalizes packed-struct quite a bit, just lacking the compile-time offset calculation as of now .. <wingo>nalaginrut: it will use master but it will be a special-purpose compiler <wingo>nalaginrut: it's fairly stable, yes -- i'm not compiling from bytecode though <mark_weaver>nalaginrut: there might still be some small changes though, such as add1/sub1 --> add-immediate <nalaginrut>mark_weaver: you always elaborate it precisely, but it's appreciated, thanks for explaining ;-P *wingo loves extending the compiler without restarting <taylanub>What would you recommend for protecting an object from the GC until a certain point in Scheme code ? (I'm using the FFI in funky ways.) Something that will be immune to even the most aggressive optimizer. I'm thinking (with-output-to-file *null-device* (display object)), maybe there's a better way. This is for a contrived piece of test-suite code by the way, no worries about how unusual it is. <taylanub>I decided to go with (display (eq? #f obj)) to prevent a potentially costly `display'. (Really just bikeshedding here...) <dje42>civodul: re: the libgc 7.4 issue you found: There's now a guile component in gdb's bugzilla if you want to file a bug report <civodul>fortunately, there's jemarch's fancy bugz-mode <TheBrayn>I want to write a function that tries to match a regex which is passed to that funktion with a string, how can I validate this regex? <civodul>TheBrayn: you can try to instantiate the regexp, with 'make-regexp' <TheBrayn>and how can I catch an error if the regexp is invalid? <civodul>'make-regexp' throws an exception if the regexp is invalid <saul>Good news: GNUcash 2.6.1 has been released; which is the first stable version with support for Guile 2.0 . <wingo>man, i complain about tests, but i love our peval tests. <wingo>we should figure out a way to test cps also, but it's so much more verbose that there's more churn <wingo>maybe now that things have settled down... <wingo>,optimize (let lp ((n 1)) (if (= n 1) (let inner () (inner)) (lp (1- n)))) <wingo>^ interesting case that doesn't peval <wingo>it tries to do so, but the inner loop exhausts the effort counter and the whole "lp" unrolling attempt aborts <wingo>this prevents my "parallel-iota" thing from fully unrolling even when you specify that you only want to use one core <ArneBab>Is there already a version or preview-version of lilypond which supports guile 2.0? <madsy>ArneBab: No idea. Ask the lilopond devs? :) <ft>So, why would this work: (dynamic-link "libm"), while this doesn't: (dynamic-link "libc")? [yet, (dynamic-link "libc-2.13") does] <saul>ArneBab, Lilypond released a stable version just before the end of the year that presumably supports Guile 2.0 (woot!). <ft>wingo: that's an idea, I'll try that. <ft>civodul: doesn't that return a handle that covers every symbol available at the time it is run? <civodul>ft: yes it does, but that typically include libc symbols <saul>ArneBab, version 2.18 . I say presumably because the previous 2.17.x dev branch supported Guile 2.0 <ft>wingo: It tries to "open("/usr/lib/x86_64-linux-gnu/libc.so", O_RDONLY) = 5" which apparently succeeds, but it still goes on to try "open("/usr/local/lib/libc.la", O_RDONLY) = -1 ENOENT" next. <ft>wingo: With libm, it does "open("/usr/lib/x86_64-linux-gnu/libm.so", O_RDONLY) = 5" and that's seems to be it. <ft>civodul: That's probably true, but I thought, it might make sense to limit scope... And now I'm mainly wondering why this doesn't work. :) *ft installs ‘libtool-doc’ <ft>Ah, I think it bails out because /usr/lib/x86_64-linux-gnu/libc.so is a GNU ld script <ft>Yes, and the libm.so in the same place is an actual ELF file. <ft>well, it's a symlink to an actual ELF file. <ft>Feels like a can of worms. So, I guess I'll go the (dynamic-link) route. ***dsmith-w` is now known as dsmith-work
<ft>Until guile compiles to machine code, there's no way around that, I guess. :) <ft>dje42 had exactly my problem not so long ago. Seems like I wasn't paying attention. :) <ft>dje42: Did you get anywhere with (dynamic-link "libc")? <dsmith-work>ft: Even direct to machine code, it will still probably use some C lib functions. <ft>dsmith-work: Even if the program is trivial? Like, compute (* 2 3) and return that to the system? <davexunit>I don't have anything for the potluck again. :( <ijp>I remembered the last two times, but I doubt I'll have anything this year <stis>I hope that a prolog feature in a guile potluck is not like swearing the church ;-) <taylanub>Wonder if I can fix a macro implementation of my bytestructures by then. <davexunit>I wonder if I can make a guile-2d demo or something... <madsy>Can I somehow list all the exported symbols in a package? :) <madsy>I'm using geiser if that helps <ijp>,b / ,binding will tell you the ones bound in the current module <madsy>I'm adding stuff to a module I defined in the C API, so I want to make sure that works like I intended <madsy>That is, I created a module (guile-demo opengl) in the C API and added all my OpenGL entrypoints there. Now I want to add a couple of macros to the same module, but from scheme <dsmith-work>madsy: Typically, there is also a .scm module that loads the C code from a .so and then exports things. You can add macros there. <madsy>dsmith-work: Yep, I will. Except the OpenGL bindings are added to the binary itself (i'm using libguile not guile), so I don't need to use load-extension <didi>People, we need a better manual organization. The only way I can do it is by knowing the location of a specific section or by C-s inside the Info manual. <ijp>didi: agreed, there are a bunch of issues with organisation, but it's an unsexy task to fix <didi>mark_weaver: I don't. Useful feature, thank you. <didi>I feel things are all over the place. <mark_weaver>didi: I agree with you. Are you volunteering to fix it? <didi>Also, it's not like the information is not there. It's just awkward to find. <didi>We could, for example, turn the manual inside-out a little. For me, "API Reference" feels like /the/ manual. <didi>"Guile Modules" could be merged with "API Reference" (after changing its name) and the functionality, rather than the modules, be presented. <mark_weaver>didi: I agree with all of that, but talking about it is easy. someone needs to actually do the work. <didi>mark_weaver: Right right. <didi>I don't know how the project feels about it, but the manual could turn down a little the guile capability of being a library extension while turning up the fact that it's a full fledged Scheme implementation.