Re: Which command-line handlers do you use most?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Which command-line handlers do you use most?

Santiago Bragagnolo
This are great news. Maybe you can extend Pharo launcher as a usage case for implantation! 

It would be really welcomed and useful.

Santiago

El lun., 9 de jul. de 2018 17:40, Damien Pollet <[hidden email]> escribió:
Hi all,

I'm starting to port / reimplement existing command line handlers using Clap. There's a dozen, but I wonder which ones are the most relied upon, because it's a good opportunity for refactoring the command line API as a whole and simplifying it or at least making it more orthogonal.

For instance I discovered there is a "perform" command, which is sort of redundant with the "eval" one. Similarly there are both a "configuration" and a "metacello" handlers which seem to have the same exact purpose…

Since Clap can exist besides the current command-line handlers, we can have a deprecation  period to minimize breakage and leave time for people to adapt before we kill old command line handlers for real.

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Reply | Threaded
Open this post in threaded view
|

Re: Which command-line handlers do you use most?

Herby Vojčík


Damien Pollet wrote on 9. 7. 2018 17:38:

> Hi all,
>
> I'm starting to port / reimplement existing command line handlers using
> Clap. There's a dozen, but I wonder which ones are the most relied upon,
> because it's a good opportunity for refactoring the command line API as
> a whole and simplifying it or at least making it more orthogonal.
>
> For instance I discovered there is a "perform" command, which is sort of
> redundant with the "eval" one. Similarly there are both a
> "configuration" and a "metacello" handlers which seem to have the same
> exact purpose…

The default (.st file), save, update, ge£

Herby

> Since Clap can exist besides the current command-line handlers, we can
> have a deprecation  period to minimize breakage and leave time for
> people to adapt before we kill old command line handlers for real.
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet

P.S.: What I would like regarding of the command-line, is if
linux/osx/windows did the same regarding save/no-save/quit/no-quit then
running .st file. I have to include #save:andQuit: send in my .st files
b/c in Win it keeps running. But I understand this is actually VMs
having different options on different platforms. Anyway, would be
_really_ nice.

Reply | Threaded
Open this post in threaded view
|

Re: Which command-line handlers do you use most?

Herby Vojčík


Herbert Vojčík wrote on 11. 7. 2018 14:48:

>
>
> Damien Pollet wrote on 9. 7. 2018 17:38:
>> Hi all,
>>
>> I'm starting to port / reimplement existing command line handlers
>> using Clap. There's a dozen, but I wonder which ones are the most
>> relied upon, because it's a good opportunity for refactoring the
>> command line API as a whole and simplifying it or at least making it
>> more orthogonal.
>>
>> For instance I discovered there is a "perform" command, which is sort
>> of redundant with the "eval" one. Similarly there are both a
>> "configuration" and a "metacello" handlers which seem to have the same
>> exact purpose…
>
> The default (.st file), save, update, ge£
>
> Herby
>
>> Since Clap can exist besides the current command-line handlers, we can
>> have a deprecation  period to minimize breakage and leave time for
>> people to adapt before we kill old command line handlers for real.
>>
>> --
>> Damien Pollet
>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> P.S.: What I would like regarding of the command-line, is if
> linux/osx/windows did the same regarding save/no-save/quit/no-quit then
> running .st file. I have to include #save:andQuit: send in my .st files

"when running"

> b/c in Win it keeps running. But I understand this is actually VMs
> having different options on different platforms. Anyway, would be
> _really_ nice.
>