Activity for Alexander Ploumistos
-
Alexander Ploumistos posted a comment on ticket #37
Great news! Thank you Hendrik!
-
Hey Hendrik! Yes, that's the one.
-
Add formatting options to the text tool
-
Hi Fellype, Thank you, I was afraid it would be something like that. I guess I will also need to write every number with a decimal separator and hope the plots line up. Well, as long as they are aligned, I could touch up the numbers in Gimp to get rid of any unseemly formats. All the best, A.
-
Hello, I hope everyone has been doing well during these weird times. I wonder if there is a way to accomplish what I'm failing to do and I just haven't been able to figure it out. Attached is a rather simple case of a thermal analysis. I am monitoring several different values as my samples are heated and I need to know what happens at which point. My x values are temperature and time and I have a bunch of different y values, all at very different magnitudes. A single plot with 2 y axes becomes difficult...
-
If I'm not mistaken, the former developers designed the fit plugins structure in a way to make the software extensible, with the possibility of having advanced users writing their own plugins and adding them without having to compile all the software, but just the plugins they had wrote. In which case the symbol versions would be different than those of the system or SciDAVis, if they were explicitly linked against (g)libc. So there's no reason for explicit linking?
-
The discussion I linked to had left me quite baffled; I was wondering if anything might break if I do not explicitly link the shared objects to glibc in my spec file.
-
Hello and happy new year to all, I'm having a feeling of déjà-vu with this one, so if it has already been discussed, please point me to the conclusion. There was this change in Fedora 30, aiming to reduce unneeded linking and I believe there might have been some other system-wide modifications in that vein. Side effects of those changes sparked discussions like this one here. Recently I pushed an update for version 1.26 and I noticed that our linter complained about these plugins: scidavis.x86_64:...
-
Charges get cropped when exporting to image
-
Btw, this happens on both Qt4 and Qt5 builds.
-
I think you need to maximize the window first before it becomes unresponsive in its minimized state. At least when the buttons are no longer responding, we can get the window back by double-clicking its title bar (or via the window menu).
-
I'm testing a Qt5 build and some things have already improved, for instance gone are the white patches of dead space. Axis numbers are still white by default.
-
I can confirm that building against Qt5 solves the problem.
-
I strongly encourage you to compile/use the Qt5 version. I will ping the qwt maintainer again for a qwt5-qt5 subpackage. Before that happens (or SciDAVis moves to qwt6) I can't really do anything on my end. I will report again when I hear back.
-
Issues with dark desktop themes (1.23.4, Fedora 29, GNOME 3.30.2, Adwaita-dark theme)
-
"Plot Associations" button does nothing on Fedora 29, SciDAVis 1.23.4, Qt 4
-
I have submitted a liborigin-3.0.0-3 update which should already be available in rawhide. As soon as the updates hit stable, I will submit an update for scidavis, because I hadn't noticed that v1.23.4 included the change (bug 1652697). Once more, than you very much Miquel!
-
Thank you, so that means I should find out how bootstrapping works with rpms…
-
Thanks Miquel, I don't see the warning any more. On an unrelated question, how can I build opj2dat so that it uses the shared library and not the static one?
-
Shared library call to exit() function
-
Yup, that takes care of it. I am building patched updates for Fedora. Thank you!
-
Hi ALex. Your description is not detailed enough. Sorry about that, I too had problems with the terminology, but I had hoped that mentioning project windows and the windows menu would help avoid the confusion.
-
I thought there was a problem with my configuration, so on a different system which runs MATE, I uninstalled scidavis, deleted ~/.config/SciDAVis/SciDAVis.conf, I ran find on my filesystem to verify that nothing had been left behind and reinstalled. I imported a data file, created a line plot, maximized it and minimized it. Same thing. Could you try again with your configuration file moved out of ~/.config/SciDAVis ? Which desktop environment are you using?
-
Fonts in plots getting bigger after each minimize & restore action
-
Port Python code to 3.x
-
Hello Miquel, I've just tried the patch and pasting is now instantaneous. I will rebuild Fedora packages with it later today. Thank you!
-
Hello Fellype, Unfortunately SciDAVis is very slow when one paste a large volume data on a column/table. And it doesn't matter where were the source data (*Office, text file, Origin, ...). I vaguely remember being able to paste stuff on a 6-core Phenom II with a slight delay. It's good to know that it even with the load spikes, it works. As far I know, it is the intended behavior for pasting data in columns/tables, according to the former SciDAVis developers I was wondering if that was actually a...
-
Hello, Were there any code changes related to this issue? I've been having somewhat similar problems with the x86_64 Fedora 27 1.22 build. I do get increased CPU/RAM usage when I try to copy a column from LibreOffice Calc to SciDAVis - didn't wait for it to finish, killed it after a couple of minutes or so, but the computer I'm using is a piece of ****, so maybe it will succeed eventually, given enough time. The other problem appears when I am trying to copy a column from one table to another. If...
-
Hello Hendrik, Molsketch packages have been built for f26, f27 and rawhide and they are queued for testing. I think you can close this bug now. Thank you both for all your help and efforts. Best regards Alex
-
I retrieved the newest snapshot, I reverted Antonio's patch and now I have in my spec file: %build %{qmake_qt5} "MSK_PREFIX=%{_prefix}" "MSK_INSTALL_PREFIX=%{_prefix}" "MSK_INSTALL_DOCS=%{_docdir}/%{name}" "MSK_INSTALL_LIBS=%{_libdir}/%{name}" "MSK_INSTALL_INCLUDES=%{_includedir}" ./Molsketch.pro %make_build %files devel %{_includedir}/lib%{name}/ and these are the contents of the devel subpackage: usr/ └── include └── libmolsketch ├── abstractxmlobject.h ├── actions │ ├── abstractitemaction.h │...
-
It seems that you are packaging from the archive's content rather than the install target's result. The result seems to make sense, though. I didn't think obabeliface should be a legitimate include as it's only used by the main app anyhow. I'm always daunted by devel and debug subpackages, I'm only fairly certain about the contents of the main package. Let's see what Antonio thinks. Then I'll upload my changes and you can start a new RPM build. Sounds alright? Sure thing.
-
Oooh, haven't used tree in a while. So here's what I've got in my latest build: molsketch-0.5.1-6.fc28.x86_64.rpm: usr/ ├── bin │ └── molsketch-qt5 ├── lib ├── lib64 │ └── molsketch │ ├── libmolsketch-qt5.so │ └── libobabeliface-qt5.so └── share ├── applications │ └── molsketch.desktop ├── doc │ └── molsketch │ └── CHANGELOG ├── icons │ └── hicolor │ └── scalable │ ├── apps │ │ └── molsketch.svg │ └── mimetypes │ └── application-x-molsketch.svg ├── licenses │ └── molsketch │ └── COPYING ├── metainfo...
-
Well, actually the versioned library was probably my fault. I tied the "plugin" setting (which causes the library to be built without a version) to a "CONFIG(!static)" condition for qmake (cmake should be fine). Somehow that didn't work (and doesn't seem to be necessary for the static Windows build to work -- don't ask me why I did that, must have been late). Anyhow: that one is fixed and uploaded as latest snapshot again. I got a little confused, so now there aren't any versioned libraries?
-
Hello again, I've managed to build packages for rawhide and f27, please take a look if everything is as it was supposed to be. I still get this error (for which I do not know what I am supposed to do): molsketch-debuginfo.x86_64: E: useless-provides debuginfo(build-id) and this warning: molsketch.x86_64: W: devel-file-in-non-devel-package /usr/lib64/molsketch/libmolsketch-qt5.so Should it not be there? Do I need to put it in /usr/lib64/ instead of /usr/lib64/molsketch/ ? As for the other error: [!]:...
-
Hi Hendrik, Thanks for taking care of this. I think I will have a couple of hours to spare later today and I will try some new builds then. Till later, Alex
-
The reasoning behind shared object file separation is explained here: https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#DevelPackages
-
Hello Hendrik, Antonio is a fellow chemist, he is part of Fedora's SciTech Special Interest Group and the one who has undertaken the review of Molsketch. He knows a lot more about rpm packaging, Qt and the like than I do. In the package I had originally submitted, the automated review tool picked this up: Unversioned so-files -------------------- molsketch: /usr/lib64/libmolsketch-qt5.so molsketch: /usr/lib64/libobabeliface-qt5.so Following Antonio's comments, in the %files section of the spec file...
-
Can't reproduce it either. I'm using 1.22 on Fedora 27, x86_64.
-
And you can close this one as well.
-
No, you can close it.
-
Hi Hendrik, Of course. I would have closed it myself, but sf doesn't allow the reporter to close bugs.
-
As for the debugging, it seems that Fedora doesn't like debug output from Qt (admittedly, their libs seem to output quite a bit more, so that there was quite a bit more than the mere molsketch output), see this bugreport and luckily, stackoverflow knows how to fix it (which led me to the bug report in the first place). A few years ago, some people complained on the devel mailing list about the volume of messages that was displayed in the terminal when users launched programs. Though I don't remeber...
-
I've just started a local build, as soon as that completes and I run some tests, I will submit molsketch-0.5.0-5 to copr. I noticed that you added the xpm icon back and I updated the %files section accordingly. Aboslutely unimportant, I saw some "INCHI_FOMRAT" declarations in obabeliface.cpp, which I guess should be "INCHI_FORMAT". Of no consequence, since it's consistent across the file, but I thought I should mention it.
-
Starting with F27, debuginfo and debugsource have been split into separate subpackages, so if you tried debugging it in F27 or rawhide, you wouldn't need to download so much stuff. Also begining in F27, you can install debuginfo packages in parallel. As long as you use the packages from copr, dnf knows how to handle everything.
-
And a screenshot of the molecules that had appeared when the crash happened.
-
I am attaching a gdb backtrace. The last messages before the crash were these: Info: ((null):0, (null)) obtained molecule from wikidata: "N6-[(1R)-2-{[(1R)-1-carboxy-2-methylpropyl]oxy}-1-(mercaptomethyl)-2-oxoethyl]-6-oxo-D-lysine" "CC(C)C(C(=O)O)OC(=O)C(CS)NC(=O)CCCC(C(=O)O)N" "1S/C14H24N2O7S/c1-7(2)11(13(20)21)23-14(22)9(6-24)16-10(17)5-3-4-8(15)12(18)19/h7-9,11,24H,3-6,15H2,1-2H3,(H,16,17)(H,18,19)(H,20,21)/t8-,9-,11+/m0/s1" "CC(C)[C@H](C(=O)O)OC(=O)[C@H](CS)NC(=O)CCC[C@@H](C(=O)O)N" Info: ((null):0,...
-
No objections, you can close it now. Every aspect of it seems in order.
-
Hi Hendrik, I had just started to download ~1GB of debuginfo packages in order to use gdb, is that going to do?
-
Crash when results for "lysine" query start showing up
-
Hello Hendrik, I had taken a peek at your github repo, but I was waiting for the package to appear here and when I downloaded Molsketch-latest-src.tar.gz, sourceforge had it marked as changed in the last couple of days or something like that. The files inside the package were dated 1 October though. Anyway, I just picked up the latest "latest" snapshot and took my time deleting atoms, bonds and parts of molecules. No crashes and no strange fragments left behind, so I'd say this is fixed.
-
Hi Hendrik, I just tested your latest version with the same molecules and it doesn't crash. However, when I try to delete the oxygens and their double bonds, I end up with a water molecule on one side, while the other carbonyl remains unchanged.
-
Program crash when deleting simultaneously atoms and their bonds
-
Please add a MIME type for msk files
-
Hello again, It took a while and we've had some internal glitches with the migration to new infrastructure in Fedora, but since this evening, SciDAVis has hit the testing repositories and it is now available on F25, F26, F27 (which is in beta) as well as rawhide. I want to thank you all for your help - I will probably need it again. All the best, Alex
-
Oh, I think you can close the ticket.
-
From looking at your build.log, it appears that you are first building using qmake and then again using CMake. Might it be that, during the linking after the CMake build, somehow this produces the duplicate definition error? Thanks, that was my bad, I had left a " #%cmake . " commented out in the %build section which got activated. It took a few /usr/local → /usr and /lib* → /usr/lib* substitutions and in the end I managed to get it to build. Now I need to whip the spec file into shape and declare...
-
That did help and compilation failed a lot further down the road, see build.log. I have used the same spec file. There were a lot of output, but I think the problem was during this stage: [ 71%] Linking CXX shared library libmolsketch-qt5.so It was followed by a lot of messages like these: CMakeFiles/molsketch_LIB.dir/molsketch_LIB_autogen/mocs_compilation.cpp.o: In function `Molsketch::abstractRecursiveItemAction::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': /builddir/build/BUILD/Molsketch-0.5.0/libmolsketch/molsketch_LIB_autogen/T4QKTR7IAB/moc_abstractrecursiveitemaction.cpp:63:...
-
Hello Hendrik, After a bit of trial and error, amending the spec file along the way, I got to this error: Project MESSAGE: Using pkgconfig to find OpenBabel. make[1]: Entering directory '/builddir/build/BUILD/Molsketch-0.5.0/obabeliface' compiling obabeliface.cpp make[1]: Leaving directory '/builddir/build/BUILD/Molsketch-0.5.0/obabeliface' obabeliface.cpp: In function 'bool Molsketch::isInputFormatAvailable(OpenBabel::OBConversion, const char*)': obabeliface.cpp:367:85: error: format not a string...
-
Sure, no worries. I'll start afresh with 0.5.0 and we'll see from there.
-
Hello Miquel, Please try attached patch (that includes an alternative to my previous armv7hl-build.patch) and publish the link to build.log if it doesn't fix the bug. Robert-André Mauchin, another Fedora contributor, had sent me the same patch for scidavis.sip and I was about to submit a PR, when you send yours. Since it was a 2 in 1, I went with that. Thank you very much yet again! Sure enough, the builds are now successful: https://koji.fedoraproject.org/koji/taskinfo?taskID=21843516 Would you...
-
Did you want to try to test changing double->qreal everywhere, and submitting a pull request when you get something working? I'm not really set up to test ARM here (although I do have a Raspberry Pi in the corner I could press into service if things get too desperate. I was looking at Miquel Garriga's patch for 313 and he used a conditional to switch from double to float on ARM. In Qt's documentation there's this: typedef qreal Typedef for double unless Qt is configured with the -qreal float option....
-
Failure to build 1.21 on armv7hl with Python scripting enabled
-
Oh, it does work! Thanks a million! (Once again)
-
Hi Fellype, To be honest, I don't know what is (or where is) the upstream version. The latest version hosted at SF site [1] is numbered as 2.0.0. But inspecting the 3rdparty/liborigin/liborigin.pro file in the SciDAVis source code we see that the version shipped with it is numbered as 3.0.0. I was referring to the liborigin repo hosted here on SF. The last release was indeed 2.0.0, but if you look at the git log, you'll notice there's been considerable development since last March. Plus, in CMakeLists.txt...
-
Hello, I've noticed that your copy of liborigin has some differences compared to that upstream (please correct me if I am wrong). Given that both projects share contributors, are you planning to merge those changes upstream or will you be keeping a forked version of sorts in SciDAVis? Best regards
-
Failure to build on armv7hl
-
I can't thank you enough, nor can I put into words how happy I was when I read your reply! I had two out of three right in my own patch, but I completely botched scidavis/sciadavis.pro, it never occurred to me to remove that section, I added references to the system library and path. At first the build kept failing and the error message wasn't very helpful, but I managed to track it down to some extraneous dollar signs and backslashes in config.h.in, see attached patch. I noticed that during compilation,...
-
Molsketch fails to build from source on Fedora 25
-
Hello Dr. Standish, SciDAVis was retired in Fedora about a year ago, when builds started failing because of incompatibilities with newer versions of gcc and the compiler flags enabled by default in the distribution. I had kept a VM with the last version I could get to work on F23 for my own needs and whenever I had time, I tried to patch things up and get it working again on current OS versions. Thankfully, you released version 1.17 and then 1.18 which both worked with minimal effort on my part and...
-
I've dug a little deeper and it seems that the problem is that the variables in the...
-
I am attaching a diff of the unpatched config.pri in versions 1.D9 and 1-14 as well...
-
This is great news! However, there are a number of files and folders missing from...
-
Hello, I am really grateful for your work on scidavis. Just realised that a whole...
-
Can scidavis be re-introduced to F24 now or are there more kinks to iron out?
1 >