- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Monticello SmalltalkHub no longer asks for credentials

by Sean P. DeNigris

btc wrote > Before logging an issue, can someone confirm that (from a least build > #30545) saving via Monticello to Smalltalkhub does not ask for > credentials, but just fails with MCPermissionDenied? This is a "feature". Before, when the dialog appeared, there was no way to get rid of it. It would just keep coming back, over and over, until you supplied credentials. If the dialog was important to you, please figure out a way to have it easily cancelable for those of us who never use it... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Monticello-SmalltalkHub-no-longer-asks-for-credential… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-dev] Remove Class Category

by Jimmie Houchin

Hello, Thanks for the reply. This does exactly what I wanted. I believe I saw the method while browsing the plethora of methods that the Finder pulls up. But I did not know automatically how to have the instance of the SystemOrganizer to operate on. And since I was not even sure that it was the correct way. I finally decided to ask. Thanks. Jimmie On 11/12/2013 2:25 AM, Goubier Thierry wrote: > Hi, > > this probably depends on the version of Pharo you're using but, in > 3.0, what you can do is: > > Smalltalk globals organization removeCategory: name. > > And then you need to update the relevant RPackage tag: > > package removeClassTag: name > > (Because RPackage class tags are synchronized on some category > operations, but not all). > > In 2.0, you just have to execute the first one. > > Nautilus, or Browser, are good places to see that type of code. > > Thierry > > Le 11/11/2013 23:33, Jimmie Houchin a Ã©crit : >> Hello, >> >> I am wanting to write a method which uninstalls all of the Classes which >> I have created. >> >> I have one which looks like this: >> >> uninstall >> >> AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ] >> >> >> However the class category which was created to install them into still >> remains. I am having a hard time discovering what method I use to remove >> the category these classes were in. >> >> There are a lot of methods with category in the name. And is quite >> confusing how category and protocol are sometimes used interchangeably. >> I can't tell whether or not they are talking about removing the method's >> protocol categorization or the classes' category categorization. Its not >> until you go read the source that you might learn which you are >> looking at. >> >> Any help pointing to the method I am looking for is greatly appreciated. >> >> Jimmie >> >> >

Nov. 12, 2013

Monticello SmalltalkHub no longer asks for credentials

by Ben Coman

Before logging an issue, can someone confirm that (from a least build #30545) saving via Monticello to Smalltalkhub does not ask for credentials, but just fails with MCPermissionDenied? cheers -ben

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Martin Dias

(Checked in Pharo 30567) On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Thanks Ben. It's neat to have Spec models for tree columns. It was > strange to instantiate MorphTreeColumnMorph directly from my Spec > model. > > I found an issue in TreeModel: Only one level of children is shown. > Reproduce with: > > TreeModel new > roots: (1 to: 5); > childrenBlock: [ :item | 1+item to: 5+item ]; > openWithSpec > > Should I report? > > MartÃn > > On Tue, Nov 12, 2013 at 2:59 PM, Benjamin > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> Itâs this one: https://pharo.fogbugz.com/default.asp?12135 >> >> Ben >> >> On 12 Nov 2013, at 14:49, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> I forgot to specify: in latest Pharo (30565) >> >> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> I think there is some issue with TreeColumnModel. For example: >> >> TreeModel exampleWithCustomColumnsAndNodes >> >> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" >> >> Should I report in fogbugz? >> >> thanks, >> MartÃn >> >> On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> >> Yes this is what I did for the change sorter. I do not like this DSL like >> way of passing block over block over block >> over blocks. >> >> I love blocks but methods are named blocks and I prefer them. >> >> Stef >> >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than >> using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> >> wrote: >> >> One can just use an object too. >> >> Itâs just that otherwise, it pollutes a bit the method with tons of inst >> vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> >> It is not necessary better, but it saves you from having hundreds of temp >> vars :) >> >> Ben >> >> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> >> Example: >> aMenu addGroup: [ :aGroup | >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix ]. >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ] ] ]. >> >> >> I do not see the value of passing block to add element to groups >> why not the normal way i.e. passing an object. I do not get why executing >> a block with an object is better? >> >> >> he, I thought the same :) >> >> >> Stef >> >> >> >> >> >> >> >>

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Martin Dias

Thanks Ben. It's neat to have Spec models for tree columns. It was strange to instantiate MorphTreeColumnMorph directly from my Spec model. I found an issue in TreeModel: Only one level of children is shown. Reproduce with: TreeModel new roots: (1 to: 5); childrenBlock: [ :item | 1+item to: 5+item ]; openWithSpec Should I report? MartÃn On Tue, Nov 12, 2013 at 2:59 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Itâs this one: https://pharo.fogbugz.com/default.asp?12135 > > Ben > > On 12 Nov 2013, at 14:49, Martin Dias <tinchodias(a)gmail.com> wrote: > > I forgot to specify: in latest Pharo (30565) > > On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > I think there is some issue with TreeColumnModel. For example: > > TreeModel exampleWithCustomColumnsAndNodes > > Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" > > Should I report in fogbugz? > > thanks, > MartÃn > > On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > Yes this is what I did for the change sorter. I do not like this DSL like > way of passing block over block over block > over blocks. > > I love blocks but methods are named blocks and I prefer them. > > Stef > > biut that method can be written: > > aMenu addGroup: (MenuGroupModel new > addItem: (MenuItemModel new > name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix); > addItem: (MenuItem new > name: 'Browse Class'; > action: [ self browseSelectedObjectClass ])). > > and you do not have to declare variables for that (and is a lot better than > using a block, IMO). > > > > On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> > wrote: > > One can just use an object too. > > Itâs just that otherwise, it pollutes a bit the method with tons of inst > vars > (and then you forget to use them :P) > > Ben > > On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > It is not necessary better, but it saves you from having hundreds of temp > vars :) > > Ben > > On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Example: > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix ]. > aGroup addItem: [ :anItem | > anItem name: 'Browse Class'; > action: [ self browseSelectedObjectClass ] ] ]. > > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > > he, I thought the same :) > > > Stef > > > > > > > >

Nov. 12, 2013

[update 3.0] #30567

by StÃ©phane Ducasse

30567 ----- - Issue: 12137 Temporary variables are not added properly https://pharo.fogbugz.com/f/cases/12137/Temporary-variables-are-not-added-p… Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-StephaneDuc…

Nov. 12, 2013

[pharo-project/pharo-core] d070ae: 30567

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d070aeab7951689bea06bf8630560199051ab5a9 https://github.com/pharo-project/pharo-core/commit/d070aeab7951689bea06bf86… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-12 (Tue, 12 Nov 2013) Changed paths: M OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/declareTempAndPaste_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script223.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30567.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30567 - Issue: 12137 Temporary variables are not added properly https://pharo.fogbugz.com/f/cases/12137/Temporary-variables-are-not-added-p… http://files.pharo.org/image/30/30567.zip

Nov. 12, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 12, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 12, 2013

[pharo-project/pharo-core] c0600e: 30566

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: c0600e5f2c660098f6ad0cace7fdf97b690fe7ef https://github.com/pharo-project/pharo-core/commit/c0600e5f2c660098f6ad0cac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-12 (Tue, 12 Nov 2013) Changed paths: M Morphic-Base.package/MenuMorph.class/instance/events/keyStroke_.st A Morphic-Base.package/MenuMorph.class/instance/events/recordFiltering_.st A Morphic-Base.package/MenuMorph.class/instance/filtering/getFiltering_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script222.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30566.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/SpecAdapterBindings.class/instance/initialize/initializeBindings.st M Spec-Debugger.package/SpecDebugger.class/instance/updating/updateInspectorsFromContext_.st M Spec-MorphicAdapters.package/MorphicAdapterBindings.class/instance/initialize/initializeBindings.st Log Message: ----------- 30566 - Issue: 12139 Navigating in menus https://pharo.fogbugz.com/f/cases/12139/Navigating-in-menus - Issue 12135 Missing bindings https://pharo.fogbugz.com/f/cases/12135/Missing-bindings - 12055 The Spec Debugger should not require the registered inspector to be built on Spec https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir… http://files.pharo.org/image/30/30566.zip

Nov. 12, 2013