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

Re: [Pharo-project] plan for 1.1

by Mariano Martinez Peck

On Wed, May 26, 2010 at 10:53 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Mariano wrote: > >So...if you take a Core 11367 and load the metacellol version, it will > >work perfect. > > But wouldn't that mean we should have a "1.1-beta1.11367" in the config? > Yes, sorry about that, I have just noticed the confusion: I put the correct name to the method version, but wrong pragma (because of copy paste). That pragma should have been 1.1-beta1.11367 instead of 1.1-beta1.10517 > > >That's not broken. > > Yes, the '1.1-beta1.10517' still works with the core 11367 image. > > Ok, this what is important, and what I want to achieve. > But if you update it to a Core 11372 first and then use > the ConfigurationOfPharo (1.1-beta1.10517) it is broken. > > Of course it is. How do you pretend that the same version of external packages work perfectly with changes in the core? > >How can you assure that for any core version the same metacello version > can > >work on it? That's impossible. > > Yes. So the question is which core image is the base for Pharo 1.1. > (10517, 11367, ...)? > Depending. For Pharo beta 1 it was 11367. For Pharo beta2 we don't know yet, neither for rc or final. > > I would do: > - a feature freeze for the core or pick a stable core > so we have a stable 1.1 base to build the dev-image upon > - adopt the config and loaded packages until they work on this core > - test, test, test > > >I can update it, but if noone fixes Nile... > > I think the Nile problem is related to the traits problem introduced > between core 11367 and core 11372. Since Stef already found the > problem I asked if we get a fix in an upcoming 11373 so > building the dev-image may work again. > > Maybe it works. Maybe it doesn't. Just suppose in that new core version, some method or class where renamed or removed. What happen with external packages? > So currently we dont have a broken configuration but a broken core. > > It is not broken. It is just a bug. > Bye > T. > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] plan for 1.1

by StÃ©phane Ducasse

On May 26, 2010, at 3:10 PM, Torsten Bergmann wrote: > Stef wrote: >> does this plan look ok for you? > > Yes > > Alexandre wrote: >> Ok for me. But we need a Beta that is regularly built for this. > > +1 especially since it is currently broken > (see http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/027376.html) > > Stef wrote >> I found the traits bug :) > > OK, can we expect a fix in the next update (11373?). yes of course I was exhausted and had to sleep. http://code.google.com/p/pharo/issues/detail?id=2477 > Using ConfigurationOfPharo anyone is able to rebuild an own > beta to test and from time to time mariano can upload a full > beta image. > > Bye > T. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Levente Uzonyi

On Wed, 26 May 2010, Lukas Renggli wrote: >> not right to me. I wanted to express the feeling that, for me, the one >> of the best things about Smalltalk is its readability in difference to >> C, which is very fast. The ?new compiler optimize? both, anyway. > > - The "New Compiler" does not yet work. > > - The optimized #and:and:and: code never decompiled correctly. > > - The exact semantics of #and:and:and: is not clear without knowing > how it is implemented. > > - There are subtle semantic differences between "a and: [ b ] and: [ c > ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the > conditions have side-effects. That's not true. Both #and: and #and:and:and: (and friends) are short-circuit, so they'll cause exactly the same side effects. Levente > > - The #and:and:and: constructs are very confusing to newbies, I have > seen that numerous times. > > - The use of #and:and:and: doesn't shorten code. > > - #and:and:and: is not necessary from a language point of view. > > - And most important for me: #and:and:and: is incompatible with the > rest of the world. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] plan for 1.1

by StÃ©phane Ducasse

