April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Talking to Steve Jobs about Scratch.

by Esteban Lorenzano

> > As everyone should be aware Scratch as an interpreted language is not = > allowed, but in the=20 > future Smalltalk as a language not on the short list is not allowed even = > if it's hidden from view > or ultimately cross compiled into an Objective-C application. so... I want to be clear... that means "Deimos" (and the adhoc vm) is not being allowed to exist? (right now, I'm working on deimos as if not change was introduced at all, but I need to take all of this into account now :P) Cheers, Esteban

April 22, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > Sean I cannot find your slice in the inbox. > Is it there? > I just re-uploaded. I see it there now. -- View this message in context: http://smalltalk.1294792.n4.nabble.com/Fix-2329-Default-MC-Directory-Settin… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by StÃ©phane Ducasse

Just a meta remark > What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) This is not a question of pride. do not imply that we do not have serious users that would like to avoid move :) do not imply that we do actions based on pride, this was not the case. Since the old protocol was wrong people preferred to see it fixed - at that time it was not clear that compatibility with squeak could make sense. The deprecation only works if you add a different name. And this was not what we wanted at that time. I contacted damien to see what he is thinking and if there is something we could do. Because we may introduce request:onCancel: and rewrite the old senders. Stef

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by StÃ©phane Ducasse

We could rollback and introduce a new message and deprecates the other. This is just that I do not have the energy for that. Now this is also important that we do not get bound to existing API for the sake of them. Stef >> >>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >>> >>> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) >> >> That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. >> >> Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. >> >>> With ToolBuilder, I also include the protocol of UIManagers. >>> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. >> >> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. >> >> It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. >> >> Cheers, >> - Andreas > No arguments from me, I strongly defended the approach you suggested at the time. > Sadly, (in my eyes) discussion just died, and everything got changed anyways. > > Cheers, > Henry > > (Link to thread in question, for those interested) > http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-re… > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 11:10 47AM, Andreas Raab wrote: > On 4/22/2010 1:21 AM, Henrik Johansen wrote: >> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >> >> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. > > Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. > >> With ToolBuilder, I also include the protocol of UIManagers. >> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. > > It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. > > Cheers, > - Andreas No arguments from me, I strongly defended the approach you suggested at the time. Sadly, (in my eyes) discussion just died, and everything got changed anyways. Cheers, Henry (Link to thread in question, for those interested) http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-re…

April 22, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by StÃ©phane Ducasse

Sean I cannot find your slice in the inbox. Is it there? Stef On Apr 21, 2010, at 10:07 PM, Sean P. DeNigris wrote: > > In Inbox. http://code.google.com/p/pharo/issues/detail?id=2329. > > Details: > > > Michael Roberts-2 wrote: >> >> I appreciate I hijacked this thread somewhat.... >> > > That's it - I'm pissed and I'm taking my damn thread back ;-) > > > Sean P. DeNigris wrote: >> >> http://code.google.com/p/pharo/issues/detail?id=2329 >> >> Pharo image: Pharo 1.0 >> >> In Monticello Browser, when I click "+Repository" and select "directory," >> I'd love to be taken right to the directory where I keep my local >> repositories, instead of having to click to the same place over and over. >> > > Okay, now that we're back on track... > > > StÃ©phane Ducasse wrote: >> >> it would be good to be able to >> either choose to have one local cache on the side of the image >> or one shared among image - this implies a way to store and set it up >> => probably a class variable + a setting in 1.1 >> > > Steph, I followed your suggestion and implemented it as a class var + > settings. > > I had to add the capability to have directory-type settings (which was very > similar to the existing file type settings, predictably). > > Summary: > * Added ability to System-Settings to have directory-based settings > * Added defaultDirectoryName setting to Settings-Monticello > * Added feature to Monticello to remember parent directory where user likes > to keep local repository directories and start directory-choosing dialogs > there. > * Tested (by hand) in PharoCore1.1ALPHA Latest update: #11312 > > Sean > -- > View this message in context: http://n4.nabble.com/Fix-2329-Default-MC-Directory-Setting-tp2019559p201955… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by StÃ©phane Ducasse

On Apr 22, 2010, at 11:10 AM, Andreas Raab wrote: > On 4/22/2010 1:21 AM, Henrik Johansen wrote: >> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >> >> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. > > Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. Agreed. > >> With ToolBuilder, I also include the protocol of UIManagers. >> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. I know you remember I was in favor of your solution. > It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Andreas Raab

On 4/22/2010 1:21 AM, Henrik Johansen wrote: > ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. > > Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. > With ToolBuilder, I also include the protocol of UIManagers. > In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. Cheers, - Andreas

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 10:21 20AM, Henrik Johansen wrote: > > On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote: > >> On 4/21/2010 4:32 AM, Hannes Hirzel wrote: >>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? >>> Or if there is a difference what is the impact of it? >>> >>> Or put the question in another way. If I code an UI using the >>> ToolBuilder in Squeak 4.1 will it run in Pharo? >> >> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). >> >> Cheers, >> - Andreas > > ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. > > Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > With ToolBuilder, I also include the protocol of UIManagers. > In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > Cheers, > Henry > Should of course be noted, if you take a look in a Pharo image, this change has not been reflected in the ToolBuilder UIManager comment, nor the MorphicUIManager, just in the PSUIManager which is the default manager in Pharo. (Don't see that changing anytime soon though :) ) Cheers, Henry

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote: > On 4/21/2010 4:32 AM, Hannes Hirzel wrote: >> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? >> Or if there is a difference what is the impact of it? >> >> Or put the question in another way. If I code an UI using the >> ToolBuilder in Squeak 4.1 will it run in Pharo? > > They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). > > Cheers, > - Andreas ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) With ToolBuilder, I also include the protocol of UIManagers. In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. Cheers, Henry

April 22, 2010