Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

We are just using zip compression on eBible.org. On 11/02/2016 09:45 PM, Peter von Kaehne wrote: > I can categorically say that there are no released CW modules using any > compression other than zip. There might be some in our experimental repo. But > they would not be released so. > > I would

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

If memory serves, XZ and BZip2 only made it into 1.7 because I goofed. Working with branches in SVN is such a travesty that it led to a few accidental commits moved from trunk to the release branch despite not being intended as such. This is why I've been reluctant to make further releases on 1.7,

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

Experimental in the sense that there is no use found for them at this moment. We will not publish any modules until there is a) consensus and b) a valid preferential use case over the existing system. Sent from my phone. Apologies for brevity and typos.On 3 Nov 2016 1:52 pm, DM Smith

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

lzss is an early compression supported by SWORD and JSword. There is no need, other than policy, to refrain from using it. xz and bzip2 are fully supported by JSword. But not all frontends in the wild have it. I worked with Chris Little on both xz and bzip2 support. Him adding it to SWORD

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

I think the original rationale for the three experimental compression methods was to find something most suitable for limited resources devices. Given that my current phone has 100+ times RAM, 64 times HD equivalent space and 20 times the processor speed than the first desktop computer on which

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

The other two are not in use either. Re removing/keeping, ask Troy, that is his responsibility. Mine is to keep the modules sane. Peter Sent from my phone. Apologies for brevity and typos.On 3 Nov 2016 7:57 am, Jaak Ristioja wrote: > > Thanks you, Peter! Ok, so XzCompress

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

Thanks you, Peter! Ok, so XzCompress is experimental and the most common ZipCompress is considered stable. But what about LZSSCompress and Bzip2Compress? Will the experimental compression methods be removed from stable Sword releases in the future? J On 03.11.2016 09:45, Peter von Kaehne wrote:

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

I can categorically say that there are no released CW modules using any compression other than zip. There might be some in our experimental repo. But they would not be released so. I would think the same can be confirmed rapidly with all other official repos, Xiphos, IBT and eBible. I am

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

I just tried `./configure && make` Sword 1.7.4 and it did compile in xzcomprs.cpp. So I guess the stable releases DO include the experimental code. Usually it helps when experimental features have their own feature branches or similar. This not being a common practice in the Sword project, is

Re: [sword-devel] #include in xzcomprs.cpp - is this a bug or ?

Leaving aside the question of a bug, xzcompress.cpp is experimental code. It is not included in any releases so far AFAIK and should not be compiled into releases or used by frontends. At least under autotools you need to ask to include it. We have no modules created with it and would

[sword-devel] #include in xzcomprs.cpp - is this a bug or ?

In xzcomprs.cpp, at line 30, there’s the code: #include Xcode was not happy about this since there is no header named this. It seems that in the previous version of PocketSword, the fix was just to set Xcode as to not include this file when compiling so that’s what I’m doing too. Since the