Re: Write a macro which defines a procedure

[Arne Babenhauserheide]

zelphirkaltstahl  writes:

> Hi Guile Users,
>
> I want to write a macro, which creates a procedure of given name,
> where the given name is a not yet defined identifier.
> Here is what I have so far:
… 

> Anyway, can you help me out writing the macro, fixing at least the 2
> issues or direct me to a tutorial, which covers how to write a macro
> which gives basically a new define form?

I can’t debug your form right now, but I can give you an example where I
created macros to write macros:

https://bitbucket.org/ArneBab/wisp/src/5e860c746ee02c764bf378aeb8f436a1a341bd5c/examples/enter-three-witches.scm#lines-209

The Enter-Macro defines a macro which outputs its arguments as text.

It took me some time to get it right, but it works pretty well.

Bits and pieces:
- check for the presence of a macro-binding:
(syntax-case x ()
   ((_ (name more ...) b ...)
 ; new binding: only create it if the binding is not already a macro
 (not (eq? 'macro (syntax-local-binding (syntax name
 
- stay on the same level:
  #'(begin …

(this is originally written in wisp and then transformed to scheme for
easier sharing with other schemers:
https://bitbucket.org/ArneBab/wisp/src/5e860c746ee02c764bf378aeb8f436a1a341bd5c/examples/enter-three-witches.w#lines-209
 )

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Mes 0.20 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> a GNU/Linux system without binary GNU toolchain or equivalent).  It
> should land in Guix master any day now: a big thank you to everyone who
> helped, notably Ludovic and Mark.

That’s awesome!

> This release is a step towards the upcoming Scheme-only bootstrap and
> bringing Mes into NixOS and Debian.  This effort is now sponsored by
> NLnet[12].

Big congrats for that!

>  *** The build system has been simplified, again.
>  Mes now builds ootb on Debian.

That feels way more significant than I thought it would — thank you!

And happy hacking for the next targets!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Maintainership changes: many thanks to Mark!

[Arne Babenhauserheide]

Vladimir Zhbanov  writes:

> On Wed, Sep 11, 2019 at 09:56:53AM +0200, Andy Wingo wrote:
>> On behalf of myself and Ludovic and no doubt all Guile users and
>> developers: a heartfelt thanks, Mark, for all of your years of
>> service, and see you around the Guile community!
>
> Thank you very much, Mark, Andy, and Ludovic for your great
> work and support, and very best wishes!

Yes, you are awesome! Thank you, and a special thank you for Mark! I
still remember fondly how you helped me get my string replacement fast
enough for wisp. Without your help my start into Scheme would have been
much harder.

all the best, and good luck for your future endeavors!
- Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Arne Babenhauserheide]

John Cowan  writes:

> On Sun, Oct 20, 2019 at 2:11 AM Todor Kondić  wrote:
>
>> But, I doubt any of them would find it natural to take a step further and
>> participate in GNU itself (ugh, now I sound like a preacher of a new age
>> religion). To my knowledge, interaction within GNU communities is still
>> mostly mailing lists and IRC. This _not_ my students' natural digital
>> habitat.

> The only natural digital habitat of human beings is their fingers.  All
> else is learned, and more can be learned at any time.  There's no reason
> why students ought to be so closed to new experiences.

That’s true, but even though I prefer IRC to new protocols, there is
much it lacks. For example showing images inline.

That‘s a client-problem, but it’s real.

Basically this sais that we’re the ones who are closed (often for good
reason, but those reasons need to be explained).

Best wishes,
Arne


signature.asc
Description: PGP signature

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Arne Babenhauserheide]

Zelphir Kaltstahl  writes:
> To verify another person's device, one has to exchange information via a
> second trusted channel. That information is a sequence of icons being
> shown. If they are the same, that the other person sends you via the
> second trusted channel, you can reasonably assume, that the device you
> are communicating with is under their control.
>
> When it comes to the step of exchanging information about what icons are
> displayed, most people will close the app and say "it's too
> complicated", because they do not understand it ("Huh? How strange! Why
> I have to do that? Are icons secure?") or do not want to do anything in
> order to have security. They are not willing to invest as much as 5min

In Freenet we have the same problem. We once had someone start an app
that used tapping phones together to exchange references, but it did not
get developed further.

It nowadays lives under my account, but I don’t have the time to work on
it (or rather: other things have higher priority for me).

https://github.com/ArneBab/Icicle

Maybe someone can find a tool there to ease initial setup.

Also TOFU is something we desperately need more of. For example I
recently had two unrelated people writing to me by email and our
communication was encrypted automatically because they used enigmail
with autocrypt and pretty-easy-privacy.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: TensorFlow bindings to Guile?

[Arne Babenhauserheide]

Hi Jan,

Jan Wedekind  writes:
> Hi Basile,
> I have implemented Tensorflow bindings for Guile: 
> http://wedesoft.github.io/aiscm/
> Let me know if you have any problems installing it.

Is aiscm already at a stage where I could experiment with using it for
handwriting recognition even though I don’t have prior experience with
setting up machine learning pipelines?

Does it work with a simple intel GPU or on CPU?

There’s a project I’ve wanted to start for quite some time now.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: TensorFlow bindings to Guile?

[Arne Babenhauserheide]

Hi Jan,


Jan Wedekind  writes:
> On Wed, 23 Oct 2019, Arne Babenhauserheide wrote:
>> Is aiscm already at a stage where I could experiment with using it for
>> handwriting recognition even though I don’t have prior experience with
>> setting up machine learning pipelines?
>   I have only tested the Tensorflow C bindings with a CPU. However
> there is also a GPU version of the library available [1].
>   I put an MNIST (handwritten digit recognition) example on the
> website [1]. I am not sure how to do general handwriting recognition.

That sounds great! Maybe I can use it to create a first prototype.
Though I’m slightly afraid of having to write 20k examples of steno
words :-)

>   The Tensorflow C bindings lack some higher level stuff which is
> implemented in Python (e.g. dropout regularization, saving
> checkpoints).

Is there any chance of getting a guix.scm file for the dependencies?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: guile-json, SRIFs and licenses

[Arne Babenhauserheide]

John Cowan  writes:

> On Wed, Nov 6, 2019 at 9:56 AM Zelphir Kaltstahl 
> wrote:
>> I think in this case, it might be a good idea to make sure, that
>> guile-json runs on all Schemes implementing a standard level and keep it
>> free software, to avoid the problem of people grabbing it and making it
>> proprietary software.

I’d like to give my own reason for accepting the MIT for wisp. My reason
is simply that SRFIs are supposed to be a standard.

Scheme SRFIs are a distributed effort to create a better programming
experience for those who use Scheme. There is a lot of choice, and if
all Schemes go off into different directions, you as developer lose
mobility between Schemes, and this often benefits the proprietary
systems that can pay more people to work on the shiny you need.

Therefore it is a viable decision to give an implementation away —
though not the only one.

> Lots of people who are quite committed to free and open source software
> don't actually think that's a problem.  There are two traditional arguments
> in favor of putting libraries under the GPL:
>
> 1) "Block embrace, extend, and extinguish":  the proprietary version gets
> all the new and sexy features while the original FLOSS version languishes.
> I don't think this is much of a problem for an implementation controlled by
> a stable specification like a SRFI: new features will be non-conforming
> features.
>
> 2) "Benefit GPLed programs":  if a library is GPLed, it supposedly gives
> the advantages of using that library only to GPLed applications.  That was
> the explicit reason for making readline a GPL library, and it did make
> CLISP GPL-licensed; similarly with the Objective-C front end to gcc.   I
> think history shows that this doesn't work very well in the long run:
> rather than accepting the GPL, a lot of duplicative effort was put into
> libedit/editline, which provides the same user-visible functions (but no
> longer has a readline-compatible interface).

You could also say that the GPL-licensing of readline is a huge success
story because it provided an edge to Free Software over proprietary
software for decades.

GCC did not mainly lose its edge for technical reasons, but because
Apple poured money into LLVM to have a compiler they can proprietarize.

> One of the purposes of FLOSS is to try to *prevent* duplicated effort.

I disagree with that point. The purpose of FLOSS is to have the option
to avoid proprietary software.

To that end every bit of additional effort required to create comparable
proprietary software is a good thing.

However for the SRFI this would also mean that running free software
which uses the SRFI on another Scheme implementation would require
additional work, so the edge to Free Software would be far smaller and
the cost might outweight the benefits. Might.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

State of lilypond with Guile 2?

[Arne Babenhauserheide]

Hi,

I had the recollection that lilypond nowadays can work with Guile 2, but
when I checked right now in the docs, I saw them saying "Version 2.x of
Guile is not currently supported"
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=Documentation/included/compile.itexi;h=0abd68a9177912138f01055504f20721e4a507de;hb=HEAD#l85

Do you know the state of using lilypond with modern Guile?

Does the lilypond in Guix use Guile 2?

Does lilypond on Windows use Guile 2?

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: guile-json, SRIFs and licenses

[Arne Babenhauserheide]

John Cowan  writes:

>> Whether or not a GPLed JSON library requires the Scheme implementation
>> > to be itself GPL depends on the implementation, but certainly a
>> > stand-alone *application* that uses it would have to be.
>>
>> Again, you are mistaken.  Check your facts, please.  See
>> .
…
> Thus if the JSON library is combined into the Scheme implementation as part
> of it, and that implementation is released, it must be released under the
> GPL.  If a stand-alone application (as opposed to a mere script that
> invokes the implementation) written in Scheme makes use of a GPLed library,
> it too (if publicly distributed) must be GPLed.  That's what I said

The precise statment would be: If you use a GPL’ed library, you must
license your own code under a GPL-compatible license and release the
application as a whole under the GPL.

I’m often in that bind at work myself. If I’d just like to use a lib,
but it’s GPL licensed. I hope that some day our product management/sales
will release under free licenses.

> As for clang, Apple funded it for commercial reasons, but there were
> efforts among BSD developers to write their own C compiler for years before
> that, though they came to nothing.

There is lots of history for GPL-criticism by BSD developers. I don’t
agree with their reasoning.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: State of lilypond with Guile 2?

[Arne Babenhauserheide]

Hi Thomas,

Thank you for your answer and for continuing to check Guile 2!

Thomas Morley  writes:

