- Pharo-dev - lists.pharo.org

Re: [Pharo-project] History and SUnit

by Alexandre Bergel

http://www.squeaksource.com/Testing/ http://wiki.squeak.org/squeak/SUnit%20for%203.10 Alexandre On 3 Oct 2008, at 12:13, Simon Kirk wrote: > Stef, what do you mean by "the Testing package" ? > S > > > On 3 Oct 2008, at 09:46, StÃ©phane Ducasse wrote: > >> Simon what would be good is a feedback on whether the Testing >> package is good, useful, .... >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by Simon Kirk

Stef, what do you mean by "the Testing package" ? S On 3 Oct 2008, at 09:46, StÃ©phane Ducasse wrote: > Simon what would be good is a feedback on whether the Testing > package is good, useful, .... > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by StÃ©phane Ducasse

Simon what would be good is a feedback on whether the Testing package is good, useful, .... Stef

Oct. 3, 2008

Re: [Pharo-project] Formalised UI

by StÃ©phane Ducasse

Hi antony > >> By professional we mean: clean and robust, Of course we would like >> to have a good layout and UI. But someone has to do it. :) >> What is also important is that people get the fredom to invent new >> things and that pharo keeps making progress even at the price to be >> incompatible. > > I have slightly different goals. I'm less concerned about cleaning > up Squeak to start with, more concerned with making something that > is commercially focussed, with support, that is packaged to allow it > to cross the chasm. To that end I don't care about breaking > everything that I don't intend to support, so my refactoring can be > quite aggressive. Yes I understand. (We are doing the same for a lot of experimental code. For the release 1.0 we want to remove etoy + friends + bookmorph ) Our goal is similar except that we know that we do not have the workpower to offer support. Now some guys approached us to know if FFI and other stuff would be maintained / improved in Pharo because they would like to port VSE software. So clearly this is not something that we can offer but we would love if a company would offer this service on top or aside of pharo. We have no problems with people making money with what we are doing: in fact this is a goal that people can make money. > I'm focused on Traits + OmniBrowser. Ok. What is your business model: offering a better IDE? Because we could buy it. I would love to see some real offer, because we are buying all kind of software and I would love to be able to buy some code software that supports our second main activity (coding - first one is writing papers). > > My reasons for attempting a commercial development is to generate a > revenue stream that ensures continuity of development, so that it > doesn't become abandonware. I'm planning for a situation like > MyEclipse. I can support this project for at least a few years > without revenue. Do I guess correctly that you would like to sell a IDE for "Squeak"? I do not know myEclipse. If you would base your effort on Pharo we could also integrate your refactoring >> Is your code free? > > Yes, that code is. I haven't explicitly licensed it yet. Let us know when you know and if you want to share what can be shared. > > >> Now may be you could join gary effort with polymorph? > > My ongoing efforts are commercial, so it's probably not possible. > And I've got a very definite architecture in progress already. > >> Did you check the way newspeak does it with hopstoch > > I was working on a dynamic document-based model before hopscotch was > demonstrated, so yes. I have a background in structured document > editors, which is what motivates me. Excellent! > > >> What do you mean by new packaging. We are thinking about a module >> system but for milestone 4 or 5 (one year or two from now). > > My packaging/modularity project is called MirrorImage - some details > are on my blog. It works with VW, although I haven't really released > it because there wasn't much interest, and in any case VW is the > wrong community for such proposals. :) > > > MirrorImage is a reworking of how classes are defined. In particular > it uses a DSL approach to system construction that allows classes to > be incrementally constructed, with contributions from different > 'Projects' that can be prioritized with dependencies etc based on a > configuration algebra. Such contributions can be more that simply > adding vars and methods (ala GST) - you can delete/add/transform/ > shadow any part of the code model (ivar/cvar/methods/traits etc). > Transformation is useful for changing the way traits are integrated > into a class you want to change. Sounds interesting. > Traits also have an interesting interaction with system construction > from a pragmatic perspective because they act as a conceptual > delimiter, although that may be less interesting once I don't have > to rely on the completely braindead method-category string prefix > model of packaging. My #1 dislike in Squeak. Welcome :) >> Can you bootstrap the kernel? > > Not yet, I was about to do that when I decided to switch from VW. I > will bootstrap the Kernel using the same technique that Lisp systems > use to bootstrap. I would really like to have a bootstrap kernel so that we could even manage the source with git :) > > > Once that works it will also be the tool I use to cut out the stuff > I don't intend to support. > >> One which version of Squeak are you based? > > I started with the Damien's 3.10 dev packaging, although I'm > thinking of switching to Pharo as a base. You are welcome. Our goal is really to get rid and improve a lot of things. So if you can share some parts we may be in a win-win situation. > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > There is nothing more difficult to plan, more doubtful of success, > nor more dangerous to manage than the creation of a new order of > things... Whenever his enemies have the ability to attack the > innovator, they do so with the passion of partisans, while the > others defend him sluggishly, So that the innovator and his party > alike are vulnerable. > -- Niccolo Machiavelli, 1513, The Prince. Nice quote :) >

