IRC channel logs
2024-09-07.log
back to list of logs
<ekaitz>lilyp: the other day we discussed about PEG parsers <ekaitz>the paper that described them has it <ekaitz>i'll share some thought that might be superwrong but I felt some kind of opposition to the idea of adding things to it the other day <ekaitz>like if I was making unneeded requests <ekaitz>and in fact we have a pretty poor peg parser <ekaitz>i felt discouraged to try to improve it <ekaitz>i'm not blaming anyone (it's okay) <ekaitz>but this has been my feeling with guile a lot and i think this is something we should think about <ekaitz>i don't feel the same in guix, for example <ArneBab>daviid: since I never used clos/mop, I don’t see the relevance of that ☺ — but I like GOOPS using more of the specificities of Guile. <daviid>ArneBab: well, whether you like it or not, goops is an implementation (bugged) of the clos/mop protocol, and i am not going to propose to add something to gule core that a guile maintainer didn't himself wanted to add ... <mwette>sneek, later tell dthompson I did try 6+ and that works fine_ <robin>daviid, what kinds of things are buggy wrt goops, other than incompleteness? (i haven't done anything tricky with it but i may be attempting to bring it more in line with clos+mop in the future) <robin>sneek, later tell ekaitz iirc the peg library is somewhat buggy... <lilyp>sneek later tell ekaitz: the thing is that the paper thinks '_' to be a valid identifier, which it is not in Guile; I think the replacement of '_' with '-' comes natural to Schemers <sneek>ekaitz, you have 2 messages! <sneek>ekaitz, robin says: iirc the peg library is somewhat buggy... <sneek>ekaitz, lilyp says: the thing is that the paper thinks '_' to be a valid identifier, which it is not in Guile; I think the replacement of '_' with '-' comes natural to Schemers <ekaitz>lilyp: but it's not replacing but saying that's wrong <ekaitz>a different thing would be that _ is correctly parsed and then defined in the context as - <ekaitz>and the docs say Guile provides a superset of the PEG syntax, which is just a lie <ekaitz>a different syntax what it provides, that has some intersection with PEG's <ekaitz>robin: so yeah, true. I'd say is more incomplete than buggy <ekaitz>i just wrote the proper peg parser, and i'm trying to convert that result to a valid Sexp <lilyp>well mapping _ to - would still lead to confusion, not sure how that helps <lilyp>and yes, you could do more complex mappings while trying to ensure that those don't leak <lilyp>but apart from the [_-] confusion, what else is missing in PEGs? I think that might be more worth tackling <dpk>i would like to see (ice-9 peg) re-written to allow left recursion as in pika parsing, but that would be an incompatible API change for people who have implemented their own parser procedures rather than used the high-level API, because it’s bottom up rather than top down <ekaitz>lilyp: also using " for literals and not only ' <dpk>a pika parser in Scheme is on my ‘i’ll get round to it some day’ projects list <ekaitz>dpk: i'm trying to implement what the original paper says, with is own problems <ekaitz>we'll see i still have time after that :) <ekaitz>this is a veeeery deep yak shaving what i'm doing <dpk>when i used (ice-9 peg) there was also something very weird i had to do to get it to give me a string in one case, instead of a list of one-character strings … <dpk>(char-set->peg, defined at the top of that file, would also be useful to have built into (ice-9 peg)) <sneek>I've been serving for one month and 17 days <sneek>This system has been up 6 weeks, 5 days, 56 minutes <ArneBab>ekaitz_: I feel that in guile we have a bottleneck in code review and merging smaller patches. And I have the impression that that prevents us from building the "batteries" of Guile together. Improvements of the core work pretty well — thanks to established contributors working there — but stuff in ice-9 often feels like there’s often just a bit missing. <dadinn>I am trying to run this code '(execlp "python" "-c" "\"print('hello')\"")', but getting a "SyntaxError: invalid syntax" message. <dadinn>It seems to be coming from Guile, not from Python. <Arsen>(execlp "python" "python" "-c" "\"print('hello')\"") "works" (in that it prints nothing), I suspect you want (execlp "python" "python" "-c" "print('hello')") and that if you run: stat "\"print('hello')\"" <Arsen>... in your shell, you will see results <dadinn>>>> (execlp "python" "-c" "print('hello')") <dadinn> (execlp "python" "-c" "print('hello')") <Arsen>you pasted guile code into a python shell <Arsen>if you've already execl'd python, it replaced guile - this is how exec works <dadinn>hmm, it is still not really doing what I expect it to. `python -c "print('hello')"` work in the shell, but when running (execlp "python" "-c" "\"print('hello')\"") in the REPL, I get this: <dadinn>-c: can't open file '/home/dadinn/Workspace/dev/besenczy/infra/ovpn2/"print(\'hello\')"': [Errno 2] No such file or directory <dadinn>It's been nice interacting with you! <robin>(apparently this was for parsing synctex data for jumping between the document and source, i'll have to find a sample file i guess) <sneek>dthompson, you have 1 message! <sneek>dthompson, mwette says: I did try 6+ and that works fine_ <robin>ah i see, it's supposed to match all the sheets of the form {<BYTE-OFFSET>...}<BYTE-OFFSET> and finds two sheets in a ~100-page document <robin>it does complain about "possibly wrong number of arguments to `link'" everywhere it's used in the grammar, so maybe it's a bug in my program. i haven't tried it with my own packrat parser generator yet (portable enough, but written for a different scheme) <robin>the program is from 2016, no bug filed b/c i haven't identified the actual problem yet :) <dsmith>dadinn, You probably want this instead: (execlp "python" "-c" "print('hello')") <Arsen>once for program and once for argv0 <dadinn>scheme@(guile-user)> (execlp "python" "-c" "print('hello')") <dadinn>-c: can't open file "/home/dadinn/Workspace/dev/print('hello')": [Errno 2] No such file or directory <dadinn>It's been nice interacting with you! <dadinn>Arsen if I put "python" twice that doesn't change the output either <dsmith>scheme@(guile-user)> (execlp "python3" "python3" "-c" "print('hello')") <Arsen>scheme@(guile-user)> (execlp "python" "python" "-c" "print('hello')") <dadinn>hmm, now it worked. Not sure what I was doing wrong <dadinn>Why do I need the "python" command twice? <Arsen>because one is the executable being ran and the other is the 0th argument to that executable <dsmith>Once for the command to run, and again for argv[0] <dsmith>It's not necessary that they are the same! <dadinn>ah, weird... can you then pass something else instead? that would nicely confuse scripts, so they think something else is running them? <rlb>dadinn: you can also change argv at run time, and some programs do that to indicate what they're up to (postgres' subproceses, iirc, etc.). <rlb>Though your platform (python, etc.) may not make it remotely easy to do so :) <Arsen>not all kernels regard such edits fwiw <rlb>Ahh, right, shouldn't assume -- fair enough. <dsmith>I vaguely remember something about login shells having a '-' as the first char of argv[0] <dsmith>I think on Linux (and Solaris?) you can get the actual executable by trolling through /proc/$PID/ <rlb>wrt dash (INVOCATION bash(1)) <ekaitz_>robin: thank you for sharing that. Hopefully when I write the proper parser someday it'll fix your issue <ekaitz_>this is how our PEG parser should look like <ekaitz_>the thing is now i need to implement the conversion from text to sexps <ekaitz_>so, only looking at the line count of the peg definition, we can see our parser does not provide the same amount of things <ekaitz_>to the point that calling it a PEG parser is kind of misleading <robin>ekaitz_, i'm not convinced a stringy syntax is even necessary...unless you're replacing (ice-9 peg) and aiming for full compatibility or something <ekaitz_>it's just there for readability and testing <ekaitz_>i'm parsing it with itself to make sure it works <robin>oic, it's based on the existing api <old>any idea why this would segfault? ((@ (system vm disassembler) disassemble-image) (call-with-input-string "(lambda () 1)" (lambda (port) ((@ (system base compile) read-and-compile) port))))