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

[Pharo-project] assert:includes

by Daniel P Zepeda

Greetings, I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not. So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes: Here is the test: testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed if I simply put parens around the argument to assert: like this: assert: (mom refreshed children includes: kid refreshed) it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here? Thanks! DZ

Aug. 17, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

Henry, I'm impressed - that sure sounds like my situation. Do you know what to do about it? :) This is another situation when it would be nice to have the errors appended to the log vs. replacing the file contents. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, August 17, 2009 3:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote: > 2009/8/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> Two UI processes polling for input is probably what has happened. >> I should give some attention to how Dolphin prevents that. Two >> things that come to mind are raising the priority of a new UI thread >> to create a modal event loop, and (which Pharo almost certainly does >> too) starting a new UI thread when needed. >> >> My TimedEvaluator class has headless and "with progres" >> subclasses. The latter will need some porting, and perhaps the >> headless one should simply block, or at least do so in Pharo. >> >> Terminating the UI thread seems a little harsh, but that might be >> what is needed. > > Sure it is what debugger does when you closing its window - it > terminating the process you currently debugging. Nothing harsh or > wrong and nothing to worry about (usually). :) > >> Another option might be to suspend the old UI thread, start the new >> one, and then undo the damage at the end. > > There are is a little damage which is done when you doing that - > mainly the event which is currently handled is lost, but since your > intent to terminate the current process, as a result of event > handling, nothing wrong with it. As for the rest , when you start a > new UI process everything continues to work normally. I don't know if you remember, but there was a DNU bug some months ago (probably) caused by 2 UI-processes being active for a short period of time, one nilling mouse state after the other had initiated mouse handling. At least that was the only explanation I could come up with,nobody replied whether the scenario I described was actually possible :) http://n2.nabble.com/-ANN--MouseOverHandler-refactoring-td3068941.html#a309… Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] swapMouseButtons

by StÃ©phane Ducasse

I do not know I thought it works. I will let linux people check and reply Stef On Aug 17, 2009, at 6:12 AM, Philippe Marschall wrote: > Hi > > What happened to the swapMouseButtons preference? On Linux the middle > and right mouse button are wrong. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] [Fix] Call initialsPerSe in isHarvester

by Alexandre Bergel

The problem disappeared for some reason. Alexandre On 14 Aug 2009, at 18:38, StÃ©phane Ducasse wrote: > Strange > are you sure that you really get the latest version ? > > Stef > > On Aug 14, 2009, at 5:25 PM, Alexandre Bergel wrote: > >> Ah sorry. I checked on google code for "initialsPerSe" and >> "fullNamePerSe" and I could not find it. Moreover, I did an update >> yesterday and I still had the error. >> >> Cheers, >> Alexandre >> >> >> On 14 Aug 2009, at 11:13, Adrian Lienhard wrote: >> >>> This is already fixed (see my mail from this morning regarding issue >>> #1069). >>> >>> Cheers, >>> Adrian >>> >>> On Aug 14, 2009, at 17:01 , Alexandre Bergel wrote: >>> >>>> Issue #1070 >>>> initialsPerSe is a deprecated method. When opening an image, a >>>> deprecated error shows up. "Author uniqueInstance fullNamePerSe" >>>> should be used in instead. The following .cs fixes this. >>>> >>>> On google code >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 17, 2009

Re: [Pharo-project] Help on Polymorph [was How to build a GUI]

by Alexandre Bergel

> would be nice to save a script and its png. .png can be easily produced. Just send exportAsPNG to a MOCanvas. This can be done using an inspector. I need to add an entry in the menu. > Now can you have use relationships? Yes, but they need to be defined manually. Alexandre > > On Aug 14, 2009, at 4:53 PM, Alexandre Bergel wrote: > >>>> Is DrDoc on SqueakSource? I'll take a look. >>> >>> Yes I would be more than happy if someone could take the lead there. >>> I could embed images (UML diagram). >> >> It could maybe be used with Mondrian :-) >> >> Alexandre >> >> >>> >>> >>> >>>> >>>> - Brian >>>> >>>> >>>> >>>>> >>>>> Stef >>>>> >>>>>>> So far we should invent it. >>>>>>> And I totally agree with you. If people do not see the good doc >>>>>>> they >>>>>>> will not write good comment. >>>>>>> I started to work on DrDoc a kind of package meta data to add >>>>>>> documentation to a package but it got stole >>>>>>> I should push that again. What would be nice is to take one >>>>>>> package >>>>>>> and do it well as an example. >>>>>>> >>>>>>> >>>>>>> It think it should be possible to write documentation at the >>>>>>> package level. So developpers have a place where they can write >>>>>>> an >>>>>>> overview of their package. When we click on a package, >>>>>>> documentation should be displayed by default or easily. >>>>>> >>>>>> Yes! Here is a post I made in April of 2003: >>>>>> >>>>>> >>>>>>> The biggest frustration with using comments is that there is no >>>>>>> good >>>>>>> "starting place" for a given class category. For example, go >>>>>>> browse >>>>>>> the Seaside classes and categories and figure out where one >>>>>>> should >>>>>>> start. You can repeat this exercise for any number of >>>>>>> categories. I >>>>>>> propose that we we add a documentation attribute to the >>>>>>> PackageInfo >>>>>>> stuff, so there is a category level documentation spot, with >>>>>>> links >>>>>> to >>>>>>> the appropriate class comments. >>>>>> >>>>>>> Any thoughts? >>>>>> I didn't get any response, and I sent a similar type of thought >>>>>> to >>>>>> Stef recently, but he's so busy I don't even know if he read my >>>>>> email :) >>>>>> >>>>>> - Brian >>>>>>> >>>>>>> In the rubygems world, it is a common practice to write >>>>>>> documentation in a README file which is displayed by RDoc on >>>>>>> startup page (github works the same way). It seems to me that >>>>>>> there's the same level of comment between Ruby class/methods and >>>>>>> Pharo. The documentation at the package level may be the >>>>>>> difference. >>>>>>> >>>>>>> Python has a real documentation effort.Each release come with >>>>>>> its >>>>>>> up to date documentation. It's a release criteria. Python shares >>>>>>> some similarities with Pharo as they both have "batteries >>>>>>> included". May be there should have a process to contribute to a >>>>>>> centralized Pharo documentation which can be accessed within the >>>>>>> IDE. >>>>>>> >>>>>>> Laurent. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 17, 2009

