July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] class variable names: initial cap not enforced

by StÃ©phane Ducasse

On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: > I just loaded the code I have been developing in Pharo into Squeak > (closure VM, using 4.10.2-7179web09.07 image base) and it had one > complaint while loading: > > Squeak (seemingly) requires an initial cap on class variable names. > [Maybe it allows it... but it popped up the debugger on an MC load.] This is fun because I thought only previous version of pharo were doing that > Does Pharo allow the symbol to start with lower case by design, or was > that act of omission? I am merely raising point to make certain it is > an act of commission. We had discussion in the past. class variables should be Uppercased instance variables should be lowercased. I believe that this is part of the semantics and that this is good that the compiler enforces that and reject bad code. Now since lukas complained loudly we removed the checks that we introduced earlier. People cannot say that we are not open and listening. Now the latest version allows you write any shitty code you want, to the point that you can totally confuse yourself by writing instance variable with Uppercase and the inverse too. Stef

July 18, 2009

Re: [Pharo-project] Pharo apparently slow on linux

by StÃ©phane Ducasse

The message search is just a UI for people that do not know the keyboard binding and this is more welcoming. I think that if Ocompletion would be integrated there it would be great Stef On Jul 18, 2009, at 8:46 AM, Adrian Lienhard wrote: > > On Jul 18, 2009, at 08:02 , Schwab,Wilhelm K wrote: > >> Laurent, >> >> I will preface this by saying that I have had a fairly intense week >> with Pharo. I am closing in on a solution to a real problem. I >> greatly miss Dolphin's Browse-it command, and its F12 and shift-F12 >> (definitions/references to a typed selector); the message search has >> its points, but it takes some extra steps to use in comparison to >> the Dolphin features. > > Isn't Ctrl-b (browse selected class name), Ctrl-m (implementors of > selector), Ctrl-n (senders of selector), and Ctrl-shift-n (class > references) doing the same? I almost never use the message search but > always these shortcuts. > > Adrian > >> Back to the topic at hand; let's see if I am following. Start with >> a core image, run a script that installs what looks like a Pharo web >> image, makes a few changes to settings in favor of speed, and you >> get something that you find faster than Pharo?? Did you make the >> same speed selections in Pharo? If so, one wonders what happened >> between core and Pharo-dev/web that Lukas did not do to the core >> image. >> >> Sorry if I'm off base here - it's been a long and very good few days. >> >> Bill >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of laurent laffont >> Sent: Saturday, July 18, 2009 12:45 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pharo apparently slow on linux >> >> >> On Fri, Jul 17, 2009 at 8:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> <mailto:stephane.ducasse@inria.fr>> wrote: >> Hi >> >> David shaffer reported to me in fuzzy way that pharo is slow on >> linux. >> Dear linux users can you report if you experienced the same and >> on which >> machine >> distributions >> vm >> image >> >> please compare the core and the dev (with browser usage) >> >> _______________________________________________ >> >> Hi, >> >> machine: core duo 2.0 GHz, 1 GB RAM (White Macbook, 2007) >> distribution: Archlinux >> vm: exupery pharo-vm-0.15.1b-linux.zip >> images: pharo0.1-10373dev09.07.2 and latest Pharo-Core >> >> Pharo-Core: (System Browser) >> - startup time: instantaneous >> - navigate randomly in browser: 3% - 8% CPU usage >> - find class OrderedCollection: ~10% CPU >> - browse senders of add: time to open 1s, 21% CPU >> >> Pharo-Dev: (Package Browser) >> - statup time: 3s (cold start 5s) >> - navigate randomly in browser: 9% - 15% CPU usage >> - find class OrderedCollection: ~13% CPU >> - browse senders of add: time to open 19s, 48% CPU >> >> Now I'm using Pharo-Core with Luka's scripts (http://code.google.com/p/pharo/wiki/ImageBuildScripts >> ) as it's far more pleasant to use for me. >> >> Laurent >> _______________________________________________ >> 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

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by StÃ©phane Ducasse

