On 5/24/2016 2:06 PM, Stefan Koch wrote:
> On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:
>> On 5/24/2016 1:27 PM, Guillaume Boucher wrote:
>>> There's no reason not to use the compression in the deco name.
>>>  Just make sure
>>> the references are relative and you're set.
>>
>> Not totally, since you'd like to refer to types that are common across deco
>> names.
>
> On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:
>
> A serious question, do these templates even need a mangle ?
> Is anyone ever going to call them from a different module ?
> I don't think you could do that because those are voldemort types.
>
> Those symbols are only temporary aren't they ?

The types do exist in the compiler, and are used in template name generation, generating types, etc.

On Tuesday, 24 May 2016 at 21:26:58 UTC, Walter Bright wrote:
> On 5/24/2016 2:06 PM, Stefan Koch wrote:
>> A serious question, do these templates even need a mangle ?
>> Is anyone ever going to call them from a different module ?
>> I don't think you could do that because those are voldemort types.
>>
>> Those symbols are only temporary aren't they ?
>
> The types do exist in the compiler, and are used in template name generation, generating types, etc.

But would one ever have to be able to reconstruct the mangle ?
templates cannot be exported nor can instanciations.
Or can they ?

On 5/24/2016 2:34 PM, Stefan Koch wrote:
> But would one ever have to be able to reconstruct the mangle ?

Symbolic debugging, and dealing with various linker errors.

> templates cannot be exported nor can instanciations.
> Or can they ?

Of course they can!

Am Tue, 24 May 2016 19:16:07 +0000
schrieb Anon <anon@anon.anon>:

> Upping it to sixteen levels:
> 
> current: Generate a 3_688_679 byte symbol
> lz4 -9: Generate a 3_688_679 byte symbol, then compress it to
> 15535 bytes
> lzma -9: Generate a 3_688_679 byte symbol, then compress it to
> 840 bytes
> BRNT: Generate a ~527 byte symbol
> 
> 
> 
> I want to let that sink in: in the general case, BRNT beats even **LZMA**.

Let's go this route. It seems to be a scalable solution without any big memory operations.

-- 
Marco

On Tuesday, 24 May 2016 at 20:25:18 UTC, Era Scarecrow wrote:
>  64 bytes? Hmm I had the impression it was going to be far larger...

 Well it's been a while since I last touched this topic (or code) so I'll post it, but there's 3 formulas written.


0) compress.c - control code, we are comparing against
1) compress_reduced.c, a drop-in replacement. Shouldn't be any issue with using, although doesn't compress or as fast as it could be.
2) compress_min.d, might need some API reworking, but other than that it is real fast by my tests.
3) compress_big.d, much more memory usage, but compresses similar to compress_min, but does much better compression on large objects that are more normal text like source code.

 For sheer speed compress_min is the best choice. although it may not compress as well.

Note: wideint.d is referenced for a compress test, you can change the script to use something else, or copy something and just fill the file in.

https://github.com/rtcvb32/Side-Projects/commit/452532904ca2d43af09bced31854eadc0395f406