IRC channel logs
2023-01-14.log
back to list of logs
<flatwhatson>so, i guess with posix_spawn merged, we must be inching closer to a release? <civodul>and yes, i think we're getting closer to a release! <civodul>i'll probably merge the linker/assembler changes i posted too <apteryx>when I raise a srfi-35 exception defined with define-condition-type, Guile prints: Error while printing exception. what does it mean? <apteryx>it looks like a bug to me; I don't mind to report it if others think the same <haugh>So what's the difference between string-titlecase and string-capitalize? Are these defined in C? <haugh>So it looks like string-titlecase comes from SRFI-13 and therefore provides the start and end index parameters missing from string-capitalize. <haugh>this is why I can't bill by the hour <old>will we get the correction of source location in 3.0.9? <flatwhatson>old: yes, at least the "unknown location" regression is be fixed <old>Been waiting for this one <old>this regression gave me headache while debugging with 3.0.8 <mfiano>I despise scripting, particularly of the shell variety, but Guile makes this not only fun, but the module system really helps here because I tend to structure different layers of abstraction as re-usable modules. This has worked well for "scripting" too, because scripts mostly all have the similar boilerplate and "modules" in the form of other scripts and executables on the file system. <mfiano>That said, it isn't as fun as my usual systems or graphics programming stuff, but it is long-neglected work that needs to be done. <mfiano>I would go as far as to say that Guile is the nicest shell scripting replacement I have tried to use a language for. Raku and Julia claim to also be good here, but the startup times really hurt here, as well does the non-uniform, anti-sexp, cognitive-taxing syntax nature of it all as usual. <flatwhatson>that is a completely different approach to "shell scripts in scheme" :P <mwette>Isn't there another one scsh or something like that? <flatwhatson>yes, scsh is more like a library of scripting utilties for scheme <flatwhatson>but it seems to have fizzled out. according to the manual it inspired some of guile's libs <flatwhatson>well worth resurrection, now that we're running scheme as PID 1 <flatwhatson>in the future history books, this chapter will be "The Sacking of Scheme 48" <a12l>If I want to use procedures in file-b.scm that are defined in file-a.scm, must I then define a module in file-a.scm (e.g. (define-module (file-a))) and then write (use-modules (file-a)) in file-b.scm? <a12l>If the files are located in the same directory, do I need to add the current directory to the load path? <mfiano>1) That is the simplest method, yes. 2) Only if that directory is not already in %load-path, though you can just use guix packages to not have to manually configure that. <mfiano>For #1, you'd also have to export the symbols you wish to use. There are ways around this, but again, that's the simple way. <a12l>What do you mean with "though you can just use guix packages to not have to manually configure that"? Do you mean that if I install the files with Guix I don't need to bother with `%load-path`? <a12l>1) I only need to use `(define-public ...)`? <a12l>To export the functions I define? <mfiano>Yes, guix can manage your environment for you. <mfiano>No need to specify a load-path if you invoke the guix shell to setup a package <mfiano>define-public is just an alternative way to specify the symbols to export directly in the module definition form. <mfiano>I personally don't use define-public <mfiano>dthompson's projects are pretty enlightening for good structure. I learned a lot from them <mfiano>there, you can see his guix.scm, though keep in mind, this is using guix's gnu-build-system instead of its guile-build-system. If you don't plan on wrapping any C code in your project, you can use the guile-build-system and ignore the autotools files in his projects. <mfiano>I'm not sure if he wants so many eyes on this though :) <mfiano>I have mostly been studying the work of those two developers. They seem to know what they are doing more than me, anyway :) <old>Aurora_v_kosmose: Just though of that. You could use primitive-include of your module in your unit-testing file. That way you have every symbols, including the private one.. <a12l>mfiano: Thanks for the links! I'll use them for inspiration :D <Aurora_v_kosmose>old: That doesn't seem to be present in my manual version, is it a relatively recent change? For what it's worth, I'm planning on porting to SRFI-64 testing since it's standard. <mirai>I'm at the documentation page and I still have no idea what's it about <mirai>there's almost no examples and some pages are even near blank <dthompson>mirai: the documentation is... not great. I might be able to help. are you trying to parse xml to sxml or serialize sxml to xml? <mirai>dthompson: I want to do something much simpler (I think) <mirai>dtd/docbook.dtd -> prefix/dtd/docbook.dtd <mirai>I'd prefer not using regexps for this task and was thinking that sxml would be a nicer fit than invoking xpath through (system*) <Aurora_v_kosmose>Guile has very little for actually helping the handling of a parsed sxml/xml document. Recursive pattern matching is about the best there is built-in. <count3rmeasure>what type of object is a match structure? Meaning, if I wanted to take apart a match structure returned from regexp-exec am I performing vector operations? <dthompson>mirai: so it sounds like you *do* want to parse xml to sxml. <dthompson>that would be the first step of using sxml to solve your problem <mirai>yeah, I've got that using with-input-from-file <Aurora_v_kosmose>It should be quite possible to use that pattern matching backend in the creation of a frontend exposing CSS Selectors... but that has yet to be undertaken by anyone. <dthompson>now you can traverse the tree and transform the stuff you want <old>Aurora_v_kosmose: I meant that instead of doing a procedure that does the testing within the module. You could include the whole module, not "use it". This would allow you to seperate the testing from the actual module while being able to access private bindings <old>And it would 100% be compatible with srfi-64 <old>The equivalent of `#include' a .c file in your test file in C <Aurora_v_kosmose>old: Yeah I understood the purpose, I just don't think I *have* primitive-load available in my installed version, somehow. <Aurora_v_kosmose>Ah. I do have plain "include" though. Well. That's certainly an interesting option. <Aurora_v_kosmose>It seems to interact weirdly when including a file with a module declaration. <old>oh I most have confused with primitive-load <old>`include' seems what I was refering to <old>How so? I've never tried to inclue a module <Aurora_v_kosmose>Including a module inside another module seems to not add the importee's bindings and interferes with adding new bindings in the binder as well. <Aurora_v_kosmose>There are workarounds I can think of, but I think they'll lose in reliability & neatness. <daviid>Aurora_v_kosmose: just to recap, i lost track of the conversation, but iirc, you want to test none exported procedure(s), and iirc you are using unit-test - so why don't you just add tests as in ((@@ mod proc) ...)? <old>Sometime @@ does not work for private bindings from my experience <daviid>old - that never ever happend to me <Aurora_v_kosmose>daviid: The debug-only mention in the manual suggests that method is not recommended. Which old's experience bears out. <old>but typically that would be the easiest solution <old>I have one software that use guix-package, the module, and I needed some private binding in it <Aurora_v_kosmose>And since old mentioned SRFI-64 is a thing, I'm considering porting to it anyway. <old>It was indeed in the *.scm file, but I could not get a reference to it in any way .. <daviid>there is no other way, ime, to test none exported proc, and i do that in all my projects, it never ever failed, so far :) <old>True it should work in most cases. The other solution I proposed is to have a single public procedure in the module that does the srfi-64 testing <old>But if you like to have your tests in a different compilatio unit, then that's not what you want <old>daviid: Consider if the compiler inline a private procedure. I don't think you can get a reference to it then <old>So '@@` should work relatively well for testing. That's what I do too. But it is perhaps not a bullet proof solution. <daviid>but you test the private procedure, the you may test the one that 'inlined', those tests have 'nothing to do with ..' <daviid>but we are we are talking about testing none exported procedures, @@ should always work <daviid>or you may get the proc calling module-ref mod proc ... that should work to <daviid>if you can not refer to a none exported proc using @@ in a test-suite, it means guile has a (very serious) bug <old>I have an example here: (@@ (guix scripts package) store-item->manifest-entry) <old>You won't be able to get a reference to it <Aurora_v_kosmose>Apparently that autogenerates syntax for those predicates, rather than procedures directly. <daviid>old: then something in guix is 'in the way', but also, i was assuming none exported procedure you define(d) as a user <daviid>Aurora_v_kosmose: hopefully autogenerated syntax predicates that test if a record is a record ... are testted in guile's test-suite itself (?) <Aurora_v_kosmose>Well yes but when the test involves ensuring a procedure returned an adequate structure with the adequate value ranges, having a predicate for it is kind of necessary. <daviid>Aurora_v_kosmose: then i'd write a none exported proc in that module, where the record is being defined, that yu then may call using @@ in you test-suite <daviid>Aurora_v_kosmose: it actually seems to me that that would not be an 'autogenerated predicate' anyway, so we fall in the none exported proc (manually written predicate) case, that you may use @@ or module-ref to test it ... <daviid>but there is no need to switch to srfi-64 'because of that' - all this is perfectly possible (and more) using unit-test ... my 2c <Aurora_v_kosmose>daviid: Oh no, it's not that making a need for it. That's simply because I learned of the existence of a standard solution doing the same thing as non-standard library. <Aurora_v_kosmose>Standard > non-standard unless there's something wrong with the standard. <daviid>ah ok then :), if that's what you want ... be 'the standard' your new testing toy - but unit-test uses goops, so it is, by definition, quite supererior to 'the standard' <Aurora_v_kosmose>I can also use GOOPS with it, presumably. But yeah, it won't be based on it from the bottom all the way up. <mfiano>Aurora_v_kosmose: How is Guile treating you? I recall you in or around the Common Lisp channels, so I'm wondering what another previous CL developer thinks. <a12l>I've a procedure there I want to check if certain preconditions are fulfilled. If these preconditions isn't fulfilled, what's the best course of action? <a12l>Just have an assertion, or to send some form of symbol? <Aurora_v_kosmose>mfiano: It's fairly nice. There are some differences which I tend to stumble a bit on encountering, some things I miss, but that's to be expected. Guile has a reasonable analogue to CLOS, along with a lot of built-in extensions, two aspects which certainly influenced my decision of which implementation to use. <mfiano>Ah, cool, same here on both counts. <Aurora_v_kosmose>I tend to mostly use Guile for cases where I want something relatively portable (for the same definition of portable that'd apply to Python) without having to pass binary blobs around. <mfiano>I haven't yet used it for anything other than a Bourne-compatible shell replacement, but from the looks of it, it will be replacing a lot more than that. <Aurora_v_kosmose>It's fairly capable and since v3.0's performance improvements it's certainly usable to replace a lot of other things. <mfiano>Yes. I will probably be doing some soft-real time computer graphics stuff with it. I'm not really into making games anymore, but I still like to make pretty things :) <mwette>Right now I'm toying wih using guile/fibers work as a wayland client using the socket-level protocol. I'm just getting to the point of getting a shared buffer. (This requires use of mmap and passing fds via sendmsg.) <mirai>I can think of an AWK way for it but I'd prefer doing it all in scheme if possible <civodul>if it's a one-shot script, just use regexps <civodul>otherwise go fancy and use (ice-9 peg) or something <mwette>(define rx (make-regexp "^PUBLIC *\"([^\"]*)\" *\"([^\"]*)\"$")) <mwette>(match:substring (regexp-exec rx "PUBLIC \"hello world\" \"again\"") 1) => "hello world" <mwette>$ at end may not be wanted/desired