yes this is good point. I would like to have alien or ffi in 1.1. Now I do not know the status of Alien on windows. On May 26, 2010, at 2:52 PM, Schwab,Wilhelm K wrote: > Stef, > > My initial reaction to 1.1's approaching release was "where are the callbacks/aliens?" Sig appears to be offering some competition to Alien. If he/we can provide a comprehensive and convenient way to make calls, do callbacks, additionally put calls onto other OS threads, and do all of this on the three major platforms, then it could easily turn out the best option for external interfacing. > > I am happy to see us take time to get it right. My only concern would be that we not fall into a pattern of leaving out the difficult things that we set out to accomplish with a given release. Since 1.1 is approaching releasable form and FFI/Alien/NB is unclear at present, a release makes sense. > > Short answer: sure, whatever you say :) > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Wednesday, May 26, 2010 4:20 AM > To: Pharo Development > Subject: [Pharo-project] plan for 1.1 > > Hi guys > > we were discussing how we can handle 1.1 and the flux of good changes. > Here is the proposal: > we take two or three weeks to let people try their code in 1.1 beta > we integrate fixes that are important or easy > then we wait one week > then we launch 1.1 rc and 1.2 unstable > > does this plan look ok for you? > The key point is that we want to avoid to have a pile of changes pending because they can rot easily. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] Image Lockdown/Deployment mode

by StÃ©phane Ducasse

Good question we need that!!!! We were thinking about that with noury for 1.0 and got distracted. This is really important. Any step in that direction is really welcome > Does Pharo currently provide support for a deployment mode/image > locking mode? > > I think of the following scenario: > ================================== > If one builds a rich (client) app for a customer based on Pharo > (I mean a real app, no Smalltalk tool - for instance a game or > a commercial app) he may want to: > > - lock the image so nobody is able to hit Cmd-. > - exchange the Walkback to display a custom dialog instead > of proving debugger access to the end user. Do we provide a > hook already? > - replace world menu with a custom menu. Do we provide a > hook already? > - wants to disable code evaluation in edit fields using > * menus (no doIt, printIt, inspectIt just cut, copy, paste) > * keyboard (Cmd-d, ...) > - wants to disable Halos > - prevent reading scripts/projects at startup so nobody is > able to hijack the image and get access to the code > - disable the dependency on source and changes file > > Maybe this locking facility can be reenabled after entering a > password so a developer can still debug in the customers environment. > (I remember Andreas said that they protect the Teleplace > image and save the password hashed in image). > > Maybe Gary can share his experience to lock the "Pinesoft â MBagger" > image or others how they lock down their image. > > Either we provide such a (switchable) mode in the default image > or give a guide in the pharo book on how to restrict end user > access to the Smalltalk environment in deployed applications. > > Yes - we provide a #cleanUpForProduction method - but this is > more to reduce size. > > Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518 > > I think of a loadable package "ImageLocker" with a class > that can set/unset the appropriate preferences and provide > alternative error handlers, menues, ... > > Any comments? > > Thx > T. > > BTW: I remember having a hard time with the "deployment step" in most > commercial environments due to "striping" the image. Now this > is partly adressed by building images bottom to top using > Metacello now. One could load his app based on a core without > the extended dev-tools. > > But Pharo should really care to also easily disable developer > facilities so developers may use it as the platform for > their next project. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

[Pharo-project] plan for 1.1

by Torsten Bergmann

Mariano wrote: >So...if you take a Core 11367 and load the metacellol version, it will >work perfect. But wouldn't that mean we should have a "1.1-beta1.11367" in the config? >That's not broken. Yes, the '1.1-beta1.10517' still works with the core 11367 image. But if you update it to a Core 11372 first and then use the ConfigurationOfPharo (1.1-beta1.10517) it is broken. >How can you assure that for any core version the same metacello version can >work on it? That's impossible. Yes. So the question is which core image is the base for Pharo 1.1. (10517, 11367, ...)? I would do: - a feature freeze for the core or pick a stable core so we have a stable 1.1 base to build the dev-image upon - adopt the config and loaded packages until they work on this core - test, test, test >I can update it, but if noone fixes Nile... I think the Nile problem is related to the traits problem introduced between core 11367 and core 11372. Since Stef already found the problem I asked if we get a fix in an upcoming 11373 so building the dev-image may work again. So currently we dont have a broken configuration but a broken core. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 26, 2010

