30 Apr
2009
30 Apr
'09
9:45 p.m.
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
30 Apr
30 Apr
11:29 p.m.
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
The code I am using myself based on this code has been moved into the
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
3 May
3 May
6:50 p.m.
On Thu, Apr 30, 2009 at 6:29 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk>wrote;wrote:
Mariano Martinez Peck 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
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
The code I am using myself based on this code has been moved into the
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
8:42 p.m.
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
4 May
4 May
1:09 a.m.
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 <keith_hodges(a)yahoo.co.uk>wrote;wrote:
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
3:10 p.m.
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
6:40 p.m.
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 <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
9:57 p.m.
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 <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
11:08 p.m.
John M McIntosh wrote:
On 4-May-09, at 6:10 AM, Keith Hodges 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 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?
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
5 May
5 May
9:27 a.m.
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
9:33 a.m.
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:
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 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?
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 
9:36 a.m.
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:
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
John M McIntosh wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
On 4-May-09, at 6:10 AM, Keith Hodges 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 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?
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
10:17 a.m.
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 <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
10:28 a.m.
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 <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
5:53 p.m.
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
=
=
=
========================================================================
10:18 p.m.
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
=
=
=
=
=
======================================================================
11:07 a.m.
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
5:49 p.m.
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:
--
=
=
=
========================================================================
John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
(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
6:05 p.m.
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:
--
===========================================================================
John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
(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
6:09 p.m.
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
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
--
=
=
=
========================================================================
John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
6:27 p.m.
Yes, good point. I've put it on the agenda for the board meeting:
http://squeakboard.wordpress.com/2009/04/22/initial-agenda-for-may-7th-2009/
Cheers,
- Andreas
John M McIntosh wrote:
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
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
--
===========================================================================
John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
4 May
4 May
10:01 p.m.
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
12 May
12 May
1:54 a.m.
On Mon, May 4, 2009 at 10:10 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk>wrote;wrote:
Mariano Martinez Peck wrote:
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
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
3:48 a.m.
Mariano Martinez Peck wrote:
On Mon, May 4, 2009 at 10:10 AM, Keith Hodges
<keith_hodges(a)yahoo.co.uk <mailto:keith_hodges@yahoo.co.uk>> wrote:
Mariano Martinez Peck wrote:
I think I mentioned Beach-Packages, although written as executable
metadata has not been tested because I have not had to load these
packages into an image as yet. So I suggested that you Browse the
package, and use the metadata to work out what order to load things in.
MC1.5 theoretically supports out of order loading so why not just load
all the packages in the Beach repo. If that doesnt work then simply load
them all twice.
Keith
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.
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
5711
days inactive
5723
days old
23 comments
6 participants
participants (6)
-
Andreas Raab -
John M McIntosh -
Keith Hodges -
Mariano Martinez Peck -
stéphane ducasse -
Tudor Girba