October 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Seaside and Apache
by Bill Schwab Oct. 8, 2008

Oct. 8, 2008

Hello all, After a few days of getting almost nothing (even in logs, which was driving me nuts), I tried a different approach and had a self-signed https Apache proxying Seaside. I will start to congratulate myself when I can reproduce it. Toward that end, I have been writing some truly ugly code to capture how to do some things. First, I have ported part of some OpenSSL tools I use with Dolphin, specifically the part the builds self-signed certificates. In short, I found recent versions of OpenSSL unbuildable with MinGW (please feel encouraged to prove me wrong on this one!), and the pre-built openssl.exe I found did not work properly on Win32. Since Apache now ships with mod_ssl and OpenSSL libraries, all I needed was a working openssl.exe. The Penguin to the rescue, so I altered the certificate factory to write a shell script; it could be integrated with OS Process to "just do it." Not fully tested yet, I also added some things to get Squeak/Pharo running as a service on Windows via the resource kit tools. Configuring Apache is still something of a mystery to me. I am content with having everything transported by SSL, and to force the use of the correct URLs (at least for now). Below please find some sample output from my evolving tool. The goal is to generate a nearly correct configuration based on the local host and registered Seaside applications. It found more than shown below, but please have a look at it to see if I am a mockery of the location statements. If something usable results from this, I will make it available. Bill # Apache-related concepts herein were shamelessly stolen from sources including: # http://lists.squeakfoundation.org/pipermail/seaside/2007-November/015181.ht… # http://leftshore.files.wordpress.com/2006/10/apacheandseaside.txt Listen 443 SSLEngine On SSLCertificateFile conf/ssl/wherever.cert SSLCertificateKeyFile conf/ssl/wherever.key SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown ProxyRequests Off ProxyPreserveHost On <Proxy *> Order deny,allow Allow from none </Proxy> <Location /seaside/bibtex> Order deny,allow Allow from all ProxyPass http://localhost:8080/seaside/bibtex ProxyPassReverse http://localhost:8080/seaside/bibtex </Location> <Location /seaside/browse> Order deny,allow Allow from all ProxyPass http://localhost:8080/seaside/browse ProxyPassReverse http://localhost:8080/seaside/browse </Location> <Location /seaside/examples/counter> Order deny,allow Allow from all ProxyPass http://localhost:8080/seaside/examples/counter ProxyPassReverse http://localhost:8080/seaside/examples/counter </Location> Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

1 0

[Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo
by Simon Kirk Oct. 7, 2008

Oct. 7, 2008

Hi all. Gary and I decided we ought to give out an MCZ of our fixes that we've put together over the last two years. Obviously some of those we found have been pulled into Pharo already, but the attached MCZ represents those that we think are still relevant :) This is a rough list of the fixes: 1. Fixed flaky borwser comment text area sometime not showing. 2. Added getArgumentPermutation to support RefactoringEngine. 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner to correctly align the first line of text when centered/justifed etc. 4. Added more constant names to Character class. 5. Modified ConnectionQueue to not accept connections when queue is full. 6. Changed GrafPort to answer a MultiDisplayScanner when appropriate (allows subclasses of MultiNewParagraph). 7. NaturalLanguageTranslator startup postion move to after PasteUpMorph since it will show a progress bar. 8. Fix to Random>>nextInt: to allow large numbers which would be out of range if using Floats (as mentioned recently on dev, use of Floats is dodgy anyway...) 9. Changed TranscriptStream>>clear to use a new buffer (was just reset which could leave a massive collection). 10. Changed RemoteString to handle concurrent processes safely. This one's particularly interesting: we were load-testing our Seaside app here and getting lots of syntax errors when hitting the image with around the 20 concurrent processes due to source file access. After this change we were hitting it with approximately 500 concurrent processes, and the failure was in the Java load tester (it timed out). Hope just submitting a .mcz is OK! :) Cheers, Simon and Gary ****************************************************************************************************************************************** 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

4 17

[Pharo-project] about ifEmptyOrNil:
by StÃ©phane Ducasse Oct. 7, 2008

Oct. 7, 2008

Hi I would like to have your take on that one: isEmpty "Answer whether the receiver contains any elements." ^self size = 0 Why do we need ifEmptyOrNil: isEmptyOrNil "Answer whether the receiver contains any elements, or is nil. Useful in numerous situations where one wishes the same reaction to an empty collection or to nil" ^ self isEmpty why can we use isEmpty: or ifEmpty: aBlock ifEmpty: aBlock "Evaluate the block if I'm empty" ^ self isEmpty ifTrue: aBlock Then from an implementation point of view ifEmptyOrNil: is bogus since it never returns nil (or should not and is also ill-specified). I checked ANSI and this is really a boolean. I'm the mood to deprecate this method. Stef

7 10

[Pharo-project] about idiots :)
by StÃ©phane Ducasse Oct. 7, 2008

Oct. 7, 2008

