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

[Pharo-project] SubpaneDividerMorph question of existence
by StÃ©phane Ducasse May 6, 2009

May 6, 2009

Hi buzy pharoers I found a removal script from etoyers and they removed SubpaneDividerMorph. I check in Pharo this class has no subclass and nobody uses it. Stef

2 2

[Pharo-project] OBScript in ScriptLoader
by StÃ©phane Ducasse May 6, 2009

May 6, 2009

Begin forwarded message: > From: David RÃ¶thlisberger <roethlis(a)iam.unibe.ch> > Date: May 5, 2009 11:05:03 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: may be I reloaded moose into moose > > >> and the OB script was run twice leading to inconsistencies. > > okay, together with Damien Cassou I found out that his current > version of 'ScriptLoader loadOB' is not entirely correct, it doesn't > load all packages required for OB... > I fixed that in PharoInbox in ScriptLoader-david_roethlisberger.854. > The problem you got should now be solved with this new loadOB method. > > David >

1 0

[Pharo-project] Fwd: may be I reloaded moose into moose
by StÃ©phane Ducasse May 6, 2009

May 6, 2009

Begin forwarded message: > From: David RÃ¶thlisberger <roethlis(a)iam.unibe.ch> > Date: May 5, 2009 11:05:03 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: may be I reloaded moose into moose > > >> and the OB script was run twice leading to inconsistencies. > > okay, together with Damien Cassou I found out that his current > version of 'ScriptLoader loadOB' is not entirely correct, it doesn't > load all packages required for OB... > I fixed that in PharoInbox in ScriptLoader-david_roethlisberger.854. > The problem you got should now be solved with this new loadOB method. > > David >

1 0

[Pharo-project] Fwd: Pier-EmailSender and "Contact Us"
by StÃ©phane Ducasse May 5, 2009

May 5, 2009

> > marcus told me once that scriptloader was already getting a big > class with a lot of method. > For now I do not have something else than removing all tests and > scriptloader. > I removed a lot of bookMorph but still it is hanging there :) > > Stef > > On May 5, 2009, at 5:53 PM, John M McIntosh wrote: > >> No, the intent is preserve the images as they are shipped see >> >> http://www.mobilewikiserver.com/ST80Docs.html >> & >> http://www.mobilewikiserver.com/SqueakDocs.html >> >> However if you have a script that removals all the *extra* things >> that people could run for server images that would be helpful at >> least to me, >> I realize that most folks don't care about 8MB, but on tiny devices >> that 8MB is golden... >> >> >> On 5-May-09, at 1:28 AM, stÃ©phane ducasse wrote: >> >>> John >>> >>> for your images did you remove tests and other unnecessary stuff? >>> The 10300 is 12.7mb without removing all kind of crap like the >>> scriptLoader and the tests. >>> I hope that we will be able to slowly get more and more modular: >>> once project/bookmorph are gone. >>> I imagine (did not read carefully the details of we got about the >>> chase of the unclosed handles) >>> that the startup behavior could be also improved. >>> >>> Stef >>> >>> On May 5, 2009, at 10:17 AM, John M McIntosh wrote: >>> >>>> Tsk, well I was off to bed, but thought I should make some notes. >>>> >>>> Last night I push out two electronic books showing smalltalk-80 >>>> based source code to Apple for iPhone review. >>>> One was based on the latest pharo of end of april 09 with >>>> closures the other based on the sq3.10.2-719web09.04.1.zip no >>>> closures. >>>> The two e-books apps are identical except for the code base. >>>> >>>> I dropped the wikiserver stuff into both, happy since the changes >>>> required were non-existent for pharo and one or two for sq3.10.2 >>>> >>>> (a) The sq3.10.2 version was missing some of the extra add-on >>>> Pier stuff, and has the LGPL Swazoo which makes some folks run >>>> for the fire exit. >>>> >>>> (b) The pharo image is 20.2 mb, the sq3.10.2 is 25.2 mb, so 5MB >>>> bigger. >>>> >>>> (c) The pharo image needed about 35mb of ram to be happy, the sq >>>> 3.10.2 about 40mb >>>> (c2) The pharo image ramps to the welcome screen using 19.23 mb >>>> ram, 97.12mb virtual >>>> (c3) The sq 3.10.2 image ramps using 19.05mb and 102.12 virtual. >>>> This makes sense because I avoid a full gc and doing >>>> allInstances, so the code base is really startup logic and seaside. >>>> (I had to fix the sq 3.10.2 image because of ignored bug using >>>> allInstances I reported years back, never fixed, but fixed in >>>> pharo last fall). >>>> >>>> (d) The pharo image needs 2.6 to 6.6% cpu on the iphone at idle, >>>> the sq 3.10.2 needs 8 to 18% >>>> (to be fair here I could bring some fixes into the 3.10.2 image >>>> to reduce the cpu time, but really those fixes should have gone >>>> in years ago...) >>>> >>>> (e) The sq 3.10.2 book feels sluggish. the pharo less so. So the >>>> sq 3.10.2 excessive CPU usage is the usability killer here. >>>> >>>> To be fair WikiServer is happy with 20MB of ram with a 10.5MB >>>> image size, and runs with a 0 to 0.9% cpu usage at idle, starup >>>> ram of 11.69, virtual memory of 90.34 >>>> Lots of hours to get there.. >>>> >>>> PS I see the etoys image is only 16.4 MB, well that doesn't >>>> include seaside etc, but if you need that you should start with >>>> etoys as the base and add pier and seaside, less bloated I'd >>>> guess, and supported for that etoy feature set you need? >> >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> > > > >

