hey,
that sucks. unfortunately your stack trace doesn't have any useful
debugging information, but i can reproduce.
maybe i should actually fix this into the main gui (without the opengl
bit then).
-jo
On Mon, Jan 21, 2013 at 10:51 PM, Togan Muftuoglu
wrote:
> Hi,
>
> With the latest git maste
Le 21/01/2013 22:39, jeremy rosen a écrit :
>> He propose to add asserts to drop params inclusion if an error occurs
> more precisely, add
>
> assert(iop version = last version lr knows about)
>
> somewhere in DT init for all iop used by lightroom
>
> this way whenever a dev changes a iop version,
Pascal,
I just have done a quick look at your code. You add a button somewhere
in darkroom, isn't it ?
So you read xmp from darkroom mode and change iop params directly ?
IMHO it's not the right place to do such stuff. AFAIK xmp
importing/exporting is usually done in the "file manager" (or call i
> He propose to add asserts to drop params inclusion if an error occurs
more precisely, add
assert(iop version = last version lr knows about)
somewhere in DT init for all iop used by lightroom
this way whenever a dev changes a iop version, DT will immediately
assert, and (hopefully) the code wo
Aldric,
> yes but this version can change. The principe here is drop the include
> "iop/h" and you replace it by duplicating the iop params structure.
> You add it to lightroom header as well as the iop version you pick the
> struct from
> When you save all that in the db,
I save nothing int
P
Le 21/01/2013 22:12, Pascal Obry a écrit :
> Aldric,
>
>> parafin propose a solution : duplicating struct and iop version in your
>> header, instead of including *.h
>> That way, you can create safe history stacks and if the iop version has
>> been updated, the iop legacy_params fct will update p
On 22/01/13 07:12 AM, Pascal Obry wrote:
>
> Aldric,
>
>> parafin propose a solution : duplicating struct and iop version in your
>> header, instead of including *.h
>> That way, you can create safe history stacks and if the iop version has
>> been updated, the iop legacy_params fct will update par
Aldric,
> parafin propose a solution : duplicating struct and iop version in your
> header, instead of including *.h
> That way, you can create safe history stacks and if the iop version has
> been updated, the iop legacy_params fct will update params.
How is this supposed to work since I'm usin
Aldric,
> Sadly I have no idea how to avoid this (my coding are too poor, sorry)
At least one thing we can do is add a script to check that all modules
versions in lightroom.c corresponds to the ones in iop/*.c. It will be
easier to ensure that we are ready for a release.
How does that sounds?
Thanks for your answer,
The solution you propose is not really good imho. Because, from a dev
point of view this mean that each time you update a module, you would
have to ask you how to handle this in lightroom code. And as you know,
final design need lot of try, which doesn't suffer any delay
Aldric,
> Sadly I have no idea how to avoid this (my coding are too poor, sorry)
I have also no solution. But to me this is not a big problem... Well,
not the only big problem as when the new version of Lightroom will be
out an update of the import support will also be required.
For the lightro
Hi all (and hi Pascal)
I have a little concern about the actual lightroom implementation in the
code.
The context : As some of you know, I'm currently working on mask
implementation. This implies some changes to spot removal iop, as it
will reuse the forms used by masks.
So I have updated spot
Hi,
With the latest git master 1.1-798-g8c69c14, I get a segfault when I
want to use darktable-viewer for the latest collection of the library. I
can't say if that was also there in previous git versions
Attached is the debug
Thanks
Togan
this is darktable 1.1_798_g8c69c14 reporting a segfault:
13 matches
Mail list logo
