Re: guile-user Digest, Vol 171, Issue 14

[Amirouche <amirouche@hypermove.net>]

Le 14/02/2017 à 18:24, Cecil McGregor a écrit :
> As a relative noobie to Guile I have some grievances
> with Guile. I started to use it for awhile, get frustrated
> and go away, and then, eventually, come back.
>
> My first problem lies in the lack of a decent debugger.
> (I can hear the screams of more enlightened Guilers
> already!) The stack traces seldom provide filenames
> and line numbers to hint where a problem might hide.
> While I've read advice to allow the appearance of
> filenames/line numbers, I still can't seem to
> consistently find these in a stack trace.
>
> I would really like the filename/line number to appear
> in a stack trace with the actual source code and not
> some partially opaque macro expansion.
>
> Then there is the matter of a good code coverage
> tool. Having experienced the benefits of TDD, Test
> Driven Development, I insist on good coverage
> when I develop in NodeJS and python. I really
> need to know that all my code has been tested.
>
> Imagine the obstacle a noobie faces as they
> begin learning Guile and they have problems with
> debugging and they can't be sure that all their
> code has been tested. Yes, they can insert
> print statements everywhere, but at what cost?
> When they revisit code at a later date, do they
> re-insert print statements to demonstrate the
> effectiveness of code?
>
> I remember once getting irritated with Guile
> because some system code was displaying
> a long stack trace for some reason. I spent
> about half a day mucking about before
> deciding my time was more valuable elsewhere.
>
> Has anyone followed up on the SICP classes
> and asked why scheme was not more popular?
> Was it so unpopular that the students took up
> C/C++/Java instead? SICP uses a "portable"
> form of Scheme that apparently works with
> almost any Scheme implementation. SICP
> doesn't deal with messy system issues or
> implementing larger projects. Small programs
> such as SICP offers does not require serious
> debugging. As programs become systems
> the necessity of serious debugging rears
> an ugly side.
>
> Debugging and TDD become critical when/if
> Guile gets used with larger groups. A decent
> debugger provides an ideal environment to
> assist in understanding code. Step through
> with various cases and your understanding
> increases. Use TDD and examine the coverage.
>
> Ease of use with a decent debugger significantly
> reduces friction in learning and using a language.
>
> (Yes, there are holes and exceptions in the above.
> Flames to /dev/null.)
>
>
>
>
>
> On Tue, Feb 14, 2017 at 5:11 AM, <guile-user-request@gnu.org> wrote:
>
>> Send guile-user mailing list submissions to
>>          guile-user@gnu.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>          https://lists.gnu.org/mailman/listinfo/guile-user
>> or, via email, send a message with subject or body 'help' to
>>          guile-user-request@gnu.org
>>
>> You can reach the person managing the list at
>>          guile-user-owner@gnu.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of guile-user digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Re: How to make GNU Guile more successful (Marko Rauhamaa)
>>     2. Re: How to make GNU Guile more successful (Panicz Maciej Godek)
>>     3. Help formatting a UTC Timestamp (Guy Baumann)
>>     4. Re: Help formatting a UTC Timestamp (tomas@tuxteam.de)
>>     5. Re: Help formatting a UTC Timestamp (Chris Vine)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 14 Feb 2017 07:59:07 +0200
>> From: Marko Rauhamaa <marko@pacujo.net>
>> To: Arne Babenhauserheide <arne_bab@web.de>
>> Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,
>>          "guile-user\@gnu.org" <guile-user@gnu.org>
>> Subject: Re: How to make GNU Guile more successful
>> Message-ID: <87zihp48k4.fsf@elektro.pacujo.net>
>> Content-Type: text/plain; charset=utf-8
>>
>> Arne Babenhauserheide <arne_bab@web.de>:
>>
>>> Marko Rauhamaa <marko@pacujo.net> 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)
>>
>>> 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).
>>
>> 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!"
>>
>>>> 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.
>>
>>> Decorators are really cool to use:
>> Have yet to find a need for one.
>>
>>>> dunder jungle,
>>> What?s that?
>> <URL: https://docs.python.org/3/genindex-_.html>
>>
>>>> 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.
>>
>>>> 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 Linux, all pathnames, files, sockets, environment variables and
>> command-line arguments are, or deal with, bytes. The bytes are often
>> encoded with UTF-8, but a programming language cannot assume that, even
>> if LOCALE promises otherwise.
>>
>> It would be better to leave Unicode out of Guile's system interface and
>> have the application encode and decode explicitly where needed.
>>
>>>> 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?
>> For example tcgetattr(3). (Ok, not a system call.)
>>
>> Missing epoll(2) is inconvenient. Not being able to transfer an open
>> file descriptor via sendmsg(2) is really bad.
>>
>>
>> Marko
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 14 Feb 2017 10:54:38 +0100
>> From: Panicz Maciej Godek <godek.maciek@gmail.com>
>> To: Arne Babenhauserheide <arne_bab@web.de>
>> Cc: Amirouche <amirouche@hypermove.net>,        "guile-user@gnu.org"
>>          <guile-user@gnu.org>
>> Subject: Re: How to make GNU Guile more successful
>> Message-ID:
>>          <CAMFYt2YcX1vT6hznAMnnDF3gM9rmz465JauyBeaw7SxFRJKr5w@mail.
>> gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 2017-02-13 23:54 GMT+01:00 Arne Babenhauserheide <arne_bab@web.de>:
>>
>>> Panicz Maciej Godek <godek.maciek@gmail.com> writes:
>>>
>>>> 2017-02-13 12:06 GMT+01:00 Arne Babenhauserheide <arne_bab@web.de>:
>>>> 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.
>>>
>>>
>> 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)
>>
>>> 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
>>
>>
>>> 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
>>
>>
>>> 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)
>>
>>
>>>> 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")
>>
>>
>>> 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.
>>>
>>> Do you have ideas for principles which could be shared by most Schemers?
>>>
>>>
>> It depends on the most Schemers, not me :)
>> However, you can have a look at the (grand scheme) glossary that I've been
>> maintaining for some time:
>>
>> https://github.com/plande/grand-scheme
>>
>> of course, the intent is to make the glossary usable for someone else than
>> me,
>> and I can boast that I have at least one user distinct from the maintainer.
>> You can have a look and let me know what you think. (for now it only works
>> with Guile). In particular, are there any factors that could convince you
>> to
>> adapt it as a base for your library, or what would you want changed
>> (I assume you won't stop at the README file).
>> Anyways, the rules (of thumb) are:
>>
>>
>>     - functions should be pure
>>     - language constructs that cause side-effects should be encapsulated
>>     with macros that limit the extent of those side-effects
>>     - if possible, use the quasiquote macro, rather than cons, append or
>> list
>>     - prefer the use of match <http://synthcode.com/scheme/match.scm> to
>> cond,
>>     if the patterns are simple
>>     - never use abbreviations
>>     - use commented prepositions to separate arguments
>>
>> Also, I recently added infix syntax to Scheme, but (unlike in Racket or
>> David Wheeler's solutions) in the way it is still a prefix syntax. So for
>> example,
>> instead of writing (< a b), one ought to write (is a < b). The rationale is
>> that
>> prefix notation is terrible for non-symmetrical binary predicates, because
>> it
>> obscures the roles of respective arguments (in addition, (is a < b <= c)
>> expands
>> to (and (< a b) (<= b c))). I'm still not sure whether it is a good idea,
>> but I have
>> no reasons to think that it is bad either :]
>> [Curiously enough, I think that prefix notation in arithmetic is just fine:
>> (+ a b c) reads as "sum of a, b and c"]
>>
>>> Also, I think that the astounding success of R provides hints with
>>>> regard what is needed for a programming language to gain popularity. R
>>>> has a large repository of packages that fills a certain niche. When I
>>>> advertised my Pamphlet on Hacker News, someone responded critically:
>>>> "are there out of the box libraries to estimate a zero inflated
>>>> negative binomial regression model in guile". Of course, if I knew
>>>> what a zero-inflated negative binomial regression model, I could
>>>> deliver an implementation by just explaining the notions used in that
>>>> phrase.
>>> I think there?s a quote which applies here: "Most people only use 20% of
>>> the capabilities of any program, but they do not use the same 20%."
>>> ? Joel Spolksy, if I remember correctly.
>>>
>>> And to make people really dig into it, a programming language must work
>>> well for all tasks they might encounter. That?s why a comprehensive
>>> standard library is important: It gives the assurance that the skills
>>> you learn will stay useful wherever you go.
>>>
>>> There?s a nice quote from Rust folks: "people started to feel safe when
>>> we told them about unsafe" ? someone on GNU social.
>>> This essentially says: they then saw that Rust could work in the
>>> uncomfortable way some of their tasks might require. That they could
>>> take it into harsher territory, if needed.
>>>
>>> I like it that you and Amirouche look a lot at the sociocultural
>> perspective
>> of programming
>>
>>
>>>> (But then again, I try to write functional programs whenever
>>>> possible, often consciously sacrificing time complexity of my
>>>> solutions, and I'm aware that not everybody will like it.)
>>> I look for ease of understanding, with functional programming techniques
>>> being a useful tool to reduce complexity and to simplify refactoring.
>>>
>>> But then, this is a point where we actually move into a similar
>>> direction out of different motives. I think the only problem here is the
>>> danger of assuming contradiction where there does not need to be
>>> any. Just different nuances of Zen :)
>>>
>>> Yes, to me the ease of understanding is also crucial. (I'd even go
>> further and say that undestranding is the very point of programming)
>>
>> Best regards,
>> Panicz
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 14 Feb 2017 12:27:16 +0000
>> From: Guy Baumann <guy@gammarus.co.uk>
>> To: guile-user@gnu.org
>> Subject: Help formatting a UTC Timestamp
>> Message-ID: <20170214122716.GA2454@debian>
>> Content-Type: text/plain; charset=us-ascii
>>
>> I am trying to format a timestamp from an api. It is sent in the
>>   format "2011-03-24T20:30:47Z"
>>
>> what I want to output is something like this
>> (strftime "%d %b %g " (localtime (current-time)) )
>>
>> However I am unable to work out how to do this, have tried using
>>   string->date with results below
>>
>> Enter `,help' for help.
>> scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>> scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>> bad-date-format-string: "2011-03-24T20:30:47Z"
>>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]> (string->date date "~Y-m-dT~H:~M:SZ")
>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>> bad-date-format-string: "~Y-m-dT~H:~M:SZ"
>>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [2]> (string->date date "~Y-m-dT~H:~M:SZ")
>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>> bad-date-format-string: "~Y-m-dT~H:~M:SZ"
>>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [3]> (string->date "2000" "~Y")
>> srfi/srfi-19.scm:571:22: In procedure encode-julian-day-number:
>> srfi/srfi-19.scm:571:22: In procedure -: Wrong type: #f
>>
>> thanks for any help
>>
>> //guy
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 14 Feb 2017 13:48:51 +0100
>> From: <tomas@tuxteam.de>
>> To: guile-user@gnu.org
>> Subject: Re: Help formatting a UTC Timestamp
>> Message-ID: <20170214124851.GB14935@tuxteam.de>
>> Content-Type: text/plain; charset=utf-8; x-action=pgp-signed
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Tue, Feb 14, 2017 at 12:27:16PM +0000, Guy Baumann wrote:
>>> I am trying to format a timestamp from an api. It is sent in the
>>>   format "2011-03-24T20:30:47Z"
>>>
>>> what I want to output is something like this
>>> (strftime "%d %b %g " (localtime (current-time)) )
>>>
>>> However I am unable to work out how to do this, have tried using
>>>   string->date with results below
>>>
>>> Enter `,help' for help.
>>> scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
>>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>>> scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
>>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>> bad-date-format-string: "2011-03-24T20:30:47Z"
>>
>> You got the args reversed: it's first the date string, then the
>> template. Besides, you forgot a couple of tildes in your template
>> (e.g. it's "~m" and not just "m" and so on). Lastly, the template
>> for the zone offset is "~z" (a small z). The "big Z" in your input
>> string is just a concrete zone (afaik UTC).
>>
>> This works:
>>
>>    scheme@(guile-user)> (define mydate "2011-03-24T20:30:47Z")
>>    scheme@(guile-user)> (string->date mydate "~Y-~m-~dT~H:~M:~S~z")
>>    $3 = #<date nanosecond: 0 second: 47 minute: 30 hour: 20 day: 24 month:
>> 3 year: 2011 zone-offset: 0>
>>
>> hth
>> - -- t
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>>
>> iEYEARECAAYFAlii/LMACgkQBcgs9XrR2kbySACfY3yqQgFw4XWIBZo1Nif8exJ1
>> jwUAn04XBldYBIWDDhheEjI1nLbFbjhm
>> =MJ3B
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 14 Feb 2017 13:11:07 +0000
>> From: Chris Vine <chris@cvine.freeserve.co.uk>
>> To: Guy Baumann <guy@gammarus.co.uk>
>> Cc: guile-user@gnu.org
>> Subject: Re: Help formatting a UTC Timestamp
>> Message-ID: <20170214131107.7cd4c42b@bother.homenet>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> On Tue, 14 Feb 2017 12:27:16 +0000
>> Guy Baumann <guy@gammarus.co.uk> wrote:
>>> I am trying to format a timestamp from an api. It is sent in the
>>>   format "2011-03-24T20:30:47Z"
>>>
>>> what I want to output is something like this
>>> (strftime "%d %b %g " (localtime (current-time)) )
>>>
>>> However I am unable to work out how to do this, have tried using
>>>   string->date with results below
>>>
>>> Enter `,help' for help.
>>> scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
>>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>>> scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
>>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>>> bad-date-format-string: "2011-03-24T20:30:47Z"
>>>
>>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>>> scheme@(guile-user) [1]> (string->date date "~Y-m-dT~H:~M:SZ")
>>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>>> bad-date-format-string: "~Y-m-dT~H:~M:SZ"
>>>
>>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>>> scheme@(guile-user) [2]> (string->date date "~Y-m-dT~H:~M:SZ")
>>> srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
>>> srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
>>> bad-date-format-string: "~Y-m-dT~H:~M:SZ"
>>>
>>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>>> scheme@(guile-user) [3]> (string->date "2000" "~Y")
>>> srfi/srfi-19.scm:571:22: In procedure encode-julian-day-number:
>>> srfi/srfi-19.scm:571:22: In procedure -: Wrong type: #f
>> You haven't got the escapes quite right.  This will work:
>>
>>    (string->date date "~Y-~m-~dT~H:~M:~SZ")
>>
>> As will this with skipping, given that your example uses numeric values:
>>
>>    (string->date date "~Y~m~dT~H~M~SZ")
>>
>> Chris
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> guile-user mailing list
>> guile-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/guile-user
>>
>>
>> ------------------------------
>>
>> End of guile-user Digest, Vol 171, Issue 14
>> *******************************************
>>

I understand your struggle but I can't make work what supposed to work 
regarding ,break and ,break-at-source meta commands in guile 2.1 and 2.2 
REPL.

Regarding, code coverage I know there is a project that use it on github 
but I don't recall which one.

Otherwise I find that guile works. I created my "own" test macro and 
debug mostly using `pk` procedure. I recognize that coverage helps, but 
at the end of the day, I try to keep the number tests to the minimum 
because I find it boring.

I disagree with the paragraph about guile being only a theorical 
language to teach the basic of programming theory. It's used to be a 
teaching language for good reason and that code still works.

I agree that most of my daily work is about composing libraries, tho... 
I do the exact same thing in Guile except it's a different topics, hence 
different bugs.