<jlicht>leoprikler: thanks! Binary I/O is where it's at, I guess :-) <leoprikler>you could also try line-delimited stuff from textual IO, but lines are overrated imo <Bob131>Hi. I'm working on a parser-generator that takes regexes encoded in S-expressions and produces a DFA represented as a table for a table-driven scanner. I was hoping to do the table generation at compile-time, but that plan came undone when I found that the Guile VM assembler can't intern procedures <Bob131>I'm a little bit stumped as to how to salvage the situation. I'm curious as to how some seasoned Schemers might approach the problem? ***dftxbs3e__ is now known as dftxbs3e
***catonano_ is now known as catonano
***iltutmus is now known as Guest42020
<apteryx>hello! are guile syntactic extensions (define-syntax-rule ...) global? <apteryx>e.g., if something uses the module they are defined within, they'll be available even they were not "exported", correct? ***nly is now known as nly-on-arm
***nly-on-arm is now known as xXx-nly-GoDsLaYe
***xXx-nly-GoDsLaYe is now known as nly-zweihander
***nly-zweihander is now known as vits
***vits is now known as vits-ushanka
<daviid>apteryx: no, you must export or re-export or re-export-and-replace <apteryx>OK! Thanks for clearing that up. That's better. ***vits-ushanka is now known as nly
***apteryx is now known as Guest15218
***apteryx_ is now known as apteryx
<jlicht>If I use read-elisp to read some elisp (surprising, I know), how do I get it written as a 'pretty' string again? Currently, elisp's backtick ("`") gets turned into "#{`}#", which can't be read by normal Emacs. <jlicht>likewise for elisp's vector notation: "[x]" -> "#(x)" <xelxebar>Does guile have any procedure for getting cpu info of the executing machine? <xelxebar>Something like the moral equivalent of lscpu or /proc/cpuinfo? *nalaginrut had identify the nick, now he can speak <nalaginrut>xelxebar: (current-processor-count), however, it's only for cores <nalaginrut>wingo: could you take a look at my mail about record in the mailing-list? <xelxebar>nalaginrut: Thanks. Really want to inspect the flags. <xelxebar>Actually, I *really* want to detect avx/avx2 support. <nalaginrut>maybe someone should write a small lib for cpuinfo ***gagbo_ is now known as gagbo
<rekado>I wonder if we should reconsider the decision to only implement the bare minimum of elisp in Guile. <nalaginrut>xelxebar: if you just want an oneshot program, maybe you can just parse it with regex <rekado>it made sense to just do a little and hand over to Emacs as soon as possible, but I wonder if it would make sense to get more of elisp into Guile. <xelxebar>nalaginrut: Hrm. That might be a fun project. In this case, I know the script will be executing on linux, so parsing /proc/cpuinfo is an option, but I thought there might be a ready-made solution already. <nalaginrut>rekado: I haven't followed for a while, didn't it support elisp smoothly? <nalaginrut>xelxebar: well, folks are too low-profile in Guile community. Sometimes I thought there was not any existing solution, then I wrote it, then I realized there's some good solution in certain corner. <nalaginrut>I do think we should have a better way to publish folks' projects to avoid redundant work <nalaginrut>it's better to let them publish by themselves. I think there's someone who are collecting existing projects occasionally, but it's not an very efficient way. <wingo>nalaginrut: is that the one about "match" and r6rs records? <sneek>wingo, nalaginrut says: could you take a look at my mail about record in the mailing-list? <wingo>yeah :/ i didn't realize that change was user-visible, i.e. i didn't know that people used match on r6rs records <wingo>the 3.0 behavior is better for performance and memory fwiw. but i sympathise with it being an unexpected change that causes needless work for you <nalaginrut>I use it a lot, actually, it's very convenient, I'd like to advocate about this usage <wingo>if you prefer to match on "hierarchies" via composition rather than inheritance, it would be possible to use a different record facility that preserves the old behavior <wingo>like a non-r6rs define-record-type that includes "parent" record types via a has-a relationship rather than an is-a relationship, from a struct point of view <wingo>like, that could be a good solution to allow your existing match invocations to keep working <wingo>dunno, there are tradeoffs all around of couse <nalaginrut>wingo: how can I make such a non-r6rs record? or is there any existing facility that I can use? <wingo>so, do you use the procedural introspection interface on records at all? <wingo>like (record-type-fields rtd) and similar <wingo>you mostly use define-record-type, is that it? <wingo>and then the defined interfaces <nalaginrut>btw, I'm also using record matching in my compiler design, I think it's very convenient to parse the IR and processing the pass. Well. actually, I thought everybody use it like me, sadly, it seems not. <wingo>i use record matching all the time :) i just don't use inheritance <wingo>nalaginrut: ok so one easy option is to make a local copy of (rnrs records procedural) from 73d0a3bccb3c2b79d7f0e3aaca88a84f3a5c3f43 <wingo>you'd have to copy the syntactic layer as well <wingo>that has the old behavior of "nested" inheritance rather than flat inheritance <wingo>disadvantage of course is that accessing a field from the Nth ancestor is O(N) <wingo>another possible option would be to change the source program -- instead of specifying record type B as inheriting from A, make A the first field in B <wingo>but that's more of a structural change that it sounds like you didn't want to make <nalaginrut>does it mean the (parent ...) field is useless for matching now? <wingo>nalaginrut: hmm, no it just makes it be the first field <wingo>either of the changes i was suggesting keep your `match` expressions the same <nalaginrut>is it too hard to set its parent to be the first field in 3.0? <wingo>even if it were a good idea, it can't be changed in 3.0 for compatibility reasons <wingo>i don't think it's a good idea though. the 2.2 behavior for "nested" inheritance was worse from both performance and memory points of view <wingo>i don't know of any language implementation that has inheritance that uses a nested-separately-allocated-instances approach <wingo>they do what we do in 3.0. that goes for racket as well btw <wingo>note, other kinds of match facilities are also possible <wingo>i can imagine match facilities that take a more structured approach; guile's though is quite low-level <nalaginrut>should I consider it's a permanent change? Fortunately, Artanis uses a little record matching. I just use a lot of matching with parent in my new compiler, if it's a problem, then I can pin this project to 2.2. <wingo>yeah, i think you should probably consider it a permanent change. really sorry that it's causing probs for you <nalaginrut>well, that's alright, at least we have solution to make the least change. Can you update the parts in doc? In case others encounter the same issue. <nalaginrut>and I will reply my mail to explain it for a memo <jlicht>is there a way to make `read-hash-extend' only work for the current file/module? <rekado>jlicht: AFAIK it’s a global change. <civodul>yeah, it's global, so use with care (or don't use) <civodul>"syntactic sugar causes cancer of the semicolon" <jlicht>again, trying to parse snippets of elisp code embedded in guile, so if there is some better way I'd love to know ;-) <civodul>so this is "real" elisp code, not elisp code that you generate yourself? <civodul>in the latter case, you could use a syntactic subset common to elisp and Scheme, i think <wingo>there is an elisp reader in guile <wingo>gotta spelunk around to figure out how to use it tho <wingo>relatedly, i would like to convert read.c to scheme, and write a little compiler to then compile it to c for bootstrapping purposes <jlicht>wingo: I know! I'm using it! I'm now writing a hacky `elisp-write' so I can actually use Emacs' elisp interpreter on serialized S-expressions <wingo>dunno if that's reasonable tho <civodul>performance might not be as good, but it'd certainly be nicer <civodul>and perhaps the compiler to C could be used to implement the GC that's on your mind... <wingo>dunno, that might be a different kind of program <wingo>but i did think that generating c from scheme might allow the compiler to ensure that gc integration is correct <wingo>if we did ever end up changing to a moving GC, for example <wingo>anyway it would let `read` be interruptable <jlicht>I found `(system reader confinement)' in guile-reader: it seems to allow file-local modification of the reader :-) <nalaginrut>civodul: btw, is it possible to support rsync to download guix packages now? ;-) <civodul>nalaginrut: no idea! i know rekado looked into it back then, but that's all <nalaginrut>sign~I believe it's the only obstacle to advocate guix in China... <civodul>we'd have to check why that stalled, but maybe you can help? <nalaginrut>well, usually we believe it's interfered by the national firewall, the only solution is to provide rsync, and I can tell my friends in university to mirror it periodically. <nalaginrut>they've been maintaining many mirrors of big FOSS projects, so it's piece of cake for mirroring guix packages <nalaginrut>well, no matter if you believe, it's the way how Chinese IT industry relies on ***leoprikler_ is now known as leoprikler
<rekado>civodul, nalaginrut: still the same problem: “guix publish” needs to be modified to create files with more relaxed permissions. That’s really all that’s needed. <rekado>such a small thing, but I never got around to fixing it. ***bchar_ is now known as bchar
***conjunctive_ is now known as conjunctive
<RhodiumToad>is it supposed to process it? it's clearly not valid json <matijja>It should read object by object, I guess? <RhodiumToad>looking at the code, it expects to read one single document and then find an end-of-file <RhodiumToad>if the data starts with an object (as in this case), it reads one object, skips any whitespace, and then throws error if it's not at EOF <matijja>As I see, `json-read' call `json-read-object' Which read object until read # <RhodiumToad>json->scm calls json-read and then checks for end-of-file <matijja>I see. So I should call json-read directly. <RhodiumToad>it even has a comment ;; If there's anything else other than the end, parser fails. <RhodiumToad>json-read isn't exported, it's not intended to be public <matijja>Is there any other way to read stream of json objects? <RhodiumToad>that said, json->scm's interface could be better thought out, a function to read one value leaving the stream positioned just past the end of it would be of more general use <matijja>Do you have an idea, why it work with Guile v2? <RhodiumToad>the code seems quite explicit that it's intended to produce an error for this case <matijja>Maybe it use other version of library... <manumanumanu>civodul: so maybe just a clarification that these procedures are in the global environment? I'll submit that. <matijja>RhodiumToad: (procedure-arguments (@@ (json parser) json-read)) gives me ((required parser) (optional) (keyword) (allow-other-keys? . #f) (rest . #f)) ... insead of (port and null). How can be procedure arguments changed from these in source? <matijja>If I get refernce to procedure with @@ it requires other arguments from those in library code. <matijja>Is guile compiler capable of modifying intern procedures signature? <manumanumanu>matijja: json-read got the null argument in a recent release. are you reading the github code or the code you are actually using? <matijja>I'm reading code from ~/.guix-profile <manumanumanu>nalaginrut: it does not solve your problems right now, but my plan is to write an optimizing pattern matcher based on the algorithm by balland and friends (from 2006) that is also user-extensible (syntax-local-binding to the rescue!). That is probably a year away from being finished, but I have the internal pattern matcher representations done mostly. I _will_ however depend on (ice-9 match) for it. Having a <manumanumanu>pattern matcher is very comfortable when writing a pattern matcher. The big upside of the guile implementation compared to the one in the paper is that guile already handles a lot of the things they spend a lot of time doing (DCE, inlining, partial evaluation). <manumanumanu>matijja: then I don't know. you seemed to have issues where 2 versions were not playing along well, so I just suspected you had one distro-packaged guile and guile-json and one guix. The one in my distro is at 3.2, whereas the null change was sometime in the 4.0 release <manumanumanu>`which guile` in the terminal might give some info as well. <matijja>manumanumanu: Load path: (./modules/ /gnu/store/dm6l1jzr5d0sl5z76hk496asnjrxqhg9-logs-0.3.1/share/guile/site/2.2 /gnu/store/6s765nvcy77cla92wxzwhakglzlpv362-guile-json-3.5.0/share/guile/site/3.0 /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/share/guile/3.0 /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/share/guile/site/3.0 /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/share/guile/site <matijja>/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/share/guile) <matijja>... so I building with wrong version. <manumanumanu>4.0 (or even better git-master) is a _lot_ faster than 3.5. I think we measured something like a 9x speed increase for large json files. <matijja>Good. I need a minute to find it in the Guix repo... <matijja>RhodiumToad, manumanumanu: Thank you for help. No it works. :) ***dftxbs3e_ is now known as dftxbs3e