Hi, all,
On Thu, 2011-03-03 at 09:41 +, Michael Meeks wrote:
> Perhaps one thing you could do - would be to help dung out the
> instsetoo_native/util dmake file, and check the tooling - such that we
> can build several install sets in parallel - that would help
> particularly wrt. help-
Hi Kami,
On Thu, 2011-03-03 at 00:14 +0100, Kálmán „KAMI” Szalai wrote:
> Compression time (in the tinderbox) was:
> runtime: 1087.37 (minutes)
> now:
> runtime: 1232.32 (minutes)
So it takes another 2:30 or so extra ? sounds like quite a lot.
Perhaps one thing you could do - wou
Compression time (in the tinderbox) was:
runtime: 1087.37 (minutes)
now:
runtime: 1232.32 (minutes)
Is it okay for us? Or it is too big penalty? I asked Fridrich to make
available the latest tb Windows build for download. I would like to
check the installer size and performance.
KAMI
--
Best re
Hi Michael,
2011-02-28 13:16 keltezéssel, Michael Meeks írta:
> Hi Kami,
>
> Wow - I'm so sorry, I missed your sexy mail for a week; that sucks -
> over-much merging on another branch :-) Tor has been on FTO, and
> Fridrich with his head down releasing 3.3.1 (and the Novell LibreOffice
> pro
Hi Wols,
On Tue, 2011-03-01 at 00:21 +, Wols Lists wrote:
> I checked on wikipedia after I posted and Huffman is actually SIXTY
> years old! Set as a class project, and published in 1952.
I tried to gently correct your thesis that Huffman is -the- optimal
compression algorithm for all
On 28/02/11 21:51, Michael Meeks wrote:
>> Why the surprise? How long has Huffman been around - 30 years? 40? And
>> > you CANNOT do better than Huffman (there are other equally as good
>> > algorithms, though).
> Ho hum; glad to know Huffman compression is optimal ;-) (personally I'd
> go f
Hi Wols,
On Mon, 2011-02-28 at 18:04 +, Wols Lists wrote:
> > So - personally, I find it amazing that ZIP is better than LZMA - ever,
> > it is such an older compression algorithm, and this flies in the face of
> > everything I've seen in practise with it [ eg. we use LZMA for our RPMs
> >
On 28/02/11 12:16, Michael Meeks wrote:
> Hi Kami,
>
> Wow - I'm so sorry, I missed your sexy mail for a week; that sucks -
> over-much merging on another branch :-) Tor has been on FTO, and
> Fridrich with his head down releasing 3.3.1 (and the Novell LibreOffice
> product) - which in part
Hi Kami,
Wow - I'm so sorry, I missed your sexy mail for a week; that sucks -
over-much merging on another branch :-) Tor has been on FTO, and
Fridrich with his head down releasing 3.3.1 (and the Novell LibreOffice
product) - which in part explains the lack of response to you (and
Steven)
Hi Michael and Friends of LibreOffice,
I ran few test to figure out what is the best method for installset
compressing (se the attached document and diagram). I cheated a bit,
because I used the tools (7z, zip, cabmake) and I didn't modified build
environment. So I downloaded LibO_3.3.1rc2_Win_x86
Hi Kalman,
On Sun, 2011-02-20 at 15:15 +0100, Kálmán „KAMI” Szalai wrote:
> I am sure we can shrink the installer more with better compression
Hah - so, of course Fridrich and Tor have looked into this - and
naturally you are right :-) there is a lot we can do. Clearly
compressing things
Hi,
After my last mail I created the required patches (3) for already built
LibO. A diffed against 3-3. Please test is if possible.
Please check the attached patches.
--
Best regards,
Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com
My favorite projects:
OxygenOffice Professional
Hi,
I am sure we can shrink the installer more with better compression
settings. Unfortunately I am not able to try these theory now because I
have problem with Windows based build system. So any participation
related to this topic is welcome
The current situation:
We are using double compression
13 matches
Mail list logo