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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Mariano Martinez Peck wrote:
> 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 Beach project, I think you will find it a bit more workable there. I dont think it has any dependencies upon beach itself. www.squeaksource.com/BeachPostBox-Seaside Keith _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Thu, Apr 30, 2009 at 6:29 PM, Keith Hodges <[hidden email]> wrote:
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. Thanks in advance, Mariano
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> Thanks! Now, suppose I want to use it and I want to put the Beach > dependency I should need the following information: > The Email Sender is not dependent upon Beach. > 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. The information you seek is in the meta-data stored in the Beach-Packages package, which itself depends upon Sake/Packages. This can be installed via Installer install: 'Packages'. > 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 Sun, May 3, 2009 at 3:42 PM, Keith Hodges <[hidden email]> wrote:
_______________________________________________ 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 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, 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 |
but this is true that the author code should be cleaned because it was
and this is still a mess. Stef On May 4, 2009, at 6:40 PM, 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, > 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by keith1y
Because Utilities is giant anthrax.
Stef On May 4, 2009, at 3:10 PM, Keith Hodges wrote: > 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by johnmci
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 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 |
>>>
>> >> >> 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. Yes you are right. But we have pretty limited resources. > >> 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. So do not use pharo! Please don't! Stef > > > 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 |
In reply to this post by keith1y
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 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?" _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by stéphane ducasse-2
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 |
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? > > > 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 > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by johnmci
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 = = = ======================================================================== _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by stéphane ducasse-2
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 <[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 |
In reply to this post by johnmci
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 > > -- > =========================================================================== > 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 |
I note if you go to the squeak.org website and tap but report it dumps
you into Mantis. However for novices that likely isn't helpful and the link to a mail message from Feb isn't something anyone is going to find, or mmm or remember. On 5-May-09, at 9:05 AM, Andreas Raab wrote: > 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 -- = = = ======================================================================== 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 |
Free forum by Nabble | Edit this page |