IRC channel logs

<ArneBab>benq: I just added a note to the README about installation in /usr/local

<benq>arnebab: thanks, interested in a 'realpath' command?

<pebftab>daviid , dsmith-work : welp, found out that DUMA was causing trouble. Time to switch to valgrind.

<benq>arnebab: perl -MCwd -e 'print Cwd::realpath($ARGV[0])'

<ArneBab>benq: is perl guaranteed to exist on OSX?

<benq>or with a newline: perl -MCwd -le 'print Cwd::realpath($ARGV[0])' ~/.Xauthority

<pebftab>thanks anyway, and may that be a lesson on "if it breaks in testing, perhaps your testing tools are breaking it"

<benq>yes, Perl is used for many utilities. That's the reason I still use Perl a lot.

<ArneBab>why ARGV[0] and not $0?

<benq>I don't understand why not more people take more advantage of Perl wide distribution.

<ArneBab>(or rather '$0')

<ArneBab>(or rather '…'$0'…')

<ArneBab>benq: can I make this fail if the path does not exist?

<ArneBab>(return 1 instead of 0)

<mwette>ArneBab benq: for portable realpath look at the stackoverflow ref. It provides a bash function

<mwette>#!/bin/bash

<mwette>realpath() {

<mwette> [[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"

<ArneBab>mwette: do you mean this one? 2>/dev/null 1>/dev/null

<mwette>}

<mwette>realpath "$0"

<ArneBab>this one: https://stackoverflow.com/questions/3572030/bash-script-absolute-path-with-osx

<ArneBab>(sorry about the previous, wrong copy buffer)

<ArneBab>does OSX always have bash?

<mwette>yes

<ArneBab>then that shall be my fallback-fallback

<ft>That's not very realpathy though. :) One could at least take the directory part, cd to that in a reassemble properly.

<benq>ArneBab: I think it would be nice to have a customizable delimiter in wisp. I replaced ':' with '$'

<ArneBab>benq: You might want to try out the readable project then. Wisp should stay as simple as possible.

<benq>Right now I use both ....

<ArneBab>benq: in readable they added several useful syntactic structures, but by doing so they lost the simplicity which had drawn me to them

<ArneBab>that’s the origin of wisp: trying to make a simpler readable

<ArneBab>benq: the reason why I don’t want to add more syntax is that every syntax element I add makes the language more complex and removes one element the programmers can use for their own tools

<ArneBab>mwette, benq: wisp 0.9.4 should now have working make check on OSX (still untested, since I don’t have OSX): https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.9.4.tar.gz

<ArneBab>ACTION needs to get to bed

<ArneBab>benq, mwette: thank you for your help in making wisp better!

<benq>ok, you sleep well.

<ArneBab>thank you!

<ArneBab>cu

<mwette>I would prefer to see you use /site/.

<mwette>The nice thing about wisp is that it could be used by people who don't operate a language sensitive editor. Scheme has got to be tough if you edit using textedit or some noise like that. one could potentially have non-sw folks edit in gnumeric

<amz3`> https://github.com/JunSuzukiJapan/macro-lisp

<ArneBab_>benq: the deeper reason for preferring : over $ is that : occurs more frequently in normal prose, therefore code written with : looks more familiar to all people who know prose.

<ArneBab_>sneek: later tell mwette: 0.9.4 now uses /site/

<sneek>Okay.

<ArneBab_>sneek: later tell mwette: editing for non-programmers is something I see as a goal for wisp. However I don’t think that the syntax is actually much easier to edit. What it provides is that it looks less daunting, so people dare to assume that they can understand what it does — and therefore dare to edit.

<sneek>Got it.

<benq>ArneBab_: I think I once read your entire conversation Arne/David about wisp/readable. What I recall is that he showed great interests in you thoughts I think he even mentions you positively in his SRFI. Thats the important thing: curiosity. In that sense: you see it more from a purely syntactical side, me on the other hand I narrow it down to use the additional sugar for specific uses.

<benq>so I use ':' only as infix operator for function application. And to emphasize that point I use a operator symbol that is also used in other languages which is '$'

<ArneBab_>benq: yes. I also refer to his SRFI-109 for all the complex stuff. David did great work and wisp wouldn’t be possible without readable, and programming in wisp would be much less convenient without his curly infix (SRFI-105). The difference is essentially aesthetics and purity of language design.

<ArneBab_>benq: the actual deep difference is that wisp uses the dot-prefix to denote a line as "not a procedure call". Readable does not have that, so in theory it would need much more vertical space, but that is mitigated by the additional syntax elements.

<ArneBab_>benq: how do you use : as infix? do you mean inline?

<benq>I thinks there is one big difference and not even sure if that was intentional on your side because it is not discussed in the conversation (as far as i remember). I don't know the proper term, but the thing I'm talking about is how Wisp handles "negative" indentation.

<benq>sorry all my typos...

<ArneBab_>do you mean a line with less indentation than the previous one?

<benq>yes, this is absolutely genius

<ArneBab_>I’d love to take that praise, but that’s essentially stolen from Python :)

<benq>and the only reason I went through the auto tools pains multiple times.

<benq>I once recreated this rules in Perl. It was a painful experience.

<ArneBab_>I also fought quite a lot with it ☺ — I have a python implementation which isn’t completely correct, and a scheme implementation which isn’t completely correct, and then a second scheme implementation which finally gets it right :)

<benq>you mean 'wisp.scm' ?

<ArneBab_>the bootstrapping uses the python-implementation to parse the first scheme implementation which then parses itself and then the second scheme implementation.

<ArneBab_>wisp.scm is the first, wisp-scheme.w is the second

<benq>good to know. what do you think about curly braces?

<ArneBab_>there are some corner cases in string handling which wisp.scm doesn’t get perfectly right.

<ArneBab_>benq: I like curly braces a lot. Prefix-math is off-putting to many, and curly braces make that code approachable to them.

<benq>any plans to implement it in wisp?

<ArneBab_>it’s already included: when you switch to wisp it activates curly braces syntax from SRFI-105

<benq>I've tried it in the past, but it never worked.

<ArneBab_>there is one catch compared to readable: curly braces in wisp are always a full expression. If you want to use them as only item on a line, you have to prefix the expression with a dot

<ArneBab_>. {3 + 4}

<ArneBab_>benq: do you have a successfully built wisp folder around?

<ArneBab_>if yes: cd $WISP_FOLDER; guile -L . --language=wisp

<ArneBab_>then type . {3 + 4} .

<ArneBab_>(the final period just relieves you from having to hit return thrice)

<benq>and which ci tool would you use?

<benq>I mean cli ...

<ArneBab_>what do you mean by that?

<ArneBab_>I run the Guile wisp prompt and edit with Emacs

<benq>my system is a mess Wisp wise. So I have to work in the local folder of wisp. Is it wisp-scheme.scm?

<ArneBab_>just run guile -L . --language=wisp

<ArneBab_>(in the wisp folder)

<benq>Ok , the real works. great!

<ArneBab_>nice!

<benq>and now I would like to transpile a file :-)

<ArneBab_>(you can do that to create other wisp projects: it only needs language/wisp/spec.scm and wisp-scheme.scm — but a future release should move wisp-scheme.scm into language/wisp.scm so you’d only need language/

<ArneBab_>benq: guile wisp.scm file.w > file.scm

<benq>but wisp.scm not final/good implementation, no?

<ArneBab_>this actually works for most lisp syntaxes, including emacs lisp

<ArneBab_>benq: it’s the implementation which has at least one known bug in character literal handling in comments

<ArneBab_>but it works for almost all wisp files — should work for all files which don’t do something crazy like implementing a wisp parser :)

<benq>I get '{ 55 + 88 }' or '({ 55 + 88 })'

<ArneBab_>run this . {55 + 88}

<ArneBab_>(mind the leading period)

<benq>I get '{ 55 + 88 }'

<ArneBab_>that’s correct

<ArneBab_>if you use curly infix in the wisp, you will get curly infix in the scheme

<ArneBab_>you need to activate its reader directive

<ArneBab_>!curly-infix

<benq>Ahh now it get interesting

<benq>I love directives .. (not so much)

<ArneBab_>hm … need to check that

<ArneBab_>ah, #!curly-infix

<benq>nope, and #!curly-infix doesn't do it either

<ArneBab_>please create a file with the following content:

<ArneBab_>#!curly-infix

<ArneBab_>(display {55 + 88})

<ArneBab_>(newline)

<ArneBab_>does guile <that file> display 143?

<benq>I check that, meanwhile examples/fib.w is also interesting.

<benq>#!curly-infix

<benq>((display {55 + 88}))

<benq>((newline))

<benq>thats the output

<benq>sorry

<ArneBab_>benq: ah, that’s from running guile wisp.scm on the file

<ArneBab_>what I gave you was the scheme testfile

<benq>Ah, sorry, yes then the result is correct

<benq>but I would be interested in the transformed code

<ArneBab_>now to transpile, use this content:

<ArneBab_>. #!curly-infix

<ArneBab_>display {55 + 88}

<ArneBab_>newline

<ArneBab_>(dear powers that be, I hope it’s ok to paste the lines three)

<benq>for me it's ok, is there some IRC rule about pasting stuff?

<benq>and how to process the file with this 3 lines?

<benq>guile wisp.scm t.w

<benq>the curly braces are still unprocessed.

<ArneBab_>benq: that’s intentional: guile wisp.scm t.w > t.scm; guile t.scm

<ArneBab_>curly braces are completely orthogonal to wisp

<ArneBab_>in other words: wisp plays well with curly places

<ArneBab_>in other words: wisp plays well with curly braces

<benq>yes I know that, but still ... (sorry to be annoying)

<ArneBab_>you’re not :)

<benq>It would be great if wisp could process/transform the curleys

<ArneBab_>if I were to implement curly-braces uncurlying, then wisp would no longer play well with curly braces

<ArneBab_>if someone were to add new features to curly braces, wisp would not have them

<benq>oh man this goes over my head :-)

<ArneBab_>therefore rather use: (write '{55 + 88})

<ArneBab_>then guile writes the uncurled version

<benq>ok arne: in a few month there is christmas, maybe you can make me a wisp-ben version ...

<ArneBab_>I can’t promise that, sorry :-)

<ArneBab_>wisp is as it is, because that’s the best way I see to do it. There are reasons I did not do it in any other way.

<ArneBab_>benq: so, if you want to uncurl curly infix, just use (write '{55 + 88}). the output is (+ 55 88)

<ArneBab_>you don’t actually need wisp for that

<benq>wisp-ben version: curly-braces are processed, delimiter is customizable, dot-prefix notation can be disabled (I think you don't like that either, aaand neoteric expressions!

<ArneBab_>→ use readable

<benq>readable: no "negative" indentation, lot's of additional sugar ('<*', '*>', '\\\\', .. ) I don't like.

<benq>so I think my processing pipeline will remain long.

<benq>or to put it in other words: I think you took the 'readable' tool and added the pythonic indention rules, which is really great. Then you took a lot of syntax away, a little too much since the dollar-sign and neoteric-expression and curly-infix is great. And then you added dot-prefix which I personally don't like, but I think this comes really down on personal preference.

<ArneBab_>but IIRC readable does have something for un-indenting

<ArneBab_>yepp, definitely

<ArneBab_> https://sourceforge.net/p/readable/wiki/Examples/

<ArneBab_>see the fixnum example

<benq>but you cannot do https://pastebin.com/JmxsYJLL

<ArneBab_>you cannot do that in wisp either (or rather: you should not be able to. If you can, that’s a bug in the parser)

<benq>I had cases where I've used this

<benq>not sure if it was exactly this case, but definitely cases where 'readable' didn't work.

<benq>your right this a bad example

<benq>and there is a more serious problem with 'readable': it changes the code! So you loose track of the lines.

<ArneBab_>this is a non-caught error in wisp.scm. The reader will throw an error here, because it’s too easy to get misled by the different indentation

<ArneBab_>benq: that’s true (or at least it was). I took some pains in wisp.scm to preserve lines and comments

<benq>And thats REALLY important. I don't know how I forgot that.

<benq>indeed; readable erases comments. Cannot use that.

<benq>I wait for christmas than. Maybe I'll get my pony.

<ArneBab_>or play with wisp :)

<ArneBab_>you already have curly infix there

<ArneBab_>and you can make the dollar sign yourself (but I really wouldn’t. It only looks simple to people used to programming languages with $)

<ArneBab_>benq: one great part: You found a bug in the reader. I just added a testcase for it. The next release should have consistent transpiling and direct reading

<ArneBab_>(direct reading treats intermediate indentation as the lower indentation level, which is the most wrong™ option)

<ArneBab_>benq: thank you!

<benq>hey you took away my dearest feature :-)

<benq>"you already have curly infix there" yes, but only in guile. Am I correct?

<civodul>wingo: i'm curious what you think of https://lists.gnu.org/archive/html/guile-devel/2017-09/msg00031.html

<civodul>i'd love to address it

<wingo>i thought the focus on the weak hash table was probably off-base, but it's an interesting candidate. i need to collect thoughts more tho

<wingo>incidentally it is possible to incrementally mark a large region

<wingo>i.e. without making the mark stack overflow

<civodul>oh, is it?

<wingo>yes, see comments in gc_mark.h

<civodul>how do you tell the GC that an object is partially marked?

<wingo>you mark a fixed size, then re-push the to-be-marked large object on the mark stack, remembering where you were

<wingo>but i didn't get any improvement when using that strategy to mark stacks

<wingo>which surprised me :/

<civodul>ok

<wingo>i think for that reason i didn't commit that test, and then lost the code when i lost my laptop :/

<civodul>bah :-/

<civodul>i can experiment with it

<wingo>i wanted to do some differential profiling at some point... i.e. profile a test file with size N, 2N, 3N, etc, and compare profiles

<civodul>yes that could be useful

<ArneBab_>benq: yes, only in Guile and other schemes which understand curly infix

<ArneBab_>benq: I’m currently unsure whether I’ll throw an error or treat it the same way as the transpiler

<dsmith-work>Tuesday Greetings, Guilers

<thomasd>hello #guile

<sneek>Welcome back thomasd, you have 2 messages.

<sneek>thomasd, nee`` says: I moved the system links like you said and reconfigure worked now. Thank you!

<sneek>thomasd, nee`` says: in the new parameters file (store (device ...)) is still #f

<thomasd>Hi Guilers, is there a guile interface for DBus?

<davexunit>not that I know of

<dsmith-work>I think civodul has one

<dsmith-work>Or maybe I'm thinking avahi instead

<thomasd>thinking about how to listen for dbus/udisk events in a GuixSD service, might not be easy :-/

<dsmith-work>thomasd: I saw this: https://wingolog.org/archives/2004/09/11/all-aboard maybe that's what I remember

<thomasd>yes, I found that, too, but I haven't found any other trace

<thomasd>Well, if anyone's looking for a project idea... ;-)

<dsmith-work>civodul: Didn't you have guile interface for dbus?

<dustyweb>beep beep

<cmaloney>boop

<civodul>dsmith-work: i think wingo had libdbus bindings a loooong time ago

<manumanumanu>ArneBab_: about curly infix... Wouldn't it be neater to make curly bracket partial application? Now, I don't think that would be possible to make as a library, but it would be pretty useful

<manumanumanu>{eq? x <>} => (cut eq? x <>)

<dsmith-work>civodul: Ok thanks.

<amz3`>tzag

<amz3`>ijp: did you look at my code?

<amz3`>ijp: silly, question, do you think it doable to cache some of what is compiled by jslink?

<amz3`> https://gitlab.com/ijp/guile/merge_requests/1/commits

<ArneBab_>manumanumanu: I think (cut eq? x <>) is so close to {eq? x <>) that we don’t need special syntax for that. For curly-infix there’s an dedicated section detailing why it is the only approach which can work well: https://srfi.schemers.org/srfi-105/srfi-105.html#rationale_changereader

<ArneBab_>manumanumanu: if it weren’t for that reasoning, I’d actually be against using up syntax characters for this.

<amz3`>“When you have a company idea, you usually want to start right away.”

<amz3`>Ah... those startup peoples...

<amz3`>Then you end up with dozens of dead projects

<amz3`>at the same time it's better than nothing

IRC channel logs

2017-09-19.log