Hi,
Hartmut Goebel skribis:
> Am 03.07.23 um 02:01 schrieb jgart:
>> Starting multiple workers:
>>
>> $ herd start microblog-tasks@{1..4}
>> $ herd status microblog-tasks@{1..4}
>
> Please note that this syntax is expanted by the shell! Thus these
> commands are the same as
>
> $ herd start
Am 03.07.23 um 02:01 schrieb jgart:
Starting multiple workers:
$ herd start microblog-tasks@{1..4}
$ herd status microblog-tasks@{1..4}
Please note that this syntax is expanted by the shell! Thus these
commands are the same as
$ herd start microblog-tasks@1 microblog-tasks@2
Hi,
"jgart" skribis:
> In other words being able to specify workers with shepherd:
>
> Starting multiple workers:
>
> $ herd start microblog-tasks@{1..4}
> $ herd status microblog-tasks@{1..4}
>
> Restarting a particular worker:
>
> $ herd restart microblog-tasks@3
>
> WDYT
I’ve never felt the
Hello,
On Sun, Jul 02, 2023 at 09:54 PM, Ludovic Courtès wrote:
> HI,
>
> John Kehayias skribis:
>
>> As one who also would like a shorter syntax option, here's a quick
>> thought: what about a short version of what we have for when there
>> is only one package given or it can be applied to all
Hi Ludo,
Is there any interest in having a syntax for shepherd for controlling multiple
workers?
>>>
Excerpt from
https://blog.miguelgrinberg.com/post/running-a-flask-application-as-a-service-with-systemd
Now I can start four workers using brace expansion in bash:
$ sudo systemctl
HI,
John Kehayias skribis:
> As one who also would like a shorter syntax option, here's a quick thought:
> what about a short version of what we have for when there is only one package
> given or it can be applied to all packages/be a positional argument? An
> example is perhaps best, so
Hello,
As one who also would like a shorter syntax option, here's a quick thought:
what about a short version of what we have for when there is only one package
given or it can be applied to all packages/be a positional argument? An example
is perhaps best, so what if we could write:
guix
Hello!
"jgart" skribis:
> Uses specified commit hash:
>
> guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567
>
> Uses specified commit hash (short):
>
> guix build emacs-ement@8b56efa
>
> Uses latest upstream release:
>
> guix build emacs-ement@latest
>
> Uses upstream version
I don't like the unpredictability of jgart's original proposal, but maybe
something explicit could still look similar.
Suppose you could build emacs-ement these three ways:
# no transform- this is a version packaged in Guix
guix build emacs-ement@0.5.2
# transform using `with-git-commit`
guix
> What disturbs me with your suggestion is that it reuses the same syntax
> that is already used for a different purpose. So in a sense you do
> "operator overloading", and the same command line then means different
> things depending on whether the package version is already provided by
> Guix or
Am Tue, May 23, 2023 at 02:12:02PM + schrieb jgart:
> > I think your semantics ends up meaning "try to make sense of the version
> > field, and give me the package at this version".
> Aren't these the current semantics of guix package transformations though?
> I'm just proposing shell syntax
Hi jgart,
On Tue, 23 May 2023 at 16:12, jgart wrote:
> Aren't these the current semantics of guix package transformations though?
> I'm just proposing shell syntax for them.
The main difference is explicit vs implicit. The current syntax is
explicit. The one you are proposing is implicit.
> I am a bit wary of too much intelligence in interpreting commands, at the
> expense of clarity
Hi Andreas,
I agree with this design aesthetic.
Personally, I like my software not too dumb and not too smart with a slight
bias towards the smart.
> I think your semantics ends up meaning "try
Hello,
Am Tue, May 23, 2023 at 01:24:00PM + schrieb jgart:
> I was openly ideating on having shell syntax like we do currently for
> emacs-ement@0.9.3, for example, but for a subset of package transformation
> options as well.
I am a bit wary of too much intelligence in interpreting
> WDYT about what? Could you be more specific and detail your idea?
Hi Simon,
I was openly ideating on having shell syntax like we do currently for
emacs-ement@0.9.3, for example, but for a subset of package transformation
options as well.
Does that clarify my intent?
If not, let me know to
Hi jgart,
On Tue, 23 May 2023 at 06:43, "jgart" wrote:
> Hi Guixers WDYT,
WDYT about what? Could you be more specific and detail your idea?
> Uses specified commit hash:
>
> guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567
>
> Uses specified commit hash (short):
>
> guix
On Tue, May 23, 2023 at 06:43:30AM +, jgart wrote:
> Hi Guixers WDYT,
>
> Uses specified commit hash:
>
> guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567
for a comparison, the current (long) version:
guix build emacs-ement
17 matches
Mail list logo