can you disable the annotation pane too? Could you also load the packageBrowser so that we can pick the other one too? May be put also the highPerformance on I would also remove the optional buttons because they just take space. (You see I can also be dogmatic). I imgaine that the roundcorner could be disable too to gain some cycles too. Stef On Jul 18, 2009, at 8:55 AM, Damien Cassou wrote: > I've just uploaded a new Pharo image. It is much faster now, but you > won't get the package browsing (only the category browsing). > > http://pharo-project.org/pharo-download > > For all the people who found Pharo slow, please tell me what you think > of this one ! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by StÃ©phane Ducasse

On Jul 18, 2009, at 8:55 AM, Damien Cassou wrote: > I've just uploaded a new Pharo image. It is much faster now, but you > won't get the package browsing (only the category browsing). > > http://pharo-project.org/pharo-download > > For all the people who found Pharo slow, please tell me what you think > of this one ! funnily enough I cannot program with this browser. So I will load the OBpackage one and wait that it gets faster. Stef > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] How to have a faster image

by StÃ©phane Ducasse

> On Sat, Jul 18, 2009 at 12:01 AM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >> I think that pharo (old pharo-dev should contain as less as >> possible). > > Each user means something different by 'as less as possible' (not sure > it's good english though :-)). You want syntax highlighting and > completion to be in. IIRC, Michael has no need for them. Yes but mike does not like refactoring either. So I think that we should find what is reasonable and as I said: http://code.google.com/p/pharo/wiki/Packages then may be we will have three distributions pharo-core pharo pharo-dev Stef

July 18, 2009

Re: [Pharo-project] MD5 in pharo?

by StÃ©phane Ducasse

Yes this is a good idea. Stef On Jul 18, 2009, at 8:41 AM, Adrian Lienhard wrote: > Bill, please note that Esteban just needs a standard hash algorithm. > No encryption. > > Some time ago we discussed including hash functions from Cryptography > in Pharo core. We postponed it then because it seemed that maybe some > people would join and make Cryptography work in Pharo. An OpenSSL > interface would be a very interesting alternative too. > > In any case I think we should add MD5 and maybe some other hash > functions to the core. Will add this to my todo list. > > Adrian > > > On Jul 18, 2009, at 05:09 , Schwab,Wilhelm K wrote: > >> Esteban, >> >> IMHO, the correct path is to write an interface for OpenSSL. >> Ultimately, that should also give us SSL sockets, but long before >> that, it can provide various hashes and cyphers with very little >> effort. I am open on whether the interface should be FFI, Alien, or >> plugin based. One argument for a plugin could come through benefits >> that _might_ acrue to sockets. I have along way to go on Squeak/ >> Pharo external interfacing, so I could be way off here(!!), but I am >> under the impression that plugins can use OS threads, and that could >> greatly simplify getting OpenSSL to not hang the entire image while >> waiting on things to happen to/on a socket; that benefit would come >> at the cost of having to write a plugin. >> >> Another option might be to use FFI/Alien to access the cyphers and >> have a plugin for the SSL sockets. Hopefully someone with Squeak >> external interfacing experience will tell us "where be the dragons" >> with the various options. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Esteban Lorenzano >> Sent: Friday, July 17, 2009 7:25 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] MD5 in pharo? >> >> Hi, >> Some time ago, I read a thread about cryotography, and as far as I >> remember, some body says about integrate the basic algoritms (MD5 >> and maybe others) as part of the pharo core. >> Well... now I need to use MD5 and cryptography package is not >> working well (it opens a debugger each time I save my image). >> >> I wonder if there are another package with MD5? >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by StÃ©phane Ducasse

