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

Thanks! Now, suppose I want to use it and I want to put the Beach dependency I should need the following information:

1) which are the necessary packages from MC to install 2) in which order should I install them 3) An explanation somewhere which is each package for. I saw some mails in your ANN but there are several packages more.

I look at google code wiki and squeaksource wiki but I didn't found any information. I am creating a Pier application and would be nice to detail know how to integrate beach with Pier.

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: 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 <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ====================================================================== _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 4-May-09, at 6:10 AM, Keith Hodges wrote: 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 wrote: 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. 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

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

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

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?

I'll check it out. Also note that cc-ing release(a)lists.squeakfoundation.org 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… >> >> 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

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 M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================

On Mon, May 4, 2009 at 10:10 AM, Keith Hodges &lt;keith_hodges(a)yahoo.co.uk <mailto:keith_hodges@yahoo.co.uk>> wrote: Mariano Martinez Peck wrote: I don't use pharo myself. Goodness knows why they break things as simple as author initials. Please. Come back to the original thread. Is there another working way of loading Beach on Pharo ? A MC script or something like that ? I know you don't use Pharo but consider this as a way of expanding, testing and even improving Beach. Cheers, Mariano