Re: Stepping back up as a co-maintainer

[tomas]

On Thu, Oct 17, 2019 at 12:24:03PM +0200, Mikael Djurfeldt wrote:
> I think we should trust what Mark says and not second guess him.

Definitely. I think this should count for *all*. Second-guessing anyone
in this difficult situation can only add more difficulties on top.

I think each of us should apply Hanlon's razor with much generosity.

Towards all people involved (that doesn't mean we should paper over
the obvious problems we have, mind you).

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Stepping back up as a co-maintainer

[tomas]

On Fri, Oct 18, 2019 at 10:36:17AM +0200, zx spectrumgomas wrote:
[...]

You are not being helpful. Please, stop this.

-- tomás


signature.asc
Description: Digital signature

Re: Stepping back up as a co-maintainer

[tomas]

On Fri, Oct 18, 2019 at 11:51:52AM +0200, zx spectrumgomas wrote:
> Yes, it clarifies things. I don't agree with you, but you have a noble
> heart. I hope you all come to an agreement.Thanks.

Thanks :)

and... agreed. I've been mostly a bystander here, but have
perceived most of you (Andy, Mark, Mikael, all of you) as
outstanding persons. Thank you all for that.

We have a difficult situation now. Let's sort it out without
throwing things at each other. Inuendo, and he-said-she-said
don't help. Let's be clear, but at the same time let's be
compassionate. Each of us deserves that.

Cheers
-- t


signature.asc
Description: Digital signature

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

[tomas]

On Wed, Oct 23, 2019 at 11:37:24AM +0100, Chris Vine wrote:
> "pelzflorian (Florian Pelz)"  wrote:

[...]

> > I would prefer eventually having a forum/bulletin board-like Web
> > interface to mailing lists in Guile and until then stick to pure
> > mailing lists.
> 
> That's pretty much what discourse is - an attractive web interface to
> something like mailing lists, with the option to use a mail client
> interface as well as the web interface if you want.

I've some practical experience with Discourse and... I'd say it's
the other way around. Shiny GUI is the paradigm, mail is just a
let's-keep-those-old-goofs-happy afterthought.

If you're wired around mail, it's not enjoyable. Feels like
a second-class citizen to me.

This doesn't sound positive, I know -- but I think the "problem"
might lie at a deeper level and won't be solvable without deeper
analysis (instead of hacking together yet-another-forum).

Just watch the regular conflicts between top-posters and top-post
phobia on other mailing lists: those tensions are cultural, and
can't be addressed "just" by a tool. 

I'm not dismissing Todor's insighful initial post -- not in the
least! Actually I think he's very right. But perhaps we need
bridges between cultures and not just between tools. And that
takes deep thinking (and people instead of machines, maybe).

Cheers
-- t


signature.asc
Description: Digital signature

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

[tomas]

On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz) wrote:

[...]

> If there isn’t one already, then I would like to start working on a
> written in Guile [...]

Hmmm. I might be your first contributor :)

Cheers
-- t


signature.asc
Description: Digital signature

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

[tomas]

On Wed, Oct 23, 2019 at 08:48:13AM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> > Regarding the mailling list, many projects (among GNOME) have or will
> > adopt https://www.discourse.org/ [...]

> I only know that subscribing to GNOME Discourse required Javascript
> and its mail headers are less pretty compared to mailman.

Yep. That's another antipattern. The platform dictates the client,
the protocol is whatever the client /du jour/ which you download
time and again happens to talk today to the server.

With Discourse, at least, there's a mail interface, although I
perceive it as less-than-nice.

Cheers
-- t


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut  a écrit :

[...]

> Last time I checked the security requirements for web application that
> do not rely on JavaScript was too complicated. I preferred to forget
> about it.
> 
> See 
> https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Now this is interesting. I still dream of an "application"
which is viable (perhaps with some restrictions) without
any javascript (as Wikipedia and relatives do, BTW). So
I'm interested in such things as above...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

On Thu, Oct 24, 2019 at 11:03:07PM +0800, Nala Ginrut wrote:
> I've ever tried to write a site for our local community without any JS
> code, all auxiliary features include simple animation are implemented with
> CSS.
> However, I have to say it's painful to write a more complex site. I don't
> know if there's any framework for that. I'm too lazy to write all things
> manually. But I recommend you try it if you never did. It's interesting.

I once did. Long time ago. A simple shop -- no javascript.

All state was coded in the URL. You wouldn't do that these days (at least
not without thinking hard) -- but it worked acceptably. People ordered
things :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p

[tomas]

On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:

thanks for your good overview... a question

> Passing session tokens via GET requests is a bad idea, because that
> leaks the token.

Even in https?

Cheers
-- t


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

On Thu, Oct 24, 2019 at 06:35:50PM +0200, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> Do you still remember some of the issues you came across when making
> such a shop?

As I said, it was a pretty simplistic thing:

 - low volume (both customers and inventory)
 - no interest whatsoever in SEO and other things

but it worked pretty well. As basic design principles...

 - I postponed creating session to the last possible
   moment: so the user was browsing the inventory
   basically as a static page, no state encoded;

 - once I had to carry status related to the session
   (i.e. the user dropped the first item into the
   tray), a random session token was generated and
   inserted into the URL. A HTTP redirect then let
   the browser "know" our new common basis.

   I remember chosing an "early" spot at the URL to
   leverage the browser's relative addressing, which
   saves a lot of template substitution in the pages.

   Tokens were expired to avoid abandoned sessions
   piling up

User's feedback was fairly positive: the page felt quick (back
then, the scripts weren't the huge monsters of today, but the
browser's javascript engines weren't as streamlined as today's
either, and the usual bandwidth was a fraction of what is common
these days).

> If I am not mistaken, Racket's continuation based webserver does
> something like this. It also stores state in the URL, which then looks a
> bit strange. I think that state even encodes the continuation.

This is a thing I considered: not to have a per-session
token, but a per-transaction token -- the continuation
idea is pretty cool, because the user can have several
different "histories" of their session running in parallel.

OTOH I tried to imagine the poor webshop user confronted
with that. It sure would confuse the hell out of me ;-)

I think it would take some thinking to tame the less intuitive
parts.

Cheers
-- t


signature.asc
Description: Digital signature

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

[tomas]

On Wed, Oct 23, 2019 at 10:02:11PM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 03:43:26PM +0200, to...@tuxteam.de wrote:
> > But perhaps we need
> > bridges between cultures and not just between tools. And that
> > takes deep thinking (and people instead of machines, maybe).
> > 
> 
> I believe good mailing list etiquette is similar to good forum
> etiquette.  Today’s culture is not a forum culture, of course.

I'm talking of a more implicit culture.

I've taken part in more than one of those "split medium" situations,
the most common that one where the whole company had Outlook as their
UI whereas I had mutt. Issues like "top posting" were typical (top
posting being confusing for me, in-quote posting for most of the
rest of the world) and many other such subtleties.

If someone tries to explain something to someone else about one
of the exchanged messages, it is often in terms of the GUI. You
only become aware of that when you try to live at the rift.

Think "semantic markup" (which doesn't really exist). People think
in terms of "bold", "italic", "top left" etc, because that's how
they /read/ -- those markup's "semantic" varies just so slightly
depending on context. Then academicians come and say "no, no,
you have to think "semantically", i.e. in terms of "strong",
"emphasised", "important", etc -- and they are right, but then
they're not, because they are just peeling the onion off its
999th skin. When they finish, there's no onion :-)

At the end, the medium is (at least part of) the message, to steal
a well-known word.

Sorry for the rambling -- I hope you understand now what I
meant by "culture".

Cheers
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Sat, Oct 26, 2019 at 11:03:12AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 10:14:22AM +0200, to...@tuxteam.de wrote:

[...]

> > only become aware of that when you try to live at the rift.
> 
> Yes, this is something we should keep in mind.  IMHO the medium should
> remain a mailing list and this should be clear.  Top posting is
> useless and undesirable with both e-mail and forums though, I believe.
> 
> Since I use mutt too, I think plain text compatibility is important.

See? There lies the problem. I'm firmly in your "camp", and still I
learnt to realise that the other "cultures" do have as difficult a
time to adapt to "our" camp as the other way around.

That's why I believe that we need serious thinking (beyond the "easy"
technical things) and lots of tolerance.

To me, Wikipedia is a wonderful inspirational example for a web site
which succeds in bridging an astonishly broad swath of those "cultures"
(and still doesn't cover all of them, it has a distinct academic and
"liberal", in the broadest sense, "smell" to it).

> As for the formatting, I think for plain text e-mail compatibility,
> when there are stars around a word, it should *not* be highlighted as
> italic.

Uh -- isn't the star reserved for *strong*? ;-)

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p

[tomas]

On Sat, Oct 26, 2019 at 11:35:06AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 12:31:34AM -0400, Mike Gerwitz wrote:
> > On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> > > So you would use both a cookie to retain login state and then only for
> > > sensitive requests additionally use nonces to prevent CSRF.  Would you
> > > use POST for all (sensitive) requests after login?
> > 
> > GET requests are supposed to retrieve information, not modify it, and
> > should be indempotent.  Since they should have no meaningful
> > side-effects, CSRF shouldn't have any meaningful action to
> > exploit.
> 
> You are right.  That makes sense.  We need not abstain from cookies
> and with cookies we can have GET requests retain session state and
> then for anything sensitive use a nonce, whether GET or POST,
> i.e. write code for links to include a nonce and verify nonces.
> Thank you!

You can still have session state in the URL and keep GET idempotent
(there might be other reasons to use cookies, though: I've yet to be
convinced ;-)

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

On Sat, Oct 26, 2019 at 11:42:47AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 10:04:14AM +0200, to...@tuxteam.de wrote:
> >I remember chosing an "early" spot at the URL to
> >leverage the browser's relative addressing, which
> >saves a lot of template substitution in the pages.
> > 
> 
> So you encoded the session token not in the GET parameter, but similar
> to
> 
> https://your-shop.com//the/place/on/the/site

Yes, exactly.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p

[tomas]

On Sat, Oct 26, 2019 at 06:35:18PM +0800, Nala Ginrut wrote:
> On Sat, Oct 26, 2019 at 3:49 PM  wrote:
> 
> > On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
> >
> > thanks for your good overview... a question
> >
> > > Passing session tokens via GET requests is a bad idea, because that
> > > leaks the token.
> >
> > Even in https?
> >
> 
> I guess he mean query-string with GET.

That's another possibility. Both of them end up encrypted in HTTPS
anyway. I decided against query string at that time because that
saved me quite a bit of template substitution (use relative links).

Cheers
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Sat, Oct 26, 2019 at 03:02:57PM +0200, Zelphir Kaltstahl wrote:
> Hi!

Hi :)

> Well, I hope that such tolerance does not lead us to accept usage of
> mini-uglyfied proprietary JavaScript or other bad things, just to please
> people, who in the majority most likely …

[...]

Lemme digest your long mail for a while. In the meantime just a
short answer:

 - from experience I acknowledge that the issue raised by
   Todor Kondić exists. The tools used for communications
   may pose a barrier to some;
 - I don't like barriers :-)
 - I think the problem is beyond a problem of "tools", and
   to make that plausible here

More on your post later.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p

[tomas]

On Sun, Oct 27, 2019 at 12:50:17AM -0400, Mike Gerwitz wrote:
> To make sure I see replies, please include me in the recipient list (not
> just the mailing list).  I missed this at first.
> 
> On Sat, Oct 26, 2019 at 09:48:37 +0200, to...@tuxteam.de wrote:
> >> Passing session tokens via GET requests is a bad idea, because that
> >> leaks the token.
> >
> > Even in https?