which version are you using because this was removed at least 2 weeks ago? Stef > In Pharo, I originally create created the class with this: > > Object subclass: #FaFnBasicKeyLabelAssociations > instanceVariableNames: '' > classVariableNames: 'theSingleton' > poolDictionaries: '' > category: 'FA-FinanceMeta' > > And it compiled without complaint in Pharo. > > It was Squeak that complained during a load using Monticello. And > just now, I reverted back to the lower case version (as exampled up > above) and throws an "Error: theSingleton class variable name should > be capitalized; proceed to include it anyway" ... and it lets me > proceed. (I didn't read the full message previously and changed it.) > So Squeak allows it, but complains where Pharo didn't. > > Sounds like it was "by design" in both cases. > > (I have three spinoff questions which I will put forth with a > different subject line.) > > Thanks, > Cam > > > On Jul 17, 2009, at 6:04 PM, StÃ©phane Ducasse wrote: > >> this is strange can you show us the class definition. >> >> We removed the hard check that >> enforced that classVariable should be capitalized and instvar >> starting >> with a lower case. >> >> Lukas wrote some smallLint rules to check that >> >> Stef >> >> On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: >> >>> I just loaded the code I have been developing in Pharo into Squeak >>> (closure VM, using 4.10.2-7179web09.07 image base) and it had one >>> complaint while loading: >>> >>> Squeak (seemingly) requires an initial cap on class variable names. >>> [Maybe it allows it... but it popped up the debugger on an MC load.] >>> >>> Does Pharo allow the symbol to start with lower case by design, or >>> was >>> that act of omission? I am merely raising point to make certain it >>> is >>> an act of commission. >>> >>> -Cam >>> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by StÃ©phane Ducasse

but lukas what are you saying? We removed them so what is the problem? Stef On Jul 18, 2009, at 8:28 AM, Lukas Renggli wrote: > Yes, I hate all these warning that the original compiler showed. It > just slows the development down and limits the use of the language. > There is really no need for the compiler to check for coding > conventions, that's what Lint is for. > > Lukas > > 2009/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> this is strange can you show us the class definition. >> >> We removed the hard check that >> enforced that classVariable should be capitalized and instvar >> starting >> with a lower case. >> >> Lukas wrote some smallLint rules to check that >> >> Stef >> >> On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: >> >>> I just loaded the code I have been developing in Pharo into Squeak >>> (closure VM, using 4.10.2-7179web09.07 image base) and it had one >>> complaint while loading: >>> >>> Squeak (seemingly) requires an initial cap on class variable names. >>> [Maybe it allows it... but it popped up the debugger on an MC load.] >>> >>> Does Pharo allow the symbol to start with lower case by design, or >>> was >>> that act of omission? I am merely raising point to make certain it >>> is >>> an act of commission. >>> >>> -Cam >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

but nobody care about what you did :) Stef BTW it would be good to see if your stream implements the same interface as the great GNU smalltalk ones. Sorry I could not resist :( I'm in a really bad mood On Jul 18, 2009, at 12:26 AM, Damien Cassou wrote: > On Thu, Jul 16, 2009 at 5:04 PM, Lukas Renggli<renggli(a)gmail.com> > wrote: >> ((aCollection readStream >> select: [ :e | ... ]) >> collect: [ :e | ... ]) >> contents >> >> will iterate only once. Furthermore the second approach allows any >> combination of any of the enumeration methods, not just a few >> predefined ones. Also the implementation is less error prone, because >> it just uses the standard methods on collection and stream. > > This is what I did in Nile: > > NSCollectionStream>>select: aBlock > "Returns a new stream which contains a selection of elements in the > receiver. All elements of the receiver are passed to aBlock. This is > really like Collection>>select:." > ^ NSSelectStream selectBlock: aBlock inputStream: self > > NSSelectStream being a kind of stream whose #next method iterate on > the input stream: > > NSSelectStream>>next > self inputStream do: [:each | (selectBlock value: each) ifTrue: > [^ each]]. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] Pharo apparently slow on linux

by Damien Cassou

2009/7/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I did find Pharo still slow. Please try latest Pharo and tell me what you think. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 18, 2009