IRC channel logs

<nalaginrut>morning guilers~

<zacts>hello

<zacts>so, I have a guile question

<zacts>how may I create a self executing guile source code file?

<zacts>if possible I prefer not to launch one from a #!/bin/bash

<zacts>I can't seem to get #!/usr/bin/guile to work for me either though

<zacts>I have some really simple C tools I've written for myself, and I'm reimplemented them in scheme

<zacts>but I want to move like hello.scm -> ~/bin/hello for example

<zacts>and be able to just type 'hello', rather than 'guile -s ~/bin/hello'

<mark_weaver>zacts: https://gnu.org/software/guile/manual/html_node/The-Top-of-a-Script-File.html#The-Top-of-a-Script-File

<mark_weaver>particularly the last two examples here: https://gnu.org/software/guile/manual/html_node/Scripting-Examples.html#Scripting-Examples

<zacts>oh perfect, thanks!

<mark_weaver>np!

<zacts>(I must have missed that somehow, when I searched the doc)

<zacts>although, I was kind of in a hurry about to go somewhere at the time

<mark_weaver>it takes some time to learn your way around the guile manual

<mark_weaver>probably it could be organized a bit better

<paroneayea>it's a great manual, but it's pretty different than most texinfo layout from the frontpage's ToC at least

<paroneayea>but I do <3 the guile reference manual

<paroneayea>there's room for improvement... if it had more tutorial stuff, it'd be even better! but I do like it quite a bit :)

<paroneayea>hey ijp

<paroneayea>if you do guile->js

<paroneayea> https://github.com/mozilla/source-map

<paroneayea>used by a different wisp than ArneBab 's :) https://github.com/Gozala/wisp

<ArneBab>paroneayea: that reminds me that I wanted to link to that wisp so people can find it if they stumble over my site while searching for it… done now ☺

<civodul>Hello Guilers!

<ArneBab>moin civodul

<ArneBab>zacts: nowadays I think that the best way to create guile-scripts is shell-deferring: http://draketo.de/proj/py2guile/#sec-3-3-3-2-1

<ArneBab>#!/bin/sh

<ArneBab># -*- scheme -*-

<ArneBab>exec guile -e main -s "$0" "$@"

<ArneBab># Thanks to exec, the following lines

<ArneBab># are never seen by the shell.

<ArneBab>!#

<ArneBab>^ I hope this does not count as flooding

<ArneBab>zacts: one advantage of that is that you can adjust the PATH to select a different guile.

<ArneBab>for example this here automatically adds the path of the parent-directory of the script file to the search path of guile: exec guile -L $(dirname $(dirname $(realpath "$0"))) --language=wisp -e '(@@ (examples ensemble-estimation) main)' -s "$0" "$@"

<ArneBab> https://bitbucket.org/ArneBab/wisp/src/3d69d9715898321bb8f4bca7a7f187796bfd75bc/examples/ensemble-estimation.w?at=default

<ArneBab>zacts: … I just realized that I missed your “I don’t want to defer to bash” line… sorry

<zacts>ArneBab: heh, yeah that's ok

<zacts>the only reason I didn't want to defer to bash is that for some of my scripts I want more efficient startup times

<zacts>(and the only reason it's noticable is that a few of my scripts just do a bunch of (display ...) to the screen)

<zacts>I notice a split second lag sometimes

<zacts>but shell deferring sounds really useful!

<zacts>so thanks for the tip!

<zacts>I guess I should share a tip with you that I just discovered, perhaps you know of it.

<zacts>ArneBab: I now use 'less +F' rather than 'tail -f' for log files

<zacts>'less +f' let's you pause and grep, and then unpause while it's displaying a live log file

<zacts>s/'less +f'/'less +F'/

<ArneBab>wow n nice!

<ArneBab>zacts: from my tests, bash deferring costs about 6ms startup time - but the variance rises (from 2.4ms to 4.6ms)

<ArneBab>so >15% of your calls could take more than 10ms longer than with the meta-trick.

<ArneBab>using another shell than bash might reduce that cost (I guess that it’s due to file accesses).

<ArneBab>zacts: with /bin/dash instead of /bin/sh in the header, I cannot distinguish the shell-deferring from the env anymore.

<ArneBab>bash: 20.19 +- 3.64608008689

<ArneBab>dash: 17.18 +- 3.98341561979

<ArneBab>env: 17.4 +- 3.99749921826

<ArneBab>meta: 15.72 +- 2.0836506425

<ArneBab>(this is on my work-machine, not at home, that’s why it’s faster)

<zacts>yeah /bin/sh is symlinked to /bin/bash on my system

<zacts>I would change /bin/sh to another shell, like mksh or dash, but it stops my system from being able to boot (Slackware64 for now until I can replace it with Guix or Dragora)

<civodul>ArneBab: for the comparison to be fair, one must make sure each shell loads the same amount of extra functionality

<civodul>like programmable completion, etc.

<ArneBab>civodul: not for this test: it’s only a single feature test.

<ArneBab>civodul: sh --noprofile seems to have the same properties.

<ArneBab>civodul: and /bin/sh should already launch bash in sh-compatibility mmode

<ArneBab>civodul: I re-did the test, and dash only saved 0.5ms…

<ArneBab>(on average in 1000 tests, with a standard deviation of 2.5)

<civodul>heh

<wleslie>in ~400 cases, the test completed before they began

<wleslie>but you know, that's not normal

<wleslie>ba-dum-tish

<ArneBab>☺

<ArneBab>wleslie: it *saved* 0.5ms - dash still took 17ms

<ArneBab>I also updated py2guile (to be uploaded): that also contains the min-max range for the tests

<davexunit>ArneBab: someone made a clojure-ish lisp -> js thing named Wisp http://www.jeditoolkit.com/try-wisp/

<davexunit>first someone forks SLIME and names it Sly (the name of my game engine), and now this

<ArneBab>davexunit: I know: Our emacs modes once clashed ☺ — I linked it from the wisp page: http://draketo.de/light/english/wisp-lisp-indentation-preprocessor

<davexunit>lots of name clashes lately

<davexunit>oh okay

<davexunit>you already know :)

