- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Make the auto completion pop-up appear faster

by Aliaksei Syrel

I always change delay to 200ms. So, you have my vote :) On Aug 10, 2015 10:18 PM, "Merwan Ouddane" <merwanouddane(a)gmail.com> wrote: > 200 seems perfect to me. > > Does anyone else have other preferences ? :) > > Le 10/08/2015 21:56, stepharo a Ã©crit : > >> may be the default should be 250. >> Can you try and let us know? >> >> >> Le 10/8/15 17:39, Merwan Ouddane a Ã©crit : >> >>> Yes. >>> Specially if you have a bad timing, you start to type your method name >>> and the pop-up shows up just before you press enter >< >>> >>> On lun., 2015-08-10 at 17:27 +0200, Franck Warlouzet wrote: >>> >>>> On every image I take, I replace the delay from 500 to 100 and it is >>>> fast (too much maybe for some people) enough, 500 is far too much, you >>>> finished to type in a half second. >>>> >>>> Franck >>>> >>>> >>>> ______________________________________________________________________ >>>> Date: Mon, 10 Aug 2015 17:22:05 +0200 >>>> From: i.uhnak(a)gmail.com >>>> To: pharo-dev(a)lists.pharo.org >>>> Subject: Re: [Pharo-dev] Make the auto completion pop-up appear faster >>>> >>>> Yes, there is >>>> Settings > Code Browsing > Code Completion... > Popup appearance delay >>>> >>>> >>>> So I guess the question should be whether the _default_ delay should >>>> be shorter. >>>> >>>> >>>> Showing popup immediately may not be so useful, because you haven't >>>> typed much... >>>> I personally prefer to use shortcut to force the popup to show up. >>>> >>>> >>>> Peter >>>> >>>> On Mon, Aug 10, 2015 at 4:29 PM, Thomas Heniart >>>> <heniart.thomas(a)gmail.com> wrote: >>>> Hi, >>>> There is a setting for this >>>> Cheers, >>>> Thomas >>>> 2015-08-10 16:16 GMT+02:00 Merwan Ouddane >>>> <merwanouddane(a)gmail.com>: >>>> Hi, >>>> I wanted to have your opinion on this >>>> case: >>>> >>>> https://pharo.fogbugz.com/f/cases/15697/Speed-up-the-autocompletion-pop-up-… >>>> Cheers, >>>> Merwan >>>> >>>> >>>> >>> >>> >>> >> >> > >

Aug. 11, 2015

Re: [Pharo-dev] Make the auto completion pop-up appear faster

by Sean P. DeNigris

MerwanOuddane wrote > 200 seems perfect to me. >>>> On every image I take, I replace the delay from 500 to 100 and it is I also set it to 100 via startup script ----- Cheers, Sean -- View this message in context: http://forum.world.st/Make-the-auto-completion-pop-up-appear-faster-tp48419… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 11, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50219 Home: https://github.com/pharo-project/pharo-core

Aug. 11, 2015

[pharo-project/pharo-core] 4dd200: 50219

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4dd200aa5fb739ab9cb02b9f9e928d015459f844 https://github.com/pharo-project/pharo-core/commit/4dd200aa5fb739ab9cb02b9f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-11 (Tue, 11 Aug 2015) Changed paths: R AST-Core.package/BIConfigurableFormatter.class/class/accessing/traditionalBinaryPrecedence.st A AST-Core.package/BIConfigurableFormatter.class/class/accessing/traditionalBinaryPrecedenceArray.st A AST-Core.package/BIConfigurableFormatter.class/class/accessing/traditionalBinaryPrecedenceArray_.st R AST-Core.package/BIConfigurableFormatter.class/class/accessing/traditionalBinaryPrecedence_.st A AST-Core.package/BIConfigurableFormatter.class/instance/accessing/traditionalBinaryPrecedenceArray_.st R AST-Core.package/BIConfigurableFormatter.class/instance/accessing/traditionalBinaryPrecedence_.st M AST-Core.package/BIPrettyPrinterContext.class/definition.st M AST-Core.package/BIPrettyPrinterContext.class/instance/accessing/traditionalBinaryPrecedenceArray.st A AST-Core.package/BIPrettyPrinterContext.class/instance/accessing/traditionalBinaryPrecedenceArray_.st R AST-Core.package/BIPrettyPrinterContext.class/instance/accessing/traditionalBinaryPrecedence_.st M AST-Core.package/BIPrettyPrinterContext.class/instance/initialization/initialize.st M MonticelloGUI.package/MCTool.class/instance/morphic ui/textMorph_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50218.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50219.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50218.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50219.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tests.package/SystemSettings.class/README.md A Tests.package/SystemSettings.class/definition.st A Tests.package/SystemSettings.class/instance/tests/testOpening.st Log Message: ----------- 50219 16138 WorldMenu->System->Settings throws DNU - Image 50217 https://pharo.fogbugz.com/f/cases/16138 16140 Monticiellos save popup should should wrap the text. https://pharo.fogbugz.com/f/cases/16140 http://files.pharo.org/image/50/50219.zip

