From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Amirouche Newsgroups: gmane.lisp.guile.user Subject: Re: guile-user Digest, Vol 171, Issue 14 Date: Tue, 14 Feb 2017 23:00:00 +0100 Message-ID: <53e9c3de-8803-6682-9bef-93ff8869f190@hypermove.net> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1487109646 3755 195.159.176.226 (14 Feb 2017 22:00:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 22:00:46 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 14 23:00:38 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdl9J-0000Dp-1Z for guile-user@m.gmane.org; Tue, 14 Feb 2017 23:00:37 +0100 Original-Received: from localhost ([::1]:37392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdl9O-0001M3-MG for guile-user@m.gmane.org; Tue, 14 Feb 2017 17:00:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdl8y-0001Lm-Bj for guile-user@gnu.org; Tue, 14 Feb 2017 17:00:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdl8u-0005bQ-3Q for guile-user@gnu.org; Tue, 14 Feb 2017 17:00:16 -0500 Original-Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:51924) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cdl8t-0005ZU-NR for guile-user@gnu.org; Tue, 14 Feb 2017 17:00:12 -0500 Original-Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 872CC41C09D for ; Tue, 14 Feb 2017 23:00:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net Original-Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Pzcp53HOURXA for ; Tue, 14 Feb 2017 23:00:05 +0100 (CET) X-Originating-IP: 37.168.226.142 Original-Received: from [192.168.2.11] (unknown [37.168.226.142]) (Authenticated sender: amirouche@hypermove.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id AE75841C07F for ; Tue, 14 Feb 2017 23:00:04 +0100 (CET) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4b98:c:538::197 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13207 Archived-At: 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, 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 >> To: Arne Babenhauserheide >> Cc: Panicz Maciej Godek , >> "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 : >> >>> Marko Rauhamaa writes: >>>> Then, there's GOOPS, which in my opinion is simply an unnatural way >>>> to go about object-oriented programming. It does violence both to >>>> ordinary OO way of thinking and classic Lisp idioms. >>> GOOPS works pretty well for me where I use it (for dispatch by type). >>> Could you clarify your criticism: Do you think it is bad or is it just >>> different? >> GOOPS starts by defining slots. Slots are an objects internal business >> and should not be visible to the outside. Instead, objects should be >> black boxes that interact with methods. For example, the port interface >> is a nice, classic OO API. You don't know anything about the slots of a >> port. >> >> Furthermore, I think an extensive type system is un-Lisp-like. OO is not >> about things belonging to a type but objects interacting through >> methods. In fact, the concept of a "class" could be done away with. >> >>>> Continuations and multiple values are obstacles instead of enablers. >>> I think multiple values are nice. But they are not well-integrated (I >>> have to import something to use them). Why do you think them enablers? >> Yes, the multiple values API is a problem in and of itself, but more >> generally, what does: >> >> (values a b c) >> >> give you on top of, say: >> >> (list a b c) >> >>> 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? >> >> >>>> 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 >> To: Arne Babenhauserheide >> Cc: Amirouche , "guile-user@gnu.org" >> >> Subject: Re: How to make GNU Guile more successful >> Message-ID: >> > gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> 2017-02-13 23:54 GMT+01:00 Arne Babenhauserheide : >> >>> Panicz Maciej Godek writes: >>> >>>> 2017-02-13 12:06 GMT+01:00 Arne Babenhauserheide : >>>> There's also this problem with Scheme that it is a very diverse >>>> community with plethora of implementations. And while I use Guile, I >>>> don't mind using Chicken or Chez or Gambit for various purposes. Or >>>> even Stalin sometimes. Maybe, instead of getting a better compiler, we >>>> should focus on integrating existing compilers? >>> You?ll have to ask Andy Wingo about all the hidden complexity in just >>> wiring in a compilier. I assume it?s pretty big. >>> >>> I think the r7rs folks are working in that regard, to make it possible >>> to write code which you can simply run through another Scheme >>> implementation if you need those strengths. >>> >>> I started to use (import (...)) to get closer to that: Getting used to >>> the portable stuff (also it?s shorter than (use-modules (...)). But not >>> everything is portable, and performance critical stuff most definitely >>> isn?t. >>> >>> And for the stuff I do, most things get performance critical at some >>> point. Even looking for null-bytes in a file becomes a bottleneck if you >>> have a few hundred TiB to check. >>> >>> Though I mainly need to write Python at work (Scheme isn?t widespread >>> enough for the folks there ? Python is everywhere in science >>> nowadays). It?s still efficient to do that and I enjoy it, but not as >>> much as writing Scheme. >>> >>>>> And it's easy to packages. >>>>>> => Another pain topic. In reality it's very easy to package >>>>>> all sort of guile programs for guix. But guix itself needs >>>>>> to be more stable. >>>>> I wish I had guildhall ready. Got hit by >>>>> time-eaten-by-other-project-because-guildhall-was-priority-three. >>>>> >>>>> It needs to be easy to not just package some code, but also to share >>>>> that package without hitting a bottleneck. >>>>> >>>> What happened to initiatives like Scheme NOW, that tried to integrate >>>> various groups of developers. >>> I did not hear from that. >>> >>>> Or why can't we just "steal" eggs from Chicken? (I mean it. They >> already >>>> have that problem solved) >>> Do you mean, integrating eggs into Guile so we could just use them? >>> Conceptually what would be needed for that is a metadata field: "Works >>> with Guile". And practically someone to write the integration. >>> >>> >> 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 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 >> 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: >> 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 = #> 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 >> To: Guy Baumann >> 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 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.