<ArneBab>yes, but the link is from today

<ArneBab>paroneayea: spoke about it

<davexunit>is it just me, or is clojure syntax gross?

<dsmith-work>Morning Greetings, Guilers

<ArneBab>moin dsmith-work

<davexunit>I feel like every other brace is different

<dsmith-work>davexunit: Looks gross to me.

<davexunit>(fn [x y] { ... })

<taylanub>isn't it fairly normal sexprs with few non-conventional extensions?

<taylanub>davexunit: huh, seriously?

<davexunit>they have special read syntax for maps

<taylanub>is there some logic behind that?

<davexunit>{ a 1, b 2 }

<davexunit>and at least in real clojure, you *have* to use [] instead of () in certain cases

<davexunit>which ones, I don't know

<ArneBab>here’s a comparison: http://clojure.org/lisps

*taylanub is too ignorant -- ceases judgement

<davexunit>ugh, why did Clojure have to be the Lisp that finally got mainstream adoption?

<ArneBab>it gives you the java libraries

<davexunit>and every other Lisp gives you an FFI for all of the C libraries...

<unknown_lamer>ArneBab: so does kawa

<ArneBab>maybe add that people talk about clojure on conferences

<davexunit>because it got more adoption somehow, that's why

<davexunit>due to the java interop

<unknown_lamer>random chance, it's like when there was a bit of a common lisp revival

<ArneBab>kawa says it has an “incomplete tutorial”

<unknown_lamer>paul graham says it is cool ergo I will hack in it

<ArneBab>clojure people talk a lot about cool new immutable datastructures

<unknown_lamer>they aren't hardcore enough to just move onto haskell ;)

<davexunit>they're not really new though :(

<unknown_lamer>"I haven't mutated anything in ten years!"

<ArneBab>to java they are…

<davexunit>well, yeah

<davexunit>I guess I just get extra frustrated because I like Scheme an order of magnitude more than any other Lisp I've ever tried

<davexunit>and it never gets the recognition it deserves, unless John Carmack tweets about it or something.

<ArneBab>target group: Java programmers (the biggest group of programmes). Do something radically new for them. Well done website. Say “concurrency”. See http://clojure.org/rationale

<ArneBab>this was the clojure site in 2009: Already looked good: https://web.archive.org/web/20090211203927/http://clojure.org/

<davexunit>I just wish that you didn't have to target Java programmers to make something successful

<ArneBab>nowadays it also targets .NET and Javascript…

<ArneBab>which means: Everybody except for GNU/Linux system programming.

<ArneBab>(and all the hard lowlevel stuff)

<ArneBab>^ except that

<ota>ArneBab, tnx for Clojure link

<ArneBab>davexunit: I think guile suffers from not being available effortlessly for non-GNU systems

<ArneBab>if you create a product, every system you do not support costs you a disproportionate number of users

<ArneBab>customers

<ArneBab>I cannot give the guile programs I write to windows using friends (90% of my friends).

<paroneayea>davexunit: I'm also not a fan of clojure syntax

<paroneayea>especially not the let and cond stuff

<davexunit>ArneBab: partly I agree, and partly I say "fuck windows"

<paroneayea>(let (var value var value) wat)

<paroneayea>actually

<ArneBab>davexunit: essentially I’m limited to writing programs for myself and for web servers.

<paroneayea>(let [var value var value] wat)

<davexunit>it runs on real operating systems (gnu/linux bsd os x etc.)

<ArneBab>davexunit: are there guile packages for OSX?

<davexunit>yeah

<paroneayea>guile suffers from some things which are all fixable

<davexunit>we have some amount of os x users.

<ArneBab>(or rather: a simple way to package a guile program as app?)

<ArneBab>paroneayea: yes, but it’s work. And the clojure people seem to have focussed on that thankless work

<davexunit>guile on windows pretty much works, afaik

<davexunit>what do you mean by "app"?

<davexunit>as a nasty ball of all the dependencies? no thanks.

<ArneBab>davexunit: exactly as that: What all the normal users want

<ArneBab>something I can put on the app-store

<davexunit>who wants that?

<ArneBab>I’d guess >90% of OSX users

<ArneBab>the few of my friends who use OSX

<ArneBab>my parents

<ArneBab>my uncle

<davexunit>guile on ios would be sad

<ArneBab>why?

<davexunit>not an ounce of freedom

<ArneBab>it would be a program which people can keep using when they switch to something freer

<ArneBab>I’d define “easy to ship” as “there’s a script in the guile distribution. Call it to create a release for every platform.”

<ArneBab>something like `guild ship`

<davexunit>that problem is outside of guile's purview, IMO

<davexunit>system dependencies and such

*wingo would like a way to statically compile an app to a binary

<wingo>just dynamically linking to libc and such things

<wingo>all scheme source text included, all compiled scheme included, etc

<wingo>libguile included (or not)

*mario-goulart hands wingo a machine with 128GB of RAM

<ArneBab>davexunit: it doesn’t matter where the way to ship to Windows users is defined. That’s an implementation detail. But if that doesn’t exist (or takes more than a short look on the website), then most people cannot ship to Windows.

<wingo>mario-goulart: :)

<ArneBab>or OSX

<ArneBab>or at least not in a way which 90% of users will accept.

<wingo>i think such a thing shouldn't take more than what a guile process takes already

<ArneBab>davexunit: question: What would guile have to provide to make it possible to write the next skype (or jitsi) in guile?