Aug. 11, 2015

Re: [Pharo-dev] Nautilus leak symptom

by Ben Coman

On Tue, Aug 11, 2015 at 3:54 AM, stepharo <stepharo(a)free.fr> wrote: > >> Its been noted before there may be some leak in Nautilus. > > > Yes because probably of announcer. Thanks for reporting them. > We started to clean Nautilus and we already simplified a lot some dark > corners but there was and still > certainly a lot of places for improvements. > > >> I bumped >> into a possible symptom... >> >> 1. Open fresh image (e.g. 50216) >> >> 2. Open Transcript. >> >> 3. Open *one* System Browser >> >> 4. Add instrumentation to method Nautilus >>> NautilusUI >> >> methodModified: >> e.g.... Transcript crShow: '>>>' , thisContext printString; tab; >> show: anAnnouncement printString ; tab ; show: sourceTextModel text. >> >> 5. In same System Browser, >> add method MyPackage >>> MyClass >> test1 >> >> Observe steps (4.) and (5.) each logged a single item to Transcript. >> >> 6. Open a *second* System Browser and >> add method MyPackage >>> MyClass >> test2 >> >> Observe step (6.) logged two items to Transcript, one for each open >> System Browser. >> >> 7. Close *second* System Browser. >> 8. In *first* System Browser, modify #test1. >> >> Observe step (8.) logged two items to Transcript. I would expect only >> one. >> >> >> Is there any issue open for this? I couldn't find one. >> >> cheers -ben >> Posts seem to be slow coming through, sorry if I double up this response. Not sure yet if this is all that is required, but its a start... NautilusWindow >> delete | mod | mod := self model. super delete. ">>>" SystemAnnouncer uniqueInstance unsubscribe: mod. "<<<added" mod ifNotNil: [ mod announce: (WindowClosed new window: self) ] cheers -ben

Aug. 11, 2015

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

I am nearly finished with converting old shortcut mapping (Editor/TextEditor cmdActions/shiftCmdAction map) to our keymapping framework. 15619 <https://pharo.fogbugz.com/default.asp?15619> cleanup TextEditors shortcut definition I need some more time, one or two vm changes and some people testing this on a mac. I know, this is a bit late because we replace our text components with rubric, but if this is finished and working for "old" PluggableTextMorphs, I will do the same for rubric. 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > if reintroduce them means reintroduce them hardcoded as before, then Iâm > complete against it and I WILL NOT integrate such solution. > Iâm sorry for being so strong here, but previous implementation was lame > and we need to get rid of them. > > Now, I understand people are used to use those bindings and also some > others (no idea which ones because I never used themâ¦ for me ocompletion is > good enoughâ¦ but those are tastes). So I would be very happy to integrate a > generic way to define keybindings and outputs (which is already there, with > keymapping, but I mean an editor or something), and I would be very happy > to integrate a default configuration (which of course, will include > #ifTrue:/##ifFalse:) > > Esteban > > > > On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > I would also appreciate if it was readded, as I've been using it regularly. > > Peter > > On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.thomas(a)gmail.com> > wrote: > >> I think it could be nice to keep this shortcut :) >> >> >> On 08/08/2015 12:12, Franck Warlouzet wrote: >> >> Hi, >> >> Yes it was not on purpose. It is not implemented in Rubric, but I can do >> it if there is a need of it (which seems to be the case). >> >> Franck >> >> ------------------------------ >> Date: Sat, 8 Aug 2015 12:09:22 +0200 >> From: i.uhnak(a)gmail.com >> To: pharo-dev(a)lists.pharo.org >> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >> >> Hi, >> >> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >> >> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… >> (maybe was caused by switch to Rubric?) >> >> Peter >> >> >> > >