>> I had the recollection that lilypond nowadays can work with Guile 2, but
>> when I checked right now in the docs, I saw them saying "Version 2.x of
>> Guile is not currently supported"
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=Documentation/included/compile.itexi;h=0abd68a9177912138f01055504f20721e4a507de;hb=HEAD#l85
>>
>> Do you know the state of using lilypond with modern Guile?
>
> Due to the lack of manpower we don't get close to release any LilyPond
> supporting guile-2.x.
> Thus the known problems persist.
> All low hanging fruits are done, though and speaking only for me: I
> can't go deeper, it's beyond my depth.
> Remember, I'm not even a programmer, but a musician, maybe an
> ambitious musician ;)
>
> Additionally I recently found something preventing our `make
> test-baseline´ to work.
> Probablly identified here:
> https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00236.html
> (unsolved)
>
> Following the link you'll find a .zip containing several patches.
> Applying them you'll get a successful
> `make´ and `make doc` for every guile up to guile-2.9.4, but  as said
> `make test-baseline´ fails.

That actually looks pretty promising. Thank you for tackling it!

So with your patches Lilypond works with Guile 2.0.14. Is there a chance
that you could get them into a new guile-v2-work-rev2 branch or such?

And maybe post the commands you use to build and test it?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: babelia

[Arne Babenhauserheide]

Hi Amirouche,

For the firefox driver you might get a good start from skewer-mode:
https://github.com/skeeto/skewer-mode

Best wishes,
Arne

> Related blog post: https://hyper.dev/blog/on-the-road-to-babelia.html


--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: State of lilypond with Guile 2?

[Arne Babenhauserheide]

Ricardo Wurmus  writes:

> Arne Babenhauserheide  writes:
>
>> Does the lilypond in Guix use Guile 2?
>
> No.

It would be great if we could change that once it works with Guile 2.9
again, because that will be the testbed closest to Guile development.

That would be a way to reduce the probability that changes in Guile
break lilypond.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Mes 0.21 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> We are pleased to announce the release of GNU Mes 0.21, representing
> 54 commits over 10 weeks.
>
> Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> a GNU/Linux system without binary GNU toolchain or equivalent).  See
> https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
>
> This release supports a Scheme-only bootstrap: Mes can now be built with
> Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU
> Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and
> GNU Tar.  Also, the Mes C Library now supports bootstrapping those.
> Finally, this release brings Mes as a package to Debian GNU/Linux.

That’s two small paragraphs of humble text with a bang that’s hard to
overstate. Thank you very much!

> We are excited that the Nlnet Foundation[12] is now sponsoring this
> work!

I’m very, very happy that this worked out!

>  - the Hurd

What’s needed for the Hurd in addition to Linux?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Nyacc and guile-nearly-3.0 (progress report)

[Arne Babenhauserheide]

to...@tuxteam.de writes:

> On Mon, Dec 02, 2019 at 06:28:53AM -0800, Matt Wette wrote:
>> Look at etc/README.  Maybe edit etc/configure.ac and rerun as in the README.
>> 
>> I'm building 2.9.5 now but running into errors (ubuntu 18.04):
>> /bin/bash: line 6: 14657 Segmentation fault  (core dumped)
>
> Ouch. A segmentation fault in bash :-o

Do you know when your bash was compiled? I started getting such errors
with externally compiled binaries about two months ago and have been
unable to resolve that so far.

(i.e. the Firefox compiled for Ubuntu does not work anymore)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Announcing the first actually stable release of guile-for-loops

[Arne Babenhauserheide]

Hi,

Linus Björnstam  writes:
> The syntax is more or less the same as racket's loops, and they are generally 
> compatible. The code generated is for almost all cases as fast as hand-rolled 
> code. They are all expressed as left or right folds, and are as such (apart 
> from for/list, but read about that in the documentation) free of mutation. 
> They are all converted to named lets.

That’s cool!

> (define (erathostenes n)
>   (define vec (make-vector n #t))
>   (for/list ([i (in-range 2 n)] #:when (vector-ref vec i))
> (for ([j (in-range/incr (* 2 i) n i)])
>   (vector-set! vec j #f))
> i))
>
> The code and documentation is available here:
> https://hg.sr.ht/~bjoli/guile-for-loops

Is there a chance that this could get included in Guile (ice-9
for-loops?) and become a SRFI?

If the code is non-portable (I guess the #:keywords are), the two
existing implementations (Racket, Guile) would still be sufficient for a
SRFI.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Logo proposal

[Arne Babenhauserheide]

Marc Chantreux  writes:
> * it would be cool to have λ as an alias to lambda in guile so
>   we could be able to write
>
> (λ (x) (* x x))

Did you try it?
(spoiler: that’s what I’ve been using for years :-) )

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

potluck; Re: Happy birthday, Guile!

[Arne Babenhauserheide]

Happy Birthday Guile!

Here’s a small contribution to the potluck:

define : first-encounter
Enter : Juli Fin
Melter Lark
Rooted Breeze

game-state-set!
. game-state-initial

Juli Fin
Finally we have our own home!

Melter Lark
I will dry it out.

Rooted Breeze :eerie
My slumber breaks
my mind awakes
who are you strangers
in my home?

Choose
: explain
  ,(explain-your-home)
: fast-talk
  ,(fast-talk-the-dryad)



Enter three witches is progressing from a text-based dialog system to a
game engine which also considers reuse of scenes and game-state.

This is a shortened version I wrote in replay to an email where someone
said that py2guile is a great article about Python :-)
See the full version at https://hg.sr.ht/~arnebab/dryads-wake/

Best wishes,
Arne


Ludovic Courtès  writes:

> Hello Guilers!
>
> Today, it’s been 9 years since Guile 2.0 came out!
>
>   https://lists.gnu.org/archive/html/guile-devel/2011-02/msg00173.html
>
> It’s impressive how much has been accomplished since 2.0, and how what
> seemed like a pipe dream back then came into reality with 3.0.  I think
> Guile 2.0 started a renaissance of Guile, and it’s in bloom now.  :-)
>
> We used to have a “Guile potluck” for the anniversary, where people
> would bring their own hacks and virtually join for a party.  We missed
> it this year, but if there’s a nice hack that you’d like to share, now
> is a good time!
>
> Happy hacking with Guile!
>
> Ludo’.


--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Geiser vs. guile-mode?

[Arne Babenhauserheide]

Jose A. Ortega Ruiz  writes:
> we don't continuously evaluate
> what you write in a buffer.  writing something by mistake in use-modules
> would then pollute the whole namespace, invisibly if one later removes
> the use-modules subclause.  maybe that flymake/flycheck function will do
> that for you? (to be honest, it's not something i find natural, so i'd
> add it to geiser only if someone else contributes it and it's an
> opt-in).

Would it be possible to recognize when something is removed from
use-modules and to re-evaluate the whole file in a fresh REPL then?

Basically what I want is the quality of configuration-free
auto-completion I get in IntelliJ for Java. And I know that that’s a
very high bar. Avoiding the need for extra-actions is also important for
new users, because it reduces the amount of extra-actions needed to
start working efficiently.

Would it be possible to re-evaluate on save?
(defun re-evaluate-buffer () …)
(add-hook 'after-save-hook 're-evaluate-buffer)

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Guile Studio's goals (and home)

[Arne Babenhauserheide]

Eli Zaretskii  writes:
> A "problem" doesn't necessarily have to be a bug or a deficiency, it
> could also be a missing feature.  In this case, a missing feature
> could perhaps be described as a lack of guile-ide.el package in Emacs,
> which users of the Guile Studio could simply load, and magically have
> their confusion taken care of.

There is a problem I see: I cannot easily share configurations that can
be loaded with use-package. The main reason for that is that melpa
rejects meta-packages which only setup other packages and adjust some
configuration values.

Another aspect is that "use Emacs for X" is a major selling point of
many publicly shared configurations. If you look outside the box and
check IntelliJ, you’ll see that JetBrains sells several customizations
for specific usecases, so this is not unique to Emacs.

TLDR: It would be nice if Emacs could at startup offer users to select a
customization for a specific use-case.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Guile Studio's goals (and home)

[Arne Babenhauserheide]

Eli Zaretskii  writes:

>> From: Arne Babenhauserheide 
>> Date: Sat, 29 Feb 2020 22:15:05 +0100
>> 
>> TLDR: It would be nice if Emacs could at startup offer users to select a
>> customization for a specific use-case.
>
> Please report this using "M-x report-emacs-bug", so that an issue is
> open with the Emacs issue tracker.

done :-)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: guile-gi: In procedure dynamic-link: file: "libguile-gi", message: "file not found"

[Arne Babenhauserheide]

Mike Gran  writes:
> I had wanted to wait until I scrubbed the docs to push a new release,
> but, I could push one out pretty quickly to pick up those bug fixes.

That would be great! I also got stuck on this …

> If you want a workaround in the meantime, try setting the
> GUILE_SYSTEM_EXTENSIONS_PATH environment variable to the directory
> into which libguile-gi.so was installed.

Works! Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Python on guile

[Arne Babenhauserheide]

Stefan Israelsson Tampe  writes:

> Now in corona times I'm working quite a lot with python-on-guile fixing
> bugs in the parser and compiler. Trying to add and test more python
> modules. My test case is to get IPython running on python on guile.

You’re awesome! Thank you!

It sounds like the time could be coming to actually test the speed.
Maybe you can look into the pypy benchmarks for that:

https://speed.python.org/
https://speed.python.org/about/ — with link to the code

Those would give the first truly comparable test of the speed of Guile
vs. a non-Scheme — and a practical path into improving performance based
on higher level usage patterns.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: syntax taste: use of unquote in macros

[Arne Babenhauserheide]

Matt Wette  writes:

> Hi All,
>
> I'm not sure if you know about this, but there is a discrepancy in the
> way some folks define macros to use unquote (aka ,).   For example,
>
>> (use-modules (system base pmatch))
>> (pmatch '(foo "bar")  ((foo ,val)  (write val) (newline)))
> => "bar"
>
>> (use-modules (ice-9 match))
>> (match '(foo "bar")  (`(foo ,val)  (write val) (newline)))
> => "bar"
>
> Note the difference in the use of quasiquote (aka `) in the pattern
> for (foo ,val): match syntax uses it, pmatch does not.
> In Scheme, quasiquote and unquote always come together.
>
> Is pmatch syntax in bad taste?  I'm looking for opinions.

I did not know about pmatch, but it gives me the feeling that this is a
pattern that will appear again for other embedded domain specific
languages.

I had a usecase for that in dryads-wake¹ for embedding instructions in
otherwise declarative code. It looks like this:

(Enter (Speaker))
(Speaker
(My Text, line 1)
(Second line)
(very ,(color 'red) important ,(color #f) line))

At this point the difference to quasiquote doesn’t look big. It gets
much bigger when this code is used from wisp:²

Enter : Speaker
Speaker
My Text, line 1
Second line
very ,(color 'red) important ,(color #f) line

With written quasiquote there would either be line-noise on every line
or this would have structure-noise because it would have to be wrapped
in a list instead of working like arguments to a procedure call:

(Enter (Speaker))
(Speaker
  `((My Text, line 1)
(Second line)
(very ,(color 'red) important ,(color #f) line)))

or

(Enter (Speaker))
(Speaker
`(My Text, line 1)
`(Second line)
`(very ,(color 'red) important ,(color #f) line))

Best wishes,
Arne

¹: https://hg.sr.ht/~arnebab/dryads-wake/browse/default/dryads-wake.w#L231
²: https://www.draketo.de/english/wisp
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: How best to produce a standalone executable with Guile?

[Arne Babenhauserheide]

Hi James,

James Cooper  writes:
> Am I correct in understanding that guild essentially is what the Guile
> runtime will use to compile my source files before executing them?

Not quite. Guile does create bytecode, and guild can create it, but this
also happens during normal execution.

For some tasty details see https://wingolog.org/archives/2014/01/19/elf-in-guile

> traditional executable is that I'm planning to run comparative benchmarking
> directly on equivalent versions of the same program in different languages,
> and I *think *that will work a lot better if I can specify an executable

This sounds pretty interesting. Before you run this, though, please get
the help of experienced Guile programmers. I have an example of a
string-handling procedure which got more than 160x faster thanks to help
from others here. No typo there: It really got more than
hundred-and-sixty-times faster.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: guile-sdl2 0.5.0 released

[Arne Babenhauserheide]

Thompson, David  writes:
> I am happy to announce the release of guile-sdl2 0.5.0!
>
> There are a handful of new bindings and some improvements to the build system.
>
> Full release notes and download links can be found here:
> https://dthompson.us/guile-sdl2-050-released.html

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: chickadee 0.5.0 released

[Arne Babenhauserheide]

Hi Dave,

Thompson, David  writes:
> I just released chickadee 0.5.0. Chickadee is a general-purpose game
> programming library for Guile.

That’s great timing! Just yesterday I had its page open thinking about
whether I could use this for quick visiualizations.

Thank you!

> Release notes, download links, and more project information can be
> found in the full release announcement:
> https://dthompson.us/chickadee-050-released.html
>
> The covid-19 lockdown here in the US has given me a bit of extra time
> to make this release and yesterday's guile-sdl2 release ahead of the
> spring Lisp game jam happening over on itch.io.  I don't know if I
> will submit a game jam entry, but if I do I will share it here.  If
> you're interested in the jam, you can participate here:
> https://itch.io/jam/spring-lisp-game-jam-2020

That sounds interesting. I might actually be able to take part this
year. At least with something small.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: [ANN] Guile Hall 0.3.0 released

[Arne Babenhauserheide]

Catonano  writes:

> Overall, I'd say this:
>
> There is level 0 of Guile packaging: that's NO packaging. You keep your
> files scattered around and they will be autocompiled
>
> You put your files in a git repo on line, your friends will check them out
> and autocompile them too
>
> Then there's level 1: when things get a bit more structured, for example
> your package may depend on some other Guile library or on a specific
> version of Guile

I’d say that level 1 is when you want you code to be (a) tools that are
pre-compiled and installed systemwide, or (b) libraries that are
available for other Guile code.

That’s when you need autotools.

Then level 2 is when you need other tools. At that point you need some
package management.

> In that case, you need to setup the autotools in your project
>
> Distros such as Ubuntu and Fedora will be able to distribute your package
> and your friends on Gentoo will be able to deal with them by hand
>
> In the future, there could be a level 2. That is: no m4 anymore !! As fas
> as I undertsand the Autoconf based machinery relies on bash to execute
> tests (is such library available ? Is Guile version >= 2.7 ?)

Autoconf is intended to be bootstrappable with minimal dependencies.
It needs some shell. At some point gash might be a suitable option.

m4 is just a very simple templating language. Should not be too hard to
implement it in Guile.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: [ANN] Guile Hall 0.3.0 released

[Arne Babenhauserheide]

Alex Sassmannshausen  writes:
>> m4 is just a very simple templating language. Should not be too hard
>> to implement it in Guile.
>
> Again, this has come up in the past.  I love the idea of having a Guile
> way to do the work that m4, autoreconf and automake do — I think any
> piecemeal or module work towards this would super valuable.
>
> I hope for now, in the absence of those things existing, having Hall
> provide a kludgy bridge between autotools and Guile might be the best of
> both worlds…

I have yet to use it (I’m still doing the autotools setup by hand; but
that’s mostly because my Guile tools are mostly wisp so I need custom
stuff), but yes: having autotools autogenerated is extremely valuable.

If you have automated autotools setup - something that just works - it’s
like all those project-setup tools other languages have (Java with
Maven, Javascript with npm, Rust with cargo, Go …), but with the
difference that it works everywhere.

I have used several different build tools in the past, and once you
stray even slightly outside the usual path, autotools (with all its
cludginess) still outdoes them all.

Sidenote: Does guile hall setup help for Make?

→ 
https://hg.sr.ht/~arnebab/conf/browse/Makefile.am?rev=314983dd7beb661ac931aa33a4937bd7cccd30c1#L26
(shows rule lines with ## comments as help output for commands)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: C programs in Scheme syntax

[Arne Babenhauserheide]

Also have a look at https://github.com/sph-mn/sph-sc

Examples:

;; declaration
(declare
  a uint32_t
  b (array uint8_t 3)
  c (struct (id int) (name char*))
  d (enum (x y z))
  e (type uint16_t)
  f (type (struct (id int) (name char*

;; define with value
(define a uint32_t 1)

;; macros
(pre-define
  is-included #t
  id-size 4
  (mymacro a b) (set a 1 b 2))

;; functions
(define (myfunction a b) (int char void)
  "a description of this function"
  (return 1))


I found it when the author did the full round-trip over wisp via
c-indent: http://sph.mn/computer/guides/c/c-indent.html
This then looks much more similar to C; but fully regular:


pre-include "stdio.h"

define (main argc argv) : int int char**
  declare i int
  printf "the number of program arguments passed is %d\n" argc
  for : (set i 0) (< i argc) (set+ i 1)
printf "argument %d is %s\n" (+ i 1) (array-get argv i)
  return 0


Best wishes,
Arne

John Cowan  writes:

> Check out the Chibi library (chibi show c). in the Chibi repo at
> lib/chibi/show/c.scm and .sld.  It provides combinators that create a C
> equivalent of the sexp; there is both a macro-based compiler and an
> interpreter, IIRC.  Unfortunately there is no real documentation.  There's
> some cleverness in it: c-if in statement context expands to an
> if-statement, but in an expression context to a ?: operator.  If you import
> (chibi show) and (chibi show c) then (show #t (c-if 'foo 'bar 'baz)) will
> generate a statement, but (show #t (c+ 2 (c-if 'foo 'bar 'baz))) will
> generate an expression.
>
>
> On Thu, May 28, 2020 at 11:38 PM Keith Wright  wrote:
>
>> I am thinkging about a project that uses Scheme macros
>> to generate C code.  To this end I want to encode C
>> programs as S-expressions.  For example, the C program
>> that is encoded in Ascii as
>>
>> for (j=0;j<12;++j) a[j] = j*pi/6;
>>
>> might be encoded as an S-expression as
>>
>> (for ((= j 0)(< j 12) (++ j)) (= (sub a j)(/ (* j pi) 6)))
>>
>> Note that this is not a valid Scheme program, even with
>> non-standard functions defined.  It is a re-encoding
>> of the Ascii C syntax as an S-expression.
>>
>> I think I have read about something like this, perhaps
>> on this list, I am not sure.  (Note to future language
>> inventors: a single letter name makes a horrible Google
>> search query.  Name things with made up but pronouncable
>> words---perl, fortran...)
>>
>> I most need to convert S-expr encoded C, to Ascii encoded C,
>> but I am interested in
>> (a) programs to convert S-expresions to C
>> (b) specifications for the form of the S-expr encoding
>> (c) better plans; advice from those who have tried and failed.
>>
>> Any pointers?
>>
>>-- Keith
>>
>>
>>


-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Normal distribution random numbers

[Arne Babenhauserheide]

Hi Zelphir,

Zelphir Kaltstahl  writes:
> Then I thought: How would I get normal distributed random numbers? I
> don't have a project or program in mind for this, but it struck me, that
> I do not know, how to get a normal distribution from a uniform
> distribution. So I dug into the matter …
…
> So my question is: Is there a good implementation in the Guile universe
> already? (Or a simple way to implement it?) I don't really need it right
> now, but I think this thing could be an obstacle for many people without
> serious math knowledge and it would be good to know, where to find it,
> should one have need for normal distributed random numbers.

I don’t know how random:normal does it, just that I used it.

See https://www.gnu.org/software/guile/manual/html_node/Random.html

If you want to add defined covariance, you can use cholesky
decomposition: 
https://hg.sr.ht/~arnebab/wisp/browse/examples/cholesky.scm?rev=91ec8dc32652

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: guile-json 4.1.0 released

[Arne Babenhauserheide]

Aleix Conchillo Flaqué  writes:
> I'm happy to announce guile-json 4.1.0. This version improves number
> parsing performance by a 2x factor and cleans up and simplifies the builder
> code specially unicode related.

Cool! Thank you!

>  https://github.com/aconchillo/guile-json/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

status of the guile-js GSoC project?

[Arne Babenhauserheide]

Hi,

What is the state of the Javascript backend for Guile?

The early examples looked very promising (being able to use Guile as
unified tool for browser-applications), but I did not see new reports
lately.

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.

Re: Where are the guile libraries?

[Arne Babenhauserheide]

Am Freitag, 28. August 2015, 12:31:45 schrieb Ian Zimmerman:
> I'm asking if it exists, anywhere, at all, possibly in small pieces,
> but ready to be reused.

Disclaimer: The following is just my limited knowledge.

Some Batteries are in the Guildhall: https://github.com/ijp/guildhall

Some might be packaged in Guix: http://gnu.org/s/guix
(you can install and use Guix as simple user)

Others are the SRFIs: http://srfi.schemers.org/final-srfis.html

They aren’t directly visible, but you can get many of them with

(use-modules (srfi srfi-N)) ; with N the SRFI number.

And some more are mentioned on IRC (#guile @ irc.freenode.net)¹ and
summarily not documented. Many of these can be found on Github.

¹: https://webchat.freenode.net/?randomnick=1&channels=guile

Best wishes,
Arne
--
Ich hab' nichts zu verbergen – hab ich gedacht: 

- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen



signature.asc
Description: This is a digitally signed message part.

Re: Where are the guile libraries?

[Arne Babenhauserheide]

Am Freitag, 28. August 2015, 22:58:42 schrieb Ian Zimmerman:
> On 2015-08-29 00:15 +0200, Arne Babenhauserheide wrote:
> > Some Batteries are in the Guildhall: https://github.com/ijp/guildhall
> 
> I cloned it and built it.  However, I'm confused how it is supposed to
> work, because I have no "guild" exacutable, and none is built or
> installed by make, just guile modules.

guild is supplied by Guile, guildhall only adds commands to it.

Which version of Guile do you run? If it’s not 2.0.11, I would highly
recommend to update it.

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

Re: Using in C a function defined in guile

[Arne Babenhauserheide]

Hi Vadimir,

Am Sonntag, 6. September 2015, 17:10:01 schrieb Vladimir Zhbanov:
> After speaking with a man who doesn't like scheme and wants to make all
> his work in C, I wonder if there is an easy way to make the procedures
> wholly written in Guile available in C, besides any kind of 'eval'.
> Looking through the guile info I didn't found anything other.

The manual shows how to call Guile functions from your program:
http://www.gnu.org/software/guile/manual/guile.html#Guile-Initialization-Functions

The sample however embeds a full Guile shell:
http://www.gnu.org/software/guile/manual/guile.html#A-Sample-Guile-Main-Program

If I recall correctly, if you only want to provide the Scheme
functions, stick to scm_init_guile and scm_with_guile.

See Initializing Guile from the API reference:
http://www.gnu.org/software/guile/manual/guile.html#Initialization

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.

Re: Using in C a function defined in guile

[Arne Babenhauserheide]

Am Sonntag, 6. September 2015, 16:09:06 schrieb Mike Gran:
> The simplest way to implement such a thing is using
> functions like scm_c_eval_string, where one creates a string
> containing Guile code and executes it.
> …
> There is an example in the manual here
> http://www.gnu.org/software/guile/manual/html_node/Accessing-Modules-from-C.html

That’s much better than what I wrote. Please don’t let yourself get stuck on my 
mail.

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.

guildhall build-failure with guile master

[Arne Babenhauserheide]

Hi,

With guile master, I get build errors of guildhall.

To reproduce: Install guile in /usr/local/, then build guildhall:

git clone g...@github.com:ijp/guildhall.git
cd guildhall
./autogen.sh && ./configure && make

I get this backtrace:

./env /usr/local/bin/guile-tools compile -Wunbound-variable -Warity-mismatch 
-Wformat -o "guildhall/weinholt/struct/pack.go" 
"guildhall/weinholt/struct/pack.scm"
Backtrace:
In ice-9/boot-9.scm:
 857: 19 [with-throw-handler _ _ _]
In system/base/compile.scm:
  59: 18 [#]
 153: 17 [# #]
 222: 16 [read-and-compile _ #:from _ #:to _ #:env _ #:opts ...]
 253: 15 [compile _ #:from _ #:to _ #:env _ #:opts ...]
 181: 14 [compile-fold _ _ ...]
In language/cps/compile-bytecode.scm:
 478: 13 [compile-bytecode # # ...]
 471: 12 [lower-cps # (#:to-file? #t #:warnings ...)]
In language/cps/optimize.scm:
  86: 11 [optimize-higher-order-cps _ _]
In language/cps/dce.scm:
 357: 10 [eliminate-dead-code _]
 105: 9 [compute-live-code #]
In language/cps/intmap.scm:
 515: 8 [visit-branch #(#(# # # ...) #(# # # ...) #(# # # ...) ...) _ ...]
 515: 7 [visit-branch #(#(# # # ...) #(# # # ...) #(# # # ...) ...) _ ...]
 515: 6 [visit-branch #(# # # # ...) _ 544 ...]
In language/cps/type-checks.scm:
  47: 5 [elide-type-checks # _ _]
In language/cps/intmap.scm:
 515: 4 [visit-branch #((absent) (absent) (absent) ...) _ ...]
 515: 3 [visit-branch #(#(# #) #(# #) #(# #) #(# #) ...) _ 576 ...]
In language/cps/type-checks.scm:
  43: 2 [# 590 ...]
In language/cps/types.scm:
1129: 1 [# _ ...]
In ice-9/boot-9.scm:
 781: 0 [dispatch-exception _ _ _]

ice-9/boot-9.scm:781:26: In procedure #f:
ice-9/boot-9.scm:781:26: Wrong number of arguments to #
Makefile:1561: recipe for target 'guildhall/weinholt/struct/pack.go' failed
make: *** [guildhall/weinholt/struct/pack.go] Error 1


Do you know where this comes from -- and how to fix it?

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Guile project generator

[Arne Babenhauserheide]

Am Dienstag, 15. September 2015, 14:28:28 schrieb David Thompson:
> > Maybe we should consider to make it a GNU standard one, if so, we need
> > to add ChangeLog and NEWS. And BUGS/HACKING/THANKS could be optional.
> 
> Yes, those would also be good to include.

A template for the NEWS file would be good, so people know what to do
with it. Example (built on the NEWS file of Guile):

--
[The NEWS file lists user-facing changes for the releases, newest first]

Changes in 0.1 (since 0.0):

* Use standard project structure.

This makes it easy to build and test the project with anything which
supports GNU autotools and provides the basic information:
- NEWS (this file)
- README (description of your project)
- configure.ac (autoconf file with project name, current version and 
dependencies)
- ChangeLog (autogenerated)
- Makefile.am (automake file with build instructions)
- pre-inst-env.in (??)
- COPYING (the license)

--


To make it nice, we could include a generator for the ChangeLog
instead of the ChangeLog itself. For projects managed with git it
needs a bit of shell mangling, but for Mercurial it’s trivial:

ChangeLog:
hg log --style changelog > $@

Since many people will be using git, something conditional would be
better:

ChangeLog:
if test -d .hg; then hg log --style changelog > $@; elif test -d .git; 
then git log --no-merges --format='xxx%aI::%aN %n%n%B[%h]' | sed 
's/T..:..:.:..::/  /' | sed 's/^//' | sed 's/xxx//' > $@; fi

(or a more full featured script like this:
http://stackoverflow.com/a/16738477/7666 )

Best wishes,
Arne
--
Celebrate with ye beauty and gather yer friends for a Pirate Party!
→ http://1w6.org/english/flyerbook-rules#pirate-party ←



signature.asc
Description: This is a digitally signed message part.

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Sonntag, 27. September 2015, 21:00:46 schrieb Panicz Maciej Godek:
> You wrote there, among others, that "with a little more work, standard
> Scheme might actually become a language essentially as usable as Python and
> the like".
> 
> If you're looking for a language that is "as usable as Python", then I'd
> recommend trying out Python, which is very good at what it does.
> 
> Maybe I'm reading your point wrong, but I don't think that competing with
> Python or chasing Python or trying to mimic Python would be anything but a
> waste of time

Saying that it should be “as usable as Python” isn’t the same as
saying that it should chase Python or mimic Python. You can make
furniture from wood or steel, but if you only have off-the-shelf
chairs and tables of wood, no one is going to open a restaurant with a
kitchen made of steel. Or built a skyscraper, for that matter.

Making Scheme as usable as Python requires finding an elegance which
fits Scheme and allows creating applications at least as easily as
with Python — but not necessarily in the same style.

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Mittwoch, 30. September 2015, 01:02:50 schrieb Panicz Maciej Godek:
> 2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide :
> > I wrote SRFI-119, not because I want Scheme to become more like
> > Python, but because I want it to *look* more like Python while
> > retaining its strengths.

> If you asked me, I'd say that if people started using that SRFI (or the two
> others), then it would be most harmful to the Scheme community, because
> that would increase code enthropy and force programmer to make an
> irrelevant choice.

It’s no more irrelevant than the choice between Guile and Racket. And
different from that choice, it’s trivial to change:

for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done

> It also sacrifices some of the strengths of Scheme, actually, because it
> makes the code structure obscure.

I disagree on that. The structure is still just as easy to recognize
as with parens: Even with parens the strongest indicator of the
structure is the indentation. It keeps the effects of inline-colons
limited to one line to avoid the need to do any complex mental
parsing: If there’s a colon in a line, the paren it opens gets closed
at the end of the line.

> The same goal could better be achieved (non-intrusively) by making an easy
> to use editor that would allow to display your Scheme code in the way you
> prefer, be it Python-style indentation or some fancy LaTeX formatting.

I consider it as problematic when programming languages need strong
tool support to be easy to read. With the right tools, even Java is
nice to use.

Changing indentation sensitive code needs some tool support to be
elegant, but that is available in most editors, but reading does
not. And I’ve been stuck in too many github diffs to consider that as
a solved problem :)

> > It isn’t necessary to sacrifice the strengths of Scheme to become as
> > easy for new programmers as Python. However it does require accepting
> > that a large part of the utility of any language lies in its
> > libraries: The best language for any job is the one which provides the
> > solution off-the-shelf.
> 
> Fine. But I don't find it disturbing that this "useful language with tons
> of great libraries" is called Racket or Guile, rather than Scheme.

This week a Freenet user wrote a client to Freenet in Racket. I wanted
to use it for Guile, but since I didn’t really know the capacities of
Racket, I didn’t know how to replicate them in Guile. I asked the user
whether he/she could port to Guile and after a few days he/she
published a Guile version but stated that it did not work yet. One
hour of fixing later I had it running.

Why I write that: For large projects it might be relatively easy to do
the conversion, because the compatibility layers are only a small part
of the total code base. The saved time by reusing existing code is
much larger than the time spent doing the compatibility stuff. For
small projects, it can be a blocker. You can’t spend a few days
waiting and 1 hour porting for programs which just take 4 hours to
write. Or rather: You can’t do that if you need to combine many small
projects into a bigger whole.

> I will agree with you if you show me one example of successful deployment
> of Guile or Racket. Like, Python has some impressive tools like Django or
> Enaml.

Can you give me clear criteria for when you would consider a
deployment as successful?

> > But someone has to actually do that: Creating libraries with
> > consistent style which provide to the application developer what
> > Scheme already provides to the language developer.
> >
> 
> I agree. But from my experience, in order to make a useful library, it is
> best to work on some real applications.

I agree.

> I think it is actually reasonable to think that the power of a programming
> language manifests itself in the applications that are written in that
> language.

I agree, too.

So our viewpoints don’t seem to be that far away from each other :)

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Montag, 28. September 2015, 22:02:42 schrieb Panicz Maciej Godek:
> Even within the Scheme community there appear voices complaining on the
> Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119.

I wrote SRFI-119, not because I want Scheme to become more like
Python, but because I want it to *look* more like Python while
retaining its strengths.

It isn’t necessary to sacrifice the strengths of Scheme to become as
easy for new programmers as Python. However it does require accepting
that a large part of the utility of any language lies in its
libraries: The best language for any job is the one which provides the
solution off-the-shelf. SRFIs could give Scheme such solutions, and
the flexibility of Scheme would allow making these solutions much more
elegant than what can be created with Python.

But someone has to actually do that: Creating libraries with
consistent style which provide to the application developer what
Scheme already provides to the language developer.

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek:
> > > others), then it would be most harmful to the Scheme community, because
> > > that would increase code enthropy and force programmer to make an
> > > irrelevant choice.
> >
> > It’s no more irrelevant than the choice between Guile and Racket.
> 
> No. Guile and Racket are both experiments. I think it was a good move on
> Racket's side that they proclaimed that they are a separate programming
> language, because that way they manage to avoid bad community pressures
> like this.

Do you see wisp as community pressure on Scheme implementations?

> > And different from that choice, it’s trivial to change:
> >
> > for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done

> Converting strange syntax to Lisp is essentially what parsing does.

I’ll cheat a bit here and pull your later answer:

> This is the reason why emacs indents lisp code. This is the part of
> Norvig's comparison that I particularly like:
> 
> "One of Python's controversial features, using indentation level rather
> than begin/end or braces, was driven by this philosophy: since there are no
> braces, there are no style wars over where to put the braces.
> Interestingly, Lisp has exactly the same philosphy on this point: everyone
> uses emacs to indent their code, so they don't argue over the indentation.
> Take a Lisp program, indent it properly, and delete the opening parens at
> the start of lines and their matching close parens, and you end up with
> something that looks rather like a Python program."

If you do that, you essentially have wisp. Being as close as possible
to Scheme with just leaving out the parens you can infer from
indentation is the core design principle of wisp.

> Yet you loose a lot of support from your tools if you miss the assumptions
> that they were made upon.

That’s completely, totally true.

Guile itself provides almost its full support when you’re using wisp,
but the tool support is much weaker. The Emacs mode for wisp is much,
much weaker than Geiser and there are no syntax highlighters in any
code hosting service, and that doesn’t even start with external code
analysis tools.

But you can already do stuff like this:
http://draketo.de/english/wisp/shakespeare

> > > It also sacrifices some of the strengths of Scheme, actually, because it
> > > makes the code structure obscure.
> >
> > I disagree on that. The structure is still just as easy to recognize
> > as with parens:
> 
> It is easy for you, because you're inveted it. For everyone else it's just
> another thing they'd need to learn in order to read the code. They'd need
> to remember all the assumptions you've made.

Let’s do that by example:


define : hello world
  format #t "Hello ~A!\n" world

hello "World"


Recognizing the structure isn’t the problem. Tool support is a
problem. And integration. And documentation. And so on. It is unlikely
to be the best system for all kinds of hacking. But it might be a
pretty good system for some tasks. And when you program in wisp, going
to standard Scheme is really easy. You already know all the
functionality, the structures, the libraries and so on.

> > > The same goal could better be achieved (non-intrusively) by making an
> > easy
> > > to use editor that would allow to display your Scheme code in the way you
> > > prefer, be it Python-style indentation or some fancy LaTeX formatting.
> >
> > I consider it as problematic when programming languages need strong
> > tool support to be easy to read. With the right tools, even Java is
> > nice to use.
> 
> Raise your hands all those who don't use emacs to write their Lisp code.
> Raise your hands all those who don't use geiser to interact with Guile.
> 
> I honestly think that, however clever Lisp is, it would be rather painful
> to edit it without proper tools. Even the aforementioned 'wisp.scm' is a
> tool.

You’re talking about editing right now. I explicitly talked about
reading, not about editing.

> Regarding Java, I think its tools have the same problem the language has,
> i.e. everything is fine as long as you stick to the path that their
> developers chose for you.

Replace Java with Python, and that still fits. Python even has flake8
for Emacs which checks for you whether you are following the canonical
path. And people do that intentionally. I know I do.

But there’s a reason why I started into Scheme.

> > > Fine. But I don't find it disturbing that this "useful language with tons
> > > of great libraries" is called Racket or Guile, rather than Scheme.
> > …
> > small projects, it can be a blocker. You can’t spend a few days
> > waiting and 1 hour porting for programs which just take 4 hours to
> > write. Or rather: You can’t do that if you need to combine many small
> > projects into a bigger whole.
> 
> The same is true if you try to port e.g. PHP code to Guile, but then it
> only gets more difficult

Sure, but that’s not what I would compare it to. I’d rather com

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Mittwoch, 30. September 2015, 09:58:32 schrieb Taylan Ulrich Bayırlı /Kammer:
> Exactly, I agree.  It should be noted though that some things can be
> implemented purely as portable libraries, so there needn't be a Request
> For Implementations to do it, whereas some other things, which I call
> "fundamental" features, need to be supported by implementations, so they
> need to be in the language specification or an authoritative SRFI.

What is an authoritative SRFI? One which is available in most
implementations?

Best wishes,
Arne
-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org



signature.asc
Description: This is a digitally signed message part.

Re: bindings for fltk or tk?...

[Arne Babenhauserheide]

Am Dienstag, 13. Oktober 2015, 16:34:24 schrieb Robert lewko:
> Are there any bindings for graphical tool kits such as FLTK or TK?
> The only set of bindings are for GNOME and I am not a fan of GNOME.
> Nor to I wish to install all the dependencies that GNOME relies on
> (OK, I am an old unix guy and I normally just install enlightenment,
> so I don't have GNOME installed - call em weird).

There are quite a few who try that. I did, too, and only stopped when
I realized that avoiding gnome tools just made my computer harder to
use.

> So, here;s my question.  As outlined above, is this the best way to
> provide an API for FLTK?

I don’t have experience with that, so I can’t really help, but it
would be interesting for me to see it — in the way you rightfully
called weird above :)

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.

Re: Embedding Guile with sandboxing

[Arne Babenhauserheide]

Am Samstag, 21. November 2015, 13:35:12 schrieb Matthew Keeter:
> If I were to replace Python with Guile, is there a way to sandbox it so that 
> arbitrary (perhaps
> malicious) user-provided scripts can be run safely?

The languages which try to do that are Java and Javascript, and they
have several bugs connected to this every year (which i.e. allowing
execution of code with elevated priviledges).

To make this safe, you could follow the route described by Pascal:
Define a restricted sub-language which is not turing-complete. You can
do that with a medium amount of hassle with Guile (my personal
estimate). This will not give users a full programming language —
which is exactly why it can be made safe.

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

Re: list of guile related projects

[Arne Babenhauserheide]

Am Montag, 23. November 2015, 20:18:57 schrieb tantalum:
> here is a list of projects with code that guile can run and projects that use 
> guile:
> 
> http://sph.mn/content/3e73

Wow, that’s nice!

> i made this list and would be interested in hearing about projects i have 
> missed.

I wrote wisp aka SRFI-119: http://draketo.de/english/wisp

Best wishes,
Arne


signature.asc
Description: This is a digitally signed message part.

My Wisp slides for FOSDEM

[Arne Babenhauserheide]

Hi,

Can someone who’s at FOSDEM download my slides and lend me a computer
tomorrow during the talk (or get it on the presentation computer)?
https://fosdem.org/2016/schedule/event/guilewisp/attachments/slides/911/export/events/attachments/guilewisp/slides/911/fosdem2016_arne_babenhauserheide_wisp.pdf
 

I plan to arrive at 9:30 at Gare Midi so I’ll likely arrive just in time
for the Guile session and I wouldn’t want to have to fight with the
computer.

Liebe Grüße,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: My Wisp slides for FOSDEM

[Arne Babenhauserheide]

Hi Alex,

> I've downloaded them to my computer — but really I would rather be your
> fail safe, as I'm not 100% sure how my laptop will work with the
> presentation equipment :-/

Thank you!

I would help that someone who is presenting anyway would also bring it
(my laptop will likely not interact with the presentation equipment at
all…)

Best wishes,
Arne

>> Can someone who’s at FOSDEM download my slides and lend me a computer
>> tomorrow during the talk (or get it on the presentation computer)?
>> https://fosdem.org/2016/schedule/event/guilewisp/attachments/slides/911/export/events/attachments/guilewisp/slides/911/fosdem2016_arne_babenhauserheide_wisp.pdf
>>  

-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: My Wisp slides for FOSDEM

[Arne Babenhauserheide]

Jan Wedekind writes:

> WISP looks interesting. Does it work in the REPL?

Yes. The Guile implementation also uses the reserved final dot on a line
in SRFI-119 to make the REPL more convenient: You can end the line by
appending " ." to the line (and enter). Example:

> display "Hello World!\n" .

Debug output also mostly works: Most debug lines have the correct source
line information (some are missing, these might need more heavyweight
tracking of source information in the parser than I want to do right
now).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: My Wisp slides for FOSDEM

[Arne Babenhauserheide]

Jan Wedekind writes:

> Ok, I got it working in the REPL. Just had to copy 
> "language/wisp/spec.scm" and "wisp-scheme.scm"
> to the directory /usr/share/guile/2.0/language/wisp and then type
> ",language wisp" in the Guile REPL :)

Nice!

Please tell me about your experience with it.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: FOSDEM 2016 slides

[Arne Babenhauserheide]

Hi Alex,

> And my slides from the FOSDEM devroom (for my Guile Config
> presentation), for anyone interested (copying in Guile User as it isn't
> Guix related…):
>
> http://alex.pompo.co/presentations/fosdem-16-conf.html

These are great — and I hope I can use guile-config. I tend to write
quick commandline tools which sometimes begin to grow wild. Elegant
commandline parsing is still one of the things with which I had problems
in Guile, and I hope that guile-config can fix that. It already shows
what can be gained in expressivity by macros.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: My Wisp slides for FOSDEM

[Arne Babenhauserheide]

Jan Wedekind writes:

> Yes, I'm still playing with it.
>
> By the way, here is a proposed change for the automake build [1] to have 
> "make install" and "make uninstall" work as expected.
>
> [1] https://github.com/wedesoft/wisp/compare/master...make-install

That’s great — thank you!
(and easier to read)

Writing good autotools scripts is still a challenge — though I think
that’s mostly an issue of documentation.

When trying this, I stumble over this error message:

configure: error: searching for guile development files for versions 2.0 1.8, 
but previously found /home/arne/.guix-profile/bin/guile version 2.2

Do you know how to fix that?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: FOSDEM 2016 slides

[Arne Babenhauserheide]

Alex Sassmannshausen writes:

>>
>> These are great — and I hope I can use guile-config.
>
> Thank you! And great you want to use it — I'll try to get a proper
> release ASAP then :-)

Cool, thank you!

> I'd definitely be really keen in getting a config file writer/reader
> working using wisp too.  The more I think about it, the more I like the
> idea!

If it works with scheme code, it should directly work with Wisp, too —
thanks to the language integration in Guile.

That said, I’d like to see how it looks when written in Wisp. Looking
forward to a release!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [ANN] An impudent introduction to Guile

[Arne Babenhauserheide]

Panicz Maciej Godek writes:

> I also think it would be helpful to interface Guile with plot generation. I
> see that Nala has a guile-plot package, but I haven't tried it. I
> personally wrote some code for generating LaTeX pgfplots for the project,
> and can add it to the repo if you llike.

A good plotting tool would be great!

I actually opened a socket to Python and used pylab from Scheme when I
wanted to plot beautifully…

Liebe Grüße,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile-Config 0.1 Released

[Arne Babenhauserheide]

Hi Alex,

Alex Sassmannshausen writes:

> I have the pleasure of officially announcing the first release of
> Guile-Config.

That’s great!

> You can download the release tarball at:
>   http://alex.pompo.co/software/guile-config-0.1.tar.gz
…
> You can also conveniently install guile-config using Guix:
>   guix package -i guile-config

Is there a recommended way to use this in my project when my users don’t
use Guix?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [ANN] Lisparuga - a 2D shoot-em-up made for the Lisp Game Jam

[Arne Babenhauserheide]

Thompson, David writes:

> It's a bit difficult to build right now if you don't use GNU Guix

This is actually a really cool usage of Guix — a meta-distribution for
reproducible builds of non-packaged software.

I have guix running on Gentoo, but I had to adjust the build instructions:

guix pull # I do not know whether this was required

cd lisparuga-0.1.0
guix environment --search-paths -l guix.scm
(execute the update of the search paths by copying the lines into the shell)
./configure
make
./pre-inst-env guile game.scm


However it fails at OpenGL:

sly/window.scm:100:20: In procedure init-window:
sly/window.scm:100:20: Throw to key `sdl-error' with args `("make-gl-context" 
"failed to create OpenGL context: ~A" "Could not create GL context: 
GLXBadFBConfig")'.


Now if Guix (the build daemon setup with per-user profiles) just came
pre-packaged for all distributions… that would massively simplify
sharing in-development software.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

How do you earn money with Guile?

[Arne Babenhauserheide]

Hi,

> “I would take Guile seriously when someone earned money with it.”
> — someone from IRC

When I saw this on IRC, I realized that the there’s something to it:
When a professional sees something new and is unsure whether it can be
useful to business, it’s sensible to first check whether someone else
already earns money with it. That doesn’t work for the first person, but
it works for all others.


So I want to ask you: Do you earn part of your income by programming
with Guile?


I’ll go first: I used Guile for a few tasks for my PhD thesis (which I
got paid for).

The first main task was to assemble commandlines for my plotting tool
where my previous shell scripts became a maintenance nightmare. All in
all that’s about 300 lines of Guile Scheme. I’ll be using Guile for this
again in the following months.

The second main task was to build an Ensemble Kalman Filter to get a
deeper understanding of the method. That’s about 266 lines of Guile wisp
and available online:
https://bitbucket.org/ArneBab/wisp/src/v0.9.0/examples/ensemble-estimation.w


I’d be glad to hear how you earn money with Guile!


Best wishes,
Arne Babenhauserheide

PS: Earning money with Free Software is awesome!

Re: "AIscm" array JIT

[Arne Babenhauserheide]

Hi Jan,

Jan Wedekind writes:

> Yes, here are some examples with empty arrays and arrays with 250,000 
> elements. I hope that the upcoming Guile version 2.2 will help increase 
> performance as well.
>
>  $ make bench
>  Making bench in bench
>  make[1]: Entering directory '/home/jan/test/aiscm/bench'
>  LD_LIBRARY_PATH=./.libs:/usr/local/lib GC_INITIAL_HEAP_SIZE=1G 
> GC_USE_ENTIRE_HEAP=Y /usr/bin/guile bench.scm
> user system  total
> real
>  Guile GOOPS method dispatch0.40   0.00   0.40 (  
> 0.40)
>  Guile make empty sequence  0.000150   0.00   0.000150 (  
> 0.000140)
>  Guile allocate memory  0.000190   0.00   0.000190 (  
> 0.000200)
>  Guile negate empty sequence0.001580   0.000110   0.001690 (  
> 0.001690)
>  Guile make sequence0.000230   0.10   0.000240 (  
> 0.000240)
>  Guile negate sequence  0.002400   0.000930   0.003330 (  
> 0.003350)
>  C allocate memory  0.60   0.00   0.60 (  
> 0.60)
>  C negate empty sequence0.30   0.00   0.30 (  
> 0.30)
>  C negate sequence  0.000730   0.00   0.000730 (  
> 0.000720)
>  make[1]: Leaving directory '/home/jan/test/aiscm/bench'

Do you have a comparison to the same tasks without compilation?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: get all available symbols in scheme

[Arne Babenhauserheide]

Hi,

Welcome to Guile!

source liu writes:

> I wonder if there is some way to dump all available symbols in current
> enviroment（something like “dir” in python）， i think it is very useful when
> you are trying new modules

> I have tried the guile reference guide as well as google，but cant find any
> clue

It’s pretty hidden. The easiest way is activating readline and just
hitting tab twice:

echo "(use-modules (ice-9 readline))(activate-readline)" >> ~/.guile

Essentially this:

(module-map (λ (sym var) sym) (resolve-interface '(guile)))


and

,use ; returns (guile-user)
,in (guile-user) ,use ; returns module listing
,in (guile) ,b ; returns the bindings
,in ...

Essentially this:

(map (λ (x) (cons (module-name x) (module-map (λ (sym var) sym) 
(resolve-interface (module-name x) (module-uses (resolve-module 
'(guile-user


There actually isn’t a dir function, yet…

(import (ice-9 optargs))
(import (oop goops))
(use-modules (texinfo reflection))

; define basic dir
(define* (dir #:key (all? #f))
  (if all?
  (map (λ (x) (cons (module-name x)
(module-map (λ (sym var) sym) (resolve-interface 
(module-name x)
   (module-uses (current-module)))
  (module-map (λ (sym var) sym) (current-module
; add support for giving the module as argument
(define-generic dir)
(define-method (dir (all? )) (dir #:all? all?))
(define-method (dir (m )) (module-map (λ (sym var) sym) 
(resolve-interface m)))
; add support for using modules directly (interfaces are also modules, so this 
catches both)
(define-method (dir (m )) (module-map (λ (sym var) sym) 
(resolve-interface (module-name m


Now there is dir, but its output is a bit unwieldy for large modules…


You can use it this:

(dir) ; all local bindings, excluding imported modules
(dir #t) ; all available bindings, including imported modules
(dir #:all? #t) ; same as above

(dir '(ice-9 optargs)) ; all exported bindings from the (ice-9 optargs) module
; => (let-optional* define* let-keywords let-keywords* define*-public defmacro* 
defmacro*-public let-optional lambda*)

(dir (resolve-module '(ice-9 optargs)) ; all bindings in the module
; => (let-optional* parse-lambda-case %module-public-interface let-keywords 
let-keywords* define*-public defmacro* defmacro*-public *uninitialized* 
let-optional vars&inits)


I just added this to guile-basics: 
http://www.draketo.de/proj/guile-basics/#sec-2-5


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Performance implications of having many methods? Re: get all available symbols in scheme

[Arne Babenhauserheide]

Hi Tomas,

to...@tuxteam.de writes:

>> source liu writes:
>> > I wonder if there is some way to dump all available symbols in current
>> > enviroment [...]
>> It’s pretty hidden. The easiest way [...]
> [a blazing tour through Guile introspection follows]
>
> Not the OP here, but... wow, thanks, Arne!

Thank you for writing — I’m glad you like it!

It’s not all my own work, though: I have to thank the people in here and
in IRC who helped me understand it. They are pretty awesome!

What I missed was to note the use of (class-off OBJECT) to find the
value I put into the methods.

What I cannot give is performance information about the methods: There
are some important implications of having many methods, but I just don’t
know them.

>> I just added this to guile-basics: 
>> http://www.draketo.de/proj/guile-basics/#sec-2-5
> thanks again

Enjoy Guile, and Happy Hacking!
- Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How do you earn money with Guile?

[Arne Babenhauserheide]

Hi Jean,

Jean Crépeau writes:

> I used to work at a company called Avant! in California. Avant! was
> selling software (Apollo II and later Astro) which used an older version
> of guile (1.2 or 1.4, I can't remember which) that had been customized
> for the tool. Avant! made hundreds of millions selling those products,
> though customers were buying it more for its place and route technology
> than its interface language.

That sounds awesome!

And practically put, something like this, but with Guile 2.x, is a great
example of the user stories needed to spread Guile (along with the other
ones in this thread — I read them and they made me happy, but I didn’t
get to answer yet).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How do you earn money with Guile?

[Arne Babenhauserheide]

Tristan Colgate writes:

> To play the game a bit, I earned money writing guile, or rather, I wrote
> guile to earn money. I wrote guile-snmp to manage several large networks.
> guile-snmp was developed to run parts of the NHS.net network (I re-wrote
> several tools back to perl net-snmp for the benefit of colleagues, but
> tools were developed with guile-snmp first, far more quickly, and concisely
> that I could have achieved otherwise). I used and extended it for a 5 or 6
> years and it became by far the best SNMP reporting tool I've ever used
> (yes, I'm biased). I'm no longer in the network management business, and
> SNMP has (unjustly) fallen out of favour, so sadly I don't really do much
> with it any more.

This is really cool!

>   More importantly, I learnt an enormous amount about functional
> programming, learned to really lovee lisp (and scheme, and guile). That
> knowledge definitely made me a better programmer. It made me really "get"
> various aspects javascript development that I'd have struggled with
> otherwise. Got me interested in SML and haskell (the alternatives to the
> cult of lambda).
>
>   So my time with guile has, indirectly,  gotten me plenty of jobs, even if
> the people that hired me didn't know it.

I don’t know how to put that, yet, but this isq a pretty strong
quote. May I quote you on it? (though I’ll for starters only do that on
GNU social and twitter, because it’s easiest there)

I started using Guile to expand the limits of what I can do elegantly in
programming, and I feel that that expanded what I can do — writing three
witches¹ showed me where Programming could be and how much of what I
once considered as how programming works was actually ceremony, even
with Python — though Python still is the "rational" choice for many
problems I face.

Best wishes,
Arne

¹: http://www.draketo.de/english/wisp/shakespeare
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How do you earn money with Guile?

[Arne Babenhauserheide]

Christopher M. Hobbs writes:

> In today's development ecosystem, I fear a language won't gain any
> popular traction (and thereby cause profit to be gained) until you can
> build a blog or some other inane web application in it... preferably in
> under 5 minutes.  It doesn't matter how well the language does anything
> else.
>
> At the risk of derailing the thread, I think a better approach would be
> to show things that guile can do.  This seems to help the popularity of
> languages.

I agree that that is important. This thread is, however, to address a
specific aspect which I also think important and which I did not see
here at all till now: Before investing effort into anything, most people
first check whether others have successfully done so, especially when
they think about marketable skills. That’s a very useful strategy most
of the time (see xkcd bridge¹ ☺), and I did not see any answer for that
From Guile yet.

With this thread, we can now answer that question: Do people earn money
with Guile? Yes, they do. Here are some examples:
https://lists.gnu.org/archive/html/guile-user/2016-06/msg7.html

¹: https://xkcd.com/1170/

> And to contribute:  I wrote a couple of bits of guile at work for
> monitoring some system processes, which I was paid for.

Nice!

Did you use a specific library or module for that?

(that could be useful for my current work, too — for keeping tabs on a
Solaris cluster)

> I've also used it in a side project related to mail processing that
> may someday generate income but that's still a long way off.

Good luck! I hope it works out.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How do you earn money with Guile?

[Arne Babenhauserheide]

Nala Ginrut writes:

> It's an interesting topic. Although I planed to share something when I earn
> more money, now that someone raised it... :-)

:)

> Here I give you two real cases.
>
> The first one is that we use Guile to send command from UART to control a
> small robot. We made it in a sponsored hackathon. And earned the highest
> award in couple of hours, about $1500 (10,000 Chinese yuan). People never
> saw such a project, as the journalist wrote: "they ask the robot to write
> just 3 Chinese characters and get 10,000 yuan."
> It's an interesting story, I will write it in my blog. I wrote the
> prototype in Guile, but the hackathon day I have to go to church, and my
> friends encoutered problems, then someone have to rewrite it in Forth, or
> we may lost the chance in time. But the name of the project is
> lambda-tortoise, since it's in Scheme originally. Of course it's free
> project, and yes I wrote a thing to let Guile control serial port. But I
> haven't gotten time to release it.
> Here is the media report:
> http://m.leiphone.com/news/201510/Hk7mizNbynrIInam.html

Cool! I can’t really read the page, but Google translation gives a rough
idea if the content.

> The second case is that I wrote a complete video multicasting system for a
> primary school. It's a serious business project, I spent lot of time to
> debug and deploy. The priciple is not complicated, there's server-side
> written in GNU Artanis (of course it's pure Guile Scheme) provided RESTful
> APIs, and more than 50 raspberryPI as client nodes (running some scripts to
> interact with the server), each node control a TV set. The operator could
> control nodes in groups, or monitor heartbeat, and even give command to it
> (shutdown or replay certain video).
> The old solution is very expensive for the school, and can not be scalable.
> I use Artanis for quick develop, and raspberryPI is cheap. So I helped them
> to solve the scalability problem, now if they want to add new node, just
> buy a raspberryPI, and flash a card with a customized system, connect to
> network, plug to the TV set, and just power it, it'll be recognized by
> server and push the latest video list. Very easy for them.
> Besides, my server is faster then their old solution which runs on Windows
> with dot net. They surprised that how my server can be so fast to upload 1G
> video in few seconds. And I surprised too, how can they endure such
> performance these years, 200M video they have to wait 10 minutes.
> For such a result all beyond their expectation. I get well paid, consider I
> just spent two days for programming(more time spent on debug and deploy), I
> think it's efficient to develop with Guile.

That sounds great!

> Well, I can't reveal how much money for this project. But it's far more
> than the number of the award I mentioned in the first case.
> And unfortunately, they bought all the code, so I can't free it to you. I
> really want to persuade them to free it to make this project as a perfect
> case of free software. But it's high customized system to meet their
> specific need. They don't want to reveal it for many reasons.
>
> Anyway, Artanis become stronger after this real business project. I think
> it's the most important.

This is something which would fit really well as a user story on the
Artanis web page. It would be ideal if you could get a quote from a
principal of the School how much your work improved their situation.

> And I have to say frankly, I can earn the money is not because I use Guile,
> but because I know how to solve the problem. Although the ability of
> solving problem is unrelated to the language, it's good for you to choose a
> good language for better develop experiences.

> Guile is a practical one in Scheme world. To my experience, Scheme is
> flexible enough when your code base increase, that is to say, you
> don't have to refactor frequently to meet your new needs, all the old
> part are easy to intergrate with your new code.

And this paragraph should in one way or another be on the Guile Website.

> For an Object-Oriented user, this may not surprise, but what if you
> drop your heavy object system and do the job in a light way?
>
> I think I'm the only one who refuse OO (yes, extreamly intended) in Scheme
> programming. I just want to see, to what extent, we may drop OO for same
> purpose in Scheme. OK, I confess I'm cheating, since I use the inheritance
> in record-type in r6rs. But it's the only cheating. :-)

:)

Thank you for sharing your experience here!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Core Guile bindings

[Arne Babenhauserheide]

Ludovic Courtès writes:

> Hi!
>
> "Thompson, David"  skribis:
>
>> On Wed, Oct 12, 2016 at 3:18 PM, Panicz Maciej Godek
>>  wrote:
>>>
>>>
>>> 2016-10-12 20:21 GMT+02:00 Thompson, David :


 My understanding is that these symbols have been part of the default
 environment for so long that a lot of code would break if they were
 removed, so they will be staying for the foreseeable future.

>>>
>>> On the other hand, the fix would usually be trivial (just one use-modules
>>> clause), and besides I don't think that Guile has ever had a tradition of
>>> worrying too much about backwards compatibility.
>>
>> The Guile maintainers care very much about backwards compatibility,
>> from what I've seen over the last few years.
>
> I think I asked the same question as Panicz when I started using Guile
> ca. 2004.  The situation of global bindings hasn’t changed since then,
> and that’s for compatibility reasons that I very much appreciate as a
> user.

What would be possible without breaking backwards compatibility is
moving them ino a module which is imported by default, with a way to
suppress those default imports.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Core Guile bindings

[Arne Babenhauserheide]

Panicz Maciej Godek writes:

> 2016-10-13 20:19 GMT+02:00 Arne Babenhauserheide :
>
>>
>> What would be possible without breaking backwards compatibility is
>> moving them ino a module which is imported by default, with a way to
>> suppress those default imports.
>>
>> I think it is a very nice idea. Guile could install with "configurations",
> and the default configuration would just load the modules to make all
> currently global bindings available, but users could tweak their
> configurations in their ~/.guile files, supressing that default
> configuration. Or they could change it system-wide, provided that there are
> no dependencies in current guile scripts that could break anything.

To some degree this is already the case for interactive mode (so this is
not really my idea, just an application of what’s already there).

We might need an option to suppress loading the default modules, though,
similar to the -Q in emacs (which I use to make it start faster when I
just need basic editing capabilities).

However I think removing things from the existing default behaviour
should never be automatic, otherwise people won’t be able to rely on the
Guile on another system behaving as expected.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile security vulnerability w/ listening on localhost + port (with fix)

[Arne Babenhauserheide]

Christopher Allan Webber writes:
> browsers do and don't allow, but I'm stunned that a browser will let a
> request from some http://foo.example/ to http://localhost:37146/, even
> for just a GET.  It seems like there are all sorts of daemons you can
> exploit that way.

This can be pretty useful for embedding an iframe with a local service
(I do that for babcom[1]: Decentralized comments over Freenet, sadly still
pretty slow, because I’m using an in-Freenet system for that which
wasn’t optimized for the usecase).

On the downside, companies use the same methods to connect local
services with playback-restrictions (DRM) which aren’t easily doable via
the web alone. Likely this is the reason why it’s still possible, though
I’d wish it were the other way round (possible for the good usages, not
possible for the problematic-but-profitable ones)…

[1]: http://www.draketo.de/proj/freecom/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: on bootstrapping: first Mes 0.3 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen writes:

> I am pleased to announce the first release of Mes: 0.3, representing
> 152 commits over 3 months since the second status report[1].
>
> * About
>
> Mes aims to create an entirely source-based bootstrapping path.  The
> target is to [have GuixSD] boostrap from a minimal, easily inspectable
> binary --that should be readable as source-- into something close to
> R6RS Scheme.

This is really cool! Thank you for your work!

> As bootstrapping is presumably easiest and probably most fun with
> Scheme, the next step for Mes is mescc: a C compiler/linker to
> boostrap into GNU Gcc and GNU Guile, possibly via Tiny-CC.
>
> It currently has an interpreter written in C (mes) with Garbage
> Collector (Jam Scraper), a library of loadable Scheme modules with
> test suite just barely enough to support a simple REPL (repl.mes)
> and a proof-of-concept c-compiler (mescc.mes) that produces an elf
> from the simplest of C files.

How do you compile the interpreter?

> Mes is inspired by The Maxwell Equations of Software: LISP-1.5[2]
> -- John McCarthy page 13
…
> [1] https://lists.nongnu.org/archive/html/guile-user/2016-09/msg00061.html 
> [2] 
> http://www.softwarepreservation.org/projects/LISP/book/LISP%25201.5%2520Programmers%2520Manual.pdf

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: on bootstrapping: first Mes 0.3 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen writes:

> Arne Babenhauserheide writes:
>> How do you compile the interpreter?
>
> The current interpeter I consider to be a prototype in C; I use gcc.
> However, HACKING mentions two ways forward
>
> ** Move mes.c into hex?
> One idea is to use OrianJ's amazing self-hosting
> [[https://github.com/oriansj/stage0][stage0]] hex assembler and
> minimal bootstrap binaries and rewrite the mes.c core to directly
> bootstrap into Scheme.

This seems to be the strongest option, but also very expensive. And only
useful if it becomes a step on the way to compile GCC (the goal of
stage0).

> ** Rewrite mes.c and generate hex?
> Another idea (thanks Rutger!) is to rewrite the mes.c core in a
> C/Assembly variant and have mescc produce the simple, annotated
> bootstrap binary.
>
> Possibly you have an even better idea?  I am choosing to explore the
> latter first: work on the compiler backend and write the interpreter in
> its Assembly/C-like s-expressions.

I think the C/Assembly variant sounds better — maybe written in simple
enough style to be compiled by stage0 before that can compile GCC.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Dumb Licensing Questions

[Arne Babenhauserheide]

Wes Frazier writes:

> Ive mostly stuck to compiled languages until now. However, I know that
> if I were writing compiled code, using a GPLed library with no linking
> exception, my resulting code would have to be GPLed as well. This is why
> many libraries are under the LGPL instead (including libsdl proper.)
> 
> Is this the case for interpreted languages? including scheme code
> interpreted via guile? Is code using guile-sdl thus forced to be under
> the GPL?

You need to differenciate more strongly between code and the combined
work your users actually get.

For compiled code as well as for interpreted code which uses GPL’ed
code, your own code has to be under a GPL-compatible license.

If you ship the different parts together, the resulting *combined work*
will be GPL, but your part of the code will stay under the
(GPL-compatible) license you selected.

This means you have to provide your code to people who get your
*combined work*, but the license of your part of the code need not be
GPL — only GPL-compatible.

If through refactoring you incorporate some GPL code into code which is
only GPL-compatible, having different licenses for different parts of
the codebase will likely become hard to maintain so the pragmatic
decision is simply using the GPL.

> And if so why was guile-sdl licensed GPL when it's upstream library was
> LGPL? Was this intentional?

I do not know that. It could have been intentional or not — I can find
good reasons for and against that.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Dumb Licensing Questions

[Arne Babenhauserheide]

Greg Troxel writes:

>  writes:
>
>> It's clear that there are different standpoints. The linking thing (dynamic
>> or static) hasn't, AFAIK, tested in court. It's quite possible that different
>> courts reach different conclusions (in the same or different places in the
>> world). It's even possible (gasp!) that the legal interpretations of things
>> change over time.
>  
> Completely agreed.   And, to expand, copyright law doesn't talk about
> linking, it talks about things like "derived works", which leads to "if you
> do X, is it a derived work".
>
>> If I were you, I'd just comply with what the FSF proposes, and that is pretty
>> clear [1]. Any reasons not to comply with that?
>
> A very good point.  Stepping back, there is a question of what's legal
> and where the line is.  But there's another question of what individuals
> and the Free Software community think of as good behavior.  If someone
> writes software and makes it available under a Free License, politenss
> at least demands that those who copy/modify/distribute/use the software
> respect their wishes about what the license means.

Finally there’s the question what’s safe practice. There are three
cases:

1. safe ground: you don’t need to worry about legal issues.
2. murky waters: someone might sue you and you might win or lose.
3. clear breach: if you get sued, you lose.

Case 1 is "just assume you create a derived work and follow the
GPL". Just comply with what the FSF proposes.

Case 2 is madness if you don’t have a well-staffed legal team at your
disposal.

Case 3 is madness if you aren’t already in organized crime. And might be
madness even then (remember that many criminals got caught over tax
fraud. It would be ironic to see branches of the mafia get taken down
for breaching the licenses of the tools they distribute, while getting
away with murder).

Best wishes,
Arne


signature.asc
Description: PGP signature

Re: GOOPS functional setter

[Arne Babenhauserheide]

to...@tuxteam.de writes:
> [fset vs clone]
>
>> I think cloning isn't as clear; what we want is something that's the
>> same as the previous instance of the object, but with one field changed.

> Yes, and after having read your post I understood where you came from.
> The naming wouldn't have been discovrable for me right off.
…
> Now I'm not trying to imply that "clone" is "more right"; actually
> I believe that there are two "modes" at work here. Let me speculate
> a bit:
>
> Perhaps from the more "strictly functional" point of view, the clone
> operation is less important, because, whether the thing is cloned
> behind the scenes or things are arranged by deep compiler magic and
> the clone doesn't happen after all is none of our business. Not the
> cloning is important, but the changed fields. In this world, the
> mutating counterpart (set) doesn't even exists. Clone wouldn't be
> an appropriate name here.
>
> - From the more "naive", "imperative" point of view, it's the clone
> operation what keeps us awake: allocating memory and things. Here
> "clone" is the right word, it seems.
>
> Perhaps what irritates me most is that "fset" is named  after
> an imperative operation (set) and lives in a functional world.
> Or something.

If I did not need a short name, I’d use something like
slot-copy-with-changed. I had an immutable datatype in Python where I
used something equivalent to

(changed event
  #: new-value
  #: other-new-value)

I know that this does not provide a better name by itself, but I hope it
helps finding one.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Playing with guile (vs python). Generate file for GDP suitable for gnuplot.

[Arne Babenhauserheide]

Hi Germán,


If I understand your script correctly, you want to grab all lines with
GDP, sort the values by year and country and output them. Is that right?

As a first warning: the csv module in Python mainly calls into a C-based
implementation (_csv, see csv.__file__), so it will be hard to beat this
in pure Scheme.


But now, let’s begin with the optimization. These are my times:

$ time guile-2.0 extract_gdp.scm
real0m0.509s
$ time python3 extract_gdp.py
real0m0.089s

The first step is using Guile 2.1.6 instead of 2.0. That reduces the
runtime by 40% to 0.3s. Source: ftp://alpha.gnu.org/gnu/guile/guile-2.1.6.tar.xz

$ time guile extract_gdp.scm
real0m0.296s
$ time python3 extract_gdp.py
real0m0.089s

So there’s a factor of 3.3 between Python and Guile on my machine.


Aside from using a more recent Guile, I do not see obvious
optimizations, however (more exactly: all my tries to speedup the code
only made it slower). Though there might be optimizations I do not
see, because 80% of the remaining time is spent in string-parsing.


One thing where I don’t see how to make it cheaper in pure Scheme is
string->number. That calls directly into libguile/numbers.c which does
much more than what python's int() does (internally it calls
mem2complex). But using a pure-scheme function which does less only
makes it slower:

(define (string->integer s)
  (define (b10fold x kept)
   (+ (* 10 kept)
  (- (char->integer x) 48)))
  (string-fold b10fold 0 s))

As I said: the above makes the code run slower, not faster. A native C
function for string->integer (which only handles integers) could provide
a speedup for that, but I don’t know whether you want to go that far. See
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/numbers.c;hb=475772ea57c97d0fa0f9ed9303db137d9798ddd3#l6439

However every time I thought I had a program optimized as far as
possible, talking with Andy Wingo made it much faster, so there might be
lots I’m missing.

Given that just converting a bytevector read from the file to integers
takes 0.8s, I do not think just using bytevectors will help:
(bytevector->u8-list bv) ; takes 0.8s for your file

Maybe there are more efficient ways to do this, though.

Best wishes,
Arne



Germán Diago writes:

> Hello everyone,
>
> I did a script that parses some file with the GDP since 1970 for many
> countries.  I filter the file and discard uninteresting fields, later I
> write in a format suitable for gnuplot.
>
> I did this in python and guile.
>
> In python it takes around 1.1 seconds in my raspberry pi.
>
> In Guile it is taking around 11 seconds.
>
> I do not claim they are doing exactly the same: in python I use arrays and
> dictionaries, in guile I am using mainly lists, I would like to know if you
> could give me advice on how to optimize it. I am just training for now.
>
> The scripts in both python and guile are attached and the profile data for
> scheme is below. Just place in the same directory the .csv file and it
> should generate an output file with the data ready for gnuplot :)
>
> % cumulative   self
> time   seconds seconds  name
>  26.24  3.45  3.43  %read-line
>  20.51  2.68  2.68  string->number
>  15.54  2.05  2.03  string-delete
>   7.39  7.75  0.97  map
>   5.13  3.96  0.67  transform-data
>   4.07  1.75  0.53  format:format-work
>   3.17  0.41  0.41  string=?
>   2.87  0.37  0.37  string-ref
>   1.81  2.50  0.24  tilde-dispatch
>   1.81  0.24  0.24  number->string
>   1.51  0.34  0.20  is-a-digit
>   1.06  0.28  0.14  anychar-dispatch
>   1.06  0.14  0.14  display
>   1.06  0.14  0.14  string-length
>   1.06  0.14  0.14  char>=?
>   1.06  0.14  0.14  char<=?
>   1.06  0.14  0.14  string-split
>   0.60  0.08  0.08  length
>   0.45  0.49  0.06  format:out-num-padded
>   0.45  0.06  0.06  remove-dots
>   0.30  0.04  0.04  %after-gc-thunk
>   0.30  0.04  0.04  list-tail
>   0.30  0.04  0.04  write-char
>   0.15  3.53  0.02  loop
>   0.15  3.47  0.02  read-line
>   0.15  0.02  0.02  substring
>   0.15  0.02  0.02  list-ref
>   0.15  0.02  0.02  reverse!
>   0.15  0.02  0.02  # (e)>
>   0.15  0.02  0.02  integer?
>   0.15  0.02  0.02  char=?
>   0.00 13.07  0.00  load-compiled/vm
>   0.00 13.07  0.00  # (thunk)>
>   0.00 13.07  0.00  # ()>
>   0.00 13.07  0.00  call-with-prompt
>   0.00 13.07  0.00  # ()>
>   0.00 13.07  0.00  apply-smob/1
>   0.00 13.07  0.00  catch
>   0.00 13.07  0.00  #
>   0.00 13.07  0.00  run-repl*
>   0.00 13.07  0.00  save-module-excursion
>   0.00 13.07  0.00  statprof
>   0.00 13.07  0.00  start-repl*
>   0.00 11.22  0.00  #
>   0.00  3.53 

Re: Playing with guile (vs python). Generate file for GDP suitable for gnuplot.

[Arne Babenhauserheide]

Germán Diago  writes:

>> Aside from using a more recent Guile, I do not see obvious
>> optimizations, however (more exactly: all my tries to speedup the code
>> only made it slower).
>
> I was struggling with using read-line! instead of read-line but
> experimenting in the command line
> I cannot figure out how it works actually. read-line! will reuse a buffered
> string. There was lots of time spent there, I am not sure if because of
> allocations or just because of I/O. If someone could tell me how to do it...

One thing I realized now is that you might be able to avoid the
string->number conversion completely since you’re outputting as text
anyway. That might save 1/4th of the time (but I did not experiment with
that now).

Also I’m not sure whether the "is this a number"-check could be sped up
by adding specialization for chars in the Scheme-compiler, similar to
how floating point comparisons were added in the latest release:
https://git.dthompson.us/guile.git/commitdiff/79fa147990021b48a5ede2f33441bc95721fe63d

> Thanks for your time Arne!

Thank you for the challenging problem :)

Best wishes and happy hacking!
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Hi Amirouche,

Thank you for your nice writeup!

Amirouche writes:

> I don't know why Racket is successful probably because
> it has a very good documentation and also a documentation
> generator written in scheme.
>
>   => This is a long debate and core principle of GNU project
>  so I don't want to enter that debate

But I want to add something: I’m getting the hang of just checking the
info-page to look something up. And I realize that with well-written
info-pages this is faster than googling for stack overflow.

> And it's easy to packages.
>
>   => Another pain topic. In reality it's very easy to package
>  all sort of guile programs for guix. But guix itself needs
>  to be more stable.

I wish I had guildhall ready. Got hit by
time-eaten-by-other-project-because-guildhall-was-priority-three.

It needs to be easy to not just package some code, but also to share
that package without hitting a bottleneck.

> Python is successful because it has a massive number
> of libraries.
…
>=> We (all the people reading this mail) can not just
>   create all those projects. It requires to many domain
>   knowledge for a handful of people to be able to compete.
>   But what we can do is *share*, *share* and *share*
>   again *all* what we do (on mailing list, blogs, on gitlab
>   or whatever) whether it is a full blown project with a
>   website made by a professional designer with tests suite,
>   a tutorial documentation reference doc and a community or
>   a simple *snippet* or broken experiments.

A really simple way to share a project would be nice here. Nowadays many
people just push something with a README to github, but github is
unfree.

>=> In terms of software I really think, we need something like
>   ActiveState Python Cookbook [0]. I still go there sometime even
>   I could simply ask the question on StackOverflow and get an
>   answer in minutes.
>
>   [0] http://code.activestate.com/recipes/langs/python/
>
> During a long time I was said that Pythonist were
> among the smartest developer, because simply they had
> the guts to learn a language that was not learned in
> school.

I never heard that one :)

> Python *was* easy to learn.
>
>   => Scheme is easy to learn if you stick in the "garden"
>  (garden must be defined but it's basically what I
>  introduce in my tutorial [1]) Which is totally the
>  same for the Python of today (read Python 3.5+).

Or look at py2guile: http://draketo.de/py2guile

Python is no longer easy due to integrating additional syntactic forms,
each of which makes a specific kind of code much nicer but complicates
learning.

We have something similar in foof-loop:

(define (count-matching-items list predicate)
  (loop ((for item (in-list list))
 (with count 0   
   (if (predicate item)
   (+ count 1)
   count)))
=> count))
;   ^^ here

This looks really simple in this place, but it introduces special syntax
which will be unintelligible for someone who does did not explicitly
learn foof-loop.

And guildhall is filled with special forms I had to understand just to
be able to do small changes.

This is a social problem. For a deeper discussion why it is a problem,
see http://winestockwebdesign.com/Essays/Lisp_Curse.html
"Lisp is so powerful that problems which are technical issues in other
programming languages are social issues in Lisp."

We can counter this with easy tutorials and with writing something like
canonical Scheme. But for this, we need to define a canonical Scheme
which is hits the performance and readability sweet-spot for
Guile. Canonical code must be close to the fastest code.

Practically put: We need Andy Wingo to nitpick the tutorial about things
which will cause overheads the compiler cannot fix easily — including
expensive use of macros.

>  [1] http://hyperdev.fr
>
> PHP was successful back in the days because it was easy
> to install,

Or because it was the only thing which existed. Didn’t it make it easy
for the hoster to sandbox it — both in terms of access and in terms of
resource requirements?

> => A scheme web application is much easier to run!

Sadly not on my cheap webhoster which provides unlimited bandwidth for
a fixed cost.

> => While you might not be interested to build something
>like prestashop. You very much be interested to build
>something like Drupal or Wordpress to allow mom and
>dad and others create a personnal experience on the
>web.
>
> Another thing, Python has GNU Media Goblin
>
> => We must do better!

Or, maybe collaborate with it? I’m sure that there’s lots of stuff which
could be shared, because it is not language-specific (more exactly: it’s
HTML, CSS, Javascript and images).

> What block you from contributing to the wide ecosystem of GNU Guile?

- publishing a program for non-Linux platforms (well, Windows, OSX and
  mobile phone

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Arne Babenhauserheide writes:
> - an alternative to `python setup.py register sdist upload`

Since we are GNUfolks, we can leverage autotools for that. I have a
pet-project which automates the setup of autotools-projects in the style
of Rust Cargo (but without the NIH). I should share it … 

Best wishes,
Arne

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Panicz Maciej Godek  writes:

> 2017-02-13 12:06 GMT+01:00 Arne Babenhauserheide :
> There's also this problem with Scheme that it is a very diverse
> community with plethora of implementations. And while I use Guile, I
> don't mind using Chicken or Chez or Gambit for various purposes. Or
> even Stalin sometimes. Maybe, instead of getting a better compiler, we
> should focus on integrating existing compilers?

You’ll have to ask Andy Wingo about all the hidden complexity in just
wiring in a compilier. I assume it’s pretty big.

I think the r7rs folks are working in that regard, to make it possible
to write code which you can simply run through another Scheme
implementation if you need those strengths.

I started to use (import (...)) to get closer to that: Getting used to
the portable stuff (also it’s shorter than (use-modules (...)). But not
everything is portable, and performance critical stuff most definitely
isn’t.

And for the stuff I do, most things get performance critical at some
point. Even looking for null-bytes in a file becomes a bottleneck if you
have a few hundred TiB to check.

Though I mainly need to write Python at work (Scheme isn’t widespread
enough for the folks there — Python is everywhere in science
nowadays). It’s still efficient to do that and I enjoy it, but not as
much as writing Scheme.

>> And it's easy to packages.
>> >
>> >   => Another pain topic. In reality it's very easy to package
>> >  all sort of guile programs for guix. But guix itself needs
>> >  to be more stable.
>>
>> I wish I had guildhall ready. Got hit by
>> time-eaten-by-other-project-because-guildhall-was-priority-three.
>>
>> It needs to be easy to not just package some code, but also to share
>> that package without hitting a bottleneck.
>>
> What happened to initiatives like Scheme NOW, that tried to integrate
> various groups of developers.

I did not hear from that.

> Or why can't we just "steal" eggs from Chicken? (I mean it. They already
> have that problem solved)

Do you mean, integrating eggs into Guile so we could just use them?
Conceptually what would be needed for that is a metadata field: "Works
with Guile". And practically someone to write the integration.

We could also have guildhall working, and add a tool for converting
chicken eggs into guildhall packages (and ideally vice versa). Then
people could do the required Guile integration steps once and provide
the packages to all who might want them.

>> > Python is successful because it has a massive number
>> > of libraries.
>>
>
>> This is a social problem. For a deeper discussion why it is a problem,
>> see http://winestockwebdesign.com/Essays/Lisp_Curse.html
>> "Lisp is so powerful that problems which are technical issues in other
>> programming languages are social issues in Lisp."
>>
>> We can counter this with easy tutorials and with writing something like
>> canonical Scheme. But for this, we need to define a canonical Scheme
>> which is hits the performance and readability sweet-spot for
>> Guile. Canonical code must be close to the fastest code.
>>
> Practically put: We need Andy Wingo to nitpick the tutorial about things
>> which will cause overheads the compiler cannot fix easily — including
>> expensive use of macros.

> I definitely oppose. If Chez has something solved better, why not use
> Chez?

It’s not "why not use Chez", but rather "what should I teach new
people?"

They are already learning a new language. When I now go and point them
towards many different implementations which differ in details of stuff
I teach them, I’m throwing more complexity at them. More things to
understand before even starting to write working code.

Maybe it would already help to mark the code which will work the same in
all (r7rs) Schemes. Is there stuff which is well optimized in all
Schemes? Who knows that? The r7rs benchmarks look like this is very much
not the case: http://ecraven.github.io/r7rs-benchmarks/benchmark.html

(Or rather, the benchmarks would ask: "why should I *not* use Chez or
stalin for everything I do?" Because those are the fastest for most
tasks.)

But that might mean to write less elegant or efficient code to keep it
cross-implementation. Should I rather teach new people to solve a
problem as well as possible, or teach them to solve a problem in a
portable way?

In my case, I decided to use Guile by checking Scheme
implementations. There were three with roughly equal activity and
features. I chose Guile, because it’s a GNU project and it has a long
history of surviving changing maintainers, so my skills are most likely
to stay useful.

> The ultimate goal is not to optimize programs, but programmers.

I’m 

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Amirouche  writes:

> Le 13/02/2017 à 12:06, Arne Babenhauserheide a écrit :
> My peers have this habit during system programming looking at man
> pages and other stuff. I don't know much command line-fu. My experience,
> about programming:
>
> - looking up the API referennce (procedure index)
> - looking up ansers in stack overflow

I used to do that. But Emacs C-h i C-s  is becoming more
and more efficient for me (since I know more and more keywords).

I still google stuff, but less than in Python. It feels like the info
documentation is actually better.

> In the case of Guile programming I also look general scheme solution like
> in racket. Last time I checked they had a Racket->JS translator, but not
> much graphdb stuff.
>
> The ability to generate multiple format is what makes TEXINFO powerful.

Yes.

>> It needs to be easy to not just package some code, but also to share
>> that package without hitting a bottleneck.
>
> I got stuck with guile-git; because of new way of bindings C. I use
> guile-bytestructures.

It would be great if you could simply run "make binary" and get binaries
for multiple platforms which you can provide for different people.

But that’s just what blocks me the most.

>> A really simple way to share a project would be nice here. Nowadays many
>> people just push something with a README to github, but github is
>> unfree.
>
> I try to move to framagit. but I still use github sometimes.

I did not hear from that until today. I prefer Mercurial with my
self-written site extension[1] for static http repositories — at least
as a backup.

[1]: https://www.mercurial-scm.org/wiki/SiteExtension

>> Practically put: We need Andy Wingo to nitpick the tutorial about things
>> which will cause overheads the compiler cannot fix easily — including
>> expensive use of macros.
>
> Right now, I don't have performance issues. Except maybe with the crawler 
> code.
>
> I improved stream srfi-41 performance, if you want the code.

Sounds good. Can you get that into Guile? Having the default
implementation more efficient would help me the most (in case I need
streams at some point).

>>>  => A scheme web application is much easier to run!
>> Sadly not on my cheap webhoster which provides unlimited bandwidth for
>> a fixed cost.
> Ok, I have a vps, I simply spawn the guile application in a screen and
> point nginx to it. It's like configuring nginx for gunicorn. nginx forward
> the traffic from :80 to :8080 or whatever based on some rules. It's like
> a router for the ports being smart about http protocol.

That’s like a remote server with full access. What I have is FTP
access. But in exchange my sites can cope with serving several hundreds
of GiB of data per month.

> There is the protocol Chris is working at w3c which is interesting.
> I forgot the name :p but it looked cool. At some point, I'd like to talk
> some kind of federation protocol. The issue is that they require some
> identification, so that people can name you unlike 4chan. Yes my current
> project is like a text 4chan with a search engine.

In GNU social you can simply use n...@instance.tld

But this is again standard proliferation. I already moaned when
identi.ca turned away from status.net. The new pump.io interface never
worked well for me :(

> I love their website and logo!

:)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Marko Rauhamaa  writes:
> I have typed this message in emacs.

Same for me, but getting people to use Emacs is harder. It might not
*be* that complicated, but it *feels* different.

> In my opinion one of the worst problems with Scheme is the Schemers:
> Scheme lovers are often far too enthusiastic with defining new, esoteric
> syntax instead of solving practical problems.
>
> Then, there's GOOPS, which in my opinion is simply an unnatural way to
> go about object-oriented programming. It does violence both to ordinary
> OO way of thinking and classic Lisp idioms.

GOOPS works pretty well for me where I use it (for dispatch by
type). Could you clarify your criticism: Do you think it is bad or is it
just different?

> Continuations and multiple values are obstacles instead of enablers.

I think multiple values are nice. But they are not well-integrated (I
have to import something to use them). Why do you think them enablers?

Why do you think that continuations are an obstacle (do you mean general
continuations or do you mean prompts)?

> BTW, Python seems to be suffering from quite many self-inflicted wounds:
> Python2/Python3 incompatibility,

Py2 vs. Py3 really hurts, yes.

It still really hurts and will likely hurt for the next 10 years. I
think that should be a lesson for all other language-implementors: Once
you start to become popular, you cannot do any backwards-incompatible
changes without endangering your position. Once you start to get
traction, you have to stick to your horse.

Many other wounds I do not see as much:

> asyncio, type annotation,

type annotations should provide nice ways to optimize for pypy and other
more optimizing Python implementations.

> decorators,

Decorators are really cool to use:

@with_progress
def something():
time.sleep(10)

That’s almost like

(with-progress
  (define (something)
  (sleep 10)))

But decorators are actually definition time, so they bring the tower of
meta-levels to Python …

> dunder jungle,

What’s that?

> meta-object programming,

That’s needed to make some things elegant. "Different 20%"-rule again.

> Unicode illusion. (Guile has fallen into that last trap as well,
> unfortunately.)

I’m using Python and Guile for physics and math (to some degree), and
having good Unicode-support is great for that. What’s your practical
criticism here?

> In its eagerness to please everyone, Python might well
> be jumping the shark.
>
> There's one thing Python has over Guile, still: Python's system call
> support is outstanding. For example, I managed to implement a full-blown
> shell using Python. That was the first time I ever ran into
> terminal-related system calls, and Python had them all.

Which ones are missing in Guile?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Panicz Maciej Godek  writes:
> There's surely many ways to approach that issue. The point is that for
> some reason, Schemers from various tribes prefer to reinvent the
> wheel, rather than use an existing one. (Not that I am any different)
> However, I also think that these CPAN-alike solutions are far from
> optimal: ideally, programming could be made an experience similar the
> game "The Journey" by thatgamecompany (where you travel to your goal
> and sometimes encounter other players heading the same direction), and
> the repository itself could look more like Wikipedia (but first we'd
> need to start perceiveing programming as a compact way of representing
> knowledge)

That sounds somehow like stackoverflow. We might already be going there :)

>> Practically put: We need Andy Wingo to nitpick the tutorial about things
>> >> which will cause overheads the compiler cannot fix easily — including
>> >> expensive use of macros.
>>
>> > I definitely oppose. If Chez has something solved better, why not use
>> > Chez?
>>
>> It’s not "why not use Chez", but rather "what should I teach new
>> people?"
>>
>> They are already learning a new language. When I now go and point them
>> towards many different implementations which differ in details of stuff
>> I teach them, I’m throwing more complexity at them. More things to
>> understand before even starting to write working code.
>>
> I totally agree. Programmers shouldn't be concerned whether they're
> using Chez or Guile or Gambit or Stalin or whatever else. Ideally, they
> should do well without even knowing that such things exist.
> There are Schemes, such as Kawa or Biwa or IronScheme, that are tied
> to their environment, but most of them just run on the PC

I think this is a point which cannot be reached, because the design of
the Scheme system itself must make certain tradeoffs — especially for
the default environment (what to present a new user). If that is too
large, then users cannot start quickly. If it is too small, then users
cannot solve problems easily. But different problem spaces require
different base tools.

Another points are the basic datastructures: If they are too complex,
then the system cannot be used easily on tiny computers.

Essentially you have to find reasons for decisions like this:
https://docs.python.org/3/faq/design.html#how-are-lists-implemented
and this:
https://wiki.python.org/moin/TimeComplexity

>> Maybe it would already help to mark the code which will work the same in
>> all (r7rs) Schemes. Is there stuff which is well optimized in all
>> Schemes? Who knows that? The r7rs benchmarks look like this is very much
>> not the case: http://ecraven.github.io/r7rs-benchmarks/benchmark.html
>>
>> (Or rather, the benchmarks would ask: "why should I *not* use Chez or
>> stalin for everything I do?" Because those are the fastest for most
>> tasks.)
>>
>> But that might mean to write less elegant or efficient code to keep it
>> cross-implementation. Should I rather teach new people to solve a
>> problem as well as possible, or teach them to solve a problem in a
>> portable way?

> I think that in principle, the programmer should only focus on writing
> most elegant code

I think there are several different kinds of elegance. There’s technical
elegance (combining existing things to build something unexpectedly
powerful with minimal effort), readability (being easy to understand for
newcomers), minimal code (solving a problem with the minimal amount of
code — often close to mathematics), uniformity (using the same basic
structure everywhere), efficiency (solving a problem with minimal
resource-consumption), ...
I’m sure we’ll find more.

Sadly these elegances contradict each other in some points.

>> In my case, I decided to use Guile by checking Scheme
>> implementations. There were three with roughly equal activity and
>> features. I chose Guile, because it’s a GNU project and it has a long
>> history of surviving changing maintainers, so my skills are most likely
>> to stay useful.

> That's interesting. I chose it by trying to add a scripting language
> to my game engine written in C++. But I guess that if I was starting
> now, I'd write the whole engine in Chez (which wasn't opensource until
> last year)

Chez becoming free software is an interesting development.

>> > The ultimate goal is not to optimize programs, but programmers.
>>
>> I’m not sure that I want to optimize them, I want to teach them tools to
>> be more efficient and enjoy their work more (and teach myself the same).
> Yeah, maybe I used a harsh word, but I meant exactly optimizing
> programmers' efficiency (or if it sounds too bad, "giving them tools
> to be more efficient")

Sounds good :)

>> I think one important point for Scheme would be to gather some consensus
>> points. The Zen of Python is part of what made that one community
>> strong. There is no reason why there should not be a Zen of Scheme,
>> along with implementation-specific Koans which extend it.

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Marko Rauhamaa  writes:

> Arne Babenhauserheide :
>
>> Marko Rauhamaa  writes:
>>> Then, there's GOOPS, which in my opinion is simply an unnatural way
>>> to go about object-oriented programming. It does violence both to
>>> ordinary OO way of thinking and classic Lisp idioms.
>>
>> GOOPS works pretty well for me where I use it (for dispatch by type).
>> Could you clarify your criticism: Do you think it is bad or is it just
>> different?
>
> GOOPS starts by defining slots. Slots are an objects internal business
> and should not be visible to the outside. Instead, objects should be
> black boxes that interact with methods. For example, the port interface
> is a nice, classic OO API. You don't know anything about the slots of a
> port.
>
> Furthermore, I think an extensive type system is un-Lisp-like. OO is not
> about things belonging to a type but objects interacting through
> methods. In fact, the concept of a "class" could be done away with.
>
>>> Continuations and multiple values are obstacles instead of enablers.
>>
>> I think multiple values are nice. But they are not well-integrated (I
>> have to import something to use them). Why do you think them enablers?
>
> Yes, the multiple values API is a problem in and of itself, but more
> generally, what does:
>
> (values a b c)
>
> give you on top of, say:
>
> (list a b c)

Practically it gives me (let-values (((a b c) (values 1 2 3))) a)

I could get the same by using match on a list, but then I have to use
match on a list instead of just assigning the values. let-values could
be designed to work with lists, though.

So conceptually I assume that the real difference is in implementation:
avoiding the construction of a list.

>> Why do you think that continuations are an obstacle (do you mean
>> general continuations or do you mean prompts)?
>
> Continuations prevent you from implementing Python's try/finally and
> emacs' (unwind-protect).

If I understand it correctly, this is only true, if there are resources
in use which do not get created in the try. I hit that problem when
implementing 'with':
https://bitbucket.org/ArneBab/wisp/src/3a654cfe6632af4b0002ce98c753c07c400aac55/examples/with.w#with.w-8

with (open-file "with.w" "r") as port
  format #t "~a\n" (read port)

^ working Guile code which ensures that the port is closed after it is
  no longer used. But it can break if a continuation is used. To fix
  that, I’d have to add guards which save the state of the port when
  code creates a continuation and reconstructs that state when the
  continuation is used.

> On the other hand, I don't think any application developer would come to
> a point of thinking, "Hey, I know, I'll use a continuation!"

Error-handling is simply a specific case of that. In Python people use
exceptions for flow control, which can be efficient when the
non-exception case is much, much more common than the exception case
(because in the first case the overhead of that is almost zero).

>>> asyncio, type annotation,
>>
>> type annotations should provide nice ways to optimize for pypy and
>> other more optimizing Python implementations.
>
> You can't have it bothways. A dynamic language liberates you from
> shackles and boilerplate even if it destroys your performance. The
> moment you bring in the boilerplate, you are back to Java.

It’s optional boilerplate which you only add where you really need it.

>> Decorators are really cool to use:
>
> Have yet to find a need for one.

I used them quite a bit. The most efficient one was a caching decorator:

@cached
def fun(a):
# something expensive
return a

In Python 3.2 you can use the standard lru-cache for that:
https://docs.python.org/3/library/functools.html#functools.lru_cache

>>> dunder jungle,
>>
>> What’s that?
>
> https://docs.python.org/3/genindex-_.html>

Ah, yes :)

I think these are a good way to show that I as developer am venturing
into regions I should only enter when I am really, really sure I want
to, because they can cause problems I may not see right away.

Sadly this rule is broken with if __name__ == "__main__": ...
and for def __init__(self)

So I think it’s good to have that, but not good that programmers need to
use that during typical programming tasks.

>>> meta-object programming,
>>
>> That’s needed to make some things elegant. "Different 20%"-rule again.
>
> Again, I haven't yet found a need to deviate from the regular object
> semantics.

I saw some, like actually accessing and changing the bytecode at runtime
to add tracing commands.

>>> Unicode illusion. (Guile 

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

David Kastrup  writes:

> Arne Babenhauserheide  writes:
>
>> Marko Rauhamaa  writes:
>>> I have typed this message in emacs.
>>
>> Same for me, but getting people to use Emacs is harder. It might not
>> *be* that complicated, but it *feels* different.
>>
>>> In my opinion one of the worst problems with Scheme is the Schemers:
>>> Scheme lovers are often far too enthusiastic with defining new, esoteric
>>> syntax instead of solving practical problems.
>>>
>>> Then, there's GOOPS, which in my opinion is simply an unnatural way to
>>> go about object-oriented programming. It does violence both to ordinary
>>> OO way of thinking and classic Lisp idioms.
>>
>> GOOPS works pretty well for me where I use it (for dispatch by
>> type). Could you clarify your criticism: Do you think it is bad or is it
>> just different?
>
> My main beef with GOOPS is that it does not help with narrowing down on
> a solution but rather with extending the problem space.  It is too
> generic to provide guidance and a cohesive framework: if two different
> people solve problems using GOOPS, the likelihood that those solutions
> can be connected in interface or design better than non-GOOPS solutions
> is slim.

That’s a good point.

A framework which provides that guidance could be built on top of GOOPS,
though. Or would that carry around too much burden from the generic
approach it’s based on?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Michael Vehrs  writes:

> As a late-comer to this discussion, here are my two cents. The thing I 
> miss most is a central package repository like Eggs Unlimited 
> (http://wiki.call-cc.org/chicken-projects/egg-index-4.html), or the 
> Racket Package List (http://pkgs.racket-lang.org/), or CPAN, of course. 
> Sure, a bespoke package manager might be nifty, but a single curated 
> list of packages would be a game-changer.

In theory we have guildhall for this: https://github.com/ijp/guildhall

In practice it does not provide a web interface for uploading packages.

If you want to do something truly exciting, you could take wingos fibers
and build a high performance web interface for guildhall with them.

This is something I’d love to do but I fear that it’s not high enough in
my todo list that I’ll actually get it done.¹

Best wishes,
Arne

¹: I became Freenet Release Manager a few months ago. That took away the
   last free time I could allocate to new challenging projects.
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Michael Vehrs writes:

> On 02/20/2017 09:41 PM, Arne Babenhauserheide wrote:
>> Michael Vehrs  writes:
>>
>>> As a late-comer to this discussion, here are my two cents. The thing I
>>> miss most is a central package repository like Eggs Unlimited
>>> (http://wiki.call-cc.org/chicken-projects/egg-index-4.html), or the
>>> Racket Package List (http://pkgs.racket-lang.org/), or CPAN, of course.
>>> Sure, a bespoke package manager might be nifty, but a single curated
>>> list of packages would be a game-changer.
>> In theory we have guildhall for this: https://github.com/ijp/guildhall
>
> In theory, yes. But there isn't actually very much available in the 
> repository.

I think the main reasons for that are (a) that it’s unmaintained (you
can’t just get your package added), (b) that it’s underdocumented (it
doesn’t say how to add a package or create a repo in less than 5 steps),
and (c) that there is no web interface for uploading a package.

>> In practice it does not provide a web interface for uploading packages.
>>
>> If you want to do something truly exciting, you could take wingos fibers
>> and build a high performance web interface for guildhall with them.
>
> High performance is not really important in this case. We are not 
> talking about gazillions of npm packages.

That’s true. That’s why I wrote exciting :)

You could also use the existing (web server) tools to build such a site.

Best wishes,
Arne

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Amirouche  writes:
>> If someone had a realistic plan of building something like that, I 
>> might be able to contribute. I am not going to tackle it alone.
>
> What's the status of guildhall, does it work? where are the latest changes?

What we need is someone who regularly puts the package folder onto a
static webserver (starnge that I did not think of just using a repo
instead of implementing a full web interface with access rights and
such).

Guildhall works with guile-2.0, and there are no changes (though I have
a local version in which `guild hall` outputs the default installation
locations).

However I get an error with guile 2.1.5:

$ make
./env /home/arne/.local/bin//guile-tools compile -Wunbound-variable 
-Warity-mismatch -Wformat -o "guildhall/cli/config.go" 
"guildhall/cli/config.scm"
Backtrace:
In ice-9/boot-9.scm:
  2860:10 19 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  2799:17 18 (resolve-interface (guildhall config) #:select _ #:hide …)
  2724:10 17 (_ (guildhall config) _ _ #:ensure _)
  3000:16 16 (try-module-autoload _ _)
   2336:4 15 (save-module-excursion #)
  3020:22 14 (_)
In unknown file:
  13 (primitive-load-path "guildhall/config" #)
In guildhall/config.scm:
 25:0 12 (_)
In ice-9/boot-9.scm:
  2799:17 11 (resolve-interface (guildhall destination fhs) #:select …)
  2724:10 10 (_ (guildhall destination fhs) _ _ #:ensure _)
  3000:16  9 (try-module-autoload _ _)
   2336:4  8 (save-module-excursion #)
  3020:22  7 (_)
In unknown file:
   6 (primitive-load-path "guildhall/destination/fhs" #)
In guildhall/destination/fhs.scm:
152:0  5 (_)
In guildhall/ext/inc/irregex-r6rs.scm:
  1505:17  4 (sre->irregex _ . _)
  2448:15  3 (sre->nfa _ 0)
  2391:29  2 (lp ((* any) (: "." ($ (+ (~ numeric) 1 0 0)
  2301:52  1 (lp ("." ($ (+ (~ numeric 1 0 _)
In ice-9/boot-9.scm:
   762:26  0 (dispatch-exception _ _ _)

Best wishes,
Arne


signature.asc
Description: PGP signature

Re: GNU Guile 2.1.7 released (beta)

[Arne Babenhauserheide]

Andy Wingo  writes:

> I think that the 2.1.x series is ready to go.

Nice!

> Release blocker bugs principally concern ABI.  For example the foreign
> objects facility which was applied to 2.0 and 2.2 and then rolled out
> from 2.0 because maybe it's not an interface that we want to support in
> the future -- well that is still part of 2.2 and if we released today we
> would indeed have to support it.  It's that kind of question.

The main strategical question I see for that is: Does anything make it
harder to complete or improve the lilypond transition to Guile 2?

Is there something which would need to be done before 2.2 which could
make it easier for lilypond developers?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile benchmark

[Arne Babenhauserheide]

Chris Vine  writes:

> On Mon, 27 Feb 2017 21:00:54 +0100
> Andy Wingo  wrote:
>> Hi,
>> 
>> On Thu 26 Jan 2017 09:39, Rchar  writes:
>> > https://ecraven.github.io/r7rs-benchmarks/benchmark.html
>> > Is Guile slow or fast, comparing to others?  
>> 
>> Schemes that compile to native code go faster.  Guile compiles to
>> bytecode right now, so it's generally (though not always!) slower than
>> the native-compiling schemes.  But compared to the
>> bytecode-interpreter schemes it's pretty fast.
>
> On reading this, out of interest I wrote a very simple program solving
> primes, using the basic 'seive odd divisors to square root' algorithm.
> I tested guile-2.0, guile-2.2, chicken and chez scheme on it.
>
> guile-2.0 was a little slower than chicken with chicken compiled to C,
> but guile-2.2 on that test took about 75% of the time of chicken, and
> about 50% of the time of guile-2.0.  chez scheme was fastest of all,
> taking about 50% of the time of chicken.  OK, chicken may not be the
> fastest of "compile to C" schemes.

Do I read this correctly that Chez took only about 30% less time than
Guile 2.2?

Could you try stalin, too? (Chez wins 28 comparisons, Stalin 14, so that
would be an obvious target)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile benchmark

[Arne Babenhauserheide]

Chris Vine  writes:
> No, on my Haswell laptop running 64-bit linux, solving the 40,000th
> prime (479909) is 1.26 times faster in chez scheme than in guile-2.1.7,
> on the simple algorithm. (0.509 seconds versus 0.624 seconds, on a
> i7-4712HQ CPU @ 2.30GHz.)  This is only the time taken in the body of
> the calculation.  Start-up times and printing times and so forth are
> ignored.

Ah, ok. Thank you!

> I have just tried out the same code on an older Sandybridge desktop
> @3.30 GHz running 32-bit linux which I can access remotely, and that had
> chez scheme 1.7 times faster than guile-2.1.7 so it looks to be
> somewhat CPU and/or cache and/or pointer-width sensitive. Anyway, it is
> just one benchmark.
>
> I think I am about schemed out so installing Stalin is probably not an
> option.  Like you, I am told it is fast.  Guile's selling point IMO is
> its libraries and its FFI.  Guile 2.2 certainly seems adequately fast
> at run time.  Possibly compile times may be an issue, I don't know.

Factor 10 between C++ and pure Scheme is pretty awesome. Implementing
algorithms in pure Python carries a penalty of easily factor 100 (though
delegating anything expensive to builtin operators is fast).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Guile 2.1.7 released (beta)

[Arne Babenhauserheide]

Andy Wingo  writes:

> On Fri 24 Feb 2017 18:46, Arne Babenhauserheide  writes:
>
>> The main strategical question I see for that is: Does anything make it
>> harder to complete or improve the lilypond transition to Guile 2?
>>
>> Is there something which would need to be done before 2.2 which could
>> make it easier for lilypond developers?
>
> I don't know of any concrete points here.  2.2 is not dissimilar to 2.0.
> If you someone like to try to determine exactly what specific bits of
> Guile 2.2 impact Lilypond (and indeed any big application using the C
> interface), that would be welcome :)  I guess I'd start with NEWS to see
> what's up.

I’ll have to write up my test setup for lilypond, too …

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile 2.1.8 on 9 March / 2.2.0 on 16 March

[Arne Babenhauserheide]

Andy Wingo  writes:

> Finally for the release we should consider publicity -- what do we do?
> Anything special?  Volunteers are welcome here.  The NEWS is quite
> verbose, so condensing it into a set of 5-10 big-ticket items could be
> useful; dunno.

One important point would be to send advance press releases with an
explicit EMBARGO (not to be released before ... = EMBARGOED UNTIL ...)
to many newspapers, including as many as possible in India, china and
any other non-US country with many programmers.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

David Kastrup  writes:

> Nala Ginrut  writes:
>
>> I think we have to elaborate the question clearer.
>>
>> 1. How to make guile-scheme more successful?
>> I think this is similar to ask "how to make scheme more successful".
>> This is the big question to the whole scheme community.
>>
>> 2. How to make guile platform more successful?
>> I this case, let me ask a question, if we have guile-python3
>> (compatible with most of Python3 features), and provide more
>> convenient FFI helper function to help bind more libraries in short
>> time, is it possible to attract more people from Python land? Given
>> we'll have good JIT compiler in the future.
>
> Frankly, I doubt that migration of large Python-based applications is
> going to be a thing when nobody can even be bothered with immersing
> himself in the problems with migrating LilyPond from Guile-1.8 to
> Guile-2.

I worked on testing Lilypond with user installed Guile 2.x, does that
count?

Just to have it recorded somewhere, here’s a patch to lilypond along
with a copy of the bash history of the setup (cleaned up, it was many
times as long):

## patch

From bd2ffea6f4c4c1ede13f5ac82d0a8ce31ccfe3c7 Mon Sep 17 00:00:00 2001
Subject: [PATCH] Build fixes for Guile 2.1.x (not yet functional)

---
 configure.ac | 7 ++-
 lily/pdf-scheme.cc   | 4 
 scm/memory-trace.scm | 3 ++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index d77ea15..393976b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -267,7 +267,12 @@ STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10)
 STEPMAKE_WINDOWS
 
 # guile executable for some scripts
-STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0)
+if test "$GUILEv2" = "yes"
+then
+STEPMAKE_GUILE(OPTIONAL, 2.0.7, 2.2.0)
+else
+STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0)
+fi
 
 # perl for help2man and for mf2pt1.pl
 STEPMAKE_PERL(REQUIRED)
diff --git a/lily/pdf-scheme.cc b/lily/pdf-scheme.cc
index da2ce2c..f5ae70c 100644
--- a/lily/pdf-scheme.cc
+++ b/lily/pdf-scheme.cc
@@ -91,7 +91,11 @@ LY_DEFINE (ly_encode_string_for_pdf, 
"ly:encode-string-for-pdf",
*  (string->utf16 str 'big)
*/
   if (g)
+#if GUILEV2
+return scm_take_locale_stringn (g, bytes_written); // scm_take_str 
eventually frees g!
+#else
 return scm_take_str (g, bytes_written); // scm_take_str eventually frees g!
+#endif
   else
 return str;
 }
diff --git a/scm/memory-trace.scm b/scm/memory-trace.scm
index d8ffeb9..9ebd722 100644
--- a/scm/memory-trace.scm
+++ b/scm/memory-trace.scm
@@ -2,7 +2,8 @@
 
 (define-module (scm memory-trace))
 (use-modules (lily)
- (ice-9 format))
+ (ice-9 format)
+ (ice-9 threads))
 
 (define-public (mtrace:start-trace freq)
   (set! usecond-interval (inexact->exact (/ 100 freq)))
-- 
2.10.2


## bash history

sudo emerge media-fonts/tex-gyre
sudo nano /etc/portage/package.keywords/sonstiges 
sudo emerge media-fonts/tex-gyre
sudo pmerge dblatex
git clone git://git.sv.gnu.org/lilypond.git
cd lilypond/
./autogen.sh --prefix ~/.local --enable-guile2
mkdir -p ~/texmf/lh
cp ~/Downloads/lhfnt35g-source.zip ~/texmf/lh/
unzip lhfnt35g-source.zip 
cd ~/texmf/source/latex/lh
latex lcyfonts.ins 
latex ot2fonts.ins; latex t2ccfonts.ins
ls ~/texmf/examples/
mkdir ~/texmf/lh
cp *sty ~/texmf/lh/
./autogen.sh --prefix ~/.local --enable-guile2
sudo emerge dev-texlive/texlive-langcyrillic
sudo pmerge dev-texlive/texlive-langcyrillic
make out/lilypond-invoke-editor
cd scripts/
/home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor 
--no-discard-stderr
/home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor 
./autogen.sh --prefix ~/.local --enable-guile2
make
LD_LIBRARY_PATH=/home/arne/.local/lib/guile/2.2/ g++ -o out/lilypond  
./out/modified-font-metric.o ./out/sequential-iterator.o 
./out/hara-kiri-group-spanner.o ./out/completion-note-heads-engraver.o 
./out/slur-score-parameters.o ./out/flag.o ./out/span-arpeggio-engraver.o 
./out/beam-quanting.o ./out/dynamic-performer.o ./out/parse-scm.o ./out/tie.o 
./out/bend-engraver.o ./out/staff-spacing.o ./out/rest-collision-engraver.o 
./out/simple-spacer-scheme.o ./out/audio-item.o ./out/pdf-scheme.o 
./out/paper-score.o ./out/slur-configuration.o ./out/constrained-breaking.o 
./out/score-engraver.o ./out/unpure-pure-container.o 
./out/multi-measure-rest-engraver.o ./out/system-start-delimiter-engraver.o 
./out/context-property.o ./out/freetype.o ./out/interval-minefield.o 
./out/kievan-ligature.o ./out/completion-rest-engraver.o 
./out/pure-from-neighbor-engraver.o ./out/horizontal-bracket-engraver.o 
./out/grob-closure.o ./out/default-bar-line-engraver.o 
./out/control-track-performer.o ./out/file-name-map.o ./out/audio-staff.o 
./out/line-spanner.o ./out/grob-info.o ./out/spring.o ./out/slur.o 
./out/music-scheme.o ./out/program-option.o ./out/fretboard-engraver.o 
./out/hyphen-engraver.o ./out/page-marker.o ./out/global-vars.o 
./out/stream-event-scheme.o ./o

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Alejandro Sanchez  writes:

> If I may add my two cents as a Scheme layman: the question is not so much 
> about making Guile more popular, but about making Scheme itself more popular.
>
> One big reason for Python’s popularity is something I haven’t seen
> mentioned in this thread so far: if you know pseudocode you basically
> know Python already. Of course this is hyperbolic, there are a lot of
> finer details to Python, but the superficial simplicity of Python
> makes you think you already know the language and that you can get
> started right away. By the time you encounter the more arcane aspects
> of Python you have already invested enough time into it that you will
> put up with learning something new.

This is basically what wisp¹ is intended to address:

define : hello who
format #t "Hello ~a!\n" who

hello "World"

And it’s still full scheme. Just looking like pseudocode.

I documented that in py2guile: http://draketo.de/py2guile

¹: http://draketo.de/english/wisp

> I think someone here mentioned the lack of a proper Scheme IDE, other
> than Dr. Racket for Racket. I don’t use IDEs anymore, but I can see
> how that can be a problem for other people who only want to do
> intermediate scripting rather than write entire applications.

I also see lots of people at work using Python IDEs, which all bring
their own problems but provide the kind of information I get from the
commandline.

Just having a geiser setup for Emacs properly documented — or maybe an
Emacs customized for Scheme development — would help a lot, I think.

"This is our canonical interface for writing Scheme" ← That is what
people need to be able to find.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Thien-Thi Nguyen  writes:

> () Arne Babenhauserheide 
> () Sun, 05 Mar 2017 01:23:59 +0100
>
>Just having a geiser setup for Emacs properly documented — or
>maybe an Emacs customized for Scheme development — would help
>a lot, I think.
>
> Could you please summarize (or point to a summary of) Geiser
> documentation deficiencies?

I can’t just say "give me the canonical Guile development environment"
and have that work without any additional setup needed from me. This is
not about the documentation of Geiser itself but rather about the
documentation of "how to make Emacs the best tool for hacking Scheme".

The following contains user experience questions of coming to
geiser. These will sound unfair, because they assume a user who did not
read any documentation and just wants to work on a Scheme file given to
him/her by a co-worker, likely with a sentence like "here’s the file,
you’ll need to adapt it for your usecase".

This is how I come to geiser:


First I use M-x package-list-packages to find and install geiser (Why is
geiser not shipped with Emacs (like org-mode)?).

Then I open a Scheme file, then I type M-x geiser followed by guile (why
doesn’t geiser start by default? Why do I have to know that the best way
to write scheme is called geiser?).

Finally I add M-x geiser-mode in the file (why does this not happen
automatically? — or: why is there no information in the REPL that I can
do so?).


Now I have a Geiser repl and a function tool tip in the echo area.

Is this the canonical setup people use? What else is there I do not get
right away? From the IDEs co-workers use I know display of local
variables (and their values). And warnings and errors shown in the
fringe (I get that in Python with flycheck mode). Is this also provided
by geiser (maybe harnessing some other tool)?


Best wishes,
Arne


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Erik Edrosa  writes:

> I think one issue when you want to compare languages like Python to
> Scheme is that these languages are dominated by a single
> implementation.

I read this argument repeatedly, but it does not apply to C and C++, two
of the most widely used languages. Therefore that argument might just
interpret too much into a coincidence — or rather: into a situation
which happens in the beginning of language development.

Even Java nowadays has several different implementations.

> Of course that isn't the only thing needed to make Scheme or Guile more
> popular. I believe a programming language needs a somewhat unique and
> powerful library or framework

From what I know, that’s what ruby had: many people wanted to use rails
and after they already knew ruby well, they also used it for other
tasks.

For Python I’m not sure.

Java had that big company behind it, which marketed it as the best
choice for companies.

> an awesome application to show off the
> power of the language, good tooling, and some luck.

And zealots, never forget zealots. I’d dare to say that people, who
believe that the language or tool is the best thing in existence and
give lots of talks about it, are a far too easily underestimated factor
in the success of any tool.

Best wishes,
Arne


signature.asc
Description: PGP signature

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Alejandro Sanchez writes:

> Thank you for you responses, I will try to respond to them all in one email.
>
>
>> About Emacs + Geiser as the default development environment
> Emacs is a power tool. Giving someone Emacs to write a simple script is like 
> handing someone a jackhammer to nail plywood together. OK, maybe I’m 
> stretching the analogy a bit, but when I think IDE I imagine something that 
> handholds people, for the better or worse. Sure, you could offer some sort of 
> pre-configured Emacs setup, but what’s the point of that?

The point of that is that every developer starts by doing small
things. Therefore the small startup things should work well.

I know many people at work who’ve been using Emacs for years but mostly
limit their use to what it provides by default.

What works well from the start is where most people will stay. And
that’s not unreasonable: If it doesn’t work now, how are the chances
that it will be better than something which works well right away?

>> About the syntax
> I know about wisp, but that looks like an awkward cross-breed between Python 
> and Lisp. Lisp syntax is simply something one needs to get over. For me it 
> really clicked when I understood that Lisp syntax is not really a syntax, 
> it’s the AST (sort of). Wisp reminds me of those people who use the arrow 
> keys Vim and never leave insert-mode, in the end they just have a convoluted 
> Nano. Maybe Wisp will help people, I don’t know, but it didn’t do anything 
> for me.

The difference to vim in insert mode is that wisp provides all features
of scheme. The opening and closing parens just look different :)

(or rather: they are merged into the existing indentation, so this
reduces duplication of information)

>> Closing remark
> The question for someone shopping around for languages is: what is the 
> selling point for Guile (or Scheme)? Being a programmable programming 
> language sounds cool, but what does it let me do? Nothing on Guile's website 
> tells me “look at how easy this is to solve in Guile, you cannot do this in 
> other languages”. What would that be? I don’t know, I’m just a layman. The 
> topic of the thread is “how to make Guile more successful”, and I most of 
> those are technical points, so I’m afraid that discussing popularity is all I 
> can contribute.

You can for example build wisp ;)

And "natural script writing" would have been much harder (and much more
mechanical work) in other languages. In most languages it would have
required parsing the text by hand and explicitly extracting code and
handing it to some function to execute it.

Best wishes,
Arne

Re: How to make GNU Guile more successful

[Arne Babenhauserheide]

Vítor De Araújo writes:

> (Or maybe package _names_ could be URLs pointing to an index in a
> well-defined format, which tells how to download each version of a
> package; then we could have even dependency management without a
> central repository. I'm pipe-dreaming here, though.)

You’re not just dreaming:

https://github.com/plande/compan/blob/master/compan.scm

;; clone the repository and load (lib) module from the top level:
(load-modules ("https://bitbucket.org/panicz/dogma"; (lib)))

;; as above, but load modules from "libraries" directory:
(load-modules (("https://github.com/panicz/pamphlet"; "libraries") 
(pamphlet)))

;; one can also fix on a particular tag/branch/commit:
(load-modules (("https://bitbucket.org/panicz/dogma"; "." "3884445191c2") 
(lib)))

We’d just have to decide to use this.

Best wishes,
Arne
-- 
Sent with my mu4e

Re: Guile foreign object interface

[Arne Babenhauserheide]

David Kastrup writes:

> To a certain degree one can chalk this off as "growing pains" that
> long-standing users have to shoulder, at least when working with
> development rather than stable versions.

I’d like to chime in here. When looking at the prospects of larger Guile
adoption, I think that Lilypond is a critical component: It is an early
adopter and the absolute top tool in the niche it took.

People thinking about adopting Guile will ask themselves "is this a
viable longterm option?". They will then look at Lilypond, the prime
example of a highly successful Guile-using tool.

So this is not just a growing pain for Lilypond. It is a critical issue
for Guile.

Both communities, Lilypond and Guile, need Lilypond-Guile2 to work well.

And given the speed I see from Guile 2.1.7 at other tasks, there should
be ways to make Lilypond-Guile2.2 outperform Lilypond-Guile1.8
significantly.

Best wishes,
Arne

PS: Just saying "it’s a scripting language now" will not cut it. People
who adopt Guile now will have to ask whether it will stay a viable
option as scripting language, and they will again look at Lilypond
to see whether Guile-as-an-option kept its promises.

Re: Guile foreign object interface

[Arne Babenhauserheide]

David Kastrup  writes:

> Arne Babenhauserheide  writes:
>> PS: Just saying "it’s a scripting language now" will not cut it.
>
> With an implied "rather than an extension language": that _would_ cut
> it.  It would imply LilyPond having to work with a fork of Guile-1.8,
> and possibly encourage active maintenance of such a fork independently
> of LilyPond.  It would also put a clear perspective on Emacs-Guile's
> future, namely none.

It would also show that Guile leaves people behind who choose it. Yes,
it would be a strategy, but not one which inspires much confidence in
the longterm stability of its goals.

>> People who adopt Guile now will have to ask whether it will stay a
>> viable option as scripting language, and they will again look at
>> Lilypond to see whether Guile-as-an-option kept its promises.
>
> Well, Guile is not an "option" in LilyPond,

I did not mean it as option in Lilypond. I meant it as strategic
possibility.

> and it is clearly more than just an extension language (as I believe
> it is designed to be in GnuCash).  It's more like its programming
> paradigm.  The C++ part is structured to fit in with Guile.  But this
> sort of 1:1 relation is much more tenuous with Guile-2 since the
> interaction costs have become quite larger.  So it works better for
> either applications that have just a little Guile, or for applications
> that have little else.

I hope that will change again. I’m sure most people here want Lilypond
to be faster with Guile 2.x than with Guile 1.8.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile foreign object interface

[Arne Babenhauserheide]

David Kastrup  writes:

>> I did not mean it as option in Lilypond. I meant it as strategic
>> possibility.
>
> As I see it, it's not big enough that strategic guarantees can be given.
> If you need guarantees, you need to invest into the resources needed for
> that.

Using "The official GNU extension language" is typically pretty safe,
since GNU libraries tend to live and stay stable longer than the typical
middle size company.

>> I hope that will change again. I’m sure most people here want Lilypond
>> to be faster with Guile 2.x than with Guile 1.8.
>
> Where is "here"?  It would look better, for sure.

Here is the Guile community.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature