Re: Pier-EmailSender and "Contact Us"

> 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

> 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.html
>
> 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
>
> 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?

> 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 <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project