Re: [Pharo-dev] OSProcess for Pharo3.0
Goubier Thierry wrote Le 06/09/2013 14:13, Marcus Denker a écrit : So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability. I'm OK for that. 3.0 is just plainly too unstable, and this is the way it should be. But 2.0 shouldn't be considered a dead platform ;) I feel the same pain and was motivated enough to create my special interim version mentioned above. And, having previously backported autocompletion (for 1.4 iirc), I can verify that backporting requires significant manpower. I introduced bugs which I then felt compelled to spend many hours fixing (instead of working) because I had broken production software. Given our massive vision, I feel that manpower is better spent moving forward. And I am willing to deal with the pain of feeling one step behind development if it gets us to the system of our dreams. - Cheers, Sean -- View this message in context: http://forum.world.st/OSProcess-for-Pharo3-0-tp4706087p4707036.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 05/09/2013 22:04, Stéphane Ducasse a écrit : Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact. As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works (who did it, already? Sean? Sven?). But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0. I'll do. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get touched by these bugs. 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and the story will never ends. And there I can only disagree with you. * I do want you on an unstable Pharo, something moving and changing fast to be able to aim for the sky and bring me a smile for what tomorrow will bring me... * I want a stable Pharo, because this is where my work takes place, and there bugs should really get fixed... * I want old stable Pharo(s), because, if my work goes into production, it may stay there for years. * And I want a nice path from today's stable to the next stable to be able to port my code as soon as possible (for example, we did OSProcess this time... but I believe there is a chance this work will have to be done again before 3.0 is released ;)) Insisting for 3.0 based developpement means I require additional code to the core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for 3.0 is extremely difficult, with very disruptive changes coming often. And one get tired of complaining; at one point I just open a bugfix, create a slice and add a line to my image building makefiles to load the bugfix because bickering about whether it should be integrated or not isn't worth the time spent on it. So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze), and 4.0 alpha (experimental), and maybe different teams for handling each of those (and releases on a six months basis?). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 6, 2013, at 9:33 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 05/09/2013 22:04, Stéphane Ducasse a écrit : Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact. As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works (who did it, already? Sean? Sven?). no, we don't bah, we have 2S, which would be the 2.5 if you want. Also Sean made something to install some new issues from 3 in the older version... but that's not a new version, is just that Sean wanted to have some things immediately :) But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0. I'll do. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get touched by these bugs. 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and the story will never ends. And there I can only disagree with you. * I do want you on an unstable Pharo, something moving and changing fast to be able to aim for the sky and bring me a smile for what tomorrow will bring me... * I want a stable Pharo, because this is where my work takes place, and there bugs should really get fixed... * I want old stable Pharo(s), because, if my work goes into production, it may stay there for years. * And I want a nice path from today's stable to the next stable to be able to port my code as soon as possible (for example, we did OSProcess this time... but I believe there is a chance this work will have to be done again before 3.0 is released ;)) Insisting for 3.0 based developpement means I require additional code to the core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for 3.0 is extremely difficult, with very disruptive changes coming often. And one get tired of complaining; at one point I just open a bugfix, create a slice and add a line to my image building makefiles to load the bugfix because bickering about whether it should be integrated or not isn't worth the time spent on it. So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze), and 4.0 alpha (experimental), and maybe different teams for handling each of those (and releases on a six months basis?). that's not possible because that implies manpower that we do not have, and thats, so far, a reality that will not change in the near future. So, what we have is: stable branch (now 2.0), unstable branch (now 3.0), and when we release pharo3, that will become stable and the next branch will be unstable, while 2.0 will fade out. the effort of maintaining multiple versions is exponential, not linear. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 06/09/2013 14:13, Marcus Denker a écrit : So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability. I'm OK for that. 3.0 is just plainly too unstable, and this is the way it should be. But 2.0 shouldn't be considered a dead platform ;) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On 09/05/2013 05:01 AM, David T. Lewis wrote: On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote: Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I do not think that there is any right or wrong answer to this, it is perhaps a matter of personal perspective. For me, much of my professional experience is related to supporting manufacturing operations for a large commercial company. In this environment, the ability to engineer solutions to new problems without disrupting existing operations is critical. To me, a failure related to software changes is not just a red mark on a unit test, it is a significant emotional event if I cause a manufacturing plant to stop production (thankfully this has rarely happened in my career so far, knock wood). So maybe this makes me conservative, but from my point of view the ability to deliver future versions of software that work without breaking older versions is a matter of good engineering discipline, and I stand by that as a matter of principle. This is a very good principle :). As an example, at 3DICC we are currently on Squeak4.1, but I think it wasn't that long ago that it was 3.8 based. Of course, all things come to an end. But with larger systems the life cycles are often unbelievably long. regards, Göran
Re: [Pharo-dev] OSProcess for Pharo3.0
Thanks. I have merged -dtl.33 and two more change in OSProcess-Base-ThierryGoubier.35 on http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ (osVersion and vmVersion), if you want to merge them as well. I have a question: are you sure about the perform: #delete in OSProcess class#deleteFileNamed: ? ensureDelete/ensureDeleted have a different behavior than #delete. Regards, Thierry Le 05/09/2013 04:21, David T. Lewis a écrit : On Wed, Sep 04, 2013 at 02:17:29PM +0200, Marcus Denker wrote: On Sep 4, 2013, at 2:13 PM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 05/09/2013 14:19, David T. Lewis a écrit : On Thu, Sep 05, 2013 at 11:18:27AM +0200, Goubier Thierry wrote: Thanks. I have merged -dtl.33 and two more change in OSProcess-Base-ThierryGoubier.35 on http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ (osVersion and vmVersion), if you want to merge them as well. Thanks! I have a question: are you sure about the perform: #delete in OSProcess class#deleteFileNamed: ? ensureDelete/ensureDeleted have a different behavior than #delete. No, I am not sure about this. It is probably a bug. If you have a correction, I appreciate it. OSProcess-Base-ThierryGoubier.36 in the same place: http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ Thanks a lot for your help :) Dave And I appreciate you welcoming my contributions to OSProcess :) OSProcess is something I really need to work with Pharo. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. The system is still not in a situation where changes are simple and with limited impact. But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I'm not sure :) Because I regularly figure out that **I** do NOT understand how exactly it is difficult and demanding energy to produce something good. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get touched by these bugs. 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and the story will never ends. Stef Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. Yes we admit it and then? We are concerned to help people. Did you run the rules generated from 1.4-2.0 activity because we are creating to help people migrating. We are fthinking about having better support to automatically migrate code based on changes (but for that we need manpower). And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. This is what we are doing. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: Open bug entries and propose some code. You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying All software development should be done on 3.0 [Camillo Bruni]. Give us any ideas how to help you and we will. This is why I propose to even undeprecate certain key features if it helps providing more stability from the users side. I understand that not everybody is working in 3.0. Stef Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Thu, Sep 05, 2013 at 03:31:06PM +0200, Goubier Thierry wrote: Le 05/09/2013 14:19, David T. Lewis a ?crit : On Thu, Sep 05, 2013 at 11:18:27AM +0200, Goubier Thierry wrote: Thanks. I have merged -dtl.33 and two more change in OSProcess-Base-ThierryGoubier.35 on http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ (osVersion and vmVersion), if you want to merge them as well. Thanks! I have a question: are you sure about the perform: #delete in OSProcess class#deleteFileNamed: ? ensureDelete/ensureDeleted have a different behavior than #delete. No, I am not sure about this. It is probably a bug. If you have a correction, I appreciate it. OSProcess-Base-ThierryGoubier.36 in the same place: http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main/ I merged your fixes back into the OSProcess repository. Thank you :-) Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. Excellent. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. If you need help let me know. Stef
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 21:04, Camillo Bruni a écrit : On 2013-09-03, at 09:36, Goubier Thierry thierry.goub...@cea.fr wrote: And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... exactly, and for each Pharo version there is a different branch of OSProcess. Sometimes, you just have to go with how the software you are using and updating is handling this adaptation... If it's something by you, I won't hesitate to branch and fork :) well, once you start working on git you see the advantages of branches ;) too bad that the monticello tools do not properly support this feature. Yes, I was thinking of how to use git branches for gitfiletree:// repositories and couldn't find a right way to integrate it into Monticello, apart from displaying the current branch when browsing a git repository. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 08:38, Marcus Denker a écrit : On Sep 4, 2013, at 4:52 AM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. right now, there are 3 bugs reported for Pharo 2.0: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed none of which is fixed in Pharo3 yet. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 09:40, Marcus Denker a écrit : Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 10:00 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 04/09/2013 09:40, Marcus Denker a écrit : Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do what we did in Pharo3 in Pharo2, then these Problems are in Pharo2. But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. What is a solution other than stopping development and declaring Pharo as finished as it is? Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 10:06, Marcus Denker a écrit : On Sep 4, 2013, at 10:00 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 04/09/2013 09:40, Marcus Denker a écrit : Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do what we did in Pharo3 in Pharo2, then these Problems are in Pharo2. But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying All software development should be done on 3.0 [Camillo Bruni]. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@cea.fr wrote: But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only solution is to stop doing, then the pain stops but there will be no future. e.g. imagine we would say: Yes, you convinced us to stop. Pharo is finished. Then someone else would develop SuperSmalltalk which is more or less what Pharo 6 would have been, and it's even released around that time. What will the reactions of the Pharo users be? - I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago! ? And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix. You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying All software development should be done on 3.0 [Camillo Bruni]. Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it? Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 11:27, Marcus Denker a écrit : On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@cea.fr wrote: But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only solution is to stop doing, then the pain stops but there will be no future. You're arguing the extreme there :) Forced march to 3.0 seems difficult and counter productive to me, that's all. e.g. imagine we would say: Yes, you convinced us to stop. Pharo is finished. Then someone else would develop SuperSmalltalk which is more or less what Pharo 6 would have been, and it's even released around that time. What will the reactions of the Pharo users be? - I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago! ? I'm sure you are good enough to convince people to switch to 3.0 even if 2.0 has no bugs. And there will still be new things for 4.0, 5.0, 6.0, ... Many things in store for 3.0 are very interesting and motivating; it's just that, given the state of things, I have to wait and get 2.0 fixed as well as possible. And get ready to transition to 3.0 as smoothly as possible (and repeat for the next version)... And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix. You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying All software development should be done on 3.0 [Camillo Bruni]. Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it? That's the point :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
I don't understand where the tragedy is.. you want your production code to work in Pharo 2.0? Write it to work well in 2.0, don't care about 3.0 or any other future possible changes. Want your code to work on bleeding-edge 3.0 image? Refactor/do the changes to make it work.. leave 2.0 behind. You want both? So, keep 2 separate versions for each version of system. You just have to accept that there is no code which will magically stay compatible with all old and all possible future versions without any changes. On 4 September 2013 11:27, Marcus Denker marcus.den...@inria.fr wrote: On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@cea.fr wrote: But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only solution is to stop doing, then the pain stops but there will be no future. e.g. imagine we would say: Yes, you convinced us to stop. Pharo is finished. Then someone else would develop SuperSmalltalk which is more or less what Pharo 6 would have been, and it's even released around that time. What will the reactions of the Pharo users be? - I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago! ? And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix. You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying All software development should be done on 3.0 [Camillo Bruni]. Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it? Marcus -- Best regards, Igor Stasenko.
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 11:52, Igor Stasenko a écrit : I don't understand where the tragedy is.. you want your production code to work in Pharo 2.0? Write it to work well in 2.0, don't care about 3.0 or any other future possible changes. Want your code to work on bleeding-edge 3.0 image? Refactor/do the changes to make it work.. leave 2.0 behind. It's very tempting to do that, effectively. Want SmaCC on 3.0? Sorry, I'm only using 2.0, so you're on your own :( Want smart suggestions in Nautilus in 2.0? Sorry, not implemented. You want both? So, keep 2 separate versions for each version of system. And appreciate how the attitude makes it more complex than it has to be. You just have to accept that there is no code which will magically stay compatible with all old and all possible future versions without any changes. Yes, and its hard enough for people to appreciate any effort made in helping smooth out the transition. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Thanks Henry for the correction. Should I prepare an OSProcess version with all the changes necessary for Pharo3 ? Thierry Le 04/09/2013 04:51, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false Dave platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 2:13 PM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
On Wed, Sep 04, 2013 at 02:17:29PM +0200, Marcus Denker wrote: On Sep 4, 2013, at 2:13 PM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote: Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. I do not think that there is any right or wrong answer to this, it is perhaps a matter of personal perspective. For me, much of my professional experience is related to supporting manufacturing operations for a large commercial company. In this environment, the ability to engineer solutions to new problems without disrupting existing operations is critical. To me, a failure related to software changes is not just a red mark on a unit test, it is a significant emotional event if I cause a manufacturing plant to stop production (thankfully this has rarely happened in my career so far, knock wood). So maybe this makes me conservative, but from my point of view the ability to deliver future versions of software that work without breaking older versions is a matter of good engineering discipline, and I stand by that as a matter of principle. Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 10:28, Henrik Johansen a écrit : On Sep 2, 2013, at 4:41 , Goubier Thierry thierry.goub...@cea.fr wrote: Le 02/09/2013 16:07, Stéphane Ducasse a écrit : what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 When starting pharo4? That would be perfect :) I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no? (or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name]) When was Smalltalkos introduced ? Thierry 3.5 years ago ;) http://forum.world.st/Worth-reading-discussion-on-Smalltalk-vs-SmalltalkImage-td1576291.html#a1576588 It's been included since Pharo 1.1/Squeak 4.1, so it's a reasonable default path. Though, better use Smalltalk os platformName (which should work in all versions since the above mentioned), writing a test for whether #name is the correct method to use ala 3.0 would be an interesting exercise since it's also implemented for older returns of Smalltalk os, but with a different meaning. *cough* find a better selector for 3.0? *cough* I think OSPlatform is one of those packages which tries to work on Squeak 3.6 and up, and in that case you still need more fallbacks. Cheers, Henry Thanks Henry for the info. However, I'm sure platformName (and platformSubtype) will be deprecated in Pharo sooner or later... leaving us with another deprecation. At least the deprecation warning seems to be pointing to that. At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 12:56, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository. I think all-in-one solutions only result in bad code.. On 2013-09-03, at 08:48, Goubier Thierry thierry.goub...@cea.fr wrote: Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... :) Thierry Le 03/09/2013 14:22, Camillo Bruni a écrit : bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository. I think all-in-one solutions only result in bad code.. On 2013-09-03, at 08:48, Goubier Thierry thierry.goub...@cea.fr wrote: Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): Thank you! I will check this when I get home this evening. Dave in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName
Re: [Pharo-dev] OSProcess for Pharo3.0
On 2013-09-03, at 09:36, Goubier Thierry thierry.goub...@cea.fr wrote: And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... exactly, and for each Pharo version there is a different branch of OSProcess. well, once you start working on git you see the advantages of branches ;) too bad that the monticello tools do not properly support this feature. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false Dave platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-dev] OSProcess for Pharo3.0
Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 02/09/2013 12:02, Stéphane Ducasse a écrit : ok I read the big thread and what would be a solution? Updating OSProcess? It's just that the code which does the platform selection is already quite interesting due to platform differences, and I'm not sure how I should update it for Pharo3. Suggestions? OSProcess classosVersion osVersion After Squeak version 3.6, #osVersion was moved to SmalltalkImage. Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. self osVersion ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #osVersion]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) osVersion Thierry On Sep 2, 2013, at 11:20 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Stef, a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ? If I write something like (Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ]. Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk? Thanks, Thierry Le 02/09/2013 12:02, Stéphane Ducasse a écrit : ok I read the big thread and what would be a solution? On Sep 2, 2013, at 11:20 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 Stef On Sep 2, 2013, at 2:21 PM, Goubier Thierry thierry.goub...@cea.fr wrote: Stef, a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ? If I write something like (Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ]. Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk? Thanks, Thierry Le 02/09/2013 12:02, Stéphane Ducasse a écrit : ok I read the big thread and what would be a solution? On Sep 2, 2013, at 11:20 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 02/09/2013 16:07, Stéphane Ducasse a écrit : what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 When starting pharo4? That would be perfect :) I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no? (or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name]) When was Smalltalkos introduced ? Thierry Stef On Sep 2, 2013, at 2:21 PM, Goubier Thierry thierry.goub...@cea.fr wrote: Stef, a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ? If I write something like (Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ]. Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk? Thanks, Thierry Le 02/09/2013 12:02, Stéphane Ducasse a écrit : ok I read the big thread and what would be a solution? On Sep 2, 2013, at 11:20 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] OSProcess for Pharo3.0
On 2 September 2013 16:41, Goubier Thierry thierry.goub...@cea.fr wrote: Le 02/09/2013 16:07, Stéphane Ducasse a écrit : what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 When starting pharo4? That would be perfect :) I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no? (or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name]) When was Smalltalkos introduced ? i don't remember.. but it been a while ago. Smalltalk os name = 'Mac OS' Smalltalk os version = '1083' Thierry Stef On Sep 2, 2013, at 2:21 PM, Goubier Thierry thierry.goub...@cea.fr wrote: Stef, a question then: how to check that I am on a pharo3 image which is newer than 2013-07-22 (since this is the date where the OSPlatform methods have been deprecated) ? If I write something like (Smalltalk version beginsWith: 'Pharo3') ifTrue: [ ^ Smalltalk os name ]. Then this code may fail on old Pharo3 images. Or should I test the presence of os and vm as methods of Smalltalk? Thanks, Thierry Le 02/09/2013 12:02, Stéphane Ducasse a écrit : ok I read the big thread and what would be a solution? On Sep 2, 2013, at 11:20 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Hi, sometimes during the summer, a method used by OSProcess to determine the OS Platform has been deprecated in Pharo 3.0. Is it possible to have a look into updating OSProcess? I'm still unable to use Pharo3.0 because of issue 11102, but I'd like to get gitfiletree to work on it, and I think the main issue is OSProcess. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Best regards, Igor Stasenko.
Re: [Pharo-dev] OSProcess for Pharo3.0
On 2013-09-02, at 11:07, Stéphane Ducasse stephane.duca...@inria.fr wrote: what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 I would say the exact opposite, deprecate methods as early as possible If I deprecate a method now, - it is deprecated in the current dev version 3.0 dev - it is deprecated in the next release 3.0 stable - it is removed in the next dev version 4.0 dev so the current behavior is correct. For these issues apply the following strategy: - the latest stable version should load in 2.0 (1.4 is dead) - the latest dev version should most probably work in 3.0 So in this case, OSProcess could be easily updated to use 'Smalltalk os' since that exists already in 2.0, and nobody should even care developing or backporting software for 2.0. signature.asc Description: Message signed with OpenPGP using GPGMail
