September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Assignment operator in new core packages

by Lukas Renggli

We should actually run them every night and post the results in the list :-) Lukas 2009/9/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > lukas implemented a smallLint rule that convert all the code. We run > it in the past and we should run it again. > > stef > > On Sep 30, 2009, at 11:04 AM, Peter Hugosson-Miller wrote: > >> Isn't there a test case for this, or similar coding customs? In my >> day job we have some, and they are most useful for detecting misses >> like that. >> >> If anyone thinks it's a good idea I could write one, then this kind >> of problem shouldn't turn up again the future. >> >> -- >> Cheers, >> Peter >> >> 2009/9/30 Torsten Bergmann <astares(a)gmx.de> >> Classes like "SHA1" (now included in core) use _ again instead >> of := >> >> Shouldnt we clean up such packages? >> >> Thx >> T. >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 30, 2009

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by StÃ©phane Ducasse

I agree with andreas point. :) Begin forwarded message: > From: codesite-noreply(a)google.com > Date: September 29, 2009 6:31:41 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Issue 1129 in pharo: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > > > Comment #22 on issue 1129 by andreas.raab: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > http://code.google.com/p/pharo/issues/detail?id=1129 > > I'll give it one last shot: From my perspective, the problem is not > how difficult it > is to fix it, the problem is that there is a change in semantics of > a widely deployed > method that affects every single place that uses it. I could follow > your reasoning > more easily if the situation where such that for 80% of the users > everything stays > the same but the change you are proposing necessitates that every > single place that > uses these methods needs to be changed. And not being able to tell > whether a > particular place has been fixed or not is just bad engineering since > you are making > it strictly harder for your users to determine whether they still > need to do > something for addressing this issue or not. That's what deprecations > are for - > telling users that there is something they need to take care of. > > I think that the change you are proposing is a decidedly bad choice > and urge you to > reconsider for the following reasons: > > 1) It is subtle breakage that creates a major and completely > unnecessary PITA for > anyone who needs to write UIManager code that works across Pharo, > Squeak, Croquet etc. > > 2) It weakens the framework. Toolbuilder is based on having the same > semantics across > platforms and UIs and this change means that the entire family of > input requests is > no longer reliable as it will behave differently between Pharo and > anything else in > existence. > > 3) The alternatives are every bit as good. The protocol complication > of using > onCancel: are minimal to non-existent (since in many cases the > ability to provide a > cancel action is what you'll want anyway) and even if that were the > case, a new > protocol that over time can be supported by other UIs would solve > that completely and > in a proper evolutionary way. > > 4) With the choice you've made, you need to touch every user of that > method anyway. > If that's true, there is no penalty for changing the protocol and it > will make > migration easier since you can simply browse for all senders of > #request: and find > those that haven't been converted yet. > > Please do consider these issues carefully. I really don't think > there is any > advantage for you or your users by introducing such a subtle breakage. > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

Sept. 30, 2009

Re: [Pharo-project] Assignment operator in new core packages

by StÃ©phane Ducasse

lukas implemented a smallLint rule that convert all the code. We run it in the past and we should run it again. stef On Sep 30, 2009, at 11:04 AM, Peter Hugosson-Miller wrote: > Isn't there a test case for this, or similar coding customs? In my > day job we have some, and they are most useful for detecting misses > like that. > > If anyone thinks it's a good idea I could write one, then this kind > of problem shouldn't turn up again the future. > > -- > Cheers, > Peter > > 2009/9/30 Torsten Bergmann <astares(a)gmx.de> > Classes like "SHA1" (now included in core) use _ again instead > of := > > Shouldnt we clean up such packages? > > Thx > T. > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2009

Re: [Pharo-project] Alien and special objects Array

by StÃ©phane Ducasse

>> > > I thought #fixTemp was for code compatibility but isn't really needed > because of real closures? this is just for backward compatibility normally the method is empty on pharo

Sept. 30, 2009

Re: [Pharo-project] tabs with icons?

by Gary Chambers

TabGroupMorph/TabSelectorMorph support arbitrary morphs as well as text labels. An example: |dialog| dialog := (UITheme builder newPluggableDialogWindow: 'Example tabs') useDefaultOKButton. dialog contentMorph: ( dialog newTabGroup: { (dialog newRow: {dialog newImage: MenuIcons smallFindIcon. dialog newLabel: 'Page 1'})-> dialog newPanel. 'Page 2'->dialog newPanel}). dialog model: nil. World openModal: dialog Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 29, 2009 10:01 PM Subject: [Pharo-project] tabs with icons? > Hi, > > In Glamour we are using a TabGroupMorph (actually we use a subclass > that specifies LazyTabs). The question is if there is a way to add an > icon instead of a string? > > Or perhaps is there another solution for a tab control that allows for > icons in the tabs? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2009

