<amz3>I'd like to use csv parser for the guile parser combinator article I'm writing <amz3>Seem like if I can parse: <amz3>erf actually it's very easy to parse csv using parser combinators <amz3>the tricky thing is having data to test it <amz3>anyone knows of a good csv data set; that is not only 0 and 1 and the like <amz3>something like panama papers maybe <zv>does the `make-thread' procedure transparently fail if threading isn't enabled? <zv>I can't get this to return anything except 101: (begin-thread (set! x (* x x))) (begin-thread (set! x (+ x 1))) <zv>likewise for the `parallel` form <galex-713>would tex be difficult to implement with lisp? <galex-713>also would lisp be difficult to implement in TeX? <galex-713>(note TeX is turing-complete and has macros and homoiconicity) <galex-713>(except it can dynamically change its core syntax while I know no lisp that can do that) <amz3>galex-713: not necessarly the best advice, but I would start implementing flexbox in scheme <galex-713>is it a language that supports macros and homoiconicity? <amz3>flexbox is a layouting algorithm used in browser <amz3>tex has a similar algorithm to layout documents <amz3>I started an implementation based on fbk code, but stopped working on it due to legal issues <zv>damn you thread-based scum! <galex-713>do you mean the algorithm to decide hyphenation, line breaking etc. by testing all the possibilities and picking the best? <davexunit>ACTION has the urge to implement a time series database with guile <wingo>done with ethreads/ports stuff for now <wingo>the ports documentation is now sufficient i think <wingo>popping that one off my task stack! <Bobbejaantje>wingo, your efforts are greatly appreciated and worthy of song. <Bobbejaantje>wingo, you wrote the internal C function open-process from (ice-9 popen) right? <wingo>Bobbejaantje: i think so yea <Bobbejaantje>wingo, excellent, would you happen to know of a way to fork/exec from a multithreaded program obtaining the pid of the child without using that internal function. <wingo>Bobbejaantje: i don't know, no :) you have to write your own function in C i think, to avoid the various pitfalls <wingo>that function can't be written in scheme right now <wingo>of course you can call primitive-fork but it's only going to work sometimes <wingo>which is not a good property for a program <Bobbejaantje>Yeah, I tried just using (let [[pid (primitive-fork)]] (if (zero? pid) (apply execlp command-line) pid)), that sometimes works and sometimes doesn't, weirdly enough. <Bobbejaantje>Not sure what open-process exactly does to mae it work always. ***Bobbejaantje is now known as Vlaamsche_Friete
<wingo>" * After a fork(2) in a multithreaded program, the child can safely call only async-signal-safe functions (see signal(7)) until such time as it calls execve(2). <wingo>that's what the open-process C function does -- it only calls async-signal-safe functions <Vlaamsche_Friete>And that scheme code I used calls some non async signal safe functions internally or something? <mejja>ACTION wonders why there is not a spoon system call.. <peterbrett_work>wingo: Wow, the complete incompatibility between R6RS and R7RS for bytevector-copy! is totally insane <wingo>peterbrett_work: it boggles the mind <wingo>i see how you could get there if you really think srfi-13 has the right argument style, and bytevector-copy! is really the right name, but the result is bonkers <mejja>Can I haz the executive report please?! <wingo>peterbrett_work: i think very few schemes implement r6rs bytevectors and also want to support r7rs <wingo>guile is somewhat in that set fwiw <mejja>R6: (bytevector-copy! source source-start procedure target target-start k) vs R7: ? <peterbrett_work>I.e. R6 has a start index + length; R7 has a start index + end index <mejja>so r6 can be safely ignored as the pile of poo it is.. ***octo- is now known as octophore
***Vlaamsche_Friete is now known as zXR-zpringue
<amz3>weeee, `csv-parser' is just one `parse-unless` away <zv>daviid: what is the point of nesting `let'? <zv>e.g the body of `csv->list' <zv>can't you *always* either use let* or let? <ijp>I can come up with a convoluted example of when let* isn't what you want <zv>answers online say "oh yeah, there is no problem" <ijp>basically it would involve "redefining" a foo while simultaneously using its value <zv>but it seems really obvious to me that withdrawl could read a value, deposit could read a value, withdrawal could set that valu and then deposit would and the balance would be incorrect by the inital read of `deposit' <zv>ijp: I see -- is that behaviour (redefinition) forbidden by let*?