On 6/4/2013 1:15 AM, Peter Alexander wrote:
> On Tuesday, 4 June 2013 at 08:03:15 UTC, Walter Bright wrote:
>> On 6/4/2013 1: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).
>>
>> Note also I didn't document it, so it is private and can be moved.
>
> Then it should be private.

I 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.

There's no point in having modules reinvent the wheel everytime. CircularBuffer is clearly usable in other contexts.

Reusing such code makes sure bug fixes and efficiency gains are done once and for all and work across the board.

>> I wanted to make at least one module that doesn't pull in 100% of
everything in Phobos

That seems like a very artificial exercise leading to unnecessary contorsions.

On Tue, Jun 4, 2013 at 1:00 AM, Walter Bright <newshound2@digitalmars.com>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).
>

On Tuesday, 4 June 2013 at 08:23:52 UTC, Walter Bright wrote:
>> 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.

import std.compress;
import mylib.circularbuffer;

CircularBuffer!(ubyte[1024]) buf;

ERROR: conflicting names, even though std.compress.CircularBuffer is private! I have to fully qualify CircularBuffer, or use alias to get around the problem.

D may not have a global namespace, but it does have unqualified name lookup, and private symbols still pollute that pseudo-namespace.

On 6/3/2013 8:44 PM, 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
>
> Comments welcome.

BTW, I also wrote this because it is a tricky component to write. There is not a 1:1 correspondence between input and output - the relationship is not predictable. Worse, there are "look backs" on input and "back patches" on output. Hence, sliding buffers have to be used on both input and output.

I like to think of it as an example of how to do such. It took me a bit of time to figure out a way to do it that wasn't too numbingly complex.

On 2013-06-04 08:40, Timothee Cour wrote:
> A)
> there already is std.zlib; why not have:
> std.compress.zlib: public import std.zlib
> std.compress.lzw: put this new module there instead of in std.compress
> std.compress.image.png
> std.compress.image.jpg
>
> B)
> rename:
> std.compress.lzwCompress => std.compress.lzw.compress
> std.compress. lzwExpand => std.compress.lzw.uncompress
>
> which is more consistent with compress/uncompress from std.zlib
>
> C)
> maybe add a link to
> https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch or other
> source
>
> D)
> CircularBuffer belongs somewhere else; maybe std.range or std.container

I agree with all of these.

Perhaps it should be put in the review queue as well.

-- 
/Jacob Carlborg

On Tuesday, 4 June 2013 at 08:33:29 UTC, Peter Alexander wrote:
> On Tuesday, 4 June 2013 at 08:23:52 UTC, Walter Bright wrote:
>>> 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.
>
> import std.compress;
> import mylib.circularbuffer;
>
> CircularBuffer!(ubyte[1024]) buf;
>
> ERROR: conflicting names, even though std.compress.CircularBuffer is private! I have to fully qualify CircularBuffer, or use alias to get around the problem.

Is this according to the specs though, or a bug? It was my
understanding that another module's private symbols should not
even be "seen" ?

On Tuesday, 4 June 2013 at 09:11:49 UTC, monarch_dodra wrote:
> On Tuesday, 4 June 2013 at 08:33:29 UTC, Peter Alexander wrote:
>> On Tuesday, 4 June 2013 at 08:23:52 UTC, Walter Bright wrote:
>>>> 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.
>>
>> import std.compress;
>> import mylib.circularbuffer;
>>
>> CircularBuffer!(ubyte[1024]) buf;
>>
>> ERROR: conflicting names, even though std.compress.CircularBuffer is private! I have to fully qualify CircularBuffer, or use alias to get around the problem.
>
> Is this according to the specs though, or a bug? It was my
> understanding that another module's private symbols should not
> even be "seen" ?

Well, the fix is currently in an unapproved DIP. I have no idea whether Walter intends to accept it or reject it. The discussion thread just seems to have died off.

http://wiki.dlang.org/DIP22

Timothee Cour:

> D)
> CircularBuffer belongs somewhere else; maybe std.range or std.container

If you are interested in adding a CircularBuffer to Phobos, then I'd like both that fixed sized one and a growing one like this:
http://rosettacode.org/wiki/Queue/Usage#Faster_Version

Bye,
bearophile

On Tuesday, 4 June 2013 at 11:18:45 UTC, bearophile wrote:
> If you are interested in adding a CircularBuffer to Phobos, then I'd like both that fixed sized one and a growing one like this:
> http://rosettacode.org/wiki/Queue/Usage#Faster_Version

Nitpick;

head = (head + 1) & ((cast(size_t)1 << power2) - 1);

can be

head = (head + 1) & (A.length - 1);

No? power2 seems superfluous. Also, left/right shifts by variable amount are very slow on some processors

Anyway, we'll really need allocators before we can add more allocating containers. Andrei? :-)

I actually wish we could have multiple modules in a single file. Correct me if I'm wrong, but if imported something and only used one type there, the linker should strip out the others, right?

But this doesn't happen because ModuleInfo references all kinds of things, and moduleinfo is referenced for constructors and such. This is useful and removing it is probably a bad idea.

Breaking up into packages is one idea but you can't always do it. What if you're doing some big string mixins? A single file is also a little easier to distribute.

But mixins is the case that is hard to work around since they by definition go into one file. If we could do something like mixin("module foo.mixin"~name~" { code }"); you could work around it.

Then you could isolate sections of generated code in their own logical modules, letting the linker kill those sections if they aren't actually used.