unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@gmail.com>
To: Catonano <catonano@gmail.com>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: Long command line arguments using SRFI 37
Date: Mon, 7 Jan 2019 15:08:06 +0100	[thread overview]
Message-ID: <281bb613-8444-59f7-0956-c449ccc58804@gmail.com> (raw)
In-Reply-To: <CAJ98PDxi4pBpo5Uh22ejHUCX9FUeLOR4SFe4d28LfZzosOep0g@mail.gmail.com>


On 1/5/19 2:22 PM, Catonano wrote:
>
>
> Il giorno ven 4 gen 2019 alle ore 19:55 Zelphir Kaltstahl
> <zelphirkaltstahl@gmail.com <mailto:zelphirkaltstahl@gmail.com>> ha
> scritto:
>
>     Hi Guile Users,
>
>     I have a question regarding the usage of SRFI 37. Is it possible
>     to have
>     long arguments, which one can use as follows:
>
>     guile main.scm --argument value
>
>     This is what I am used to with other command line programs. It
>     seems to
>     me, when I use SRFI 37, I can only get it to allow the following style
>     of command line arguments:
>
>     guile main.scm --argument=value
>     guile main.scm --argument="some value"
>
>     It is not really a big issue, but I think it would still be great to
>     have a way of allowing the first style as well, as I just spend an
>     hour
>     or so trying to figure out what was wrong with my program, until I
>     took
>     a look at my example code (see link below) again and checked how it
>     behaved with style 1 and noticed it has the same error.
>
>     I have the example code, where I am trying to use SRFI 37, on:
>
>     https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/blob/dev/command-line-arguments/using-srfi-37.scm
>
>     Maybe I am missing something or doing something wrong?
>
>     Regards,
>
>     Zelphir
>
>
> Hi Zelphir,
>
> I can't help you with the processing of arguments with Guile, as I
> don't know the first thing about that
>
> I want to thank you for collecting that set of examples and tutorials
>
> I only skimmed through the macro section and it seems quite interesting
>
> Examples are very important and the Guile documentation sorely misses
> some examples
>
> Also, I also had the experience to struggle and waste lots of time
> with Guile for quite simple things, too
>
> For example, it too me some years to learn the usage of readline for a
> better REPL experience (this information is sinked deep in the manual)
>
> It also too me a long time to get the gist of the "eval buffer"
> command in Geiser
>
> You might be interested in this talk
> https://archive.fosdem.org/2017/schedule/event/legacy_docs/
>
> There is another library of examples that Tantalum pointed me to, this one
> https://github.com/sph-mn/sph-lib/tree/master/modules/sph/server
>
> Together with yours, this material is becoming meaningful, if not
> substantive
>
> Maybe the Guile website could point to these collections, maybe they
> could be merged into one library only, we'll see
>
> For now I just wanted to acknowledge your effort
>
> Thanks

The server example you linked to looks interesting. I still haven't used
fibers. I am planning to do so, when I finally get to port my decision
tree implementation from Racket to Guile, but I am not sure yet how to
best make use of fibers. I could imaging running a fiber for each
subtree (after each split a fiber could take care of learning the
subtree), but where to stop? How many fibers are good and how many will
cause no further speedup? And how to generalize that, so that I can
calculate how many fibers to use and how to know how many fibers there
are, without using global state and having concurrent modifications to
it … maybe a pool of available fibers would work, or maybe decision
trees are usually not that deep and starting a fiber for each subtree
will be fine, as their overhead is supposed to be little. Or maybe there
is not a general answer to this.

I also have some TCP server and TCP client example somewhere, which
could also make use of fibers, so maybe I can get some hints from the
code you linked.

I think however, there are many more things, for which examples would be
nice to have. I think the Guile manual actually does a pretty good job
of making things easy to discover, as far as procedures and modules go.
Just sometimes it could need a more complete example of usage or so. I
often wonder if I am doing things the way they should be done in Guile.
So I am glad my repository is of help for anyone. As I figure out how to
do things, I create the examples, so that I can look them up again once
I start something new. If it is helpful for others as well, then even
better.

Regards,

Zelphir



  reply	other threads:[~2019-01-07 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-04 18:55 Long command line arguments using SRFI 37 Zelphir Kaltstahl
2019-01-04 20:04 ` Amirouche Boubekki
2019-01-05 13:22 ` Catonano
2019-01-07 14:08   ` Zelphir Kaltstahl [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-01-06 12:07 tantalum
2019-01-06 22:57 ` Zelphir Kaltstahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=281bb613-8444-59f7-0956-c449ccc58804@gmail.com \
    --to=zelphirkaltstahl@gmail.com \
    --cc=catonano@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).