1 0

Re: [Pharo-project] Pier-EmailSender and "Contact Us"
by John M McIntosh May 5, 2009

May 5, 2009

Well then for http://bugs.squeak.org/view.php?id=6581 who would stick that into 3.11? Let alone that I'm looking at 3.10.2 image Added (partly) http://bugs.squeak.org/view.php?id=7348 On 5-May-09, at 2:07 AM, Andreas Raab wrote: > Hi John - > > John M McIntosh wrote: >> (I had to fix the sq 3.10.2 image because of ignored bug using >> allInstances I reported years back, never fixed, but fixed in pharo >> last fall). > > [... snip ...] > >> (to be fair here I could bring some fixes into the 3.10.2 image to >> reduce the cpu time, but really those fixes should have gone in >> years ago...) > > Just as an FYI, there is now a well-defined process for contributing > stuff to 3.11: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134095… > > If these fixes are on Mantis all you need is to provide an installer > script and update its status accordingly. Just try it! > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] Author in Squeak (Thread moved over from smallwiki)
by Keith Hodges May 5, 2009

May 5, 2009

stÃ©phane ducasse wrote: > Apparently there is no value in what we are doing: I didn't say that, is that what you believe? > removing etoy, removing a lot of ***SHIT*** from squeak, fixing tons > of bugs (the bug archives > is full of fixed bugs and fixes problems), writing more tests, > cleaning a HUGE spaghetti mess > (preferences....). Utilities is one of this crap. Not much use to me I am afraid, if my code cant work interoperably between squeak and pharo, then I cant port any of my existing projects over. Hmm what is needed for this... oh yes Installing and package loading tools that are managed outside of any one image as a common resource for everyone, that all those wise and knowledgeable about such things should contribute to. This needs political will to promote collaboration at this level. The problem with this idea is that I myself am not good enough nor do I have the time to realise the vision. I wonder where the people that do have the knowledge to do this are. Oh yes they are all working on Pharo! So that leaves the rest of us scuppered, thanks... You still don't understand, my argument against pharo is NOT that you will not use my code, it is that you will NOT contribute resources to the community in such a way as can be used for the benefit of all. i.e. MC1.5 is a project outside of Pharo and Squeak that you could contribute to, but you wont. So is SUnit, and SSpec etc. Furthermore those projects may be doomed to failure if you dont contribute, after all your team has the knowledge of traits which no one else has, I certainly don't. MC1.5 needs your team's input, and has needed it for over a year, yet you will not see it as something worth contributing to for the benefit of all. So MC1.5 is dead in the water and 2 years of work has been wasted. > And of course Author could be made a bit better. Author, what is Author, Author doesn't exist for Squeak users. If you would think in a community minded way, Author would be another external package, that is available for all. > Of course there is no preference to avoid to warn on deprecated call! > > Apparently you only do stuff right. Perfect! I didn't say that, is this what you believe? I am saying the opposite, and I have always been saying the opposite. I need others to collaborate to make these ideas a success. I am primarily an ideas man, my code is not that brilliant until the third or fourth iteration. My concern is that the Pharo team continuously seek to compete not to contribute. > But we will do it our way. Period. Exactly the opposite attitude to what is needed in this situation. No wonder we are not getting anywhere. Keith

