Hi Peter
Thanks. It is now fixed on git. Tomorrow I will release beta2 tarballs
with all fixes.
Best regards
Marti
Peter Speck wrote:
Hi Marti,
The subject was wrong in the previous emails. It should of course have been "beta
1".
I've tried building the new beta 2, and 'make check' fails
Hi Marti,
The subject was wrong in the previous emails. It should of course have been
"beta 1".
I've tried building the new beta 2, and 'make check' fails on 64-bit OSX: The
first call to DebugFree fails with "allocated by a different thread".
The reason is that the DebugMalloc/DebugFree funct
Quoting Peter Speck :
>
> --- building in 64 bit mode:
>
> ./configure --prefix=/my/path
> make
> make check
>
> This fails with:
> Arrr!!: Trying to free memory allocated by a different thread!
>
> Output:
> http://pastebin.com/nDeuAaxa
>
Good finding. Thanks so much for reporting.
As you ca
--- building in 64 bit mode:
./configure --prefix=/my/path
make
make check
This fails with:
Arrr!!: Trying to free memory allocated by a different thread!
Output:
http://pastebin.com/nDeuAaxa
--- building in 32 bit mode:
32-bit is forced using:
export CFLAGS="-arch i386"
export LDFLAGS="
Hi Bob.
Ok, done
Marti
Quoting Bob Friesenhahn :
> In the development lcms 2.0 API I see this:
>
> lcms2.h:#define LCMS_VERSION200
>
> which is a problem since existing using code does tests like
>
> #if defined(LCMS_VERSION) && (LCMS_VERSION > 1010)
>
> and 200 is numerically less tha
In the development lcms 2.0 API I see this:
lcms2.h:#define LCMS_VERSION200
which is a problem since existing using code does tests like
#if defined(LCMS_VERSION) && (LCMS_VERSION > 1010)
and 200 is numerically less than the previous versions. I suggest
appending another zero so that
Hi,
today have ported the lcms 1.16/1.17 Python bindings through ctypes mostly to
the lcms 2.0 preview. Some things are different, and I had to skip some other
things, but in general it worked quite well.
Some things that I have noticed, in no particular order of importance:
* I had to modify
Getting this back to LCMS 2.0. Looking at the code there have been some
significant changes in 2.0. For example it still has cmsSetErrorHandler() but
this is for backward compatibility and it now has support for creating an
error handler plug-in that appears to have more functionality although
On Wed, 17 Dec 2008, Guy K. Kloss wrote:
>
> Hmmm, if it were object oriented (e. g. C++) no callback would be necessary
> anyways, as then just an exception could be thrown, that is managed through
> the default exception handling mechanism. But if it were C++ code, it wouldn't
> be as easy to wra
On Wed, 17 Dec 2008 17:10:59 you wrote:
> It is true that with this approach only one C callback function can be
> registered at one time. Via inheritance, several different types of
> objects can simultaneously use lcms. If lcms was written in C++ then
> it could provide a base class for callbac
On Wed, 17 Dec 2008, Guy K. Kloss wrote:
>
>> If you are using an object oriented
>> language and lcms supports passing a pointer then you can pass the
>> address of 'this' object and the callback function can then invoke a
>> well known method name on the object so that the error is handled by
>>
On Wed, 17 Dec 2008 16:11:20 Bob Friesenhahn wrote:
> I am not sure which of the solution you say is a dirty workaround and
> depends on global variables.
As far as I understood the C code snippet, "cmsJumpBuffer" is a global
variable of type "jmp_buf".
> If you are using an object oriented
> l
On Wed, 17 Dec 2008, Guy K. Kloss wrote:
> Hi Hal and Bob,
> thanks for that info. It's a dirty workaround, and as it depends on
> global variables it will always bear the problem of potential
> failure in multi-threaded programs. Additionally, as I'm coding away
> in Python I don't have those
Hi Hal and Bob,
thanks for that info. It's a dirty workaround, and as it depends on global
variables it will always bear the problem of potential failure in multi-
threaded programs. Additionally, as I'm coding away in Python I don't have
those Dirty Old Tricks (TM) at hand, either.
And I belie
On Tue, 16 Dec 2008, Hal V. Engel wrote:
>
> What I do in my code is use this type of thing:
>
> #include
>
> jmp_buf cmsJumpBuffer;
This sort of approach does not work adequately/reliably for
multi-threaded applications. The whole setjmp mechanism is based on
restoring a single CPU's stack so
On Tuesday 16 December 2008 14:31:44 Guy K. Kloss wrote:
> Hi,
>
> I'm playing a bit with the preview of lcms 2.0 right now (more particularly
> with ctypes based Python bindings). I've seen in the code that the error
> handler again is just a callback function that is globally set.
>
> I'd appreci
Hi,
I'm playing a bit with the preview of lcms 2.0 right now (more particularly
with ctypes based Python bindings). I've seen in the code that the error
handler again is just a callback function that is globally set.
I'd appreciate it if some mechanism for error handling/reporting could be
fou
On Tuesday 04 November 2008 17:18:58 Guy K. Kloss wrote:
> On Wed, 05 Nov 2008 13:38:55 Hal V. Engel wrote:
> > The patch has the makefile. I only had to add the include for stddef.h
> > and add -fPIC to the CFLAGS line of the makefile that the patch created
> > and it built.
>
> Yes. My bad. Too
On Wed, 05 Nov 2008 13:38:55 Hal V. Engel wrote:
> The patch has the makefile. I only had to add the include for stddef.h and
> add -fPIC to the CFLAGS line of the makefile that the patch created and it
> built.
Yes. My bad. Too dumb to use a GUI app (Kompare) that my mailer launched on
the clic
On Tuesday 04 November 2008 13:34:23 Guy K. Kloss wrote:
> Thanks to Kai-Uwe and Hal for the proposed fixes. I got further, but it
> still doesn't want to build :-/
>
> On Mon, 03 Nov 2008 21:21:35 Kai-Uwe Behrmann wrote:
> > attached you will find a patch for basically compiling the library and
>
Thanks to Kai-Uwe and Hal for the proposed fixes. I got further, but it still
doesn't want to build :-/
On Mon, 03 Nov 2008 21:21:35 Kai-Uwe Behrmann wrote:
> attached you will find a patch for basically compiling the library and
> tifficc. It consists of a trivial makefile and some fixes/hacks (
On Monday 03 November 2008 00:21:35 Kai-Uwe Behrmann wrote:
> Hello,
>
> attached you will find a patch for basically compiling the library and
> tifficc. It consists of a trivial makefile and some fixes/hacks (take your
> pick;) to let the code run on Linux.
>
> hope this helps,
> Kai-Uwe Behrmann
Hello,
attached you will find a patch for basically compiling the library and
tifficc. It consists of a trivial makefile and some fixes/hacks (take your
pick;) to let the code run on Linux.
hope this helps,
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.
To check it out I have created a little SConscript file to build lcms2 as a
shared library (see the SConscript at end of mail). I don't know what other
libraries are needed, but I just assumed for now the usual candidates that
were also needed for versino 1.1.7 ['m', 'jpeg', 'tiff', 'z'].
Unfor
24 matches
Mail list logo
