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

Windows VM crash with Autotest package

by Torsten Bergmann

Scenario: 1. Load fresh Pharo 2.0 (VM+image) from http://files.pharo.org/platform/Pharo2.0-win.zip 2. open Tools -> Config Browser and install "Autotest" package 3. Evaluate AutotestDashboard open. to open the autotest dashbord 4. Create a test class in Nautilus TestCase subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: '' 5. Create a test method testFoo self assert: 'hi' size = 2 and ACCEPT it => Crashes the VM Anyone able to reproduce this? Thx T.

Sept. 16, 2013

Re: [Pharo-dev] Issues trying to use NewList on Nautilus

by StÃ©phane Ducasse

Thanks nicolas! I love to read this mail :) Stef On Sep 16, 2013, at 4:18 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano Peck and Guido Chari we have been trying to address issue 11605, i.e. using NewList in Nautilus. I am still trying to finish with this task, and I have a few questions, may be somebody here can enlighten me. > > We have encountered some problems with multiple selections. First, the list has 4 ValueModels for its selected elements: selectedIndex, selectedIndexes, selectedItem, selectedItems. I would like to understand more clearly how should we use them. In particular I find difficult to bring the plural versions and the singular versions together. > If I select more than one element in the list, it seems that the value in the selectedItem/selectedIndex points to the last one I clicked. But then the model in Nautilus is receiving two updates, one from selectedItem/Index and the other from selectedItems/indexes, should we just ignore the singular one or what? > > Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this? > > > Finally, another question not related to multiple selections. > The old list (it was a PluggableIconListMorph) has a "searchedElement" attribute. Looking at the categories list in Nautilus, the usage is so: if you have not selected any category (i.e. you are seeing the method of all categories in a class) and you click on a method in the method list, the searched element of the category list points to the category of the selected method. This is different from selecting the category, because selecting the category would filter the method list. It also highlights the category in a different color. > > So, my question is, should we keep this behaviour while migrating Nautilus to new lists o not? > If the answer is yes, I would ask how to do it, because the NewList does not seem to have this feature. Should I add the searchedElement to the NewList or is there another way to achieve the same behavior? > > > > >

Sept. 16, 2013

Re: [Pharo-dev] Seaside Continuous Integration on ci.inria.fr

by StÃ©phane Ducasse

I deeply appreciate your effort and I want to thank the seaside group. Stef On Sep 16, 2013, at 11:20 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > This is a short write up on the state of Seaside on ci.inria.fr. > > After a week of work we have Metacello based builds running green at ci.inria.fr. > > Grease 1.0 and 1.1 are green on both Pharo 2.0 and 3.0 [1]. Updating Pier 3 to use the latest Grease 1.0 should fix the Pier 3 build. > > For Seaside 3.x we load the Metacello group 'CI' and run the tests in the packages matching the following regex > ((Seaside)|(Comet)|(Javascript)|(RSS)|(JQuery)|(Prototype)|(Scriptaculous))-.*. Currently we have no way of running SLint/Slime and fake Checkstyle like in [3]. If anybody knows how to do with please let us know. There are still some issues with file library in Pharo 3.0 and Seaside 3.0. They are only fixed in Seaside 3.1. > > Please try to keep the build green, otherwise we'll get spammed with emails. > > Currently we keep all the build (5GB already). Do we really need this? > > [1] https://ci.inria.fr/pharo-contribution/job/Grease/ > [2] https://ci.inria.fr/pharo-contribution/job/Seaside/ > [3] http://jenkins.lukas-renggli.ch/view/Seaside%203.1/job/Seaside%203.1/ > > Cheers > Philippe > >

Sept. 16, 2013

Re: [Pharo-dev] Understand Icons in Pharo

by StÃ©phane Ducasse

> Hi, > > Take a look at Form. > > Icons don't have a class that models them, so they're an ImageMorph > with a Form, that was either imported from externally (jpg, bmp,png ) > or stored in the image in a method. > > For examples look at ThemeIcons. > > BTW, In the past I've did an icon family importer, you could use to > automatically fetch external icons and store in the image. > > http://www.squeaksource.com/@Rob10iGjuJJag2hV/BVCvaSPt we should move it to SmalltalkHub. Stef

Sept. 16, 2013

Re: [Pharo-dev] Completion again ...

by Igor Stasenko