Oct. 3, 2008

Re: [Pharo-project] Did you harvest Kernel-dc.198

by StÃ©phane Ducasse

Done in 10085 Stef On Oct 3, 2008, at 8:08 AM, Marcus Denker wrote: > > On 02.10.2008, at 21:59, StÃ©phane Ducasse wrote: > >> Hi marcus >> >> did you harvest ? >> > > No, but this looks good. > > Marcus > >> Name: Kernel-dc.198 >> Author: dc >> Time: 28 September 2008, 4:00:03 pm >> UUID: 3b2eeec4-6461-4d22-94d1-e7f692e7e177 >> Ancestors: Kernel-marcus.denker.197 >> >> - M7166: speedup allSelectors add allSelectorsBelow:. >> >> Firstly #allSelectors inefficiently creates multiple intermediate >> collections. Refactoring this yields a 27% speed improvement. >> >> Secondly many users of #allSelectors forget that when applied to >> the class side it doesnt stop at ProtoObject class, it continues to >> Class ClassDescription, Behavior, Object and ProtoObject. This is >> catered for by adding #allSelectorsBelow: >> >> Magritte and SUnit are heavy users which benefit. >> >> >> I imagine not so I will. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by Simon Kirk

On 2 Oct 2008, at 23:24, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Thanks >> I will have a look. I do not really understand what is written, this >> is too cryptic. >> Does the framework changes remove the fact that tests should start >> with test? >> >> Stef > Yes, although the default behaviour is preserved, TestCase subclasses > can publish their own test suites with whatever behaviour they wish. > BTW: the framework has changed somewhat since that documentation was > written. > > For example in SSpec "specs" start with spec* > > the goal is to enable TestRunner to be used as a runner for SSpec as > well as SUnit, if I ever get around to it. In the latest version of the SSpec runner that we use (which is also the latest in Squeaksource iirc, as John here made the most recent changes) specs can be whatever format you want, but the spec method(s) must be in the method category "specs" in order to run. Generally specs (ie BDD) are of the format "shouldDoBlahBlah" so that they read in a BDD manner when they report problems. In practice this means It parses the camel case in the output message, so for example: if the spec class is AddTwoNumbersSpec then you'd get something like "Add two numbers spec should get negative number for negative arguments". This sentence is English, and is relatively easy to parse and understand what the desired behaviour is. So: using "should" as a prefix makes sense to me, and I like the use of the method categorisation to define what runs as a spec: it makes it easy to turn some specs on and off within a spec class without having to do method renames, which is generally more hassle (changing a method category is a drag and drop operation). My â¬0.02 as usual. S ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 3, 2008

[Pharo-project] Re: Exupery's VMMaker on SqueakSource now has closures

by bryce＠kampjes.demon.co.uk

Markus Fritsche writes: > bryce(a)kampjes.demon.co.uk schrieb: > > > I can supply a built VM if anyone wants to try it immediately. If > > not I'll package one up after finishing tidying up. > > Hello Bryce, > > I'd like to try it out immediately. But... > > What are the premises? Do I have to build a special VM for Exupery (your > post indicates that)? Is Exupery x86_64 compatible? Do I have to take > special actions with my image? Can I run 'seaside' with exupery? Are > there drawbacks/ gains on memory/ cpu consumption? I'll bundle up the VM after work. (Tonight UK time) Exupery requires a few VM extensions, they're completely harmless unless you also load Exupery and start it running. I already need to maintain a VM for Exupery, so I merged the changes Pharo wanted into it. By merging the changes into Exupery's branch of VMMaker, they'll get in all future VMs I build. So long as you don't run Exupery, it's just another VM, but with both the truetype font changes and the closure bytecodes. You can run Seaside, and anything else. Exupery itself is compatable with Seaside. There's a tiny fix to Seaside's continuations that's been included in 2.9 that you may want. The VM is a 32 bit one, but runs OK on 64 bit Linux in compatability mode. If you want to have a modern VM with closure bytecodes then using the Exupery VMMaker is a reasonable thing to do. By just building using Exupery's latest version of VMMaker rather than the one from SqueakMap, you'll get closure support and sub-pixel anti-aliasing. Bryce