<wingo>which is mostly read-only and so shareable, at least among different instances of the app

<ArneBab>or rather: to make that likely

<davexunit>ArneBab: I don't see guile itself missing anything.

<ArneBab>On the Guile website I see lots of potential, but few solutions.

<wingo>davexunit: really? :)

<wingo>there's lots to do, yo :)

<davexunit>community-wise, we need gtk bindings that are in good shape and stuff

<ArneBab>davexunit: I do: I thought about porting a game I wrote in Python to guile. Then I realized that I would not be able to give it to any of my friends.

<ArneBab>even less the visitors of my website.

<ArneBab>(this isn’t a change, by the way: Currently it doesn’t run conveniently on non-Linux either: The Python porting story is also not that great)

<davexunit>I know there's lots to do, but this idea that Guile isn't suitable for, IMO, bad software distribution practices doesn't convince me.

<davexunit>of course, I'm certainly interested in native compilation, unboxed flonum operations, etc.

<ArneBab>the problem I see is that most users rely on these practices, and we cannot change the users without giving them cool applications.

<davexunit>and even a statically compiled guile, to displace tinyscheme in the Hurd project.

<ArneBab>nowadays there’s android, built on free software, and it doesn’t have guile, so I could not ship a program there.

<paroneayea>I think the following things could put guile light years ahead:

<ArneBab>but I understand that all the things I’m complaining about are *hard*, even though they look easy

<ArneBab>Python didn’t get the shipping story right during the last decade, even though multiple teams tried

<davexunit>ArneBab: built on free software, but users only use the proprietary stuff on top.

<paroneayea> - a more modern, friendly looking website, something that doesn't give the impression that Guile merely emerged from RMS' forehead somewhere in the late 1990s. There's a ton going on in Guile, tons of things for modern users, and users don't know!

<paroneayea> - a nice, friendly tutorial!

<paroneayea> - alias ice-9 -> guile

<ArneBab>davexunit: that’s not true. There’s quite a bit of free software. It’s just that the proprietary software often delivers the features users want.

<ArneBab>paroneayea: +1 to alias!

<paroneayea> - alias all the srfi modules to more useful names

<paroneayea>(use-modules (srfi lists))

<paroneayea>instead of

<paroneayea>(use-modules (srfi srfi-1))

<paroneayea> - theme the docs so they don't look so 1998

<paroneayea>the html export

<paroneayea>and finally

<paroneayea> - do outreach to developers encouraging new ones to come in and try things out

<paroneayea>that means guile community members talking at usergroups, etc, trying to get talks into conferences

<ArneBab>paroneayea: and fix lilypond, texmax and gnucash. That these do not work with guile 2.x is a desaster PR wise.

<paroneayea>oh and one more

<paroneayea>once you have all that, concurrently even

<paroneayea> - get more basic building block libraries in a good state (a json library people agree on, database binding system like sqlalchemy, some kind of templating system, a web framework) and get them packaged for main distros

<paroneayea>in the interim we should get guix packaged for main distros maybe

<davexunit>I would like to talk about Guile/Guix at conferences sometime

<taylanub>paroneayea: AFAIK all existing Guile developers (which aren't that many) have their hands full. maybe you can cook up patches for these recommendations and send them to the ML? :-)

<paroneayea>yes, Sly is a good selling point too

<paroneayea>taylanub: I will be taking some months off, I might be able to help in some ways, though I have a feeling that I don't know enough to muck with guile internals on some things :)

<ArneBab>davexunit: I think one of the main things holding up free software is that the free software devs don’t sell their software. Our package managers are lightyears ahead of appstores, but they lack one crucial feature: An easy way to pay.

<paroneayea>but it also helps to have guile leaders agree that these are priorities and announce that they are and call for help :)

<paroneayea>wingo: ^^^ ;)

<davexunit>guile-json is good enough, despite my disagreements with it's implementation

<paroneayea>the call for help thing is really important I think

<paroneayea>if you have an action plan

*wingo catches up

<davexunit>quasiquote + sxml is our templating system

<ArneBab>I think most of the parts of guile are good enough, but I agree on the tutorial: It’s hard to find how to do stuff.

<ArneBab>we can do all that, but we don’t say so.

<paroneayea>ArneBab: I already knew several lisps and I had a hard time diving in

<paroneayea>racket is killing guile on the intro process

<paroneayea>it's so easy to get running and doing cool things fast

<paroneayea>with guile you can start doing cool computer science'y things fast ;)

<ArneBab>I only knew emacs lisp, and I stumbled a lot. I only managed to get in due to the great help from wingo, mark_weaver and others.

<davexunit>a database abstraction is needed, but hard to do well.

<paroneayea>and actually not even that, you can do cool computer sciencey things faster than most computer sciencey things elsewhere

<ArneBab>I think it would already help a lot to have a list with good practices

<paroneayea>but not faster than doing actually useful things like, users writing utilities for themselves in python

<paroneayea>ArneBab: something like PEP-8?

<wingo>1+ regarding racket; they do so many great things that a first-order approximation of "what would be better for guile" is "what is racket doing" :-)

<paroneayea>I'm not sure what that would look like for guile :)

<ArneBab>not list all the strings functions, but list the conventional (and good and fast) way to do string manipulation

<davexunit>I write all of my personal utilities in guile

<davexunit>and one-off scripts at the FSF

<ArneBab>paroneayea: similar, but more like a tutorial.

<davexunit>so, an official tutorial on the website would be a good start?

<wingo>the other thing i would look at, and look hard at, is node and specifically npm

<ArneBab>in short: this: http://stevelosh.com/blog/2013/09/teach-dont-tell/

<wingo>npm enables loads of things to happen in js-land

<paroneayea>davexunit: yeah I know you do, and that inspires me! but I think getting from "opening the guile manual" to "writing utilities for yourself" is not a clear transition for new guilers

