- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] command line handler default options

by Camillo Bruni

On 2013-05-26, at 15:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Camillo, > > On 26 May 2013, at 13:57, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Currently Pharo runs without a message when started in headless mode: >> >> ./pharo Pharo.image >> >> However I would expect it to give a feedback, so it would behave like this: >> >> ./pharo Pharo.image --help >> >> AFAIK seaside doesn't have a command line handler yet ;), but how would you guys >> perceive it if >> >> - there is a a help message printed, >> - the image stops if there are no commands provided? >> >> We can add a --no-quit option to the default command line handler so the image >> continues running with whatever service there is. > > Yes, but > > - it might be a bit confusing since a normal image with GUI is started like in the first cmd line > - tools that don't print needless information are cool I took care of that in UI mode it - doesn't print anything on the command line - continues running and in headless mode - it prints --help - it quits unless there is --no-quit > - the -no-quit option is useful in the eval case as well to start a server/service added that as well in the same refactoring. Maybe you can have a look at it? https://pharo.fogbugz.com/default.asp?10759 with its proper SLICE in the inbox.

May 26, 2013

Re: [Pharo-dev] command line handler default options

by Sven Van Caekenberghe

Hi Camillo, On 26 May 2013, at 13:57, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Currently Pharo runs without a message when started in headless mode: > > ./pharo Pharo.image > > However I would expect it to give a feedback, so it would behave like this: > > ./pharo Pharo.image --help > > AFAIK seaside doesn't have a command line handler yet ;), but how would you guys > perceive it if > > - there is a a help message printed, > - the image stops if there are no commands provided? > > We can add a --no-quit option to the default command line handler so the image > continues running with whatever service there is. Yes, but - it might be a bit confusing since a normal image with GUI is started like in the first cmd line - tools that don't print needless information are cool - the -no-quit option is useful in the eval case as well to start a server/service Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 26, 2013

[update 3.0] #30169

by Marcus Denker

30169 ----- 10621 Create a lint rule to make sure UITheme and ThemeIcons are not used anymore https://pharo.fogbugz.com/f/cases/10621 10763 Lots of Opal test failing in 168: update tests https://pharo.fogbugz.com/f/cases/10763 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-MarcusDenker.13… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.473.diff

May 26, 2013

command line handler default options

by Camillo Bruni

Currently Pharo runs without a message when started in headless mode: ./pharo Pharo.image However I would expect it to give a feedback, so it would behave like this: ./pharo Pharo.image --help AFAIK seaside doesn't have a command line handler yet ;), but how would you guys perceive it if - there is a a help message printed, - the image stops if there are no commands provided? We can add a --no-quit option to the default command line handler so the image continues running with whatever service there is.

May 26, 2013

seaside 31 configuration not loading

by Camillo Bruni

https://ci.inria.fr/pharo-contribution/job/Seaside/ is currently red. What is the "official" location of the seaside configuration?

May 26, 2013

Re: [Pharo-dev] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Camillo Bruni

On 2013-05-21, at 20:19, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/21 Sean P. DeNigris <sean(a)clipperadams.com> > >> Camillo Bruni-3 wrote >>> Yuriy we can discuss that after tomorrow? >>> I would as well appreciate some common solution to avoid the selector >>> clash. >> >> Bump ;) >> >> > I don't remember is it was public conclusion but we agree to try StateSpecs > for Phexample. > After I finish key features of TxText I will adapt StateSpecs to satisfy > Camillo requirements. cool! let me know once you're ready ;) (no hurry) and we can do a tryout in Pharo 3.0!

May 26, 2013

Re: [Pharo-dev] Kernel Discussion

by Edgar J. De Cleene

On 5/26/13 6:03 AM, "Camillo Bruni" <camillobruni(a)gmail.com> wrote: > > You'll find it on the pharo-contribution CI: > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/ Very thanks ! Edgar

May 26, 2013

Re: [Pharo-dev] Kernel Discussion

by Camillo Bruni

On 2013-05-26, at 10:57, "Edgar J. De Cleene" <edgardec2005(a)gmail.com> wrote: > On 5/25/13 8:02 AM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > >> well... I said the same when I was applying those changes, he :) >> I already made a note in my TODO list to refactor that as soon as possible too >> :) >> >> Esteban >> >> On May 25, 2013, at 12:55 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I've seen a lot of progress for the Pharo Kernel by Pavel recently and I >>> really appreciate his work. But I have some questions I think we should >>> discuss. >>> >>> There have been quite a few changes to make code work in the Kernel and to >>> reduce dependencies between packages. But I really have the impression that >>> many of these changes are of bad quality :/. >>> >>> I do not want to offend people, but this is fairly important if we want to >>> have a nice code base. >>> >>> Example: >>> ======== >>> UnixResolver >> nbGetEnv: str >>> #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. >>> ^ nil >>> >>> The goal of this code is to conditionally do something in the main image but >>> continue to work in the kernel. >>> >>> Observations: >>> ============= >>> - #asClassIfPresent: and Co are bad >>> - Why do we clutter the main image if the kernel should change? >>> - Can't we solve these things by having proper other objects? >>> - Is the UnixResolver really needed in the Kernel? >>> >>> I worked with Esteban last week on a similar case in the CommandLineHandler >>> and we ended up introducing a minimal superclass. I guess this goes much in >>> the direction of having proper NullObjects. >>> >>> I really think we should not add these little nasty changes, but rather >>> introduce proper >>> new classes that can be unloaded if needed. >>> >>> What do you think? >> >> > Could say the url for dowloading the last PharoKernel ? You'll find it on the pharo-contribution CI: https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/

May 26, 2013

Re: [Pharo-dev] Kernel Discussion

by Edgar J. De Cleene

On 5/25/13 8:02 AM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > well... I said the same when I was applying those changes, he :) > I already made a note in my TODO list to refactor that as soon as possible too > :) > > Esteban > > On May 25, 2013, at 12:55 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I've seen a lot of progress for the Pharo Kernel by Pavel recently and I >> really appreciate his work. But I have some questions I think we should >> discuss. >> >> There have been quite a few changes to make code work in the Kernel and to >> reduce dependencies between packages. But I really have the impression that >> many of these changes are of bad quality :/. >> >> I do not want to offend people, but this is fairly important if we want to >> have a nice code base. >> >> Example: >> ======== >> UnixResolver >> nbGetEnv: str >> #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. >> ^ nil >> >> The goal of this code is to conditionally do something in the main image but >> continue to work in the kernel. >> >> Observations: >> ============= >> - #asClassIfPresent: and Co are bad >> - Why do we clutter the main image if the kernel should change? >> - Can't we solve these things by having proper other objects? >> - Is the UnixResolver really needed in the Kernel? >> >> I worked with Esteban last week on a similar case in the CommandLineHandler >> and we ended up introducing a minimal superclass. I guess this goes much in >> the direction of having proper NullObjects. >> >> I really think we should not add these little nasty changes, but rather >> introduce proper >> new classes that can be unloaded if needed. >> >> What do you think? > > Could say the url for dowloading the last PharoKernel ? Edgar

May 26, 2013

Re: [Pharo-dev] Kernel Discussion

by stephane ducasse

Hi pavel I agree with you. I think that at the end this is a problem of architecture and hooks been made to be customised. Stef

May 26, 2013