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

Re: [Pharo-project] About overlapping packages :(

by Schwab,Wilhelm K

Stef, Are you perhaps running into problems with mapping category names to packages? The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. They got so many things *really* right that I default to trusting them. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, August 01, 2010 1:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About overlapping packages :( Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote: > Stef, > > Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo. One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The truth is that it is not a big deal: save the image and figure it out after you get some coffee. However, it sure seems awful the first few times the system refuses to save a package. > > Dolphin uses concrete packages; classes, methods and other objects belong to a package. Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere. Packages are explicitly created by the user and then are separately populated. > > I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages. Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier. However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello. I responded by "porting" a tool called Migrate that I wrote early on for Dolphin. Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each. Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo. > > Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else. Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are. In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image. > > Perhaps the place to start is to have a quick look and to let me know if you have any questions. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, July 31, 2010 11:19 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About overlapping packages :( > >> sounds tricky. at the very least add a checker to a menu somewhere so >> we can start to use it. > > I will do that. > >> You wouldn't need to that deeply integrate it >> in the first instance... >> >> do you need to match the existing semantics exactly? I don't think >> it's good that we can get into these situations. Perhaps we should >> prevent them being able to be created in the first place, rather than >> deal with them once they overlap. > > It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created) > , but will have to start delete the top package. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > <Migrate-Core-BillSchwab.1.mcz>_______________________________________________ > 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

Aug. 1, 2010

Re: [Pharo-project] About overlapping packages :(

by StÃ©phane Ducasse

Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote: > Stef, > > Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo. One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The truth is that it is not a big deal: save the image and figure it out after you get some coffee. However, it sure seems awful the first few times the system refuses to save a package. > > Dolphin uses concrete packages; classes, methods and other objects belong to a package. Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere. Packages are explicitly created by the user and then are separately populated. > > I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages. Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier. However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello. I responded by "porting" a tool called Migrate that I wrote early on for Dolphin. Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each. Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo. > > Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else. Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are. In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image. > > Perhaps the place to start is to have a quick look and to let me know if you have any questions. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, July 31, 2010 11:19 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About overlapping packages :( > >> sounds tricky. at the very least add a checker to a menu somewhere so >> we can start to use it. > > I will do that. > >> You wouldn't need to that deeply integrate it >> in the first instance... >> >> do you need to match the existing semantics exactly? I don't think >> it's good that we can get into these situations. Perhaps we should >> prevent them being able to be created in the first place, rather than >> deal with them once they overlap. > > It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created) > , but will have to start delete the top package. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > <Migrate-Core-BillSchwab.1.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by StÃ©phane Ducasse

Cool! Thanks. I think that this is important to get good infrastructure. On Aug 1, 2010, at 3:43 PM, Philippe Marschall wrote: > On 01.08.2010 09:39, StÃ©phane Ducasse wrote: >> andrey >> >> do you know if they tests are failing also in squeak? >> Else what are the problems? > > #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. > I sent a patch to Andreas, got WebSockets running in Seaside now :-) > > 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. 1, 2010

Re: [Pharo-project] About overlapping packages :(

by Schwab,Wilhelm K

Stef, Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo. One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The truth is that it is not a big deal: save the image and figure it out after you get some coffee. However, it sure seems awful the first few times the system refuses to save a package. Dolphin uses concrete packages; classes, methods and other objects belong to a package. Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere. Packages are explicitly created by the user and then are separately populated. I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages. Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier. However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello. I responded by "porting" a tool called Migrate that I wrote early on for Dolphin. Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each. Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo. Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else. Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are. In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image. Perhaps the place to start is to have a quick look and to let me know if you have any questions. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, July 31, 2010 11:19 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About overlapping packages :( > sounds tricky. at the very least add a checker to a menu somewhere so > we can start to use it. I will do that. > You wouldn't need to that deeply integrate it > in the first instance... > > do you need to match the existing semantics exactly? I don't think > it's good that we can get into these situations. Perhaps we should > prevent them being able to be created in the first place, rather than > deal with them once they overlap. It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created) , but will have to start delete the top package. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2010

Re: [Pharo-project] String, ByteString and WideString

by Philippe Marschall

On 01.08.2010 01:56, Andrey Larionov wrote: > Working with WebClient i found what it lacks of non latin languages > support (for example Russian). During investigation i found, what for > streaming there used ByteString, which is custructed by calling String > class>>new:. All subclases of String by calling of this method > produces only ByteString instances. Also WriteStream>>contents > indirectly calls String class>>new:. So even you construct WideString > with #basicNew: calling > (WideString basicNew: size) writeStrem contents > produce only ByteString You probably want one of the MultiByteStreams and then set either the encoding or the converter. Cheers Philippe

Aug. 1, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Philippe Marschall

On 01.08.2010 09:39, StÃ©phane Ducasse wrote: > andrey > > do you know if they tests are failing also in squeak? > Else what are the problems? #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. I sent a patch to Andreas, got WebSockets running in Seaside now :-) Cheers Philippe

Aug. 1, 2010

Re: [Pharo-project] Bug in OBHierarchyBrowser

by Lukas Renggli

I fixed and closed the issue: Name: OB-Standard-lr.481 Author: lr Time: 1 August 2010, 3:33:14 pm UUID: 0fd4e1fa-323e-4ef5-b1ad-0ae74361a8f5 Ancestors: OB-Standard-lr.480 - Issue 2737: "Green hierarchy arrows" not working as expected in OBHierarchyBrowser On 1 August 2010 12:38, Max Leske <maxleske(a)gmail.com> wrote: > http://code.google.com/p/pharo/issues/detail?id=2737. > > Lukas will accept the bug. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Aug. 1, 2010

Re: [Pharo-project] List of possible actions for busy pharoers

by Mariano Martinez Peck

this one is ready also: http://code.google.com/p/pharo/issues/detail?id=2733 On Sun, Aug 1, 2010 at 12:39 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr > wrote: > hi guys > > I know that some of you would like to contribute but are busy, scared ... > I spent three hours to go over the bug entries. Feel free to pick one and > fix it: > So now you can easily contribute. Just do it. > > Stef > > Some easy fixes: > -------------- > for the fixes based on squeak changed, it often requires to check the code > and run pharo tests. > > http://code.google.com/p/pharo/issues/detail?id=2603 Issue 2603 > isRunningCog > http://code.google.com/p/pharo/issues/detail?id=2704 Issue 2704: > Tests for broken withNoLineLongerThan: behavior. > http://code.google.com/p/pharo/issues/detail?id=2693 > http://code.google.com/p/pharo/issues/detail?id=2661 Issue 2661: > File name correction for unix to allow > http://code.google.com/p/pharo/issues/detail?id=2706 Issue 2706: > Mirror primitive tests succeed on the Cog VMs. > http://code.google.com/p/pharo/issues/detail?id=1746 Issue 1746: > ReferenceStream>>readOnlyFileNamed: is missing > http://code.google.com/p/pharo/issues/detail?id=1767 Issue 1767: > Method Finder gives UndefinedObject error on search > http://code.google.com/p/pharo/issues/detail?id=1765 Issue 1765: > JPEGReadWriter>>#decompressionTest should be made into a Sunit Test > http://code.google.com/p/pharo/issues/detail?id=2265 Issue 2265: to > check MCWorkingCopyBrowser from Squeak > http://code.google.com/p/pharo/issues/detail?id=2063 Issue 2063: > NumberTest > http://code.google.com/p/pharo/issues/detail?id=2266 Issue 2266: > MessageNames selectorListIndex > http://code.google.com/p/pharo/issues/detail?id=2176 Issue 2176: > Integrated DirectoryEntry>>attributes > http://code.google.com/p/pharo/issues/detail?id=2296 Issue 2296: > Point>>closeTo > http://code.google.com/p/pharo/issues/list?cursor=2573 Issue 2573: > Make it possible to run cleanup non-interactively. > http://code.google.com/p/pharo/issues/detail?id=2609 Issue 2609: > getSystemAttribute: 2 -> documentPath > > > Some important ones: > ------------------ > http://code.google.com/p/pharo/issues/detail?id=2579 > http://code.google.com/p/pharo/issues/detail?id=2698 > http://code.google.com/p/pharo/issues/detail?id=2662 Issue 2662: value: > primitives > http://code.google.com/p/pharo/issues/detail?id=1801 Issue 1801: > Rescue Sophie Undo framework > http://code.google.com/p/pharo/issues/detail?id=2177 Issue 2177: > Generalize stream protocol #readInto:startingAt:count: > http://code.google.com/p/pharo/issues/detail?id=1921 Issue 1921: > Class>>Binding Fix > Issue 1981: Raising DuplicateError Exception in class builder > http://code.google.com/p/pharo/issues/detail?id=1981 > http://code.google.com/p/pharo/issues/detail?id=2146 Issue 2146: > Fix SystemChangeNotification for traits. > http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: > MethodDictionary improvement > http://code.google.com/p/pharo/issues/detail?id=2315 Method Dictionary > Compact protocol to investigate > http://code.google.com/p/pharo/issues/list?cursor=2313 Issue 2313: > HashedCollectionIntegrityTest > http://code.google.com/p/pharo/issues/detail?id=2583 Issue 2583: > COG - MessageTally > Issue 2619: ignore vm parameters with nil value in > MessageTally, so it can be used in Cog > > http://code.google.com/p/pharo/issues/detail?id=2584 COG- COG- > LargeNegativeInteger to be compact at 5 > http://code.google.com/p/pharo/issues/detail?id=2567 Issue 2567: > evaluate the finalizers outside the protected block in WeakRegistry > http://code.google.com/p/pharo/issues/detail?id=2564 Issue 2564: > WeakKeyDictionary finalizeValue tests > http://code.google.com/p/pharo/issues/list?cursor=2551 weakstructure > http://code.google.com/p/pharo/issues/detail?id=2620 Issue 2620: > BlockClosure asContext losing bound variable? > http://code.google.com/p/pharo/issues/detail?id=2617 Issue 2617: > Fix restart in blocks in debugger > http://code.google.com/p/pharo/issues/detail?id=2618 Issue 2618: a > bit faster DependentsArray >> #select: > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2010

[Pharo-project] [update 1.2] #12072

by StÃ©phane Ducasse

12072 ----- - Issue 2727: Consistency by providing uppercase menu items in Tools menus (Part 2). Thanks Torsten. There are no such little fixes :)

Aug. 1, 2010

[Pharo-project] next list of integration ready items

by stephane ducasse

Aug. 1, 2010