<davexunit>npm :(

<wingo>hehe :)

<ArneBab>npm ~ PyPI ← great

<wingo>you can disagree with the form of the thing while also recognizing what it contributes :)

<paroneayea>as someone who's done lots of language packaging, I used to be very up on it

<ArneBab>it essentially means guildhall

<paroneayea>but I'm less so now

<paroneayea>but

<davexunit>I guess that's where guildhall comes in

<paroneayea>I agree it's important for developers

<paroneayea>you could say "guix is our guildhall now" but

<wingo>in the case of npm what it's really about is enabling people to work together

<davexunit>it's not

<wingo>which is something we're not great at in guile :)

<davexunit>no?

<davexunit>I guess there's truth to that

<ArneBab>npm and pypi and such make it easy to work together without interacting a lot.

<paroneayea>davexunit: cwebber@earlgrey:~$ apt-cache search guile | grep guile | wc -l

<paroneayea>18

<paroneayea>only 18 really-obviously-guile packages in debian

<paroneayea>eek

<ArneBab>3 in Gentoo

<mario-goulart>paroneayea: try "grep -i guile"

<paroneayea>19 ;p

<davexunit>paroneayea: yeah, we need packagers.

<davexunit>debian is notoriously difficult to package for, so I'm not stepping up for that one.

<ArneBab>this could be circumvented by an easy to access guildhall. And that would work for all distros. And it would be a good base to create a standard packaging script (package <guildhall name> → deb/ebuild/rpm/guix)

<davexunit>agreed about guildhall

<davexunit>sorry for my grumpiness this morning. it's one of those days when you realize your industry sucks and you'll never do anything you actually want to do for real money.

<paroneayea>having "a good base for creating standard packaging" would be great

<wingo>for me the usual reason to be bashful about guile is speed, so i'm working on that.

<paroneayea>wingo: as a cpython user I'd say: you don't have a lot to worry about :)

<wingo>haha :-)

<paroneayea>that's *not* guile's adoption bottleneck

<paroneayea>people are still using ruby!

<wingo>hehe :)

<davexunit>ruby is hopeless for optimization

<paroneayea>I partly bring this stuff up because I introduced tsyesika to Guile, and she started to get into it

<wingo>davexunit: not sure about that :)

<paroneayea>oh no she's in channel ;)

<paroneayea>now she'll hear me talking about her

<wingo>however! given the choice between e.g. ruby and guile the obvious choice is ruby because of ecosystem, newbie on-boarding material, large community, etc

<Tsyesika>paroneayea: i need to find time to do more scheme

<paroneayea>and I think we shared that we both had the experience looking at the guile site and assuming that it was just some legacy, dust accumulating gnu project, and that was the wrong impression

<davexunit>wingo: I'll certainly take your word for it since you actually know what goes into fast interpreters/compilers

<wingo>if guile is really quite fast it can make people more motivated to build those things

<wingo>paroneayea: that's an incredibly important data point!

<wingo>i wonder how to fix that

<paroneayea>contrast with Hy, which I think has had more adoption recently than Guile and is *way worse* (and I say that as a Hy contributor)

<Tsyesika>i might write some this weekend maybe

<paroneayea> http://hy.readthedocs.org/en/latest/ it just has a vanilla readthedocs page, but it looks nice

<bipt>it's interesting how much web design influences people's perceptions. i've heard similar comments about texinfo html manuals

<paroneayea>and the page immediately guides you how to get started

<paroneayea>bipt: yeah

<paroneayea>bipt: there was that emacs thread

<paroneayea>and actually I really like info, but I agree that texinfo html output is terrible looking. Yes, lilypond is a great example that it could look better

<paroneayea>we need a better default and for all gnu projects to use it.

<ArneBab>so, to list what we had: modern website, modern docs¹, tutorial², alias srfi and ice-9 modules, racket-like intro, easy to find basic building block libraries (json, database, templating, web framework, game framework, ...), give talks, easy to use guildhall.

<paroneayea>yes

<davexunit>paroneayea: civodul proposed a better default and karl berry rejected it without discussion

<ArneBab>¹: maybe with this: https://github.com/nicferrier/gnudoc-js

<paroneayea>davexunit: what

<paroneayea>really??

<paroneayea>davexunit: that's highly disturbing

<ArneBab>²: follow this guide: http://stevelosh.com/blog/2013/09/teach-dont-tell/

<davexunit>it wasn't anything radical

<davexunit>just the style emacs uses

<davexunit>even that is an improvement

<taylanub>maybe we can beg Luis Felipe to make a neat website and doc theme for us. I could even throw some money in their direction, having seen their work on GuixSD artwork. :-)

<ArneBab>davexunit: you’re doing the FSF websites nowadays, right?

<paroneayea>davexunit: yeah that's still dated but much nicer

<paroneayea>taylanub: I suspect given talks with john that the FSF would be willing to be a fiscal sponsor for raising some funds for that

<paroneayea>and I'd be willing to donate

<paroneayea>to put words in john's mouth :)

<davexunit>ArneBab: certain ones, yeah.

<paroneayea>but he's expressed interest to me before in doing more fiscal sponsorship

<paroneayea>for gnu projects

<davexunit>it's hard not to get depressed about gnu when the folks at the top don't want to change

<paroneayea>taylanub: commissioning luis felipe to make a website would be great

<ArneBab>davexunit: any chance to allow you to do some paid work to make the guile website look as modern as the clojure one?

<davexunit>ArneBab: no.

<ArneBab>paroneayea: just making a design isn’t enough: all the links have to keep working.

<paroneayea>ArneBab: sure

<paroneayea>how is the site currently built?

<ArneBab>and doing that right is hard work…

<davexunit>I could ask but it would surely be denied because there's too much other work to do on FSF stuff.

