Pier-EmailSender and "Contact Us"

> Hi!
>
> I need to do the typical "Contact Us" form where the user can put the
> name the email and the question and then this email to the webmaster
> email account.
>
> I look there was a Pier-EmailSender  which seems to do what I need.
> However It has different walkbacks in Pier 1.1.1.
>
> Keith Hodges: do you think it's rather to make it work that doing my own ?
>
> It is very simple to reproduce. Just open a fresh Pier 1.1.1 and add
> that widget.
>
> Thanks!!
>
> Mariano

> Keith: should this work on pharo?
>
> Installer install: 'Packages'.
> Installer ss project: 'Beach-Packages'.
>
> Because I am having a warning with Utilities #authorInitialsPerSe
> deprecated. Use instead initialsPerSe.
>
> However, I put "proceed" and my image freezes.
>
> Cheers,
>
> Mariano

>
> 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,
> since Pharo has a more business target and the first question those  
> folks ask, what's the license
> and code ownership like?
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> Mariano Martinez Peck wrote:
>> Keith: should this work on pharo?
>>
>> Installer install: 'Packages'.
>> Installer ss project: 'Beach-Packages'.
>>
>> Because I am having a warning with Utilities #authorInitialsPerSe
>> deprecated. Use instead initialsPerSe.
>>
>> However, I put "proceed" and my image freezes.
>>
>> Cheers,
>>
>> Mariano
> I don't use pharo myself. Goodness knows why they break things as  
> simple
> as author initials.
>
> Keith
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>
> 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

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

> 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

> 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

> 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
>

> 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?
>
>
> On 5-May-09, at 12:33 AM, 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
>>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> 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?

> 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.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 M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

> I'll check it out. Also note that cc-ing [hidden email]
>  will generally be useful.
>
> Cheers,
>  - Andreas
>
> John M McIntosh wrote:
>> 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.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