- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

by Ben Coman

On 19 March 2018 at 17:07, Petr Fischer <petr.fischer(a)me.com> wrote: > Hello! > > I assume that Ctrl+W is a widely used keyboard shortcut for closing > windows or a tab, if the window is "tabbed" (it works in web browsers, some > desktops, Linux, IE, Mac OS X...). > > But when I start up some exploration session in GT inspector, I have > several tabs opened in a second - then, after Ctrl+W, not the actual tab, > but the whole window is immediately closed, gosh... > Same situation in "window groups" (when you created tabbed window group > from browser/Calypso) - Ctrl+W behaves weird. > > Is everyone in comfort with the idea that Ctrl+W should close the actual > tab, and if there is no tab in the window (or actual tab is the last tab), > then close the window? > Actually I never knew that shortcut, but I will now. I see it works that way in both Chrome and InternetExplorer and web browsers are a good benchmark. But its not "critical" so I think it will be tough convincing someone to work on it for 5.0, 6.0, 6.1. For 7 it sounds like a good idea. cheers -ben > > Tested in Pharo 5, 6 and 6.1. > > pf > >

March 19, 2018

Re: [Pharo-dev] Idea to manager package comment in better way

by Denis Kudriashov

I created issue 21617 <https://pharo.fogbugz.com/f/cases/21617/Better-implementation-of-package-co…> 2018-03-16 16:54 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi denis > > Both solutions are ok for me. > > STef > > On Fri, Mar 16, 2018 at 2:38 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > And at the end I found that #packageComment: is not really work because > it > > expects already formatted string suitable for source code insertion. > > So you can't just call: > > > > aPackage packageComment: 'my comment'. > > > > Instead all users (only Nautilus exists) should write > > > > aPackage packageComment: 'my comment' printString > > > > I will create pull request with all this changes > > > > 2018-03-14 16:51 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > >> And I found that manifest classes are already commented as package > >> comment. > >> > >> 2018-03-14 16:40 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >>> > >>> Hi. > >>> > >>> I look at hierarchy of PackageManifest and I was wondering that all > these > >>> classes are commented but most of packages which they describe are not. > >>> > >>> Also interesting that most of manifest comments are same. > >>> > >>> Then I found that package comment is managed as special class side > method > >>> #description which is generated when you call "aPackage packageComment: > >>> 'test'". > >>> > >>> Now the idea: will not it be better to manage package comment as > manifest > >>> class comment? > >>> > >>> Manifest is already responsible to describe the package. So it looks > >>> logical to have "manifest comment = package comment". > >>> Also it will simplify code and remove duplication of texts. > >>> In addition it will add extra place indicating that package needs to be > >>> commented because uncommented classes are marked in the browser. > >>> > >>> What you think? > >>> > >> > > > >

March 19, 2018

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

by Denis Kudriashov

Hi. Are you sure that Calypso closes full window instead of single tab? Because I use it all the time and it works for me in the way you described. 2018-03-19 10:07 GMT+01:00 Petr Fischer <petr.fischer(a)me.com>: > Hello! > > I assume that Ctrl+W is a widely used keyboard shortcut for closing > windows or a tab, if the window is "tabbed" (it works in web browsers, some > desktops, Linux, IE, Mac OS X...). > > But when I start up some exploration session in GT inspector, I have > several tabs opened in a second - then, after Ctrl+W, not the actual tab, > but the whole window is immediately closed, gosh... > Same situation in "window groups" (when you created tabbed window group > from browser/Calypso) - Ctrl+W behaves weird. > > Is everyone in comfort with the idea that Ctrl+W should close the actual > tab, and if there is no tab in the window (or actual tab is the last tab), > then close the window? > > Tested in Pharo 5, 6 and 6.1. > > pf > >

March 19, 2018

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

by Alistair Grant

On 19 March 2018 at 10:07, Petr Fischer <petr.fischer(a)me.com> wrote: > Hello! > > I assume that Ctrl+W is a widely used keyboard shortcut for closing windows or a tab, if the window is "tabbed" (it works in web browsers, some desktops, Linux, IE, Mac OS X...). > > But when I start up some exploration session in GT inspector, I have several tabs opened in a second - then, after Ctrl+W, not the actual tab, but the whole window is immediately closed, gosh... > Same situation in "window groups" (when you created tabbed window group from browser/Calypso) - Ctrl+W behaves weird. > > Is everyone in comfort with the idea that Ctrl+W should close the actual tab, and if there is no tab in the window (or actual tab is the last tab), then close the window? > > Tested in Pharo 5, 6 and 6.1. > > pf +1

