[Pharo-project] Good practicces! Looking for examples
Hi guys talking with sven during the last sprint we realized that it would be good to collect and document some good practices. So I started a chapter for PBE2 on coding practices. I will take the some of the optimization that sven did in time/date printOn: as a start If you have some suggestions with examples I could integrate to the chapter. Stef
Not sure what you mean with good coding practice, but here my contrib: - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function - writing test before fixing code - having short methods Alexandre On 24 Dec 2011, at 10:53, Stéphane Ducasse wrote:
Hi guys
talking with sven during the last sprint we realized that it would be good to collect and document some good practices. So I started a chapter for PBE2 on coding practices.
I will take the some of the optimization that sven did in time/date printOn: as a start
If you have some suggestions with examples I could integrate to the chapter.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
Bad practices and anti-pattern might be very instructive too... Nicolas 2011/12/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
Yes this is what I wrote in the 4 pages so far :) Stef On Dec 24, 2011, at 4:18 PM, Nicolas Cellier wrote:
Bad practices and anti-pattern might be very instructive too...
Nicolas
2011/12/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
Oh, but I didn't understand it was about optimization... Good practice is to not optimize prematurely ;) For example, inlining some message send, replacing explicit iteration message by more obscure to:do: or whileTrue: loops etc... are not good practices, just compromises... Nicolas 2011/12/24 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Bad practices and anti-pattern might be very instructive too...
Nicolas
2011/12/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
On Dec 24, 2011, at 4:28 PM, Nicolas Cellier wrote:
Oh, but I didn't understand it was about optimization... Good practice is to not optimize prematurely ;)
Not only but I started to collect what I have
For example, inlining some message send, replacing explicit iteration message by more obscure to:do: or whileTrue: loops etc... are not good practices, just compromisesâ¦
Indeed :) I would like something more in the vein of Smalltalk by Example Stef
Nicolas
2011/12/24 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Bad practices and anti-pattern might be very instructive too...
Nicolas
2011/12/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
Stef, My current working theory is that the command pattern is indeed good practice; it also has a way of exacting a price for the flexibility. Objects as functions are useful. I do a fair amount of that in gathering data from/about various algorithms. The objects can (by inheritance) share details of what to record (with overrides where needed) and then do their own thing on what/how to compute. Add a #subclassResponsibility method for the algorithm's name/label, and the result is fairly nice. FWIW, I sometimes ask myself why I "bothered" to use command (as I said, it is powerful and trouble all at the same time), but I don't recall regret over objects as functions. Find bug, write failing test, fix bug with help of new test, in that order; +10. Short methods - not always!! :) I am reminded of the first time I *enrolled* in a numerical analysis class. Details below for those who have nothing better to do. During that one lecture I attended, he said many things of interest. He talked about generic programming, using equations of lines (Ax+By=C always works, slope-intercept can become indeterminate). He didn't care what language we chose to use for exercises, because (without a hint of arrogance about it) "I will be able to READ (his emphasis) anything in common use." There was more (not bad for a first day of an undergraduate class). The relevant point was his description of structured programming as an alternative to goto instructions. But he said something that was a new thought to me at the time: the problem was not the goto, it was the label, which invites jumps from anywhere. My point? Short methods come at the cost of many little methods. Each of those "helper" methods is what Dr. X would see as a label. Think about it. Please do not suggest that we enforce private methods in Smalltalk, because the code still reads the same way, and all it really does is force people to copy methods or create forwarding methods to be able to call what they want, making more entry points - IMHO at least. I am *not* saying that we should have a minimum line length for methods, but there are indeed times when it helps to put an entire thought in one place. If it helps any, I usually encounter this in methods that fork processes. By the time the process gets a loop started, has an #ensure: block to clean up after itself, has a critical section or two, etc., it's not what one would call short, but IMHO, it is one "phrase" that is best seen as a whole. Bill So what's all this about enrolling for a class I didn't take? My undergraduate advisor was an interesting guy. One of the more colorful instructions he gave me was to try to get ahead of things by taking numerical analysis as taught by the computer science department; scheduling details meant that I would get the course almost a year earlier than would have otherwise been possible. One caveat: I had clear instructions that if (let's call him Dr. X) was assigned to teach it, leave immediately, drop the course and add (I forget what) in its place. You already know what happened: Dr. X walked in the room. Not wanting to walk out in the middle of his lecture, I stuck around. After about 20 minutes, I really wanted to take the class, which is why I tried to talk my advisor into letting me do so, but he was emphatic that Dr. X was a first class nut job (some US slang) and that I would end up being just one more bright student who would come back screaming - he had tried several times earlier, always with the same results. With that, I followed his instructions and took numerical analysis in turn. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, December 24, 2011 9:51 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Good practicces! Looking for examples On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
Not sure what you mean with good coding practice, but here my contrib:
- the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
- writing test before fixing code - having short methods indeed
Here is what I started to write.
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ? Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ? tia  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance. If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged. If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it? -- Best regards, Igor Stasenko.
On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
Igor, I think he is not criticizing that. What he points out is not the lack of maintenance but a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here. Cheers
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote
a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Yes, something is needed. Squeak has revived SqueakMap and documented a procedure. See http://forum.world.st/How-to-publish-software-for-Squeak-4-3-td4240339.html -- View this message in context: http://forum.world.st/Good-practicces-Looking-for-examples-tp4231211p4243480... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
For pharo this is simple: create a configurationOf and publish it in MetacelloRepository. I do not have the cycles to put in place what I wanted for Pharo1.2, Pharo1.3 distributions i.e. specific MetacelloRepositories per version so if somebody wants to really get an impact for Pharo he should contact me and we can discuss about the next steps. Stef
Mariano Martinez Peck wrote
a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Yes, something is needed. Squeak has revived SqueakMap and documented a procedure. See http://forum.world.st/How-to-publish-software-for-Squeak-4-3-td4240339.html
-- View this message in context: http://forum.world.st/Good-practicces-Looking-for-examples-tp4231211p4243480... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
Igor, I think he is not criticizing that. What he points out is not the lack of maintenance but a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Well, it is just another side of same problem. If package maintainer wants its package to work without problems with Pharo, usually, he takes care of everything, from checking if it works with latest pharo up to mentioning where and how it can be loaded/used. And if people don't care about their stuff, it is just rots and dies. Any attempts to do that externally (by people who don't maintain own projects directly) are futile and counterproductive. Because it is fine, you can spend couple of hours verifying that some software works ok today, "certify" it and list it in some "catalogue". But then tomorrow something will be changed and again package will be broken/stop working properly. So unless you maintaining your software continuously, there's no other way to guarantee that it works and will keep working in future. Remember the SqueakMap and Universe? They meant to solve same problem. But you cannot solve it automatically, because putting a package into list of certified packages does not guarantees that if today it works, it will keep working tomorrow. I seen numerous complaints about that in Universe, when people were really annoyed that package is listed in it, but cannot be loaded and so on. As a result, nobody using Universe today.
Cheers
-- Best regards, Igor Stasenko.
On 30 December 2011 09:49, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
Igor, I think he is not criticizing that. What he points out is not the lack of maintenance but a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Well, it is just another side of same problem. If package maintainer wants its package to work without problems with Pharo, usually, he takes care of everything, from checking if it works with latest pharo up to mentioning where and how it can be loaded/used. And if people don't care about their stuff, it is just rots and dies.
Any attempts to do that externally (by people who don't maintain own projects directly) are futile and counterproductive. Because it is fine, you can spend couple of hours verifying that some software works ok today, "certify" it and list it in some "catalogue". But then tomorrow something will be changed and again package will be broken/stop working properly. So unless you maintaining your software continuously, there's no other way to guarantee that it works and will keep working in future. Remember the SqueakMap and Universe? They meant to solve same problem. But you cannot solve it automatically, because putting a package into list of certified packages does not guarantees that if today it works, it will keep working tomorrow.
Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo 1.3" point to immutable chunks of code. And of course they must be immutable, because otherwise your versioning's useless. Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD requires maintenance, right up until 1.4 enters code freeze. Once 1.4 is released, Foo 1.2 can be released, and you can safely know - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 can load cleanly and work correctly in Pharo 1.4. And so on. frank
I seen numerous complaints about that in Universe, when people were really annoyed that package is listed in it, but cannot be loaded and so on. As a result, nobody using Universe today.
Cheers
-- Best regards, Igor Stasenko.
On 30 December 2011 10:54, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 December 2011 09:49, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
Igor, I think he is not criticizing that. What he points out is not the lack of maintenance but a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Well, it is just another side of same problem. If package maintainer wants its package to work without problems with Pharo, usually, he takes care of everything, from checking if it works with latest pharo up to mentioning where and how it can be loaded/used. And if people don't care about their stuff, it is just rots and dies.
Any attempts to do that externally (by people who don't maintain own projects directly) are futile and counterproductive. Because it is fine, you can spend couple of hours verifying that some software works ok today, "certify" it and list it in some "catalogue". But then tomorrow something will be changed and again package will be broken/stop working properly. So unless you maintaining your software continuously, there's no other way to guarantee that it works and will keep working in future. Remember the SqueakMap and Universe? They meant to solve same problem. But you cannot solve it automatically, because putting a package into list of certified packages does not guarantees that if today it works, it will keep working tomorrow.
Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo 1.3" point to immutable chunks of code. And of course they must be immutable, because otherwise your versioning's useless.
Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD requires maintenance, right up until 1.4 enters code freeze.
Once 1.4 is released, Foo 1.2 can be released, and you can safely know - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 can load cleanly and work correctly in Pharo 1.4. And so on.
What you described here is a normal _maintenance_ process. Now if there's no people who doing it, how it can magically keep working? There's no any guarantees for that. Because Pharo does not standing still, it moves and evolves. My main point is that questions like "why it cannot be loaded?" should be addressed to right person(s) who is responsible for maintaining particular project. And if there's none, then you can make it work by yourself but again, ask right questions like "class is missing, what can i do" instead of "my beloved package stops working what can you do".
frank
-- Best regards, Igor Stasenko.
On 30 December 2011 10:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 December 2011 10:54, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 December 2011 09:49, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
Igor, I think he is not criticizing that. What he points out is not the lack of maintenance but a clear way of knowing which project/packages are expected to work or not in Pharo. If you take a random package/project from SS there is no way to know that. Having a Pharo catalog/certified packages/projects would help here.
Well, it is just another side of same problem. If package maintainer wants its package to work without problems with Pharo, usually, he takes care of everything, from checking if it works with latest pharo up to mentioning where and how it can be loaded/used. And if people don't care about their stuff, it is just rots and dies.
Any attempts to do that externally (by people who don't maintain own projects directly) are futile and counterproductive. Because it is fine, you can spend couple of hours verifying that some software works ok today, "certify" it and list it in some "catalogue". But then tomorrow something will be changed and again package will be broken/stop working properly. So unless you maintaining your software continuously, there's no other way to guarantee that it works and will keep working in future. Remember the SqueakMap and Universe? They meant to solve same problem. But you cannot solve it automatically, because putting a package into list of certified packages does not guarantees that if today it works, it will keep working tomorrow.
Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo 1.3" point to immutable chunks of code. And of course they must be immutable, because otherwise your versioning's useless.
Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD requires maintenance, right up until 1.4 enters code freeze.
Once 1.4 is released, Foo 1.2 can be released, and you can safely know - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 can load cleanly and work correctly in Pharo 1.4. And so on.
What you described here is a normal _maintenance_ process. Now if there's no people who doing it, how it can magically keep working? There's no any guarantees for that. Because Pharo does not standing still, it moves and evolves.
Indeed, it is _precisely_ a normal maintenance process, which is why I'm surprised that people are even talking about it. If you're actually writing an application against Pharo's HEAD, well, be prepared to run to keep up. And if you want to use such an application, you're on the bleeding edge, so hopefully you have some bandages. Pharo - or any other application - might move and evolve, but each version marks - or should! - a frozen point in time, a stable mark. In other words, applications released against _particular_ Pharo versions _should not rot_. They might not load in the latest Pharo, but that's what support is for. And to your main point, I can only agree: there's no substitute for the need for people to support the application to keep it up to date. frank
My main point is that questions like "why it cannot be loaded?" should be addressed to right person(s) who is responsible for maintaining particular project. And if there's none, then you can make it work by yourself but again, ask right questions like "class is missing, what can i do" instead of "my beloved package stops working what can you do".
Vigourous agreement. Which means that SqueakMap (or whatever) should point to the responsible person/s (as it can), so the beloved user could pester the right person. You still need some kind of process to handle cases like a maintainer retiring, of course. Again, a solved problem in many communities. (Hey, maybe it's already solved in Pharo, too: I can't claim to know more than a dabbler. I don't want to sound like I'm pointing fingers.) frank
frank
-- Best regards, Igor Stasenko.
What if a class was deleted in Pharo? What if some methods are missing? What if it's referring to a Preference while we dumped this in favor of settings ? What if it's using some Morphic stuff that was cleaned up. Your comment assumes that everything on SqueakSource is outdated an unusable. FYI, lots of packages there (that are 5 years old) ***do load cleanly*** in Squeak 4.3... Besides, there are LOTS of Squeak users that maintain their stuff only for Squeak without considering Pharo. Should we maintain those packages by adding some "PharoCompatibility" classes or we should start our own repository ? Finally, it's not because a package is 5 years old that it's not useful... If it's there and freely available, why would we throw all this code to the trash ? To reinvent the wheel ? I think we should seriously consider porting a lot of this stuff to our own repository before the distance between Squeak and Pharo gets too big. My 2 cents. P.S. I've read this on the #pharo-project channel on IRC : "yeah, Pharo is great but nothing on SqueakSource works with it"  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
________________________________ From: Igor Stasenko <siguctua@gmail.com> To: Pharo-project@lists.gforge.inria.fr; Benoit St-Jean <bstjean@yahoo.com> Sent: Thursday, December 29, 2011 11:02:01 AM Subject: Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !
On 29 December 2011 15:44, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
The recipe is simple: maintenance.
If you really care, spend time maintaining packages you using. If nobody cares to maintain the software, it is dead. It is only a matter of time for it to get broken. We cannot give any guarantee that something which worked fine 10 years ago will keep working today, without keeping everything unchanged.
If you have a garden and planted a rose there, do you expect that 5 years later it will still grow there, without you taking care of it?
-- Best regards, Igor Stasenko.
Em 29/12/2011 16:48, Benoit St-Jean < bstjean@yahoo.com > escreveu: Benoit, You rise some important points, this is my attempt to contribute:
What if a class was deleted in Pharo?Â
We should get a thorough analysis of the case and understand if the deleted class does indeed makes its lacking or if the package in SS has to be re-engineered to be compatible with the Pharo view. Then two outcomes are possible: a recipe for the similar cases where the lack of the deleted class is created or we understand the deletion as a mistake and reintroduce or replace it with a new implementation of it.
What if some methods are missing?Â
Same general methodology: were they suppressed but replaced by others? Or were they removed due being only specific to some package and did not belong to the places they were in the classes hierarchy? Perhaps were they just 'syntactic sugar' and thus have to be replaced by another code snippet?
What if it's referring to a Preference while we dumped this in favor of settings ? What if it's using some Morphic stuff that was cleaned up. Your comment assumes that everything on SqueakSource is outdated an unusable.Â
FYI, lots of packages there (that are 5 years old) ***do load cleanly*** in Squeak 4.3...
Makes sense, after of all there is called SqueakSource, isn't it?
Besides, there are LOTS of Squeak users that maintain their stuff only for Squeak without considering Pharo.Â
To which I think the whole Stef's post applies! If _we_ Pharo comunity long or want that package in our changed Smalltalk, we should adapt it. Our wage is that in time the package originators may become convinced of the advantages of: or switching to Pharo, or maintaining in both 'dialects'.
Should we maintain those packages by adding some "PharoCompatibility" classes or we should start our own repository ?
I'm a firm believer that '"PharoCompatibility" classes' are no-no. We rather have a repo which has packages adapted to Pharo as Stef described.
Finally, it's not because a package is 5 years old that it's not useful... If it's there and freely available, why would we throw all this code to the trash ? To reinvent the wheel ? I think we should seriously consider porting a lot of this stuff to our own repository before the distance between Squeak and Pharo gets too big.
I think each package needs to be considered in isolation, no general rule can be created for all cases without incurring in the risk of going irrational... My 0.0199999.... -- Cesar Rabak
On Dec 29, 2011, at 7:48 PM, Benoit St-Jean wrote:
What if a class was deleted in Pharo? What if some methods are missing? What if it's referring to a Preference while we dumped this in favor of settings ? What if it's using some Morphic stuff that was cleaned up. Your comment assumes that everything on SqueakSource is outdated an unusable.
You did not reply to my question: what packages do not load?
FYI, lots of packages there (that are 5 years old) ***do load cleanly*** in Squeak 4.3...
Besides, there are LOTS of Squeak users that maintain their stuff only for Squeak without considering Pharo.
How many? And we cannot force them. So what is the solution? Should we stop pharo?
Should we maintain those packages by adding some "PharoCompatibility" classes or we should start our own repository ? The way people want. Now you ****CANNOT**** imagine how this is difficult to manage a monolithic system with full of unused code and complex duplicated half done logic.
Finally, it's not because a package is 5 years old that it's not useful... If it's there and freely available, why would we throw all this code to the trash ? To reinvent the wheel ? I think we should seriously consider porting a lot of this stuff to our own repository before the distance between Squeak and Pharo gets too big.
Indeed. Now nothing prevent the community to look at important packages and decide to maintain them. See the list at the end for an example.
My 2 cents.
What do you mean?
P.S. I've read this on the #pharo-project channel on IRC : "yeah, Pharo is great but nothing on SqueakSource works with it"
Reply to my question: - what exact packages? - what added value? Now tell me: just compare the two next methods and tell me which you believe will let us have multitouch support for real in the future? You can also look at generateKeyboardEvent: if you are not afraid. generateMouseEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | position buttons modifiers type trail stamp oldButtons evtChanged | evtBuf first = lastEventBuffer first ifTrue: ["Workaround for Mac VM bug, *always* generating 3 events on clicks" evtChanged := false. 3 to: evtBuf size do: [:i | (lastEventBuffer at: i) = (evtBuf at: i) ifFalse: [evtChanged := true]]. evtChanged ifFalse: [^nil]]. stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. position := evtBuf third @ evtBuf fourth. buttons := evtBuf fifth. modifiers := evtBuf sixth. type := buttons = 0 ifTrue: [lastEventBuffer fifth = 0 ifTrue: [#mouseMove] ifFalse: [#mouseUp]] ifFalse: [lastEventBuffer fifth = 0 ifTrue: [#mouseDown] ifFalse: [#mouseMove]]. buttons := buttons bitOr: (modifiers bitShift: 3). oldButtons := lastEventBuffer fifth bitOr: (lastEventBuffer sixth bitShift: 3). lastEventBuffer := evtBuf. type == #mouseMove ifTrue: [trail := self mouseTrailFrom: evtBuf. ^MouseMoveEvent basicNew setType: type startPoint: (self position) endPoint: trail last trail: trail buttons: buttons hand: self stamp: stamp]. ^MouseButtonEvent basicNew setType: type position: position which: (oldButtons bitXor: buttons) buttons: buttons hand: self stamp: stamp handleMouseInputEvent: sysEvent | type oldButtons | type := sysEvent typeBasedOnPreviousEvent: self lastSystemEvent. oldButtons := self lastSystemEvent buttons. lastSystemEvent := sysEvent. type == #mouseMove ifTrue: [ ^MouseMoveEvent basicNew setType: type startPoint: self position endPoint: sysEvent trail last trail: sysEvent trail buttons: sysEvent buttons hand: self stamp: sysEvent timeStamp]. ^MouseButtonEvent basicNew setType: type position: self position which: ( oldButtons bitXor: sysEvent buttons) buttons: sysEvent buttons hand: self stamp: sysEvent timeStamp See the list at the end - XML - Soup - XMLRPC - OmniBrowser 6.2 Automatic Method Categorizer 6.3 Script Manager 6.4 Shout 6.5 OCompletion 6.6 Pharo Non Core Packages 6.7 New Inspector 6.8 Refactoring Browser 6.8.1 Programmatically Refactor Method Example 6.9 Nile 6.10 ProfStef 6.11 Metacello 6.12 Memory Monitor 6.13 Mondrian 6.14 Spy 6.15 SqueakDBX 6.16 Moose 6.17 Seaside 6.18 Pier 6.19 Magritte 6.20 Class Use Discovery 6.21 RemoteFrameBuffer 6.22 Glorp 6.23 Magma 6.24 Goods 6.25 SandstoneDB 6.26 TokyoTyrant 6.27 Cassandra 6.28 FFI 6.29 Postgres Driver 6.30 SIXX 6.31 SqueakSave 6.32 CouchDB 6.33 SPrevayler 6.34 Riak 6.35 Pharogenesis 6.36 Fuel 6.37 Monticello 6.38 Gofer 6.39 Metacello Browser 6.40 Autotest 6.41 Filesystem 6.42 HelpSystem 6.43 OSProcess
Benoit Let us start with some concrete questions - Do you have a concrete list of package not working? - Then do you prefer to have a vectorial UI with zomable facilities, clean code or just and old fuzzy bitmap. Same question: do you prefer Zinc and a nice HTTP layer or and old pre internet library? - Do you expect DOS applications to work nowadays? Do you care? Stef On Dec 29, 2011, at 3:44 PM, Benoit St-Jean wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Probably. With quality-rules run automatically, style checking rules and some more. And with tests of course and automatically. We should have a Pharo distribution. I will come.
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
tia
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
1) readily available, no 2) I was not necessarily thinking about the UI. For instance, a lot of stuff still references Preferences and break on load. 3) Yeah, I do have a few DOS application that I do care about because, so far, after all those years, they're the best at doing what they were designed for an no Java (or anything else) apps have replaced them in terms of performance and features. They're mostly tools but they work great and I haven't found any decent replacement for them. Beside, this is a weak argument Stephane! Do you still need that crappy 50 years old language called COBOL ? I guess so, in some cases! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
________________________________ From: Stéphane Ducasse <stephane.ducasse@inria.fr> To: Pharo-project@lists.gforge.inria.fr; Benoit St-Jean <bstjean@yahoo.com> Sent: Thursday, December 29, 2011 11:07:13 AM Subject: Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !
Benoit
Let us start with some concrete questions    - Do you have a concrete list of package not working?    - Then do you prefer to have a vectorial UI with zomable facilities, clean code or just and old fuzzy bitmap.    Same question: do you prefer Zinc and a nice HTTP layer or and old pre internet library?    - Do you expect DOS applications to work nowadays? Do you care?
Stef
On Dec 29, 2011, at 3:44 PM, Benoit St-Jean wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?Â
Probably. With quality-rules run automatically, style checking rules and some more. And with tests of course and automatically.
We should have a Pharo distribution. I will come.
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
tia  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
On Dec 29, 2011, at 7:52 PM, Benoit St-Jean wrote:
1) readily available, no ?
Again what is the list of package not loading that are important for you.
2) I was not necessarily thinking about the UI. For instance, a lot of stuff still references Preferences and break on load.
So what is the point? We should have a Preferences packages with the squeak preferences? Sure it was in Deprecated 1.2. Then? Now if you do one publish it.
3) Yeah, I do have a few DOS application that I do care about because, so far, after all those years, they're the best at doing what they were designed for an no Java (or anything else) apps have replaced them in terms of performance and features. They're mostly tools but they work great and I haven't found any decent replacement for them. Beside, this is a weak argument Stephane! Do you still need that crappy 50 years old language called COBOL ? I guess so, in some cases!
No it is not. Look at Mac.
2011/12/29 Benoit St-Jean <bstjean@yahoo.com>:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
This is not a direct reply to your concerns, but maybe Pharo should stick to this convention regarding the semantic versioning in the future: http://semver.org/ This implies that a public API should be established clearly and maybe this is not for tomorrow ;-) I wondering if the conformity check to this specification could be automatically done in Pharo. I guess yes because we have access to all the code with MC. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
We can yet know which packages load in Pharo 1.2 / 1.3, .... it's written in the ConfigurationOf......>>stable: spec <symbolicVersion: #stable> spec for: #'pharo1.2.x' version: '1.0'. spec for: #'pharo1.3.x' version: '1.1'. Would be nice / necessary to script upcoming SmalltalkHub and render automatically the compatibility list. Automatic dashboard and good indicators are the first step. Second nice step would be automatic testing that each ConfigurationOf loads according according to what is declared. Jenkins to the rescue. It seems stable API is always subject to controversy and will slow down the release process. Pharo already has a deprecation policy. I do not see the point of taking a 5 years old package and expect to load it correctly in current Pharo (especially in an open source platform). Custom solutions mixing old, new and legacy stuff will always be a pains and lot of work, stable API or not - except (maybe) when high test coverage is present (at least it's far easier). Now I believe in fixed length iteration that provide some answers to moving packages from one version to another. Example: - 4 months development of Pharo (new features) - 1 / 2 months feature freeze and fix - now guys upgrade your packages we won't break things anymore. - write announcements and release. Good process, automation and visibility is one key for me. Laurent On Thu, Dec 29, 2011 at 3:44 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:
I was wondering what is planned regarding packages available on SqueakSource and Pharo. More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo. Are we looking at a Pharo-only kind of SqueakSource in the future ?
Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed. I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ?
tia
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
On 24 December 2011 14:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
If you have some suggestions with examples I could integrate to the chapter.
Hernán had a good list in his talk on the design of patagonia: http://www.slideshare.net/esug/design-principlesbehindpatagonia -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
indeed the presentation is quite good and I like the tips section. Right now I started to collect coding examples (i.e. do not use , but nextPutAll:â¦.). Stef On Dec 25, 2011, at 3:26 AM, Damien Pollet wrote:
On 24 December 2011 14:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
If you have some suggestions with examples I could integrate to the chapter.
Hernán had a good list in his talk on the design of patagonia: http://www.slideshare.net/esug/design-principlesbehindpatagonia
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Don't forget, there are lectures on idioms and best practice patterns with lots of examples in the Smalltalk course. https://www.iam.unibe.ch/scg/svn_repos/Lectures/Smalltalk/ Many of these come from Kent Beck's book. - on On 25 Dec 2011, at 10:11, Stéphane Ducasse wrote:
indeed the presentation is quite good and I like the tips section. Right now I started to collect coding examples (i.e. do not use , but nextPutAll:â¦.).
Stef
On Dec 25, 2011, at 3:26 AM, Damien Pollet wrote:
On 24 December 2011 14:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
If you have some suggestions with examples I could integrate to the chapter.
Hernán had a good list in his talk on the design of patagonia: http://www.slideshare.net/esug/design-principlesbehindpatagonia
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Stef, you should also refere to Kent Beck's book "SmallTalk Best Practice Patterns" in your chapter. IMHO it's one of the best Smalltalk books written in this area. Franz Josef Am 24.12.2011 14:53, schrieb Stéphane Ducasse:
Hi guys
talking with sven during the last sprint we realized that it would be good to collect and document some good practices. So I started a chapter for PBE2 on coding practices.
I will take the some of the optimization that sven did in time/date printOn: as a start
If you have some suggestions with examples I could integrate to the chapter.
Stef
"Franz" == Franz Josef Konrad <franzl@fjkonrad.de> writes:
Franz> Stef, Franz> you should also refere to Kent Beck's book "SmallTalk Best Practice Patterns" Franz> in your chapter. IMHO it's one of the best Smalltalk books written in this Franz> area. But... it's not "SmallTalk"... it's "Smalltalk". I wonder why people keep doing that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
blame the German Amazon site for that... I've copied the title from there to make sure that I don't write it wrong ... <http://www.amazon.de/SmallTalk-Best-Practice-Patterns-Kent/dp/013476904X> Sorry Randal, for not fixing that ... Am 25.12.2011 15:33, schrieb Randal L. Schwartz:
"Franz" == Franz Josef Konrad<franzl@fjkonrad.de> writes:
Franz> Stef, Franz> you should also refere to Kent Beck's book "SmallTalk Best Practice Patterns" Franz> in your chapter. IMHO it's one of the best Smalltalk books written in this Franz> area.
But... it's not "SmallTalk"... it's "Smalltalk". I wonder why people keep doing that.
participants (16)
-
Alexandre Bergel -
Benoit St-Jean -
csrabak＠bol.com.br -
Damien Pollet -
Frank Shearar -
Franz Josef Konrad -
Igor Stasenko -
laurent laffont -
Mariano Martinez Peck -
merlyn＠stonehenge.com -
Nicolas Cellier -
Oscar Nierstrasz -
Schwab,Wilhelm K -
Sean P. DeNigris -
Serge Stinckwich -
Stéphane Ducasse