Hi marcus Try to stop thinking that making errors is bad. This is a christian ideology that may block your way of looking at the world in a open way. You know like "good and bad". (Watch for example Spirit away for example I'm always fascinated by the fact that we are looking for who are the good and bad). Oscar would say "live and learn". Making error is part of life. Period! Being stupid is when - you repeat errors without learning from them. - if you would not take action after. So introducing a bug is NOT A PROBLEM and nobody is stupid. We are dealing with a really complex program. We will do mistakes, many in fact. We may break the system and put it on its knees. But we will learn and fix or rollback. Easy in computer world we clone duplicate. Imagine it you would be a drawer on expensive paper with ink that you cannot erase!! Simple. So marcus dont be stupid to think that people making mistakes are idiots. They are not! You and me are far from stupid and we will do mistakes. For sure and we will learn from them. Pharo is the proof of it :) So do not let you fun gets spoiled by this oversimplistic view on the world. Stef PS: bookmark this mail because this is the last one on that topics.! When you feel idiots read it. PSPS: one young guy at IBM made IBM lost 1 Millions dollars, so he can to see his boss to resign. The boss said no way, we reject this, we invested on you 1 Million dollars. Nice!

3 3

[Pharo-project] Some clearifications
by Marcus Denker Oct. 7, 2008

Oct. 7, 2008

Hi, Maybe I need to make some thing clear 1) There will be mistakes. When integrating bugfixes and enhancements, it is impossible to not make mistakes. The problem is that one can not check every single fix, this is just not possible. And even if it would be checked line-by-line and very closely, there would be new bugs. It is just impossible that this does not happen. The problem is of course that the people doing the integration everytime a bug is introduced look (and feel) like idiots. It would help if people would not strengthen this feeling... if I do something where I feel like an idiot most of the time, at some point I will stop. 2) There is only limited time. We can not look at every submission directly, we can not fix every bug (even those introduced recently) very fast. This does not mean that we don't like the person who submited something (or that this person did something wrong). It *especially* does not mean to discriminate againt projects. e.g. if Seaside can't be loaded because of somet stupid bug, this does not mean that seaside is not wanted or something like that. 3) There is a lot of stuff that should be done ... and the only reason it is not done is lack of time. It's not because we are idiots. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

7 9

[Pharo-project] Changing the name of the Pharo mailing list
by Adrian Lienhard Oct. 7, 2008

Oct. 7, 2008

Stef, Is it possible to change the long name of the mailing list that is used for pharo-project(a)lists.gforge.inria.fr? It currently is "An open mailing list to discuss any topics related to an open-source Smalltalk" I would prefer "The genera-purpose Pharo developer list" or something similar that is shorter and includes Pharo. Its just a detail, but it would be worth to change if it does not take much time... Adrian ___________________ http://www.adrian-lienhard.ch/

6 7

Re: [Pharo-project] About reusing tests via traits
by Bill Schwab Oct. 7, 2008

Oct. 7, 2008

Stef, Alexandre, I will grant you a head start: if you have to copy code, it's not the same thing. My next question would be whether a competitive "say it once" design could be realized with composition and single inheritance. Alexandre refers to use cases the show an advantage, and I do not dispute that. I am mostly just curious at this point. Is there more or less overhead specifying the traits vs. arranging for good composition? My guess would be that the traits win, but I have no data to support that. Is there a performance advantage either way? Unless traits are (whether used or not) very expensive at runtime, I would argue that anything that gets us better test coverage is a good thing. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/06/08 2:32 AM >>> you can achieve the same with copy and paste or code generation. What is nice with traits is that they represent a bloc of coherent behavior that can be parametrized. Load the latest Collection-Tests from the pharo source. This is just the start but this is quite cool. Check TEmptyTest. It is applied to OrderedCollection, Basg, Set, Array, Interval (and could be to others too). Yesterday I got a really nice presentation of Miro by alain plantec and he is also using traits. Stef On Oct 6, 2008, at 3:35 AM, Bill Schwab wrote: > Stef, > > Dumb question: are traits essential to it, or simply a way of > achieving > it? Just curious, as I am still trying to put traits in perspective. > They strike me (so far, right or wrong) as a form of multiple > inheritance, which I have assumed (right or wrong) is often not needed > with clever aggregation/composition of single-inheritance objects. > One > very slick use of multiple inheritance in C++ provides an easy way to > implement COM objects with multiple interfaces - not that I have any > desire to do that, but it is slick for C++. Whether that says > something > about multiple inheritance's strengths or about C++'s weaknesses, I'm > not sure :) > > Pearls of wisdom will be eagerly assimilated. > > Bill > > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/05/08 5:37 PM >>> > Hi guys > > I did a fun coding session in the train to brest. I started to code > collection tests > as traits (as damien did for stream) and this is reallllly cool. > > I could write some tests and apply them to > OrderedCollection, Set, Bag, Interval..... > I will publish that and continue. I imagine that the coverage for > Collection is > increase a lot. > > Stef > > _______________________________________________ > 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

3 3

Oct. 7, 2008

Hi adrian could you explain the logic behind this code in the traits tests self c6: (self createClassNamed: #C6 superclass: ProtoObject uses: { }). ProtoObject removeSubclass: self c6. self c6 superclass: nil. Especially the ProtoObject tx Stef

2 1

Oct. 7, 2008

I would really like to have a way to specify that a class is abstract. For example I would like to be able to write a test as follow self assert: (Collection allSubclasses reject: [:each each isAbstract ]) new isEmpty now saying that isAbstract is if a class has one method sending subclassResponsibility is not really good for me. May be we could have something like isAbstract ^ self declaredAsAbstract or: [ (self whichSelectorsReferToSymbol: #subclassResponsibility) isEmpty not] Stef

4 6

Oct. 7, 2008

we will check! Stef On Oct 7, 2008, at 3:42 AM, Rob Rothwell wrote: > Hello, > > I would like to be able to share my pharo findings with the list, > but seem unable to post to pharo-project(a)lists.gforge.inria.fr. > > Can anyone help? I have registered, received confirmation, and > verified... > > Thanks, > > Rob > > ---------- Forwarded message ---------- > From: <pharo-project-owner(a)lists.gforge.inria.fr> > Date: Wed, Oct 1, 2008 at 6:39 AM > Subject: pharo0.1-10074dev08.09.2.image > To: r.j.rothwell(a)gmail.com > > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > >

1 0