Re: [Pharo-project] VM Preferences > System Configuration > Network Configuration...

by Mariano Martinez Peck

I agree. And I even think the behavior is different in the 3 VMs. Alain, what do you think? On Fri, May 21, 2010 at 5:06 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > I am just wondering whether the Network - HTTP proxy and network > authentication - settings (from the much improved new Settings Browser by > the way) should actually be moved to the VM Preferences under System > Configuration just like the Printer Configuration. > > At home I use the Mac VM and I tend to take my image on a USB key and use > the same image (how great is that) with the windows VM at work. I reckon > the Network Settings are just like the Print Setup and depend on the > environment where the VM is running and not necessarily the image. I > assume > the same goes for a developer who develops an app on one machine and > deploys > the image on a server? > > Anyway, just a thought :) > -- > View this message in context: > http://forum.world.st/VM-Preferences-System-Configuration-Network-Configura… > 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 >

May 26, 2010

[Pharo-project] Image Lockdown/Deployment mode

by Torsten Bergmann

Does Pharo currently provide support for a deployment mode/image locking mode? I think of the following scenario: ================================== If one builds a rich (client) app for a customer based on Pharo (I mean a real app, no Smalltalk tool - for instance a game or a commercial app) he may want to: - lock the image so nobody is able to hit Cmd-. - exchange the Walkback to display a custom dialog instead of proving debugger access to the end user. Do we provide a hook already? - replace world menu with a custom menu. Do we provide a hook already? - wants to disable code evaluation in edit fields using * menus (no doIt, printIt, inspectIt just cut, copy, paste) * keyboard (Cmd-d, ...) - wants to disable Halos - prevent reading scripts/projects at startup so nobody is able to hijack the image and get access to the code - disable the dependency on source and changes file Maybe this locking facility can be reenabled after entering a password so a developer can still debug in the customers environment. (I remember Andreas said that they protect the Teleplace image and save the password hashed in image). Maybe Gary can share his experience to lock the "Pinesoft â MBagger" image or others how they lock down their image. Either we provide such a (switchable) mode in the default image or give a guide in the pharo book on how to restrict end user access to the Smalltalk environment in deployed applications. Yes - we provide a #cleanUpForProduction method - but this is more to reduce size. Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518 I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ... Any comments? Thx T. BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image. Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools. But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 26, 2010

Re: [Pharo-project] plan for 1.1

by Mariano Martinez Peck

On Wed, May 26, 2010 at 10:10 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Stef wrote: > > does this plan look ok for you? > > Yes > > Alexandre wrote: > >Ok for me. But we need a Beta that is regularly built for this. > > +1 especially since it is currently broken > (see > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/027376.html) > > It is not broken. As you see in the name of the image: Pharo-1.1-*11367* -Beta1dev10.05.1 AND in the name of the metacello version: '1.1-beta1.10517'. So...if you take a Core 11367 and load the metacellol version, it will work perfect. That's not broken. How can you assure that for any core version the same metacello version can work on it? That's impossible. > Stef wrote > >I found the traits bug :) > > OK, can we expect a fix in the next update (11373?). > > I don't know. If someone proposes a fix, then yes. Probaly next week I can create a Pharo beta2 if you want. > Using ConfigurationOfPharo anyone is able to rebuild an own > beta to test and from time to time mariano can upload a full > beta image. > > Yes, but it is not a matter of the ConfigurationOfPharo. I can update it, but if noone fixes Nile... Cheers Mariano Bye > T. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

[Pharo-project] plan for 1.1

by Torsten Bergmann

Stef wrote: > does this plan look ok for you? Yes Alexandre wrote: >Ok for me. But we need a Beta that is regularly built for this. +1 especially since it is currently broken (see http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/027376.html) Stef wrote >I found the traits bug :) OK, can we expect a fix in the next update (11373?). Using ConfigurationOfPharo anyone is able to rebuild an own beta to test and from time to time mariano can upload a full beta image. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 26, 2010