<civodul>davexunit: progress is being made on that CSS topic, though :-)

<davexunit>oh is it?

<davexunit>that's good to hear.

<paroneayea>I think commissioining someone else, like luis felipe, is a great idea.

<davexunit>I should tone down my cynicism I guess.

<ArneBab>I have to go AFK for some time

<davexunit>paroneayea: sounds like a good idea to me

<ArneBab>I’ll read my backlog — bbl

<paroneayea>wingo: how do you feel about that

*wingo catches up again :)

<paroneayea>we would need to know how the website is put together

<bipt>speaking of websites and people working together...would anyone else be interested in a guile wiki? (i have hosting and a domain i could use for one)

<davexunit>luis might do it free of charge, as he's done for guix

<paroneayea>bipt: I would!

<davexunit>bipt: shouldn't it be hosted on gnu.org?

<paroneayea>davexunit: he might! though I think doing a whole website is extra work

<davexunit>sure

<bipt>possibly. i didn't know if gnu had a wiki-farm or not

<davexunit>we don't

<davexunit>but it seems weird to rely on a third party host

<paroneayea>davexunit just wants to volunteer for more sysadmin tasks ;)

<wingo>paroneayea: sounds like a great idea to me

<wingo>the current site is built using spit and bailing wire

<wingo>it is horrific inside that cvs repo :)

<paroneayea>wingo: so, as guile (co?-)bdfn (benevolent dictator for now?), how would you feel about seeing if the FSF is willing to be the fiscal sponsor of that

<paroneayea>set up a donate link basically

<paroneayea>or

<paroneayea>should we just do a paypal thing

<wingo>paroneayea: definitely co-, as ludo and mark are also maintainers

<paroneayea>:)

<bipt>well, i was considering setting up an unofficial one on my own initiative, but gnu-approved hosting would be better

<wingo>and "maintainer" is probably better than anything involving "dictator" :)

<paroneayea>benevolent maintainers for the present

<paroneayea>mark_weaver: ^^^ your input also valuable :)

<paroneayea>I don't think ludo is on here right now right? I forget his username.

<taylanub>civodul

<paroneayea>oho

<paroneayea>I'm so bad at mappings :(

<paroneayea>civodul: ^^^^

<taylanub>(read it in reverse ;) )

<paroneayea>ohhhhhhhhhhhhhhhhhhhhhh

<paroneayea>now I see

<paroneayea>okay

<mario-goulart>On the CHICKEN land we have this kind of discussions pretty frequently and we usually conclude that "we need more and better libraries". Maybe CHICKEN's context is a bit different from Guile's in some aspects, but I think that conclusion still applies, to some extent. We have gone through basically all things discussed here: speed, better sites, wiki, deployment, donations, marketing etc. Many times. Again, not sure it is applicable

<mario-goulart>to Guile, but I thought I should share the experience with CHICKEN.

<wingo>paroneayea: regarding a funding drive: i think it's a great idea, i'm happy to provide support/endorsement, but a bit overloaded atm and so would be delighted to delegate :)

<paroneayea>wingo: mark_weaver: civodul: I have to have a call with John soon about MediaGoblin fiscal sponsorship stuff soon anyway. Should I bring it up there?

<wingo>paroneayea: that would be great, thank you!

<paroneayea>wingo: I think we don't have to do a full blown crowdfunding campaign

<wingo>mario-goulart: interesting, thanks for the info

<mario-goulart>yw

<paroneayea>just setting up a donate link, and asking everyone to pitch in to funding an overhaul

<paroneayea>probably will get us pretty far

<civodul>paroneayea: yes, sure!

<paroneayea>I can help spread the word.

<wingo>y'all are doing better on that front, given eggs

<paroneayea>okay.

<mario-goulart>still not enough!

<paroneayea>wingo: I think you making a blogpost would help, you have a good readership base esp syndicated to planet gnome and stuff

<wingo>paroneayea: yes, very happy to do that

<mario-goulart>Still hard to get things done as easily as with mainstream languagens.

<wingo>i have some posts ideas queued up too

<civodul>paroneayea: the message should be that people are hosting their web site elsewhere because gnu.org is stalled, and that this is bad for GNU

<paroneayea>civodul: yeah, well... I think we shouldn't message it in a way that makes gnu.org look bad (even if the state is bad)

<paroneayea>but more that "we want the rest of the world to see how awesome guile is so we want to make a dedicated, modern website!"

<paroneayea>but I agree that behind the scenes, that's partly it ;)

<paroneayea>btw, does someone here know luis felipe?

<paroneayea>would they be willing to volunteer to reach out and see if they're willing to work on the design, and Cc: me on the email?

<civodul>paroneayea: yes sure, the idea must be expressed positively and i'm sure we can count on you for that ;-)

<paroneayea>if not I can do it but spreading around some of this is helpful, as I'm in crunch mode myself :)

<wingo>i don't know him fwiw

<paroneayea>okay

<paroneayea>so here's the deal, if I haven't reported back on this in 2 weeks

<paroneayea>someone pester me :)

<paroneayea>I'm going to start rolling on the talking to john thing

<paroneayea>if someone wants to reach out to luis felipe that would be great, otherwise I can do it

<paroneayea>but let's make this happen :)

<wingo>thank you paroneayea! :-)

<civodul>yay!

<wingo>for getting started

<wingo>i will try to help as i can but your energy is really great, thank you :)

<civodul>paroneayea: we could talk to Luis when they're around, but maybe once you've heard from johns?

<davexunit>paroneayea is a good motivating force

<paroneayea>:)

<paroneayea>wingo: mark_weaver: civodul: I'd also like to write up "an action plan for guile" blogpost, mostly talking about what we talked about in here today, but I'll run it by you all first. It seems like #guile mostly had consensus on priorities though!

<wingo>cue mr t regarding plans

