August 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12074

by StÃ©phane Ducasse

12074 ----- - Issue 2169: FileDirectory>>matchingEntries: criteria is broken. Thanks CarloTeixeira. - Issue 2738: Browse instance/?/class button should provide fly by help. Thanks Torsten Bergmann. - Issue 1068: Mac: Quit from host menu not working anymore. Thanks Mike Roberts. - Issue 2721: Extending SUnit to emit announcement. Thanks Alexandre Bergel Thanks. I like all the discussions we have to produce a better system. Stef

Aug. 3, 2010

[Pharo-project] Telling the OS that the VM wants focus

by Max Leske

Hi folks The project I'm currently working on requires that I have to wait frequently for computations / operations to complete. To control the status I used progress bars wherever possible. Now, since the operations might take several minutes I like to sometimes switch to another Desktop, maybe read an e-mail or an article. I'd find it rather useful if the OS would notify me that the VM needs my attention as soon as the operations have completed or if there was an error during execution, so that I don't have to go and check every 30 seconds. Is there an existing way to do this? If not, I'd like to propose this as a feature for a future release (although I don't have an inkling how one would accomplish this...). Cheers, Max

Aug. 3, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Nick Ager

2010/8/3 laurent laffont <laurent.laffont(a)gmail.com> > On Mon, Aug 2, 2010 at 9:50 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> with the experience around the XMLRPC project, ESUG wants to change >> strategy to help growing business at the technical >> level. So what are the key areas where you think that effort should be >> supported to help you making business in smalltalk? > > Libraries Make connecting to C libraries/Java libraries as plainless as possible. Make discovery of available Smalltalk libraries less painful: * There's little or no differentiation on squeaksource between great, well-tested reliable code, and "my first Smalltalk project" * Be great if ESUG sponsored the infrastructure for something like Apache commons (http://commons.apache.org/) for Smalltalk projects. They have three designations: 1) Commons Proper - repository of reusable components 2) Commons Sandbox - workspace for component development 3) Repository of sandbox components that are currently inactive * This would aid in the discovery of projects. * Ideally projects in the equivalent to "commons proper" would be part of a CI system like Lukas' Hudson setup (http://hudson.lukas-renggli.ch/) HTH Nick

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by Lukas Renggli

> Lukas, that doesn't seem right, as I had to do it manually and it seems to > work fine in my code (maybe it wasn't clear what Â was trying to extract)? Sorry, I misread your mail. I thought you talked about 'extract to method', not 'extract to temporary'. > nextEditorCharacter := (editor text at: editor startIndex ifAbsent: [nil ]). > (opposite = aCharacter and: [ nextEditorCharacer = aCharacter ]) ifTrue: > [.... > > I should have been able to select the expression 'editor text at: editor > startIndex ifAbsent: [nil ])' and use the extract temporary menu item to get > the above. > > In fact, it looks like if you select it from right to left then sometimes it > un-disables that source menu item (but not always)? Or if I select it left > to right as well as the space at the end of the expression? I don't see that difference with the space, but it is true that you need to select a valid expression to get the menu items enabled. In that regard, the conditions could probably be relaxed a bit. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 3, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by laurent laffont

On Mon, Aug 2, 2010 at 9:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > with the experience around the XMLRPC project, ESUG wants to change > strategy to help growing business at the technical > level. So what are the key areas where you think that effort should be > supported to help you making business in smalltalk? > I would prefer: What kind of powerful task should be made easy out of the box ? - connect to a legacy MySQL database, send SQL requests and manipulate results - describe relations (a Library has many Books and Subscribers) -> generate -> Seaside (and/or Iliad or desktop) / view / controllers / models / database automatically setup. Plug in custom relations. - build an UI and create custom widgets. - deploy desktop and/or web app. and showcases + documentation. So Pharo can attracts new developpers who can say "wooww, so easy !". More developpers -> more business needs -> more contributions. Laurent > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 3, 2010

Re: [Pharo-project] Problem with InstructionPrinter?

by Levente Uzonyi

On Tue, 3 Aug 2010, James Ladd wrote: > > Hi All, > > InstructionPrinter printInstructionsOn: doesnt print anything for variable accessor methods. > Is this correct and expected? > > I have a class with an instance variable called 'first' and I have a method called 'first' > which simply answers the instance variable. > > first > ^ first > > When I dump the bytecode for this I get nothing. > > However, when I add the following to the method the result is as expect, ie: > the instance variable is answered. > > first > |x| > x := 1. > ^ first > > 13 <76> pushConstant: 1 > > 14 <68> popIntoTemp: 0 > 15 <00> pushRcvr: 0 > > 16 <7C> returnTop > > Why is there no bytecode for the simpler case? Because there are special primitives for that. Try this: String streamContents: [ :stream | (YourClass >> #first) longPrintOn: stream indent: 0 ]. Levente > > Rgs, James. >

Aug. 3, 2010

[Pharo-project] Problem with InstructionPrinter?

by James Ladd

Hi All, InstructionPrinter printInstructionsOn: doesnt print anything for variable accessor methods. Is this correct and expected? I have a class with an instance variable called 'first' and I have a method called 'first' which simply answers the instance variable. first ^ first When I dump the bytecode for this I get nothing. However, when I add the following to the method the result is as expect, ie: the instance variable is answered. first |x| x := 1. ^ first 13 <76> pushConstant: 1 14 <68> popIntoTemp: 0 15 <00> pushRcvr: 0 16 <7C> returnTop Why is there no bytecode for the simpler case? Rgs, James.

Aug. 3, 2010

Re: [Pharo-project] Limitation of number os literals in a method?

by Igor Stasenko

If performance is not a problem , then you could wrap things in one array, like: array := #( ( #selector1 arg1 arg2 arg3) ( #selector2 arg1 arg2 arg3) ( #selector3 arg1 arg2 arg3) ( #selector4 arg1 arg2 arg3) ... ) then in compiled method you'll have only a single literal - and outer array, and everything else will sit within it: array do: [:msg | container perform: msg first withArguments: msg allButFirst ] -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2010

Re: [Pharo-project] About overlapping packages :(

by Igor Stasenko

Potentially, user could state explicitly to which package belongs given class/method, ignoring all naming stuff. An alternative approach is to disentangle the category name from package name and matching logic. Instead of ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects' change it to: ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Objects' package: 'Kernel' or as separate doit: !ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Objects'.! !Object package: 'Kernel'.! On 2 August 2010 10:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 1, 2010, at 10:40 PM, Tudor Girba wrote: > >> Hi Stef, >> >> I would go for first mirroring categories. Like this, Monticello would still work as expected, and we can just focus on improving the image based tools/concepts. > > > I know this is why I'm doing it slowly and with some pain... :) > >> >> Cheers, >> Doru >> >> >> On 1 Aug 2010, at 22:02, StÃ©phane Ducasse wrote: >> >>> >>> >>>> Stef, >>>> >>>> Are you perhaps running into problems with mapping category names to packages? Â The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. Â The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. Â I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. Â They got so many things *really* right that I default to trusting them. >>> >>> This is what my implementation does. No magic matching. Just a list of classes and methods. >>> Now if I do not support the * convention of packageinfo it means that we will not be able to load and save >>> packages in a compatible form. We could do that and it would save me a lot of work. But people have to agree and understand the >>> consequences. Of course we could do a MCPackageInfor specific loader that loads and convert MC packages. >>> But this means that the packages will not be able to be used in Squeak. >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Sometimes the best solution is not the best solution." >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by Tim Mackinnon

Lukas, that doesn't seem right, as I had to do it manually and it seems to work fine in my code (maybe it wasn't clear what was trying to extract)? - e.g. nextEditorCharacter := (editor text at: editor startIndex ifAbsent: [nil ]). (opposite = aCharacter and: [ nextEditorCharacer = aCharacter ]) ifTrue: [.... I should have been able to select the expression 'editor text at: editor startIndex ifAbsent: [nil ])' and use the extract temporary menu item to get the above. In fact, it looks like if you select it from right to left then sometimes it un-disables that source menu item (but not always)? Or if I select it left to right as well as the space at the end of the expression? Something seems amiss somewhere. Tim On 2 Aug 2010, at 14:34, Lukas Renggli wrote: > On 2 August 2010 15:13, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >> I was having a look at some of the ecompletion code - and noticed >> that I >> couldn't do an extract to temporary refactoring because the >> refactor source >> method is grayed out? >> >> This looks like a bug - and I'm happy to report it - but just >> wanted to >> check with people here. >> >> The code fragment in question is: >> >> (opposite = aCharacter and: [ (editor text at: editor startIndex >> ifAbsent: [ >> nil ]) = aCharacter ]) ifTrue: [ >> editor selectFrom: editor startIndex + 1 to: editor >> startIndex. >> self invalidateEditorMorph. >> ^ true ]. >> >> If I hilite the expresion (editor.... nil]) inside the and: block >> its grayed >> out? I should be able to extract a temp for that code shouldn't I? > > No, that's not a bug. For obvious reasons you cannot extract > expressions with a return inside. > > Lukas > > -- > Lukas Renggli > 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

Aug. 2, 2010