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

Re: [Pharo-project] [Metacello] Re: collecting all packages of a configuration

by Mariano Martinez Peck

On Fri, Aug 3, 2012 at 9:51 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Fri, Aug 3, 2012 at 2:12 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Mariano, >> >> Metacello is written to run on multiple Smalltalk dialects. I cannot just >> replace SystemChangeNotifier with SystemAnnouncer without considering how >> that code will affect the other platforms the Metacello runs on ... it's >> not a simple matter. >> >> > I know. My email was to show you that after a single change we have MOST > of the tests green, don't we? So it is not that broken. That's all I wanted > to show. > I know it is not easy to change. I have the same problem in Fuel for > example and how to make it work for different Pharo versions. I was > thinking the other day and maybe I will end up rewriting each: > "SystemChangeNotifier" to "FuelPortabilityLayer notifier" (the API is the > same). And then I will have subclasses of FuelPortabilityLayer for > different Pharo version...or overrides in the (already existing) > compatibility packages, not sure...using Grease is overkilling in this case > for me. > > Well, let's think together. From what I can see (let me know if it is not like that), you use SystemChangeNotifier just to make things silent. So rather than doing, for example, SystemChangeNotifier uniqueInstance doSilently: [ super runCase ] we can do [ super runCase ] valueSilently or change #doSilently to #withoutNotifications or whatever. Then we just implement those messages differently in different Pharo versions. what do you think? > > >> >> ----- Original Message ----- >> | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> >> | To: metacello(a)googlegroups.com >> | Sent: Thursday, August 2, 2012 2:44:15 PM >> | Subject: Re: [Metacello] Re: collecting all packages of a configuration >> | >> | >> | >> | >> | On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs < dhenrich(a)vmware.com >> | > wrote: >> | >> | >> | Issue 6295[2] was the first bug that shut me down and then when I >> | went to try loading Metacello again (with a new vm) I hit Issue >> | 6336[1] so I have yet to validate whether Issue 6295 is fixed or not >> | (the resolution comment is not confidence inspiring).... >> | >> | Sean hit Issue 6461[3] a week ago and it is still open... >> | >> | Mariano, you hit 6336 a couple of days ago (I just reopened it). >> | >> | And now you've hit another issue that smells an awful lot like the >> | other two issues ... that are still unresolved >> | >> | So, right now it seems that there are some serious Pharo-2.0 issues >> | with package loading independent of Metacello. >> | >> | As I said, I'll patiently wait until the base system stabilizes a bit >> | more before taking a chance that the load might work and that I >> | might get a chance to run my unit tests ... >> | >> | >> | >> | >> | This week, SystemChangeNotifier was removed. If you just change its >> | references to SystemAnnouncer in Metacello, I got the following >> | (using last Metacello version) >> | >> | >> | >> | 678 run, 667 passes, 0 expected failures, 0 failures, 11 errors, 0 >> | unexpected passes >> | Failures: >> | >> | >> | Errors: >> | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline >> | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline >> | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment >> | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment >> | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment >> | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment >> | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave >> | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave >> | MetacelloInsideToolBoxTutorialTests>>#testExamples >> | MetacelloIssue136TestCase>>#testCachedIssue136 >> | MetacelloIssue136TestCase>>#testIssue136 >> | >> | >> | >> | >> | >> | >> | BTW, does anyone know if the Metacello unit tests are run by the >> | Jenkins server against 2.0? >> | >> | Dale >> | >> | [1] http://code.google.com/p/pharo/issues/detail?id=6336 >> | [2] http://code.google.com/p/pharo/issues/detail?id=6295 >> | [3] http://code.google.com/p/pharo/issues/detail?id=6461 >> | >> | >> | ----- Original Message ----- >> | | From: "Sean P. DeNigris" < sean(a)clipperadams.com > >> | | To: metacello(a)googlegroups.com >> | >> | >> | | Sent: Thursday, August 2, 2012 1:35:08 PM >> | | Subject: [Metacello] Re: collecting all packages of a configuration >> | | >> | | >> | | Dale Henrichs wrote >> | | > >> | | > I assume that the issue is a problem in Pharo-2.0. >> | | >> | | +1. This sounds to me like >> | | http://code.google.com/p/pharo/issues/detail?id=6461 >> | | >> | | Try loading in #20232 to confirm... >> | | >> | | Sean >> | | >> | | >> | | >> | | -- >> | | View this message in context: >> | | >> http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p… >> | | Sent from the Metacello mailing list archive at Nabble.com. >> | | >> | >> | >> | >> | >> | -- >> | Mariano >> | http://marianopeck.wordpress.com >> | >> | >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 3, 2012

Re: [Pharo-project] Pharo on retina display

by Philippe Marschall