<civodul>ok!

<wingo>bipt: i have never had much success with wikis, but maybe it could work :)

<paroneayea>ooh

<paroneayea>we should make the website redesign look like this ;) https://www.gentoo.org/news/2015/03/31/website-update.html

*paroneayea actually likes that aesthetic but does not advocate for it!

<ArneBab>I think a good way to check what’s to do is to look at what we need to write a tutorial: get guile 2.x (currently: get the tarball - means we cannot get it into distros), run the first program (works well), test the REPL (mostly works: document the most useful ,X commands), do a small task easily (srfi-??, I can explain (ice-9 cool-feature), but not “check info for right SRFI, hope you got the right one, ask in IRC if there’s something

<ArneBab>better”), share your tool (guildhall, since distros are out of question), ...

<ArneBab>I think that would actually be enough for a short Guile tutorial.

<taylanub>something explaining how to use the debugger would be great, for those not accustomed to gdb.

<taylanub>also, is there a shortcut for something like ',bt #:full? #t #:width 9999'?

<ArneBab>On related news: py2guile is almost ready. I got an offer from the freenet maintainer to help improve it. I want to share the source under GPL while also selling it as PDF+epub+mobi+print for all those who don’t want to build it from source.

<ArneBab>taylanub: I’d love to read a tutorial just on debugging in guile!

<ArneBab>the first blocker I see in the tutorial are the aliases for SRFIs

<ArneBab>how would one go about creating these?

<civodul>gentoo.org is excellent :-)

<davexunit>ArneBab: not sure it's possible right now

<davexunit>because the module's name is tied to it's source file name

<davexunit>its*

<mark_weaver>I don't see why those aliases should be a blocker to create a tutorial.

<ArneBab>so I’d create new modules which use the SRFIs

<ArneBab>it would also be possible to write down all SRFIs instead

<ArneBab>(list them)

<davexunit>yeah, a tutorial could be done without them for sure.

<davexunit>srfi-1 is probably the only one a tutorial would even need to touch upon

<mark_weaver>a guile tutorial should teach people the more widely accepted conventions of how to write guile programs, not some non-standard thing that one of us personally prefers

<ArneBab>what are those conventions?

<davexunit>things like "prefer match over car/cdr/cadr/etc."

<ArneBab>(just to get that out of the way: note that I do *not* think that a guile tutorial should use wisp)

<mark_weaver>I'm not sure I can easily list the conventions, and maybe that's too strong a statement to make.

<ArneBab>I think documentation of those conventions is badly missing: Just call them best practices.

<davexunit>perhaps a mailing list thread can gather some conventions used for the scheme code in guile core?

<mark_weaver>there is of course some diversity in our community

<ArneBab>that would be great!

<davexunit>if the comaintainers state a thing or two thay they think is an accepted convention, we can go from there.

<mark_weaver>I guess I'm just saying that inventing new module names for a tutorial is a bad idea, IMO.

<ArneBab>mark_weaver: it wouldn’t be only for the tutorial.

<davexunit>most of us roughly follow these style guidelines: http://mumble.net/~campbell/scheme/style.txt

<davexunit>so some of the stuff in here could be adapted

<davexunit>there*

<ArneBab>it’s from the problems paroneayea identifierd.

<mark_weaver>the reason that SRFIs are numbered instead of named is that *anyone* can create a SRFI and finalize it

<mark_weaver>there's no filtering process except in what implementors end up implementing and what users decide to use

<ArneBab>that’s clear, but it doesn’t mean that guile cannot make them easier to use by giving them easy names.

<paroneayea>mark_weaver: yes, that's true, but I think it's hard for users to understand and remember those

<mark_weaver>so e.g. we end up with multiple versions of the same basic concept

<paroneayea>I think wingo said guile's import system can handle aliases right?

<ArneBab>I have a hard time remembering what SRFI provides what I need

<paroneayea>so maybe that can help a lot

<paroneayea>right now it feels like I'm importing robot serial numbers

<mark_weaver>for example, there are multiple SRFIs for structs

<ArneBab>something like (use-modules (srfi list)) would make it much easier.

<paroneayea>srfi-11 and srfi-42, get ready to roll out from the ice-9 robocenter

<ArneBab>mark_weaver: that’s a problem in itself: For guile users, guile developers should decide which one of these is canonical.

<ArneBab>(which one is most suited for guile programs)

<paroneayea>+1

<paroneayea>guile does do that some in the manual

<mark_weaver>the guile community decided on many "canonical" modules in the past that are now quite undesirable

<mark_weaver>for example, we have (ice-9 streams)

<davexunit>ArneBab: that's assuming we support the "one way to do it" approach

<paroneayea>the naming thing is more important to me though

<ArneBab>mark_weaver: that’s change

<paroneayea>and also, I think ice-9 aliased to "guile" would make a lot more sense

<mark_weaver>a nice name, except that it was a bad API and now we have a much better and more popular stream library (srfi srfi-41)

<paroneayea>ice-9 is kind of guile's stdlib

<ArneBab>davexunit: there will always be more than one way to do it. The question is: How do I as new user find out which way to try first.

<paroneayea>so say that (guile streams) is deprecated in favor of (srfi streams) ;)

<paroneayea>ArneBab: right!

<mark_weaver>regarding ice-9 -> guile, we could use that opportunity to make a new 'guile' namespace that doesn't have so much old garbage in it

<ArneBab>(or as experienced user who starts into a new domain)

<paroneayea>and I think guile having more than one way to do it is a huge feature

<paroneayea>but it's overwhelming to newcomers; analysis paralysis

<mark_weaver>in other words, I'd rather make (guile ...) a namespace for more modern, carefully selected, well designed modules

<bipt>ice-10 ;)

<paroneayea>mark_weaver: that would make sense to me

