- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Box-Admins] Re: Delay when I upload to Squeaksource 2MB files size

by Bert Freudenberg

On 27.10.2010, at 10:39, Tobias Pape wrote: > Am 2010-10-27 um 10:16 schrieb nullPointer: >> Seems upload correctly, but when the progress bar is almost ended seems much >> more slow... > > > Hence, squeaksource is down. > I encountered this behaviour onsite (i.e. here at HPI) > whenever a student tried to upload a MCZ, and it failed > or hanged, the SqueakSource installation went haywire. > So, whenever you encounter failing or endlessly hanging > uploads, pleas tell the mailing lists or the box admins, > so that squeaksource can be bought up again quickly. squeaksource.com is hosted by University of Bern's Software Composition Group. Kudos to them, it's an outstanding service to the community! But since it is not hosted on a squeak.org server, it does no good to notify the Squeak box admin team when squeaksource.com goes down. OTOH if source.squeak.org misbehaves, then the box admins are the right address. - Bert -

Oct. 27, 2010

Re: [Pharo-project] Delay when I upload to Squeaksource 2MB files size

by Tobias Pape

Am 2010-10-27 um 10:16 schrieb nullPointer: > Seems upload correctly, but when the progress bar is almost ended seems much > more slow... Hence, squeaksource is down. I encountered this behaviour onsite (i.e. here at HPI) whenever a student tried to upload a MCZ, and it failed or hanged, the SqueakSource installation went haywire. So, whenever you encounter failing or endlessly hanging uploads, pleas tell the mailing lists or the box admins, so that squeaksource can be bought up again quickly. So long, -Tobias

Oct. 27, 2010

[Pharo-project] [update 1.2] #12217

by Marcus Denker

12217 ----- Issue 3164: Fix find and seach all source Issue 1801: Rescue Sophie Undo framework Issue 2797: MIMEDocument class >> #guessTypeFromName: results in MNU -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 27, 2010

[Pharo-project] Delay when I upload to Squeaksource 2MB files size

by nullPointer

Seems upload correctly, but when the progress bar is almost ended seems much more slow... Regards. -- View this message in context: http://forum.world.st/Delay-when-I-upload-to-Squeaksource-2MB-files-size-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 27, 2010

Re: [Pharo-project] posting etiquette - please post new text at the *top* of your email

by StÃ©phane Ducasse

+ 1 > Hi Folks, > > It is really hard keeping up with the deluge of email on this list. It is even harder if you have to search through posts to find the actual new text buried in all the quoted stuff. > > Unless there is a very good reason to provide the context, please add your new text *before* any quoted material. > > Thanks a bunch.

Oct. 27, 2010

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by StÃ©phane Ducasse

thanks! On Oct 27, 2010, at 3:52 AM, Levente Uzonyi wrote: > On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: > >> HI Ramain (or someone with time). >> >> OCompletion does not work anymore in Pharo 1.2 because of the Preferences >> removal. It would be nice if you could update it to use the new settings >> framework. > > Ocompletion-ul.74 should work in both Pharo 1.1 and 1.2. After loading the package evaluate [ECToolSet register]. > > > Levente > >> >> There is information here: >> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ >> >> Thanks >> >> mariano >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2010

[Pharo-project] posting etiquette - please post new text at the *top* of your email

by Oscar Nierstrasz

Hi Folks, It is really hard keeping up with the deluge of email on this list. It is even harder if you have to search through posts to find the actual new text buried in all the quoted stuff. Unless there is a very good reason to provide the context, please add your new text *before* any quoted material. Thanks a bunch. - on

Oct. 27, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by Adrian Kuhn