On 08/01/2012 10:43 PM, Igor Stasenko wrote: > On 1 August 2012 21:56, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Like all apps not upgraded for retina, Pharo looks pixelated and fuzzy on the >> new MBPs. Is there any workaround which at least makes the text less fuzzy? >> > Use freetype :) Doesn't help Cheers Philippe

Aug. 3, 2012

Re: [Pharo-project] Memory usage

by Tudor Girba

Not bad :) Doru On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: > > On Aug 2, 2012, at 10:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 2, 2012, at 10:17 PM, jannik.laval wrote: >> >>> Hi, >>> >>> I tried the VM included in Moose (moosetechnology.org) >>> If I remember well, it is a cog vm. >>> >>> The maximal heap size is (precisely): 2138046463 bytes. >>> Why this number ? I don't know. But I will need more than 2Gb. >> >> HI jannik >> >> was the system usable? >> Because the problem with more memory is that you need specific GCes. > > It seems. > I built a DSM on a 1300 packages system. > > Jannik > >> >> Stef >> >> >> >>> >>> I will try the 64bits vm, and see. >>> >>> Cheers, >>> Jannik >>> >>> On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> >>>> Hi John, >>>> >>>> There is no regression in the interpreter VM ... well actually there was >>>> about 6 months back, but I keep an eye on it and it's fixed again now :) >>>> >>>> The 32-bit interpreter VM will not fail on any 2GB or 4BG boundaries, >>>> and an interpreter VM compiled for the 64-bit object format can handle >>>> images greater than 7GB (probably much more, but my 8GB PC is too small >>>> to do anything larger). >>>> >>>> I'm not sure if all of the necessary fixes are in place for the StackVM >>>> and Cog. If not, I'm sure it will be addressed over time (it's just not >>>> something that I have ever checked). >>>> >>>> I believe that Jannik is interested in running very large images, at >>>> least on an experimental basis. For anything over a few GB, this requires >>>> an interpreter VM and a 64-bit image. As you know, this is sure to run >>>> into problems for the garbage collector as the number of objects >>>> increases, but it would certainly be interesting to see how far the >>>> current garbage collector can go in real world conditions before it >>>> turns to mollasses. >>>> >>>> Dave >>>> >>>> >>>> On Wed, Aug 01, 2012 at 08:57:02AM -0400, John McIntosh wrote: >>>>> A few years back the interpreted virtual machine was fixed to allow an >>>>> image to grow to the 4 GB limit. >>>>> It is unclear to me if someone regressed the software to impose a 2GB limit >>>>> again, or if the 2GB number >>>>> mentioned is based on how things worked10 years ago? >>>>> >>>>> On Wed, Aug 1, 2012 at 5:01 AM, St?phane Ducasse >>>>> <stephane.ducasse(a)inria.fr>wrote: >>>>> >>>>>> >>>>>> On Jul 31, 2012, at 11:46 PM, johnmci wrote: >>>>>> >>>>>>> David Lewis and I spent a far amount of time a few years back to make >>>>>> the 32 >>>>>>> vm 4gb clean. So are you running on stale knowledge here, or does the vm >>>>>>> crash when to goes over 2gb? >>>>>> >>>>>> sorry my english limit does not let me know understanding what you mean >>>>>> exactly. >>>>>> Jannik in the context of moose would like to see if we can have image >>>>>> larger than 500 mb (on mac it should be possible). >>>>>> >>>>>> Stef >>>>>> >>>> >>> >>> --- >>> Jannik Laval >>> >>> >> >> > > --- > Jannik Laval > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 3, 2012

Re: [Pharo-project] Memory usage

by jannik.laval

On Aug 2, 2012, at 10:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 2, 2012, at 10:17 PM, jannik.laval wrote: > >> Hi, >> >> I tried the VM included in Moose (moosetechnology.org) >> If I remember well, it is a cog vm. >> >> The maximal heap size is (precisely): 2138046463 bytes. >> Why this number ? I don't know. But I will need more than 2Gb. > > HI jannik > > was the system usable? > Because the problem with more memory is that you need specific GCes. It seems. I built a DSM on a 1300 packages system. Jannik > > Stef > > > >> >> I will try the 64bits vm, and see. >> >> Cheers, >> Jannik >> >> On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >>> Hi John, >>> >>> There is no regression in the interpreter VM ... well actually there was >>> about 6 months back, but I keep an eye on it and it's fixed again now :) >>> >>> The 32-bit interpreter VM will not fail on any 2GB or 4BG boundaries, >>> and an interpreter VM compiled for the 64-bit object format can handle >>> images greater than 7GB (probably much more, but my 8GB PC is too small >>> to do anything larger). >>> >>> I'm not sure if all of the necessary fixes are in place for the StackVM >>> and Cog. If not, I'm sure it will be addressed over time (it's just not >>> something that I have ever checked). >>> >>> I believe that Jannik is interested in running very large images, at >>> least on an experimental basis. For anything over a few GB, this requires >>> an interpreter VM and a 64-bit image. As you know, this is sure to run >>> into problems for the garbage collector as the number of objects >>> increases, but it would certainly be interesting to see how far the >>> current garbage collector can go in real world conditions before it >>> turns to mollasses. >>> >>> Dave >>> >>> >>> On Wed, Aug 01, 2012 at 08:57:02AM -0400, John McIntosh wrote: >>>> A few years back the interpreted virtual machine was fixed to allow an >>>> image to grow to the 4 GB limit. >>>> It is unclear to me if someone regressed the software to impose a 2GB limit >>>> again, or if the 2GB number >>>> mentioned is based on how things worked10 years ago? >>>> >>>> On Wed, Aug 1, 2012 at 5:01 AM, St?phane Ducasse >>>> <stephane.ducasse(a)inria.fr>wrote: >>>> >>>>> >>>>> On Jul 31, 2012, at 11:46 PM, johnmci wrote: >>>>> >>>>>> David Lewis and I spent a far amount of time a few years back to make >>>>> the 32 >>>>>> vm 4gb clean. So are you running on stale knowledge here, or does the vm >>>>>> crash when to goes over 2gb? >>>>> >>>>> sorry my english limit does not let me know understanding what you mean >>>>> exactly. >>>>> Jannik in the context of moose would like to see if we can have image >>>>> larger than 500 mb (on mac it should be possible). >>>>> >>>>> Stef >>>>> >>> >> >> --- >> Jannik Laval >> >> > > --- Jannik Laval

Aug. 3, 2012

Re: [Pharo-project] [update 2.0] #20240

by Sean P. DeNigris

Feast or famine... for this build, the simple trigger fired twice, and URLTrigger once (all hours after the update), plus Esteban's manual build = 4! I filed another two bug reports with the URLTrigger plugin... Sean -- View this message in context: http://forum.world.st/update-2-0-20240-tp4642636p4642799.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 3, 2012

Re: [Pharo-project] Opposite of raisedToInteger: or raisedTo:

by Esteban A. Maringolo

Deepi wrote > > Is there any method that does this in Pharo? > Yes, again, #nthRoot: :) It is available in Pharo 1.4 at least. Did you try evaluating "27 nthRoot: 3" in a Workspace? Regards, -- Esteban. -- View this message in context: http://forum.world.st/Opposite-of-raisedToInteger-or-raisedTo-tp4642778p464… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 3, 2012

Re: [Pharo-project] FileTree sources

by Dale Henrichs

Cami, Oh good, I appreciate your help ... I've closed the pull request ... if it is easier for you to do the compat layer work in Pharo-2.0 then submitting a pull request as a branch off of pharo2.0 will be fine ... in fact if you do that, I can be responsible for doing the port of the compat layer to the other pharo, gemstone, and squeak branches (at my leisure). That way we can get the pharo2.0 branch operation as quickly as possible. Keep in mind that the git repository is the repository of record and has my latest work .. any mcz packages that are published are there for bootstrapping only and don't represent the latest code base. Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, August 2, 2012 4:29:37 PM | Subject: Re: [Pharo-project] FileTree sources | | thanks dale, | | I manually loaded the overridden/new methods so problem "solved". | As for the compat layer, I will sit together with esteban tomorrow | and discuss further steps :) | | On 2012-08-02, at 22:37, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > Cami, | > | > I just saw your email ... are there any particular versions that | > you need? | > | > We were conversing over on GitHub around that same time, so perhaps | > you no longer need the versions? | > | > Dale | > | > ----- Original Message ----- | > | From: "Camillo Bruni" <camillobruni(a)gmail.com> | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | > | <pharo-project(a)lists.gforge.inria.fr> | > | Sent: Thursday, August 2, 2012 8:06:14 AM | > | Subject: [Pharo-project] FileTree sources | > | | > | I am trying to fix FileTree for 2.0 without FileDirectory. | > | Can anyone give the mcz versions (they usually get cached) to | > | fill | > | the | > | gap between the gemstone and the github repos? | > | | > | Cause currently I cannot merge, and I realized that only after | > | applying all the | > | changes... | > | | > | best | > | cami | > | | > | | |

