- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] plan for 1.1

by Schwab,Wilhelm K

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

May 26, 2010

Re: [Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Mariano Martinez Peck

On Wed, May 26, 2010 at 6:15 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2010/5/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Wed, May 26, 2010 at 9:43 AM, Serge Stinckwich > > <serge.stinckwich(a)gmail.com> wrote: > >> > >> It look likes the problem is related to the fact that Deja Vu fonts is > >> only in 9 and 12pt under Mac OS X. > > > > > > Serge: did you change to DejaVu fonts in Pharo1.1? because in this > image, > > StrikeFonts are by default. > > Yes i think so with the Settings tool. > Ok....and with StrikeFonts (like the default image) does it work properly? Cheers Mariano > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > 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 nullPointer

Well, I understand than #&& and #|| must be equivalents to #and: AND #or: . Lazy comparison I want say. Regards -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231539.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 26, 2010

Re: [Pharo-project] plan for 1.1

by Alexandre Bergel

>> 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? > > > Ok for me. Ok for me. But we need a Beta that is regularly built for this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 26, 2010

Re: [Pharo-project] ConnectionQueue defect in 1.0

by Schwab,Wilhelm K

Henry, Whatever fix we want is fine with me, provided we fix it :) Re #next:, it will silently truncate and does not complain on stream exhaustion. Both are *BAD* when they happen by surprise; when they are good, IMHO one should use specific selectors that clarify that the code is authorized to think for us. See http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware http://code.google.com/p/pharo/wiki/ProposalForConsistentStreamsBehavior I prefer Dolphin's approach to the problems, but since I cannot unilaterally adopt it, I have chosen the alternate selectors for my own work. Code I write will require #nextOne, #nextMany:, and #nextAvailable:, etc. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] Sent: Wednesday, May 26, 2010 5:35 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ConnectionQueue defect in 1.0 Yes, it is broken. To me, removing the return of true, and changing the method comment to reflect the real return values seem like the "simplest" solution. There seems to have been some issues related to clock wraparound fixed around the time of the method time stamps, not sure if the ^true was just a way to align better with the comment, or a real fix for something though :/ Cheers, Henry On May 25, 2010, at 8:58 44PM, Schwab,Wilhelm K wrote: > Hello all, > > Please see attached - CAREFULLY :) It turns out that NetworkSmokeTest will fail in your images, for want of #nextMany: and other additions I have made to streams. > PS. What is wrong with next: ? _______________________________________________ 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 Richard Durr

Ah okay, I am much relieved now, thanks :) On Wed, May 26, 2010 at 2:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > In general (but it often does not work :)) having a lot of conditions in OOP > means that you are missing class to dispatch on then. > >> But then which is the equivalence to #and:and:and: when I have many >> conditions? > > a and: [b] and: [c] > > if a and c do not have side effect that may change the condition are equivalent > to > a and: [ b and: [c]] > > so you have express what you want > >> Perhaps I will say a stupidity... but , not is valid the implementation of >> #&& and #|| messages instead of #and:... Â #or: .....? > > > & and | are executing all their arguments while > Â Â Â Â true & error -> error > Â Â Â Â true and: [error] -> true but it is more costly > > >> >> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >> >> >> Regards >> -- >> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.h… >> 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 > > > _______________________________________________ > 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 StÃ©phane Ducasse

In general (but it often does not work :)) having a lot of conditions in OOP means that you are missing class to dispatch on then. > But then which is the equivalence to #and:and:and: when I have many > conditions? a and: [b] and: [c] if a and c do not have side effect that may change the condition are equivalent to a and: [ b and: [c]] so you have express what you want > Perhaps I will say a stupidity... but , not is valid the implementation of > #&& and #|| messages instead of #and:... #or: .....? & and | are executing all their arguments while true & error -> error true and: [error] -> true but it is more costly > > ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] > > > Regards > -- > View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.h… > 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