February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] Object>>is:

by StÃ©phane Ducasse

I can understand your position. I do not have strong opinion on that and indeed I would like to avoid that this is becoming handy to do isKindOf: so may be we should remove is: Stef On Feb 11, 2011, at 9:56 PM, Colin Putney wrote: > On Thu, Feb 10, 2011 at 5:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Just yesterday i had discussion about this with people in the lab. I >> can't say that i heard something new regarding this, >> and not saying that i'd like to resurrect the discussion. >> So, in short: there was no objection concerning getting rid of isXXX >> in favor of using #is: method. >> The only thing which still looks controversial is too simple default >> implementation which answers false. > > No so. I think #is: is a terrible idea, and I object to it on those > grounds. I only object to the default implementation because it's the > thin edge of the wedge which invites people to use an anti-pattern. > > Colin >

Feb. 12, 2011

Re: [Pharo-project] ConfigurationOfGlorpDBX

by StÃ©phane Ducasse

Hi sven A message to people :) If you extend a core package with a method that you think should be in core please say it, open a bug entry, and tell us. Stef On Feb 12, 2011, at 10:15 AM, Sven Van Caekenberghe wrote: > Hi, > > While switching to Pharo 1.2 (starting from the Seaside CI build), I loaded ConfigurationOfGlorpDBX. This worked fine (after also loading PostgresV2 in my case and setting some defaults). So thanks a lot to whoever maintained the configs and packages. > > However, the Compiler package in now dirty in Monticello: > > Scanner>>#xLetter > BlockNode>>#arguments > > The first one comes from ConfigurationOfGlorpDBX>>#loadUnderscoreFix (if this is really needed, for Glorp SQL table/method names ?, could this not be put in its own package or could Pharo support this out of the box, maybe with a preference ?). > > The second one seems to come from Mocketry (Core). > > Anyway, this is not something that I cannot live without, it is just that I like Monticello to be clean, especially for core packages. > > Sven > >

Feb. 12, 2011

Re: [Pharo-project] List weekly digest

by Sven Van Caekenberghe

On 12 Feb 2011, at 10:08, StÃ©phane Ducasse wrote: > excellent > Francois if we could have this summary weekly it would be a **huge** contribution to the community. > I know that adrian, geert, sean and dmitri were talking about a blog on pharo-project so I imgaine that you could join efforts. This is indeed a great and very useful initiative, but it will require quite some effort, preferrably by multiple people, to keep this up. Sven

Feb. 12, 2011

[Pharo-project] ConfigurationOfGlorpDBX

by Sven Van Caekenberghe

Hi, While switching to Pharo 1.2 (starting from the Seaside CI build), I loaded ConfigurationOfGlorpDBX. This worked fine (after also loading PostgresV2 in my case and setting some defaults). So thanks a lot to whoever maintained the configs and packages. However, the Compiler package in now dirty in Monticello: Scanner>>#xLetter BlockNode>>#arguments The first one comes from ConfigurationOfGlorpDBX>>#loadUnderscoreFix (if this is really needed, for Glorp SQL table/method names ?, could this not be put in its own package or could Pharo support this out of the box, maybe with a preference ?). The second one seems to come from Mocketry (Core). Anyway, this is not something that I cannot live without, it is just that I like Monticello to be clean, especially for core packages. Sven

Feb. 12, 2011

[Pharo-project] Issue 3698 in pharo: removing caseOf:

by pharo＠googlecode.com

Status: Fixed Owner: stephane...(a)gmail.com CC: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3698 by stephane...(a)gmail.com: removing caseOf: http://code.google.com/p/pharo/issues/detail?id=3698 Hi guys let us do another pass at cleaning and realigning the system. Could we agree to deprecate caseOf: and caseOf:otherwise:? it will simply the compiler, decompiler and also we do not need that at all. | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z => "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. z detect: [:each | each key value = #b] " there is one user which I fixing right now. Stef Attachments: case.3.cs 12.7 KB

Feb. 12, 2011

[Pharo-project] Issue 3697 in pharo: UI Enhancements

by pharo＠googlecode.com