3 2

Re: [Pharo-project] Pier-EmailSender and "Contact Us"
by Tudor Girba May 5, 2009

May 5, 2009

Hi guys, I believe this mail exchange belongs to the Pharo and not to the Smallwiki mailing list :). Cheers, Doru On 5 May 2009, at 09:33, stÃ©phane ducasse wrote: > Apparently there is no value in what we are doing: > removing etoy, removing a lot of ***SHIT*** from squeak, fixing tons > of bugs (the bug archives > is full of fixed bugs and fixes problems), writing more tests, > cleaning a HUGE spaghetti mess > (preferences....). Utilities is one of this crap. And of course > Author could be made a bit better. > Of course there is no preference to avoid to warn on deprecated call! > > Apparently you only do stuff right. Perfect! But we will do it our > way. Period. > > May be you should put your code under GPL or something like that > we will not even thing that we should have a look at it. > > What we are doing is totally useless for you. Excellent! Continue to > bark if this > helps you. > > Stef > > > On May 4, 2009, at 11:08 PM, Keith Hodges wrote: > >> John M McIntosh wrote: >>> >>> On 4-May-09, at 6:10 AM, Keith Hodges wrote: >>> >>>> I don't use pharo myself. Goodness knows why they break things as >>>> simple >>>> as author initials. >>>> >>>> Keith >>> >>> >>> Er because of the re-licensing of the squeak code base and the >>> discovery that using JUST >>> initials made the chore very difficult to determine who wrote the >>> code. So they enforce names now >> Thats not my point my point is that they broke the code. >> >> The way forward is to engineer a solution, not just hack something in >> that breaks what everyone has already. >> >> One could propose a new loadable Author package that handles >> everything >> and publish that for everyone that cares to use it, rather than >> forcing >> code to break and all manner of nightmares managing two streams per >> package. >>> since Pharo has a more business target and the first question those >>> folks ask, what's the license >>> and code ownership like? >> I use Squeak for Business, and I will continue to do so. The whole >> approach behind pharo is flawed because it is dedicated to making >> more >> work for me the coder of stuff that is for all. This is one instance >> where I feel entirely justified in saying I told you so. >> >> Keith >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

1 0

[Pharo-project] [ANN] Z39.50 FFI Client (ZOOM binding)
by HernÃ¡n Morales Durand May 4, 2009

May 4, 2009

This is a binding of the ZOOM Yaz client for Squeak and Pharo [1]. To install: 1) Download the compiled library (DLL or SO) from http://www.indexdata.dk/yaz/ and copy the yaz3.dll (or equivalent in Unix) to your Squeak directory. 2) Make sure you have installed FFI package in your image: 3) If you have Installer in your image doIt this: Installer ss project: 'Z3950'; install: 'Z3950'; install: 'Z3950Tests'. To use: Right now you must know the infamous PQF/PQN query syntax (I'm working on it). Connect to a Z39.50 server and make a query for records with author Foucault : Z3950Client new server: #Alameda; query: '@attr 1=1003 foucault'. or using a random server for Kant Z3950Client new query: '@attr 1=1003 kant'. Best regards HernÃ¡n [1] SqueakSource page link : http://www.squeaksource.com/Z3950.html

4 7

May 4, 2009

> > Hi > > I would like to know if somebody extended MC to be able to > automatically publish the difference (mcz files) that are in the > package-cache to a squeaksource server. > > Stef > > >

1 0

[Pharo-project] [ANN] BobsBrowser again
by HernÃ¡n Morales Durand May 4, 2009

May 4, 2009

Dear all, As result of a strange exercise in software resurrection, you have the chance of using the BobsBrowser [1] again , which is an exploration of different ways of browsing code. To install please evaluate: Installer ss project: 'BobsBrowser'; install: 'BobsBrowser'. You can start a new browser using the World menu or by evaluating: BobsBrowser browseAllClasses The creator of this goodie was Bob Arning, enjoy it. Best regards, HernÃ¡n [1] http://www.squeaksource.com/BobsBrowser.html

3 9