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

Re: [Pharo-project] Pharo for Professional Development

by Simon Denier

On 18 dÃ©c. 2009, at 13:23, Bart Gauquie wrote: > > The dev build really misses a process like the core build has with integrators. But we can not mimic this process in dev since it integrates external packages, whose developers are sometimes not concerned with Pharo. I volunteer for that. > > > That is true. However, since Pharo chooses external packages and offers them as a dev package, it is the task/responsability of Pharo initiative to make sure they work together. > > I'm extremely lazy but a huge fan of automation. Instead of clicking in Pharo manually and checking if the basic stuff is still working; why don't write a testcase which does that for you. Make a little more effort once and then just be lazy and exploit that effort afterwards. Since Pharo is dynamic, everything is an object, it is possible to test anything. One problem is that some features can only be tested through UI. Because the feature below can not be piloted outside of the UI and I dont know any framework performing automatic UI tests in Pharo. Maybe there is. Anyway, the first thing to do is to automate the launch of tests in a newly built dev image. Some people started to do that but I dont know more. > > We can create a sort of Pharo-Dev-Integration-Tests package containing a limited set of Integration tests. I will try to create a testcase for the bug I mentioned. > > > Concerning the parts that are lacking tests. We have a rule to test everything. If you want to adapt something and you find that there is no test, you write a test first for the existing functionality; make sure it runs, add extra test for new functionality, ... . You certainly write a test if a bug occurred in something. > > So you don't need to do an effort to try to test everything. If something is working untested, and you don't need to change it: why spent effort in writing tests for it? Only if you change it, you add tests for it. > > Kind Regards, > > Bart > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by laurent laffont

2009/12/18 George Herolyants <george.herolyants(a)gmail.com> > 2009/12/18 GeertClaes <geert.wl.claes(a)gmail.com>: > > George Herolyants-3 wrote: > >> > >> Though I think WhiskerBrowser still covers the above use case better. > >> Unfortunately it doesn't run on Pharo. > >> > > > > Maybe WhiskerBrowser can be created using Glamour? > > I don't now. IIRC someone on the list mentioned that Glamour can't be > used to build real browsers for now, but I may be wrong. > I wonder, if it can be done using OB? It would be cool if it was possible. > Recently I loaded it into Pharo but it relies on some missing classes > and expects some old behaviour from underlying libraries. It worked > somehow but it has some visual artefacts (for example boxes for tree > menu items are smaller than the text they contain; see in the > attachment). And of course in lacks all the cool stuff OB has. > > Cheers, > George > I've just tried Whisker on Pharo... buggy but there's some great ideas inside !! Laurent

Dec. 18, 2009

Re: [Pharo-project] Issue 1633: Object allSubInstances appears to loop forever

by StÃ©phane Ducasse

Yes I checked that too. BTW thanks - this is nice to open a bug tracker entry because like that we do not have open it just to close it. :) >>> > I think the fixed bug was the similar 'Issue 1044: MethodContext > allInstances loops forever'. Not quite the same: > > 'From Pharo1.0beta of 16 May 2008 [Latest update: #10470] on 17 October 2009 > at 4:49:35 pm'! > > !Behavior methodsFor: 'accessing instances and variables' stamp: > 'MarcusDenker 10/17/2009 16:49'! > allInstances > "Answer a collection of all current instances of the receiver." > > | all inst next | > all := OrderedCollection new. > inst := self someInstance. > [inst == nil] > whileFalse: [ > next := inst nextInstance. > inst == all ifFalse: [all add: inst]. > inst := next]. > ^ all asArray! ! > > -- > View this message in context: http://n2.nabble.com/Issue-1633-Object-allSubInstances-appears-to-loop-fore… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009

Re: [Pharo-project] [update 1.1] #11107

by StÃ©phane Ducasse

you are talking about a dream we made and this coming to be true :) >> Thanks Steph, > > lot of Preferences references remain, but not so much :) > I would like to remove them then produce a Preferences package > removable from the core an re-loadable if needed (pharo aka dev distrib > needs it). > Then documentation ...

Dec. 18, 2009

Re: [Pharo-project] [Moose-dev] MorphTreeMorph>>mouseEnter: broken in Moose

by Alain Plantec