https://pharo.fogbugz.com/f/cases/11627/prevent-completion-from-popping-out… On 16 September 2013 17:50, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 16 September 2013 17:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> do not lose your time trying to fix that. >> We are going to change it anyway. >> >> > but i don't want to wait till your changes will come, > i want it now, so i will push the slice, and if you don't want it, just > don't integrate :) > > > >> Esteban >> >> On Sep 16, 2013, at 5:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > trying to fix completion autopopups when there is nothing to suggest >> > to prevent popping up the empty and useless menu, >> > i stumbled upon this: >> > >> > initializeInstVars >> > (clazz isNil or: [ includeVariables not ]) ifTrue: [ ^ self ]. >> > instVars := clazz allInstVarNames asSortedCollection. >> > instVars := instVars collect: >> > [ :each | NECInstVarEntry contents: each type: #instVar ]. >> > instVars add: (NECSelfEntry >> > contents: 'self' >> > type: #self). >> > instVars add: (NECSuperEntry >> > contents: 'super' >> > type: #super) >> > >> > >> > there's something sick with that.. >> > first we using >> > NECSelfEntry >> > but then, if that's not enough, >> > we pass 'self' as its contents.. >> > but that's also not enough! >> > we pass 'self' as its type as well.. >> > >> > checking many subclasses of NECEntry >> > and how they initialized, it is almost every time the same: >> > >> > - you use NECXXXXEntry , we always pass separate #XXXX >> > as its type like just using NECXXXXEntry not enough to indicate that. >> > >> > i going to fix that as well >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Sept. 16, 2013

Re: [Pharo-dev] Completion again ...

by Igor Stasenko

On 16 September 2013 17:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > do not lose your time trying to fix that. > We are going to change it anyway. > > but i don't want to wait till your changes will come, i want it now, so i will push the slice, and if you don't want it, just don't integrate :) > Esteban > > On Sep 16, 2013, at 5:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > trying to fix completion autopopups when there is nothing to suggest > > to prevent popping up the empty and useless menu, > > i stumbled upon this: > > > > initializeInstVars > > (clazz isNil or: [ includeVariables not ]) ifTrue: [ ^ self ]. > > instVars := clazz allInstVarNames asSortedCollection. > > instVars := instVars collect: > > [ :each | NECInstVarEntry contents: each type: #instVar ]. > > instVars add: (NECSelfEntry > > contents: 'self' > > type: #self). > > instVars add: (NECSuperEntry > > contents: 'super' > > type: #super) > > > > > > there's something sick with that.. > > first we using > > NECSelfEntry > > but then, if that's not enough, > > we pass 'self' as its contents.. > > but that's also not enough! > > we pass 'self' as its type as well.. > > > > checking many subclasses of NECEntry > > and how they initialized, it is almost every time the same: > > > > - you use NECXXXXEntry , we always pass separate #XXXX > > as its type like just using NECXXXXEntry not enough to indicate that. > > > > i going to fix that as well > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Sept. 16, 2013

Re: [Pharo-dev] Annotating classes

by Igor Stasenko

