<daviid>apteryx: the htmlprag patch, did you write it 'alone' or were you also helped by others? asking to mention their name if ... i kind of remember others did propose at least part of the solution, but i am not sure ... ***scs is now known as Guest81063
<chrislck>if anyone can assist -- how exactly do I use srfi-180 reference implementation in guile? it's written as .sld <chrislck>is there a magic (enable-sld-read #t) mode? <roptat>mh, I'm having troubles with a regexp: (string-match "[^()\\[\\]]+" "text") doesn't match anything <roptat>I'm trying to match anything that is not a parenthesis or square bracket <apteryx>daviid: for the htmlprag patch, I wrote it alone, but tweaking the parent-constraints idea was suggested by Ricardo Wurmus and authored in Guix as commit 7854bbeb3f88ad4747b0a4ca01021ef2741f7b4e by Ludovic (as a very localized hotfix) <daviid>apteryx: ok, I will mention their contribution then, thanks ***scs is now known as Guest13375
<cousin_itt_>Is there a procedure call that you can put in source code that will cause you to enter the "backtrace" environment? I suppose I could type something silly like "(sqrt)" ... but is there some more elegant thing I could do? ***ecraven- is now known as ecraven
***berndj-blackout is now known as berndj
***edcragg0 is now known as edcragg
***drakonis- is now known as drakonis
<cousin_itt_>Is there a procedure call that you can put in source code that will cause you to enter the "backtrace" environment? I suppose I could type something silly like "(sqrt)" ... but is there some more elegant thing I could do? <dsmith>roptat: Try "[^][()]+" See: man 7 regex. The key to get a ] in a character class is have it first or right after ^ <dsmith>scheme@(guile-user)> (string-match "[^][()]+" "text") <dsmith>scheme@(guile-user)> (string-match "[^][()]+" "[(text)]") ***scs is now known as Guest28582
***scs is now known as Guest91961
***scs is now known as Guest53508
***scs is now known as Guest33678
***^_ is now known as V
***vup2 is now known as vup
<mdevos>Is it posible to define keyword argument functions in C? I can't find the documentation <sneek>Welcome back mdevos, you have 1 message! <sneek>mdevos, lloda says: one thing I do when editing Guile code is disable trailing whitespace removal. Unfortunately Guile code has a lot of that and if you have autoremoval on, the diffs will be very dirty. ***scs is now known as Guest28120
<civodul>mdevos: i think you'd have to manually fiddle with rest arguments <civodul>anyhow, i recommend doing the heavy lifting in Scheme <mdevos>Problem is, I'm trying to bring openat, fchmodat, ... to guile, and my plan is to introduce a ‘file-in-directory object’ (essentially a directory port + name pair), and the constructor would take keyword arguments <mdevos>like this: (make-file-in-directory DIR NAME #:follow? #t/#f) <mdevos>I guess I could define the 'file-in-directory object' & constructor in Scheme in boot-9.scm (or something included from there) <mdevos>and define a C function for C users that's less keywordy and just calls the Scheme procedure? <civodul>dunno, you could omit the C function <civodul>as another rule of thumb, for POSIX bindings, i recommend first providing functions that are a 1-to-1 mapping to the C function <civodul>before building abstractions on top of it <mdevos>civodul: I suppose I could do that <mdevos>I'll write binding to openat, fchmodat, fchownat, utimensat, readlinkat, fstatat and fchdir. Any requests? <civodul>wingo: looks like custom binary input ports are buffered by default; perhaps a mistake? <civodul>wingo: i was expecting it to be unbuffered by default since it's a "user port" <civodul>but i think it's always been this way anyway <civodul>another question: looks like 'drain-input' doesn't clear the putback buffer, amiright? <wingo>appears to clear the putback buffer, for me <mdevos>civodul: may the "chdir" / "scm_open" procedure be extended to allow ports as well? That's technically not a 1-to-1 mapping from C<->Scheme, but there's precedent with "chmod" and "chown" <wingo>no, seems to work properly for me <wingo>scheme@(guile-user)> (open-input-string "bc") <wingo>$8 = #<input: file 7f27fe656150> <wingo>scheme@(guile-user)> (read-char $8) <wingo>scheme@(guile-user)> (unread-char #\a $8) <wingo>scheme@(guile-user)> (drain-input $8) <wingo>basically drain-input collects and returns buffered input. but having a mental model on what's buffered is a little tricky <wingo>buffered input includes the putback buffer and may include a portion of a read buffer <wingo>(but drain-input is a funny procedure, i can't think of many ways to use it correctly) <civodul>yeah it's only useful to ensure there's no buffered input IME <wingo>why would you want to ensure that? :) <civodul>in cases where i then pass the underlying file descriptor to some other piece of code <civodul>usually not a great situation to be in, but that happens :-) <civodul>anyway i'm fighting with a situation along these lines, looking for extra buffering in a maze of ports :-) <wingo>civodul: is it necessary to buffer on the zlib side? i guess so, given that you don't know how much input corresponds to how much output <wingo>ideally you buffer only on the guile side fwiw <wingo>when guile needs more it will call the read function with the number of bytes it can take <mdevos>how can I verify whether an object is an open input port with a file descriptor from C? I don't quite understand the "object = SCM_COERCE_OUTPORT (...)" assignement in scm_stat and I would rather not cargo cult copy <wingo>SCM_VALIDATE_OPFPORT (SCM_ARG1, port); <mdevos>(I also need the fd, would SCM_FPORT_FDES on the port itself work?) <mdevos>wingo: I'll just use that, though I wonder what SCM_COERCE_OUTPORT is supposed to do in scm_stat <wingo>right, so that is a strange thing that is not well tested -- there is a thing called a "port with a print state" <wingo>which is a little object that wraps a port and includes a hash table of what's been written <wingo>to allow circular data structures, i think <wingo>but i have rarely had to touch that <wingo>anyway sometimes you can pass these to port-using procedures, and SCM_COERCE_OUTPORT can take either a port or a port-with-print-state, and returns just the port <wingo>i don't think scm_stat needs to do that fwiw <wingo>and i don't think mkdir would need to do so either <wingo>a crufty thing from days of yore :P <civodul>wingo: guile-zlib doesn't actually buffer; it makes sure the user's port is unbuffered before passing the underlying FD to zlib <mdevos>To check whether readlinkat is supported (and work around some platform-specific bugs), I thought of using gnulib's readlinkat module at first, but it's GPL and Guile is LGPL <mdevos>any particular reason it's not just GPL? ***scs is now known as Guest72330
<leoprikler>if Guile was GPL, all Scheme code written in Guile would need to be GPL as well, which is not very feasible <mdevos>leoprikler: do you know any such code? <leoprikler>civodul: "not very feasible" is my personal way of saying infeasible. <civodul>it's not about feasibility, it's about choice <civodul>it's a choice some may not like, but it's entirely "feasible" <mdevos>leoprikler: all SRFI's implemented in Guile are LGPL or GPL, or compatible, I hope <leoprikler>mdevos: they're at least LGPL/GPL-compatible, but if you write your reference implementation in Guile, you need to license that under the SRFI license, which is the same as Expat IIRC <taw10>Think about it: would all the code in SICP suddenly need to be GPL just because it can be run with Guile? <leoprikler>"When the interpreter just interprets a language" <mdevos>Guile is more than an interpreter for a language, it also comes with a few libraries of procedures <leoprikler>If you use any of Guile's own facilities not specified by RnRS, e.g. its module system, you're effectively in GPL enforcement territory. <mdevos>What I was originally asking for, was there any particular reason for using the LGPL instead of GPL for Guile in? (And would there be compatibility problems if guile would switch to GPL) <civodul>mdevos: it dates back to 25+ years ago, so we can't say for sure, but it's probably the same reasoning as for making libc LGPL <mdevos>(I haven't ever heard of propietary applications build on guile. I don't care about those, they can find another Scheme interpreter/compiler + library implementation.) <leoprikler>Well, there are more Scheme implementations than C libraries, so a naive interpretation of that statement would hold. <mdevos>Hmm, all the *at gnulib modules are all GPL: readlinkat, chmodat, chownat, faccessat, fchmodat, fchownat, fstatat, linkat, mkdirat, mkfifoat, openat, opendirat, renameat, statat, symlinkat, unlinkat, utimensat <mdevos>Would it be possible somehow to only import m4/readlinkat.m4 from gnulib, but not gnulib's C replacement / wrapper, without messing up the build system? <mdevos>(make dist & future gnulib-tool --add-import) <mdevos>(m4/readlinkat.m4 itself has a permissive license) <dsmith-work>In ages past, Guile was GPL, with a special permission/exception/something. This is from before there was a LGPL. <mdevos>... that didn't actually happen (Guile everywhere). The only propietary software I've seen it in were personal pet projects, and all the free software I've seen it in are GPL or compatible <mdevos>(LilyPond, TeXmacs, GnuCash, some librariesà <leoprikler>"All the free software are GPL or compatible." Because people don't really want to make GPL-incompatible software? <mdevos>leoprkler: in case I wasn't clear: ‘All the free software **I've seen it(Guile) in** are GPL-compatible’. <leoprikler>Most people, who write non-GPL free software, choose a more permissive license (e.g. Expat). <mdevos>I guess my argument is (1) switching to GPL wouldn't cause trouble for anyone and (2) it's convenient to be able to use GPL modules from gnulib <rlb>If I'm reading it right, I'm wondering why/if shared mutable substrings really need to keep the extra indirection through the source string, i.e. could they just point directly to the source string's buffer... <taw10>Hmm, any other examples of the license status of a program depending on which extensions you use in that language? Because I don't think it works that way. e.g. the GPL FAQ I linked to doesn't say "... as long as the interpreted program only uses some standard-compliant subset". Do your programs need to be GPL because you used a GCC extension, for example? On a quick look, the GCC manual doesn't warn <taw10>that using certain extensions come with strings attached. I'm not talking about the GCC runtime exception - that's different because it's about code actually getting copied into your executable <taw10>What I do agree with, however, is that making non-GPL *extensions* to Guile (i.e. linking against libguile) would be impossible if it were GPL, which could be regarded as a bad thing. <leoprikler>That does not apply here, because you can execute a GPL program to do anything. <leoprikler>If you only used Guile to compile to Guile bytecode and then ran your Guile program on your own proprietary Guile VM, you wouldn't violate the GPL. <taw10>Of course, what you do in private is irrelevant. I'm reading all of this under the assumption that we're talking about publishing an "interpreted program" under a proprietary license <leoprikler>I meant that as in "if you published your proprietary Guile VM and used standard Guile to compile your proprietary Guile code". <taw10>Your logic seems to be that using Guile-specific features makes your "interpreted program" become a "derivative work" of Guile. Did I misunderstand that part? <taw10>If I did misunderstand, then I don't follow where the GPL requirement for the "interpreted program" comes from <taw10>If I didn't, then I don't understand why publishing a proprietary program running on a proprietary VM would be OK <civodul>a GPL'd Guile would be like Emacs: one can publish non-GPL code (in practice, extensions or users of Guile-provided modules), but it must be GPL-compatible and the combination is GPL <civodul>that said, i think this so-far theoretical discussion is going a bit far :-) <leoprikler>which is different from LGPL, which lets you publish derivative work under any license (without limitations to compatibility and combination) <mdevos>unless Guile's LGPL / GPL situation changes, I'll just copy m4/readlinkat.m4 and use that (that's under a permissive license) & #ifdef HAVE_READLINKAT, and ignore gnulib's replacement functions *mdevos pretends to be afk again <leoprikler>that should be possible since we're already in the posix-specific part <leoprikler>Guile's filesystem stuff has two versions depending on whether you have the 'posix feature. <mdevos>leoprikler: I follow even less know. scm_readlink is in filesys.c, not posix.c -- and now I see _POSIX_C_SOURCE is not always defined due to reasons (stime.c). grrr incompatibility ***scs is now known as Guest10881
***leoprikler_ is now known as leoprikler
***scs is now known as Guest28001
<ArneBab>mdevos: from my perspective, now running Guix, Guile is pretty much everywhere I look :-) <manumanumanu>wingo: saw you merged the patch. I should really update my name in my git config. Even I react when I see my first name in a commit log <manumanumanu>did you see my other comment? That the two (map ...)s of rnrs base and (ice-9 boot-9) do the same? <manumanumanu>The r6rs one is much nicer, but slightly slower (because of being pure gulie. Not by much, though. <manumanumanu>anyway, I have to drill things tomorrow. The heavy responsibility of owning a house and all that. Good night! <wingo>manumanumanu: is the r6rs one the same? <wingo>i didn't see the other comment btw <wingo>anyway we can follow up later :) <manumanumanu>yup. same constraints and everything. the one in (r6rs base) has better error reporting and is much nicer <manumanumanu>if you pass the boot-9 one an non-proper list you get an error in (length ...), whereas (rnrs base)-map has a correct error message and everything. Regarding the speed: my test was a simple repl test: ,time (rnrs:map 1+ a-long-list-from-iota). <manumanumanu>wingo: but today the map from rnrs base is faster on that benchmark of a 10000000 element list <manumanumanu>i might have been wrong. if so: the map from (rnrs base) is sliiigtly faster and produces better error messages. <wingo>map benchmarks are squirrely, depends on heap size, whether a collect happens or not, etc <manumanumanu>It seems boot-9 map has a wider run time (0.32-0.7s), but averages lower than rnrs:map, which consistently scores 0.43-0.45s <manumanumanu>boot-9 map transverses the list more times (doing more or less (= (length l1) (length l2) ...) which conveniently errors on improper lists), whereas (rnrs base)-map is more elegant <wingo>civodul: my release to-do is currently just mkstemp, and preparing for mkstemp! deprecation (not yet tho as not enough time) <wingo>everything else done, except any mingw things that spk121 would like to land <civodul>i'd need to look at that -Wunbound-variable thing now <wingo>anyway i look forward to the patch ;) ***scs is now known as Guest23264