Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
This is a great idea!
Alex
2013/1/23 Ron Teitelbaum ron@usmedrec.com
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Thank you very much, Ron. Now folks, let's get out there and use this!
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
The install script is
Installer ss3 project: 'AndreasSystemProfiler'; install: 'AndreasProfiler'.
Thanks!
frank
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 24 January 2013 16:08, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
And rip out the existing profiler? I could +1 that. Mainly, my first reaction to "should Foo go in the base image?" is "hell no". But this _replaces_ an _existing_ thing.
But then, we should _still_ have an SM entry, if only for 4.4! (And maybe a bit of Pharo love, too. If we can give SM lots of love, I see no reason for it to be a _Squeak_Map only. We already have the tags...
frank
On Thu, Jan 24, 2013 at 9:26 AM, Frank Shearar frank.shearar@gmail.comwrote:
And rip out the existing profiler? I could +1 that. Mainly, my first reaction to "should Foo go in the base image?" is "hell no". But this _replaces_ an _existing_ thing.
I'd say leave this on SqueakMap move the existing profiler to SqueakMap as well. We can include it in the build script for the "full" image we'll release for 4.5.
Colin
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
My quick two cents is that I agree wholeheartedly with Chris. There is tons of stuff in Morphic like Nebraska, Etoys and things like MVC and Universes that could be made Squeakmap packages before something like the profiler. These would also seem to give a far greater savings in terms of class count and LOC, than the comparatively small profiler.
On Fri, Jan 25, 2013 at 10:05 AM, Chris Muller asqueaker@gmail.com wrote:
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the
profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut,
slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can
scream and leap in the dark."
My two cents is that the profiler should be an external package that is brought into a minimal core at build time if desired. Now us the time to start doing that sort of thing otherwise it will be stuck in the base image and no one will know how to get it out.. The other packages as well of course, whether at build time for a release or as a later customization for individual users.
Ken, from my iPhone
On 2013-01-25, at 11:22, Jeff Gonis jeff.gonis@gmail.com wrote:
My quick two cents is that I agree wholeheartedly with Chris. There is tons of stuff in Morphic like Nebraska, Etoys and things like MVC and Universes that could be made Squeakmap packages before something like the profiler. These would also seem to give a far greater savings in terms of class count and LOC, than the comparatively small profiler.
On Fri, Jan 25, 2013 at 10:05 AM, Chris Muller asqueaker@gmail.com wrote:
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
On 25 January 2013 18:34, Ken G. Brown kbrown@mac.com wrote:
My two cents is that the profiler should be an external package that is brought into a minimal core at build time if desired. Now us the time to start doing that sort of thing otherwise it will be stuck in the base image and no one will know how to get it out.. The other packages as well of course, whether at build time for a release or as a later customization for individual users.
Well, it is already an external package. The argument would be "it can't get entangled with the base image if it stays that way". Which is fair enough.
It _is_ a critical dev tool, and (a) devs can load it into their own custom images and (b) we have a release script that can take the clean fully updated image from CI and load it in as part of the ReleaseSqueakTrunk job. Installer _might_ need a bit of love to do this; I don't recall off-hand.
frank
Ken, from my iPhone
On 2013-01-25, at 11:22, Jeff Gonis jeff.gonis@gmail.com wrote:
My quick two cents is that I agree wholeheartedly with Chris. There is tons of stuff in Morphic like Nebraska, Etoys and things like MVC and Universes that could be made Squeakmap packages before something like the profiler. These would also seem to give a far greater savings in terms of class count and LOC, than the comparatively small profiler.
On Fri, Jan 25, 2013 at 10:05 AM, Chris Muller asqueaker@gmail.com wrote:
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
This leads us to the discussion of building different 'distributions' or releases which we had many times in the past.
This time the situation is substantially different as we now have a continuous integration server which allows to do this.
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
--Hannes
On 1/25/13, Frank Shearar frank.shearar@gmail.com wrote:
On 25 January 2013 18:34, Ken G. Brown kbrown@mac.com wrote:
My two cents is that the profiler should be an external package that is brought into a minimal core at build time if desired. Now us the time to start doing that sort of thing otherwise it will be stuck in the base image and no one will know how to get it out.. The other packages as well of course, whether at build time for a release or as a later customization for individual users.
Well, it is already an external package. The argument would be "it can't get entangled with the base image if it stays that way". Which is fair enough.
It _is_ a critical dev tool, and (a) devs can load it into their own custom images and (b) we have a release script that can take the clean fully updated image from CI and load it in as part of the ReleaseSqueakTrunk job. Installer _might_ need a bit of love to do this; I don't recall off-hand.
frank
Ken, from my iPhone
On 2013-01-25, at 11:22, Jeff Gonis jeff.gonis@gmail.com wrote:
My quick two cents is that I agree wholeheartedly with Chris. There is tons of stuff in Morphic like Nebraska, Etoys and things like MVC and Universes that could be made Squeakmap packages before something like the profiler. These would also seem to give a far greater savings in terms of class count and LOC, than the comparatively small profiler.
On Fri, Jan 25, 2013 at 10:05 AM, Chris Muller asqueaker@gmail.com wrote:
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
On Fri, Jan 25, 2013 at 10:48 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
This leads us to the discussion of building different 'distributions' or releases which we had many times in the past.
This time the situation is substantially different as we now have a continuous integration server which allows to do this.
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
--Hannes
+1
(big snip)
+1 And continuously work towards starting smaller by taking more and more out.
Ken, from my iPhone
On 2013-01-25, at 11:48, "H. Hirzel" hannes.hirzel@gmail.com wrote:
This leads us to the discussion of building different 'distributions' or releases which we had many times in the past.
This time the situation is substantially different as we now have a continuous integration server which allows to do this.
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
--Hannes
On 1/25/13, Frank Shearar frank.shearar@gmail.com wrote:
On 25 January 2013 18:34, Ken G. Brown kbrown@mac.com wrote:
My two cents is that the profiler should be an external package that is brought into a minimal core at build time if desired. Now us the time to start doing that sort of thing otherwise it will be stuck in the base image and no one will know how to get it out.. The other packages as well of course, whether at build time for a release or as a later customization for individual users.
Well, it is already an external package. The argument would be "it can't get entangled with the base image if it stays that way". Which is fair enough.
It _is_ a critical dev tool, and (a) devs can load it into their own custom images and (b) we have a release script that can take the clean fully updated image from CI and load it in as part of the ReleaseSqueakTrunk job. Installer _might_ need a bit of love to do this; I don't recall off-hand.
frank
Ken, from my iPhone
On 2013-01-25, at 11:22, Jeff Gonis jeff.gonis@gmail.com wrote:
My quick two cents is that I agree wholeheartedly with Chris. There is tons of stuff in Morphic like Nebraska, Etoys and things like MVC and Universes that could be made Squeakmap packages before something like the profiler. These would also seem to give a far greater savings in terms of class count and LOC, than the comparatively small profiler.
On Fri, Jan 25, 2013 at 10:05 AM, Chris Muller asqueaker@gmail.com wrote:
Ahem. Perhaps before we start slashing and cutting basic tools like the profiler, we should articulate a coherent description of our vision for a reduced image, what's in it, and what audience it would target.
The profiler is an essential development tool, so that would seem to cut developers from the target audience. Whatever reason you want to cut it may be that you'd also like to cut the Process browser too -- I don't know without knowing what your goals are. Like everyone else I want a smaller image, but with "small" it should be more like a neutron star is to a red-giant -- *dense* with functionality and applicability. Until we can get to a truly "minimal" image (1MB) our cutting should be toward the goal of something Small and powerful, not small and useless. :)
I suggest before we cut basic development tools we cut "app" type stuff like... "telemorphic" and
On Thu, Jan 24, 2013 at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 24-01-2013, at 8:08 AM, Chris Muller asqueaker@gmail.com wrote:
> Chris, might I lean on you a bit to add a SqueakMap entry for the > profiler?
Is this not something we should just put straight into the base image?
I'd say no; and the existing one ought to be removed as well. Cut, slash, trim.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
On 26.01.2013, at 04:58, Yanni Chiu yanni@rogers.com wrote:
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
So what is their solution now?
- Bert -
There is the Pharo 2.0 image which is the developer image and a smaller one called 'Pharo Kernel'.
https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
Both have various builds with various packages.
--Hannes
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 04:58, Yanni Chiu yanni@rogers.com wrote:
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
So what is their solution now?
- Bert -
On 26.01.2013, at 12:04, "H. Hirzel" hannes.hirzel@gmail.com wrote:
There is the Pharo 2.0 image which is the developer image and a smaller one called 'Pharo Kernel'.
https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
Both have various builds with various packages.
--Hannes
How does that deal with the problem Yanni described?
- Bert -
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 04:58, Yanni Chiu yanni@rogers.com wrote:
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
So what is their solution now?
- Bert -
Developers work with the Non-Core image daily. The Pharo-Kernel is a subset of it. So problems get detected.
In the end this is the same approach which we have here in Squeak with
SmalltalkImage unloadAllKnownPackages
(We actually would need a integration server process which does this).
But this does not answer the question which SystemProfiler should be included in the Non-Core image which people use daily.....
We might just put a load script in the 'Extending the system' workspace.
--Hannes
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 12:04, "H. Hirzel" hannes.hirzel@gmail.com wrote:
There is the Pharo 2.0 image which is the developer image and a smaller one called 'Pharo Kernel'.
https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
Both have various builds with various packages.
--Hannes
How does that deal with the problem Yanni described?
- Bert -
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 04:58, Yanni Chiu yanni@rogers.com wrote:
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
So what is their solution now?
- Bert -
Or better
remove the 50+ classes of Universe (see http://lists.squeakfoundation.org/pipermail/beginners/2013-January/008500.ht...) and add the AndreasSystemProfiler as a second profiler.
--Hannes
On 1/26/13, H. Hirzel hannes.hirzel@gmail.com wrote:
Developers work with the Non-Core image daily. The Pharo-Kernel is a subset of it. So problems get detected.
In the end this is the same approach which we have here in Squeak with
SmalltalkImage unloadAllKnownPackages (We actually would need a integration server process which does this).But this does not answer the question which SystemProfiler should be included in the Non-Core image which people use daily.....
We might just put a load script in the 'Extending the system' workspace.
--Hannes
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 12:04, "H. Hirzel" hannes.hirzel@gmail.com wrote:
There is the Pharo 2.0 image which is the developer image and a smaller one called 'Pharo Kernel'.
https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
Both have various builds with various packages.
--Hannes
How does that deal with the problem Yanni described?
- Bert -
On 1/26/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2013, at 04:58, Yanni Chiu yanni@rogers.com wrote:
On 25/01/13 1:48 PM, H. Hirzel wrote:
So this might be a good opportunity to start building another distribution/release with what Frank proposes. So besides the current one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have a "developer's release' with additional packages....
+1/-1
Don't forget the Pharo experience. There used to be a Pharo-Core-1.3 and Pharo-1.3 (a.k.a. Pharo-dev).
There was a ton of confusion when people reported a bug in "Pharo" - sometimes that meant Core, sometimes not.
With Pharo-1.4, the distinction between Core and non-Core was abandoned. IIUC, the reason was that developers worked day-to-day with the non-Core image - refactoring and so on - then had to make sure the changes worked in Core too. Going the other way, when working only in Core, if code is refactored or eliminated (because it looks like no senders in Core), then the problems would show up later when the non-Core image is built or run.
So what is their solution now?
- Bert -
On 1/26/13 8:12 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
SmalltalkImage unloadAllKnownPackages
(We actually would need a integration server process which does this).
Frank ? Any successful build on the mini ? Like discuss some glue needed for unload GetText and Enviroments. Have a manual build SqueakRosCore4dot4-12346.image working , with some changes from Trunk.
Edgar
On 26 January 2013 12:17, Edgar J. De Cleene edgardec2005@gmail.com wrote:
On 1/26/13 8:12 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
SmalltalkImage unloadAllKnownPackages
(We actually would need a integration server process which does this).Frank ? Any successful build on the mini ? Like discuss some glue needed for unload GetText and Enviroments. Have a manual build SqueakRosCore4dot4-12346.image working , with some changes from Trunk.
I don't think it has run a job, but that's quite possibly just because we only have one OSX job, which keeps hitting my machine. I would like to get some more jobs going, in particular the various OSX VMs (about which I know almost nothing).
We do need to work a bit on making GetText unloadable, IIRC.
frank
Edgar
On 26/01/13 6:12 AM, H. Hirzel wrote:
Developers work with the Non-Core image daily. The Pharo-Kernel is a subset of it. So problems get detected.
The Pharo-Kernel is a work-in-progress. It should be possible to re-construct the developer image, by reloading all the bits, but that's not how the actual developer image gets built, at present.
Done, AndreasSystemProfiler is now on SqueakMap as a Community-Supported Package.
On Wed, Jan 23, 2013 at 4:30 PM, Frank Shearar frank.shearar@gmail.com wrote:
Thank you very much, Ron. Now folks, let's get out there and use this!
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
The install script is
Installer ss3 project: 'AndreasSystemProfiler'; install: 'AndreasProfiler'.
Thanks!
frank
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Thanks very much, Chris!
frank
On 30 January 2013 16:38, Chris Muller asqueaker@gmail.com wrote:
Done, AndreasSystemProfiler is now on SqueakMap as a Community-Supported Package.
On Wed, Jan 23, 2013 at 4:30 PM, Frank Shearar frank.shearar@gmail.com wrote:
Thank you very much, Ron. Now folks, let's get out there and use this!
Chris, might I lean on you a bit to add a SqueakMap entry for the profiler?
The install script is
Installer ss3 project: 'AndreasSystemProfiler'; install: 'AndreasProfiler'.
Thanks!
frank
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Wed, Jan 23, 2013 at 12:58 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
Both AndreasSystemProfiler and MessageTally are periodic sampling profilers. The essential difference between AndreasSystemProfiler and MessageTally is in how the current method is sampled.
MessageTally is driven from a high-priority process in a loop waiting on a delay. When the delay fires the lower-priority process being profiled is interrupted, its stack is walked to determine the methods along the call chain, and that data is recorded. But since the sampling occurs when the high-priority process preempts the lower-priority process, a sample is only taken at a preemption point. In particular, primitives are *not* profiled because they are not suspension points. A process can only be suspended on method activation (a non-primitive method activation, or primitive failure) or on backward branch. The cost of primitives is charged to a caller and is inferred by subtracting the cost of children of the caller from the caller itself (subtracting the number of samples in children of the caller form the number of samples in the caller itself).
Another problem is that using the clock that underlies Delay, which is typically the clock used by processes being profiled, causes sampling errors due to the sampling and sampled processes cohering. Delays are limited in resolution (at best 1 millisecond) so if the profiled process waits on a delay it'll fire immediately after the profiling process (because the profiling process is at higher priority) and so the sampling process may only ever see the sampled process in a wait state.
If MessageTally is used to profile multiple processes then a third problem is that if a primitive causes a process switch then its cost will end up being charged to the process switched-to, not switched from. This is again because sampling can only occur after a primitive has completed (successfully or not).
AndreasSystemProfiler is driven from a high-priority process in a loop waiting on a Semaphore known to the VM. The profiling process uses a primitive to schedule a sample some number of ticks of the VM's high-performance clock in the future. When the time is reached the VM samples the current method and the current process, *before any process preemption takes place*, and independently of the standard clock, and signals the semaphore. The profiling process then collects the method,process pair via primitives. So AndreasSystemProfiler provides much more accurate results.
That said there are still limitations with primitives and Cog. Currently Cog only samples "interpreter" primitives. Those primitives it implements in machine code (integer and float arithmetic, closure evaluation, at:, identityHash) are not sampled and won't show up; they will be charged to the calling method. This is fixable, since Cog actually compiles the sampling direct into interpreter primitive invocation when profiling is in effect and not at other times, but sampling could be a significant cost in these simple and performance-critical primitives.
http://ss3.gemstone.com/ss/AndreasSystemProfiler.html
Using the MIT License.
Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4.
All the best,
Ron Teitelbaum, Julie LeMoine and David Smith
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas.Raab Sent: Friday, January 11, 2013 1:39 PM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: Profiling
Levente Uzonyi-2 wrote
It uses some primitives which were added to the CogVM, so it requires
Cog.
We could reimplement it from scratch using the same primitives and get a better profiler in the image. We can't include this due to the GPL license.
Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and Software) can re-release the code under a more permissable license.
Cheers,
- Andreas
-- View this message in context: http://forum.world.st/Profiling- tp4662704p4662987.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
Ron,
How do you want people to contribute back to this project? I have a small improvement for you.
frank
Hi Frank,
Eliot will be maintaining AndreasSystemProfiler. Could you send the change to him?
Thanks!
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Frank Shearar Sent: Friday, February 08, 2013 5:55 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] AndreasSystemProfiler Released MIT
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
Ron,
How do you want people to contribute back to this project? I have a small improvement for you.
frank
Done!
Thanks, Ron.
frank
On 9 February 2013 16:41, Ron Teitelbaum ron@usmedrec.com wrote:
Hi Frank,
Eliot will be maintaining AndreasSystemProfiler. Could you send the change to him?
Thanks!
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Frank Shearar Sent: Friday, February 08, 2013 5:55 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] AndreasSystemProfiler Released MIT
On 23 January 2013 20:58, Ron Teitelbaum ron@usmedrec.com wrote:
Hello All,
In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html
We have renamed and released the AndreasSystemProfiler.
Ron,
How do you want people to contribute back to this project? I have a small improvement for you.
frank
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Bert Freudenberg -
Casey Ransberger -
Chris Muller -
Colin Putney -
Edgar J. De Cleene -
Eliot Miranda -
Frank Shearar -
H. Hirzel -
Jeff Gonis -
Ken G. Brown -
Ron Teitelbaum -
tim Rowledge -
Yanni Chiu