[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Long command line arguments using SRFI 37

From: Zelphir Kaltstahl
Subject: Re: Long command line arguments using SRFI 37
Date: Mon, 7 Jan 2019 15:08:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 1/5/19 2:22 PM, Catonano wrote:
> Il giorno ven 4 gen 2019 alle ore 19:55 Zelphir Kaltstahl
> <address@hidden <mailto:address@hidden>> 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:
>     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
> There is another library of examples that Tantalum pointed me to, this one
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]