<paroneayea>bipt: haha

<mark_weaver>rather than simply make it a copy of ice-9

<mark_weaver>s/copy/alias/

<davexunit>that sounds like a good approach

<davexunit>ice-9 certainly has some cruft in it

<paroneayea>also, guile-json or some variant thereof should be part of guile itself, just sayin' :)

<paroneayea>you can't get around json these days

<ArneBab>how much effort would it be, and is it possible to estimate an ETA?

<paroneayea>it's everywhere :)

<mark_weaver>btw, note that there's another stream library called SRFI-40

<ArneBab>(doing the careful selections)

<mark_weaver>and it turned out to have flaws, so now there's SRFI-41

<paroneayea>mark_weaver: python does this well

<davexunit>paroneayea: since we have sxml modules already, an sjson module might be nice. :)

<mark_weaver>if they had assigned SRFI-40 the name "streams", then SRFI-41 would have needed a different name.

<paroneayea>sometimes it turns out there's a new, preferred module

<paroneayea>there's some variant of naming and the old module's docs redirect you to the new one, not unlike what happens in guile's manual already

<paroneayea>it's just, now we have srfi aliases!

<ArneBab>mark_weaver: I do not disagree with the SRFI process. I just think, guile could create the aliases for established stuff.

<mark_weaver>if we assign them names, then we have to be *very* careful that they are the right thing (TM) for the foreseeable future.

<paroneayea>mark_weaver: I have an answer to the guile ice-9 alias vs redo thing ;)

<paroneayea>let's do a (cruft) one too

<paroneayea>and (ice-9) can combine them together

<paroneayea>;)

<paroneayea>backwards compatibility ;)

<mark_weaver>btw, I really appreciate this conversation.

<paroneayea>me too!

<paroneayea>it's making me feel more confident and excited about guile stuff than I already am!

<mark_weaver>although I am raising some difficulties with some of the suggestions, I also agree that there are serious problems and that we should try to address them.

<paroneayea>serious problems... or serious opportunities??!! ;D

<ArneBab>it’s making me want to write a tutorial on guile (after finishing py2guile, hopefully next week)

<paroneayea>ArneBab: I'll happily review that!

<mark_weaver>paroneayea: heh, I appreciate your good energy :)

<ArneBab>yay!

<davexunit>mark_weaver: paroneayea has a lot of it.

<ArneBab>To get a focus for a tutorial: For which users would guile already be one of the best tools?

<paroneayea>ArneBab: I might be able to help some, I wrote most of the Hy tutorial, and people seem to think it's okay :)

<paroneayea>but also

<paroneayea>well

<ArneBab>paroneayea: nice!

<paroneayea>actually no I don't have time ;)

<paroneayea>but

<paroneayea>I can help review!

<ArneBab>☺

<paroneayea>and be excited ;)

<ArneBab>^ that’s very helpful!

<paroneayea>that seems my primary job around here

<davexunit>I should write a simple guile web dev tutorial

<ArneBab>that would be cool!

<paroneayea>davexunit: YES

<paroneayea>DO IT

<mark_weaver>davexunit: you would be a great person to do that! :)

<paroneayea>DO IT DO IT!

<mark_weaver>the perfect person, really :)

<davexunit>I've written a couple web applications in guile now so...

<paroneayea>btw I emailed John to ask about the funding thing

<paroneayea>I'll update as things happen

<davexunit>can dive into guile-json, (ice-9 match), etc.

<ArneBab>and the dry PR thoughts say “a tutorial on web dev with guile written by one of the GNU website maintainers would carry lots of credibility”

<ArneBab>paroneayea: thanks!

<paroneayea>ArneBab: ++

<davexunit>alright, I'll work on that.

<paroneayea>Guile's been around for a long time, but I think programming languages can grow in popularity later in their existence

<paroneayea>haskell's exponential growth lately is proof of that

<taylanub>Python isn't exactly young either, is it?

<ArneBab>they usually need lots of time to hatch

<davexunit>Ruby had been around for 10 years before it caught on

<ArneBab>I looked at the Python code swarm: For the first 3 years Guide wrote it completely alone, then some people joined in and 2000 it took off

<paroneayea>taylanub: yeah, not young, close to the same time! though I think it grew popular faster than haskell did

<davexunit>guile of course has been around longer

<paroneayea>haskell took nearly 20 years to grow an audience

<davexunit>guile is just a late bloomer :)

<mark_weaver>guile-json should use association lists instead of hash tables

<davexunit>mark_weaver: yup

<paroneayea>I think guile is well positioned for it too

<paroneayea>#guile is a great community, honestly the friendliest language community I've been in

<davexunit>we discussed that awhile ago, and you suggested I write a brand new library that does that.

<mark_weaver>this is an example of the problem with names, if they can be grabbed by the first comer.

<ArneBab>I’d like to try my hand at a new-user tutorial: starting from “get the tarball”. Thanks to py2guile I have all the tooling at hand to get writing at once.

<paroneayea>there's exciting stuff you can see happening between sly, guilemacs, guix, and some other things

<davexunit>mark_weaver: I think maybe such a module could be part of guile core, like the SXML stuff is

<paroneayea>and the language is now actually really awesome from an insfrastructure standpoint thanks to the compiler tower stuff being pretty neat and seemingly easy to explore

<mark_weaver>you can either have module names that are very carefully assigned to well-designed APIs that have been tested in the real world

