Re: [xz-devel] [PATCH] String to filter and filter to string

2022-06-22 Thread Jigar Kumar
Hi

Is there any progress on this? Jia I see you have recent commits. Why can't you 
commit this yourself?

Jigar



Re: [xz-devel] [PATCH] String to filter and filter to string

2022-05-27 Thread Jigar Kumar
>> The next alpha release should be coming this year so I
>> don't think it will be as long as you think until it is in a stable
>> release.

> Patches spend years on this mailing list. 5.2.0 release was 7 years ago. 
> There is no reason to think anything is coming soon.

Over 1 month and no closer to being merged. Not a suprise.



Re: [xz-devel] [PATCH] String to filter and filter to string

2022-04-28 Thread Jigar Kumar
> I chose "+" since it was the most intuitive delimiter that wasn't a
> special character on most shells. If we used ";" or "|" they would
> either have to be escaped or require the command to be in quotation
> marks, which are both annoying to use as a command line argument. If
> you can think of a better character I would be interested to hear, but
> I don't think those are better.

I see. "+" is ok.

> I appreciate the feedback. This will certainly lead to improvements of
> the format. The next alpha release should be coming this year so I
> don't think it will be as long as you think until it is in a stable
> release. The contributors to this project are hobbyists so we can't
> dedicate 40+ hours a week for fast releases of high quality. Thank you
> for your understanding and if you want to help work on anything you
> can always submit a patch :)

Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There 
is no reason to think anything is coming soon.



Re: [xz-devel] [PATCH] String to filter and filter to string

2022-04-28 Thread jiat0218
On Thu, 28 Apr 2022 at 02:42, Jigar Kumar  wrote:

> The existing way to add filter chain is confusing so this change will be 
> good. I do not think the -s short op is good. --filters as the long op is 
> good no need for -s.

I was thinking the -s would be intuitive because it is short for
"string to filters", but if it is confusing or unneeded I can remove
it.

> The "+" is not the best character. What about using ";" or "|"?

I chose "+" since it was the most intuitive delimiter that wasn't a
special character on most shells. If we used ";" or "|" they would
either have to be escaped or require the command to be in quotation
marks, which are both annoying to use as a command line argument. If
you can think of a better character I would be interested to hear, but
I don't think those are better.

> It should show all option names and values. It matches the current output 
> with -vv option.

That is a good point. The extra verbosity is probably worth it so
users understand what filter options they are really using.

> > If anyone has any suggestions for improvements on the
> > string format, I am interested to hear them. I consider this patch a
> > draft and subject to change from community suggestions. Let me know
> > how this can be improved!
>
> I did not test your codes, but if they work then I think the format only 
> needs minor adjustments I suggest. Your efforts are good but based on the 
> slow release schedule it will unfortunatly be years until the community 
> actually gets this quality of life feature.

I appreciate the feedback. This will certainly lead to improvements of
the format. The next alpha release should be coming this year so I
don't think it will be as long as you think until it is in a stable
release. The contributors to this project are hobbyists so we can't
dedicate 40+ hours a week for fast releases of high quality. Thank you
for your understanding and if you want to help work on anything you
can always submit a patch :)

Jia Tan



Re: [xz-devel] [PATCH] String to filter and filter to string

2022-04-27 Thread Jigar Kumar
Hi

> These patches add lzma_str_to_filters and lzma_filters_to_str to
> liblzma and add a new "-s, --filters" option to xz.

The existing way to add filter chain is confusing so this change will be good. 
I do not think the -s short op is good. --filters as the long op is good no 
need for -s.

> The "=" delimits a filter name from a comma separated list of option
> value pairs. The "=" is optional and only needed if you want to
> override default options. For lzma1 and 2, a short hand for a preset
> can be used: lzma2={preset number}.
>
> The ":" delimits option name from option value.
>
> The "," delimits option value pairs from each other.
>
> The "+" delimits filters from each other.

The "+" is not the best character. What about using ";" or "|"?

> Right now, lzma_filters_to_str will only specify option names and
> values if they are different from the default. This can be changed to
> always display option names and values for all options if this is
> better.

It should show all option names and values. It matches the current output with 
-vv option.

> If anyone has any suggestions for improvements on the
> string format, I am interested to hear them. I consider this patch a
> draft and subject to change from community suggestions. Let me know
> how this can be improved!

I did not test your codes, but if they work then I think the format only needs 
minor adjustments I suggest. Your efforts are good but based on the slow 
release schedule it will unfortunatly be years until the community actually 
gets this quality of life feature.

Jigar