[Pharo-project] What is the plan with Pharo changes?
Hi guys. PLEASE: I DON'T WANT TO START A WAR. I am just concerned about Pharo and it's future. I am totally in favor of making progress even if it breaks compatibility. I am all in favor of having to spend time and effort in updating projects to use latest Pharo changes. Today I faced a couple of problems with Metacello and Pier. Most problems were related to: 1) SystemChangeNotifier -> SystemAnnouncer 2) FileDirectory -> FileSystem so...after a couple of fixes, I was able to make them both to work in last Pharo version. So, DO NOT GO OFFTOPIC please. My question is, how can we make sure that we are not all trying to updated existing packages? I mean, I have updated Metacello (a part of it) and Pier. So what do we do? where do I commit without affecting all those not using Pharo 2.0 ? how can others take advantage of it? thanks guys. -- Mariano http://marianopeck.wordpress.com
Mariano, What I'd _like_ to do for Metacello and Pharo-2.0 is to make the changes against the MetacelloPreview release, which I'm managing on github. The MetacelloPreview is aimed at an eventual 1.0 release of Metacello (hopefully in the fall). I would _like_ Metacello-Base to be included in the Pharo-2.0 base image, the sooner the better and I'm poised to pull the trigger on that, but the recent changes have crippled FileTree ... So until FileTree is functional again, I can't really do anything with Pharo-2.0... Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ move forward. It is likely that I will have to redo whatever hacks that are done to get it running on Pharo-2.0 to be compatible with the rest of platforms that I am supporting and doing it right takes a little more effort ... So if you are just going to hack around to get things running on Pharo-2.0 I guess I would have to say that I don't care what you do, because the hacks don't make my job any easier. Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck@gmail.com> | To: "Pharo Development" <pharo-project@lists.gforge.inria.fr>, "Seaside - general discussion" | <seaside@lists.squeakfoundation.org>, metacello@googlegroups.com | Sent: Friday, August 3, 2012 2:26:08 PM | Subject: [Metacello] What is the plan with Pharo changes? | | Hi guys. PLEASE: I DON'T WANT TO START A WAR. | I am just concerned about Pharo and it's future. I am totally in | favor of making progress even if it breaks compatibility. I am all | in favor of having to spend time and effort in updating projects to | use latest Pharo changes. | Today I faced a couple of problems with Metacello and Pier. Most | problems were related to: | 1) SystemChangeNotifier -> SystemAnnouncer | 2) FileDirectory -> FileSystem | | | so...after a couple of fixes, I was able to make them both to work in | last Pharo version. So, DO NOT GO OFFTOPIC please. | My question is, how can we make sure that we are not all trying to | updated existing packages? I mean, I have updated Metacello (a part | of it) and Pier. So what do we do? where do I commit without | affecting all those not using Pharo 2.0 ? how can others take | advantage of it? | | | thanks guys. | | | -- | Mariano | http://marianopeck.wordpress.com | |
On 4 August 2012 02:16, Dale Henrichs <dhenrich@vmware.com> wrote:
Mariano,
What I'd _like_ to do for Metacello and Pharo-2.0 is to make the changes against the MetacelloPreview release, which I'm managing on github.
The MetacelloPreview is aimed at an eventual 1.0 release of Metacello (hopefully in the fall).
I would _like_ Metacello-Base to be included in the Pharo-2.0 base image, the sooner the better and I'm poised to pull the trigger on that, but the recent changes have crippled FileTree ...
yeah.. we talking about it all the time "how good it would be to have metacello preloaded in image" :)
So until FileTree is functional again, I can't really do anything with Pharo-2.0...
Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ move forward.
You can tell how they could help, so they will (if they will still want), leaving less work for you :) Of course, if you need help or can see where it can be useful. But i know it is hard to coordinate & organize activities.. sometimes harder than doing everything alone. :)
It is likely that I will have to redo whatever hacks that are done to get it running on Pharo-2.0 to be compatible with the rest of platforms that I am supporting and doing it right takes a little more effort ...
yes.. it is hard to keep up with moving target.. But i hope this is for good of us all (FileSystem ,as to me, is no doubt much better comparing to what we had before).
So if you are just going to hack around to get things running on Pharo-2.0 I guess I would have to say that I don't care what you do, because the hacks don't make my job any easier.
Dale
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Seaside - general discussion" <seaside@lists.squeakfoundation.org> | Cc: metacello@googlegroups.com, "Pharo Development" <pharo-project@lists.gforge.inria.fr> | Sent: Friday, August 3, 2012 9:52:18 PM | Subject: Re: [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | On 4 August 2012 02:16, Dale Henrichs <dhenrich@vmware.com> wrote: | > Mariano, | > | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the | > changes against the MetacelloPreview release, which I'm managing | > on github. | > | > The MetacelloPreview is aimed at an eventual 1.0 release of | > Metacello (hopefully in the fall). | > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base | > image, the sooner the better and I'm poised to pull the trigger on | > that, but the recent changes have crippled FileTree ... | > | yeah.. we talking about it all the time "how good it would be to have | metacello preloaded in image" :) | | > So until FileTree is functional again, I can't really do anything | > with Pharo-2.0... | > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ | > move forward. | > | | You can tell how they could help, so they will (if they will still | want), leaving less work for you :) Of course, if you need help or | can | see where it can be useful. | But i know it is hard to coordinate & organize activities.. sometimes | harder than doing everything alone. :) The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. | | > It is likely that I will have to redo whatever hacks that are done | > to get it running on Pharo-2.0 to be compatible with the rest of | > platforms that I am supporting and doing it right takes a little | > more effort ... | > | yes.. it is hard to keep up with moving target.. But i hope this is | for good of us all (FileSystem ,as to me, is no doubt much better | comparing to what we had before). Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ... | | > So if you are just going to hack around to get things running on | > Pharo-2.0 I guess I would have to say that I don't care what you | > do, because the hacks don't make my job any easier. | > | > Dale | > | | -- | Best regards, | Igor Stasenko. | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Dale Can we use an old version of Metacello that we maintain? Then we migrate when needed and this is ok. Stef
| > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the | > changes against the MetacelloPreview release, which I'm managing | > on github. | > | > The MetacelloPreview is aimed at an eventual 1.0 release of | > Metacello (hopefully in the fall). | > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base | > image, the sooner the better and I'm poised to pull the trigger on | > that, but the recent changes have crippled FileTree ... | > | yeah.. we talking about it all the time "how good it would be to have | metacello preloaded in image" :) | | > So until FileTree is functional again, I can't really do anything | > with Pharo-2.0... | > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ | > move forward. | > | | You can tell how they could help, so they will (if they will still | want), leaving less work for you :) Of course, if you need help or | can | see where it can be useful. | But i know it is hard to coordinate & organize activities.. sometimes | harder than doing everything alone. :)
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
| | > It is likely that I will have to redo whatever hacks that are done | > to get it running on Pharo-2.0 to be compatible with the rest of | > platforms that I am supporting and doing it right takes a little | > more effort ... | > | yes.. it is hard to keep up with moving target.. But i hope this is | for good of us all (FileSystem ,as to me, is no doubt much better | comparing to what we had before).
Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ...
| | > So if you are just going to hack around to get things running on | > Pharo-2.0 I guess I would have to say that I don't care what you | > do, because the hacks don't make my job any easier. | > | > Dale | > | | -- | Best regards, | Igor Stasenko. | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
BTW we discussed about it yesterday and I proposed that we keep the FileDirectory package for compatibility even if we are in 2.0. Dale I imagine that it would solve your problem. Stef On Aug 4, 2012, at 8:54 AM, Stéphane Ducasse wrote:
Dale
Can we use an old version of Metacello that we maintain? Then we migrate when needed and this is ok.
Stef
| > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the | > changes against the MetacelloPreview release, which I'm managing | > on github. | > | > The MetacelloPreview is aimed at an eventual 1.0 release of | > Metacello (hopefully in the fall). | > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base | > image, the sooner the better and I'm poised to pull the trigger on | > that, but the recent changes have crippled FileTree ... | > | yeah.. we talking about it all the time "how good it would be to have | metacello preloaded in image" :) | | > So until FileTree is functional again, I can't really do anything | > with Pharo-2.0... | > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ | > move forward. | > | | You can tell how they could help, so they will (if they will still | want), leaving less work for you :) Of course, if you need help or | can | see where it can be useful. | But i know it is hard to coordinate & organize activities.. sometimes | harder than doing everything alone. :)
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
| | > It is likely that I will have to redo whatever hacks that are done | > to get it running on Pharo-2.0 to be compatible with the rest of | > platforms that I am supporting and doing it right takes a little | > more effort ... | > | yes.. it is hard to keep up with moving target.. But i hope this is | for good of us all (FileSystem ,as to me, is no doubt much better | comparing to what we had before).
Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ...
| | > So if you are just going to hack around to get things running on | > Pharo-2.0 I guess I would have to say that I don't care what you | > do, because the hacks don't make my job any easier. | > | > Dale | > | | -- | Best regards, | Igor Stasenko. | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
FileDirectory is the current show-stopper ... with FileDirectory back I will move forward on getting the Preview working on Pharo-2.0 DAle ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Saturday, August 4, 2012 12:01:25 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | BTW we discussed about it yesterday and I proposed that we keep the | FileDirectory package for compatibility even if we are in 2.0. | Dale I imagine that it would solve your problem. | Stef | | | On Aug 4, 2012, at 8:54 AM, Stéphane Ducasse wrote: | | > Dale | > | > Can we use an old version of Metacello that we maintain? | > Then we migrate when needed and this is ok. | > | > Stef | > | > | >> | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make | >> | > the | >> | > changes against the MetacelloPreview release, which I'm | >> | > managing | >> | > on github. | >> | > | >> | > The MetacelloPreview is aimed at an eventual 1.0 release of | >> | > Metacello (hopefully in the fall). | >> | > | >> | > I would _like_ Metacello-Base to be included in the Pharo-2.0 | >> | > base | >> | > image, the sooner the better and I'm poised to pull the | >> | > trigger on | >> | > that, but the recent changes have crippled FileTree ... | >> | > | >> | yeah.. we talking about it all the time "how good it would be to | >> | have | >> | metacello preloaded in image" :) | >> | | >> | > So until FileTree is functional again, I can't really do | >> | > anything | >> | > with Pharo-2.0... | >> | > | >> | > Hacking Metacello to get it running on Pharo-2.0 doesn't help | >> | > _me_ | >> | > move forward. | >> | > | >> | | >> | You can tell how they could help, so they will (if they will | >> | still | >> | want), leaving less work for you :) Of course, if you need help | >> | or | >> | can | >> | see where it can be useful. | >> | But i know it is hard to coordinate & organize activities.. | >> | sometimes | >> | harder than doing everything alone. :) | >> | >> The bigger problem is that I have to have a code base that runs on | >> multiple platforms while being maintainable, so a "port" to | >> Pharo-2.0 is only a starting point. In the case of FileTree, | >> which is the real bottleneck there's a lot code that is written | >> against the FileDirectory API, so there will need to be | >> significant work to find a way to keep a common code base .... a | >> much tougher problem, than "just getting it working", it can be | >> solved with time, but I didn't budget time for an emergency | >> rewrite of FileTree ... today. | >> | >> | | >> | > It is likely that I will have to redo whatever hacks that are | >> | > done | >> | > to get it running on Pharo-2.0 to be compatible with the rest | >> | > of | >> | > platforms that I am supporting and doing it right takes a | >> | > little | >> | > more effort ... | >> | > | >> | yes.. it is hard to keep up with moving target.. But i hope this | >> | is | >> | for good of us all (FileSystem ,as to me, is no doubt much | >> | better | >> | comparing to what we had before). | >> | >> Oh don't get me wrong, I agree with the overall goals ... I | >> actually think that renaming FileDirectory to | >> ObsoleteFileDirectory (and keeping the implementation) would be a | >> good compromise ... I can easily switch class names for the short | >> term which then buys me time for doing a proper rewrite ... | >> | >> | | >> | > So if you are just going to hack around to get things running | >> | > on | >> | > Pharo-2.0 I guess I would have to say that I don't care what | >> | > you | >> | > do, because the hacks don't make my job any easier. | >> | > | >> | > Dale | >> | > | >> | | >> | -- | >> | Best regards, | >> | Igor Stasenko. | >> | _______________________________________________ | >> | seaside mailing list | >> | seaside@lists.squeakfoundation.org | >> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | >> | | >> | > | > | | |
Stef, That would be fine with me ... That would buy time for me to come up with a port to 2.0 that satisfies my need for portability and allows you guys to keep forging ahead without being dragged back by me:) Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, August 3, 2012 11:54:24 PM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | Dale | | Can we use an old version of Metacello that we maintain? | Then we migrate when needed and this is ok. | | Stef | | | > | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make | > | > the | > | > changes against the MetacelloPreview release, which I'm | > | > managing | > | > on github. | > | > | > | > The MetacelloPreview is aimed at an eventual 1.0 release of | > | > Metacello (hopefully in the fall). | > | > | > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 | > | > base | > | > image, the sooner the better and I'm poised to pull the trigger | > | > on | > | > that, but the recent changes have crippled FileTree ... | > | > | > | yeah.. we talking about it all the time "how good it would be to | > | have | > | metacello preloaded in image" :) | > | | > | > So until FileTree is functional again, I can't really do | > | > anything | > | > with Pharo-2.0... | > | > | > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help | > | > _me_ | > | > move forward. | > | > | > | | > | You can tell how they could help, so they will (if they will | > | still | > | want), leaving less work for you :) Of course, if you need help | > | or | > | can | > | see where it can be useful. | > | But i know it is hard to coordinate & organize activities.. | > | sometimes | > | harder than doing everything alone. :) | > | > The bigger problem is that I have to have a code base that runs on | > multiple platforms while being maintainable, so a "port" to | > Pharo-2.0 is only a starting point. In the case of FileTree, which | > is the real bottleneck there's a lot code that is written against | > the FileDirectory API, so there will need to be significant work | > to find a way to keep a common code base .... a much tougher | > problem, than "just getting it working", it can be solved with | > time, but I didn't budget time for an emergency rewrite of | > FileTree ... today. | > | > | | > | > It is likely that I will have to redo whatever hacks that are | > | > done | > | > to get it running on Pharo-2.0 to be compatible with the rest | > | > of | > | > platforms that I am supporting and doing it right takes a | > | > little | > | > more effort ... | > | > | > | yes.. it is hard to keep up with moving target.. But i hope this | > | is | > | for good of us all (FileSystem ,as to me, is no doubt much better | > | comparing to what we had before). | > | > Oh don't get me wrong, I agree with the overall goals ... I | > actually think that renaming FileDirectory to | > ObsoleteFileDirectory (and keeping the implementation) would be a | > good compromise ... I can easily switch class names for the short | > term which then buys me time for doing a proper rewrite ... | > | > | | > | > So if you are just going to hack around to get things running | > | > on | > | > Pharo-2.0 I guess I would have to say that I don't care what | > | > you | > | > do, because the hacks don't make my job any easier. | > | > | > | > Dale | > | > | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | _______________________________________________ | > | seaside mailing list | > | seaside@lists.squeakfoundation.org | > | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | > | | > | | |
Hi Dale, Dne 04. 08. 2012 07:31, piše Dale Henrichs:
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first .. Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hi all. I am answering to all together: Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see). Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions: 1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior. 3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) it is not very necessary. Thanks for considering this a friendly and positive thread. On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <janko.mivsek@eranova.si>wrote:
Hi Dale,
Dne 04. 08. 2012 07:31, piše Dale Henrichs:
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first ..
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-- Mariano http://marianopeck.wordpress.com
Hi, On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi all. I am answering to all together:
Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see).
Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions:
1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :)
Ok, we could do as Dale proposed, reload the package adding prefix Obsolete... that will work just for a while, and I certainly prefer to help on the adaptation than reintroduce it... of course, maybe we should do that in the first instance and in this case it was possible (se below), but well... we already screw it, so, I prefer to do step forwards than backward (if possible).
2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior.
SystemChangeNotifier is a complete different situation than FileDirectory, and we removed it because the effort of keeping the system working having two different notification centers was eating all our time for make improvements. So, we (I myself) decided to unload it and stop waisting time on try to make the synchronization work... if you see the "before" and "after" (once we finish, that is not done yet) you will notice the clarity and simplicity gained. So... SystemChangeNotification is not going to go back, but an approach like Mariano proposed would work fine, since Metacello just uses the #doSilently stuff. Btw... this is internal from Pharo, and 99.99% of the packages around shouldn't even notice the difference. Of course, Metacello is in the 0.01% remaining :)
3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added?
I'm strongly against this option, because I think Metacello (base) should be part of Pharo Core (in fact I was planning to introduce it next days). If I need to load grease or sport, I certainly will banish Metacello from core... and I don't want to. Again, I prefer to spend time fixing Metacello to load on Pharo (and I maintain my offer of spending it, he).
4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) i t is not very necessary.
I want Metacello in core, so... this is probably a good idea. best, Esteban
Thanks for considering this a friendly and positive thread.
On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote: Hi Dale,
Dne 04. 08. 2012 07:31, piše Dale Henrichs:
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first ..
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-- Mariano http://marianopeck.wordpress.com
SystemChangeNotifier is a complete different situation than FileDirectory, and we removed it because the effort of keeping the system working having two different notification centers was eating all our time for make improvements. So, we (I myself) decided to unload it and stop waisting time on try to make the synchronization work... if you see the "before" and "after" (once we finish, that is not done yet) you will notice the clarity and simplicity gained. So... SystemChangeNotification is not going to go back, but an approach like Mariano proposed would work fine, since Metacello just uses the #doSilently stuff. Btw... this is internal from Pharo, and 99.99% of the packages around shouldn't even notice the difference. Of course, Metacello is in the 0.01% remaining :)
3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added?
I'm strongly against this option, because I think Metacello (base) should be part of Pharo Core (in fact I was planning to introduce it next days). If I need to load grease or sport, I certainly will banish Metacello from core... and I don't want to. Again, I prefer to spend time fixing Metacello to load on Pharo (and I maintain my offer of spending it, he).
Yes I'm against adding layers of layers of layers.
4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) i t is not very necessary.
I want Metacello in core, so... this is probably a good idea.
A shrink down version then.
best, Esteban
Thanks for considering this a friendly and positive thread.
On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote: Hi Dale,
Dne 04. 08. 2012 07:31, piše Dale Henrichs:
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first ..
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-- Mariano http://marianopeck.wordpress.com
Esteban ... I agree with all of your points ----- Original Message ----- | From: "Esteban Lorenzano" <estebanlm@gmail.com> | To: metacello@googlegroups.com | Cc: "Seaside - general discussion" <seaside@lists.squeakfoundation.org>, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, August 4, 2012 3:04:02 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | Hi, | | | | On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck < | marianopeck@gmail.com > wrote: | | | Hi all. I am answering to all together: | | | Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 | with seaside and magritte. With 5 minutes of opening debuggers and | change things I was able to correctly make it work (at least, my | app, I didn't run all tests to see). | | | Dale: We don't want to just help you with "hacks", that why I send | this email and several others, to see what others think so that can | find better and non-hacky solutions. So, let's try to find good | solutions: | | | 1) does it help if we put back FildeDirectory and we remove it later | ? so that you have time to update Metacello and that we can still | use Metacello :) | | | Ok, we could do as Dale proposed, reload the package adding prefix | Obsolete... that will work just for a while, and I certainly prefer | to help on the adaptation than reintroduce it... of course, maybe we | should do that in the first instance and in this case it was | possible (se below), but well... we already screw it, so, I prefer | to do step forwards than backward (if possible). | | | | | | 2) for the SystemChangeNotifier does it make sense to delegate to the | closures? [ xx ] valueWithoutSystemNotifications. Or we add a | #doSilently: and we add a MetacelloPharo20Platform that overrides | the behavior. | | | SystemChangeNotifier is a complete different situation than | FileDirectory, and we removed it because the effort of keeping the | system working having two different notification centers was eating | all our time for make improvements. So, we (I myself) decided to | unload it and stop waisting time on try to make the synchronization | work... if you see the "before" and "after" (once we finish, that is | not done yet) you will notice the clarity and simplicity gained. | So... SystemChangeNotification is not going to go back, but an | approach like Mariano proposed would work fine, since Metacello just | uses the #doSilently stuff. | Btw... this is internal from Pharo, and 99.99% of the packages around | shouldn't even notice the difference. Of course, Metacello is in the | 0.01% remaining :) | | | | | 3) as Janko said, what about improving/using Grease/Sport for this | purpose? do they provide something for this? could this be added? | | | I'm strongly against this option, because I think Metacello (base) | should be part of Pharo Core (in fact I was planning to introduce it | next days). If I need to load grease or sport, I certainly will | banish Metacello from core... and I don't want to. Again, I prefer | to spend time fixing Metacello to load on Pharo (and I maintain my | offer of spending it, he). | | | | 4) Should we integrate Metacello in the image with our changes until | you have time and find a good solution that works everywhere? Maybe | if we do 1) i | | | t is not very necessary. | | | I want Metacello in core, so... this is probably a good idea. | | | best, | Esteban | | | | | | Thanks for considering this a friendly and positive thread. | | | On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek < | janko.mivsek@eranova.si > wrote: | | | Hi Dale, | | Dne 04. 08. 2012 07 :31, piše Dale Henrichs: | | | > The bigger problem is that I have to have a code base that runs on | > multiple platforms while being maintainable, so a "port" to | > Pharo-2.0 is only a starting point. In the case of FileTree, which | > is the real bottleneck there's a lot code that is written against | > the FileDirectory API, so there will need to be significant work | > to find a way to keep a common code base .... a much tougher | > problem, than "just getting it working", it can be solved with | > time, but I didn't budget time for an emergency rewrite of | > FileTree ... today. | | Just FYI, there is a Sport portability library and by using Sport's | SpFilename you have an instantly portable file support over quite a | dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 | filesystem first .. | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | | | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote:
Hi all. I am answering to all together:
Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see).
Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions:
1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior.
I do not understand why metacello is concerned about systemChangeNotification.
3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) it is not very necessary.
Thanks for considering this a friendly and positive thread.
On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote: Hi Dale,
Dne 04. 08. 2012 07:31, piše Dale Henrichs:
The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today.
Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first ..
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-- Mariano http://marianopeck.wordpress.com
On Sat, Aug 4, 2012 at 2:01 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote:
Hi all. I am answering to all together:
Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see).
Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions:
1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior.
I do not understand why metacello is concerned about systemChangeNotification.
Just to make certain things silent in the tests. -- Mariano http://marianopeck.wordpress.com
SystemChangeNotification is used in the tests...The tests (obviously) do a whole lot of loading and unloading of packages and suppressing change notifications during some tests has a significant impact on how long it takes to run the tests ... The solution for me is to add some code to the platform packages to hide SystemChangeNotification and use my own variant of silentlyDo: ... The real sticky problem is with FileDirectory... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Cc: "Seaside - general discussion" <seaside@lists.squeakfoundation.org>, metacello@googlegroups.com | Sent: Saturday, August 4, 2012 5:01:48 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | | On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote: | | > Hi all. I am answering to all together: | > | > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo | > 2.0 with seaside and magritte. With 5 minutes of opening debuggers | > and change things I was able to correctly make it work (at least, | > my app, I didn't run all tests to see). | > | > Dale: We don't want to just help you with "hacks", that why I send | > this email and several others, to see what others think so that | > can find better and non-hacky solutions. So, let's try to find | > good solutions: | > | > 1) does it help if we put back FildeDirectory and we remove it | > later ? so that you have time to update Metacello and that we can | > still use Metacello :) | > 2) for the SystemChangeNotifier does it make sense to delegate to | > the closures? [ xx ] valueWithoutSystemNotifications. Or we add | > a #doSilently: and we add a MetacelloPharo20Platform that | > overrides the behavior. | | I do not understand why metacello is concerned about | systemChangeNotification. | | | > 3) as Janko said, what about improving/using Grease/Sport for this | > purpose? do they provide something for this? could this be added? | > 4) Should we integrate Metacello in the image with our changes | > until you have time and find a good solution that works | > everywhere? Maybe if we do 1) it is not very necessary. | > | > Thanks for considering this a friendly and positive thread. | > | > On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek | > <janko.mivsek@eranova.si> wrote: | > Hi Dale, | > | > Dne 04. 08. 2012 07:31, piše Dale Henrichs: | > | > > The bigger problem is that I have to have a code base that runs | > > on multiple platforms while being maintainable, so a "port" to | > > Pharo-2.0 is only a starting point. In the case of FileTree, | > > which is the real bottleneck there's a lot code that is written | > > against the FileDirectory API, so there will need to be | > > significant work to find a way to keep a common code base .... a | > > much tougher problem, than "just getting it working", it can be | > > solved with time, but I didn't budget time for an emergency | > > rewrite of FileTree ... today. | > | > Just FYI, there is a Sport portability library and by using Sport's | > SpFilename you have an instantly portable file support over quite a | > dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 | > filesystem first .. | > | > Best regards | > Janko | > | > | > -- | > Janko Mivšek | > Aida/Web | > Smalltalk Web Application Server | > http://www.aidaweb.si | > _______________________________________________ | > seaside mailing list | > seaside@lists.squeakfoundation.org | > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | > | > | > | > -- | > Mariano | > http://marianopeck.wordpress.com | > | | |
ok we will discuss with the crew here to see what is the best strategy. Stef On Aug 4, 2012, at 6:08 PM, Dale Henrichs wrote:
SystemChangeNotification is used in the tests...The tests (obviously) do a whole lot of loading and unloading of packages and suppressing change notifications during some tests has a significant impact on how long it takes to run the tests ...
The solution for me is to add some code to the platform packages to hide SystemChangeNotification and use my own variant of silentlyDo: ...
The real sticky problem is with FileDirectory...
Dale
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Cc: "Seaside - general discussion" <seaside@lists.squeakfoundation.org>, metacello@googlegroups.com | Sent: Saturday, August 4, 2012 5:01:48 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | | On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote: | | > Hi all. I am answering to all together: | > | > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo | > 2.0 with seaside and magritte. With 5 minutes of opening debuggers | > and change things I was able to correctly make it work (at least, | > my app, I didn't run all tests to see). | > | > Dale: We don't want to just help you with "hacks", that why I send | > this email and several others, to see what others think so that | > can find better and non-hacky solutions. So, let's try to find | > good solutions: | > | > 1) does it help if we put back FildeDirectory and we remove it | > later ? so that you have time to update Metacello and that we can | > still use Metacello :) | > 2) for the SystemChangeNotifier does it make sense to delegate to | > the closures? [ xx ] valueWithoutSystemNotifications. Or we add | > a #doSilently: and we add a MetacelloPharo20Platform that | > overrides the behavior. | | I do not understand why metacello is concerned about | systemChangeNotification. | | | > 3) as Janko said, what about improving/using Grease/Sport for this | > purpose? do they provide something for this? could this be added? | > 4) Should we integrate Metacello in the image with our changes | > until you have time and find a good solution that works | > everywhere? Maybe if we do 1) it is not very necessary. | > | > Thanks for considering this a friendly and positive thread. | > | > On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek | > <janko.mivsek@eranova.si> wrote: | > Hi Dale, | > | > Dne 04. 08. 2012 07:31, piše Dale Henrichs: | > | > > The bigger problem is that I have to have a code base that runs | > > on multiple platforms while being maintainable, so a "port" to | > > Pharo-2.0 is only a starting point. In the case of FileTree, | > > which is the real bottleneck there's a lot code that is written | > > against the FileDirectory API, so there will need to be | > > significant work to find a way to keep a common code base .... a | > > much tougher problem, than "just getting it working", it can be | > > solved with time, but I didn't budget time for an emergency | > > rewrite of FileTree ... today. | > | > Just FYI, there is a Sport portability library and by using Sport's | > SpFilename you have an instantly portable file support over quite a | > dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 | > filesystem first .. | > | > Best regards | > Janko | > | > | > -- | > Janko Mivšek | > Aida/Web | > Smalltalk Web Application Server | > http://www.aidaweb.si | > _______________________________________________ | > seaside mailing list | > seaside@lists.squeakfoundation.org | > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | > | > | > | > -- | > Mariano | > http://marianopeck.wordpress.com | > | | |
----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck@gmail.com> | To: "Seaside - general discussion" <seaside@lists.squeakfoundation.org> | Cc: Pharo-project@lists.gforge.inria.fr, metacello@googlegroups.com | Sent: Saturday, August 4, 2012 2:21:27 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | Hi all. I am answering to all together: | | | Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 | with seaside and magritte. With 5 minutes of opening debuggers and | change things I was able to correctly make it work (at least, my | app, I didn't run all tests to see). | | | Dale: We don't want to just help you with "hacks", that why I send | this email and several others, to see what others think so that can | find better and non-hacky solutions. So, let's try to find good | solutions: | | | 1) does it help if we put back FildeDirectory and we remove it later | ? so that you have time to update Metacello and that we can still | use Metacello :) Deferring the removal of FileDirectory would buy me time for getting a more portable solution in place. | 2) for the SystemChangeNotifier does it make sense to delegate to the | closures? [ xx ] valueWithoutSystemNotifications. Or we add a | #doSilently: and we add a MetacelloPharo20Platform that overrides | the behavior. The solution for SystemChangeNotifier is for me to add a message to the MetacelloPlatform class (my Grease layer) and use the currently correct method for Pharo-2.0. | 3) as Janko said, what about improving/using Grease/Sport for this | purpose? do they provide something for this? could this be added? The right answer for FileTree is to re-architect the implementation. The code is currently liberally sprinkled with FileDirectoryisms as FileTree does a lot of directory traversal ... Cami made a pass at replacing the FileDirectory calls with Filesystem calls[1] so I have a good blueprint for building an implementation neutral directory structure traversal class that can isolate the FileDirectory/Filesystem calls into a manageable location (right now there are just too many places that are different) ... So given time (and as I mentioned elsewhere I have to start preparing my ESUG talk because that's a hard deadline) I can get a handle on this. Eventually I plan to port Filesystem to GemStone, so moving away from FileDirectory is in my future plans as well, it's just the timing that is an issue, not the direction. I think that Sport should eventually end up with a port to Pharo-2.0, but for FileTree I don't think I want to require Sport. The FileTree implementation will benefit by the removal of the FileDiretoryisms, so that's the route I will take. [1] https://github.com/dh83/filetree/commit/4232898d4dbdd9712f4276f69c9404e14a6f... | 4) Should we integrate Metacello in the image with our changes until | you have time and find a good solution that works everywhere? Maybe | if we do 1) it is not very necessary. If you decide to stick with your decision to drop FileDirectory, then a fork or Metacello will be a good choice for the near term ... you can freely make the most efficient changes to Metacello to keep it running and focus your energies on making Pharo-2.0 better ... I can take my time to port FileTree. If you rename FileDirectory or decide to keep it for a while longer, then I will be able to start immediate work on getting the Metacello Preview running on top of Pharo-2.0 (which shouldn't take too much work)... | | | Thanks for considering this a friendly and positive thread. | It was good that you made a point of focussing on the technical solutions to the problem. Leaving the politics for another thread, if any. | | On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek < | janko.mivsek@eranova.si > wrote: | | | Hi Dale, | | Dne 04. 08. 2012 07 :31, piše Dale Henrichs: | | | > The bigger problem is that I have to have a code base that runs on | > multiple platforms while being maintainable, so a "port" to | > Pharo-2.0 is only a starting point. In the case of FileTree, which | > is the real bottleneck there's a lot code that is written against | > the FileDirectory API, so there will need to be significant work | > to find a way to keep a common code base .... a much tougher | > problem, than "just getting it working", it can be solved with | > time, but I didn't budget time for an emergency rewrite of | > FileTree ... today. | | Just FYI, there is a Sport portability library and by using Sport's | SpFilename you have an instantly portable file support over quite a | dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 | filesystem first .. | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | | | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside | | | | | -- | Mariano | http://marianopeck.wordpress.com | |
On Aug 3, 2012, at 11:26 PM, Mariano Martinez Peck wrote:
Hi guys. PLEASE: I DON'T WANT TO START A WAR. I am just concerned about Pharo and it's future.
bright and shinny.
I am totally in favor of making progress even if it breaks compatibility. I am all in favor of having to spend time and effort in updating projects to use latest Pharo changes. Today I faced a couple of problems with Metacello and Pier. Most problems were related to:
You are telling to us that you loaded Pier in 20 excellent.
1) SystemChangeNotifier -> SystemAnnouncer 2) FileDirectory -> FileSystem
Is it not a dream that comes true?
so...after a couple of fixes, I was able to make them both to work in last Pharo version. So, DO NOT GO OFFTOPIC please. My question is, how can we make sure that we are not all trying to updated existing packages?
yes this is a good question.
I mean, I have updated Metacello (a part of it) and Pier. So what do we do?
publish a new configuration of the packages so that the new versions get loaded. This is the purpose of configurations
where do I commit without affecting all those not using Pharo 2.0 ? how can others take advantage of it? Use configurations.
thanks guys.
-- Mariano http://marianopeck.wordpress.com
participants (6)
-
Dale Henrichs -
Esteban Lorenzano -
Igor Stasenko -
Janko Mivšek -
Mariano Martinez Peck -
Stéphane Ducasse