Re: [Veusz-discuss] We love it! Lets Extend it
On 10/17/2012 03:45 AM, Dr. Volker Jaenisch wrote: The test finishes now with excactly the same result as a fresh 1.16 veusz installation: Original: veusz_orig)volker@killer:~/workspace/veusz_orig/veusz-1.16/tests$ python runselftest.py Testing output bar_labels.vsz Segmentation fault Modified: (veusz)volker@killer:~/workspace/veusz/veusz$ python ./tests/runselftest.py Testing output bar_labels.vsz Segmentation fault (veusz)volker@killer:~/workspace/veusz/veusz$ Since both Verions segfault I cannot track no error that may be introduced by my refactoring. Maybe you can give me hint. I'll have a look at this later. Usually it's a bad parameter in PyQt that can cause segmentation faults. If it's an old PyQt that might explain the issue. I've triggered some PyQt bugs in the past which had to be fixed. Jeremy ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
On 10/13/2012 07:14 PM, Dr. Volker Jaenisch wrote: Dear Jeremy! On 13/10/12 17:56, Dr. Volker Jaenisch wrote: My first guess would be to seperate the base-classes ImportParamsBase, ImportDialogBase etc. from the concrete ones. The Classes needed for the import, and representation of a certain Fileformat then should be more located. E.G. there may be a folder fileformats with a file for each fileformat, containing the 'incredients' of the fileformat. Added a minimal sort of registry for the fileformats and we will end up with sort of a plugin system for the fileformats. You have separated the UI-Components from the data components. That is a good approach. So a fileformat plugin should not be a simple file but at least 4 files in a folder structure like this. - HDF5 - importdialog.py <- code for import - importdiaolg.ui <- ui resource - operations.py<- one or more operations oh the fileformat - linkedfile.py <- handling of linkedfiles What is your opinion? Seems a good layout. Jeremy ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
Dear Jeremy! On 17/10/12 01:37, Dr. Volker Jaenisch wrote: > * Just noticed that I have broken all your tests. I will start fixing them > right now. Sorry for the inconvenience. I will return after fixing > the tests, for you to check the code. Fixed the tests. The commadline "module" is not that modular. The routines should be incorporated dynamically into the commandline class, not statically as is. So there is lots of work to do :-). WE will do the work, your part is to direct us. The test finishes now with excactly the same result as a fresh 1.16 veusz installation: Original: veusz_orig)volker@killer:~/workspace/veusz_orig/veusz-1.16/tests$ python runselftest.py Testing output bar_labels.vsz Segmentation fault Modified: (veusz)volker@killer:~/workspace/veusz/veusz$ python ./tests/runselftest.py Testing output bar_labels.vsz Segmentation fault (veusz)volker@killer:~/workspace/veusz/veusz$ Since both Verions segfault I cannot track no error that may be introduced by my refactoring. Maybe you can give me hint. Best Regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
Dear Jeremy! On 16/10/12 13:16, Jeremy Sanders wrote: > > I had a quick look through the current commits and it looks good! Just finished the refacturing of the code into the new folder structure. I noticed that we are quite neighbors. You are located in Garching, MUC, Germany, I am sitting in Schongau (Richard-Strauß-Str.1, 86956 Schongau, 08861 690 474 0) only 100 km away. If you like to have a beer with me, just call me. My wife works for German weather service and runs LIDAR and Ceilometer system on Observatory Hoher Peißenberg, near Schongau. Thomas is also quite often in MUC so we may have a sprint on veusz together, if you like. Some things that I noticed: * Your code is very good! I have seldom come across a code (so old) that is structured so plain and even after such a long time. Surely there are traces of aging but they are not bad. So the refactoring was boring. But that is better than cursing whole the time while doing an EXCITING refactoring. * The import of python modules at some places is quite nested. So much nested that my eclipse cannot cope with! Especially the statements import veusz.qtall as qt4 drive my eclspse mad. It may be a good thing to refactor the import statements in a more uniform fashion. From my perspective there is no need for import XXX.YYY as ZZZ if the naming convention of the modules is good. Since many of the modules are touched in the current refactoring it may be no great deal to refactor the imports quite well. Had very nasty errors with the import order of modules in python recently, so I am burned with any import that is not canonical aka from xxx.yyy.zzz import , or whatever Maybe Thomas can elaborate on that subject. He has build systems far more complex than Veusz. And has quite a wisdom of "Better not to do"s in python. * I have never worked with the FITS file format. I tried to import a sample FITS-File from NASA but failed (not by stacktraces, but by not knowing what to do). You are the astronomer, so please test if the migrated FITS still fits :-) * Just noticed that I have broken all your tests. I will start fixing them right now. Sorry for the inconvenience. I will return after fixing the tests, for you to check the code. Since you are in Germany. Do you like to meet us on the PyCon [1] in Leipzig 20.10-3.11. [1] https://2012.de.pycon.org/ Best regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
On 10/14/2012 12:10 AM, Dr. Volker Jaenisch wrote: Dear Jeremy! I forked your code and made some first structure changes. THe changes are nor complete nor perfect. At first I only moved the standard import tab into the new structure https://github.com/volkerjaenisch/veusz in the modular_import branch. Dear Volker I had a quick look through the current commits and it looks good! Jeremy ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
Dear Jeremy! I forked your code and made some first structure changes. THe changes are nor complete nor perfect. At first I only moved the standard import tab into the new structure https://github.com/volkerjaenisch/veusz in the modular_import branch. Please have a look if you like the new structure. The naming of certain files under "formats/standard" is not good. We should introduce filenames with more meaning in them and have to eliminate the repetition of "import_". It took me two hours to refactor the code for one input tab. So I suspect the whole refactoring to last 1-2 days. Best regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
Dear Jeremy! On 13/10/12 17:56, Dr. Volker Jaenisch wrote: > My first guess would be to seperate the base-classes ImportParamsBase, > ImportDialogBase etc. from the concrete ones. > The Classes needed for the import, and representation of a certain Fileformat > then should be more located. E.G. there may be a folder > fileformats with a file for each fileformat, containing > the 'incredients' of the fileformat. > Added a minimal sort of registry for the fileformats and we will end up with > sort of a plugin system for the fileformats. You have separated the UI-Components from the data components. That is a good approach. So a fileformat plugin should not be a simple file but at least 4 files in a folder structure like this. - HDF5 - importdialog.py <- code for import - importdiaolg.ui <- ui resource - operations.py<- one or more operations oh the fileformat - linkedfile.py <- handling of linkedfiles What is your opinion? Best regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
Dear Jerermy! On 12/10/12 16:34, Jeremy Sanders wrote: > On 10/12/2012 03:29 AM, Dr. Volker Jaenisch wrote: > >> While patching the code I feel bad. It is a hack but no solution. I would >> like to contribute to build a modular Import-dialog-Framework that >> is capable to assimilate the new Code I will bring in. That will be no great >> deal, just moving a few classes into a base module and organize >> that the qt-resources are >> bound to an external data structure. > > This sounds a great idea. Thanks for your offer of making the dialog more > extensible. I designed the import plugin to be able to do this, but > it's not flexible enough for complex data formats. Thank you very much for your welcome. > > Please go ahead and have a look at doing this. If you want to discuss any > designs, we can do it here or offline. There are a few places which > need to be modified in order to add a new data format - in the > document.operations, document.importparams, documents.linkedfile, the dialog > itself... If you can clean this up to make it possible to add new formats in > an easy way, please do. My first guess would be to seperate the base-classes ImportParamsBase, ImportDialogBase etc. from the concrete ones. The Classes needed for the import, and representation of a certain Fileformat then should be more located. E.G. there may be a folder fileformats with a file for each fileformat, containing the 'incredients' of the fileformat. Added a minimal sort of registry for the fileformats and we will end up with sort of a plugin system for the fileformats. This is pure guessing. A had only given a glance to your code and may have orverseen some complexity that renders this simple approach useless. I will give it a try and do some refactoring and wait for the problems to come. Best regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
Re: [Veusz-discuss] We love it! Lets Extend it
On 10/12/2012 03:29 AM, Dr. Volker Jaenisch wrote: While patching the code I feel bad. It is a hack but no solution. I would like to contribute to build a modular Import-dialog-Framework that is capable to assimilate the new Code I will bring in. That will be no great deal, just moving a few classes into a base module and organize that the qt-resources are bound to an external data structure. Dear Volker This sounds a great idea. Thanks for your offer of making the dialog more extensible. I designed the import plugin to be able to do this, but it's not flexible enough for complex data formats. Please go ahead and have a look at doing this. If you want to discuss any designs, we can do it here or offline. There are a few places which need to be modified in order to add a new data format - in the document.operations, document.importparams, documents.linkedfile, the dialog itself... If you can clean this up to make it possible to add new formats in an easy way, please do. Jeremy ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
[Veusz-discuss] We love it! Lets Extend it
Hi! I love Veusz! I worked with Origin for a decade and I loved it for the flexibility to play with the data, make a fit, plot it this or that way. Now I found veusz that brings the same capabilities as Origin to me and it is programmed in my favorite language, python. One of our customers likes us to build up a facility for visualizing CAN data from automotive sources. The data source are HDF5 files that will evolve in complexity. I am building up an import dialog for complex HDF5 files for Veusz right at the moment. Since my customer supports Open-Source I would like to share the outcome of the HDF5-Dialog with the community. Veusz at the moment promotes import-plugins that are handled by a generic import-plugin-Dialog. That generic Dialog is not capable to deal with the complexity of HDF5. So I have had to dig deeper and added a new Class ImportTabHDF5 to the importDialog File and added a new UI-Resource-File. While patching the code I feel bad. It is a hack but no solution. I would like to contribute to build a modular Import-dialog-Framework that is capable to assimilate the new Code I will bring in. That will be no great deal, just moving a few classes into a base module and organize that the qt-resources are bound to an external data structure. Here we are. Two programmers ready to work with you. Please give us orders. :-) Best Regards Volker -- Dr. Volker Jaenisch Geschäftsführer Inqbus GmbH & Co. KG Softwareentwicklung, Consulting & Hosting Karl-Heine-Straße 99 | 04229 Leipzig | Deutschland Telefon: +49 341 989758-54 Fax: +49 341 989758-79 E-Mail: volker.jaeni...@inqbus.de Web: http://inqbus.de/ Persönlich haftende Gesellschafterin: Inqbus Management GmbH (Amtsgericht Leipzig, HRB 27350) Vertretungsberechtigte Geschäftsführer: Maik Derstappen, Dr. Volker Jaenisch, Thomas Massmann, Markus Zapke-Gründemann Registergericht: Amtsgericht Leipzig Registernummer: HRA 16424 Umsatzsteuer-Identifikationsnummer: DE278744671 ___ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