Thanks for this complete account. I appreciate it very much!

> Transport is only part of the problem.
> Query parameters are also leaked to webserver access logs;

That's true -- but I'd call that "category B". The server realm
is full with sensitive data, and the logs are part of that.

> they can leak to 3rd party logs via the referrer header (I
> sometimes see sensitive data in my webserver logs from other
> domains);

That's more serious ("category A") -- third parties get to look
into sensitive data. The application has to take care of links
pointing to the "outside".

If we're trying to pull off this, we'll have to think hard
about this one.

> they're retained in browser history and written to disk;

Again "category B". The browser's cookie jar is, after all,
also there for all to see. As a forensics analyst or a data
"thieve", I'd take with me the whole browser subdir, anyway.

> may show up in proxy logs (e.g. when passing through load
> balancers); could be easily pasted unwittingly to third parties (e.g. a
> user sharing a link with someone else); etc.

Only for plain http (unless it's one of those corporate proxies
with an "open-all" root certificate, that is).

> Back in what feels like a previous lifetime by now, I used to do a lot
> of work with phpBB2, which had an option to either store sessions in
> cookies or place PHPSESSID in the URL.  It modified every link to
> include a session id.  It tried to mitigate the issue by checking the
> source IP address, but if you were logged on the same network (e.g. in
> the same place of employment; school; library; etc), then sharing a link
> would lead to session hijacking.

This all is in the context of plain http, I guess.

> Such link rewriting schemes also cause other types of problems.  For
> example, you may be able to cache most of the generated HTML (except for
> e.g. the header) regardless of what user is logged in.  But if you have
> to inject tokens into all links, that type of caching isn't useful.

Yes. But this has lost most of its bite in the last decade or
so. Machines have increased in power (speed, RAM) faster than
the network. Apart from really high-volume sites, where you
start thinking about load balancers, CDNs, etc. I think a bit
of server-side template substitution will drown in the noise.

Cheers
-- t


signature.asc
Description: Digital signature

Re: mailmam, web bridge, forum, p2p

[tomas]

On Sun, Oct 27, 2019 at 01:32:54AM -0400, Mike Gerwitz wrote:

[...]

> > Back in what feels like a previous lifetime by now, I used to do a lot
> > of work with phpBB2, which had an option to either store sessions in
> > cookies or place PHPSESSID in the URL.  It modified every link to
> > include a session id [...]

> Since I was in the mindset of leaking information, I forgot to mention
> another negative side-effect of including tokens as query strings: it
> can turn link sharing into a weapon using session fixation.  E.g. I
> could create an account, send a link to you with my session token, and
> you may then be logged into my account.

Actually there are two scenarios: User A (say Alice) "has" the session
and passes a link to B (Bob), session token included.

This could be negligence, and now Bob might do something nasty with
Alice's session (e.g. go into a shopping spree)...

>  The user may then perform an
> action that may benefit the attacker (or the action could be part of the
> URL).

...but you seem to imply that there's a reverse scenario, where Alice
does something nasty to Bob?

> This is sometimes used as a poor-man's SSO. :x  It can also work with
> POSTs: direct the user to an auto-submitting form.

Yes, you could take your "session token" with you, to another computer,
but this seems somewhat fragile [1].

> Cookies are better suited for storing session tokens---you cannot set
> cookie values for other domains without some other type of exploit
> (e.g. XSS, but your cookies best be set to HTTP-only to mitigate that).

Cookies are, after all, client-side data. The browser might not allow
you to do something, but you can engineer all sort of HTTP requests:
that means the server has to do its own sanity checks anyway.

Cheers

[1] That's why I'd go for a fairly strict session expiry; perhaps
   (but I haven't played with it in practice!) you'd need transaction
   tokens instead (as those continuation based thingies use), which
   can be even more short-lived. Perhaps even some correlation
   between token and client profile (IP address, etc.).

-- tomás


signature.asc
Description: Digital signature

Re: Weird behavior of hash-table

[tomas]

On Sun, Nov 24, 2019 at 03:04:36AM -0500, Mark H Weaver wrote:
> Hi Zelphir,
> 
> Zelphir Kaltstahl  writes:
> 
> > I've noticed a strange behavior of hash tables [...]

> > (define SQUARES
> >   ;; vector, constant time access
> >   #('A1 'B1 'C1 'D1 'E1 'F1 'G1 'H1
[...]

> I guess that you meant for this to be a vector of symbols.  In fact, it
> is a vector of lists of the form (quote ), for which '
> is a shorthand.
> 
>   scheme@(guile-user)> (vector-ref SQUARES 0)
>   $10 = (quote A1)

Yikes. I'd fall into this trap, too. Thanks you both for illustrating
it so well -- and thanks, Mark, for your unfailing sharp vision :-)

So the best thing for one's brain is to train it to read #(...)
as some weird relative of '(...)?

Is there a corresponding weird relative of `(...)?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Weird behavior of hash-table

[tomas]

On Sun, Nov 24, 2019 at 11:55:40AM +0100, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> On 11/24/19 9:57 AM, to...@tuxteam.de wrote:
> > Yikes. I'd fall into this trap, too [...]

> > Is there a corresponding weird relative of `(...)?
> >
> > Cheers
> > -- tomás
> 
> Do you mean a way to write a vector and evaluate only some of the
> elements in the vector?

Yes, and yes. See Mark's answer :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Weird behavior of hash-table

[tomas]

On Sun, Nov 24, 2019 at 06:00:43AM -0500, Mark H Weaver wrote:
> Hi tomás,
> 
>  wrote:
> 
> > So the best thing for one's brain is to train it to read #(...)
> > as some weird relative of '(...)?
> 
> Yes.  They are both literals, and no part of a literal is evaluated.
> #(...) is actually a shorthand for '#(...) [...]

Aha. Thanks for setting my light bulb on fire :-)

[...]

> > Is there a corresponding weird relative of `(...)?
> 
> Yes.  Remember that #(...) is a shorthand for '#(...).  You can replace
> the "'" with "`", just as you would for a quasiquoted list [...]

Thanks, Mark!

IMO Andy and you are doing invaluable work for Guile (and Scheme in
general) by making it mentally more accessible. Again, thanks.

Cheers
-- tomás


signature.asc
Description: Digital signature

Nyacc and guile-nearly-3.0

[tomas]

Hi,

to anyone "in the know": is it worth to give nyacc a spin under
Guile nearly-3.0 (i.e. >= 2.9.5)?

I know the "configure" precludes that, but it's fairly obvious
how to jump that fence. Is it a total loss of time -- or worth
a try?

Thanks for any insight, cheers
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Mon, Dec 02, 2019 at 10:40:41AM +0100, to...@tuxteam.de wrote:
> Hi,
> 
> to anyone "in the know": is it worth to give nyacc a spin under
> Guile nearly-3.0 (i.e. >= 2.9.5)?

