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

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

[Cecil McGregor]

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
> *******************************************
>

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

[Christopher Allan Webber]

Cecil McGregor writes:

> 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.

Usually I find the debugger to be quite good in giving exactly the right
line, so your experience doesn't match mine.  I've also found that it
provides quite a few tools that I haven't found much anywhere else; the
debugging trap infrastructure and etc are a dream to work with.
(Sometimes some lines are lost in the call stack though due to Guile's
compiler's optimizing code... I hear that can be disabled but I haven't
tried it.)

> 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.

Good news, Guile includes a testing module.  It could be better
integrated, and guile-lib apparently includes extendsions, but I unit
test my Guile libraries / programs.

> 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.

SICP's goal is to teach you how to understand the foundations of
computer science, not as much to write code as you would in
"production".

And in fact the best reason why SICP hasn't turned into real world
production programmers probably comes from one of the co-authors, Gerald
Sussman (or a relayed anecdote), on why MIT moved away from SICP as its
core book:

  https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

In short, the world has shifted to one where understanding computer
science fundamentals is less critical to getting code out the door than
to understand how to hook together a large set of prebuilt libraries.  I
would say for the first decade of my programming career, this is how I
programmed, and I did fine.  Python has so many of the tools you want
and you can just hook them together like legos, and it's a delight.

SICP still provides something valuable though.  Joining the Guile
community and reading SICP and other lispy books like The Little Schemer
have transformed me as a programmer.  Not everyone needs to do it, but
there you go.  I think we should have more introductory resources that
aren't as CS theory based, but SICP deserves the love it gets.

There's much that we can learn from Python and etc, and I think many of
us want to allow Guile to fill that role too.  Anyone who was there for
FOSDEM this (or last!) year knows what an energized group of people
constitutes this community and how much we want to improve it.

> (Yes, there are holes and exceptions in the above.  Flames to
> /dev/null.)

TBH, I found your post to be a bit flamey and combative itself, which is
unfortunate, and I know it bummed some others out too.  Maybe you did
not mean it that way, but there it goes.  Keep in mind that a lot of
people on this list care about Guile a lot, and in my experience are
extremely open to constructive criticism.  But let's keep it
constructive and positive.  We want to make Guile better and too much
negative energy can make that hard.

Indeed, if you pay close attention to Guile over the last couple of
years, I would say that it *has* been getting better by leaps and
bounds.  There's still much of ways to go!  But if we can stay
energized, we can get there.

Stay positive, and let's build Guile into something great!
 - Chris

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

[Amirouche]

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.

Stack traces

[Ludovic Courtès]

Hello,

Cecil McGregor <trailingdots@gmail.com> skribis:

> 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.

Could you mock up the stack trace as you would like to see it displayed?

I think it would be helpful because what you write here is a common
complaint, but it’s also something that seasoned Guilers no longer
realize because they’re used to it.  So a fresh eye on what it should
look like is great.

There are also deeper technical issues, such as tail calls, but we can
put them aside for now.

Thanks,
Ludo’.

Re: Stack traces

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hello,
>
> Cecil McGregor <trailingdots@gmail.com> skribis:
>
>> 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.
>
> Could you mock up the stack trace as you would like to see it displayed?
>
> I think it would be helpful because what you write here is a common
> complaint, but it’s also something that seasoned Guilers no longer
> realize because they’re used to it.  So a fresh eye on what it should
> look like is great.
>
> There are also deeper technical issues, such as tail calls, but we can
> put them aside for now.
>
> Thanks,
> Ludo’.

One thing that we see requested a lot is how to do the equivalent of:

  import pdb
  pdb.set_trace()

in python, just dumping something to "trigger" the debugger somewhere.
I seem to remember getting some arcane code to do something similar, but
maybe we can just have a simple invocation that people could put
anywhere.  (Amirouche has been raising this one also I think.)

Re: Stack traces

[Matt Wette]

> On Feb 15, 2017, at 7:36 AM, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
> 
> One thing that we see requested a lot is how to do the equivalent of:
> 
>  import pdb
>  pdb.set_trace()
> 
> in python, just dumping something to "trigger" the debugger somewhere.
> I seem to remember getting some arcane code to do something similar, but
> maybe we can just have a simple invocation that people could put
> anywhere.  (Amirouche has been raising this one also I think.)
> 

^^^This is exactly what I yearn for.  I asked about this before and got the following hint, but could not get anything to work.



