Logs: freenode/#haskell
| 2020-09-25 19:57:19 | <sm[m]> | It's forced on me by cabal |
| 2020-09-25 19:57:26 | × | mu quits (~mu@unaffiliated/mu) (Read error: Connection reset by peer) |
| 2020-09-25 19:57:27 | <int-e> | Anyway, that's a reason for using odd numbers for stable releases. |
| 2020-09-25 19:57:54 | → | mu joins (~mu@unaffiliated/mu) |
| 2020-09-25 20:00:49 | → | v_m_v joins (~vm_v@2a02:aa12:3200:6480:f507:71a:9334:3099) |
| 2020-09-25 20:01:28 | pie_ | looks at sm[m]'s link |
| 2020-09-25 20:02:05 | <int-e> | You could also skip over 2.0, I guess... |
| 2020-09-25 20:02:20 | <int-e> | Or paint a bikeshed. |
| 2020-09-25 20:02:45 | <pie_> | i think i kind of have somethign like that |
| 2020-09-25 20:03:16 | <sm[m]> | pie_: and here's the other, maybe it's better ? https://hackage.haskell.org/package/megaparsec-9.0.0/docs/Text-Megaparsec-Debug.html |
| 2020-09-25 20:03:19 | × | _vaibhavingale_ quits (~Adium@203.188.228.27) (Quit: Leaving.) |
| 2020-09-25 20:03:19 | <pie_> | re: the problem is most of the time i dont know which piece of my code is causing the error (and then i bisect or whatever and still dont get why its breaking where its breaking xD) |
| 2020-09-25 20:03:40 | × | ahri quits (~ahri@178.209.40.84) (Quit: Ping timeout (120 seconds)) |
| 2020-09-25 20:03:46 | <pie_> | maybe i just dont understand the library well enough |
| 2020-09-25 20:03:48 | <pie_> | :I |
| 2020-09-25 20:03:56 | <sm[m]> | that's why you have to sprinkle loads of these, with different labels |
| 2020-09-25 20:04:01 | <pie_> | guess i should learn a different style of parser writing |
| 2020-09-25 20:04:16 | → | ahri joins (~ahri@178.209.40.84) |
| 2020-09-25 20:05:10 | <sm[m]> | if you look at hledger parsers you'll see lots of these, perhaps commented out.. and if debugging I'll often add more |
| 2020-09-25 20:05:18 | <pie_> | *nid* |
| 2020-09-25 20:05:21 | <pie_> | *nod* |
| 2020-09-25 20:05:38 | <pie_> | there has got to be a better way of doing this |
| 2020-09-25 20:06:10 | → | Dablyon joins (~godel@173.171.157.121) |
| 2020-09-25 20:06:32 | <sm[m]> | I'm not sure what it is, other than use a parser generator |
| 2020-09-25 20:07:03 | <sm[m]> | extensive fine grained tests are also helpful, and tedious |
| 2020-09-25 20:07:31 | × | mu quits (~mu@unaffiliated/mu) (Read error: Connection reset by peer) |
| 2020-09-25 20:07:40 | <pie_> | *nod* |
| 2020-09-25 20:08:00 | → | mu joins (~mu@unaffiliated/mu) |
| 2020-09-25 20:08:59 | <sm[m]> | Interactive testing in ghci, too |
| 2020-09-25 20:10:24 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2020-09-25 20:11:00 | × | Dablyon quits (~godel@173.171.157.121) (Ping timeout: 256 seconds) |
| 2020-09-25 20:11:13 | × | Rudd0^ quits (~Rudd0@185.189.115.98) (Ping timeout: 246 seconds) |
| 2020-09-25 20:11:14 | <sm[m]> | and I suppose being disciplined and consistent, eg in how you handle whitespace, reducing the number of ways to screw up. A lexing phase should help with that but adds complexity too |
| 2020-09-25 20:11:45 | → | archaephyrryx joins (~archaephy@straasha.imrryr.org) |
| 2020-09-25 20:11:55 | <pie_> | do people have to do this for other parser styles? |
| 2020-09-25 20:12:22 | <sm[m]> | but when it's just..not..working you must have a technique to drill in and get visibility on what's happening |
| 2020-09-25 20:12:40 | sm[m] | doesn't know |
| 2020-09-25 20:12:42 | <pie_> | dont get me wrong i like combinators on some level, and they seem intuitive, except its not going well xD |
| 2020-09-25 20:12:55 | <archaephyrryx> | what parser library is this? |
| 2020-09-25 20:13:06 | <pie_> | parsy in python, its quite decent |
| 2020-09-25 20:13:12 | <pie_> | one could even say good |
| 2020-09-25 20:13:18 | <pie_> | but i dont have anything to compare agaisnt really |
| 2020-09-25 20:14:10 | <archaephyrryx> | i joined mid-conversation, but I have a bit of experience using (and even writing to a limited extent) parser combinators in Haskell |
| 2020-09-25 20:14:13 | × | frdg quits (47b88ff9@pool-71-184-143-249.bstnma.fios.verizon.net) (Remote host closed the connection) |
| 2020-09-25 20:14:15 | <archaephyrryx> | what is the issue? |
| 2020-09-25 20:14:52 | <pie_> | it works and then i hit a snag and get stuck for hurs |
| 2020-09-25 20:14:55 | <pie_> | hours |
| 2020-09-25 20:14:59 | <archaephyrryx> | what does? |
| 2020-09-25 20:15:00 | <pie_> | generally hard to debug |
| 2020-09-25 20:15:06 | <sm[m]> | can you see the log, archaephyrryx? |
| 2020-09-25 20:15:23 | <pie_> | writing parser combinators is hard to debug (for me) |
| 2020-09-25 20:15:52 | <pie_> | also tbh i shouldnt have to write print statements everywhere, it shuld be possible to point to something and figure out wtf is going on there |
| 2020-09-25 20:16:02 | <pie_> | but im not sure what kind of tooling would need to be in the library for that |
| 2020-09-25 20:16:04 | <archaephyrryx> | have you looked into HasCallStack |
| 2020-09-25 20:16:42 | <pie_> | i havent had much luck with making sense of whats going on using the pycharm debugger, though maybe i didnt try hard enough |
| 2020-09-25 20:16:51 | <archaephyrryx> | don't have much experience using it personally but it seems useful for tracing bugs in deeply nested calls |
| 2020-09-25 20:16:57 | <sm[m]> | pie_: it's actually fine, I may have overstated. Often putting the trace in one likely place will give you the insight to fix it |
| 2020-09-25 20:17:14 | <sm[m]> | and it's quick to do via ghci |
| 2020-09-25 20:17:25 | × | mu quits (~mu@unaffiliated/mu) (Read error: Connection reset by peer) |
| 2020-09-25 20:17:31 | × | s00pcan quits (~chris@075-133-056-178.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2020-09-25 20:17:54 | → | mu joins (~mu@unaffiliated/mu) |
| 2020-09-25 20:17:59 | <pie_> | sm[m]: i can do something like .map(debug) in a parser chain where debug is def debug(x): print(x); return x |
| 2020-09-25 20:18:17 | <pie_> | its helped but i have to turn it off and on (which you mentioned) and doesnt fix everything |
| 2020-09-25 20:18:25 | <sm[m]> | but.. I'm slowly realizing that you're adking for help with something quite different from what I'm talking about |
| 2020-09-25 20:18:26 | <pie_> | hm i guess i should add showing parser state to that somehow |
| 2020-09-25 20:18:53 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds) |
| 2020-09-25 20:19:04 | <pie_> | i mean, theres libary specifics but there should be general approaches amenable to the design of monadic combinators in general i think |
| 2020-09-25 20:19:28 | → | s00pcan joins (~chris@107.181.165.217) |
| 2020-09-25 20:19:56 | <archaephyrryx> | can't figure out how to view the log sm[m] |
| 2020-09-25 20:20:06 | → | alexkubicail joins (~alexkubic@37.142.205.101) |
| 2020-09-25 20:20:23 | <sm[m]> | Yes; that was the point of my first reply to you. You need a specialized trace helper that prints the parser state - what text it's looking at etc. |
| 2020-09-25 20:20:36 | <pie_> | *nod* |
| 2020-09-25 20:21:04 | <sm[m]> | ircbrowse.tomsmeding.com archaephyrryx |
| 2020-09-25 20:21:04 | <pie_> | so, do you think theres a way to integrate the tracer so you dont have to manually add calls if you need them? |
| 2020-09-25 20:21:20 | → | chaosmasttter joins (~chaosmast@p200300c4a7105f013091658b0e650c79.dip0.t-ipconnect.de) |
| 2020-09-25 20:21:31 | <sm[m]> | certainly, in the parser engine, why not |
| 2020-09-25 20:21:31 | <pie_> | well i guess that comes down to wrapping every function |
| 2020-09-25 20:21:31 | → | totallynotnate joins (~nate@125.161.70.37) |
| 2020-09-25 20:21:56 | <sm[m]> | The challenge is not being so verbose that you can't read it |
| 2020-09-25 20:22:01 | <pie_> | i guess parser combinators dont really have an engine? isnt it just a style of signatures? |
| 2020-09-25 20:22:06 | <pie_> | yeah |
| 2020-09-25 20:22:41 | <sm[m]> | I have assigned priorities to trace statements so I could filter by level |
| 2020-09-25 20:23:32 | <pie_> | maybe something you could to is tell it to trace between sections of the text |
| 2020-09-25 20:23:36 | <pie_> | so from char x to char y |
| 2020-09-25 20:23:43 | <sm[m]> | I don't know about your python lib. Haskell parser combinators run via a parser engine |
| 2020-09-25 20:23:57 | <pie_> | ok |
| 2020-09-25 20:23:57 | <sm[m]> | sounds good |
| 2020-09-25 20:24:08 | <sm[m]> | There is a lot of room for better tooling here |
| 2020-09-25 20:24:33 | <pie_> | ive googled stuff like "debuggign parser combinators" in the past but i never really saw anything relevan |
| 2020-09-25 20:24:35 | <pie_> | t |
| 2020-09-25 20:24:51 | <pie_> | doesnt mean it doesnt exist but i didnt find the right people or material... |
| 2020-09-25 20:25:04 | <pie_> | people dont seem to design for introspectability much |
| 2020-09-25 20:25:23 | <pie_> | i feel like im the idiot though, idk |
| 2020-09-25 20:25:43 | <sm[m]> | I have built some complex parsers with combinators but perhaps it's a thing people don't do much |
| 2020-09-25 20:25:56 | <pie_> | you seem to have managed |
| 2020-09-25 20:26:07 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2020-09-25 20:26:14 | <archaephyrryx> | have you tried copying the source code and running it yourself with modifications to enhance debuggability |
| 2020-09-25 20:26:36 | <pie_> | the parser im building doesnt seem horribly complex. ok maybe its not simple, im not sure, what i need to do is decompose it into small iterative steps so i can manage it |
| 2020-09-25 20:26:42 | <sm[m]> | yes, by making debug tools.. and still with a lot of labour. Otherwise, it was impossible |
| 2020-09-25 20:27:16 | <phadej> | running your parser on smaller inputs and verifying that things which you think should be accepted are actualyl accepted |
All times are in UTC.