- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20242

by Esteban Lorenzano

20242 ----- Issue 6493: Integrate new version of Fuel and remove obsolete packages http://code.google.com/p/pharo/issues/detail?id=6493 Issue 6497: new ReleaseTest >> testUnpackagedClasses http://code.google.com/p/pharo/issues/detail?id=6497 Issue 6502: FS (FileSystem) and freetype on windows http://code.google.com/p/pharo/issues/detail?id=6502 Issue 6506: add FileReference>>#isSymlink http://code.google.com/p/pharo/issues/detail?id=6506 Issue 6507: New Spec version http://code.google.com/p/pharo/issues/detail?id=6507

Aug. 3, 2012

[Pharo-project] Smalltalks 2012 invitation and registration

by Andres Valloud

Hello! You're invited to come over to the wonderful Argentine patagonia to participate in Smalltalks 2012. This year we will host the conference at a new venue for us: Puerto Madryn. We're very pleased to see different sections of the Argentine Smalltalk community represented every year. Go to FAST's website and register. See you in Puerto Madryn! http://www.fast.org.ar http://en.wikipedia.org/wiki/Puerto_Madryn

Aug. 3, 2012

[Pharo-project] [update 2.0] #20241

by Esteban Lorenzano

20241 ----- Issue 6498: Remove old events in favor of System announcements - Step 1 http://code.google.com/p/pharo/issues/detail?id=6498 Issue 6476: one Monticello package that should not be there http://code.google.com/p/pharo/issues/detail?id=6476 Issue 6505: hasUnacceptedEdits breaks the debugger http://code.google.com/p/pharo/issues/detail?id=6505 Issue 6508: Tests.Release.ReleaseTest.testMethodsWithUnboundGlobals http://code.google.com/p/pharo/issues/detail?id=6508

Aug. 3, 2012

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