(use-modules (system repl repl))
(Use-modules (system repl debug))
...
(start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t))

Re: Stack traces

[Matt Wette]

> On Feb 15, 2017, at 7:36 AM, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
> 
> One thing that we see requested a lot is how to do the equivalent of:
> 
>  import pdb
>  pdb.set_trace()
> 
> in python, just dumping something to "trigger" the debugger somewhere.
> I seem to remember getting some arcane code to do something similar, but
> maybe we can just have a simple invocation that people could put
> anywhere.  (Amirouche has been raising this one also I think.)
> 

I am playing with this.  It does dump me into the debugger but the interaction is not wonderful (like pdb.set_trace()). 
However, this is context for working in that direction (i.e., pdb.set_trace()):

mwette$ cat trapper.scm 
(use-modules (system repl repl))
(use-modules (system repl debug))

(define-syntax-rule (trap-here)
  (start-repl
   #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))

(define (foo)
  (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
    (trap-here)
    (if (null? vals) sum
	(iter (+ sum (car vals)) (cdr vals)))))

(foo)

mwette$ guile
GNU Guile 2.0.13
[…]
scheme@(guile-user)> (load "trapper.scm")
[…]
scheme@(guile-user) [1]> ,bt
[…]
In /Users/mwette/proj/scheme/myproj/potluck/trapper.scm:
     10:4  1 (foo)
In unknown file:
           0 (make-stack #t)
scheme@(guile-user) [1]> 

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 01:13, Matt Wette a écrit :
> (use-modules (system repl repl))
> (use-modules (system repl debug))
>
> (define-syntax-rule (trap-here)
>    (start-repl
>     #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>
> (define (foo)
>    (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>      (trap-here)
>      (if (null? vals) sum
> 	(iter (+ sum (car vals)) (cdr vals)))))
>
> (foo)
It looks like that. Except `iter` should be defined in the namespace of 
the REPL.

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 16:50, Amirouche a écrit :
>
>
> Le 18/02/2017 à 01:13, Matt Wette a écrit :
>> (use-modules (system repl repl))
>> (use-modules (system repl debug))
>>
>> (define-syntax-rule (trap-here)
>>    (start-repl
>>     #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>>
>> (define (foo)
>>    (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>>      (trap-here)
>>      (if (null? vals) sum
>>     (iter (+ sum (car vals)) (cdr vals)))))
>>
>> (foo)
> It looks like that. Except `iter` should be defined in the namespace 
> of the REPL.
>


Maybe iter is complicated, but at least sum and vals.

Re: Stack traces

[Matt Wette]

> On Feb 18, 2017, at 7:53 AM, Amirouche <amirouche@hypermove.net> wrote:
> Le 18/02/2017 à 16:50, Amirouche a écrit :
>> Le 18/02/2017 à 01:13, Matt Wette a écrit :
>>> (use-modules (system repl repl))
>>> (use-modules (system repl debug))
>>> 
>>> (define-syntax-rule (trap-here)
>>>   (start-repl
>>>    #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>>> 
>>> (define (foo)
>>>   (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>>>     (trap-here)
>>>     (if (null? vals) sum
>>>    (iter (+ sum (car vals)) (cdr vals)))))
>>> 
>>> (foo)
>> It looks like that. Except `iter` should be defined in the namespace of the REPL.
> Maybe iter is complicated, but at least sum and vals.

Hmm.   The procedure “foo” without the "(trap-here)” is just a simple program (using named let) that I want to debug. 
So I add the “(trap-here)” to get into the debugger at that spot in the program, like I would add “pdb.set_trace()” in python.

Matt

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 17:58, Matt Wette a écrit :
>> On Feb 18, 2017, at 7:53 AM, Amirouche <amirouche@hypermove.net> wrote:
>> Le 18/02/2017 à 16:50, Amirouche a écrit :
>>> Le 18/02/2017 à 01:13, Matt Wette a écrit :
>>>> (use-modules (system repl repl))
>>>> (use-modules (system repl debug))
>>>>
>>>> (define-syntax-rule (trap-here)
>>>>    (start-repl
>>>>     #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>>>>
>>>> (define (foo)
>>>>    (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>>>>      (trap-here)
>>>>      (if (null? vals) sum
>>>>     (iter (+ sum (car vals)) (cdr vals)))))
>>>>
>>>> (foo)
>>> It looks like that. Except `iter` should be defined in the namespace of the REPL.
>> Maybe iter is complicated, but at least sum and vals.
> Hmm.   The procedure “foo” without the "(trap-here)” is just a simple program (using named let) that I want to debug.
> So I add the “(trap-here)” to get into the debugger at that spot in the program, like I would add “pdb.set_trace()” in python.
>
> Matt
>

How do you access variables in the REPL?

Re: Stack traces

[Matt Wette]

> On Feb 18, 2017, at 11:59 AM, Amirouche <amirouche@hypermove.net> wrote:
> How do you access variables in the REPL?

To be determined.  Just starting, and I’m guessing this part is going to be nontrivial: some may optimized away, some (e.g., those set!) are boxed, etc.

Re: Stack traces

[Andy Wingo]

On Sat 18 Feb 2017 20:59, Amirouche <amirouche@hypermove.net> writes:

> How do you access variables in the REPL?

,locals

Andy

Re: Stack traces

[Amirouche]

Le 27/02/2017 à 21:23, Andy Wingo a écrit :
> On Sat 18 Feb 2017 20:59, Amirouche <amirouche@hypermove.net> writes:
>
>> How do you access variables in the REPL?
> ,locals
>
> Andy
It doesn't display something that I can use.

Re: Stack traces

[Christopher Allan Webber]

Amirouche writes:

> Le 27/02/2017 à 21:23, Andy Wingo a écrit :
>> On Sat 18 Feb 2017 20:59, Amirouche <amirouche@hypermove.net> writes:
>>
>>> How do you access variables in the REPL?
>> ,locals
>>
>> Andy
> It doesn't display something that I can use.

(Returning to this few-months-old thread...)

Yes, I frequently find that ,locals does not display much
information... it seems to be a toss-up whether the variables I need
will be contained in it, so I've reduced the amount I use the actual
debugger system in Guile a lot.  A shame, because it seems really nice.

Because of this, I think I do what a lot of Guile hackers do (which is
totally undocumented in the manual, so only people who have been hanging
around with someoen else who knows tend to know about it), which is to
use (pk) everywhere.  It's not as nice as being able to play with local
variables at the REPL though!

Matt's example from earlier in the thread seems simple enough... as a
recap:

(use-modules (system repl repl))
(use-modules (system repl debug))

(define-syntax-rule (trap-here)
  (start-repl
   #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))

(define (foo)
  (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
    (trap-here)
    (if (null? vals) sum
	(iter (+ sum (car vals)) (cdr vals)))))

(foo)

Looking at that, I would *think* that at minimum, sum and vals would be
available when I run ,locals.  I couldn't understand why they weren't:

scheme@(guile-user)> (foo)
scheme@(guile-user) [1]> ,locals
  No local variables.

But then I ran ,optimize, and that made it obvious what's happening:

(define (foo)
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  (start-repl
    #:debug
    (make-debug
      (stack->vector (make-stack #t))
      0
      "trap!"
      #t))
  21)

Ah... the compiler was being so smart that it did all the work up front
already! ;) Pretty cool from a performance and optimization perspective
(I'm still floored that Guile is able to do optimizations like that!),
but it's not as helpful from a debugging perspective maybe?

Maybe there could be a way to do something like this:

scheme@(guile-user)> ,optimize-less
;;; * user re-evaluates code they want to debug *
scheme@(guile-user)> (foo)
scheme@(guile-user) [1]> ,locals
  Local variables:
  $23 = sum = 0
  $24 = vals = '(1 2 3 5 8 2)
scheme@(guile-user) [1]> ,q
;;; User has done debugging
scheme@(guile-user)> ,optimize-more
;;; User can now re-evaluate their code with all the optimizations in
;;; place!
scheme@(guile-user)>

Thoughts?
 - Chris

Re: Stack traces

[Matt Wette]

> On May 18, 2017, at 6:38 AM, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
> 
> Amirouche writes:
> 
>> Le 27/02/2017 à 21:23, Andy Wingo a écrit :
>>> On Sat 18 Feb 2017 20:59, Amirouche <amirouche@hypermove.net> writes:
>>> 
>>>> How do you access variables in the REPL?
>>> ,locals
>>> 
>>> Andy
>> It doesn't display something that I can use.
> 
> (Returning to this few-months-old thread...)
> 
> Yes, I frequently find that ,locals does not display much
> information... it seems to be a toss-up whether the variables I need
> will be contained in it, so I've reduced the amount I use the actual
> debugger system in Guile a lot.  A shame, because it seems really nice.
> 
> Because of this, I think I do what a lot of Guile hackers do (which is
> totally undocumented in the manual, so only people who have been hanging
> around with someoen else who knows tend to know about it), which is to
> use (pk) everywhere.  It's not as nice as being able to play with local
> variables at the REPL though!

> But then I ran ,optimize, and that made it obvious what's happening:
> 
> (define (foo)
>  (start-repl
>    #:debug
>    (make-debug
>      (stack->vector (make-stack #t))
>      0
>      "trap!"
>      #t))
>  (start-repl

Thanks for the insight.  That explains a lot.

Matt

Re: Stack traces

[Andy Wingo]

On Thu 18 May 2017 15:38, Christopher Allan Webber <cwebber@dustycloud.org> writes:

> I frequently find that ,locals does not display much information... it
> seems to be a toss-up whether the variables I need will be contained
> in it, so I've reduced the amount I use the actual debugger system in
> Guile a lot.  A shame, because it seems really nice.

This is related to the "basic register allocation" task from
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks.

> But then I ran ,optimize, and that made it obvious what's happening:

Ah, yes you might also have to disable partial evaluation.  Note that
,optimize basically runs only partial evaluation and not the other
phases of the compiler.

> scheme@(guile-user)> ,optimize-less
> scheme@(guile-user)> ,optimize-more

Not a bad idea :)  Probably should use the same mechanism as "guild
compile"'s -O0, -O1, -O2 etc logic.

Andy

Re: Stack traces

[Catonano]

2017-05-18 15:38 GMT+02:00 Christopher Allan Webber <cwebber@dustycloud.org>
:

> Amirouche writes:
>
> > Le 27/02/2017 à 21:23, Andy Wingo a écrit :
> >> On Sat 18 Feb 2017 20:59, Amirouche <amirouche@hypermove.net> writes:
> >>
> >>> How do you access variables in the REPL?
> >> ,locals
> >>
> >> Andy
> > It doesn't display something that I can use.
>
> (Returning to this few-months-old thread...)
>
> Yes, I frequently find that ,locals does not display much
> information... it seems to be a toss-up whether the variables I need
> will be contained in it, so I've reduced the amount I use the actual
> debugger system in Guile a lot.  A shame, because it seems really nice.
>
> Because of this, I think I do what a lot of Guile hackers do (which is
> totally undocumented in the manual, so only people who have been hanging
> around with someoen else who knows tend to know about it), which is to
> use (pk) everywhere.  It's not as nice as being able to play with local
> variables at the REPL though!
>
> Matt's example from earlier in the thread seems simple enough... as a
> recap:
>
> (use-modules (system repl repl))
> (use-modules (system repl debug))
>
> (define-syntax-rule (trap-here)
>   (start-repl
>    #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>
> (define (foo)
>   (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>     (trap-here)
>     (if (null? vals) sum
>         (iter (+ sum (car vals)) (cdr vals)))))
>
> (foo)
>
> Looking at that, I would *think* that at minimum, sum and vals would be
> available when I run ,locals.  I couldn't understand why they weren't:
>
> scheme@(guile-user)> (foo)
> scheme@(guile-user) [1]> ,locals
>   No local variables.
>
> But then I ran ,optimize, and that made it obvious what's happening:
>
> (define (foo)
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   21)
>
> Ah... the compiler was being so smart that it did all the work up front
> already! ;) Pretty cool from a performance and optimization perspective
> (I'm still floored that Guile is able to do optimizations like that!),
> but it's not as helpful from a debugging perspective maybe?
>
> Maybe there could be a way to do something like this:
>
> scheme@(guile-user)> ,optimize-less
> ;;; * user re-evaluates code they want to debug *
> scheme@(guile-user)> (foo)
> scheme@(guile-user) [1]> ,locals
>   Local variables:
>   $23 = sum = 0
>   $24 = vals = '(1 2 3 5 8 2)
> scheme@(guile-user) [1]> ,q
> ;;; User has done debugging
> scheme@(guile-user)> ,optimize-more
> ;;; User can now re-evaluate their code with all the optimizations in
> ;;; place!
> scheme@(guile-user)>
>
> Thoughts?
>  - Chris
>
>

This is an extremely informative message, per se. Precious insights

Thanks