- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Thu, Jul 29, 2010 at 10:24 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Maybe it's just me, or could we not add Announcement to the end of every > Announcement subclass name though? > > Like with the window announcement, I like them better as verbs describing > the event, f.ex. > > someAnnouncer on: TestStarted do: [] > > someAnnouncer on: TestEnded send: #x to: y > > Someone else vote for this? > I'm experimenting with Announcers on TestResult. What do you think about this syntax ? TestResult when: TestCaseStarts do: [:event | do some stuff ]. TestResult when: TestCaseEnds do: [:event | do some stuff ]. Laurent > 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 >

Aug. 1, 2010

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

by Tudor Girba

Hi Stef, I would go for first mirroring categories. Like this, Monticello would still work as expected, and we can just focus on improving the image based tools/concepts. Cheers, Doru On 1 Aug 2010, at 22:02, StÃ©phane Ducasse wrote: > > >> 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. > > This is what my implementation does. No magic matching. Just a list > of classes and methods. > Now if I do not support the * convention of packageinfo it means > that we will not be able to load and save > packages in a compatible form. We could do that and it would save me > a lot of work. But people have to agree and understand the > consequences. Of course we could do a MCPackageInfor specific loader > that loads and convert MC packages. > But this means that the packages will not be able to be used in > Squeak. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Aug. 1, 2010

[Pharo-project] [update 1.2] #12073

by StÃ©phane Ducasse

12073 ----- - Issue 1289: Changing locale raises DNU - test categories cleaning. Thanks alexandre. - Issue 2205: pluggable Tree Morph deselect behavior. Tx Laurent.

Aug. 1, 2010

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

by StÃ©phane Ducasse

> 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. This is what my implementation does. No magic matching. Just a list of classes and methods. Now if I do not support the * convention of packageinfo it means that we will not be able to load and save packages in a compatible form. We could do that and it would save me a lot of work. But people have to agree and understand the consequences. Of course we could do a MCPackageInfor specific loader that loads and convert MC packages. But this means that the packages will not be able to be used in Squeak. Stef

Aug. 1, 2010

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

by Andrey Larionov

Pharo1.1 dosn't contain this methods On Sun, Aug 1, 2010 at 21:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > > _______________________________________________ > 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 Andrey Larionov

maybe, but i'm thinking what (WideString basicNew: size) writeStrem contents should return WideString, not the ByteString On Sun, Aug 1, 2010 at 17:48, Philippe Marschall <kustos(a)gmx.net> wrote: > 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 > > > _______________________________________________ > 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, 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