April 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] eefc9a: 50011

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: eefc9a3c0fff623e75eb2e7077a998712d2332dd https://github.com/pharo-project/pharo-core/commit/eefc9a3c0fff623e75eb2e70… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-27 (Mon, 27 Apr 2015) Changed paths: M Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/accessing/ignoredSelectors.st R Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/accessing/severity.st M Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/running/checkMethod_.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/README.md R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/class/accessing/uniqueIdentifierName.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/definition.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/instance/accessing/category.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/instance/accessing/name.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/instance/running/checkClass_.st R Refactoring-Critics.package/RBRepeteadMethodsInTheSuperclassRule.class/instance/running/find_inSuperclassesOf_do_.st M Refactoring-Critics.package/extension/ClassTestCase/instance/testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script619.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script620.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50010.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50011.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50011 15388 RBRepeteadMethodsInTheSuperclassRule duplicates RBEquivalentSuperclassMethodsRule https://pharo.fogbugz.com/f/cases/15388 http://files.pharo.org/image/50/50011.zip

April 27, 2015

Re: [Pharo-dev] CI Still Down

by Marcus Denker

It has been restarted > On 26 Apr 2015, at 10:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Yes, sadly this needs the admins of ci.inria.fr <http://ci.inria.fr/> and it is weekend... > >> On 26 Apr 2015, at 01:05, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> >> ... since yesterday! >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/CI-Still-Down-tp4821894.html <http://forum.world.st/CI-Still-Down-tp4821894.html> >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. >> >

April 27, 2015

{ANN] TMM (Teapot, Mustache, Mongo) web application stack

by Yanni Chiu

Hi, I cleaned up and released some demo code I put together for a Smalltalk user group meeting. The code was extracted from a project Iâve been working on. It also uses Magritte3, Voyage, and ZincSSO, but thatâs too many pieces to include in the web-app-stack name I was working in Pharo3, so I took the opportunity to upgrade to Pharo4. I had no problems with Pharo4 itself, but I had some minor issues with the updated Teapot and VoyageMongo versions: - VoyageMongo - <mongoContainer> pragma is now expected on class-side, not the instance-side - Teapot - To read/parse template files on each request (which is convenient during development) I had intercepted an internal API. This API changed slightly, which needed a simple fix, but it was hard to find I also decided to use a âgitâ repository. This turned out to be one of the hardest parts, but I think it was worth the effort. To try TMM, follow the instructions at: https://github.com/yannij/TMM Enhancements are welcome, but I donât quite know how this git workflow will pan out. Iâve already got a few changes to port over: - a more integrated file upload example - an email/passwordHash stored in the User object in mongo. â Yanni

April 27, 2015

Re: [Pharo-dev] Pharo 4.0 - display

by Ben Coman

On Mon, Apr 27, 2015 at 5:16 AM, MartinW <wm(a)fastmail.fm> wrote: > recursive wrote > > This is probably already a potential known solution to the display issue > > on > > MAC Retina displays but I've just tried the latest CogVM with the Pharo > > 4.0 > > image and using Cog fixes the issue, it no longer leaves outlines of > > windows or tracers. > > No, this is just because Cog defaults to "Open in low resolution" and Pharo > VM does not. You can start Pharo VM in low resolution and then you do not > have the artefacts. This might be a short term workaround. But the goal > would be to have retina support for Pharo :) > > <http://forum.world.st/file/n4822030/Cog_low_resolution.jpg> > > > So what does "low resolution" mean in this context? Recursive68 didn't indicate that the display was pixelated. cheers -ben

April 27, 2015

Re: [Pharo-dev] Pharo 4.0 - display

by Sven Van Caekenberghe

Wow, I didn't even know this option existed ! Thanks, this seems like a very useful workaround. > On 26 Apr 2015, at 23:16, MartinW <wm(a)fastmail.fm> wrote: > > recursive wrote >> This is probably already a potential known solution to the display issue >> on >> MAC Retina displays but I've just tried the latest CogVM with the Pharo >> 4.0 >> image and using Cog fixes the issue, it no longer leaves outlines of >> windows or tracers. > > No, this is just because Cog defaults to "Open in low resolution" and Pharo > VM does not. You can start Pharo VM in low resolution and then you do not > have the artefacts. This might be a short term workaround. But the goal > would be to have retina support for Pharo :) > > <http://forum.world.st/file/n4822030/Cog_low_resolution.jpg> > > > > > -- > View this message in context: http://forum.world.st/Pharo-4-0-display-tp4821797p4822030.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 26, 2015

Re: [Pharo-dev] Pharo 4.0 - display

by MartinW