Tudor Girba a Ã©crit : > Hi Oscar, > > Thanks for reporting. > > It looks like MorphTreeMorph moved to support Pharo 1.1 and in the > meantime it brakes in 1.0. I've checked and yes, last MorphTreeMorph from squeaksource is for 1.1. It is not using Preferences anymore. I will open a Momo1.0 project on squeaksource so that you don't have to hardcode the version in your configuration script. Thanks Alain > > Loading Morphic-MorphTreeWidget-AlainPlantec.39 solves the problem. > > I updated ConfigurationOfGlamour to hardcode the version for the > moment when loading the default configuration. > > I also released: > - Glamour version: 2.0-beta.2 > - Moose version: 4.0-beta.3 > > Cheers, > Doru

Dec. 18, 2009

Re: [Pharo-project] [update 1.1] #11107

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Thanks a lot alain this is really cool! > What a work! I imagine that now you want to rest from Preferences :) > Thanks Steph, lot of Preferences references remain, but not so much :) I would like to remove them then produce a Preferences package removable from the core an re-loadable if needed (pharo aka dev distrib needs it). Then documentation ... Alain > Stef > > On Dec 18, 2009, at 2:42 PM, Marcus Denker wrote: > > >> Issue 1627: Preferences Migration Part11 >> >> Pass 1 finished !!!! >> All core preferences are migrated. >> >> SLICE-PreferencesMigrationPart11-AlainPlantec.11 is in inbox >> >> * migrates "windows color" "keyboard" "security" "scrolling" "keyboard" >> "services" "updates" groups >> * removes WindowColorRegistry class >> * ProjectLauncher readDocumentAtStartup: is here again >> * each model specifies its preferred color for squeak ui themes with a >> #patchworkUIThemeColor method >> * added "Kernel-SystemSettings" package >> >> >> _______________________________________________ >> 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 > >

Dec. 18, 2009

Re: [Pharo-project] about sluggines on linux

by John M McIntosh