[Pharo-project] for noncore but close packages: morphic extras and sound

by StÃ©phane Ducasse

> > > Hi guys > > since we need nice morphic examples and also sound support. > > I propose that we do the following: > Pharo-core does not have them > Pharo has them (now I will do a pass and select from Morphic Extra > the nice examples that were there and let the rest aside). > > This will help for the book we are finishing to write. > Then in 1.1 we should put in place a process to be able to manage > noncore but close packages. > > Stef > > >

Aug. 17, 2009

[Pharo-project] SequenceableCollection do: causes GCs with closure bytecodes

by Henrik Johansen

Something I noticed when looking at ByteArray>>hex, anyone know the reason why there's GC going on in do: with closure images, but not using the old bytecodes? Even with no closed-over variables in the block, it seems it creates extra fodder for the Garbage collector... Is it something the stack VM / Improved Garbage Collector will change? Cheers, Henry Simple test: intArray := (1 to: 10000000) asArray. TimeProfileBrowser onBlock: [intArray do: [:ix | ix yourself]] (It's not due to sampling overhead, Time millisecondsToRun: return similiar runtimes) Without closures (I used 250): -941 tallies, 965 msec. **GCs** incr 4 totalling 0ms With closures (I used 414): -1938 tallies, 1938 msec. **GCs** inc 2510 totalling 614ms

Aug. 17, 2009

Re: [Pharo-project] Best practices for writing data to disk.

by StÃ©phane Ducasse

for simple matter you can use storeOn:/ readFrom protocol store one element per line and use readFrom: one each line to load back On Aug 17, 2009, at 12:49 PM, John Escobedo wrote: > I'm having trouble finding out if classic squeak methods work in > this case. > > Can anyone recommend a best practice if I have an object that holds a > large, procedurally created, orderedCollection and I want to be able > to read/write it from a file (text or binary)? > > Specifically. I have an object called "PrimeBank", that holds a huge > set of prime numbers. Its methods can grow this set at any time. As > the set gets larger, I'd like to be able to write it out to a file and > read it in when I'm running the code on another image. > > Ideally I think I'd like the file to be human readable and editable. > > - John E. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Best practices for writing data to disk.

by csrabak＠bol.com.br

Aug. 17, 2009

Re: [Pharo-project] Call for synchronization with OB tools

by csrabak＠bol.com.br

Aug. 17, 2009