Aug. 3, 2012

Re: [Pharo-project] Opposite of raisedToInteger: or raisedTo:

by Esteban A. Maringolo

#nthRoot: anInteger is your friend. i.e.: 256 nthRoot: 8 "will return 2" -- View this message in context: http://forum.world.st/Opposite-of-raisedToInteger-or-raisedTo-tp4642778p464… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 2, 2012

Re: [Pharo-project] FileTree sources

by Camillo Bruni

thanks dale, I manually loaded the overridden/new methods so problem "solved". As for the compat layer, I will sit together with esteban tomorrow and discuss further steps :) On 2012-08-02, at 22:37, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Cami, > > I just saw your email ... are there any particular versions that you need? > > We were conversing over on GitHub around that same time, so perhaps you no longer need the versions? > > Dale > > ----- Original Message ----- > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> > | Sent: Thursday, August 2, 2012 8:06:14 AM > | Subject: [Pharo-project] FileTree sources > | > | I am trying to fix FileTree for 2.0 without FileDirectory. > | Can anyone give the mcz versions (they usually get cached) to fill > | the > | gap between the gemstone and the github repos? > | > | Cause currently I cannot merge, and I realized that only after > | applying all the > | changes... > | > | best > | cami > | >

Aug. 2, 2012

[Pharo-project] RE : [Preview] The Alternative Browser