March 19, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-19 9:16 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont > <stephan(a)stack.nl>: > > > >> Denis Kudriashov <dionisiydk(a)gmail.com> > >> wrote: > >>> > >>> No. Each build just loads specified version. I do not need to create > new > >>> version for new build. > >>> But I think I still not understand you > >> > >> That specified version will no longer work in a newer pharo build. Pharo > >> changes, making it necessary for your dependencies to change. Will you > make > >> a new release each time one of your dependencies needs to change? > >> > > > > I do not put dependencies of projects which are part of standard Pharo > > image. So Pharo updates do not affect my baselines > > And your dependencies are not impacted by standard pharo changes? > It can be impacted of course. But it is normal process for alpha Pharo 7. And Pharo 6 is fixed, so I do not care. > Stephan > > > >

March 19, 2018

Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

by Petr Fischer

Hello! I assume that Ctrl+W is a widely used keyboard shortcut for closing windows or a tab, if the window is "tabbed" (it works in web browsers, some desktops, Linux, IE, Mac OS X...). But when I start up some exploration session in GT inspector, I have several tabs opened in a second - then, after Ctrl+W, not the actual tab, but the whole window is immediately closed, gosh... Same situation in "window groups" (when you created tabbed window group from browser/Calypso) - Ctrl+W behaves weird. Is everyone in comfort with the idea that Ctrl+W should close the actual tab, and if there is no tab in the window (or actual tab is the last tab), then close the window? Tested in Pharo 5, 6 and 6.1. pf

March 19, 2018

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

by Alistair Grant

Hi Pablo, On 16 March 2018 at 15:32, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > > On Fri, Mar 16, 2018 at 3:26 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> Hi Pablo, >> >> Thanks for your quick reply. >> >> On 16 March 2018 at 14:38, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >> > Hi, >> > sorry my mistake when updating the scripts. As the bootstrap.sh is >> > not >> > executed during the Jenkins process it has not been validated (locally >> > I'm >> > not using that script, because is trying to download each time the VM >> > and >> > the bootstraping process image) >> >> Right. Can we make one of the goals of the refactoring to avoid any >> code duplication? >> >> e.g. at the moment (ignoring changes proposed below), Jenkins should >> be calling bootstrap.sh. >> > > Yes that is part of the plan. > >> >> >> > The correct line is the one from the JenkinsFile, it should be something >> > like: >> > >> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st >> > --ARCH=${architecture} >> > --BUILD_NUMBER=${env.BUILD_ID} --quit >> > >> > I will submit a PR to fix it, as soon as the CI infrastructure is less >> > on >> > fire. >> > Until the fix, if you are building the image locally you can change the >> > error line with: >> > >> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit >> > >> > And it will work. >> >> Shall do. >> >> >> > The idea is to migrate more parts of the process to pure Pharo code, >> >> +1 >> >> >> > everything is implemented in a project PharoBootstrapProcess, which is >> > located in bootstrap/src in the same Pharo repository. >> > The best way to check what is there is to do the same as the process. >> > 1) Take an image with VMMaker, Espell and Ficus (we have them already >> > made >> > in >> > >> > https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapI…) >> > 2) Execute bootstrap/scripts/prepare_image.st >> > >> > That is the same image used to bootstrap Pharo. >> > I will do another pass on this first part of the process and generate >> > some >> > documentation about the changes and how to modify the whole process. >> > We decided to migrate the process by parts to be able to review it >> > easily >> > than waiting to have a whole migration of the process. >> > >> > The next step is to do the same with the build.sh file, as you can see >> > it, >> > is a little complex and have lots of steps. >> > The idea is again convert them into Pharo code. >> >> Can we also re-order the bootstrap and break it into several distinct >> phases. >> >> 1. Clean up (this ensures a clean environment for Jenkins) >> 2. Download all pre-requisites. >> The main change here is moving the call to download_vm.sh out of >> build.sh. >> This would allow a particular VM to be installed by hand for step >> 4, see below. >> 3. Initial preparation, i.e. all the execution prior to build.sh, e.g. >> prepare_image.st. >> Currently this is done with the Pharo 6 VM and image, which makes sense >> as it >> provides stability. >> 4. Main image bootstrap. Which is done with the Pharo 7 VM (currently >> what is in build.sh). >> >> That will allow the first three steps to be run once and then skipped >> when doing personal development / testing. >> >> I want to be able to manually load the VM to be used in step 4 as part >> of some stability testing so we can promote a new Pharo 7 VM to >> stable. >> >> Are you open to me submitting some PRs that do this restructure to the >> phases listed above and removing duplicate code from Jenkinsfile? >> > Yes of course. Thanks Could I ask you to have a look at: https://pharo.fogbugz.com/f/cases/21615/Separate-bootstrap-process-in-to-di… https://github.com/pharo-project/pharo/pull/1127 This does the first step of breaking the bootstrap process in to distinct phases and moving all the downloads to the start (e.g. allowing a test VM to be substituted for the build stage). Once this is integrated I can submit a PR that modifies Jenkinsfile to use the new shell scripts, removing code duplication. On 16 March 2018 at 14:38, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, > sorry my mistake when updating the scripts. As the bootstrap.sh is not > executed during the Jenkins process it has not been validated (locally I'm > not using that script, because is trying to download each time the VM and > the bootstraping process image) There are also scripts to snapshot and restore the bootstrap state, avoiding the need to do the multiple downloads. Just to be clear again: This is intended to complement and help with the goal of moving the bootstrap process to pure Pharo code. Each of the shell scripts can eventually be replaced by a call to the equivalent Pharo code. Thanks! Alistair