there's only two practical ways (which i know and use) of associating extra state per object: - internal: by extending object's state via directly adding extra instance variable (or indirectly like Morphic's properties) - external: creating a map (aka dictionary) which maps between your domain object(s) and its corresponding extra state. i do not see how classes (like any other object) is exception from that. On 13 September 2013 09:40, kilon <thekilon(a)yahoo.co.uk> wrote: > I like to hear some more details on this and other opinions too. > > One of the thing I want to work is a new SystemBrowser with more flexible > browsing system. I take inspiration from preset browsers in software > sysnthesizers. Each preset represent a sound that can be manipulated with > real time controls, the problem is that there thousands of presets the same > way there are thousands of classes. The initial implementation was to brake > presets to groups / categories , same way SystemBrowser has packages. > Unfortunately that still made browsing through presets very tedious and > long > process. > > The modern system is tag based , for example if I want to select a sound > present I a presented with a row and columns of buttons, each row is a > category of tags , each cell is a tag. For example I could choose Timbre : > metalic , Type: pad, Speed: fast, Rythm : non-rythmic etc these criterias > then would allow me to browse only a limited amount of presets having those > tags. I would have to reset the browser (which disables all tag choices) to > view all presets again. > > I am considering implementing something similar for class and even methods. > At first I was considering what Igor said, an instance variable that > contained a dictionary/hash-table associating tags with their categories > providing also a gui to set those tags easily. However I was wondering > like > the original poster if there is a better way to "annotate" classes and if > there is any way to "annotate" methods . > > > Esteban A. Maringolo wrote > > Isn't answering to a message not enough? > > > > Like #nbStruc #ormTableName etc. > > > > Pragmas are somehow orthogonal to the common message sending and method > > lookup. > > > > > > Esteban A. Maringolo > > > > > > 2013/9/12 Igor Stasenko < > > > siguctua@ > > > > > > > >> > >> > >> > >> On 12 September 2013 13:56, Torsten Bergmann < > > > astares@ > > > > wrote: > >> > >>> We can mark methods with pragmas and ask the pragma collector > >>> to give the methods marked with it. > >>> > >>> Do we (already) have some kind of pragma like mechanism to annotate > >>> classes? I mean a general mechanism that one can use to mark classes > >>> with pragmas/settings/ ...? > >>> > >>> There are various scenarios where this might be useful: > >>> - an ORM mapper would like to associate a persistence class with a > >>> table name > >>> - an NBExternalStructure subclass wrapping a structure can be > >>> annotated > >>> with > >>> the original struct name > >>> - ... > >>> > >>> > >> Why so complicated (e.g. pragmas) ? Just add one more inst var , like > >> 'annotation' for Class object > >> and you have it. > >> > >> > >>> Thx > >>> T. > >>> > >>> > >>> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > View this message in context: > http://forum.world.st/Annotating-classes-tp4707854p4708033.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Sept. 16, 2013

Re: [Pharo-dev] Completion again ...

by Esteban Lorenzano

do not lose your time trying to fix that. We are going to change it anyway. Esteban On Sep 16, 2013, at 5:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > trying to fix completion autopopups when there is nothing to suggest > to prevent popping up the empty and useless menu, > i stumbled upon this: > > initializeInstVars > (clazz isNil or: [ includeVariables not ]) ifTrue: [ ^ self ]. > instVars := clazz allInstVarNames asSortedCollection. > instVars := instVars collect: > [ :each | NECInstVarEntry contents: each type: #instVar ]. > instVars add: (NECSelfEntry > contents: 'self' > type: #self). > instVars add: (NECSuperEntry > contents: 'super' > type: #super) > > > there's something sick with that.. > first we using > NECSelfEntry > but then, if that's not enough, > we pass 'self' as its contents.. > but that's also not enough! > we pass 'self' as its type as well.. > > checking many subclasses of NECEntry > and how they initialized, it is almost every time the same: > > - you use NECXXXXEntry , we always pass separate #XXXX > as its type like just using NECXXXXEntry not enough to indicate that. > > i going to fix that as well > > -- > Best regards, > Igor Stasenko.

Sept. 16, 2013

Completion again ...

by Igor Stasenko

trying to fix completion autopopups when there is nothing to suggest to prevent popping up the empty and useless menu, i stumbled upon this: initializeInstVars (clazz isNil or: [ includeVariables not ]) ifTrue: [ ^ self ]. instVars := clazz allInstVarNames asSortedCollection. instVars := instVars collect: [ :each | NECInstVarEntry contents: each type: #instVar ]. instVars add: (NECSelfEntry contents: 'self' type: #self). instVars add: (NECSuperEntry contents: 'super' type: #super) there's something sick with that.. first we using NECSelfEntry but then, if that's not enough, we pass 'self' as its contents.. but that's also not enough! we pass 'self' as its type as well.. checking many subclasses of NECEntry and how they initialized, it is almost every time the same: - you use NECXXXXEntry , we always pass separate #XXXX as its type like just using NECXXXXEntry not enough to indicate that. i going to fix that as well -- Best regards, Igor Stasenko.

Sept. 16, 2013

Re: [Pharo-dev] [Pharo-users] Please help us by buying the book

by Alexandre Bergel

Thanks for your nice words :-) Alexandre On Sep 16, 2013, at 11:57 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Sep 2013, at 16:24, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Hi, >> >> please support our work on Pharo by buying the new Deep into Pharo book >> >> http://rmod.lille.inria.fr/deepIntoPharo/ >> >> Your money go to the Pharo Association, so it's worth it. > > Done. > > Great work, Damien, StÃ©phane, Alexandre & Jannik. > > Your effort is much appreciated. > > Sven > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2013