Status: Fixed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3697 by stephane...(a)gmail.com: UI Enhancements http://code.google.com/p/pharo/issues/detail?id=3697 Shift-click for PluggableListMorphOfMany. Not Perfect but better than nothing. Have a play (e.g. Select Classes from the finder tool). Some adjustments for Theme/builder label groups to be more flexible (takes the vResizing of individual rows into account (the control rather than the label for each). Removes the spaceFill ("spread") variant that was less flexible. Attachments: MultiListShiftEnhanchement.1.cs 1.4 KB LabelGroupImprovements.1.cs 14.0 KB DialogItemsChooserTweak.1.cs 8.1 KB

Feb. 12, 2011

Re: [Pharo-project] List weekly digest

by StÃ©phane Ducasse

excellent Francois if we could have this summary weekly it would be a **huge** contribution to the community. I know that adrian, geert, sean and dmitri were talking about a blog on pharo-project so I imgaine that you could join efforts. Stef > Hi, > > I've posted a small digest of past week activity in the Pharo-Project ML. I find it difficult to follow the pace of this list so I hope it will be useful to some of you. I will try to post an update every week. > > Feedback/critics are more than welcome :) > > Francois > > [ http://articles.tulipemoutarde.be/this-week-in-the-pharo-project-mailing-li… ] >

Feb. 12, 2011

Re: [Pharo-project] Hudson and Squeaksource statistics

by StÃ©phane Ducasse

> See www.squeaksource.com: >>> "Most Downloads: Pharo, Seaside, Seaside 3.0, Moose, ..." >>> >>> Side effect of the Hudson builds ;) >> >> Hm, maybe this is the cause of the recent performance problems of >> squeaksource.com. > > Each Hudson job retains its own package-cache directory, which is symbolically linked for each build cycle. Only newer .mcz's need to be downloaded for each build cycle. Good to know. We should pay attention that these caches are not flushed.

Feb. 12, 2011

Re: [Pharo-project] A new GUI visual designer

by StÃ©phane Ducasse

I was rereading that and I will take me time to deeply understand the table. > Had you read the Wiki, you would know. > âconvenient, lightweight and thread-safe callbacksâ > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki…

Feb. 12, 2011

Re: [Pharo-project] A new GUI visual designer

by StÃ©phane Ducasse

Hi marcel thanks for this post > > Hi. > > I wrote these Widgets and the Morphic Designer mostly from scratch. There is > almost no stacking of libraries. ;) Good news. Now do they replace in functionality existing ones? I mean - do they are new? - can/should they replace existing ones? - in such a case are the API compatible? > Widgets need Signals and Animations which I also wrote from scratch and > which do not have any dependencies other than Squeak 4.1 and later. I saw that but did not get the time to look deeply in the code. > > For now, I reused: > > - PluggableTextMorph > - TextMorphForEditView > - ScrollBar > - ScrollPane > > These I plan to replace them with new ones as well. > > The code itself is http://www.opensource.org/licenses/mit-license.php MIT > licensed as stated > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki > here . > > I did the whole thing, because I did not like, how the classic tool builder > works or how pluggable morphs are meant to be used. I'm too bad with UI to access that. I know that this is not really good. So I would be happy to get a better solution. Alain if you have some **cough** *cough** time can you have a look at this project? > > Signals could definitely be integrated into Squeak (trunk) because I fixed > the last serious bugs back in the last months as I worked with signals in > several projects in a productive way. > > Obviously, I adapted the API and some great ideas of the > http://qt.nokia.com/ Nokia/Qt Framework . So you could say that some widgets > or the signals are just a port from C++ to Squeak. There shouldn't be any > licensing issues. > > All widgets use several icon packages that are also meant to be used for > community purposes and reflect the correct license at source code level just > now: > > > applicationCascadeIcon >> "Auto-generated. >> >> Silk Icons >> Â© 2005-2006 Mark James >> Website: http://www.famfamfam.com >> License: http://creativecommons.org/licenses/by/2.5" >> >> ^ Icons >> at: #silkApplicationCascade >> ifAbsentPut:[ Form fromBinaryStream: (Base64MimeConverter >> mimeDecodeToBytes: self applicationCascadeIconContents readStream) ]. > > -- > View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3302461.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 12, 2011