March 19, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> No. Each build just loads specified version. I do not need to create new >>> version for new build. >>> But I think I still not understand you >> >> That specified version will no longer work in a newer pharo build. Pharo >> changes, making it necessary for your dependencies to change. Will you make >> a new release each time one of your dependencies needs to change? >> > > I do not put dependencies of projects which are part of standard Pharo > image. So Pharo updates do not affect my baselines And your dependencies are not impacted by standard pharo changes? Stephan

March 19, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-17 17:01 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > No. Each build just loads specified version. I do not need to create new > > version for new build. > > But I think I still not understand you > > That specified version will no longer work in a newer pharo build. Pharo > changes, making it necessary for your dependencies to change. Will you make > a new release each time one of your dependencies needs to change? > I do not put dependencies of projects which are part of standard Pharo image. So Pharo updates do not affect my baselines > > Stephan > > > >

March 18, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Tudor Girba

+1 Doru > On Mar 18, 2018, at 10:30 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Thanks Milton!!!!!!!!!!! > > Can you open issue on the bug tracker? > > https://github.com/pharo-project/pharo-launcher/issues > > This way we are sure that it is not lost. > > Stef > > On Sat, Mar 17, 2018 at 11:17 PM, milton mamani <akevalion(a)gmail.com> wrote: >> I have issues with Pharo Launcher. >> >> Pharo Launcher version >> version 1.1.1 >> http://files.pharo.org/pharo-launcher/tmp-1.1.1/ >> >> version 1.1 >> http://files.pharo.org/pharo-launcher/1.1/ >> >> You can get these links in https://github.com/pharo-project/pharo-launcher/ >> >> OS Version >> Mac OS - 10.13.3 >> >> Issues >> >> Issue #1, version 1.1 does not run in Mac OS - 10.13.3 >> * Load P.L version 1.1 >> * Copy the application in `Applications` folder >> * Try to open the program, with right-click, open >> * Current result the program P.L. does not run. >> >> Issue #2 Can not open/run downloaded images >> * Load P.L version 1.1.1 >> * Copy the application in `Applications` folder >> * Open the program, first time the program does not run >> * Open again the program, now the program shows a window >> * Try to load a pharo image, In `Templates` >> `Official distributions`>> >> `Pharo 6.1 stable`. >> * Right-click in the pharo image, then select option `Create Image` >> * A popup ask for a name >> * Introduce one name, eg: `PImage` >> * A loading process appears >> * Try to run the image with button `Launch` >> * Current result the image `PImage` does not run, and P.L. 1.1.1 quit on >> that launch. >> >> Issue #3 Pharo debugger error appear when navigating in templates >> * load P.L version 1.1.1 >> * Open the P.L >> * In templates area, try to load some templates >> * Then select one template >> * A debugger error window appears with the message #selectMorphList was >> sent to nil >> * Current result: Sometimes when you try to load and select some templates >> an error window appear >> >> Please tell me If you need more details about these issues >> >> >> >> 2018-03-17 16:42 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> On Sat, Mar 17, 2018 at 12:59 PM, Alexandre Bergel >>> <alexandre.bergel(a)me.com> wrote: >>>> Yesterday we also experienced many problem when using Launcher on OSX >>>> :-( >>> >>> Which version of Launcher? >>> Which version of your OS? >>> What problems? >>> Can we reproduce it? >>> >>> Could we get pro in reporting problems? >>> >>> >>>> Is the Launcher still maintained? >>> >>> Alexandre >>> >>> Christophe spent two months fixing tons of issues. >>> So could you report problems in a nicer way? >>> >>> >>> >>> >>>> >>>> Alexandre >>>> >>>> >>>>> On Mar 17, 2018, at 8:57 AM, kmo <voxkmp(a)gmail.com> wrote: >>>>> >>>>> I tried the default download of Pharo Launcher on my Windows 7 (32 bit) >>>>> PC at >>>>> work. It installs. Runs fine - creates images and vms but when you try >>>>> to >>>>> run them nothing happens. It fails to start the selected image. It just >>>>> fails to run the vm at all as far as I can see. >>>>> >>>>> I tried it on my Windows 10 (32 bit) laptop and got exactly the same >>>>> result. >>>>> >>>>> This is not important for me as I use pharo on Linux - but I thought >>>>> I'd >>>>> point it out. If having the launcher as the default download causes >>>>> more >>>>> problems than the traditional vm and image download then perhaps it >>>>> should >>>>> be reconsidered. A pity since I love the launcher. >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: >>>>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>>> >>>> >>>> >>> >> > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

March 18, 2018