Re: [Pharo-project] Quickly browse through large repositories

by Damien Cassou

http://code.google.com/p/pharo/issues/detail?id=1256 On Wed, Sep 30, 2009 at 9:05 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > When clicking on a package in a large repository the browser usually > takes ages to refresh. The following fix in the inbox fixes this > problem. > > Lukas > > Name: MonticelloGUI-lr.5 > Author: lr > Time: 30 September 2009, 9:04:31 am > UUID: fd2ef6fb-d926-49a6-a5d6-557e4218576b > Ancestors: MonticelloGUI-stephane_ducasse.4 > > - quickly browse through large repositories > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 30, 2009

Re: [Pharo-project] Assignment operator in new core packages

by Peter Hugosson-Miller

Isn't there a test case for this, or similar coding customs? In my day job we have some, and they are most useful for detecting misses like that. If anyone thinks it's a good idea I could write one, then this kind of problem shouldn't turn up again the future. -- Cheers, Peter 2009/9/30 Torsten Bergmann <astares(a)gmx.de> > Classes like "SHA1" (now included in core) use _ again instead > of := > > Shouldnt we clean up such packages? > > Thx > T. > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2009

[Pharo-project] Assignment operator in new core packages

by Torsten Bergmann

Classes like "SHA1" (now included in core) use _ again instead of := Shouldnt we clean up such packages? Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Sept. 30, 2009

Re: [Pharo-project] Alien & Squeak FFI issues on Snow Leopard.

by Andrey Larionov

I think it's related http://forums.newspeaklanguage.org/index.php?topic=88.0 On Wed, Sep 30, 2009 at 06:13, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > Someone finally managed to fire up a Sophie app http://www.opensophie.org/ > Â on Snow Leopard and immediately found an issue that also affects > Squeak users who do fascinating things with FFI > The innocent FFI call was > > apifstat: afileNo statBuffer: buffer > Â Â Â Â <cdecl: long 'fstat' (long MacStat* ) module: 'libc.dylib'> > Â Â Â Â ^self externalCallFailed > > Now it seems BEFORE Snow Leopard *somehow* the Squeak external > primitive call api which is part of the VM to assist in loading > plugins or finding function entry points in executable binaries or > libraries would > return the entry point for fstat by *somehow* finding libc.dylib which > is via Â /usr/lib/libc.dylib -> libSystem.dylib -> Â libSystem.B.dylib > > Interestingly this is found implicitly since the mac carbon vm lookup > logic never looks in /usr/lib/ > > Now in Snow Leopard it seems they do less implicit searching, perhaps > a security concern? Â Then it fails. > > In the past the Unix VM would search a hundred(sic) more places, but I > understand less today, but it might still work? Maybe /usr/lib is in > the hit list? > > This issue also applies to Alien because it calls back to the VM for > it to find the module and function entry point. > > Since I have received a request to ensure that doing an explicit full > path should be allowed in the squeak carbon macintosh vm. > Then a change would be: > > apifstat: afileNo statBuffer: buffer > Â Â Â Â <cdecl: long 'fstat' (long MacStat* ) module: '/usr/lib/libc.dylib'> > Â Â Â Â ^self externalCallFailed > > I'll look at doing this shortly. > > However the workaround is to go to Sophie.app/Contents/Resources > and do a ln -s /usr/lib/libc.dylib libc.dylib > to create a symbolic link in the Resources directory for libc.dylib > since we do explicitly look for libc.dylib in the Resources directory. > > Obviously if you have a FFI call like above where you are calling a > system library Oracle? for example. > You might find it no longer works with Snow Leopard on the Macintosh, > so you should check. > > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2009

[Pharo-project] Quickly browse through large repositories

by Lukas Renggli

When clicking on a package in a large repository the browser usually takes ages to refresh. The following fix in the inbox fixes this problem. Lukas Name: MonticelloGUI-lr.5 Author: lr Time: 30 September 2009, 9:04:31 am UUID: fd2ef6fb-d926-49a6-a5d6-557e4218576b Ancestors: MonticelloGUI-stephane_ducasse.4 - quickly browse through large repositories -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 30, 2009