Aug. 11, 2015

Re: [Pharo-dev] GTSpotter on CatalogBrowser

by Tudor Girba

Brick should be changed upstream. Doru On Tue, Aug 11, 2015 at 9:25 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Well adding description/caching is trivial. > > The Brick on the other hand may be more complex, and I don't know if Brick > is officially part of Pharo, or is introduced from Glamour and thus should > be fixed upstream. > > Peter > > On Tue, Aug 11, 2015 at 9:16 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Peter, >> >> Not a bug - more a feature request. I had no time lately to continue >> working on Spotter integration >> for new Catalog Browser. As always we need more resources to work on it. If >> you like open >> an issue for Pharo 5 on FogzBugz and (if possible) help/try to fix it. >> >> Thanks >> T. >> >> *Gesendet:* Dienstag, 11. August 2015 um 08:38 Uhr >> *Von:* "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> >> *An:* "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> *Betreff:* Re: [Pharo-dev] GTSpotter on CatalogBrowser >> Should this be reported to FogzBugz or upstream (Moose?)? >> >> On Sat, Aug 8, 2015 at 6:51 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> Hi, >>> >>> when previewing CatalogBrowser projects via GTSpotter, there's a lot of >>> empty space in the preview window >>> >>> âthe result is that the data that I am actually interested in are >>> cropped. >>> >>> Also I think project's description should be available there. >>> >>> >>> And final question: >>> to my knowledge http://catalog.pharo.org/catalog/json is being updated >>> only once a day, so there is not much point of downloading it and parsing >>> it every time single time I open spotter. >>> >>> Also I have to wait after typing something before the projects actually >>> show up. So why not use a time-based cache/singleton? >>> >>> Thanks, >>> Peter >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 11, 2015

Re: [Pharo-dev] GTSpotter on CatalogBrowser

by Peter UhnÃ¡k

Well adding description/caching is trivial. The Brick on the other hand may be more complex, and I don't know if Brick is officially part of Pharo, or is introduced from Glamour and thus should be fixed upstream. Peter On Tue, Aug 11, 2015 at 9:16 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Peter, > > Not a bug - more a feature request. I had no time lately to continue > working on Spotter integration > for new Catalog Browser. As always we need more resources to work on it. If > you like open > an issue for Pharo 5 on FogzBugz and (if possible) help/try to fix it. > > Thanks > T. > > *Gesendet:* Dienstag, 11. August 2015 um 08:38 Uhr > *Von:* "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> > *An:* "Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] GTSpotter on CatalogBrowser > Should this be reported to FogzBugz or upstream (Moose?)? > > On Sat, Aug 8, 2015 at 6:51 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> when previewing CatalogBrowser projects via GTSpotter, there's a lot of >> empty space in the preview window >> >> âthe result is that the data that I am actually interested in are cropped. >> >> Also I think project's description should be available there. >> >> >> And final question: >> to my knowledge http://catalog.pharo.org/catalog/json is being updated >> only once a day, so there is not much point of downloading it and parsing >> it every time single time I open spotter. >> >> Also I have to wait after typing something before the projects actually >> show up. So why not use a time-based cache/singleton? >> >> Thanks, >> Peter >> >> >

Aug. 11, 2015

Re: [Pharo-dev] GTSpotter on CatalogBrowser

by Torsten Bergmann

Aug. 11, 2015

Re: [Pharo-dev] Stream Control Transmission Protocol

by stepharo

> So it seems you only need VM changes integrated. How would you feel > about working directly with the vm-dev community to do this? A ticket > in the Pharo bugtracker is implicitly waiting for someone else to pick > it up and push it, but Pharo has only a few busy people to work on the > VM, thus your ticket there has languished >2yrs. There are more > non-Pharo vm-devs (who don't follow the Pharo bug tracker), so going > direct you might have a broader chance of getting it reviewed and > integrated. This might not have been so practical when you first > logged your ticket since at that time the Pharo-VM had diverged from > the mainline-Cog-VM but its now realigned to get all the Spur > goodness, so Pharo would inherit your changes in due course. > > Full disclosure: I'm trying to close old tickets to reduce our > software inventory [1] - but I hopefully this is a good path for you > also. > [1] http://www.joelonsoftware.com/items/2012/07/09.html > > cheers -ben Thanks ben. You are so right :)

Aug. 11, 2015