Menu
▾
▴
liborigin-devel — development related stuff
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(27) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
|
From: Ivan K. <ik...@di...> - 2024-12-20 12:43:43
|
Hello Stefan and thank you for the reply! On Fri, 20 Dec 2024 13:17:54 +0100 Stefan Gerlach <ste...@un...> wrote: > can you reupload the original file (it's deleted already) so i can > have a look? I can't promise anything, but maybe it's an issue that > can be fixed easily. Here's the link: https://0x0.st/XC3x.opj This one should expire in slightly less than a year. -- Best regards, Ivan |
|
From: Stefan G. <ste...@un...> - 2024-12-20 12:37:08
|
Hello Ivan,
can you reupload the original file (it's deleted already) so i can have a look?
I can't promise anything, but maybe it's an issue that can be fixed easily.
best,
Stefan
On 11/8/24 22:37, Ivan Krylov via Liborigin-devel wrote:
> Hello liborigin developers,
>
> I have noticed a problem reading some of my *.opj files. These are
> produced by an Origin version bundled with a fluorometer (CPYA 4.2979
> 99 W32). I seem to get wrong names for the spreadsheet contents: for
> example, for some (but not all) files and only some "excel" objects
> inside them I get the contents visible under "Sample - Blank XYZ" in
> Origin when I look at the spreadsheet named "Sample - Blank" in
> liborigin.
>
> If I resave the file in Origin 2018, the problem persists. If I remove
> spreadsheets to the right of the problematic one, the problem persists.
> If I remove "Sample - Blank XYZ" in Origin, save the file and look for
> the "Sample - Blank" spreadsheet in liborigin, I get an empty
> spreadsheet (0 rows, 0 columns). If I overwrite the contents of the
> spreadsheet in Origin, the problem persists. If I remove a spreadsheet
> to the left of the problematic one, the problem seems to vanish.
>
> The fluorometer software makes a lot of use of embedding, e.g. the
> first spreadsheet is actually a note extended over all the cells, and a
> lot of other spreadsheets are plots. I'm only interested in the data.
> Deleting the embeds doesn't seem to help.
>
> I was able to reduce a problematic file to slightly more than a
> megabyte, where the desired "Sample - Blank" spreadsheet actually shows
> up under the name "S1c/R1c Blank":
>
> # no data for name = "Sample - Blank"
> (gdb) p opj.parser.get()->excels[0].sheets[14]
> $19 = {<Origin::Window> = {name = "Sample - Blank", label = "",
> objectID = -1, hidden = false, state = Origin::Window::Normal,
> title = Origin::Window::Both, frameRect = {left = 0, top = 0,
> right = 0, bottom = 0}, creationDate = 0, modificationDate = 0,
> windowBackgroundColorGradient = Origin::NoGradient,
> windowBackgroundColorBase = {type = Origin::Color::Regular, {
> regular = 17 '\021', custom = "\021\000", starting = 17 '\021',
> column = 17 '\021'}}, windowBackgroundColorEnd = {
> type = Origin::Color::Regular, {regular = 17 '\021',
> custom = "\021\000", starting = 17 '\021', column = 17 '\021'}}},
> maxRows = 30, loose = true, sheets = 1,
> columns = std::vector of length 0, capacity 0}
>
> # expected data (1, 2, 3, 4...) under the wrong name "S1c/R1c Blank"
> (gdb) p opj.parser.get()->excels[0].sheets[6]
> $23 = {<Origin::Window> = {name = "S1c/R1c Blank", label = "",
> objectID = -1, hidden = false, state = Origin::Window::Normal,
> title = Origin::Window::Both, frameRect = {left = 0, top = 0,
> right = 0, bottom = 0}, creationDate = 0, modificationDate = 0,
> windowBackgroundColorGradient = Origin::NoGradient,
> windowBackgroundColorBase = {type = Origin::Color::Regular, {
> regular = 17 '\021', custom = "\021\000", starting = 17 '\021',
> column = 17 '\021'}}, windowBackgroundColorEnd = {
> type = Origin::Color::Regular, {regular = 17 '\021',
> custom = "\021\000", starting = 17 '\021', column = 17 '\021'}}},
> maxRows = 30, loose = true, sheets = 1,
> columns = std::vector of length 84, capacity 128 = {{name = "A",
> dataset_name = "DfAqDDD1_A@7", type = Origin::SpreadColumn::X,
> valueType = Origin::TextNumeric, valueTypeSpecification = 0,
> significantDigits = 6, decimalPlaces = 6,
> numericDisplayType = Origin::DefaultDecimalDigits,
> command = ";\r\n#range rS = $(page.tree.LTCONST.S1Blank)!;\r\nint numCols = rS.ncols; \r\n\r\nrange x = $(page.tree.LTCONST.S1Blank)!1;\r\nrange rx
> = 1;\r\nrx = x;\r\n\r\nint size = rx.GetSize();\r\ndouble start = rx[1];\r\ndouble "..., comment = "Sample - Blank\r\nnm", width = 9, index = 57,
> colIndex = 58, sheet = 6, numRows = 500, beginRow = 0, endRow = 500,
> data = std::vector of length 500, capacity 500 = {{
> m_type = Origin::Variant::V_DOUBLE, {m_double = 1,
> m_string = 0x3ff0000000000000}, {m_type = Origin::Variant::V_DOUBLE, {
> m_double = 2,
> m_string = 0x4000000000000000}, {m_type = Origin::Variant::V_DOUBLE, {
> m_double = 3,
> m_string = 0x4008000000000000}, {m_type = Origin::Variant::V_DOUBLE, { m_double = 4,
>
> Here's the opjfile.log from opj2dat parsing the file:
> https://bin.disroot.org/?7aec684f4da18c25#95w11RmCAc9s8Fm4GN4wjMzuSrz8vpz9xUC84dYS74yh
> (please let me know if you prefer text/plain attachments or a different
> paste service that allows 500-kilobyte text samples)
>
> And here's the file itself (1.2M):
> https://upload.disroot.org/r/zDkxeNw0#Zbgf8qn178+R1IANaGV3WZzoNQ5uOcIKE5TvlXfnDdU=
>
> I will be really grateful if you help me fix the problem or share a few
> hints on how to debug it further.
>
|
|
From: Ivan K. <ik...@di...> - 2024-11-08 21:37:22
|
Hello liborigin developers,
I have noticed a problem reading some of my *.opj files. These are
produced by an Origin version bundled with a fluorometer (CPYA 4.2979
99 W32). I seem to get wrong names for the spreadsheet contents: for
example, for some (but not all) files and only some "excel" objects
inside them I get the contents visible under "Sample - Blank XYZ" in
Origin when I look at the spreadsheet named "Sample - Blank" in
liborigin.
If I resave the file in Origin 2018, the problem persists. If I remove
spreadsheets to the right of the problematic one, the problem persists.
If I remove "Sample - Blank XYZ" in Origin, save the file and look for
the "Sample - Blank" spreadsheet in liborigin, I get an empty
spreadsheet (0 rows, 0 columns). If I overwrite the contents of the
spreadsheet in Origin, the problem persists. If I remove a spreadsheet
to the left of the problematic one, the problem seems to vanish.
The fluorometer software makes a lot of use of embedding, e.g. the
first spreadsheet is actually a note extended over all the cells, and a
lot of other spreadsheets are plots. I'm only interested in the data.
Deleting the embeds doesn't seem to help.
I was able to reduce a problematic file to slightly more than a
megabyte, where the desired "Sample - Blank" spreadsheet actually shows
up under the name "S1c/R1c Blank":
# no data for name = "Sample - Blank"
(gdb) p opj.parser.get()->excels[0].sheets[14]
$19 = {<Origin::Window> = {name = "Sample - Blank", label = "",
objectID = -1, hidden = false, state = Origin::Window::Normal,
title = Origin::Window::Both, frameRect = {left = 0, top = 0,
right = 0, bottom = 0}, creationDate = 0, modificationDate = 0,
windowBackgroundColorGradient = Origin::NoGradient,
windowBackgroundColorBase = {type = Origin::Color::Regular, {
regular = 17 '\021', custom = "\021\000", starting = 17 '\021',
column = 17 '\021'}}, windowBackgroundColorEnd = {
type = Origin::Color::Regular, {regular = 17 '\021',
custom = "\021\000", starting = 17 '\021', column = 17 '\021'}}},
maxRows = 30, loose = true, sheets = 1,
columns = std::vector of length 0, capacity 0}
# expected data (1, 2, 3, 4...) under the wrong name "S1c/R1c Blank"
(gdb) p opj.parser.get()->excels[0].sheets[6]
$23 = {<Origin::Window> = {name = "S1c/R1c Blank", label = "",
objectID = -1, hidden = false, state = Origin::Window::Normal,
title = Origin::Window::Both, frameRect = {left = 0, top = 0,
right = 0, bottom = 0}, creationDate = 0, modificationDate = 0,
windowBackgroundColorGradient = Origin::NoGradient,
windowBackgroundColorBase = {type = Origin::Color::Regular, {
regular = 17 '\021', custom = "\021\000", starting = 17 '\021',
column = 17 '\021'}}, windowBackgroundColorEnd = {
type = Origin::Color::Regular, {regular = 17 '\021',
custom = "\021\000", starting = 17 '\021', column = 17 '\021'}}},
maxRows = 30, loose = true, sheets = 1,
columns = std::vector of length 84, capacity 128 = {{name = "A",
dataset_name = "DfAqDDD1_A@7", type = Origin::SpreadColumn::X,
valueType = Origin::TextNumeric, valueTypeSpecification = 0,
significantDigits = 6, decimalPlaces = 6,
numericDisplayType = Origin::DefaultDecimalDigits,
command = ";\r\n#range rS = $(page.tree.LTCONST.S1Blank)!;\r\nint numCols = rS.ncols; \r\n\r\nrange x = $(page.tree.LTCONST.S1Blank)!1;\r\nrange rx
= 1;\r\nrx = x;\r\n\r\nint size = rx.GetSize();\r\ndouble start = rx[1];\r\ndouble "..., comment = "Sample - Blank\r\nnm", width = 9, index = 57,
colIndex = 58, sheet = 6, numRows = 500, beginRow = 0, endRow = 500,
data = std::vector of length 500, capacity 500 = {{
m_type = Origin::Variant::V_DOUBLE, {m_double = 1,
m_string = 0x3ff0000000000000}, {m_type = Origin::Variant::V_DOUBLE, {
m_double = 2,
m_string = 0x4000000000000000}, {m_type = Origin::Variant::V_DOUBLE, {
m_double = 3,
m_string = 0x4008000000000000}, {m_type = Origin::Variant::V_DOUBLE, { m_double = 4,
Here's the opjfile.log from opj2dat parsing the file:
https://bin.disroot.org/?7aec684f4da18c25#95w11RmCAc9s8Fm4GN4wjMzuSrz8vpz9xUC84dYS74yh
(please let me know if you prefer text/plain attachments or a different
paste service that allows 500-kilobyte text samples)
And here's the file itself (1.2M):
https://upload.disroot.org/r/zDkxeNw0#Zbgf8qn178+R1IANaGV3WZzoNQ5uOcIKE5TvlXfnDdU=
I will be really grateful if you help me fix the problem or share a few
hints on how to debug it further.
--
Best regards,
Ivan
|
|
From: Stefan G. <ste...@un...> - 2021-05-11 18:04:57
|
I just released 3.0.1. Thanks for helping out with the coordination.
best
Stefan
On 11/05/2021 19:27, Alexander Ploumistos wrote:
> Hello Stefan,
>
> I hadn't deleted the previous srpms and as a result I spent an hour
> building and rebuilding the wrong one, wondering why I'm not getting
> the documentation built…
> Everything seems fine, I think you can increment that last zero to one
> if you want.
> Thank you for all your work!
>
> Best regards,
> A.
>
>
> On Tue, May 11, 2021 at 4:47 PM Stefan Gerlach
> <ste...@un...> wrote:
>>
>> Hi Alexander,
>>
>> thanks. I fixed the GNUInstallDirs, made the doxygen doc build per default and build opj2dat with the dynamic lib if static is disabled in the
>> latest commit. I hope that fixes all issues :-)
>>
>> best
>> Stefan
>>
>>
>> On 11/05/2021 16:09, Alexander Ploumistos wrote:
>>> Hi Stefan,
>>>
>>> I had to add "include(GNUInstallDirs)" before "install" in the shared
>>> library section, e.g.
>>>
>>> --- a/CMakeLists.txt 2021-05-11 14:20:57.000000000 +0200
>>> +++ b/CMakeLists.txt 2021-05-11 15:52:50.279765255 +0200
>>> @@ -86,6 +86,7 @@
>>> VERSION ${PROJECT_VERSION}
>>> SOVERSION ${PROJECT_VERSION_MAJOR}
>>> )
>>> + include(GNUInstallDirs)
>>> install( TARGETS origin_shared
>>> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
>>> )
>>>
>>> otherwise the shared object files end up under /usr/lib even on 64-bit
>>> arches. I suppose the static library is also affected by this. Can the
>>> include statement go to the beginning of the file?
>>>
>>>
>>> The HTML documentation is no longer created, is there an extra
>>> configuration/build option I need to specify or did it get eaten up
>>> with the latest changes?
>>>
>>>
>>> I don't know anyone using opj2dat by itself, if anyone files a bug
>>> report, I'll need to find a way to build it along with the shared
>>> libraries, but for now it doesn't matter.
>>>
>>>
>>> Best regards,
>>> A.
>>>
>>>
>>> On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
>>> <ste...@un...> wrote:
>>>>
>>>> Hello Alexander,
>>>>
>>>> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
>>>> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
>>>>
>>>> Best regards,
>>>> Stefan
>>>>
>>>> On 11/05/2021 12:40, Alexander Ploumistos wrote:
>>>>> Hello Stefan,
>>>>>
>>>>> Thank you for taking care of this. It would be great to get a 3.0.1
>>>>> release, but not just yet; when I packaged the latest snapshot with
>>>>> the commits from SciDAVis, I came across a couple of issues:
>>>>> https://github.com/highperformancecoder/scidavis/issues/218
>>>>> They are not that important, but I think it would be better to get rid
>>>>> of them before the next release. Also, it might be a good idea to
>>>>> chime in on the issue or otherwise get in touch with the SciDAVis
>>>>> people, so as to avoid doing the work twice. If you get the chance to
>>>>> look at these, commit the changes and they can pick them up
>>>>> downstream. If they manage to get to them first, they should push them
>>>>> upstream.
>>>>> The later half of this discussion might also be of interest to you as well:
>>>>> https://github.com/highperformancecoder/scidavis/discussions/212
>>>>>
>>>>> Best regards,
>>>>> A.
>>>>>
>>>>> On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
>>>>> <ste...@un...> wrote:
>>>>>>
>>>>>> Hello Alexander,
>>>>>>
>>>>>> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
>>>>>> LabPlot now uses the system installed liborigin 3 if available.
>>>>>>
>>>>>> best wishes
>>>>>> Stefan
>>>>>>
>>>>>>> You can see the changes committed to SciDAVis's liborigin submodule here:
>>>>>>> https://github.com/SciDAVis/liborigin/commits/
>>>>>>> There are some fixes and cleanups and I don't think there's anything
>>>>>>> too SciDAVis-centric among them. Some of them will make my life more
>>>>>>> difficult as I'll probably need to refactor a few Fedora-specific
>>>>>>> workarounds with regard to cmake…
>>>>>>>
>>>>>>> From the point of view of a distribution package maintainer it would
>>>>>>> be great if all the work happened first in liborigin upstream or if
>>>>>>> any changes made downstream were pushed upstream (within a reasonable
>>>>>>> timeframe), so as to avoid forking and fragmentation. While git
>>>>>>> submodules are appealing, at least to consumers of projects, I think
>>>>>>> they tend to complicate things.
>>>>>>>
>>>>>>> Once you get a chance to look at the code, let me know what you think.
>>>>>>>
>>>>>>>
>>>>>>> Thank you and have a nice weekend,
>>>>>>> A.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
>>>>>>> <ste...@un...> wrote:
>>>>>>>>
>>>>>>>> Hello Alexander,
>>>>>>>>
>>>>>>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
>>>>>>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
>>>>>>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
>>>>>>>>
>>>>>>>> best wishes
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
>>>>>>>>> Hello Stefan, Miquel,
>>>>>>>>>
>>>>>>>>> I was about to update the Fedora packages of SciDAVis and its
>>>>>>>>> dependencies for which I am the maintainer and I realized that the
>>>>>>>>> changes committed to the SciDAVis branch of liborigin have not been
>>>>>>>>> incorporated yet into the "official" repository.
>>>>>>>>>
>>>>>>>>> In theory, the LabPlot should also depend on liborigin, but looking at
>>>>>>>>> the spec file, it seems that at some point one of the maintainers
>>>>>>>>> switched to the bundled version. Nevertheless, I'd like to abide by
>>>>>>>>> Fedora's rules and maintain a separate package - if possible - which I
>>>>>>>>> think it should be.
>>>>>>>>>
>>>>>>>>> Since the two of you are contributing to all of the above projects, I
>>>>>>>>> was wondering if you intend to merge the changes from SciDAVis to
>>>>>>>>> liborigin, so that there is one upstream source for everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> A.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Liborigin-devel mailing list
>>>>>>>>> Lib...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
>>>>>>
|
|
From: Alexander P. <ale...@gm...> - 2021-05-11 17:28:21
|
Hello Stefan,
I hadn't deleted the previous srpms and as a result I spent an hour
building and rebuilding the wrong one, wondering why I'm not getting
the documentation built…
Everything seems fine, I think you can increment that last zero to one
if you want.
Thank you for all your work!
Best regards,
A.
On Tue, May 11, 2021 at 4:47 PM Stefan Gerlach
<ste...@un...> wrote:
>
> Hi Alexander,
>
> thanks. I fixed the GNUInstallDirs, made the doxygen doc build per default and build opj2dat with the dynamic lib if static is disabled in the
> latest commit. I hope that fixes all issues :-)
>
> best
> Stefan
>
>
> On 11/05/2021 16:09, Alexander Ploumistos wrote:
> > Hi Stefan,
> >
> > I had to add "include(GNUInstallDirs)" before "install" in the shared
> > library section, e.g.
> >
> > --- a/CMakeLists.txt 2021-05-11 14:20:57.000000000 +0200
> > +++ b/CMakeLists.txt 2021-05-11 15:52:50.279765255 +0200
> > @@ -86,6 +86,7 @@
> > VERSION ${PROJECT_VERSION}
> > SOVERSION ${PROJECT_VERSION_MAJOR}
> > )
> > + include(GNUInstallDirs)
> > install( TARGETS origin_shared
> > LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> > )
> >
> > otherwise the shared object files end up under /usr/lib even on 64-bit
> > arches. I suppose the static library is also affected by this. Can the
> > include statement go to the beginning of the file?
> >
> >
> > The HTML documentation is no longer created, is there an extra
> > configuration/build option I need to specify or did it get eaten up
> > with the latest changes?
> >
> >
> > I don't know anyone using opj2dat by itself, if anyone files a bug
> > report, I'll need to find a way to build it along with the shared
> > libraries, but for now it doesn't matter.
> >
> >
> > Best regards,
> > A.
> >
> >
> > On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
> > <ste...@un...> wrote:
> >>
> >> Hello Alexander,
> >>
> >> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
> >> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
> >>
> >> Best regards,
> >> Stefan
> >>
> >> On 11/05/2021 12:40, Alexander Ploumistos wrote:
> >>> Hello Stefan,
> >>>
> >>> Thank you for taking care of this. It would be great to get a 3.0.1
> >>> release, but not just yet; when I packaged the latest snapshot with
> >>> the commits from SciDAVis, I came across a couple of issues:
> >>> https://github.com/highperformancecoder/scidavis/issues/218
> >>> They are not that important, but I think it would be better to get rid
> >>> of them before the next release. Also, it might be a good idea to
> >>> chime in on the issue or otherwise get in touch with the SciDAVis
> >>> people, so as to avoid doing the work twice. If you get the chance to
> >>> look at these, commit the changes and they can pick them up
> >>> downstream. If they manage to get to them first, they should push them
> >>> upstream.
> >>> The later half of this discussion might also be of interest to you as well:
> >>> https://github.com/highperformancecoder/scidavis/discussions/212
> >>>
> >>> Best regards,
> >>> A.
> >>>
> >>> On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
> >>> <ste...@un...> wrote:
> >>>>
> >>>> Hello Alexander,
> >>>>
> >>>> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
> >>>> LabPlot now uses the system installed liborigin 3 if available.
> >>>>
> >>>> best wishes
> >>>> Stefan
> >>>>
> >>>>> You can see the changes committed to SciDAVis's liborigin submodule here:
> >>>>> https://github.com/SciDAVis/liborigin/commits/
> >>>>> There are some fixes and cleanups and I don't think there's anything
> >>>>> too SciDAVis-centric among them. Some of them will make my life more
> >>>>> difficult as I'll probably need to refactor a few Fedora-specific
> >>>>> workarounds with regard to cmake…
> >>>>>
> >>>>> From the point of view of a distribution package maintainer it would
> >>>>> be great if all the work happened first in liborigin upstream or if
> >>>>> any changes made downstream were pushed upstream (within a reasonable
> >>>>> timeframe), so as to avoid forking and fragmentation. While git
> >>>>> submodules are appealing, at least to consumers of projects, I think
> >>>>> they tend to complicate things.
> >>>>>
> >>>>> Once you get a chance to look at the code, let me know what you think.
> >>>>>
> >>>>>
> >>>>> Thank you and have a nice weekend,
> >>>>> A.
> >>>>>
> >>>>>
> >>>>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
> >>>>> <ste...@un...> wrote:
> >>>>>>
> >>>>>> Hello Alexander,
> >>>>>>
> >>>>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
> >>>>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
> >>>>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
> >>>>>>
> >>>>>> best wishes
> >>>>>> Stefan
> >>>>>>
> >>>>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
> >>>>>>> Hello Stefan, Miquel,
> >>>>>>>
> >>>>>>> I was about to update the Fedora packages of SciDAVis and its
> >>>>>>> dependencies for which I am the maintainer and I realized that the
> >>>>>>> changes committed to the SciDAVis branch of liborigin have not been
> >>>>>>> incorporated yet into the "official" repository.
> >>>>>>>
> >>>>>>> In theory, the LabPlot should also depend on liborigin, but looking at
> >>>>>>> the spec file, it seems that at some point one of the maintainers
> >>>>>>> switched to the bundled version. Nevertheless, I'd like to abide by
> >>>>>>> Fedora's rules and maintain a separate package - if possible - which I
> >>>>>>> think it should be.
> >>>>>>>
> >>>>>>> Since the two of you are contributing to all of the above projects, I
> >>>>>>> was wondering if you intend to merge the changes from SciDAVis to
> >>>>>>> liborigin, so that there is one upstream source for everything.
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> A.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Liborigin-devel mailing list
> >>>>>>> Lib...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
> >>>>
|
|
From: Stefan G. <ste...@un...> - 2021-05-11 14:47:46
|
Hi Alexander,
thanks. I fixed the GNUInstallDirs, made the doxygen doc build per default and build opj2dat with the dynamic lib if static is disabled in the
latest commit. I hope that fixes all issues :-)
best
Stefan
On 11/05/2021 16:09, Alexander Ploumistos wrote:
> Hi Stefan,
>
> I had to add "include(GNUInstallDirs)" before "install" in the shared
> library section, e.g.
>
> --- a/CMakeLists.txt 2021-05-11 14:20:57.000000000 +0200
> +++ b/CMakeLists.txt 2021-05-11 15:52:50.279765255 +0200
> @@ -86,6 +86,7 @@
> VERSION ${PROJECT_VERSION}
> SOVERSION ${PROJECT_VERSION_MAJOR}
> )
> + include(GNUInstallDirs)
> install( TARGETS origin_shared
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> )
>
> otherwise the shared object files end up under /usr/lib even on 64-bit
> arches. I suppose the static library is also affected by this. Can the
> include statement go to the beginning of the file?
>
>
> The HTML documentation is no longer created, is there an extra
> configuration/build option I need to specify or did it get eaten up
> with the latest changes?
>
>
> I don't know anyone using opj2dat by itself, if anyone files a bug
> report, I'll need to find a way to build it along with the shared
> libraries, but for now it doesn't matter.
>
>
> Best regards,
> A.
>
>
> On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
> <ste...@un...> wrote:
>>
>> Hello Alexander,
>>
>> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
>> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
>>
>> Best regards,
>> Stefan
>>
>> On 11/05/2021 12:40, Alexander Ploumistos wrote:
>>> Hello Stefan,
>>>
>>> Thank you for taking care of this. It would be great to get a 3.0.1
>>> release, but not just yet; when I packaged the latest snapshot with
>>> the commits from SciDAVis, I came across a couple of issues:
>>> https://github.com/highperformancecoder/scidavis/issues/218
>>> They are not that important, but I think it would be better to get rid
>>> of them before the next release. Also, it might be a good idea to
>>> chime in on the issue or otherwise get in touch with the SciDAVis
>>> people, so as to avoid doing the work twice. If you get the chance to
>>> look at these, commit the changes and they can pick them up
>>> downstream. If they manage to get to them first, they should push them
>>> upstream.
>>> The later half of this discussion might also be of interest to you as well:
>>> https://github.com/highperformancecoder/scidavis/discussions/212
>>>
>>> Best regards,
>>> A.
>>>
>>> On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
>>> <ste...@un...> wrote:
>>>>
>>>> Hello Alexander,
>>>>
>>>> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
>>>> LabPlot now uses the system installed liborigin 3 if available.
>>>>
>>>> best wishes
>>>> Stefan
>>>>
>>>>> You can see the changes committed to SciDAVis's liborigin submodule here:
>>>>> https://github.com/SciDAVis/liborigin/commits/
>>>>> There are some fixes and cleanups and I don't think there's anything
>>>>> too SciDAVis-centric among them. Some of them will make my life more
>>>>> difficult as I'll probably need to refactor a few Fedora-specific
>>>>> workarounds with regard to cmake…
>>>>>
>>>>> From the point of view of a distribution package maintainer it would
>>>>> be great if all the work happened first in liborigin upstream or if
>>>>> any changes made downstream were pushed upstream (within a reasonable
>>>>> timeframe), so as to avoid forking and fragmentation. While git
>>>>> submodules are appealing, at least to consumers of projects, I think
>>>>> they tend to complicate things.
>>>>>
>>>>> Once you get a chance to look at the code, let me know what you think.
>>>>>
>>>>>
>>>>> Thank you and have a nice weekend,
>>>>> A.
>>>>>
>>>>>
>>>>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
>>>>> <ste...@un...> wrote:
>>>>>>
>>>>>> Hello Alexander,
>>>>>>
>>>>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
>>>>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
>>>>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
>>>>>>
>>>>>> best wishes
>>>>>> Stefan
>>>>>>
>>>>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
>>>>>>> Hello Stefan, Miquel,
>>>>>>>
>>>>>>> I was about to update the Fedora packages of SciDAVis and its
>>>>>>> dependencies for which I am the maintainer and I realized that the
>>>>>>> changes committed to the SciDAVis branch of liborigin have not been
>>>>>>> incorporated yet into the "official" repository.
>>>>>>>
>>>>>>> In theory, the LabPlot should also depend on liborigin, but looking at
>>>>>>> the spec file, it seems that at some point one of the maintainers
>>>>>>> switched to the bundled version. Nevertheless, I'd like to abide by
>>>>>>> Fedora's rules and maintain a separate package - if possible - which I
>>>>>>> think it should be.
>>>>>>>
>>>>>>> Since the two of you are contributing to all of the above projects, I
>>>>>>> was wondering if you intend to merge the changes from SciDAVis to
>>>>>>> liborigin, so that there is one upstream source for everything.
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> A.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Liborigin-devel mailing list
>>>>>>> Lib...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
>>>>
|
|
From: Alexander P. <ale...@gm...> - 2021-05-11 14:09:27
|
Hi Stefan,
I had to add "include(GNUInstallDirs)" before "install" in the shared
library section, e.g.
--- a/CMakeLists.txt 2021-05-11 14:20:57.000000000 +0200
+++ b/CMakeLists.txt 2021-05-11 15:52:50.279765255 +0200
@@ -86,6 +86,7 @@
VERSION ${PROJECT_VERSION}
SOVERSION ${PROJECT_VERSION_MAJOR}
)
+ include(GNUInstallDirs)
install( TARGETS origin_shared
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
)
otherwise the shared object files end up under /usr/lib even on 64-bit
arches. I suppose the static library is also affected by this. Can the
include statement go to the beginning of the file?
The HTML documentation is no longer created, is there an extra
configuration/build option I need to specify or did it get eaten up
with the latest changes?
I don't know anyone using opj2dat by itself, if anyone files a bug
report, I'll need to find a way to build it along with the shared
libraries, but for now it doesn't matter.
Best regards,
A.
On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
<ste...@un...> wrote:
>
> Hello Alexander,
>
> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
>
> Best regards,
> Stefan
>
> On 11/05/2021 12:40, Alexander Ploumistos wrote:
> > Hello Stefan,
> >
> > Thank you for taking care of this. It would be great to get a 3.0.1
> > release, but not just yet; when I packaged the latest snapshot with
> > the commits from SciDAVis, I came across a couple of issues:
> > https://github.com/highperformancecoder/scidavis/issues/218
> > They are not that important, but I think it would be better to get rid
> > of them before the next release. Also, it might be a good idea to
> > chime in on the issue or otherwise get in touch with the SciDAVis
> > people, so as to avoid doing the work twice. If you get the chance to
> > look at these, commit the changes and they can pick them up
> > downstream. If they manage to get to them first, they should push them
> > upstream.
> > The later half of this discussion might also be of interest to you as well:
> > https://github.com/highperformancecoder/scidavis/discussions/212
> >
> > Best regards,
> > A.
> >
> > On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
> > <ste...@un...> wrote:
> >>
> >> Hello Alexander,
> >>
> >> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
> >> LabPlot now uses the system installed liborigin 3 if available.
> >>
> >> best wishes
> >> Stefan
> >>
> >>> You can see the changes committed to SciDAVis's liborigin submodule here:
> >>> https://github.com/SciDAVis/liborigin/commits/
> >>> There are some fixes and cleanups and I don't think there's anything
> >>> too SciDAVis-centric among them. Some of them will make my life more
> >>> difficult as I'll probably need to refactor a few Fedora-specific
> >>> workarounds with regard to cmake…
> >>>
> >>> From the point of view of a distribution package maintainer it would
> >>> be great if all the work happened first in liborigin upstream or if
> >>> any changes made downstream were pushed upstream (within a reasonable
> >>> timeframe), so as to avoid forking and fragmentation. While git
> >>> submodules are appealing, at least to consumers of projects, I think
> >>> they tend to complicate things.
> >>>
> >>> Once you get a chance to look at the code, let me know what you think.
> >>>
> >>>
> >>> Thank you and have a nice weekend,
> >>> A.
> >>>
> >>>
> >>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
> >>> <ste...@un...> wrote:
> >>>>
> >>>> Hello Alexander,
> >>>>
> >>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
> >>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
> >>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
> >>>>
> >>>> best wishes
> >>>> Stefan
> >>>>
> >>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
> >>>>> Hello Stefan, Miquel,
> >>>>>
> >>>>> I was about to update the Fedora packages of SciDAVis and its
> >>>>> dependencies for which I am the maintainer and I realized that the
> >>>>> changes committed to the SciDAVis branch of liborigin have not been
> >>>>> incorporated yet into the "official" repository.
> >>>>>
> >>>>> In theory, the LabPlot should also depend on liborigin, but looking at
> >>>>> the spec file, it seems that at some point one of the maintainers
> >>>>> switched to the bundled version. Nevertheless, I'd like to abide by
> >>>>> Fedora's rules and maintain a separate package - if possible - which I
> >>>>> think it should be.
> >>>>>
> >>>>> Since the two of you are contributing to all of the above projects, I
> >>>>> was wondering if you intend to merge the changes from SciDAVis to
> >>>>> liborigin, so that there is one upstream source for everything.
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>> A.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Liborigin-devel mailing list
> >>>>> Lib...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
> >>
|
|
From: Stefan G. <ste...@un...> - 2021-05-11 12:34:43
|
Hello Alexander, i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues. If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues. Best regards, Stefan On 11/05/2021 12:40, Alexander Ploumistos wrote: > Hello Stefan, > > Thank you for taking care of this. It would be great to get a 3.0.1 > release, but not just yet; when I packaged the latest snapshot with > the commits from SciDAVis, I came across a couple of issues: > https://github.com/highperformancecoder/scidavis/issues/218 > They are not that important, but I think it would be better to get rid > of them before the next release. Also, it might be a good idea to > chime in on the issue or otherwise get in touch with the SciDAVis > people, so as to avoid doing the work twice. If you get the chance to > look at these, commit the changes and they can pick them up > downstream. If they manage to get to them first, they should push them > upstream. > The later half of this discussion might also be of interest to you as well: > https://github.com/highperformancecoder/scidavis/discussions/212 > > Best regards, > A. > > On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach > <ste...@un...> wrote: >> >> Hello Alexander, >> >> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea. >> LabPlot now uses the system installed liborigin 3 if available. >> >> best wishes >> Stefan >> >>> You can see the changes committed to SciDAVis's liborigin submodule here: >>> https://github.com/SciDAVis/liborigin/commits/ >>> There are some fixes and cleanups and I don't think there's anything >>> too SciDAVis-centric among them. Some of them will make my life more >>> difficult as I'll probably need to refactor a few Fedora-specific >>> workarounds with regard to cmake… >>> >>> From the point of view of a distribution package maintainer it would >>> be great if all the work happened first in liborigin upstream or if >>> any changes made downstream were pushed upstream (within a reasonable >>> timeframe), so as to avoid forking and fragmentation. While git >>> submodules are appealing, at least to consumers of projects, I think >>> they tend to complicate things. >>> >>> Once you get a chance to look at the code, let me know what you think. >>> >>> >>> Thank you and have a nice weekend, >>> A. >>> >>> >>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach >>> <ste...@un...> wrote: >>>> >>>> Hello Alexander, >>>> >>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin. >>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at >>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot. >>>> >>>> best wishes >>>> Stefan >>>> >>>> On 07/05/2021 23:04, Alexander Ploumistos wrote: >>>>> Hello Stefan, Miquel, >>>>> >>>>> I was about to update the Fedora packages of SciDAVis and its >>>>> dependencies for which I am the maintainer and I realized that the >>>>> changes committed to the SciDAVis branch of liborigin have not been >>>>> incorporated yet into the "official" repository. >>>>> >>>>> In theory, the LabPlot should also depend on liborigin, but looking at >>>>> the spec file, it seems that at some point one of the maintainers >>>>> switched to the bundled version. Nevertheless, I'd like to abide by >>>>> Fedora's rules and maintain a separate package - if possible - which I >>>>> think it should be. >>>>> >>>>> Since the two of you are contributing to all of the above projects, I >>>>> was wondering if you intend to merge the changes from SciDAVis to >>>>> liborigin, so that there is one upstream source for everything. >>>>> >>>>> >>>>> Best regards, >>>>> A. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Liborigin-devel mailing list >>>>> Lib...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel >> |
|
From: Alexander P. <ale...@gm...> - 2021-05-11 10:40:44
|
Hello Stefan, Thank you for taking care of this. It would be great to get a 3.0.1 release, but not just yet; when I packaged the latest snapshot with the commits from SciDAVis, I came across a couple of issues: https://github.com/highperformancecoder/scidavis/issues/218 They are not that important, but I think it would be better to get rid of them before the next release. Also, it might be a good idea to chime in on the issue or otherwise get in touch with the SciDAVis people, so as to avoid doing the work twice. If you get the chance to look at these, commit the changes and they can pick them up downstream. If they manage to get to them first, they should push them upstream. The later half of this discussion might also be of interest to you as well: https://github.com/highperformancecoder/scidavis/discussions/212 Best regards, A. On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach <ste...@un...> wrote: > > Hello Alexander, > > i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea. > LabPlot now uses the system installed liborigin 3 if available. > > best wishes > Stefan > > > You can see the changes committed to SciDAVis's liborigin submodule here: > > https://github.com/SciDAVis/liborigin/commits/ > > There are some fixes and cleanups and I don't think there's anything > > too SciDAVis-centric among them. Some of them will make my life more > > difficult as I'll probably need to refactor a few Fedora-specific > > workarounds with regard to cmake… > > > > From the point of view of a distribution package maintainer it would > > be great if all the work happened first in liborigin upstream or if > > any changes made downstream were pushed upstream (within a reasonable > > timeframe), so as to avoid forking and fragmentation. While git > > submodules are appealing, at least to consumers of projects, I think > > they tend to complicate things. > > > > Once you get a chance to look at the code, let me know what you think. > > > > > > Thank you and have a nice weekend, > > A. > > > > > > On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach > > <ste...@un...> wrote: > >> > >> Hello Alexander, > >> > >> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin. > >> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at > >> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot. > >> > >> best wishes > >> Stefan > >> > >> On 07/05/2021 23:04, Alexander Ploumistos wrote: > >>> Hello Stefan, Miquel, > >>> > >>> I was about to update the Fedora packages of SciDAVis and its > >>> dependencies for which I am the maintainer and I realized that the > >>> changes committed to the SciDAVis branch of liborigin have not been > >>> incorporated yet into the "official" repository. > >>> > >>> In theory, the LabPlot should also depend on liborigin, but looking at > >>> the spec file, it seems that at some point one of the maintainers > >>> switched to the bundled version. Nevertheless, I'd like to abide by > >>> Fedora's rules and maintain a separate package - if possible - which I > >>> think it should be. > >>> > >>> Since the two of you are contributing to all of the above projects, I > >>> was wondering if you intend to merge the changes from SciDAVis to > >>> liborigin, so that there is one upstream source for everything. > >>> > >>> > >>> Best regards, > >>> A. > >>> > >>> > >>> _______________________________________________ > >>> Liborigin-devel mailing list > >>> Lib...@li... > >>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel > |
|
From: Stefan G. <ste...@un...> - 2021-05-11 10:25:29
|
Hello Alexander, i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea. LabPlot now uses the system installed liborigin 3 if available. best wishes Stefan > You can see the changes committed to SciDAVis's liborigin submodule here: > https://github.com/SciDAVis/liborigin/commits/ > There are some fixes and cleanups and I don't think there's anything > too SciDAVis-centric among them. Some of them will make my life more > difficult as I'll probably need to refactor a few Fedora-specific > workarounds with regard to cmake… > > From the point of view of a distribution package maintainer it would > be great if all the work happened first in liborigin upstream or if > any changes made downstream were pushed upstream (within a reasonable > timeframe), so as to avoid forking and fragmentation. While git > submodules are appealing, at least to consumers of projects, I think > they tend to complicate things. > > Once you get a chance to look at the code, let me know what you think. > > > Thank you and have a nice weekend, > A. > > > On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach > <ste...@un...> wrote: >> >> Hello Alexander, >> >> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin. >> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at >> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot. >> >> best wishes >> Stefan >> >> On 07/05/2021 23:04, Alexander Ploumistos wrote: >>> Hello Stefan, Miquel, >>> >>> I was about to update the Fedora packages of SciDAVis and its >>> dependencies for which I am the maintainer and I realized that the >>> changes committed to the SciDAVis branch of liborigin have not been >>> incorporated yet into the "official" repository. >>> >>> In theory, the LabPlot should also depend on liborigin, but looking at >>> the spec file, it seems that at some point one of the maintainers >>> switched to the bundled version. Nevertheless, I'd like to abide by >>> Fedora's rules and maintain a separate package - if possible - which I >>> think it should be. >>> >>> Since the two of you are contributing to all of the above projects, I >>> was wondering if you intend to merge the changes from SciDAVis to >>> liborigin, so that there is one upstream source for everything. >>> >>> >>> Best regards, >>> A. >>> >>> >>> _______________________________________________ >>> Liborigin-devel mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel |
|
From: Alexander P. <ale...@gm...> - 2021-05-08 10:08:43
|
Hello Stefan, You can see the changes committed to SciDAVis's liborigin submodule here: https://github.com/SciDAVis/liborigin/commits/ There are some fixes and cleanups and I don't think there's anything too SciDAVis-centric among them. Some of them will make my life more difficult as I'll probably need to refactor a few Fedora-specific workarounds with regard to cmake… >From the point of view of a distribution package maintainer it would be great if all the work happened first in liborigin upstream or if any changes made downstream were pushed upstream (within a reasonable timeframe), so as to avoid forking and fragmentation. While git submodules are appealing, at least to consumers of projects, I think they tend to complicate things. Once you get a chance to look at the code, let me know what you think. Thank you and have a nice weekend, A. On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach <ste...@un...> wrote: > > Hello Alexander, > > i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin. > Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at > SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot. > > best wishes > Stefan > > On 07/05/2021 23:04, Alexander Ploumistos wrote: > > Hello Stefan, Miquel, > > > > I was about to update the Fedora packages of SciDAVis and its > > dependencies for which I am the maintainer and I realized that the > > changes committed to the SciDAVis branch of liborigin have not been > > incorporated yet into the "official" repository. > > > > In theory, the LabPlot should also depend on liborigin, but looking at > > the spec file, it seems that at some point one of the maintainers > > switched to the bundled version. Nevertheless, I'd like to abide by > > Fedora's rules and maintain a separate package - if possible - which I > > think it should be. > > > > Since the two of you are contributing to all of the above projects, I > > was wondering if you intend to merge the changes from SciDAVis to > > liborigin, so that there is one upstream source for everything. > > > > > > Best regards, > > A. > > > > > > _______________________________________________ > > Liborigin-devel mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/liborigin-devel > > |
|
From: Stefan G. <ste...@un...> - 2021-05-08 09:27:09
|
Hello Alexander, i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin. Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot. best wishes Stefan On 07/05/2021 23:04, Alexander Ploumistos wrote: > Hello Stefan, Miquel, > > I was about to update the Fedora packages of SciDAVis and its > dependencies for which I am the maintainer and I realized that the > changes committed to the SciDAVis branch of liborigin have not been > incorporated yet into the "official" repository. > > In theory, the LabPlot should also depend on liborigin, but looking at > the spec file, it seems that at some point one of the maintainers > switched to the bundled version. Nevertheless, I'd like to abide by > Fedora's rules and maintain a separate package - if possible - which I > think it should be. > > Since the two of you are contributing to all of the above projects, I > was wondering if you intend to merge the changes from SciDAVis to > liborigin, so that there is one upstream source for everything. > > > Best regards, > A. > > > _______________________________________________ > Liborigin-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/liborigin-devel > |
|
From: Alexander P. <ale...@gm...> - 2021-05-07 21:05:10
|
Hello Stefan, Miquel, I was about to update the Fedora packages of SciDAVis and its dependencies for which I am the maintainer and I realized that the changes committed to the SciDAVis branch of liborigin have not been incorporated yet into the "official" repository. In theory, the LabPlot should also depend on liborigin, but looking at the spec file, it seems that at some point one of the maintainers switched to the bundled version. Nevertheless, I'd like to abide by Fedora's rules and maintain a separate package - if possible - which I think it should be. Since the two of you are contributing to all of the above projects, I was wondering if you intend to merge the changes from SciDAVis to liborigin, so that there is one upstream source for everything. Best regards, A. |
|
From: Ivan K. <kry...@gm...> - 2020-04-30 16:42:31
|
Stefan, Miquel, Thanks for your answers. It's sad that there seems to be no publicly available information on the OPJU format or any tools that could help, but such is the life when one has to resort to the art of reverse engineering. I will share any useful code or other findings, should they happen. -- Best regards, Ivan |
|
From: Miquel <gbm...@gm...> - 2020-04-22 21:39:35
|
I didn't use any special tools. Just hexdump (from util-linux) and hex viewer of mc (midnight-commander), plus a C program and a python module I developed along with the liborigin-3.0.0 code. The python module is that of folder 'importOPJ' in 'origin_import' branch of SciDAVis repo, available at [1]. The C program is a simplified version of OriginAnyParser.cpp with an additional feature: the possibility to write files with portions of the OPJ data for further analysis with hexdump or the python module. As for the meaning of the different bytes, the vast majority of OPJ file parsing was done by Alex Kargovsky between April 2007 and March 2009 (see code at [2], [3]) best regards, Miquel [1] https://github.com/highperformancecoder/scidavis/tree/f8f5991632533a9224c8b1b5729f2ad0deed5400/importOPJ [2] https://github.com/BackupTheBerlios/qtiplot-svn/tree/8a620042d7c0ee29ab41043819daeb95f5c37f14/trunk/3rdparty/liborigin [3] https://github.com/BackupTheBerlios/qtiplot-svn/tree/85e14ad8d037716219e2fc617a723b8d04d27bc8/trunk/qtiplot/src/origin Missatge de Stefan Gerlach <ste...@un...> del dia dl., 20 d’abr. 2020 a les 13:54: > Thank you very much. Can you comment on the tools that you used to > reverse-engineer the OPJ format for anyone who wants to start a parser for > the OPJU format? That would be great :-) > > best wishes > Stefan > > On 2020-04-18 11:24, Miquel wrote: > > Not much else to comment on. The OPJ and OPJU formats are quite > different. > > One way to get the data from an OPJU file is by converting it to the > older OPJ format [1] > > > > best regards, > > Miquel > > > > [1] > https://www.originlab.com/doc/Quick-Help/Convert-OPJU-Project-File-Format-to-Older-OPJ > > |
|
From: Stefan G. <ste...@un...> - 2020-04-20 11:54:26
|
Thank you very much. Can you comment on the tools that you used to reverse-engineer the OPJ format for anyone who wants to start a parser for the OPJU format? That would be great :-) best wishes Stefan On 2020-04-18 11:24, Miquel wrote: > Not much else to comment on. The OPJ and OPJU formats are quite different. > One way to get the data from an OPJU file is by converting it to the older OPJ format [1] > > best regards, > Miquel > > [1] https://www.originlab.com/doc/Quick-Help/Convert-OPJU-Project-File-Format-to-Older-OPJ > > Missatge de Stefan Gerlach <ste...@un... <mailto:ste...@un...>> del dia dl., 13 d’abr. 2020 a les 21:28: > > Dear Ivan, > > sorry for the late reply. > You are right, the OPJU format seems to be very different than the old OPJ format. Maybe Miquel can comment on that because he did most of the > parsing work. I'm not familiar with the methods to revers-engineer the format, but i would like to hear about that too :-) > > best wishes > Stefan > > On 2019-08-24 19:39, Ivan Krylov wrote: > > Dear liborigin maintainers, > > > > How different is the new OPJU format from OPJ? How much is known about > > it? I have noticed that the library checks for the new "CPYUA" header, > > but the OPJU files I have are impossible to parse, and a cursory glance > > at the files suggests that they are, indeed, very different. For > > example, there is far less 0x0a bytes in OPJU files than in > > corresponding OPJ files, and the encoding seems to be much more > > compact, although similar byte patterns crop up now and then: > > > > OPJ: > > > > 00170620 0A 63 6F 6C 28 43 4A 29 .........col(CJ) > > 00170630 2A 32 2E 33 30 33 2F 30 2E 30 33 00 00 0A 00 00 *2.303/0.03..... > > 00170640 00 00 0A 00 00 00 00 0A 6F 00 00 00 0A 00 00 06 ........o....... > > 00170650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00170660 5C 8F C2 F5 28 5C EE 3F DB B6 6D DB B6 6D AB 3F \...(\.?..m..m.? > > 00170670 14 00 00 00 00 10 01 3E 00 3E 00 C2 FF C2 FF 00 .......>.>...... > > 00170680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00170690 00 00 00 47 52 31 00 00 00 00 00 00 00 00 00 00 ...GR1.......... > > 001706A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 001706B0 00 00 00 00 00 00 00 00 00 00 00 00 0A 14 00 00 ................ > > 001706C0 00 0A ..col(CI)*2.303/ > > > > OPJU: > > > > 000FBE70 0A 63 6F 6C 28 43 4A 29 2A 32 2E 33 30 33 2F ..col(CJ)*2.303/ > > 000FBE80 30 2E 30 33 00 00 0A 00 00 00 00 0A 00 00 00 80 0.03............ > > 000FBE90 2C 03 00 00 06 8D 11 5C 8F C2 F5 28 5C EE 3F DB ,......\...(\.?. > > 000FBEA0 B6 6D DB B6 6D AB 3F 14 81 0A 10 01 3E 00 3E 00 .m..m.?.....>.>. > > 000FBEB0 C2 FF C2 FF 91 03 47 52 31 A5 01 08 90 00 00 14 ......GR1....... > > 000FBEC0 00 00 00 0A ....col(CI)*2.30 > > > > For example, some short strings are prefixed with their length instead > > of being surrounded by NUL bytes, like 0x03 "GR1" in the example above > > or 0x07 "Book2_B" elsewhere in the same file. > > > > The data might also be compressed, since gnuplot commands > > > > plot for [i=0:7] 'file.opju' binary array=(-1) format="%double" skip=i not > > > > or > > > > plot for [i=0:3] 'file.opju' binary array=(-1) format="%float" skip=i not > > > > don't seem to reveal any structure, unlike they did for OPJ files (in > > the latter case, if I know typical range of values stored in the file > > and set it manually before plotting, I can usually see the data as they > > appear in the file). > > > > Is there a known methodology one could use to adapt the parser for > > the new format? > > > |
|
From: Miquel <gbm...@gm...> - 2020-04-18 09:24:52
|
Not much else to comment on. The OPJ and OPJU formats are quite different. One way to get the data from an OPJU file is by converting it to the older OPJ format [1] best regards, Miquel [1] https://www.originlab.com/doc/Quick-Help/Convert-OPJU-Project-File-Format-to-Older-OPJ Missatge de Stefan Gerlach <ste...@un...> del dia dl., 13 d’abr. 2020 a les 21:28: > Dear Ivan, > > sorry for the late reply. > You are right, the OPJU format seems to be very different than the old OPJ > format. Maybe Miquel can comment on that because he did most of the > parsing work. I'm not familiar with the methods to revers-engineer the > format, but i would like to hear about that too :-) > > best wishes > Stefan > > On 2019-08-24 19:39, Ivan Krylov wrote: > > Dear liborigin maintainers, > > > > How different is the new OPJU format from OPJ? How much is known about > > it? I have noticed that the library checks for the new "CPYUA" header, > > but the OPJU files I have are impossible to parse, and a cursory glance > > at the files suggests that they are, indeed, very different. For > > example, there is far less 0x0a bytes in OPJU files than in > > corresponding OPJ files, and the encoding seems to be much more > > compact, although similar byte patterns crop up now and then: > > > > OPJ: > > > > 00170620 0A 63 6F 6C 28 43 4A 29 > .........col(CJ) > > 00170630 2A 32 2E 33 30 33 2F 30 2E 30 33 00 00 0A 00 00 > *2.303/0.03..... > > 00170640 00 00 0A 00 00 00 00 0A 6F 00 00 00 0A 00 00 06 > ........o....... > > 00170650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ > > 00170660 5C 8F C2 F5 28 5C EE 3F DB B6 6D DB B6 6D AB 3F > \...(\.?..m..m.? > > 00170670 14 00 00 00 00 10 01 3E 00 3E 00 C2 FF C2 FF 00 > .......>.>...... > > 00170680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ > > 00170690 00 00 00 47 52 31 00 00 00 00 00 00 00 00 00 00 > ...GR1.......... > > 001706A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ > > 001706B0 00 00 00 00 00 00 00 00 00 00 00 00 0A 14 00 00 > ................ > > 001706C0 00 0A > ..col(CI)*2.303/ > > > > OPJU: > > > > 000FBE70 0A 63 6F 6C 28 43 4A 29 2A 32 2E 33 30 33 2F > ..col(CJ)*2.303/ > > 000FBE80 30 2E 30 33 00 00 0A 00 00 00 00 0A 00 00 00 80 > 0.03............ > > 000FBE90 2C 03 00 00 06 8D 11 5C 8F C2 F5 28 5C EE 3F DB > ,......\...(\.?. > > 000FBEA0 B6 6D DB B6 6D AB 3F 14 81 0A 10 01 3E 00 3E 00 > .m..m.?.....>.>. > > 000FBEB0 C2 FF C2 FF 91 03 47 52 31 A5 01 08 90 00 00 14 > ......GR1....... > > 000FBEC0 00 00 00 0A > ....col(CI)*2.30 > > > > For example, some short strings are prefixed with their length instead > > of being surrounded by NUL bytes, like 0x03 "GR1" in the example above > > or 0x07 "Book2_B" elsewhere in the same file. > > > > The data might also be compressed, since gnuplot commands > > > > plot for [i=0:7] 'file.opju' binary array=(-1) format="%double" skip=i > not > > > > or > > > > plot for [i=0:3] 'file.opju' binary array=(-1) format="%float" skip=i > not > > > > don't seem to reveal any structure, unlike they did for OPJ files (in > > the latter case, if I know typical range of values stored in the file > > and set it manually before plotting, I can usually see the data as they > > appear in the file). > > > > Is there a known methodology one could use to adapt the parser for > > the new format? > > > |
|
From: Stefan G. <ste...@un...> - 2020-04-13 19:47:34
|
Dear Ivan, sorry for the late reply. You are right, the OPJU format seems to be very different than the old OPJ format. Maybe Miquel can comment on that because he did most of the parsing work. I'm not familiar with the methods to revers-engineer the format, but i would like to hear about that too :-) best wishes Stefan On 2019-08-24 19:39, Ivan Krylov wrote: > Dear liborigin maintainers, > > How different is the new OPJU format from OPJ? How much is known about > it? I have noticed that the library checks for the new "CPYUA" header, > but the OPJU files I have are impossible to parse, and a cursory glance > at the files suggests that they are, indeed, very different. For > example, there is far less 0x0a bytes in OPJU files than in > corresponding OPJ files, and the encoding seems to be much more > compact, although similar byte patterns crop up now and then: > > OPJ: > > 00170620 0A 63 6F 6C 28 43 4A 29 .........col(CJ) > 00170630 2A 32 2E 33 30 33 2F 30 2E 30 33 00 00 0A 00 00 *2.303/0.03..... > 00170640 00 00 0A 00 00 00 00 0A 6F 00 00 00 0A 00 00 06 ........o....... > 00170650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 00170660 5C 8F C2 F5 28 5C EE 3F DB B6 6D DB B6 6D AB 3F \...(\.?..m..m.? > 00170670 14 00 00 00 00 10 01 3E 00 3E 00 C2 FF C2 FF 00 .......>.>...... > 00170680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 00170690 00 00 00 47 52 31 00 00 00 00 00 00 00 00 00 00 ...GR1.......... > 001706A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 001706B0 00 00 00 00 00 00 00 00 00 00 00 00 0A 14 00 00 ................ > 001706C0 00 0A ..col(CI)*2.303/ > > OPJU: > > 000FBE70 0A 63 6F 6C 28 43 4A 29 2A 32 2E 33 30 33 2F ..col(CJ)*2.303/ > 000FBE80 30 2E 30 33 00 00 0A 00 00 00 00 0A 00 00 00 80 0.03............ > 000FBE90 2C 03 00 00 06 8D 11 5C 8F C2 F5 28 5C EE 3F DB ,......\...(\.?. > 000FBEA0 B6 6D DB B6 6D AB 3F 14 81 0A 10 01 3E 00 3E 00 .m..m.?.....>.>. > 000FBEB0 C2 FF C2 FF 91 03 47 52 31 A5 01 08 90 00 00 14 ......GR1....... > 000FBEC0 00 00 00 0A ....col(CI)*2.30 > > For example, some short strings are prefixed with their length instead > of being surrounded by NUL bytes, like 0x03 "GR1" in the example above > or 0x07 "Book2_B" elsewhere in the same file. > > The data might also be compressed, since gnuplot commands > > plot for [i=0:7] 'file.opju' binary array=(-1) format="%double" skip=i not > > or > > plot for [i=0:3] 'file.opju' binary array=(-1) format="%float" skip=i not > > don't seem to reveal any structure, unlike they did for OPJ files (in > the latter case, if I know typical range of values stored in the file > and set it manually before plotting, I can usually see the data as they > appear in the file). > > Is there a known methodology one could use to adapt the parser for > the new format? > |
|
From: Ivan K. <kry...@gm...> - 2019-08-24 17:40:04
|
Dear liborigin maintainers, How different is the new OPJU format from OPJ? How much is known about it? I have noticed that the library checks for the new "CPYUA" header, but the OPJU files I have are impossible to parse, and a cursory glance at the files suggests that they are, indeed, very different. For example, there is far less 0x0a bytes in OPJU files than in corresponding OPJ files, and the encoding seems to be much more compact, although similar byte patterns crop up now and then: OPJ: 00170620 0A 63 6F 6C 28 43 4A 29 .........col(CJ) 00170630 2A 32 2E 33 30 33 2F 30 2E 30 33 00 00 0A 00 00 *2.303/0.03..... 00170640 00 00 0A 00 00 00 00 0A 6F 00 00 00 0A 00 00 06 ........o....... 00170650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00170660 5C 8F C2 F5 28 5C EE 3F DB B6 6D DB B6 6D AB 3F \...(\.?..m..m.? 00170670 14 00 00 00 00 10 01 3E 00 3E 00 C2 FF C2 FF 00 .......>.>...... 00170680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00170690 00 00 00 47 52 31 00 00 00 00 00 00 00 00 00 00 ...GR1.......... 001706A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 001706B0 00 00 00 00 00 00 00 00 00 00 00 00 0A 14 00 00 ................ 001706C0 00 0A ..col(CI)*2.303/ OPJU: 000FBE70 0A 63 6F 6C 28 43 4A 29 2A 32 2E 33 30 33 2F ..col(CJ)*2.303/ 000FBE80 30 2E 30 33 00 00 0A 00 00 00 00 0A 00 00 00 80 0.03............ 000FBE90 2C 03 00 00 06 8D 11 5C 8F C2 F5 28 5C EE 3F DB ,......\...(\.?. 000FBEA0 B6 6D DB B6 6D AB 3F 14 81 0A 10 01 3E 00 3E 00 .m..m.?.....>.>. 000FBEB0 C2 FF C2 FF 91 03 47 52 31 A5 01 08 90 00 00 14 ......GR1....... 000FBEC0 00 00 00 0A ....col(CI)*2.30 For example, some short strings are prefixed with their length instead of being surrounded by NUL bytes, like 0x03 "GR1" in the example above or 0x07 "Book2_B" elsewhere in the same file. The data might also be compressed, since gnuplot commands plot for [i=0:7] 'file.opju' binary array=(-1) format="%double" skip=i not or plot for [i=0:3] 'file.opju' binary array=(-1) format="%float" skip=i not don't seem to reveal any structure, unlike they did for OPJ files (in the latter case, if I know typical range of values stored in the file and set it manually before plotting, I can usually see the data as they appear in the file). Is there a known methodology one could use to adapt the parser for the new format? -- Best regards, Ivan |
|
From: Ivan K. <kry...@gm...> - 2019-05-14 20:39:25
|
On Mon, 13 May 2019 00:10:41 +0200 Stefan Gerlach <ste...@un...> wrote: > Providing patches would be very handy. Would the attached patches be okay? -- Best regards, Ivan |
|
From: Stefan G. <ste...@un...> - 2019-05-12 22:28:17
|
Dear Ivan, thank you very much for letting us know. Nice to know that liborigin is used in more and more projects. Providing patches would be very handy. I will check and apply them as soon as possible. best wishes Stefan On 5/12/19 9:40 PM, Ivan Krylov wrote: > Dear liborigin maintainers, > > As a maintainer of Ropj package[1], I had to make small fixes to > liborigin; all of them are available at [2]. > > I would like to propose at least some of them for merging back into > liborigin to prevent fragmentation. The changes include: > > - [3] prevent undefined behaviour caused by having invalid values in > enums and bools (direct assignment and uninitialised stack garbage) > - [4] prevent a small memory leak in projectTree caused by the whole > tree being placed below the feet of the tree, preventing it from > being freed by destructor > > And a smaller change required by CRAN policy: remove explicit > reference to std::cout from outputProjectTree[5], since R extensions > are not allowed to touch stdout directly. > > If you are interested, I can prepare the patches in a form convenient > for you to merge. > |
|
From: Ivan K. <kry...@gm...> - 2019-05-12 19:44:49
|
Dear liborigin maintainers, As a maintainer of Ropj package[1], I had to make small fixes to liborigin; all of them are available at [2]. I would like to propose at least some of them for merging back into liborigin to prevent fragmentation. The changes include: - [3] prevent undefined behaviour caused by having invalid values in enums and bools (direct assignment and uninitialised stack garbage) - [4] prevent a small memory leak in projectTree caused by the whole tree being placed below the feet of the tree, preventing it from being freed by destructor And a smaller change required by CRAN policy: remove explicit reference to std::cout from outputProjectTree[5], since R extensions are not allowed to touch stdout directly. If you are interested, I can prepare the patches in a form convenient for you to merge. -- Best regards, Ivan [1] https://cran.r-project.org/package=Ropj makes it possible to import OPJ files into R, a language for data analysis. [2] https://github.com/aitap/Ropj/commits/liborigin [3] https://github.com/aitap/Ropj/commit/ce1374741152ae41012542b3e16fd6889097d527 [4] https://github.com/aitap/Ropj/commit/cc73f0f708ae457a8f26d3295ae4fb5023b4dafd [5] https://github.com/aitap/Ropj/commit/cc73f0f708ae457a8f26d3295ae4fb5023b4dafd + https://github.com/aitap/Ropj/commit/f22cd9fab08ecb3e163919249d0bfcc2191dad1d |
|
From: Fellype <fel...@ya...> - 2017-12-20 18:01:40
|
Hi all!I'm not sure if it is the right place to ask this. I'm also not sure if it is a problem with liborigin or SciDAVis. But the datasheet name of the attached opj file, created using a modified version of Origin 8.6 (from Horiba) and edited using Origin 8.1, is not recognized when is opened in SciDAVis. The datasheet is composed by one graph, one table, and one note, and its name is SampleSpectrum, but SciDAVis opens three tables named Defaul5, Defaul5@2 and Defaul5@3, being the second one a table with the data. Is it possible to add to liborigin the ability to recognize the datasheet names of this kind of opj files?A screenshot of the origin project is attached to this mail too.FYI, origin 7.5 also does not recognize the datasheet names. Best regards, Fellype |
|
From: Frco. J. R. - A. <j....@af...> - 2014-07-08 10:09:27
|
Hi: Me again, Forget about this problem, it's not a problem, those lines are exported but NDH field is just empty.. but I can live with that On 07/07/14 10:15, Frco. Javier Rial - AFFINIMeter wrote: > Hi: > > I'm new in this project, hoping someone notice this previously. > > I realized that my opj files with deleted points (NDH field is marked > with "--") are not being exported to .dat files when using opj2dat > utility > > In log file I can see that points changed to "_ONAN" value. > > I need that points exported too because Origin takes NDH values from > one row to draw with Xt/Mt from next row.. > So, if next row is deleted (because NDH had "--" value), previous NDH > value is draw against a different par of Xt/MT values. > > I don't know if anyone is reading this, but any help will be really > appreciated. > > Chears. > |
|
From: Frco. J. R. - A. <j....@af...> - 2014-07-07 10:42:24
|
Hi: I'm new in this project, hoping someone notice this previously. I realized that my opj files with deleted points (NDH field is marked with "--") are not being exported to .dat files when using opj2dat utility In log file I can see that points changed to "_ONAN" value. I need that points exported too because Origin takes NDH values from one row to draw with Xt/Mt from next row.. So, if next row is deleted (because NDH had "--" value), previous NDH value is draw against a different par of Xt/MT values. I don't know if anyone is reading this, but any help will be really appreciated. Chears. -- Analyst & Senior programmer Software 4 Science Developments j....@af... www.affinimeter.com |
