<dsmith>Well, whatever it is, it would be well defined and proven at compile time. <dsmith>I'd *much* rather fix things at compile time than run time. <dsmith>Mostly I've worked on Embedded things. <ArneBab>I wish we could have somewhat more of compiletime-checks in Scheme — basically more warnings during bytecode compilation <ArneBab>dsmith: then I’m really glad that you’re going for Rust :-) <dsmith>It's nasty to build a filesystem, reflash your device, and *then* find a run time error. <dsmith>I blame wingo. He was talking about go channels which made me curious about go. Eventually that got me interested in Rust. <ArneBab>That’s funny — my impression is that Go managed to capture the people Rust wanted and Rust managed to capture those that Go wanted :-) <ArneBab>And I’m still trying to find ways to put guile to more productive use <dsmith>I like go a lot. But it's really no good for embedded because of gc. <ArneBab>(and all the while a co-worker added s-expressions to our tests in Java, because "they are at least readable" :-) ) <justin_smith>dsmith: I've been learning ARM assembler lately, and I like who both guile and RISC assembler let me accrete and sculpt a design around a relatively small set of operations (but can see the appeal of static checking when your goal is to have a working result, as opposed to the aesthetic flow of being engaged in programming) <ArneBab>Guile also has very reasonable performance nowadays, but existing tools aren’t there — or not easy enough to find. I sometimes find myself grabbing Python instead of Guile for quick hacks. <dsmith>justin_smith: Dynamic languages are *Very* addictive. The quick feedback loop is like a drug. <justin_smith>dsmith: this reminds me of a paper I read recently about the philosophical premise of project management in software development. plan / implement vs. brainstorm / improvise as fundamentally different ways of engaging with work <justin_smith>and I think there are a lot of signs that brainstorm / improvise gets more done when it stays vaguely on track (but has worse worst cases...) <dsmith>Forth often has an assembler, though usually *nothing* like a "traditional" asm. <justin_smith>and occasionally think about what I'd have to accomplish before I'd trust myself ot attempt programming for a greenarrays board <justin_smith>(which last I checked are only programmable using forth) <justin_smith>dsmith: yup! I ran colorforth back when I could just slip it in a floppy drive and go <dsmith>I think I recently saw a video by Chuck on that. <dsmith>"consuming as little as 7 picojoules of energy" that sounds like Chuck. <justin_smith>I'd love a reality tv series that just followed the architectural meetings and daily standups of a team making something *interesting* on a greenarrays board <justin_smith>dsmith: I have been thinking more about linux / guile / c / asm as a stack for my "laid off so I have time to pay attention to this" project <dsmith>justin_smith: Have you read "Thinking Forth" ? <chrislck>it's true... getting the average bookkeeper or sole-trader to learn lisp is not reasonable :) <chrislck>your mom-and-pop business shouldn't be worried about tail-calls nor O(N) <dsmith>"Scheme is impenetrable to most programmers^w expert beginners" <daviid>i totally desagree with "Expecting users to be able to write reports in Scheme is completely unreasonable", it is the opposite which is completely unreasonable <chrislck>if I ever make it to fosdem I'll offer a talk: how I became the defactor scheme maintainer in gnucash, or "all I wanted was VAT reports" <dsmith>I suspect that people who have never been exposed to programming at all take to Scheme nicely. <dsmith>pkill9: No bias and pre-concieved notions. <ArneBab>dsmith: I’ve been planning for a while (years) to do an actual scientific study about the effect of parens on the ease of understanding. It’s one of the uses I see for wisp: Since programs in wisp are structurally equal to their scheme equivalents, it allows separating the effect of parens from everything else. <ArneBab>chrchr: wow, Python with or without parens for function call :-) <ArneBab>chrchr: did you try to show them wisp? <ArneBab>chrchr: if you can give me a typical report, I can create the equivalent in wisp so people can compare <ArneBab>advantage: All the old stuff just works, because the *.go files are compatible. ***apteryx is now known as Guest68538
***apteryx_ is now known as apteryx
<tohoyn>daviid: anything new with g-golf? ***sputny1 is now known as sputny
<dsmith-work>ArneBab: The *shape* of lisp/scheme code matters to me. If you put everything on one line, I can't read it. <mwette>I'm looking for pointers to tutorials on web-client coding w/ authorization. I have gnutls and now gcrypt; any other externals needed? <dadinn>I have just encountered a problem with using modules. I think my problem is I am kinda expecting that the current-directory is always on the load-path, so I can use submodules (git style) more naturally. This is not the case, but the workaround was that I add the current-dir to the loadpath manualy, before the use-module directives. Like here I did here: <dsmith-work>dadinn: Putting current dir on the load path is bad the same way putting "." in your $PATH is bad. <dadinn>The problem I find is that I can't seem to compile the common/utils.scm and common/utils/dep.scm packages individually, because it is only the parent project's directory on the load path :/ <dadinn>dsmith-work: I think I have a reasonable use-case... this is exactly the same how it works on the JVM, specifically Clojure... the contents of a JAR file are always on the classpath <dadinn>dsmith-work: unless your argument is that JVM is inherently flawed... <dsmith-work>Oh I was just giving the reason why "." is not on the load-path. Adding the full path to the current directory (/some/location) is not as unsafe. <dadinn>dsmith-work: hmm, actually you are right, what I am doing is: (add-to-load-path (dirname (current-filename))) <dadinn>dsmith-work: when I am trying to run (current-filename) in the Geiser REPL I get back #f ... I suppose because the REPL is not linked to any source file, yet I have tried to load deps.scm as source file :/ <mwette>or $ export GUILE_LOAD_PATH=`pwd`:$GUILE_LOAD_PATH <ArneBab>I decided to keep the parentheses around N_ calls, because N_ is often used inline. ***sneek_ is now known as sneek
<ArneBab>chrislck: do you think the wisp-report would be easier to read for others? <dadinn>so is there a better way I could structure my code, especially the `common` submodule, so that the sources deps.scm module can reference the utils.scm module next to it in the same folder? <chrislck>IMHO only marginally so. the steep learning curve is the lack of templating language (like jinja/mustache) and lack of standard query language. Most are looking for something like PHP by writing html templates directly and inserting {{ account.name }} here and there. <chrislck>the report code will incrementally build the report HTML DOM tree by looping through accounts/transactions/invoices etc using scheme's very excellent looping constructs, but users want an easier time. <chrislck><ul> { for acc in Accounts where acc.name.beginsWith["Assets"] } <li>{ account.name } balance is { account.balanceAt[$today]} </li> { endfor } </ul> <chrislck>oops: <ul> { for acc in Accounts where acc.name.beginsWith["Assets"] } <li>{ acc.name } balance is { acc.balanceAt[$today]} </li> { endfor } </ul> <dsmith-work>There sure are a lot of templating systems out there. (Especially for JS). <chrislck>ArneBab: new-aging is of fairly high complexity, but 100% my work, so, I know it has good scheme habits :) <chrislck>I'm sure you'll see the enormous vocabulary in use -- both for data access and html report building is the next steep learning curve (after learning lisp) <chrislck>so: a templating language, and a query language, would make it much easier. unfortunately I don't know how to structure it. ***terpri__ is now known as terpri
<dadinn>or to try to ask the question more generally: how can two modules reference each other, when they only know that they are on the same relative path to each other? <dadinn>my parent project has to refer to the utils module as (common utils) but that is not the path for my other project which is in the same folder as the utils package.. yet the utils package has to define itself as (common utils) <dadinn>actually, it seems I solved it with: (add-to-load-path (dirname (dirname (current-filename)))) <dsmith-work>I think most modules are installed to a known place. Not usually relative to some other file. <dsmith-work>That's a windowsy thing I think. Install an exe and any dll's in same or subdir, and the exe looks for them relative to where it finds itself. <dsmith-work>Not sure how guix works. Probably just extends the load-path to whereever. <dsmith-work>That manual happens to be for 3.0, but 2.2 is the same. <thchr>I can try a Linux install on 1.8.8 as well ow *dsmith-work looks squinty eyed at WSL <dsmith-work>"The profiler works by setting the unix profiling signal ITIMER_PROF to go off after the interval you define in the call to statprof-reset." <thchr>Tried the 1.8.8; doesn't seem to have statprof unfortunately <thchr>I see, so could be an issue of running this through WSL then. <dsmith-work>Windows doesn't have signals. I wonder what WSL does. <ArneBab>chrislck: why not just use sxml in quasiquoting? <ArneBab>chrislck: why I translated your code to wisp (aside from wanting to show off wisp :-)): When people say "we need a non-lisp", you can show them the code and say "it’s not the scheme, the same structure in another language would be worse. Let’s work on a higher level API that can be used from Scheme, so people can drop down to low-level if needed, but don’t have to". <ArneBab>(that only gets the title dynamically) <dsmith-work>"We plan to use GTK/Scheme bindings for coding small utilities and applications. When these bindings are more mature, it should be possible to write complete applications in Scheme." <ArneBab>That’s an argument by authority. It works best if accompanied by utility. (my code is using SRFI-119; it’s just one command away from regaining the parens) <ArneBab>(though I have to admit, that templating languages that allow you to open the template in a browser to see and tweak it with placeholders visible is pretty useful) <roelj>I'm using statprof to find a performance bottleneck in my Guile program, and the top two entries are "anon #xbda148" and "anon #xbd0560". How can I dig deeper into this? <dsmith-work>ArneBab: Ugh! I don't think I could deal with code like that. <dsmith-work>roelj: I wonder if that's related to the fix df22eb595 ? <ArneBab>do you mean the one-page sxml template? <ArneBab>or in general the code with fewer parens?