by GOUBIER Thierry

Thanks. For editing more than one method, you would need to open multiple browsers (as usual). They all share the same abstract tree, so any change in organisation done in one browser is seen by the others. I had the vision of merging the tree in the left pane in the Pharo background, and keep only the editing pane (multiple ones), but the tree is taller than it is wider, and the background is wider than taller... Double-click could also be added, as well as more ways of restricting the tree (focusing the view). At the moment, it's very close to becoming my system browser of choice. Once I manage to get the shortcuts working... Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : jeudi 2 aoÃ»t 2012 19:42 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] [Preview] The Alternative Browser Thanks for the time you took. Thierry. Vidoeos are so good. What would be really nice it to be able to see multiple methods at once and edit them separately. Soemtimes I have the impression that you would like to double click on an item and to only see him to avoid to always have to click on the tree triangle to open categories. It would be like a zoom in to a class/categories/group. Stef On Aug 2, 2012, at 11:21 AM, Goubier Thierry wrote: > Ok, I made a screencast. > > http://ubuntuone.com/70xFLiJjNRbCGdpVGVIE97 > > It shows mouse-based navigation, buggy drag and drop, as well as keyboard navigation in the entire system, and a few things that are interesting to see : an empty System-Text package, for example. > > It's done on the base one-click 2.0 image. > > Thierry > > Le 01/08/2012 21:31, Bernardo Ezequiel Contreras a Ã©crit : >> yes, pleaseee >> >> On Wed, Aug 1, 2012 at 4:18 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> wrote: >> >> I'll have to make one, and script a bit. I'll try tomorrow. >> >> A youtube thing would be Ok? >> >> Thierry >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr >> <mailto:pharo-project-bounces@lists.gforge.inria.fr> >> [pharo-project-bounces(a)lists.gforge.inria.fr >> <mailto:pharo-project-bounces@lists.gforge.inria.fr>] de la part de >> StÃ©phane Ducasse [stephane.ducasse(a)inria.fr >> <mailto:stephane.ducasse@inria.fr>] >> Date d'envoi : mercredi 1 aoÃ»t 2012 20:11 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr> >> Objet : Re: [Pharo-project] [Preview] The Alternative Browser >> >> thierry do you have a video? >> >> Stef >> >> On Aug 1, 2012, at 2:05 PM, Goubier Thierry wrote: >> >> > Hi all, >> > >> > I'm happy to announce a prototype release of an alternative >> system browser for Pharo 2.0, at the following place : >> > >> > http://ss3.gemstone.com/ss/Alt-Browser >> > >> > Beware, it's a preview; but it let you experiment with the >> following features : >> > >> > * Reorganize / built a hierarchy of all packages, categories, >> classes and traits of the system. >> > * Drag and drop to reorganize : work partially. >> > * Tracks changes in other browsers (not all). >> > * Has context sensitive / selection sensitive menus >> > * Has an extensible command system : Other packages may add any >> level of menu (and keyboard shortcuts once I've managed to >> understand that part), to bring, say, all Nautilus/ OmniBrowser >> commands. >> > * Has a minimalistic GUI. >> > * Keyboard oriented navigation >> > * Spec-based ! >> > >> > Loading should simply be: >> > Add the repository in Monticello : >> http://ss3.gemstone.com/ss/Alt-Browser. >> > Open and load Alt-Browser-ThierryGoubier.18.mcz and >> Alt-Monticello-Commands-ThierryGoubier.1.mcz >> > >> > Enjoy! I'll try to make it my work system browser, so it should >> get at least a minimum of support for coding and refactoring commands. >> > >> > Thierry >> > -- >> > Thierry Goubier >> > CEA list >> > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> > 91191 Gif sur Yvette Cedex >> > France >> > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >> >> >> >> >> >> >> -- >> Bernardo E.C. > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Aug. 2, 2012