Oct. 3, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Simon Kirk

It has a search, but the last time I tried it it didn't actually find anything for any given string (perhaps I just had a bad experience) On 2 Oct 2008, at 22:05, Dan Corneanu wrote: > Just made an update and seen the Univers Browser (enhanced). It seems > to have what I wanted :) > > On Thu, Oct 2, 2008 at 11:46 PM, Dan Corneanu > <dan.corneanu(a)gmail.com> wrote: >> Hi, >> I know it is not decided yet what will pharo use for loading code, >> but >> I would really appreciate a search button in the Univers Browser. >> I always find myself lost in the tree. >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 3, 2008

Re: [Pharo-project] Formalised UI

by Antony Blakey

On 03/10/2008, at 2:50 PM, StÃ©phane Ducasse wrote: > By professional we mean: clean and robust, Of course we would like > to have a good layout and UI. But someone has to do it. :) > What is also important is that people get the fredom to invent new > things and that pharo keeps making progress even at the price to be > incompatible. I have slightly different goals. I'm less concerned about cleaning up Squeak to start with, more concerned with making something that is commercially focussed, with support, that is packaged to allow it to cross the chasm. To that end I don't care about breaking everything that I don't intend to support, so my refactoring can be quite aggressive. I'm focused on Traits + OmniBrowser. My reasons for attempting a commercial development is to generate a revenue stream that ensures continuity of development, so that it doesn't become abandonware. I'm planning for a situation like MyEclipse. I can support this project for at least a few years without revenue. > Is your code free? Yes, that code is. I haven't explicitly licensed it yet. > Now may be you could join gary effort with polymorph? My ongoing efforts are commercial, so it's probably not possible. And I've got a very definite architecture in progress already. > Did you check the way newspeak does it with hopstoch I was working on a dynamic document-based model before hopscotch was demonstrated, so yes. I have a background in structured document editors, which is what motivates me. > What do you mean by new packaging. We are thinking about a module > system but for milestone 4 or 5 (one year or two from now). My packaging/modularity project is called MirrorImage - some details are on my blog. It works with VW, although I haven't really released it because there wasn't much interest, and in any case VW is the wrong community for such proposals. MirrorImage is a reworking of how classes are defined. In particular it uses a DSL approach to system construction that allows classes to be incrementally constructed, with contributions from different 'Projects' that can be prioritized with dependencies etc based on a configuration algebra. Such contributions can be more that simply adding vars and methods (ala GST) - you can delete/add/transform/ shadow any part of the code model (ivar/cvar/methods/traits etc). Transformation is useful for changing the way traits are integrated into a class you want to change. Traits also have an interesting interaction with system construction from a pragmatic perspective because they act as a conceptual delimiter, although that may be less interesting once I don't have to rely on the completely braindead method-category string prefix model of packaging. My #1 dislike in Squeak. > Can you bootstrap the kernel? Not yet, I was about to do that when I decided to switch from VW. I will bootstrap the Kernel using the same technique that Lisp systems use to bootstrap. Once that works it will also be the tool I use to cut out the stuff I don't intend to support. > One which version of Squeak are you based? I started with the Damien's 3.10 dev packaging, although I'm thinking of switching to Pharo as a base. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince.

Oct. 3, 2008

Re: [Pharo-project] Did you harvest Kernel-dc.198

by Marcus Denker

On 02.10.2008, at 21:59, StÃ©phane Ducasse wrote: > Hi marcus > > did you harvest ? > No, but this looks good. Marcus > Name: Kernel-dc.198 > Author: dc > Time: 28 September 2008, 4:00:03 pm > UUID: 3b2eeec4-6461-4d22-94d1-e7f692e7e177 > Ancestors: Kernel-marcus.denker.197 > > - M7166: speedup allSelectors add allSelectorsBelow:. > > Firstly #allSelectors inefficiently creates multiple intermediate > collections. Refactoring this yields a 27% speed improvement. > > Secondly many users of #allSelectors forget that when applied to the > class side it doesnt stop at ProtoObject class, it continues to > Class ClassDescription, Behavior, Object and ProtoObject. This is > catered for by adding #allSelectorsBelow: > > Magritte and SUnit are heavy users which benefit. > > > I imagine not so I will. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 3, 2008