recursive wrote > This is probably already a potential known solution to the display issue > on > MAC Retina displays but I've just tried the latest CogVM with the Pharo > 4.0 > image and using Cog fixes the issue, it no longer leaves outlines of > windows or tracers. No, this is just because Cog defaults to "Open in low resolution" and Pharo VM does not. You can start Pharo VM in low resolution and then you do not have the artefacts. This might be a short term workaround. But the goal would be to have retina support for Pharo :) <http://forum.world.st/file/n4822030/Cog_low_resolution.jpg> -- View this message in context: http://forum.world.st/Pharo-4-0-display-tp4821797p4822030.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 26, 2015

[NB] NBExternalArray not working for complex types?

by Max Leske

Hi guys I have a problem with NBExternalArray. AFAICT the generated assembly should be able to handle arbitrary elements in the array (as long as they are all of the same type). The operations required to read / write an element are given by the external type specified for the collection (e.g âcharâ or âintâ). All of this works wonderfully for char, int, NBExternalAddress etc. But Iâm trying to get it working for strings. So here is the code that I would expect to work: arrayClass := NBExternalArray anonymousSubclassInitElementType: 'String'. array := arrayClass new: 1. array at: 1 put: âfoo'. array at: 1. ââ> should procude âfooâ, but produces arbitrary stringsâ I can make it work with NBExternalAddress of course but I donât want to if I can avoid it. Iâd appreciate it if someone (Nicolai?) could take a look at NBExternalArray>>emitRead / emitWrite and see if thereâs an easy solution. Especially for strings I donât think it should be too hard since all thatâs needed is already present in the string handling facilities. Cheers, Max

April 26, 2015

Re: [Pharo-dev] SystemWindow vs. StandardWindow

by stepharo

I love your state of mind. Take Pharo 30 and look at Menu API. I definitively wants to shrink it to the correct size. :) Le 26/4/15 03:51, Ben Coman a Ã©crit : > +1... > > * Outside of Pharo, I've only ever know it be called a "window title". > Never heard of "window label". A "label" would be for panes, tabs > and widgets within the window. > > * Historical context + implementor-count... > * StandardWindow>>title: ~2006 +25-most-window-related > * StandardWindow>>title ~2006 +170 (most return constant > strings - window related?) > * SystemWindow>>label ~1998 +370-many-unrelated-to-windows > * SystemWindow>>setLabel: ~2011 +1 > > * Not sure how useful it is, but I compiled a table for comparison > https://docs.google.com/spreadsheets/d/1YvMgH8uSbOsSf30T7lyaCCcnDLy4tzXnM39… > > * Would need to consider the 8 methods of SystemWindow "label" protocol > > * One random observation > EyeCollectionInspector>>title and EyeCollectionInspector-class>>label > > cheers -ben > > > On Fri, Apr 24, 2015 at 10:53 PM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Is this distinction necessary? > > I started digging when I noticed that SystemWindow>>#label and > #setLabel: > becomes StandardWindow>>#title and #title. Wouldn't it be better > to just > push #title up if we like that API better? It's exhausting to > manage all > these tiny (and possibly unnecessary) differences... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/SystemWindow-vs-StandardWindow-tp4821655.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 26, 2015

Re: [Pharo-dev] brickValue: in Glamour-Morphic-Brick

by stepharo

> > Not really, it is implemented also in Object. > It is used to script brick layout properties. So user can say: > > brick height: 10. > brick height: #approximate. brick height: [ :b | b width * 2]. while I can see that this too cases are similar, sending value to any object is always to me over polymorphism. If we could not extend Object, the provider could simply add value in his class? We are always trying to remove messages from Object. > or even > > brick height: HeightStrategy new. > > so brickValue: is sent to any kind of object that is used as height. > So without changing brick itself user can implement its own class and > override brickValue: and have custom strategy to calculate height. > > Such practice is used in many places in brick. > > > > Cheers, > Alex > > On Sun, Apr 26, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > Can we remove #brickValue: ? > I don't see how this is different from #cull: > And the name is strange, I don't see how this depends an a brick. > > nicolai > >

April 26, 2015

Re: [Pharo-dev] Pharo configurations via git unloadable behind proxy

by Thierry Goubier

Le 26 avr. 2015 16:50, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > Pharo only knows about HTTP proxies, not proxies for any other protocol. In uko's example, protocol is filetree over http (github URLs). I would suggest trying to set the proxy inside pharo. Thierry > > > On 26 Apr 2015, at 16:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > > >> > >> Am 26.04.2015 um 16:36 schrieb Max Leske <maxleske(a)gmail.com>: > >> > >> > >>> On 26 Apr 2015, at 15:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > >>> > >>> Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. > >>> Do I miss a configuration for git? > >> > >> What exactly fails? Do you get an exception? Is it a connection problem? > > The contents of downloaded files (eg. github-UkoQualityAssistantv041531859342567419945494505101053.zip) is > > just > > > > <HTML></HTML> > > > > and thus decompressing fails. > > This problem is reproducible behind a proxy and works without a proxy. Other configurations (e.g. NoCSV) work properly behind the proxy. > >

April 26, 2015