<paroneayea>I say, not having explored it (but I have read nala's article!)

*taylanub sees enormous potential in Guix and Guile-Emacs re. making Guile popular

<ArneBab>mark_weaver: Python solves that by introducing new packages: urllib, urllib2

<paroneayea>and the docs

<mark_weaver>or you can have numbers that are assigned freely without so much care

<paroneayea>taylanub: me too

<ArneBab>mark_weaver: or you can have both: start with numbers and once it’s proven itself assign a name

<mark_weaver>or I suppose you can have names that are prefixed by the author of the module or something

<paroneayea>it's also worth noting

<mark_weaver>ArneBab: sure, it's not unreasonable

<ArneBab>which problems are those which guile is best suited to solve?

<mark_weaver>I have to go afk for while

<paroneayea>eventually python libraries *outside* of python have become sometimes more popular than those in (eg requests is more popular than urllib(2) now)

<paroneayea>but

<davexunit>mark_weaver: would you be supportive of a (sjson) module that made it's way to guile-devel?

<davexunit>oh, bye mark_weaver

<paroneayea>that took a long time for pypi setuptools and etc to mature

<ArneBab>bye mark_weaver

<paroneayea>in 2005 django was proudly advertising that it didn't require anything but the stdlib

<paroneayea>bye mark_weaver

<paroneayea>thanks as always :)

<paroneayea>but now the django devs want to break their stuff into smaller packages and depend on more stuff

<paroneayea>something similar would have to happen with guildhall, and more packaging into distros

<paroneayea>for guile

<ArneBab>that’s ease of installation (get into a market) as opposed to easy of reuse (get more people to use your proven stuff)

*paroneayea is secretly procrastinating on doing the contracting he needs to do today by talking excitedly in here about guile's future!

<ArneBab>☺

<paroneayea>I should get on that now.

<paroneayea>but I will follow up on this stuff

<paroneayea>and write that blogpost

<paroneayea>hey everyone who participated in this: thanks for doing so

*ArneBab does the same - has to create a presentation which has to be held on tuesday next week - and from tomorrow till tuesday I’ll be AFK

<davexunit>it's been fun!

<ArneBab>paroneayea: thanks to you, too!

<paroneayea>I think we have a bad reputation (sometimes deserved, sometimes not) in gnu where sometimes people think we're resistant to change, and it's good to prove guile reacting in the opposite way in #guile

<paroneayea>and makes me optimistic for the future!

<bipt>sometimes you can teach an old wildebeest new tricks

<davexunit>hehe

<ArneBab>I’ve been wanting for years to test the documentation writing guide from steve losh for a real project which already has the work-intensive parts in place (i.e. the api reference)

<ArneBab>☺

<davexunit>I guess this is a good time to ask: good technical writing resources?

<davexunit>civodul just quit, but he is quite good at technical writing

<davexunit>I find mine to be lacking

<taylanub>I seem to remember ArneBab having a link for tips on good documentation

<ArneBab>davexunit: this is the best I know for that: http://stevelosh.com/blog/2013/09/teach-dont-tell/

<wingo>mark_weaver: to be fair many things like (ice-9 streams) are just legacy garbage from the 90s :)

<wingo>if we try again we're sure to do a better job

*wingo quite a bit back in the backlog, but if i get down to the end without typing i'll forget what i had to say

<wingo>so apologies in advance for saying things that were prolly addressed :P

<ArneBab>wingo: which will be good for 10 years and become legacy garbage in 2030 - but the alternative to doing stuff which will be superceded by something better is doing nothing (and thereby stopping people from learning and creating something better) ☺

*wingo also mentions "zooko's triangle"

<wingo>i.e. names can be two of unique, memorable, decentralized

<wingo>though the srfi process manages to only pick one :)

<davexunit>hahaha

<wingo>also i hear srfi is dead

<davexunit>it needs a maintainer

<ArneBab>it just got 5 new draft SRFIs

<wingo>interesting

<taylanub>the host, or the process manager or so?

<davexunit>ArneBab: thanks for that

<wingo>ok gtg

<wingo>see yall laters

<ArneBab>wingo: cu

<davexunit>I took a technical writing class in college, but the lessons learned haven't stayed in my brain.

<paroneayea>I don't think tutorials need "technical writing" training

<paroneayea>reference manuals, maybe

<paroneayea>but some of the best tutorials are engaging in that they mix technical information with a casual style

<ArneBab>I didn’t: I just got writing, and kept writing. (one of mine is the Mercurial guide: http://mercurial.selenic.com/guide )

<ArneBab>paroneayea: yes - the better I get at writing, the more I’m in awe of the people who are really good at it

<paroneayea>and actually trying to take a technical writing approach can make this boring

<paroneayea>it can get sterile

<paroneayea>I'm not going to see where but I've seen this in conflict in a project I've been in before

<paroneayea>and I learn, for tutorials, in the friendly engaging style.

<paroneayea>the whole point of the thing is to get people excited and feel like they're enjoying picking things up

<paroneayea>and not feel scared!

<paroneayea>a good tutorial should try to ease things so as to not trigger "imposter syndrome overflow"

<ArneBab>and it needs to be solid enough that core developers feel confident in referencing it.

<davexunit>ideally, this tutorial would be on the guile website

<davexunit>so it would be official

<davexunit>resolving whatever issues the maintainers have with it

<ArneBab>yes

<b4283>ArneBab: great to know there's py2guile that you mentioned it

<ArneBab>b4283: I finished polishing the first 50 pages (pending review), but I still have ~40 to go to get it into a shape where I am happy with it.

<ArneBab>b4283: this is the second draft: http://draketo.de/proj/py2guile/py2guile-v02.pdf (from a month ago, so without the polishing)

<ArneBab>b4283: I plan to also sell it (partly to test whether that works) - i.e. here: https://www.btcdlc.com/shop/drak/py2guile

<ArneBab>and I have a full autotools toolchain in place for generating the “object files”

<ArneBab>→ https://bitbucket.org/ArneBab/py2guile/src/6556328e06cf286122288ce0e963242e837a8206/Makefile.am

<ArneBab>from emacs org-mode to PDF+epub+mobi+source_tarball

IRC channel logs

2015-04-01.log