Well, I tried, this is a small progress report. First munged
_guile_versions_to_search in nyacc's configure script to contain
2.9.5 (that's what my guile --version says). Configure bails
out with:

  configure: error: found development files for Guile 2.9.5, but 
/usr/local/bin/guile has effective version 3.0

(FWIW, there's an /usr/local/lib/pkgconfig/guile-3.0.pc). Now
setting _guile_versions_to_search in said script bails out with

  checking for Guile version >= 3.0... configure: error: Guile 3.0 required, 
but 2.9.5 found

So it seems my Guile is schizophrenic: under some aspect it
reports 3.0 ("effective" version), under some aspect it's
2.9.5 (--version version, to put some name on it).

I haven't given up yet, though :-)

Cheers & thanks
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

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

Ouch. A segmentation fault in bash :-o

Let's see what happens here...

Thanks again, cheers
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Mon, Dec 02, 2019 at 06:28:53AM -0800, Matt Wette wrote:
> Look at etc/README.  Maybe edit etc/configure.ac and rerun as in the README.

Hm. Same confusion. Adding 3.0 to GUILE_PKG, like so:

  GUILE_PKG([3.0 2.2 2.0])

yields, at configure time:

  tomas@trotzki:~/src/guile/nyacc$ ./configure
  checking for pkg-config... /usr/bin/pkg-config
  checking pkg-config is at least version 0.9.0... yes
  configure: checking for guile 3.0
  configure: found guile 3.0
  checking for guile... /usr/local/bin/guile
  checking for Guile version >= 3.0... configure: error: Guile 3.0 required, 
but 2.9.5 found

Inserting 2.9.5 in configure.ac's GUILE_PKG, like so:

  GUILE_PKG([2.9.5 2.2 2.0])

yields, again at configure time:

  tomas@trotzki:~/src/guile/nyacc$ ./configure
  checking for pkg-config... /usr/bin/pkg-config
  checking pkg-config is at least version 0.9.0... yes
  configure: checking for guile 3.0
  configure: found guile 3.0
  checking for guile... /usr/local/bin/guile
  checking for Guile version >= 3.0... configure: error: Guile 3.0 required, 
but 2.9.5 found
  tomas@trotzki:~/src/guile/nyacc$ ( cd etc && autoconf -o ../configure )
  tomas@trotzki:~/src/guile/nyacc$ ./configure
  checking for pkg-config... /usr/bin/pkg-config
  checking pkg-config is at least version 0.9.0... yes
  configure: checking for guile 2.9.5
  configure: found guile 2.9.5
  checking for guile... /usr/local/bin/guile
  configure: error: found development files for Guile 2.9.5, but 
/usr/local/bin/guile has effective version 3.0

It seems I've got a schizophrenic Guile. It somehow reports
an "effective version" 3.0 (the pkg config file in /usr/local/lib
is a guile-3.0.pc, actually), but if you ask guile itself, it
reports 2.9.5.

I don't exactly know where configure has this "effective version"
from, but I dimly remember Andy mumbling about setting Guile's
effective version to 3.0, since 2.9.5 is already a pre-3.

Hmmm. I'll try to poke at it some more tomorrow...

Cheers & thanks
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Mon, Dec 02, 2019 at 10:45:23PM +0100, to...@tuxteam.de wrote:
> On Mon, Dec 02, 2019 at 06:28:53AM -0800, Matt Wette wrote:
> > Look at etc/README.  Maybe edit etc/configure.ac and rerun as in the README.
> 
> Hm. Same confusion. Adding 3.0 to GUILE_PKG, like so:
> 
>   GUILE_PKG([3.0 2.2 2.0])
> 
> yields, at configure time:

[...]

>   checking for Guile version >= 3.0... configure: error: Guile 3.0 required, 
> but 2.9.5 found
> 
> Inserting 2.9.5 in configure.ac's GUILE_PKG, like so:
> 
>   GUILE_PKG([2.9.5 2.2 2.0])
> 
> yields, again at configure time:

[...]

>   configure: error: found development files for Guile 2.9.5, but 
> /usr/local/bin/guile has effective version 3.0

To complement that, here what "my" Guile says:

  tomas@trotzki:~$ guile
  GNU Guile 2.9.5
  Copyright (C) 1995-2019 Free Software Foundation, Inc.
  
  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.
  
  Enter `,help' for help.
  scheme@(guile-user)> (version)
  $1 = "2.9.5"
  scheme@(guile-user)> (effective-version)
  $2 = "3.0"
  scheme@(guile-user)> (major-version)
  $3 = "2"
  scheme@(guile-user)> (minor-version)
  $4 = "9"
  scheme@(guile-user)> (micro-version)
  $5 = "5"

This is compiled off git, specifically:

  a12e862be (HEAD -> master, tag: v2.9.5, origin/master, origin/HEAD) GNU Guile 
2.9.5.

Not very surprising, so far. Version is 2.9.5, "effective version" is
3.0.

As seen from my corner of reality, nyacc's configury can't cope with
the fact that Guile's version and effective version are different.

Now on your side, Mark, configury seems to get past that point (and
you run into "real" stuff, like the new shiny Guile compiler doing
"too much" at compile time -- that kind of issues one might expect).

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]

[tomas]

On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote:
> 
> On 12/2/19 6:28 AM, Matt Wette wrote:
> >I'm building 2.9.5 now but running into errors (ubuntu 18.04):
> >/bin/bash: line 6: 14657 Segmentation fault  (core dumped)
> >GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
> >--target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L
> >"/home/mwette/proj/guile/guile-2.9.5/module" -L
> >"/home/mwette/proj/guile/guile-2.9.5/guile-readline" -o
> >"system/vm/linker.go" "../module/system/vm/linker.scm"
> So, as a random check, I first verified that I could reproduce the
> above error at the command line.  I did.
> 
> Then I removed "-Oresolve-primitives" and it compiled without
> error.   Any help?

OK -- compiles successfully now. I realize in hindsight that
my answers sometimes went (only) to guile-devel, so I re-quote
that one where I "solved" configury:

> OK, solved this one -- will try to follow up with the rest.
> 
> I just had to set GUILE_PROGS in etc/configure.ac besides GUILE_PKG,
> like so:
> 
>   GUILE_PKG([3.0])
>   GUILE_PROGS([2.9.5])
> 
> Configure now does "something". Next steps later.

So far, so good. Now it compiles "cleanly" (but there's no -Oresolve-primitives
option in sight in all of the compile; no idea why).

A cursory test (with the example from the man page)
shows signs of life. Yay!

Thanks
-- tomás


signature.asc
Description: Digital signature

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

[tomas]

On Tue, Dec 03, 2019 at 05:33:20AM -0800, Matt Wette wrote:
> The segfault is not in bash.  I was able to re-create the segfault
> from the (bash) command-line.

Got it, thanks :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Nyacc and guile-nearly-3.0

[tomas]

On Wed, Dec 04, 2019 at 08:12:44PM +0100, Amirouche Boubekki wrote:
> Le lun. 2 déc. 2019 à 10:40,  a écrit :
> 
> > Hi,
> >
> > to anyone "in the know": is it worth to give nyacc a spin under
> > Guile nearly-3.0 (i.e. >= 2.9.5)?

[...]

It's working for me now. It was mostly "driver error", but since the
thread went a bit out of control and got partially split between
here and guile-devel@, I restate. Setting

  GUILE_PKG([3.0])
  GUILE_PROGS([2.9.5])

in etc/configure.ac (and invoking autoconf -o ../configure, as stated
in /etc/README) did the trick for me.

Matt says that he had to remove "-Oresolve-primitives" from the compiler
options. I hadn't -- but I suspect this option isn't set by default...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Nyacc and guile-nearly-3.0

[tomas]

On Wed, Dec 04, 2019 at 04:48:33PM -0800, Matt Wette wrote:
> 
> 
> On 12/4/19 1:04 PM, to...@tuxteam.de wrote:
> >
> >Matt says that he had to remove "-Oresolve-primitives" from the compiler
> >options. I hadn't -- but I suspect this option isn't set by default...
> >
> I apologize if I generated confusion.  I was intending to build
> 2.9.5 to help debug the nyacc issue.

d'oh :-)

> The segfault I ran into was in building guile-2.9.5.  It is
> uncorrelated with the nyacc issue.

Now everything is clear. Thanks, Mark. And thanks also for setting
me on the right path. And for nyacc...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: [ANN] nomunofu v0.1.0

[tomas]

On Thu, Dec 12, 2019 at 03:57:18PM +0100, Amirouche Boubekki wrote:
> I am pleased to share with you the v0.1.4 binary release. It contains
> the following improvements:

This sounds very intriguing. I'm drowned in customer stuff at the
moment, but perhaps you've made something for my Christmas tree :-)

Thanks
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.7 Released [beta]

[tomas]

(Sorry for the cross-post, see below)

On Fri, Dec 13, 2019 at 09:23:46PM -0500, John Cowan wrote:
> I am getting the following build error on both Cygwin and Ubuntu Xenial.
> All is well until:
> 
>   BOOTSTRAP GUILEC system/vm/linker.go
> /bin/bash: line 6: 16683 Segmentation fault  (core dumped)
> GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
> --target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L
> "/home/rr828893/guile-2.9.7/module" -L
> "/home/rr828893/guile-2.9.7/guile-readline" -o "system/vm/linker.go"
> "../module/system/vm/linker.scm"
> Makefile:1930: recipe for target 'system/vm/linker.go' failed
> make[2]: *** [system/vm/linker.go] Error 139
> make[2]: Leaving directory '/home/rr828893/guile-2.9.7/bootstrap'
> Makefile:1849: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/rr828893/guile-2.9.7'
> Makefile:1735: recipe for target 'all' failed
> make: *** [all] Error 2

This sounds exactly like the bug Matt Wette is stumbling upon.
He posted to guile-devel@, so I don't know whether you missed
it, in any case it's here in the archive [1].

FWIW, Matt worked around it by removing "-Oresolve-primitives"
from the compile options.

I don't know whether there's a bug report on it already.

Cheers

[1] https://lists.gnu.org/archive/html/guile-devel/2019-12/msg00011.html

-- tomás


signature.asc
Description: Digital signature

Re: [Wikidata] [ANN] nomunofu v0.1.0

[tomas]

On Sun, Dec 22, 2019 at 06:36:06PM -0500, Ted Thibodeau Jr via General Guile 
related discussions wrote:

[...]

> Hi, Amirouche --
> 
> Kingsley's points about tuning Virtuoso to use available 
> RAM [1] and other system resources are worth looking into, 
> but a possibly more important first question is --
> 
>Exactly what version of Virtuoso are you testing?
> 
> If you followed the common script on Ubuntu 18.04, i.e., --
> 
>sudo apt update
> 
>sudo apt install virtuoso-opensource

Hi, Ted

I see you do have a stake in the game. That's fine, since having
a good technical discussion should be independent of that. So
thanks for chiming in!

> -- then you likely have version 6.1.6 of VOS, the Open Source 
> Edition of Virtuoso, which shipped 2012-08-02 [2], and is far
> behind the latest version of both VOS (v7.2.5+) and Enterprise 
> Edition (v8.3+)!

Wouldn't that be something your company could contribute to
Ubuntu/Debian? Contact the package maintainers and help keeping
the free version of Virtuoso up to snuff on those platforms?

A rising tide, etc?

> You can also try Enterprise Edition at no cost for 30 days [5].

I think it's somewhat unfair to try to compare a freshly
done free project with an established commercial one.

> I'll be interested to hear your new results, with a current build,
> and with proper INI tuning in place.

Why not assist Amirouche on that part? After all, you have
much easier access to Virtuoso expertise, and me, at least,
rather prefer Amirouche to spend his time tuning his wonderful
free creatures than tuning Virtuoso ;-P (of course, he'll end
up doing what he enjoys most, I'd hope!).

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: GNU Guile 2.9.8 Released [beta]

[tomas]

On Fri, Jan 03, 2020 at 01:34:59PM +0800, Nala Ginrut wrote:
> When I was trying to compile Artanis, the configure threw an error:
> 
> checking for Guile version >= 3.0... configure: error: Guile 3.0 required,
> but 2.9.8 found
> 
> 
> Here's what I put in configure.ac:
> GUILE_PKG(2.2 2.3 2.9 3.0)
> 
> My question is "what's the correct config here"?

Hm. I think I had that with nyacc too. This worked for me:

  GUILE_PKG([3.0])
  GUILE_PROGS([2.9.5])

I think this is due to our currently apocalyptic [1] situation:

  tomas@trotzki:~/src/guile/nyacc$ guile
  GNU Guile 2.9.5
  [...]
  
  Enter `,help' for help.
  scheme@(guile-user)> (version)
  $1 = "2.9.5"
  scheme@(guile-user)> (effective-version)
  $2 = "3.0"

(replace 2.9.5 for 2.9.8 as appropriate).

Cheers
[1] Although apocalyptic has often a negative connotation, I'm using
   it here in its more original sense [2], i.e. full of gleeful
   expectation :-)

[2] https://en.wiktionary.org/wiki/apocalyptic

-- tomás


signature.asc
Description: Digital signature

Nyacc question: where are the actions bound?

[tomas]

Hi,

I'm playing around with Nyacc: I found a first little use case
to get my feet wet.

First of all, than you, Matt, for this impressive package.

Shamelessly stolen from the minimal example, playground looks
roughly like this:

#+begin_source scheme
  (use-modules (nyacc lalr))
  (use-modules (nyacc lex))
  (use-modules (nyacc parse))
  
  ;; to be used in some ($$ ...) actions:
  (define (collect arg) (display arg))
  
  (define my-grammar
(lalr-spec
 (start my-file)
 (grammar
  (my-file
   (elt-list))
  ;; more productions, calling out to ($$... collect)
  (name
   ($ident)
  
  (define mach (make-lalr-machine aq-grammar))
  (define mtab (lalr-match-table mach))
  (define gen-lexer (make-lexer-generator mtab))
  (define raw-parse (make-lalr-parser mach))
  (define (parse) (raw-parse (gen-lexer)))
  (parse)
#+end_source

So I defined some function =collect= which will be called from
actions in the grammar.

My question is: where is the stuff resolved which is mentioned
in grammar actions? My first experiments indicate that it's
looked up at (module) top level, as if (grammar ...) greedily
weaved that in at compile time.

My idea would be to (pre-) define a grammar and to exchange
the actions later as needed. Or would I have to re-define the
grammar whenever I change my mind about actions?

Note that I'm still very much in exploratory mode: "you're
holding it wrong" would be a perfectly adequate answer, as
would be "your mumblings are pretty unintelligible" :-)

Cheers & thanks
-- tomás


signature.asc
Description: Digital signature

Re: Nyacc question: where are the actions bound?

[tomas]

On Sun, Mar 08, 2020 at 08:10:50AM -0700, Matt Wette wrote:
> 
> 
> On 3/8/20 3:14 AM, to...@tuxteam.de wrote:
> >Hi,
> >
> >I'm playing around with Nyacc [...]

> >So I defined some function =collect= which will be called from
> >actions in the grammar.
> >
> >My question is: where is the stuff resolved which is mentioned
> >in grammar actions? [...]

Thanks for your quick response, and for taking the time to make
sense of my diffuse text.

> Nyacc was envisioned with the paradigm you propose, by using tags.
> But I have not tried that in a while.  If you look at the example calc
> in examples/nyacc/lang/calc/mach.scm you will see

Note that I'm not yet proposing a paradigm. What you (graciously)
raise to the level of "paradigm" is still just a set of prejudices
as I try to find a way through the bushes :)

I'm ready & willing to change my way of seeing things.

Care to explain why you havent tried your first paradigm in a
while? After all you're probably the one having the most practical
experience with Nyacc.

> (define (gen-calc-files)
  [...]

> You can run this, then you can use the generated files to provide
> the parser [...]

> (define calc-full-act-v
  [...]

Thanks for the hint. I'll definitely give that angle a try.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: [ANN] nyacc 1.01.2 released

[tomas]

On Fri, Mar 13, 2020 at 03:29:29PM -0700, Matt Wette wrote:

[...]

> NEWS for V1.01.2

Thanks! Compiling now...

Cheers
-- t


signature.asc
Description: Digital signature

Re: Nyacc question: [found] where are the actions bound?

[tomas]

On Sun, Mar 08, 2020 at 08:10:50AM -0700, Matt Wette wrote:
> 
> 
> On 3/8/20 3:14 AM, to...@tuxteam.de wrote:
> >Hi,

[...]

> >My question is: where is the stuff resolved which is mentioned
> >in grammar actions?

Hah. Managed to answer my own question by reading the source.

For the benefits of others who might have a similar question
(without knowing how to articulate it, like it happened to
me), here's the answer:

Yes, the actions are "resolved" wrt the (calling) module's
top level environment. The magic happens here (that's wrt the
all-fresh V1.01.2), around lines 47 ff, in module/nyacc/parse.scm:

  (define (make-xct av)
(if (procedure? (vector-ref av 0))
av
(vector-map (lambda (ix f) (eval f (current-module)))
  (vector-map (lambda (ix actn) (wrap-action actn)) av

It's the (eval f (current-module)) which does the trick. The
trick happens in make-lalr-parser.

Background: I envisioned something like

  (let ( ...some environment for the actions...)
...make-lalr-parser...)

and have make-lalr-parser pick up the bindings in the lexical
environment.

but had to realize that make-lalr-parser ignores the lexical
environment. That's now clear to me, because (eval ... (current-module))
looks at the caller's module's top-level bindings.

One would have to call local-eval (from (ice-9 local-eval)) and
explicitly pass (the-environment) (from the same module) to
achieve what I had in mind.

Not that I'm proposing that, mind you. I still barely know what
I'm doing at this point. Probably there are very good reasons
to resort to the (top-level) module bindings.

I just wanted to understand, and I think I do now :-)

As to your other proposal (writing out the pre-compiled parser
with write-lalr-*), I think it's orthogonal to my issue. This
might come in handy when the parser is heavy enough that it
takes a significant time constructing it (which it is not in my
little use case for now)

Thanks & cheers
-- tomás


signature.asc
Description: Digital signature

Re: [ANN] nyacc 1.01.2 released

[tomas]

On Sat, Mar 14, 2020 at 10:34:28AM +0100, tomas wrote:
> On Fri, Mar 13, 2020 at 03:29:29PM -0700, Matt Wette wrote:
> 
> [...]
> 
> > NEWS for V1.01.2
> 
> Thanks! Compiling now...

works, thank you a lot :-)

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Nyacc question: [found] where are the actions bound?

[tomas]

On Sat, Mar 14, 2020 at 07:31:10AM -0700, Matt Wette wrote:
> On 3/14/20 4:59 AM, to...@tuxteam.de wrote:

[...]

> >and have make-lalr-parser pick up the bindings in the lexical
> >environment.

[...]

> I get it now.  What you expect makes much sense.
>  I will think about that.

It might come at a price, I don't know. At least, the calling site
has to capture the (lexical) environment, so make-lalr-parser has
either to get the env as an extra parameter or it has to become
a macro.

As I wrote in the other mail, a doc fix could be more than enough.

I repeat: I barely know what I'm doing, so I might be dangerous ;-)

Cheers & thanks
-- tomás


signature.asc
Description: Digital signature

Re: guile-lib handling

[tomas]

On Mon, Mar 16, 2020 at 02:40:45PM +0100, Michal Herko wrote:
> Dear maintainor of guile-lib.
> I believe the special handling of  elements in (htmlprag) module
> to be a bug.
> For example:
> 
> (use-modules (htmlprag))
> (html->shtml "text")
> ; expected result (*TOP* (html (body (div (p "text")
> ; actual (*TOP* (html (body (div) (p "text"
> 
> Note that the  element is parsed outside the  element.
> I attach the simple patch to remove the special case for  elements.
> 

> diff --git a/src/htmlprag.scm b/src/htmlprag.scm
> index 3bd352b..df99612 100644
> --- a/src/htmlprag.scm
> +++ b/src/htmlprag.scm
> @@ -1099,7 +1099,6 @@
>(meta . (head))
>(noframes . (frameset))
>(option   . (select))
> -  (p. (body td th))
>(param. (applet))
>(tbody. (table))
>(td   . (tr))

Where did you get htmlprag from? I'll guess it's from the
Debian package guile-lib.

It seems the upstream isn't maintained anymore [1]. The
Debian package page [2] lists a maintainer you might want
to contact.

That said, you are modifying the parser's "parent constraints";
I would go the other direction and add  to the set of
's possible parents:

>(option   . (select))
> -  (p. (body td th))
> +  (p. (body td th span))
>(param. (applet))

HTML has changed a lot since htmlprag saw its heyday.

Cheers

[1] 
https://planet.racket-lang.org/package-source/neil/htmlprag.plt/1/7/planet-docs/htmlprag/index.html
[2] https://packages.debian.org/buster/guile-library

-- tomás


signature.asc
Description: Digital signature

Nyacc: how to lex comments?

[tomas]

Hi,

in my quest to play parsing, I'm failing when I try to cope with
comments.

Here's an excerpt from my current file

(define my-grammar
  (lalr-spec
   (start my-file)
   (grammar
;; boring grammar details elided
   )))

(define mach (make-lalr-machine aq-grammar))
(define mtab (lalr-match-table mach))
(define gen-lexer (make-lexer-generator mtab
   #:comm-reader (make-comm-reader '(("#" . "\n")
(define raw-parse (make-lalr-parser mach))
(define (parse) (raw-parse (gen-lexer)))

;; (gen-lexer)
(parse)

Comments are shell-like, from "#" to end of line. Grammar
works fine so-far, but when (parse) sees a hash-comment
(even just a one-line input

  # this is a comment

it panics:

Backtrace:
In ice-9/boot-9.scm:
  1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  4 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
619:8  3 (_ #(#(#)))
In ice-9/boot-9.scm:
   2806:4  2 (save-module-excursion #)
  4351:12  1 (_)
In nyacc/parse.scm:
 78:4  0 (_ _ #:debug _)

nyacc/parse.scm:78:4: Throw to key `nyacc-error' with args `("~A:~A: parse 
failed at state ~A, on input ~S" "(unknown)" 1 0 " a comment")'.

I feel I'm doing something stupid. What can I do to understand
what's going on?

Thanks & cheers
-- tomás




signature.asc
Description: Digital signature

Re: Nyacc: how to lex comments?

[tomas]

On Mon, Mar 16, 2020 at 05:11:59PM -0700, Matt Wette wrote:
> On 3/16/20 2:39 PM, to...@tuxteam.de wrote:
> >Hi,
> >
> >in my quest to play parsing, I'm failing when I try to cope with
> >comments.
> >

[...]

> make-comm-reader will not eat newlines at end of comment by default.
> If you want the comment # ... \n to include the newline try adding
> #:eat-newline #t.

D'oh, thanks. Also, I noticed I've to set #:comm-skipper in 'gen-lexer',
instead of #:comm-reader.

I didn't quite understand the difference between both. Would I have
to include comments explicitly in the grammar if the lexer uses
#:comment-reader? 

Thanks again
-- tomás


signature.asc
Description: Digital signature

Re: Nyacc: how to lex comments?

[tomas]

On Tue, Mar 17, 2020 at 05:31:32AM -0700, Matt Wette wrote:
> 
> 
> On 3/17/20 12:46 AM, to...@tuxteam.de wrote:

[...]

> >I didn't quite understand the difference between both. Would I have
> >to include comments explicitly in the grammar if the lexer uses
> >#:comment-reader?
> >
> >Thanks again
> >-- tomás
> Yes.  Use comm-reader if your grammar accepts comments.
> Use comm-skipper if your grammar does not.
> 
> The ffi-helper does read comments in the C grammar and
> dumps them in the output files, for example.

Ah, I see, thanks. Thank you for your invaluable help!

Cheers
-- t


signature.asc
Description: Digital signature

Re: question about values

[tomas]

On Wed, Mar 18, 2020 at 03:48:03PM +0100, Massimiliano Gubinelli wrote:
> 
> > On 18. Mar 2020, at 15:40, Massimiliano Gubinelli  
> > wrote:
> > 
> > Good point with dynamic-wind. Does it pass along also multiple values or 
> > has the same problem?
> > 
> 
> Does not work...
> 
> mgubi@Ulrike guile3-usr % bin/guile
> GNU Guile 3.0.1
> Copyright (C) 1995-2020 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> (call-with-values (lambda ()
>  (dynamic-wind (lambda () (display "initialize\n"))
>   (lambda () (let ((a (values "a" "b" "c"))) a))
   ^^ HERE
>   (lambda () (display "finalize\n"
>   (lambda body body))
> initialize
> finalize
> $1 = ("a")
> scheme@(guile-user)> 
> 
> Isn't this a bug??? In my view it breaks composability of scheme code.

Above, marked with HERE is the crocodile eating
your other values.

If you instead do, in that line

  (lambda () (values "a" "b" "c"))

then you get ("a" "b" "c").

The let binding construct only binds one value. There's a
"let-values" for that.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: assign to and read from global variable

[tomas]

On Fri, Mar 20, 2020 at 06:20:38PM +0100, Malte Frank Gerdes wrote:
> Hi,
> 
> i'm trying to collect every definition of variables with it's according
> value in a global variable. How i think it's supposed to work is:
> 
> (define *global* '())
> 
> (...
>   (defvar . ,(lambda (_ . args)
>(set! *global* (cons *global* args
>  ...)
> 
> 
> 
> This results in the following output:
> ((()
^^ Here's your initial "global"

I.e.:

  scheme@(guile-user)> (cons '() 'a)
  $1 = (() . a)

(in box-and-pointer notation: you start with an empty list,
then you append 'a, you end up with:

   | | | -> | | | -> nil
||
vv
   nil   a

(sorry for my poor drawing skills).

If you keep consing at the end of your thing, the nesting
gets deeper and deeper:

  scheme@(guile-user)> (define g '())
  scheme@(guile-user)> (set! g (cons g 'a))
  scheme@(guile-user)> (set! g (cons g 'b))
  scheme@(guile-user)> (set! g (cons g 'c))
  scheme@(guile-user)> g
  $2 = ) . a) . b) . c)

I guess that's not what you want.

One "classical" idiom to achieve what you're looking for
is to prepend your new stuff onto the list, and at the
end revert it:

  scheme@(guile-user)> (define g '())
  scheme@(guile-user)> (set! g (cons 'a g))
  scheme@(guile-user)> (set! g (cons 'b g))
  scheme@(guile-user)> (set! g (cons 'c g))
  scheme@(guile-user)> g
  $3 = (c b a)

Ah. That looks better. But... it's tail first!

  scheme@(guile-user)> (reverse g)
  $4 = (a b c)

That's it.

Of course there are other ways to achieve this, like
keeping a pointer to the list's tail, using vectors
and so on. But in lispy world, and for smallish
things, the above is, as far as I konw, the usual
idiom.

Cheers
-- t


signature.asc
Description: Digital signature

Re: confused about make-module and eval

[tomas]

On 24. Mar 2020, at 01:32, Matt Wette  wrote:

> I expect this to work, but it does not.  Any anyone elaborate?
> What is the minimum module that can make this work?  (make-fresh-use-module)?

On Tue, Mar 24, 2020 at 01:35:51AM +0100, Massimiliano Gubinelli wrote:
> I think a fresh module do not have any binding. So 'lambda is not defined. 
> You would have to create bindings inside the module, maybe you could just 
> import the-scm-module .

Yes, I think that is it. The documentation is fairly sparse;
There is something in "6.20.12 Environments" [1], and via
R5RS environments (ice-9 r5rs) you have access to some kinda
standard environments (scheme-report-environment, etc.)

As you already noticed (in the context of NYACC) , this topic
is is also somewhat  coufusing and fascinating for me :-)

Cheers
--tomás


signature.asc
Description: Digital signature

Re: confused about make-module and eval

[tomas]

On Tue, Mar 24, 2020 at 10:27:35AM +0100, Massimiliano Gubinelli wrote:
> you can look into ice-9/boot-9.scm to see how modules are populated. I'm not 
> sure now how to do it right.

Thanks, will do.

Cheers
-- t


signature.asc
Description: Digital signature

Re: syntax taste: use of unquote in macros

[tomas]

On Mon, Mar 30, 2020 at 12:07:07AM +0200, Zelphir Kaltstahl wrote:
> 
> On 3/29/20 5:11 PM, Matt Wette wrote:
> > Hi All,
> >
> > I'm not sure if you know about this, but there is a discrepancy in the
> > way some folks define macros to use unquote (aka ,).   For example,

[pmatch vs. match]

> I'm not sure where I first read about pmatch doing the quasiquote
> internally automatically and I of course had already forgotten about it,

[...]

I didn't even know about `pmatch'. Is it supposed to be equivalent
to `match' (except that outer quasiquote, that is)?

With the caveat that I don't have much of a stylistic feeling for
Scheme, I'd clearly prefer `match': the writer has the choice of
quote or quasiquote, as appropriate to the case -- and the reader
sees what's going on (after all, quote and quasiquote are "low
weight" primitives: everyone more or less knows what they do.

But perhaps I misunderstood what you're after?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: syntax taste: use of unquote in macros

[tomas]

On Mon, Mar 30, 2020 at 04:43:47PM -0700, Matt Wette wrote:

[...]

> The other thing about match that is attractive is that use of
> quasiquote+unquote is "reflexive" (or maybe self-adjoint?)
> in the following sense:
> 
> '(foo "bar") => (match-lambda (`(foo ,val) `(foo ,val))) => '(foo "bar")

Sorry, my head just exploded :-)

Will take it more slowly later today. Thanks for the riddle.

Cheers
-- t


signature.asc
Description: Digital signature

Re: guile-hall error on probably every command

[tomas]

On Thu, Jun 11, 2020 at 08:59:35PM +0200, Zelphir Kaltstahl wrote:
> Hi Guile users!
> 
> I was about to follow the guile-hall tutorial posted on the list today,
> but unfortunately, I get an error the first time I need to input a
> guile-hall command:

[...]

> In unknown file:
>0 (make-regexp "^-[a-Z]*h[a-Z]*$|^--help$")

> ERROR: In procedure make-regexp:
> In procedure make-regexp: Invalid range end

I think Guile relies on the system lib for regexps. Not all take [a-Z] as
a valid range (FWIW my plain "grep" on some Debian GNU/Linux complains
also about an "invalid range end".

I think the longer version [A-Za-z] is safer.

Cheers
-- t


signature.asc
Description: Digital signature

NYACC: getting source location info?

[tomas]

Hi,

I'm having some fun with NYACC (thanks, Matt!).

To help debugging things and for errors and warnings, it'd be nice
to "know" where the current LHS non-terminal starts in the source.

Its endpoint is (is it?) (port-line (current-input-port) [and, of
course, (port-column ...)] -- at least some playing around suggest
that (and it makes sense, somehow).

Is there anything I've overlooked? Or do I have to hack the (or
roll-my-own) lexer for that?

Thanks for any insight

cheers
-- t


signature.asc
Description: Digital signature

Re: NYACC: getting source location info?

[tomas]

On Fri, Jul 10, 2020 at 08:00:15PM -0700, Matt Wette wrote:

Hey, and thanks for your quick response!

> On 7/10/20 1:37 PM, to...@tuxteam.de wrote:
> >Hi,
> >
> >I'm having some fun with NYACC (thanks, Matt!).
> >
> >To help debugging things and for errors and warnings, it'd be nice
> >to "know" where the current LHS non-terminal starts in the source.

[...]

> I assume you mean providing source location information to the
> values (i.e, $1, etc).

Yes, basically.

I was just looking from the other end of the rule (and pictured
having a "special symbol" like $loc giving the "start point" of
the curent LHS). Both would be equivalent, I think.

>   I've thought about that a few times but have
> not arrived at anything intelligent.  Maybe using object properties
> (see sec 6.11 in Guile Ref) in the lexical analyzer, as you mention.

I didn't think of that -- it feels pretty "side-channel-y" at first,
but perhaps it's an elegant solution, after all.

Cheers
-- t


signature.asc
Description: Digital signature

Trying to get friends with SRFI-19

[tomas]

Hi,

I'm trying to parse some stuff, part of which are date
strings of the form "20200106", i.e. "MMDD". Since
I don't trust my input too much (or rather, my understanding
of it), I'd like to get a slap when my assumptions fail.

So I'd like to validate the date string.

SRFI-19 seems to be my friend. After checking that
everything is numeric, I try (the example is the
sixth of January 2020, at noon):

  (make-date 0 0 0 12 06 01 2020 7200)
  => #

So far so good. But if I try a bogus date (say, instead of
month 01 I pick 32):

  (make-date 0 0 0 12 06 32 2020 7200)
  => #

Ahem. Make-date happily accepts a month 32. This was
some surprise for me :)

Next I tried converting the thing to a Julian day and
back. My idea was that the conversion would "normalize"
the date representation, and if `equal' yields #t, we
have a sensible date.

This fails because after the double-conversion, the
time zone offset has shifted from 7200 to 3600, and
the two dates aren't equal?:

  (define d (make-date 0 0 0 12 06 01 2020 7200)) ; as above
  d
  => 

  (julian-day->date (date->julian-day d))
  => #

Obviously I am barking up the wrong tree (if it's
a tree at all).

Is there a canonical way to validate a date string?

Confused. Thanks for any hint.

Cheers
-- tomás  


signature.asc
Description: Digital signature

[SOLVED] Trying to get friends with SRFI-19

[tomas]

On Mon, Jul 20, 2020 at 11:27:03PM +0200, to...@tuxteam.de wrote:
> Hi,
> 
> I'm trying to parse some stuff, part of which are date
> strings of the form "20200106", i.e. "MMDD" [...]

> Is there a canonical way to validate a date string?

I ended up rolling my own (and converting to SRFI-19 date
once validation says "OK").

Is there interest in such a thing? i.e.

 valid-date? (y m d) -> bool
 returns whether (y m d) is a valid Gregorian date.

I wouldn't mind putting it up somewhere, with a suitable
license.  OTOH, it's a whopping 36 lines or so, so perhaps
not worth it ;-D

Cheers
-- t


signature.asc
Description: Digital signature

Re: string-replace-substring is missing

[tomas]

On Wed, Jul 29, 2020 at 04:41:33PM +0200, Linus Björnstam wrote:
> Iirc that was quite recently introduced. Unless you are using a recent guile 
> (like 3.0.2 or 3.0.4) your guile installation does not have it.

Can confirm that: guile 3.0.4 here, string-replace-substring is available
from (ice-9 string-fun).

Cheers
-- t


signature.asc
Description: Digital signature

Re: Nyacc question: where are the actions bound?

[tomas]

On Thu, Jul 30, 2020 at 06:50:08AM -0700, Matt Wette wrote:
> On 3/8/20 3:14 AM, to...@tuxteam.de wrote:
> >Hi,
> >
> >I'm playing around with Nyacc: I found a first little use case
> >to get my feet wet.

[...]

> Hi Tomas, (I apologize for the ascii spelling)

Hey, no worries. I don't take such things too seriously ;)

> You may be able to do what you want with the following:
> 
> (define (parse)
>  (let ((raw-parser (make-lalr-parser)))
>    (raw-parser (gen-lexer

Hm. Have to wrap my head around it (at the moment, I'm fine
having the "semantic" functions bound in the module, and
your last patch lets pass another module/namespace explicitly,
so, short of local-eval, of which we don't know whether it's
a good idea [1] anyway, all my wishes came true.

So thanks, again

Cheers

[1] I'm still to pose a question on that in guile-user.

-- t


signature.asc
Description: Digital signature

Re: About exception handling again ...

[tomas]

Hey,

thanks to you both for this enjoyable collateral learning :)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Nyacc question: where are the actions bound?

[tomas]

On Thu, Jul 30, 2020 at 06:50:08AM -0700, Matt Wette wrote:
> On 3/8/20 3:14 AM, to...@tuxteam.de wrote:
> >Hi,
> >
> >I'm playing around with Nyacc: I found a first little use case

[...]

> >So I defined some function =collect= which will be called from
> >actions in the grammar.
> >
> >My question is: where is the stuff resolved which is mentioned
> >in grammar actions?

[...]

> Hi Tomas, (I apologize for the ascii spelling)
> You may be able to do what you want with the following:
> 
> (define (parse)
>  (let ((raw-parser (make-lalr-parser)))
>    (raw-parser (gen-lexer

OK, got it now. It doesn't actually address my problem above, but
you answered my question above anyway, and even made the environment
more flexible (that was the commit:

  commit 9f45ea29bfc22e53cf08c27a6fb9d2de581b2092
  Author: Matt Wette 
  Date:   Mon Mar 23 17:38:30 2020 -0700

  Author: Matt Wette
  Date:   Mar 23, 2020

  Add #:env option to specify module for evaluating parser actions
  * module/nyacc/parse.scm (make-lalr-parser): add #env
(make-lalr-parser/num , /sym) use (current-module) as default
  * test-suite/nyacc/lalr-01.test: add test case

so thanks a lot for that). I'm a happy camper :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: system command output different in guile than on command line

[tomas]

On Tue, Aug 04, 2020 at 09:34:22PM +, vapnik spaknik wrote:
> Hi,
> I'm trying to write some code to get the size of a diff of two files.
> If I run the following pipeline in my zsh shell:
> 
> > diff -ua /tmp/file1 /tmp/file2 | wc -c
> 
> it prints 215
> However when I run the following in guile:
> 
> guile> (system "diff -ua /tmp/file1 /tmp/file2 | wc -c")

Have you actually tried to compare both results?

There are a couple of things which could make a difference. The
one which first comes to mind would be different environments
(PATH, language settings in LANG, LC_).

One thing you might want to try (to keep most of your experimental
setup) would be:

  diff -ua /tmp/file1 /tmp/file2 > /tmp/delta1

and then

  guile> (system "diff -ua /tmp/file1 /tmp/file2 > /tmp/delta2")

...and then diff the diffs.

Cheers
-- t


signature.asc
Description: Digital signature

Re: system command output different in guile than on command line

[tomas]

On Wed, Aug 05, 2020 at 11:27:30AM +, vapnik spaknik via General Guile 
related discussions wrote:

[...]

> OK... I was being stupid.

We all are, most of us more often than not ;-)

>Another strange thing is that if I use the pipeline procedure to do the same 
>thing, then I get an exit code of 1 >from the wc command, but it still returns 
>the same result:

This is by design. Quote the "diff" man page:

  "Exit status is 0 if inputs are the same, 1 if different,
   2 if trouble."

That's probably so that you can do things in the shell like

  diff a b > /dev/null && echo "same" || echo "diff"

Cheers
-- t


signature.asc
Description: Digital signature

Re: http-client port encoding failed

[tomas]

On Fri, Sep 04, 2020 at 02:35:45PM -0500, mbcladw...@stihie.net wrote:
> 
> Hi,
> 
> I am using http-client to submit requests that contain extended
> Latin characters e.g. "Marjanović+Ž".  I believe I have locales set
> up properly as I don't receive the "can't set locales" error.  Also
> I can regex with the extended Latin characters.
> 
> scheme@(guile-user)> (locale-encoding)
> $11 = "UTF-8"
> 
>  When I submit a url containing the above Serbian name, I get the error:
> 
> Throw to key `encoding-error' with args `("put-char" "conversion to
> port encoding failed" 84 # #\ć)'.

I'm not sure and can't double-check at the moment, but: the HTTP header
part (and the URL is part of it) /must/ be 7 bit ASCII. That's why there
is that URL encoding [1] -- basically you take the UTF-8 encoded string
and represent every byte (octet) beyond 0x7f (and some "hot" bytes
beneath that) by %, where  is the hexadecimal representation
of that byte.

Perhaps you have to URL-encode your URL before "submitting" it.

> If I paste the URL into my browser I receive the correct response.

Your browser does all of the above for you. It just doesn't tell you :)

> Prior to the request I use (set-port-encoding! (current-output-port)
> "UTF-8") without effect.

Hm. I don't know what the "right" encoding for a HTTP connection
is. But the HTTP header part is 7 biz ASCII (which is a subset
of UTF-8, but just that :)

The quintessence is: try url-encoding your URL.

Cheers
 - t


signature.asc
Description: Digital signature

Re: http-client port encoding failed

[tomas]

On Tue, Sep 08, 2020 at 09:26:57AM -0500, mbcladw...@stihie.net wrote:
> 
> Not sure I am doing exactly what you suggest but the following
> (based on your suggestion) seems to work:

Glad it helped :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Guile web server example serving static files

[tomas]

On Fri, Sep 18, 2020 at 07:56:04AM +0200, divoplade wrote:
> Hello Zelphir,

[...]

> As for why guile avoid reasoning about "paths", see 
> https://www.gnu.org/prep/standards/standards.html#GNU-Manuals
> https://www.gnu.org/prep/standards/standards.html#GNU-Manuals:
> 
> Please do not use the term “pathname” [...]

For completeness's sake, one should add that `path' is customary
in UNIX in the sense Zelphir used it (that's even mentioned in
the references you gave).

Something to keep in mind when talking to "other cultures" --
they are our neighbours, after all :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Guile web server example serving static files

[tomas]

On Sun, Sep 20, 2020 at 09:52:08AM +0200, divoplade wrote:
> Le dimanche 20 septembre 2020 à 09:48 +0200, to...@tuxteam.de a écrit :
> > Something to keep in mind when talking to "other cultures" --
> > they are our neighbours, after all :-)
> 
> I did not recommend using this term. There was a question in the source
> code asking why guile used a different terminology; I put the
> explanation why, with the relevant citation (because the section is
> huge). That's all.

Don't get me wrong: I think your hint is relevant and appropriate. It
makes sense to keep a consistent terminology whithin one context.

I just wanted to complement a bit: we should keep in mind that others
use a slightly different terminology (so a little clarification here
and there won't hurt).

Building bridges :-)

Cheers & thanks
 - t


signature.asc
Description: Digital signature

Re: Guile web server example serving static files

[tomas]

On Sun, Sep 20, 2020 at 10:54:50AM +0200, divoplade wrote:

[...]

> Yes, that's why I try to clarify where the strange "file name"
> terminology comes from.

We are in violent agreement, it seems :-)

thanks
 - t


signature.asc
Description: Digital signature

Re: Surprising behavior of eq?

[tomas]

On Sun, Sep 20, 2020 at 05:37:45PM +0200, Zelphir Kaltstahl wrote:
> Hello John, hello Stefan!

[...]

> Of course SO is not a standard. Either it is simply wrong, or I
> misunderstood "primitive values" in that phrase. I thought: "Ah strings
> are a primitive value, so eqv? should work in all cases when comparing
> strings." However, this has been debunked.

Strings are mutable in Guile, so probably not what's called "primitive
values":

  scheme@(guile-user)> (define str (string-copy "the quick brown fox"))
  scheme@(guile-user)> (string-set! str 6 #\a)
  scheme@(guile-user)> str
  $3 = "the quack brown fox"

But string literals bark at you if you try to mutate them (that's why
I slyly created that one with `string-copy'):

  scheme@(guile-user)> (define str "the quick brown fox")
  scheme@(guile-user)> (string-set! str 6 #\a)
  ice-9/boot-9.scm:1669:16: In procedure raise-exception:
  string is read-only: "the quick brown fox"

Cheers
 - t


signature.asc
Description: Digital signature

Source of guile-dbi

[tomas]

Hey guilers,

what is currently the canonical source of guile DBI? Is it
the github opencog one [1]? I'm asking because I didn't want
to (unnecessarily) go through github.

Is there any way to avoid github (without making maintainer's
life unnecessarily difficult, that is)?

Thanks for any insights

[1] https://github.com/opencog/guile-dbi.git
-- t


signature.asc
Description: Digital signature

Re: Source of guile-dbi

[tomas]

On Tue, Oct 06, 2020 at 01:22:09PM +0200, Ricardo Wurmus wrote:
> 
> Hi tomas,
> 
> > what is currently the canonical source of guile DBI? Is it
> > the github opencog one [1]? I'm asking because I didn't want
> > to (unnecessarily) go through github.
> 
> this works:
> 
> 
> http://web.archive.org/web/20170225155326/http://download.gna.org/guile-dbi/guile-dbi-2.1.6.tar.gz

Thanks :)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Source of guile-dbi

[tomas]

On Wed, Oct 07, 2020 at 04:14:22PM +0200, Zelphir Kaltstahl wrote:
> Hi Ricardo and hi Tomas!
> 
> On 10/6/20 1:22 PM, Ricardo Wurmus wrote:
> > Hi tomas,
> >
> >> what is currently the canonical source of guile DBI? Is it
> >> the github opencog one [1]? I'm asking because I didn't want
> >> to (unnecessarily) go through github.
> > this works:
> >
> > 
> > http://web.archive.org/web/20170225155326/http://download.gna.org/guile-dbi/guile-dbi-2.1.6.tar.gz
> I this outdated then?
> https://notabug.org/ZelphirKaltstahl/awesome-guile/src/master/list.md#databases

No, I think this is correct (have to double-check later).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Source of guile-dbi

[tomas]

On Wed, Oct 07, 2020 at 04:17:19PM +0200, to...@tuxteam.de wrote:
> On Wed, Oct 07, 2020 at 04:14:22PM +0200, Zelphir Kaltstahl wrote:
> > Hi Ricardo and hi Tomas!

[...]

> > > this works:
> > >
> > > 
> > > http://web.archive.org/web/20170225155326/http://download.gna.org/guile-dbi/guile-dbi-2.1.6.tar.gz
> > I this outdated then?
> > https://notabug.org/ZelphirKaltstahl/awesome-guile/src/master/list.md#databases
> 
> No, I think this is correct (have to double-check later).

It is correct (modulo fragment identifier -- it's

  
https://notabug.org/ZelphirKaltstahl/awesome-guile/src/master/list.md#org071e247

...blame Org for generating funny anchors :)

The repo is on Github, alas. Ricardo's alternative is a tarball.

If I had a wish (besides ponies, yay :), it'd be a mirror somewhere
at Savannah. But somebody else is doing the hard work, so I won't
complain...

Cheers & thanks (thanks also for awesome-guile!)
 - tomás



signature.asc
Description: Digital signature

Re: Writing a procedure in different style

[tomas]

On Sun, Dec 13, 2020 at 01:29:31PM +0100, Zelphir Kaltstahl wrote:
> Hello Taylan!
> 
> I tried your procedure and indeed it seems to work : )
> 
> I think what I had been missing before were 2 things:
> 
> 1. I did not have the (if (null? rest) ...) parts, so I always tried to
> directly make a recursive call, perhaps wrapped into a cons, append or

"When recurring on a list of atoms, /lat/, ask
two questions about it: /(null? lat)/ and *else*.
When recurring on a number, /n/, ask two
questions about it: /(zero? n)/ and *else*.
When recurring on a list of S-expressions, /l/,
ask three question about it: /(null? l)/, /(atom?
( car l))/, and *else*."

Daniel P. Friedman and Matthias Felleisen: The Little Schemer [1]
"First Commandment".

Now before this sounds arrogant or something: this is a botch
I'd be very likely to do myself. That's perhaps why this book,
which at first sight looks so harmless, was for me a joy to read.

Cheers

[1] 
https://pdfs.semanticscholar.org/35d0/d5275a8390c351ce98fbdc2ad37d210ba63b.pdf

 - t


signature.asc
Description: Digital signature

Re: Writing a procedure in different style

[tomas]

On Sun, Dec 13, 2020 at 04:01:24PM +0100, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> In some way what you write makes sense. Let me state here, that I did
> read that book and worked through it for a year though, even through the
> complicated parts like the y-combinator and some chapters I must have
> read like 4 or 5 times and discovered new aspects on each try.

That's it -- I'm through some n-th iteration and still go "oh!" from
time to time :-D

> What is typically the case in the book is a different situation though,
> than what was in Taylan's procedure. Usually it is the list you are
> working on in that iteration, which you check for being (null? ...), not
> the thing, that you give as argument to a recursive call or as a return
> value, which you add in some way to the result. Usually the questions
> from the quote are asked once the argument is received in the next
> iteration. That I definitely usually do, but in Taylan's answer there is
> an (if (null? ...) ...) for the `rest`, inside the case, where the usual
> (null? ...) check is already done on the subtree, which we recur on.

I have the hunch that this is only shifting things one level
up or down the stack, but basically, it's the same principle
at work. I'd have to fiddle for a while with that to see whether
I'm totally off, though.

Anyway, a reminder for me to do the n+1st iteration: "Do It, Do
It Again, and Again, and Again, ..." :-)

Thanks for that!

Cheers
 - t


signature.asc
Description: Digital signature

Re: Writing a procedure in different style

[tomas]

On Sun, Dec 20, 2020 at 06:57:34PM +0100, Zelphir Kaltstahl wrote:
> Hello Tomas!
> 
> I think you are right about it only being down one stack frame down. The
> checks are performed on what contains the next thing which is recurred on.

Nice explanation :)

> For a moment I thought "But isn't the null? check done twice in the
> first cond part?" [...]

This is one of the fantastic (and scary) things I often experience
in this (scheme-y) context (take SICP, or the Little Schemer).

Everything looks so easy, but whenever I try myself, I realise that
I've been taken along a path along high mountains, with breathtaking
views, and down there it gets messy and there are crocodiles.

It takes a long time to massage one's messy, lowly programs into a
form which approaches that deep beauty.

But it's fun :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: trace-calls-to-procedure

[tomas]

On Fri, Dec 25, 2020 at 06:58:00AM +0100, Zelphir Kaltstahl wrote:
> Hi Tim!
> 
> I do not know the answer to your question, but I noticed something else:
> trace-calls-to-procedure returns a procedure. That procedure and its
> return value can be applied infinitely, it seems:

[...]

> Not sure if that helps :D

Not the OP here, but look at what you've done: now I feel dizzy %-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: is there a way to serialize hash tables?

[tomas]

On Fri, Dec 25, 2020 at 09:27:49PM -0600, Tim Meehan wrote:
> I have a big-ish blob of key-value pairs that I would like to not have to
> store as text and then convert to a hashtable when I am filtering my data.
> 
> Right now I am saving it as an alist and then converting back to a
> hashtable using "alist->hashtable" from SRFI 69. I was just hoping that
> there was something more clever ... perhaps it is plenty clever enough.

If that "dumping/restoring" seems too expensive (have you measured it?),
then another alternative might be to use "external" dictionaries, like
guile-dbm [1] or guile-wiredtiger [2] 

Cheers

[1] https://www.gnuvola.org/software/guile-gdbm/
[2] https://guix.gnu.org/packages/guile-wiredtiger-0.7.0/

 - t


signature.asc
Description: Digital signature

Re: GNU Guile 3.0.5 released

[tomas]

On Thu, Jan 07, 2021 at 02:09:08PM +0100, Andy Wingo wrote:
> We are delighted to announce GNU Guile release 3.0.5, the latest in the
> 3.0 stable release series.

Wohoo!

Thanks to you all for all this hard work. And a happy 2021!

Cheers
 - t


signature.asc
Description: Digital signature

Re: SXML example showing diff between node-reduce and node-join

[tomas]

On Mon, Jan 11, 2021 at 05:44:41AM -0800, Matt Wette wrote:
> Hi All,
> 
> I'm going through the (sxml xpath) low-level routines to try to get a
> solid understanding of what they do.  I just can't come up with an example
> to show how node-reduce and node-join differ.   If someone could provide
> such an example I would really appreciate it.  Takers?
> 
> My end goal is to write up a cookbook type note to show peeps how to use it.

OK, I'll bite. But slowly. I'm not sure I'll reach to the end, but
have always been curious wrt the more interesting parts of SX...

CAVEAT: the word "combinator" alone makes my head spin. I know what
it is, when I read the definition slowly. But reading code written
in this style is still a bit challenging.

So it's quite possible that someone else beats me to it. That's
fine -- I'll eagerly learn from her/his answers :)

For a start, I'm reading [1], where Oleg Kiselyov and Kirill Lisovski
actually show some usage examples for both of the above functions.

Next, I'll actually try to play with them. Might take me a couple
of days. (After having no customers for a while, a couple of them
arrived at the same time. They always do, sigh, but I still love
them ;-)

Cheers

[1] http://okmij.org/ftp/papers/SXs-talk.pdf
 - t


signature.asc
Description: Digital signature

Re: open-pipe* seems to buffer all of my writes when I don't want it.

[tomas]

On Thu, Jan 14, 2021 at 10:56:42PM -0600, Tim Meehan wrote:
> I was trying to use Matplotlib to plot some data, through a call to
> "open-pipe*" ... I'm trying to slowly rewrite some of my tools in Scheme.
> 
> When I run the program from the shell with "python -i plotter.py" I can
> send it updates ... but when I run it through Guile, it seems to store up
> all of my updates [...]

Warning: untested. But perhaps you need to put a `force-output'...

[...]
> (put-string stuff program)
> (force-output stuff)
> 
> (let loop ([command (readline prompt)])
> (unless (string-prefix? "quit" command)
> (display "updating\n")
> (put-string stuff "update_data()\n")

... around here?

> (loop (readline prompt
> 
> (close-pipe stuff)

(I'm still surprised that setting the buffer to 'none didn't help).

Cheers
 - t


signature.asc
Description: Digital signature

Re: guile-hall issues converting my project to a hall project

[tomas]

On Sat, Feb 06, 2021 at 10:49:12PM +0100, Zelphir Kaltstahl wrote:
> Hello Guile Users!

Hi, Zelphir

not that I could help you in any way wrt. your guile-hall quest, but
thanks for your long and detailed report. Way better than silently
cursing at the screen and drinking too much coffe ;-)

An example to follow.

Cheers
 - t


signature.asc
Description: Digital signature

Re: A Web client with cache for guile!

[tomas]

On Sun, Feb 21, 2021 at 10:40:42PM +0100, Vivien Kraus via General Guile 
related discussions wrote:
> Dear guilers,
> 
> With the help of promises and futures, I was able to write a small
> caching web client for guile.
> 
> https://web-client-with-cache.planete-kraus.eu/

Exciting.

OK, my late afternoon reading has been taken care of :)

Thanks!
-- t


signature.asc
Description: Digital signature

Re: GOOPS question

[tomas]

On Sun, May 02, 2021 at 12:14:37PM +0200, Damien Mattei wrote:
> i use now the good way to loadmodule:
> 
> scheme@(guile-user)> (set! %load-path (reverse (cons "." (reverse
> %load-path

Apart from what Mikael says: if you want to modify `%load-path', you
typically want to add your "special" directories at the front (same
pattern as in the shell path): your local things take precedence,
the rest of the world is default :)

So no need for that double reverse. Unless you have some very special
requirement, that is.

Best of all (see the docs) is to use the function `add-to-load-path'
which adds your directory to the front :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: %load-path

[tomas]

On Sat, Jun 12, 2021 at 11:32:52AM +, Zelphir Kaltstahl wrote:
> Hello Damien,
> 
> Until today I was not aware, that there is a use-modules with slash notation.
> 
> I have found, that modifying the load-path is usually not, what I want in the
> end. I prefer to use the -L argument for telling Guile, which directories it
> should start "looking from" when processing the list in a (use-modules ...)
> expression.

And /if/ changing the load path, consider using `add-to-load-path' :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: re-writing algorithms in Guile

[tomas]

On Mon, Jun 28, 2021 at 04:38:50PM -0500, Tim Meehan wrote:
> Say for instance, I have found an algorithm for scalar function
> minimization on a website, written in C. It is posted with a license for
> use. If I write something based on this hypothetical code, is it then
> clearly also licensed in the same manner?

Definitely not: a license is about copyright, and copyright protects the
expression of an idea, not the idea itself (the Lord of the Rings is under
copyright, but if you write a novel involving very old talking trees, you
dont infringe on that).

For ideas there are patents. The situation on software patents is complicated,
to say the least.

You might want to not use exactly the same variable names, just to make sure :)

For an example where the line lies, more or less, in U.S. jurisdiction, see
the Oracle vs. Google case on the Java API (the question was whether the
"header files", which define the interface, are under copyright or not.

Note that this actually involves copying some files verbatim, so your example
lies far on the "safe side" of it.

NOTE: I'm not a lawyer, nor I play one on TV.

Cheers

[1] 
https://www.aei.org/technology-and-innovation/supreme-court-ingests-java-as-google-oracle-copyright-spat-boils-over/
[2] 
https://siliconangle.com/2021/04/05/supreme-court-rules-googles-favor-oracle-copyright-case-android-java-code-use/
[3] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
 - t


signature.asc
Description: Digital signature

Re: re-writing algorithms in Guile

[tomas]

On Tue, Jun 29, 2021 at 01:52:56PM +, Nate Rosenbloom wrote:
> 
> > This reason is not stated in the Stack Exchange post, and I believe
> > it’s inaccurate (although, I am not a lawyer either). I think the
> > reason is that you are reading the original implementation to write
> > your own, so you are some kind of a compiler, or translator (as for
> > human spoken languages). As such, what you write is mostly the other
> > person’s work, so you should not claim copyright about it.
> 
> Sorry, I should have been more specific, the rewritten algorithm would not be 
> the same, but it would be a derivative work and still covered by copyright of 
> the original work.

I think the legal concept of "derivative work" is far more complex than
we'd all like. See [1] to get an idea.

With the caveat that I'm not a lawyer (heh), I think the "red line" lies
between those two extremes: (a) you read the original, understand the
algorithm and write your program based on this understanding. Best if
you forget details like variable naming, program structure, etc. Only
the "pure" algorithm survives, and (b) you translate the program line
by line (although that would be pretty hard between C and, say, idiomatic
Scheme). (a) is almost certainly not a derivative work, while (b) would
be, most probably.

To make sure you can cleanly /prove/ you did (a), some do what is called
a "clean room implementation". Fred looks at the original program and
tells Gina "how it works", and Gina implements the new one.

Cheers

[1] https://copyleft.org/guide/comprehensive-gpl-guidech5.html

 - t


signature.asc
Description: Digital signature

Re: Applicable structs and vtables

[tomas]

On Fri, Aug 13, 2021 at 08:33:33PM +, Zelphir Kaltstahl wrote:
> Hi Guile users,
> 
> I have some code, in which I wrap procedures in a record, which contains
> members, which express the arity of the procedures. For example one struct be:
> 
> 

I don't know whether what you're after is about generalising what a
function can be ("callable objects" or similar), or if procedure
arity introspection at run time is your ultimate goal.

In the second case, there is `procedure-minimum-arity', which might
already cater to your wishes :-)

  (procedure-minimum-arity cons) ; takes two arguments, no "rest"
  => (2 0 #f)
  (procedure-minimum-arity +) ; takes at least 0, takes "rest"
  => (0 2 #t)
  (let ((foo (lambda (x y . z) ('some-result ; DIY
(procedure-minimum-arity foo))   ; at least 2, with "rest"
  => (2 0 #t)

I don't know (yet) what the middle number is for, though ;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Applicable structs and vtables

[tomas]

On Sat, Aug 14, 2021 at 09:19:49AM +, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> Ultimately I need the minimum and maximum arity of functions [...]

It seems that the second number in `procedure-minimum-arity's result
is the number of optional arguments (cf. `define*'). Since Guile 2.0,
optional args are in the core.

So that still might fit your bill. Or perhaps not ;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: backing out of debugger

[tomas]

On Tue, Sep 14, 2021 at 08:50:03AM -0400, Mortimer Cladwell wrote:
> Hi,
> Let's say I made a lot of mistakes. I look at my repl and see:
> scheme@(guile-user) [10]>
> 
> Any way to back out to scheme@(guile-user)> without typing ,q ten times?

Guile tells you :)

  scheme@(guile-user)> foo
  ;;; :7:0: warning: possibly unbound variable `foo'
  ice-9/boot-9.scm:1685:16: In procedure raise-exception:
  Unbound variable: foo
  
  Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

This [1] thingy coming next is the new prompt. So typing ,q gets me out
of it:

  scheme@(guile-user) [1]> ,q
  scheme@(guile-user)>

I'm not deep into that, but as far as I understand, the job of this
prompt is to keep information around about what went wrong, so you
can inspect it (e.g. with ,bt).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Double-precision floating point arithmetics behaves differently in Guile and in C

[tomas]

On Sun, Sep 26, 2021 at 10:45:51AM +0200, Panicz Maciej Godek wrote:
> Hi,
> 
> I recently ran into a very weird problem. I am using code for computing
> Singular Value Decomposition that's been ported do Scheme by Gerald Sussman
> as a part of the scmutils package (more specifically, I use some bits of
> code extracted from guile-scmutils

Hm. A couple of things to check would be: your C code is using "double"
floats (the Guile manual says the inexacts are `doubles')? Are your Guile
(what's its version anyway) and C program compiled for the same platform
(i.e. word width)?

Cheers
 - t


signature.asc
Description: Digital signature

Re: source tracking for nyacc parser is coming

[tomas]

On Fri, Oct 22, 2021 at 06:00:09AM -0700, Matt Wette wrote:
> Hi All,
> 
> I just wanted to give an update on this requested feature for nyacc.
> 
> I've been working on adding source location tracking to nyacc's
> parser.  I believe I have a working implementation.  It should
> appear in future release 1.06.0 (vs latest release 1.05.0) [...]

Yay!

I saw that pass by in the bug mailing list. Thanks!

I'll give it a spin.

Cheers
 - t


signature.asc
Description: Digital signature

Re: sxml-match bad pattern syntax

[tomas]

On Tue, Dec 28, 2021 at 01:21:31AM -0500, Thien-Thi Nguyen wrote:
> 
> In an effort to join the current millennium,

:-)

> i have started to
> play w/ Guile 2.x's SXML facilities.  Good stuff!  I've run into
> a problem, however, and hope i can get help resolving it here.
> 
> The following small program attempts to use ‘sxml-match’ to
> remove an unwanted attribute from a (well-formed) SXML snippet.

> #!/usr/bin/guile -s
> !#
> (use-modules
>  (sxml match))
> 
> (define (unbogus x)
>   (sxml-match x
> ((a (@ . ,attrs) ...)
>  `(a (@ ,@(delete '(shape "rect") attrs)) ...

I /think/ the ellipsis is at a wrong place there. Note that I'm coming
from "traditional" match, and I just have wrapped half of my brain
around that (which, BTW, is somewhat painful :-)

So take this with a grain of salt.

* Phenomenology (aka: I barely know what I'm doing):

If you replace your ellipses above by ". ,rest", things seem to work:

 (define (unbogus x)
   (sxml-match x
 ((a (@ . ,attrs) . ,rest)
  `(a (@ ,@(delete '(shape "rect") attrs)) . ,rest

 (unbogus '(a (@ (shape "rect") (href "foo.html")) "kid"))

 => (a (@ (href "foo.html")) "kid")

* Philosophy (aka blah, blah)

If those ellipses resemble what match do, I think they are wrong there:

  (@ . ,attrs) ...

would mean zero or more times the shape "(@ . ,attrs)". I think this
isn't what you want.

Put grains of salt everywhere :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: sxml-match bad pattern syntax

[tomas]

On Tue, Dec 28, 2021 at 02:58:56AM -0500, Thien-Thi Nguyen wrote:
> 
> () 
> () Tue, 28 Dec 2021 08:19:04 +0100
> 
>I /think/ the ellipsis is at a wrong place there [...]

> Haha, i know exactly how you feel.

%-)

> Ah, right!  The ellipses are a tail that need to follow a head.

No, the ellipses tell the matcher that the symbol to its left acutally
stands for "zero or more of this". Consequently, you have to somehow [1]
use those ellipses on the right hand side (aka template) whenever you use
them on the left hand side (aka pattern) and vice versa.

> I guess i was confused by the documentation's use of ellipses in
> the conventional sense rather than the literal sense:

I think of the ellipses as a kind of funny Kleene star. Not really at
home in any world: in the regular world, because it isn't a star, in
the Scheme world, because it is postfix.

So, to come back on your original example,

  (@ . ,attrs) ...

would match either empty (remember: zero or more) or

  (@ (foo 1) (bar 2))

or

  (@ (meep 1)) (@ "this ain't what we expected))

... so zero or more of (@ . stuff) where stuff stands for any
S-expression (note that it's sloppy: it will match things which aren't
lists of well-formed attribute lists [2]).

It won't match

  (@ (foo 1)) (@ (bar 2)) ("rumpelstilzchen")

for example.

> Anyway, thanks to your help, i've managed to cobble together the
> following code, attached here for the benefit of future self:

[...]

Thanks. And thanks for the code :)

> Maybe it's idiomatic.  Feedback on how to improve it welcome!

For the idiomatic part, I'll have to defer to those with more chevrons
;-)

Cheers

[1] Yes, some handwaving here.
[2] which isn't what you want to match, anyway. You want to match things
   with one attribute list in them.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: sxml-match bad pattern syntax

[tomas]

On Tue, Dec 28, 2021 at 04:21:39AM -0500, Thien-Thi Nguyen wrote:
> 
> () 
> () Tue, 28 Dec 2021 09:28:32 +0100
> 
>> Ah, right!  The ellipses are a tail that need to follow a
>> head.
> 
>No, the ellipses tell the matcher that the symbol to its left

[...]

> I think we're saying the same thing, but in any case, i
> understand what you're saying.

I see now. I was mis-reading you.

[...]

> I think the ‘otherwise’ clause is a bit unwieldy; it presumes
> normal form 3 (attribute lists always present).  However, i
> couldn't find a way to match "any element".  ISTM the element
> portion (first symbol in the form) MUST be non-variable.

At first blush it seems so. At least, when I try [1], it yells at
me with something something

  Throw to key `sxml-match-error' with args `(#f "bad pattern syntax (not an 
element pattern)" ...

Hm.

Cheers

[1] what I try is matching the tag to an unquoted var, like
   so (match ((,tag ...))).
-- 
t


signature.asc
Description: PGP signature

Re: [EXT] Option to create statically linked binaries

[tomas]

On Wed, Dec 29, 2021 at 02:52:20PM -0500, Thompson, David wrote:
> Hi Sai,
> 
> On Wed, Dec 29, 2021 at 1:14 PM Sai Karthik  wrote:
> >
> > Hello everyone! I'm new to guile. I am exploring the language since a
> > couple of days. It would be nice to have option to produce such binaries
> > for programs built using guile (like with golang & some more langs).
> 
> That is not possible. Guile is currently dependent upon having a
> bytecode interpreter installed on the machine that is running Guile
> programs. The good news is that native compilation is something that
> the Guile maintainers have planned for the future, which would enable
> things like self-contained binaries.

On top of that, GNU libc is (at least in parts, libnss I think)
dynamically linked anyway, AFAIK.

My hunch is that Guile's core depends on GNU libc.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: timestamp

[tomas]

On Sat, Feb 12, 2022 at 09:37:17AM +0100, adriano wrote:
> This
> 
> scheme@(guile-user)> (stat:ctime (stat "cat.jpg"))
> $5 = 1607841890
> 
> How do I get a timedate from that number ($5) ?

The traditional POSIX-ish functions are built in:

  (localtime 1607841890)
  => #(50 44 7 13 11 120 0 347 0 -3600 "CET")

  (strftime "%Y-%m-%d %H:%m:%s" (localtime 1607841890))
  => "2020-12-13 07:12:1607845490"

If you want to "go further", there is "SRFI-19 Time/Date conversions".

HTH
-- 
tomás


signature.asc
Description: PGP signature

Re: timestamp

[tomas]

On Sat, Feb 12, 2022 at 12:49:10PM +0100, Ricardo Wurmus wrote:
> 
> Hi adriano,
> 
> I’ve got no good answers as to “why” things are the way they are, but
> the manual explains the range of these values:
> 
> > It seesm to be
> >
> > (tm:mon %3)
> >
> > This returns
> >
> > 11
> >
> > I expected 12 but ok, I recognize this kind of weirdness
> 
>  -- Scheme Procedure: tm:mon tm
>  -- Scheme Procedure: set-tm:mon tm val
>  Month (0-11).
> 
> > I'm unhappy with 
> >
> > (tm:year $3)
> >
> > This returns
> >
> > 120
> >
> > it's 2020
> >
> > Why would 120 represent 2020 ?
> 
>  -- Scheme Procedure: tm:year tm
>  -- Scheme Procedure: set-tm:year tm val
>  Year (70-), the year minus 1900.
> 
> I don’t know why this would be useful, but that’s what it is ¯\_(ツ)_/¯

Oh. That is old POSIXy tradition :-)

Guile actually only passes along what libc provides, and I think it is a
good idea, in general. See the man page of localtime(3) on your next Linux-ish
box for all the details. If you prefer an online version, perhaps [1], [2]
convey an idea.

The year... those interfaces were developed well before the year 2000. It was
usual, Back Then (TM) to write down the year as a two-digit number (the 19
prefix was implied). Nobody could predict that the year 2000 was about to
arrive, honestly ;-)

As to the month... zero based numberings ease computations and setting up
name arrays (as in: 0: January, 1: February and so on).

Don't ask me why, though, the day of the month (1..31) is one-based. It is
the only exception :-)

But it makes for an easy calculation where you can add up the year (times
year length, taking leap years into account), the days-in-month so far for
full months and the current month day and things to arrive at the current
Epoch day. Guess one has to be one-based, otherwise you'll have to add 1 at
the end.

(This is all somewhat tongue-in-cheek ;-P

But it illustrates some other point: for folks coming from C and POSIX, (I
do), all that stuff feels "pretty natural", although it isn't, of course.

Cheers

[1] https://en.cppreference.com/w/c/chrono/localtime
[2] https://en.cppreference.com/w/c/chrono/tm

-- 
t


signature.asc
Description: PGP signature

Re: timestamp

[tomas]

On Sat, Feb 12, 2022 at 02:50:34PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 12 Feb 2022 10:01:25 +0100
> > From: 
> > 
> >   (strftime "%Y-%m-%d %H:%m:%s" (localtime 1607841890))
> >   => "2020-12-13 07:12:1607845490"
> 
> I guess you meant %H:%M:%S, not %H:%m:%s...

Good catch, Eli.

Bad tomas: next time read the strftime man page again, bad tomas.

;-D

Thanks
-- 
t


signature.asc
Description: PGP signature

Re: Shell commands with output to string

[tomas]

On Tue, Feb 22, 2022 at 09:38:35AM +, Zelphir Kaltstahl wrote:
> Corrections below.
> 
> On 2/22/22 10:29, Zelphir Kaltstahl wrote:
> > Hello Guile users!
> > 
> > How would I run a shell command from inside Guile and get its output as
> > a string, instead of the output being outputted directly? (Guile 3.0.8)

Sorry for the short answer (bad connectivity).

I think you want something like `popen' (use-modules (ice-9 popen)).

See the ref manual "Guile Modules" > POSIX > Pipes.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: good papers on graphics in scheme/lisp?

[tomas]

On Wed, Mar 02, 2022 at 12:34:32PM -0500, Olivier Dion via General Guile 
related discussions wrote:
> On Wed, 02 Mar 2022, Blake Shaw  wrote:

[...]

> > Also, one last thing, I'm considering attempting to create a DSL that
> > compiles to a subset of GLSL like Chicken's GLLS library[4], as I'm
> > becoming more and more interested in compilation. I remember reading
> > somewhere about a Guile library that allows you to write C in Guile,
> 
> I think you are refering to
> .
> 
> There's also  that can be helpful if
> you're familiar with LALR(1) parsers.

Actually NYACC comes with a pretty complete C99 compiler [1], which is
used to generate FFI bindings. So perhaps using that as a stepping stone
towards GLSL doesn't sound that crazy...

Cheers

[1] https://www.nongnu.org/nyacc/nyacc-c99-ug.html

-- 
t


signature.asc
Description: PGP signature

Re: good papers on graphics in scheme/lisp?

[tomas]

On Thu, Mar 03, 2022 at 02:35:09PM -0800, Matt Wette wrote:
> On 3/3/22 11:29 AM, Blake Shaw wrote:
> >  writes:

[...]

> > > Actually NYACC comes with a pretty complete C99 compiler [1], [...]

> Note nyacc comes with a c99 parser, not compiler.  mes has the back end.

Oops. I did write `compiler', did I?

Sorry for the confusion.

Cheers
-- 
t


signature.asc
Description: PGP signature