AndreasSystemProfiler Released MIT
Locked
12
12
AndreasSystemProfiler Released MIT
 
|
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: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Andreas.Raab > Sent: Friday, January 11, 2013 1:39 PM > To: [hidden email] > 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. > |
Re: AndreasSystemProfiler Released MIT
|
|
This is a great idea! Alex2013/1/23 Ron Teitelbaum <[hidden email]> Hello All, |
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by Ron Teitelbaum
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 <[hidden email]> 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: [hidden email] [mailto:squeak-dev- >> [hidden email]] On Behalf Of Andreas.Raab >> Sent: Friday, January 11, 2013 1:39 PM >> To: [hidden email] >> 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. >> > > > |
Re: AndreasSystemProfiler Released MIT
|
|
> 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? |
Re: AndreasSystemProfiler Released MIT
|
|
On 24 January 2013 16:08, Chris Muller <[hidden email]> 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 |
Re: AndreasSystemProfiler Released MIT
|
|
On Thu, Jan 24, 2013 at 9:26 AM, Frank Shearar <[hidden email]> wrote:
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 |
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by Chris Muller-3
On 24-01-2013, at 8:08 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark." |
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by Ron Teitelbaum
On Wed, Jan 23, 2013 at 12:58 PM, Ron Teitelbaum <[hidden email]> wrote: Hello All, 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 best, Eliot
|
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by timrowledge
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 <[hidden email]> wrote: > > On 24-01-2013, at 8:08 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark." > > > |
Re: AndreasSystemProfiler Released MIT
|
|
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 <[hidden email]> wrote: Ahem. Perhaps before we start slashing and cutting basic tools like |
Re: AndreasSystemProfiler Released MIT
|
|
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
|
Re: AndreasSystemProfiler Released MIT
|
|
On 25 January 2013 18:34, Ken G. Brown <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> > >> > On 24-01-2013, at 8:08 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim >> > "How many Kzin does it take to change a lightbulb?" "None. You can >> > scream and leap in the dark." >> > >> > >> > >> > > > > > |
Re: AndreasSystemProfiler Released MIT
|
|
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 <[hidden email]> wrote: > On 25 January 2013 18:34, Ken G. Brown <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> wrote: >>> > >>> > On 24-01-2013, at 8:08 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim >>> > "How many Kzin does it take to change a lightbulb?" "None. You can >>> > scream and leap in the dark." >>> > >>> > >>> > >>> >> >> >> >> >> > > |
Re: AndreasSystemProfiler Released MIT
|
|
On Fri, Jan 25, 2013 at 10:48 AM, H. Hirzel <[hidden email]> wrote:
This leads us to the discussion of building different 'distributions' +1 (big snip) |
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by Hannes Hirzel
+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" <[hidden email]> 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 <[hidden email]> wrote: >> On 25 January 2013 18:34, Ken G. Brown <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >>> 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 <[hidden email]> wrote: >>>>> >>>>> On 24-01-2013, at 8:08 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim >>>>> "How many Kzin does it take to change a lightbulb?" "None. You can >>>>> scream and leap in the dark." > |
Re: AndreasSystemProfiler Released MIT
|
|
In reply to this post by Hannes Hirzel
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. |
Re: AndreasSystemProfiler Released MIT
|
|
On 26.01.2013, at 04:58, Yanni Chiu <[hidden email]> 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 - |
Re: AndreasSystemProfiler Released MIT
|
|
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 <[hidden email]> wrote: > On 26.01.2013, at 04:58, Yanni Chiu <[hidden email]> 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 - > > > > |
Re: AndreasSystemProfiler Released MIT
|
|
On 26.01.2013, at 12:04, "H. Hirzel" <[hidden email]> 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 <[hidden email]> wrote: >> On 26.01.2013, at 04:58, Yanni Chiu <[hidden email]> 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 - >> >> >> >> > |
Re: AndreasSystemProfiler Released MIT
|
|
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 <[hidden email]> wrote: > > On 26.01.2013, at 12:04, "H. Hirzel" <[hidden email]> 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 <[hidden email]> wrote: >>> On 26.01.2013, at 04:58, Yanni Chiu <[hidden email]> 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 - >>> >>> >>> >>> >> > > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |