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) |
| 2026 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ivan K. <ik...@di...> - 2026-05-12 11:22:49
|
On Thu, 2 Apr 2026 16:49:35 +0300
Ivan Krylov via Liborigin-devel <lib...@li...>
wrote:
> Best I was able to find was a byte at a certain offset
> (lye_header[0x12d]) that sometimes corresponded to the sheet number,
> but it's probably a coincidence, because it has a completely
> different value in other cases.
No, not a coincidence. I took a better look at my files and realised
that in the "misordered" files, lye_header[0x12d] always contains a
permutation of [0, number of sheets). In most Origin files I found on
my PC, it indeed contains increasing integers from 0 to the number of
sheets (-1).
I wrote a macro to click the Origin window for me and reached the limit
on the number of Excel sheets (255); there's no need to look at other
bytes. It's quite easy to create a file where the sheet order doesn't
follow the window layer order by manually reordering or removing Excel
sheets in Origin.
The following patch fixes the problem for me, at the cost of
introducing "phantom" empty Excel sheets where they had been deleted:
diff --git a/OriginAnyParser.cpp b/OriginAnyParser.cpp
index bdd50e7..74e5eff 100644
--- a/OriginAnyParser.cpp
+++ b/OriginAnyParser.cpp
@@ -1538,6 +1538,12 @@ void OriginAnyParser::getLayerProperties(const string &lye_header, unsigned int
} else if (iexcel != -1) { // excel
excels[iexcel].loose = false;
+ if (lye_header_size > 0x12d) {
+ ilayer = (unsigned char)lye_header[0x12d];
+ LOG_PRINT(logfile, " Apparent layer index = %d\n", ilayer)
+ }
+ if ((unsigned int)ilayer >= excels[iexcel].sheets.size())
+ excels[iexcel].sheets.resize(ilayer+1);
if (lye_header_size > 0xD2) {
excels[iexcel].sheets[ilayer].name = lye_header.substr(0xD2, 32).c_str();
}
I'm also attaching a compressed Origin file containing two Excel books,
"Book1" with 255 sheets in order from 1 to 255 (the corresponding sheet
pointer at lye_header[0x12d] is in [0, 254]), and "Book2" ("reorder21,
remove3") with Sheet2, Sheet1, Sheet4 ... Sheet255.
--
Best regards,
Ivan
|
|
From: Ivan K. <ik...@di...> - 2026-04-26 12:09:10
|
Hello,
In order to keep the R wrapper for liborigin portable to different
versions of R, I've tested it with different versions of the C++
standard. (Old versions of R know nothing about C++ > 11; new versions
default to C++20 but still allow C++17 if specifically asked [1].) It
turns out that the current code in OriginAnyParser.cpp fails to compile
in C++20 or C++23 mode due to the != operator resolution ambiguity for
tree::iterator [2]. Only a small change is needed to fix the
compilation error:
diff --git a/OriginAnyParser.cpp b/OriginAnyParser.cpp
index 209ec7f..bdd50e7 100644
--- a/OriginAnyParser.cpp
+++ b/OriginAnyParser.cpp
@@ -3259,7 +3259,7 @@ void OriginAnyParser::outputProjectTree(std::ostream &out)
out << "Origin project Tree" << endl;
char cdsz[21];
- for (tree<ProjectNode>::iterator it = projectTree.begin(projectTree.begin());
+ for (tree<ProjectNode>::sibling_iterator it = projectTree.begin(projectTree.begin());
it != projectTree.end(projectTree.begin()); ++it) {
strftime(cdsz, sizeof(cdsz), "%F %T", gmtime(&(*it).creationDate));
out << string(projectTree.depth(it) - 1, ' ') << (*it).name.c_str() << "\t" << cdsz << endl;
--
Best regards,
Ivan
[1]
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code
[2]
https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/Ropj-00install.html
|
|
From: Ivan K. <ik...@di...> - 2026-04-02 13:49:53
|
Hello again after more than a year, The misplaced excel sheets have finally annoyed me enough to investigate a bit myself. Here are my findings. I'm also taking the liberty of attaching the reproducers (<30kB; I have misplaced the previous reproducer). In both "ordered_right.opj" and "misordered.opj", the dataset columns are stored with "Processed Data: IFE" (A@22, B@22, C1@22, C2@22, D1@22, D2@22, ... D79@22, D80@22) preceding "Processed XYZ: IFE" (A@23, B@23, C@23). In the "ordered_right.opj" file (and in most files produced by the fluorometer software), when readWindowElement -> readLayerElement -> getLayerProperties is setting the Excel sheet names, the window layers come out in the same order: "Processed Data: IFE" is stored before "Processed XYZ: IFE". Origin and liborigin agree on the order, and all is well. In the "misordered.opj" file, the window layers 22 and 23 are stored in reversed order: "Processed XYZ: IFE" precedes "Processed Data: IFE". Origin agrees with the order of names (it shows the "Processed XYZ: IFE" sheet before "Processed Data: IFE") but not the order of data: somehow the "Processed XYZ: IFE" sheet must contain the columns from @23 instead of @22, and vice versa. If I start removing more parts of the file (e.g. delete all plots, as in crash.opj), liborigin may crash while trying to parse the resulting file, setting excels[iexcel].sheets[ilayer].name with ilayer == excels[iexcel].sheets.size(), even if it was previously possible to read the file without problems. Clearly, excel window layers don't always directly correspond to spreadsheets. Should there be some sort of sheet pointer inside a window layer header? Any ideas on where to look for it? Best I was able to find was a byte at a certain offset (lye_header[0x12d]) that sometimes corresponded to the sheet number, but it's probably a coincidence, because it has a completely different value in other cases. -- Best regards, Ivan |
|
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 |