Thanks to Niko for campaigning me as maintainer :) I do feel very excited about unit testing in Pharo, however these days I gotta concentrate on my thesis only. Please feel free to reuse whatever is of use to you. My code is there to be cloned and forked :) --AA On Oct 26, 2010, at 12:01 , StÃ©phane Ducasse wrote: > On Oct 25, 2010, at 10:12 AM, Niko Schwarz wrote: > >> Couldn't Adrian be the maintainer? I could step in, too. > > yes but it means being present and reactive. > >> I don't really know what you have in mind for a testing framework. We >> have our own independent and fully compatible fork of SUnit: >> akuhn/SUnit, which is quite a strong code basis. > > but do we need should, class factory..... > >> And on top of that we >> have Phexample, which has its own >> name, some extra features and gives a clear point where Pharo is >> different from the rest. > > This is not the difference that we look for. This is addressing > people problems. > >> Just a suggestion: Let Adrian maintain akuhn/SUnit, perhaps minus the >> "should" syntax that you don't like (as in: #(a b c) size should = >> 3), >> and make akuhn/SUnit part of Pharo core. The new features (having >> tests depend >> on one another, "should" syntax) go into Phexample, and I could >> maintain that. > > Why not. If adrian wants. > Now first we should have > - a better name > - clean the code = remove class factory + add comments > - make sure that the tools can work with it > - move the long execution Sunit extension to it > - make sure that the tests are green > - integrate/digest latest Sunit feature > > >> >> Cheers, >> >> Niko >> >> On Sun, Oct 24, 2010 at 8:37 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Lack of maintainers, too many unwanted features, lack of >>> explanation, >>> large changes... >>> >>> And this is not that several persons did not look at the code. It >>> got more than the average. >>> >>> Now I'm thinking that with discussion and care we should really >>> get another testing framework with the same API that SUnit >>> because if we want that PharoSunit is the same as Sunit then we >>> are doomed to be backward compatible and no >>> real improvements. >>> >>> Stef >>> >>> On Oct 23, 2010, at 10:58 PM, Adrian Kuhn wrote: >>> >>>> Sad to hear that. >>>> >>>> Technical difficulties, or just lack of customers? ^^ >>>> >>>> --AA >>>> >>>> On Oct 23, 2010, at 08:05 , StÃ©phane Ducasse wrote: >>>> >>>>> It was too difficult to integrate. >>>>> >>>>> Stef >>>>> >>>>> On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: >>>>> >>>>>> What's the status of akuhn/SUnit? I couldn't find his code in >>>>>> 1.2 core. >>>>>> >>>>>> Niko >>>>>> >>>>>> On Wed, Feb 3, 2010 at 1:13 PM, StÃ©phane Ducasse >>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>> this loads well in the latest 1,1 core :) >>>>>>> so now we should really have a look and these cool changes >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: >>>>>>> >>>>>>>> SystemChangeNotifier uniqueInstance >>>>>>>> noMoreNotificationsFor: TestCase. >>>>>>>> Gofer it >>>>>>>> disablePackageCache; >>>>>>>> squeaksource: 'akuhn'; >>>>>>>> package: 'SUnit'; >>>>>>>> package: 'SUnitGUI'; >>>>>>>> load. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://scg.unibe.ch/staff/Schwarz >>>>>> twitter.com/nes1983 >>>>>> Tel: +41 076 235 8683 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2010

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by Levente Uzonyi

On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: > HI Ramain (or someone with time). > > OCompletion does not work anymore in Pharo 1.2 because of the Preferences > removal. It would be nice if you could update it to use the new settings > framework. Ocompletion-ul.74 should work in both Pharo 1.1 and 1.2. After loading the package evaluate [ECToolSet register]. Levente > > There is information here: > http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ > > Thanks > > mariano >

Oct. 27, 2010

Re: [Pharo-project] Smells looking at collections

by Eliot Miranda

Hi Florin, On Tue, Oct 26, 2010 at 3:26 PM, Florin Mateoc <fmateoc(a)gmail.com> wrote: > On 10/26/2010 2:27 PM, Eliot Miranda wrote: > > > > The argument is not over the utility of stateful traits. The argument > is over how to access that state. The > > existing Traits implementation allows indirect access to state, where the > Trait uses accessors that must be > > implemented by a class using the trait. This has the disadvantages > listed by Levente, possibility of accessor > > selectors clashing with existing protocol, lack of privacy and poorer > performance. One possible solution is to do a > > new traits implementation that supports state, but as discussed > integration is hard and that could be a lot of work. > > There are other solutions to explore that could localise the changes. > > > > For example imagine adding some special illegal syntax that a variant of > the compiler (a compiler mode or a subclass > > or...) can deal with and using that to reference trait state. Then > changes are localised to > > - the compiler (to compile the syntax down onto the relevant inst vars) > > - class definition/trait composition (to ensure the state inst vars exist > in the class) > > - shout (to highlight the new syntax) > > - the decompiler (so decompiled trait code displays the new syntax for > trait state access) > > > > Another possibility might be a selector privacy hack. The selectors used > to access state in a trait are known not to > > clash in the trait (they ca be so chosen by the trait author not to > conflict with anything in the trait) but they > > cannot be guaranteed not to clash with a user of the trait. So > post-compile the selectors for the trait's state could > > be changed to private values (keys that existed only in the method > dictionary of the trait user). This doesn't have > > the performance of direct inst var access, but it solves the clash and > privacy issues. > > > > And I expect there are other solutions too. > > > > In summary don't argue for or against stateful traits, instead think > about how to add state to traits whilst having > > the most minimal impact on the rest of the infrastructure. > > > > best > > Eliot > > > > For me, the utility argument is an important one. I don't care about just > making it work, whether I believe in it or not. > It's bad enough that I have to do that at my workplace. Then again, they > are paying me for it. > Whatever. I think you're taking me wrong. I agree that stateful traits are more useful than non. I'm trying to discuss the engineering of them. Are you interestined in realising something you want or are you more interested in scoring points? Or is getting things to work not what you get paid for? Eliot > Cheers, > Florin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2010