On 18 February 2014 17:00, marti.ma...@littlecms.com wrote:
Another release candidate, this time with the pthreads dependency.
Built fine on armv7hl, x86_64, i686 and passes the colord test suite, thanks!
Richard
--
Hello Richard,
Excellent! thanks for doing the testing.
Best regards
Marti
Quoting Richard Hughes hughsi...@gmail.com:
On 18 February 2014 17:00, marti.ma...@littlecms.com wrote:
Another release candidate, this time with the pthreads dependency.
Built fine on armv7hl, x86_64, i686 and
Hello,
Another release candidate, this time with the pthreads dependency. The
level of testing on this one is notably increased. Hopefully it would
take very few more to get this powerful but difficult release up and
working.
http://www.littlecms.com/lcms2-2.6rc3.tar.gz
GIT also can be
Am 13.02.2014 23:05, schrieb Graeme Gill:
marti.ma...@littlecms.com wrote:
Yep, that is how actually works, and this is the source of all pain.
What I really need is a sort function that given a pointer, would guess
if this points to a cmsContext internal structure or to used supplied
data.
On 14 February 2014 10:14, Kai-Uwe Behrmann k...@gmx.de wrote:
Escaping the incompatible APIs appears to me as the best suggestion so
far.
I don't think it's required:
commit 3e31c44f4cd6c44280cd18708cc2223dcddf670a
Author: Marti Maria i...@littlecms.com
Date: Fri Feb 14 09:44:26 2014 +0100
Hello everybody,
Thanks the feedback I got from you, I have spotted some
issues in release candidate 0, and tried to fix them.
As a result, we have now release candidate 1, which
can be downloaded from GIT or by using this tarball:
http://www.littlecms.com/lcms2-2.6rc1.tar.gz
- In this
On 14 February 2014 11:22, marti.ma...@littlecms.com wrote:
- Unfortunately this makes cmsCreateContext() not
thread-safe
Can't you just wrap it in a mutex?
I wish to thank you again for all your aid in
finding the issues the previous candidate had.
Thanks for fixing them :) I've built
Quoting Richard Hughes hughsi...@gmail.com:
On 14 February 2014 11:22, marti.ma...@littlecms.com wrote:
- Unfortunately this makes cmsCreateContext() not
thread-safe
Can't you just wrap it in a mutex?
This is actually my big headache. To do that, I need to add a pthreads
dependency.
On 14/02/2014 10:59, Richard Hughes wrote:
On 14 February 2014 11:58, marti.ma...@littlecms.com wrote:
This is actually my big headache. To do that, I need to add a pthreads
dependency.
Is that a problem? pthreads is available everywhere isn't it?
Well, not on Windows.
But presumably we
On Fri, 14 Feb 2014, marti.ma...@littlecms.com wrote:
This is actually my big headache. To do that, I need to add a pthreads
dependency.
Quite probably this is the best option at all. And pthreads will be
used as a default for read/write profile locking, which may be
overriden by locking
On 13 February 2014 00:01, marti.ma...@littlecms.com wrote:
Please feel free to download and check the CMM in your application
I've run the colord test suite against the new lcms2. There are a lot
of compiler warnings now like this:
In file included from cd-create-profile.c:27:0:
On 13/02/2014 10:18, Richard Hughes wrote:
On 13 February 2014 00:01, marti.ma...@littlecms.com wrote:
I've run the colord test suite against the new lcms2. There are a lot
of compiler warnings now like this:
In file included from cd-create-profile.c:27:0:
/usr/include/lcms2.h:1568:14:
On 13 February 2014 11:36, Robin Watts robin.wa...@artifex.com wrote:
Secondly, for people who happen to be using small positive integers for
the cmsContext value, Marti has a horrible hack/clever piece of
engineering in there that recognises this case and works around it.
Sure, and I fully
Hi Richard,
Much has been discussed about this new functionality and the
impact it will surely have on yet existing apps using THR
functions. The main drivers I used to take the decision were:
1) Any client using THR functions and the lib as shared object
is basically broken. if a client
On 13 February 2014 12:35, marti.ma...@littlecms.com wrote:
1) Any client using THR functions and the lib as shared object
is basically broken. if a client sets a listener or plug-in,
it got events from any other clients of the .so, with
obviously unexpected user data format. This
On 13 February 2014 13:22, Robin Watts robin.wa...@artifex.com wrote:
Personally, I have to say that I dislike the 'magically detect small
integer values' hack. I'd vote for ditching it if that's the thing
that's causing problems.
I think you nailed it with hack.
Possibly a stupid question,
On 13 February 2014 00:01, marti.ma...@littlecms.com wrote:
if something does not work, let us know
Another regression:
//gcc -o test test.c `pkg-config --cflags --libs lcms2` ./test
#include lcms2.h
#include stdlib.h
#include assert.h
int
main(int argc, char *argv[])
{
cmsHPROFILE p;
Another regression:
[...]
Note. If I'm not supposed to use cmsWriteTag(NULL) to remove a tag,
then I need some other way to do this. And if cmsWriteTag() is
supposed to fail, it should probably not make the cmsCloseProfile()
explode...
A genuine bug, thank you. On 2.6 erasing tags by using
On 13 February 2014 13:29, marti.ma...@littlecms.com wrote:
Valgrid complains and I'm concerned about that, but in some
cases it keeps working. Fixing the cases it does not work
is actually my first headache.
So, I can certainly port the libcolord stuff to using the new context
stuff in two
On Thu, 13 Feb 2014, Robin Watts wrote:
That's because the meaning of the 'cmsContext' has now changed in this
new version.
Previously cmsContext was 'any opaque void * value that the caller
wanted to provide'.
Now the cmsContext is a pointer to a (private) library defined structure
that
On 13 February 2014 15:18, marti.ma...@littlecms.com wrote:
A genuine bug, thank you. On 2.6 erasing tags by using NULL *is*
supported and documented (though you discovered to be buggy)
Confirmed fixed in git, thanks.
Richard
Quoting Bob Friesenhahn bfrie...@simple.dallas.tx.us:
I strongly recommend against releasing this new version of the
library until it is proven that existing software can be
successfully adapted to it.
Bob, this is exactly the point of release candidates. If we found
it to break
On Thu, 13 Feb 2014, marti.ma...@littlecms.com wrote:
Quoting Bob Friesenhahn bfrie...@simple.dallas.tx.us:
I strongly recommend against releasing this new version of the
library until it is proven that existing software can be
successfully adapted to it.
Bob, this is exactly the point of
Am 13.02.2014 17:51, schrieb marti.ma...@littlecms.com:
Still, the issue continues to be in how to differentiate cmsContext
from user data. If we could fix that, then compatibility would
be kept.
Just an idea:
typedef struct {
const char type_[8];
// more members here
void * user_data;
Quoting Kai-Uwe Behrmann k...@gmx.de:
Am 13.02.2014 17:51, schrieb marti.ma...@littlecms.com:
Still, the issue continues to be in how to differentiate cmsContext
from user data. If we could fix that, then compatibility would
be kept.
Just an idea:
Yep, that is how actually works, and
Quoting Bob Friesenhahn bfrie...@simple.dallas.tx.us:
These descriptions of static vs shared libraries don't make any
sense to me. On the planet I live on, programs using a shared
library always get private data and there is no sharing of data
between programs due to using a shared
On Thu, 13 Feb 2014, marti.ma...@littlecms.com wrote:
Obviously you are right and my description of the issue was wrong,
actually the reports I got was about an application using both lcms2
and another library which was using lcms2 as well. The app did set
its own memory management via a
On 13 February 2014 18:30, marti.ma...@littlecms.com wrote:
if (ptr 0x1) {
I'm right now open to other ideas.
Why not do the opposite? i.e. use the *first* bit rather than the last
-- malloc seems to always align the returned addresses to 32 bits on
my 64 bit platform. If the ctx
Hello everybody,
Those of you that are following the GIT page for lcms surely have
noticed a huge merge done today just few hours ago.
I've upgraded the repository to the latest development sources, which
includes a big amount of changes. Those comes from a great
contribution made by
29 matches
Mail list logo