Hi All, I've been working on the ODS importer for the Tabular package (http://ss3.gemtalksystems.com/ss/Tabular.html) and wanted to offer the opportunity for feedback before updating the code as it is likely to affect existing users. While the class structure of Tabular is designed to support multiple formats in theory, in practice the existing implementation is quite XLSX specific. I think that trying to extend the core Tabular classes to be a superset of all the functionality from the various formats (XLSX, ODS, etc.) will not be practical - I don't have a good enough understanding of all the formats to implement it in the first place, and certainly not to resolve conflicting attributes in any sensible way. The approach I've taken is to make the existing classes, which were intended to be format independent, abstract and create format specific subclasses, i.e. the existing TabularCell and TabularStyle become: TabularCell TabularXLSXCell TabularODSCell TabularStyle TabularXLSXStyle TabularODSStyle The modified code runs the existing test suite successfully without any modifications. I welcome any comments, suggestions, etc. Also, Tabular currently loads PharoExtras/XMLWriter and PharoExtras/XMLParser as dependencies. I've been using XMLSupport, which I thought I remembered reading was a replacement for XMLWriter and XMLParser, but now I can't find the reference. Is one generally preferred over the other? Thanks very much, Alistair
Le 19/4/16 16:41, Alistair Grant a écrit :
Hi All,
I've been working on the ODS importer for the Tabular package (http://ss3.gemtalksystems.com/ss/Tabular.html) and wanted to offer the opportunity for feedback before updating the code as it is likely to affect existing users.
cool
While the class structure of Tabular is designed to support multiple formats in theory, in practice the existing implementation is quite XLSX specific.
I think that trying to extend the core Tabular classes to be a superset of all the functionality from the various formats (XLSX, ODS, etc.) will not be practical - I don't have a good enough understanding of all the formats to implement it in the first place, and certainly not to resolve conflicting attributes in any sensible way.
The approach I've taken is to make the existing classes, which were intended to be format independent, abstract and create format specific subclasses, i.e. the existing TabularCell and TabularStyle become:
TabularCell TabularXLSXCell TabularODSCell TabularStyle TabularXLSXStyle TabularODSStyle
The modified code runs the existing test suite successfully without any modifications.
Sounds correct and if you add a factory or specific importer then you get it :)
I welcome any comments, suggestions, etc.
Also, Tabular currently loads PharoExtras/XMLWriter and PharoExtras/XMLParser as dependencies.
This is good because these are the clean versions.
I've been using XMLSupport, which I thought I remembered reading was a replacement for XMLWriter and XMLParser, but now I can't find the reference. Is one generally preferred over the other?
XMLSupport is a union of too many things. Modularity is not stupid Union. Stef
Thanks very much, Alistair
Hi Stepharo, Thanks very much for your feedback. On Wed, Apr 20, 2016 at 08:24:55AM +0200, stepharo wrote:
Le 19/4/16 16:41, Alistair Grant a écrit :
Hi All,
I've been working on the ODS importer for the Tabular package (http://ss3.gemtalksystems.com/ss/Tabular.html) and wanted to offer the opportunity for feedback before updating the code as it is likely to affect existing users.
cool
While the class structure of Tabular is designed to support multiple formats in theory, in practice the existing implementation is quite XLSX specific.
I think that trying to extend the core Tabular classes to be a superset of all the functionality from the various formats (XLSX, ODS, etc.) will not be practical - I don't have a good enough understanding of all the formats to implement it in the first place, and certainly not to resolve conflicting attributes in any sensible way.
The approach I've taken is to make the existing classes, which were intended to be format independent, abstract and create format specific subclasses, i.e. the existing TabularCell and TabularStyle become:
TabularCell TabularXLSXCell TabularODSCell TabularStyle TabularXLSXStyle TabularODSStyle
The modified code runs the existing test suite successfully without any modifications.
Sounds correct and if you add a factory or specific importer then you get it :)
Yep, the importers were already format specific.
I welcome any comments, suggestions, etc.
Also, Tabular currently loads PharoExtras/XMLWriter and PharoExtras/XMLParser as dependencies.
This is good because these are the clean versions.
I've been using XMLSupport, which I thought I remembered reading was a replacement for XMLWriter and XMLParser, but now I can't find the reference. Is one generally preferred over the other?
XMLSupport is a union of too many things. Modularity is not stupid Union.
Thanks, I'll switch to XMLParser and XMLWriter. I've also realised that I built all my changes on an older version of Tabular. :-( So, time to learn more about Monticello... Reading the Updated PbE is helpful, however I did notice one thing which doesn't match my experience. On page 150 it is discussing how you can't lose code... "This is because all of the code that you executed is saved in the .changes file. All of it! This includes one liners that you evaluate in a workspace, as well as code that you add to a class while programming." Should "workspace" be changed to "playground"? My experience has been that code evaluated in the playground is *not* saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell Pharo to save evaluated code to the changes file? (I admit to being lazy and not trying to figure this one out myself yet). Finally, in Section 8.2 on versions of a method, my impression from reading the section was that it would always display all versions of a method, i.e. I have 24 versions of a package in my package cache, so expected to see each modification to each method in the package. However because I had switched to a new image and loaded the newest package, only the latest version was shown. Re-reading the section, it does say that you can see each version that you save, however it might be worthwhile adding a sentence that explicitly states that only versions loaded into the image are shown (I guess it is actually versions in the changes file?). Thanks again, Alistair # vim: tw=72
And to answer my own question... On Wed, Apr 20, 2016 at 10:47:46PM +0200, Alistair Grant wrote:
Hi Stepharo,
Thanks very much for your feedback. ...
So, time to learn more about Monticello... Reading the Updated PbE is helpful, however I did notice one thing which doesn't match my experience. On page 150 it is discussing how you can't lose code...
"This is because all of the code that you executed is saved in the .changes file. All of it! This includes one liners that you evaluate in a workspace, as well as code that you add to a class while programming."
Should "workspace" be changed to "playground"?
My experience has been that code evaluated in the playground is *not* saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell Pharo to save evaluated code to the changes file? (I admit to being lazy and not trying to figure this one out myself yet).
It looks like evaluated code is saved in the play-cache directory and accessible through the Spotter. Perhaps you could change the paragraph to something like: This is because all of the code that you write is saved in the .changes file, and expressions that are evaluated in the playground are saved to the play-cache. Expressions from the playground may be found using the spotter as described in section 2.11. (And then go on to describe how to recover code) Thanks, Alistair
Le 20/04/2016 22:47, Alistair Grant a écrit : Hi,
Thanks, I'll switch to XMLParser and XMLWriter.
I've also realised that I built all my changes on an older version of Tabular. :-(
So, time to learn more about Monticello... Reading the Updated PbE is helpful, however I did notice one thing which doesn't match my experience. On page 150 it is discussing how you can't lose code...
"This is because all of the code that you executed is saved in the .changes file. All of it! This includes one liners that you evaluate in a workspace, as well as code that you add to a class while programming."
Should "workspace" be changed to "playground"?
Yes, can you open an issue please? :) https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
My experience has been that code evaluated in the playground is *not* saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell Pharo to save evaluated code to the changes file? (I admit to being lazy and not trying to figure this one out myself yet).
All the *compiled* code is save. The playgroud is for playing, so it is not save in the change file. But the playground should save the code and you have a little menu to select your last scripts. http://puu.sh/opMd9/a823c07bf9.png If you use several times the same code you can also give a name to the tab (2 click on "Page") and after you can save the playground code. Via the spotter you can use the name of the tab to get a playground with the code.
Finally, in Section 8.2 on versions of a method, my impression from reading the section was that it would always display all versions of a method, i.e. I have 24 versions of a package in my package cache, so expected to see each modification to each method in the package. However because I had switched to a new image and loaded the newest package, only the latest version was shown.
In the setting you can change the package-cache location to use always the same location even when you change of image. If the book is not clear can you copy/paste your mail into a github issue please? To not lose this feedback :)
Re-reading the section, it does say that you can see each version that you save, however it might be worthwhile adding a sentence that explicitly states that only versions loaded into the image are shown (I guess it is actually versions in the changes file?).
Thanks again, Alistair
# vim: tw=72
Thank you for the feedback. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote:
Le 20/04/2016 22:47, Alistair Grant a écrit :
So, time to learn more about Monticello... Reading the Updated PbE is helpful, however I did notice one thing which doesn't match my experience. On page 150 it is discussing how you can't lose code...
"This is because all of the code that you executed is saved in the .changes file. All of it! This includes one liners that you evaluate in a workspace, as well as code that you add to a class while programming."
Should "workspace" be changed to "playground"?
Yes, can you open an issue please? :)
https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
Issue 164: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/164
My experience has been that code evaluated in the playground is *not* saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell Pharo to save evaluated code to the changes file? (I admit to being lazy and not trying to figure this one out myself yet).
All the *compiled* code is save. The playgroud is for playing, so it is not save in the change file. But the playground should save the code and you have a little menu to select your last scripts.
http://puu.sh/opMd9/a823c07bf9.png
If you use several times the same code you can also give a name to the tab (2 click on "Page") and after you can save the playground code. Via the spotter you can use the name of the tab to get a playground with the code.
This sounds great, but I can't reproduce it. Would you mind clarifying what you mean by "2 click on Page"? I tried clicking on the various buttons, and clicking action-clicking, and middle buttong click on the tab name ("Page"), without success (Pharo 5.0 50702).
Finally, in Section 8.2 on versions of a method, my impression from reading the section was that it would always display all versions of a method, i.e. I have 24 versions of a package in my package cache, so expected to see each modification to each method in the package. However because I had switched to a new image and loaded the newest package, only the latest version was shown.
In the setting you can change the package-cache location to use always the same location even when you change of image. If the book is not clear can you copy/paste your mail into a github issue please? To not lose this feedback :)
Issue 165: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/165 If I get time I'll also make the suggested changes and issue a pull request. Thanks! Alistair
On Apr 20, 2016, at 23:55, Alistair Grant <akgrant0710@gmail.com> wrote:
On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote: Le 20/04/2016 22:47, Alistair Grant a écrit :
So, time to learn more about Monticello... Reading the Updated PbE is helpful, however I did notice one thing which doesn't match my experience. On page 150 it is discussing how you can't lose code...
"This is because all of the code that you executed is saved in the .changes file. All of it! This includes one liners that you evaluate in a workspace, as well as code that you add to a class while programming."
Should "workspace" be changed to "playground"?
Yes, can you open an issue please? :)
https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
Issue 164: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/164
My experience has been that code evaluated in the playground is *not* saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell Pharo to save evaluated code to the changes file? (I admit to being lazy and not trying to figure this one out myself yet).
All the *compiled* code is save. The playgroud is for playing, so it is not save in the change file. But the playground should save the code and you have a little menu to select your last scripts.
http://puu.sh/opMd9/a823c07bf9.png
If you use several times the same code you can also give a name to the tab (2 click on "Page") and after you can save the playground code. Via the spotter you can use the name of the tab to get a playground with the code.
This sounds great, but I can't reproduce it. Would you mind clarifying what you mean by "2 click on Page"? I tried clicking on the various buttons, and clicking action-clicking, and middle buttong click on the tab name ("Page"), without success (Pharo 5.0 50702).
I think you want to double click on "Page". At least it works on Mac OSX and Pharo 5.
Finally, in Section 8.2 on versions of a method, my impression from reading the section was that it would always display all versions of a method, i.e. I have 24 versions of a package in my package cache, so expected to see each modification to each method in the package. However because I had switched to a new image and loaded the newest package, only the latest version was shown.
In the setting you can change the package-cache location to use always the same location even when you change of image. If the book is not clear can you copy/paste your mail into a github issue please? To not lose this feedback :)
Issue 165: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/165
If I get time I'll also make the suggested changes and issue a pull request.
Thanks! Alistair
On Thu, Apr 21, 2016 at 07:49:24PM -0700, John Pfersich wrote:
On Apr 20, 2016, at 23:55, Alistair Grant <akgrant0710@gmail.com> wrote:
On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote: Le 20/04/2016 22:47, Alistair Grant a écrit : If you use several times the same code you can also give a name to the tab (2 click on "Page") and after you can save the playground code. Via the spotter you can use the name of the tab to get a playground with the code.
This sounds great, but I can't reproduce it. Would you mind clarifying what you mean by "2 click on Page"? I tried clicking on the various buttons, and clicking action-clicking, and middle buttong click on the tab name ("Page"), without success (Pharo 5.0 50702).
I think you want to double click on "Page". At least it works on Mac OSX and Pharo 5.
Ohh, of course (feeling embarrassed now). Thanks! Alistair
participants (4)
-
Alistair Grant -
Cyril Ferlicot D. -
John Pfersich -
stepharo