On 6/4/13 4:00 AM, Walter Bright wrote:
> On 6/3/2013 11:40 PM, Timothee Cour wrote:
>> D)
>> CircularBuffer belongs somewhere else; maybe std.range or std.container
>
> I have mixed feelings about that. If you'll notice, std.compress doesn't
> have any imports! I wanted to make at least one module that doesn't pull
> in 100% of everything in Phobos (one of my pet peeves).

The downside of that is reinventing everything. I haven't looked at the code yet, but std.range has http://dlang.org/phobos/std_range.html#cycle which implements a circular buffer.

Andrei

Am 04.06.2013 05:44, schrieb Walter Bright:
> https://github.com/WalterBright/phobos/blob/std_compress/std/compress.d
> 
> I wrote this to add components to compress and expand ranges.
> 
> Highlights:
> 
> 1. doesn't do any memory allocation
> 2. can handle arbitrarily large sets of data
> 3. it's lazy
> 4. takes an InputRange, and outputs an InputRange
> 
> Comments welcome.

Why do we need that? I would much rather have a deflate which doesn't depend on a C zlib (a proper std.zlib written in 100% D) and followed by a less buggy, less pita, less limited std.zip (btw. I think I fxed one of the bugs a while ago but it is still open and listed as bug on dlang.org).

I personally never used lzw compression and from what I know it is only used in GIF and TIFF (I might be wrong here), in comparison to deflate which is used in a varity of formats. So making std.compress only contain a rarely used compression algorithm feels wrong, having in it std.compress.* ok.

Peter Alexander:

> Nitpick;
>
> head = (head + 1) & ((cast(size_t)1 << power2) - 1);
>
> can be
>
> head = (head + 1) & (A.length - 1);
>
> No? power2 seems superfluous.

I see. Thank you. I will improve it later.

Bye,
bearophile

On 2013-06-04 05:44, Walter Bright wrote:
> https://github.com/WalterBright/phobos/blob/std_compress/std/compress.d
>
> I wrote this to add components to compress and expand ranges.
>
> Highlights:
>
> 1. doesn't do any memory allocation
> 2. can handle arbitrarily large sets of data
> 3. it's lazy
> 4. takes an InputRange, and outputs an InputRange

I'm wondering if (un)compress can take the compressing algorithm as a template parameter. Does that make sense?

Something like:

auto result = data.compress!(LZW);

Then we could pass different compressing algorithms to the compress function.

-- 
/Jacob Carlborg

04-Jun-2013 12:23, Walter Bright пишет:
> On 6/4/2013 1:15 AM, Peter Alexander wrote:
 agree.
>
>> You should also mangle the name so that it doesn't
>> pollute the unqualified symbol namespace (either that or fix
>> visibility of
>> private symbols).
>
> If it proves useful, it will be moved into some more proper and public
> place.
>
> I think it's a bad idea to 'mangle' the name. First off, if it is
> private, it is not visible. And even being public, the anti-hijacking
> language features make it a non-problem. The whole point is to avoid the
> wretched C problems with a global name space, by not having a global
> name space.
>
They are visible and clash with other symbols just like public do. Maybe now is the time fix this bug?

-- 
Dmitry Olshansky

On 6/4/2013 5:17 AM, Adam D. Ruppe wrote:
> I actually wish we could have multiple modules in a single file.

I don't see much point to that in modern file systems.

On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
> I'm wondering if (un)compress can take the compressing algorithm as a template
> parameter. Does that make sense?
>
> Something like:
>
> auto result = data.compress!(LZW);
>
> Then we could pass different compressing algorithms to the compress function.

I don't see the point. Furthermore, it requires that the compress template know about all the compression algorithms available, which limits future expansion.

On 6/4/2013 5:26 AM, Andrei Alexandrescu wrote:
> The downside of that is reinventing everything. I haven't looked at the code
> yet, but std.range has http://dlang.org/phobos/std_range.html#cycle which
> implements a circular buffer.

cycle only reads from a circular buffer. CircularBuffer can be filled as well as emptied at the same time (it has a put() method).

On Tuesday, 4 June 2013 at 16:09:09 UTC, Walter Bright wrote:
> On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
>> I'm wondering if (un)compress can take the compressing algorithm as a template
>> parameter. Does that make sense?
>>
>> Something like:
>>
>> auto result = data.compress!(LZW);
>>
>> Then we could pass different compressing algorithms to the compress function.
>
> I don't see the point. Furthermore, it requires that the compress template know about all the compression algorithms available, which limits future expansion.

Not necessarily. If the compression algorithms were free functions in the module you could just be passing an alias to one, which compress would then call. (which would also allow people to specify their own algorithms)

Am 04.06.2013 18:09, schrieb Walter Bright:
> On 6/4/2013 6:34 AM, Jacob Carlborg wrote:
>> I'm wondering if (un)compress can take the compressing algorithm as a
>> template
>> parameter. Does that make sense?
>>
>> Something like:
>>
>> auto result = data.compress!(LZW);
>>
>> Then we could pass different compressing algorithms to the compress function.
> 
> I don't see the point. Furthermore, it requires that the compress template know about all the compression algorithms available, which limits future expansion.
> 

No the compression type only has to provide a certain api.