Please note this could be a problem with the Windows VM you are using. Please check with the Windows VM suport person for guidance if the numbers appear rational for the machine you are using. In general the tinybenchmark reports how good the compiler choices has optimized the main interpreter loop, or points out the inability of the Squeak VM to get 100% of the CPU when running the benchmark, or points out that the image is running lots of higher priority smalltalk process that interfere with the benchmark. But in general I would expect a Squeak image or a Pharo image to post the name numbers when using the same VM on the same machine. Obviously someone could confirm that. On 2009-12-18, at 2:28 AM, StÃ©phane Ducasse wrote: > No problem. > > >> Hi Stef, >> I dind't see your email until today, when I came back to this topic! Don't know why it was marked as read :(. >> Just to report the same test under Vista (obviously, on the same machine). >> >> '225948808 bytecodes/sec; 6804203 sends/sec' >> > > they are coherent with the previous ones. > >> '533333333 bytecodes/sec; 12157397 sends/sec' > > and clearly and indication that we should get also slower machines to kick us to optimize > or rethink certain decisions. > > Stef -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 18, 2009

Re: [Pharo-project] Rome port

by csrabak＠bol.com.br

On devel image 1.0 10502 (Windows XP SP3), I get the following in the Transcript: a MCOrganizationDefinition(#(#'Rome-BalloonCanvas'))a MCOrganizationDefinition(#(#'Rome-Base'))a MCOrganizationDefinition(#(#'Rome-PluginCanvas'))a MCOrganizationDefinition(#(#'Rome-Fonts'))a MCOrganizationDefinition(#(#'Rome-Demo'))a MCOrganizationDefinition(#(#'Rome-Reference'))a MCClassDefinition(RomePluginForm)a MCClassDefinition(RomePluginGlyphForm)a MCClassDefinition(RomePluginSourceForm)a MCClassDefinition(RomePluginTargetForm)a MCClassDefinition(RomePluginTargetFile)a MCClassDefinition(RomePluginPDFTarget)a MCClassDefinition(RomePluginPSTarget)a MCClassDefinition(RomePluginSVGTarget)a MCClassDefinition(ExtendedArray)a MCClassDefinition(RomeCanvas)a MCClassDefinition(RomePluginCanvas)a MCClassDefinition(RomeReferenceCanvas)a MCClassDefinition(RomeBalloonCanvas) RomeReferenceCanvas>>string:from:to: (OffsetTransform is Undeclared) RomeReferenceCanvas>>translateBy: (OffsetTransform is Undeclared) a MCClassDefinition(RomeClipshape)a MCClassDefinition(RomeDemo)a MCClassDefinition(RomeFill)a MCClassDefinition(RomeFont)a MCClassDefinition(RomeFreetypeFont)a MCClassDefinition(RomeFontFamily)a MCClassDefinition(RomeFontManager)a MCClassDefinition(RomeFontManagerHandle)a MCClassDefinition(RomeFreeTypeFileInfo)a MCClassDefinition(RomeGlyphCache)a MCClassDefinition(RomePath)a MCClassDefinition(RomeBalloonPath)a MCClassDefinition(RomePen)a MCClassDefinition(RomePolygonClipper)a MCClassDefinition(RomeFontNotFoundException) RomeReferenceCanvas>>string:from:to: (OffsetTransform is Undeclared) RomeReferenceCanvas>>translateBy: (OffsetTransform is Undeclared) I still have to find some docs so I can do any intelligent test in the loaded package!! HTH -- Cesar Rabak Em 18/12/2009 17:08, Alexandre Bergel < alexandre(a)bergel.eu > escreveu: Gofer new impara: 'RomePharo'; addPackage: 'Rome-BalloonCanvas'; addPackage: 'Rome-Base'; addPackage: 'Rome-PluginCanvas'; addPackage: 'Rome-Fonts'; addPackage: 'Rome-Demo'; addPackage: 'Rome-Reference'; load loads fine in a 10500 for me. Alexandre

Dec. 18, 2009

Re: [Pharo-project] MorphTreeMorph>>mouseEnter: broken in Moose

by Alain Plantec

Oscar Nierstrasz a Ã©crit : > I get an infinite loop of exceptions in the Moose Finder when I load Moose into the latest Pharo. > > LazyMorphTreeMorph does not understand keyboardFocusOnMouseDown ... > > What gives? > > Alain, it seems this method comes from you. What gives? I am unsure what to do ... > sorry, It seems that I've misplaced something... I vill fixe that soon Alain > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Dec. 18, 2009

Re: [Pharo-project] [ANN] MagmaBrowser

by Alexandre Bergel

> 2009/12/17 Alexandre Bergel <alexandre(a)bergel.eu>: >> Don't you have the '+' and '-' button at the top? Maybe I could >> rename >> to 'Zoom +' and 'Zoom -'. > > Now I see them. Yes, adding labels would help to get the '+' and '-' > symbols more visibility. Now in Mondrian-Alexandre_Bergel.317 Thanks for your suggestion >> What do you mean by constraints? Can you give an example of such a >> constraint? > > There is a very old ThingLab video which is the best demo I've seen: > > http://www.cs.washington.edu/research/constraints/videos/thinglab-1978.mov > http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Document… Videos are cool! Unfortunately, resizing widget is not currently supported in the Pharo version of Mondrian. All the infrastructure is there, what is missing is the morphic event management. In short, a class MOResizeElementEvent is missing. > Summarising, with constraints you say what do you want to achieve, and > not how to do it. The layout adjustement algorithm will use > constraints to achieve it. There is an implementation of constraints > solvers in Squeak called Cassowary > > http://www.squeaksource.com/Cassowary.html Thanks Alexandre >> >> On 17 Dec 2009, at 21:44, HernÃ¡n Morales Durand wrote: >> >>> Hi Alex, >>> I've tried the Mondrian script, nice work, it looks something I >>> could integrate to the Dependency Browser. Does Mondrian support >>> zooming? Do you plan to use constraints for the layout? >>> Cheers, >>> >>> HernÃ¡n >>> >>> 2009/12/17 Alexandre Bergel <alexandre(a)bergel.eu>: >>>> The UML visualization is not lost however. >>>> >>>> Doit the following to load Mondrian: >>>> Gofer new squeaksource: 'Mondrian'; addPackage: >>>> 'ConfigurationOfMondrian'; load. (Smalltalk at: >>>> #ConfigurationOfMondrian) perform: #loadLastStable. >>>> >>>> and then: >>>> MOReadme new umlFor: MOShape withAllSubclasses >>>> >>>> You will have a simple uml view that shows hierarchy of MOShape. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On 17 Dec 2009, at 13:28, Torsten Bergmann wrote: >>>> >>>>> Back in "the good old Pharo days" (TM) we had a >>>>> >>>>> ScriptLoader loadSuperOB >>>>> >>>>> and I remember this browser already providing a >>>>> UML class diagram when you selected a class in >>>>> the browser ... >>>>> >>>>> Bye >>>>> T. >>>>> >>>>> >>>>> -- >>>>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >>>>> Firefox 3.5 - >>>>> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 18, 2009