One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
Damn formatting -- and why can't I use a Tab character in an e-mail?! Geesh!
Here's the hierarchy which will hopefully not be reformatted by Gmail:
Morphic (and everything else) ST80 Tools System Balloon Graphics Multilingual Kernel Collections Exceptions
And now the responsibility / capabilities descriptions:
Morphic -- UI framework ST80 -- Not sure about this one. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
On Fri, Jul 26, 2013 at 11:25 AM, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
On a side note, who did the dot files that I post-processed around new year?
Am 26.07.2013 um 18:28 schrieb Chris Muller ma.chris.m@gmail.com:
Damn formatting -- and why can't I use a Tab character in an e-mail?! Geesh!
Here's the hierarchy which will hopefully not be reformatted by Gmail:
Morphic (and everything else) ST80 Tools System Balloon Graphics Multilingual Kernel Collections Exceptions
And now the responsibility / capabilities descriptions:
Morphic -- UI framework ST80 -- Not sure about this one. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
On Fri, Jul 26, 2013 at 11:25 AM, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
Those were mine, I think. You can find the generator here: https://gist.github.com/frankshearar/5781906
I made a mild improvement recently where test packages' dependencies are dashed, so they don't clutter up the "production" code while still remaining visible.
frank
On 26 July 2013 19:09, Tobias Pape Das.Linux@gmx.de wrote:
On a side note, who did the dot files that I post-processed around new year?
Am 26.07.2013 um 18:28 schrieb Chris Muller ma.chris.m@gmail.com:
Damn formatting -- and why can't I use a Tab character in an e-mail?! Geesh!
Here's the hierarchy which will hopefully not be reformatted by Gmail:
Morphic (and everything else) ST80 Tools System Balloon Graphics Multilingual Kernel Collections Exceptions
And now the responsibility / capabilities descriptions:
Morphic -- UI framework ST80 -- Not sure about this one. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
On Fri, Jul 26, 2013 at 11:25 AM, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
Am 26.07.2013 um 20:11 schrieb Frank Shearar frank.shearar@gmail.com:
Those were mine, I think. You can find the generator here: https://gist.github.com/frankshearar/5781906
I made a mild improvement recently where test packages' dependencies are dashed, so they don't clutter up the "production" code while still remaining visible.
Ok I tweaked it a little bit (really, just a little) and put my process to create the pdfs (including the pdfs) on github:
https://github.com/krono/Squeak-Trunk-Deps
Best -Tobias
Cool! I'm just curious as to how you might phrase the "executive summary" of the maps. They don't, for instance, show the massive amount of circularity between, say, System, Collections, Kernel, Network and so on. The maps look much more like how I'd _like_ the dependencies to be.
frank
On 29 July 2013 07:37, Tobias Pape Das.Linux@gmx.de wrote:
Am 26.07.2013 um 20:11 schrieb Frank Shearar frank.shearar@gmail.com:
Those were mine, I think. You can find the generator here: https://gist.github.com/frankshearar/5781906
I made a mild improvement recently where test packages' dependencies are dashed, so they don't clutter up the "production" code while still remaining visible.
Ok I tweaked it a little bit (really, just a little) and put my process to create the pdfs (including the pdfs) on github:
https://github.com/krono/Squeak-Trunk-Deps
Best -Tobias
Am 29.07.2013 um 14:36 schrieb Frank Shearar frank.shearar@gmail.com:
Cool! I'm just curious as to how you might phrase the "executive summary" of the maps. They don't, for instance, show the massive amount of circularity between, say, System, Collections, Kernel, Network and so on. The maps look much more like how I'd _like_ the dependencies to be.
note that I used tred to figure out transitive dependencies, but it does not work too well with circular dependencies; when tred encounters circles, the outcome is undefined with respect to where the circles is actually shown.
tred(1): If a graph has cycles, its transitive reduction is not uniquely defined. In this case tred emits a warning.
So we actually only get meaningful information once all circles are removed.
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel depend on nothing.
Best -Tobias
On 29 July 2013 13:46, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 14:36 schrieb Frank Shearar frank.shearar@gmail.com:
Cool! I'm just curious as to how you might phrase the "executive summary" of the maps. They don't, for instance, show the massive amount of circularity between, say, System, Collections, Kernel, Network and so on. The maps look much more like how I'd _like_ the dependencies to be.
note that I used tred to figure out transitive dependencies, but it does not work too well with circular dependencies; when tred encounters circles, the outcome is undefined with respect to where the circles is actually shown.
tred(1): If a graph has cycles, its transitive reduction is not uniquely defined. In this case tred emits a warning.
So we actually only get meaningful information once all circles are removed.
Ah, that would explain a lot.
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel depend on nothing.
I would very much like to have Kernel depend on nothing, but we're a long way from being able to do that. Collections _can't_ depend on nothing, because it must at the least depend on things like Object and Class, which properly belong in Kernel.
frank
Best -Tobias
Am 29.07.2013 um 14:51 schrieb Frank Shearar frank.shearar@gmail.com: […]
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel depend on nothing.
I would very much like to have Kernel depend on nothing, but we're a long way from being able to do that.
Why? (see below)
Collections _can't_ depend on nothing, because it must at the least depend on things like Object and Class, which properly belong in Kernel.
I looked around in Kernel and, boy, it is crowded. Eg, why is ObjectViewer in Kernel? (just mocking)
Wouldn't it be possible to extract the actual kernel from "Kernel" and rename Kernel to Base or something? Only that we have the most basic objects (Object ±ProtoObject, Booleans, MNU (with dependencies))
Best -Tobias
On 29 July 2013 14:13, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 14:51 schrieb Frank Shearar frank.shearar@gmail.com: […]
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel depend on nothing.
I would very much like to have Kernel depend on nothing, but we're a long way from being able to do that.
Why? (see below)
Well, we can attack the inter-package dependency problem from anywhere. I just wanted to untangle System, and get Etoys/MorphicExtras/Morphic unloadable before potentially frightening people with "extreme" stuff like gutting Kernel of arithmetic, and pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Collections _can't_ depend on nothing, because it must at the least depend on things like Object and Class, which properly belong in Kernel.
I looked around in Kernel and, boy, it is crowded. Eg, why is ObjectViewer in Kernel? (just mocking)
Decades of noone getting really serious about package dependency management in a giant blob of persistent state will do that every time :) That's mostly easy to fix though.
Wouldn't it be possible to extract the actual kernel from "Kernel" and rename Kernel to Base or something? Only that we have the most basic objects (Object ±ProtoObject, Booleans, MNU (with dependencies))
Agreed.
frank
Best -Tobias
Having Collection and Kernel dissociated is a very difficult thing, because Array, ByteArray, String, Symbol ... are all used in the Kernel. At least if Kernel contains the very basic stuff used by the VM.
See http://stackoverflow.com/questions/17176380/inconsistencies-in-smalltalk/171... viewing a small part of those inter-connections.
The object map of a minimal Spoon image might also be of interest (can't find the link right now).
2013/7/29 Frank Shearar frank.shearar@gmail.com
On 29 July 2013 14:13, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 14:51 schrieb Frank Shearar frank.shearar@gmail.com: […]
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel
depend
on nothing.
I would very much like to have Kernel depend on nothing, but we're a long way from being able to do that.
Why? (see below)
Well, we can attack the inter-package dependency problem from anywhere. I just wanted to untangle System, and get Etoys/MorphicExtras/Morphic unloadable before potentially frightening people with "extreme" stuff like gutting Kernel of arithmetic, and pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Collections _can't_ depend on nothing, because it must at the least depend on things like Object and Class, which properly belong in Kernel.
I looked around in Kernel and, boy, it is crowded. Eg, why is ObjectViewer in Kernel? (just mocking)
Decades of noone getting really serious about package dependency management in a giant blob of persistent state will do that every time :) That's mostly easy to fix though.
Wouldn't it be possible to extract the actual kernel from "Kernel" and rename Kernel to Base or something? Only that we have the most basic objects (Object ±ProtoObject, Booleans,
MNU (with dependencies))
Agreed.
frank
Best -Tobias
Am 29.07.2013 um 16:12 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Having Collection and Kernel dissociated is a very difficult thing, because Array, ByteArray, String, Symbol ... are all used in the Kernel. At least if Kernel contains the very basic stuff used by the VM.
See http://stackoverflow.com/questions/17176380/inconsistencies-in-smalltalk/171... for viewing a small part of those inter-connections.
The object map of a minimal Spoon image might also be of interest (can't find the link right now).
The crucial point here are the VM-known classes that make modularity hard:
Class, CompiledMethod, MessageNotUnderstood (<->via #doesNotUnderstand:) Their superclasses are definitely _not_ kernel-worthy (eg, Behavior, NotImplemented, Error) But we cannot change superclasses on loading…
There, catch-22.
Best -Tobias
On 29-07-2013, at 7:00 AM, Frank Shearar frank.shearar@gmail.com wrote:
pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Sigh. That should have gone away 15 years ago.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A)bort, R)etry, I)nfluence with large hammer.
Am 29.07.2013 um 18:52 schrieb tim Rowledge tim@rowledge.org:
On 29-07-2013, at 7:00 AM, Frank Shearar frank.shearar@gmail.com wrote:
pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Sigh. That should have gone away 15 years ago.
What do you mean exactly?
Best Tobias
On 29-07-2013, at 10:41 AM, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 18:52 schrieb tim Rowledge tim@rowledge.org:
On 29-07-2013, at 7:00 AM, Frank Shearar frank.shearar@gmail.com wrote:
pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Sigh. That should have gone away 15 years ago.
What do you mean exactly?
Waaaaaay back when I was at Interval Research (along with Craig and several other longtimer Smalltalkers) we came up with a cleaner Method format. The 'old' way is to mangle reality cruelly by making a byte object and storing your bytecodes in it - but treat the latter part of it as a pointer object and store assorted stuff there - source pointer object etc. This complicates the gc, makes for some awkward prims and so on. I don't like it much. The newer format simpy made a CompiledMethod object that was a'proper' pointer object, split the bytecodes out to a bytearray and got rid of some complications.
It costs maybe 8 bytes per method in the image to pay for the extra object and saves some ugliness in code that ought to save a little time. As a side effect, it became very easy to handle source code access via any old object that you wanted to stick in the relevant instance var. Not that it is all that difficult the older way, but it encouraged experimentation. IIRC Eliot looked at it when firing up Cog and decided the space cost wasn't worth it in his opinion; since he was writing the code he got to make the call.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: EBO: Emulate Brown-Out
Am 29.07.2013 um 20:28 schrieb tim Rowledge tim@rowledge.org:
On 29-07-2013, at 10:41 AM, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 18:52 schrieb tim Rowledge tim@rowledge.org:
On 29-07-2013, at 7:00 AM, Frank Shearar frank.shearar@gmail.com wrote:
pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Sigh. That should have gone away 15 years ago.
What do you mean exactly?
Waaaaaay back when I was at Interval Research (along with Craig and several other longtimer Smalltalkers) we came up with a cleaner Method format. The 'old' way is to mangle reality cruelly by making a byte object and storing your bytecodes in it - but treat the latter part of it as a pointer object and store assorted stuff there - source pointer object etc. This complicates the gc, makes for some awkward prims and so on. I don't like it much. The newer format simpy made a CompiledMethod object that was a'proper' pointer object, split the bytecodes out to a bytearray and got rid of some complications.
It costs maybe 8 bytes per method in the image to pay for the extra object and saves some ugliness in code that ought to save a little time. As a side effect, it became very easy to handle source code access via any old object that you wanted to stick in the relevant instance var. Not that it is all that difficult the older way, but it encouraged experimentation. IIRC Eliot looked at it when firing up Cog and decided the space cost wasn't worth it in his opinion; since he was writing the code he got to make the call
Can we make a coordinated move with Squeak, Cuis, and, Pharo? We could implement a trivial PIC on the way...
Best -Tobias
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
Am 29.07.2013 um 21:07 schrieb tim Rowledge tim@rowledge.org:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
What is the alternative in the long run?
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
I don't say it does not. Anyways, it just came to my mind :)
Best -Tobias
Tobias Pape wrote in reply toTim Rowledge:
Yet another image format change would be fairly painful IMO.
What is the alternative in the long run?
Please note that this was all actually implemented back in 2002, but not adopted by the community. If I remember correctly, even the author (Anthony Hannan) was against the simple adoption of his code at one point, though I don't remember the reasons why.
http://wiki.squeak.org/squeak/2119
Note that he credits Tim for the inspiration in the part where he talks about the CompiledMethod2 class.
In terms of history, I don't remember if Tektronix Smalltalk was like this. They did change OrderedCollection to point to an array with the contents so they wouldn't have to use #become: to grow. Certainly Self 1.0 from 1990 used this design for compiled methods.
-- Jecel
On 29 Jul 2013, at 20:07, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
[sic]
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
And as we are on it. A report which shows the Package Hierarchy Map.
On 7/30/13, H. Hirzel hannes.hirzel@gmail.com wrote:
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
If you like, you can add a note requesting this on http://wiki.squeak.org/squeak/6189
Otherwise, the good idea might be forgotten!
frank
On 30 July 2013 14:52, H. Hirzel hannes.hirzel@gmail.com wrote:
And as we are on it. A report which shows the Package Hierarchy Map.
On 7/30/13, H. Hirzel hannes.hirzel@gmail.com wrote:
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
While we are at it, do we actually have a 4.5 Release manager yet?
Am 30.07.2013 um 16:28 schrieb Frank Shearar frank.shearar@gmail.com:
If you like, you can add a note requesting this on http://wiki.squeak.org/squeak/6189
Otherwise, the good idea might be forgotten!
frank
On 30 July 2013 14:52, H. Hirzel hannes.hirzel@gmail.com wrote:
And as we are on it. A report which shows the Package Hierarchy Map.
On 7/30/13, H. Hirzel hannes.hirzel@gmail.com wrote:
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote:
Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
Always have!
Chris Muller & Colin Putney.
frank
On 30 July 2013 18:00, Tobias Pape Das.Linux@gmx.de wrote:
While we are at it, do we actually have a 4.5 Release manager yet?
Am 30.07.2013 um 16:28 schrieb Frank Shearar frank.shearar@gmail.com:
If you like, you can add a note requesting this on http://wiki.squeak.org/squeak/6189
Otherwise, the good idea might be forgotten!
frank
On 30 July 2013 14:52, H. Hirzel hannes.hirzel@gmail.com wrote:
And as we are on it. A report which shows the Package Hierarchy Map.
On 7/30/13, H. Hirzel hannes.hirzel@gmail.com wrote:
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote: > > Can we make a coordinated move with Squeak, Cuis, and, Pharo?
Yet another image format change would be fairly painful IMO.
> We could implement a trivial PIC on the way…
Cog already has a very sophisticated PIC and indeed I think a HIC. (Maybe)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
Thanks, I just forgot :)
Am 30.07.2013 um 19:01 schrieb Frank Shearar frank.shearar@gmail.com:
Always have!
Chris Muller & Colin Putney.
frank
On 30 July 2013 18:00, Tobias Pape Das.Linux@gmx.de wrote:
While we are at it, do we actually have a 4.5 Release manager yet?
Am 30.07.2013 um 16:28 schrieb Frank Shearar frank.shearar@gmail.com:
If you like, you can add a note requesting this on http://wiki.squeak.org/squeak/6189
Otherwise, the good idea might be forgotten!
frank
On 30 July 2013 14:52, H. Hirzel hannes.hirzel@gmail.com wrote:
And as we are on it. A report which shows the Package Hierarchy Map.
On 7/30/13, H. Hirzel hannes.hirzel@gmail.com wrote:
We might need a workspace with a glossary in the help menu in Squeak 4.5 ....
--Hannes
On 7/30/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
On Mon, Jul 29, 2013 at 12:07 PM, tim Rowledge tim@rowledge.org wrote:
> > On 29-07-2013, at 11:50 AM, Tobias Pape Das.Linux@gmx.de wrote: >> >> Can we make a coordinated move with Squeak, Cuis, and, Pharo? > > Yet another image format change would be fairly painful IMO. > >> We could implement a trivial PIC on the way… > > > Cog already has a very sophisticated PIC and indeed I think a HIC. > (Maybe) > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- Casey Ransberger
On 29-07-2013, at 9:55 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
Sorry Casey, apparently you're not on the NTK list.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, as Piglet pressed <START> on the Microwave...
Ouch.
On Jul 30, 2013, at 9:09 AM, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 9:55 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
What's a HIC? Google the TLA doesn't help. I'm pretty sure we aren't talking about a hydraulic integrated circuit! (which is the weirdest thing I came across in my search)
Sorry Casey, apparently you're not on the NTK list.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, as Piglet pressed <START> on the Microwave...
Hi Tobias,
Quoting Tobias Pape Das.Linux@gmx.de:
Can we make a coordinated move with Squeak, Cuis, and, Pharo? We could implement a trivial PIC on the way...
Best -Tobias
My plan with Cuis is to follow Squeak's lead wrt image format. I especially look forward to a 64 bit image and Cog VM with immediate Floats :). Simplified CompiledMethods wouldn't hurt.
Cheers, Juan Vuletich
On Fri, Jul 26, 2013 at 11:28:52AM -0500, Chris Muller wrote:
Damn formatting -- and why can't I use a Tab character in an e-mail?! Geesh!
Here's the hierarchy which will hopefully not be reformatted by Gmail:
Morphic (and everything else) ST80 Tools System Balloon Graphics Multilingual Kernel Collections Exceptions
And now the responsibility / capabilities descriptions:
Morphic -- UI framework ST80 -- Not sure about this one.
"ST80" is the MVC UI framework, in the same sense that "Morphic" is the Morphic UI framework. I'm sure that ST80 started out as a general category of all the stuff that originated in ST80, but as a practical matter, nowadays it refers to MVC. An MVC user interface is hosted in an MVCProject, just as a Morphic user interface is hosted in a MorphicProject.
Dave
Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
On Fri, Jul 26, 2013 at 11:25 AM, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
On 26 July 2013 17:25, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
I mildly object to the description 'being driven by "any
place but here because it creates a cycle"' :). I think losing the cycle is more important than which edge goes, is all. While we're slicing things up, we'll get things wrong, but it's easy enough to move bits around. We'll only really get a proper idea of when we've messed up when we unload things and what's left breaks.
We're largely in agreement as to what's high- and what's low-level. Mainly we disagree about System: you _want_ it to be a low-level thing while I _see_ it as a high-level package. Of course, that's because it has low level parts and high level parts. Not surprising, given that the only packages larger (*) are Morphic, MorphicExtras and Etoys!
(*) ((PackageInfo allInstances collect: [:pkg| {pkg name. pkg classes size. pkg extensionMethods size}]) sorted: [:a :b | (a second + a third) < (b second + b third)]) reverse first: 5 "=> #(#('EToys' 125 630) #('Morphic' 220 127) #('MorphicExtras' 128 143) #('System' 127 83) #('Tools' 64 120))"
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
I do think _ideally_ that Kernel would have no dependencies at all. But doing that would require drastically altering the contents of Collections. But that's a problem for much later.
Morphic and ST80 fulfil the same function: supplying a user interface. (I know that's obvious.)
Text should probably be broken out into a separate package, in which multilingualisation, Strings and other such stuff would reside. At the moment text handling's spread all over the place: Collections, Multilingual, Morphic, perhaps part of System too. (I'm running off memory of an experiment I tried and threw away a few days ago.)
frank
On Fri, Jul 26, 2013 at 12:47 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 26 July 2013 17:25, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
I mildly object to the description 'being driven by "any
place but here because it creates a cycle"' :). I think losing the cycle is more important than which edge goes, is all. While we're slicing things up, we'll get things wrong, but it's easy enough to move bits around. We'll only really get a proper idea of when we've messed up when we unload things and what's left breaks.
We're largely in agreement as to what's high- and what's low-level. Mainly we disagree about System: you _want_ it to be a low-level thing while I _see_ it as a high-level package. Of course, that's because it has low level parts and high level parts. Not surprising, given that the only packages larger (*) are Morphic, MorphicExtras and Etoys!
I'm just trying to think about responsibilities as much as levels. Even if MethodFinder didn't need any of the other packages Tools depends on, it fits into the responsibility of the Tools package.
If "System" is all the little engines and services needed to make the Smalltalk environment work, then being actually right in the _middle_ might be helpful so that factorings above or below it can slide right into this System "catch-all" package until they can be factored out at a future point.
For example, at some future point maybe we'd be able to factor out the SmartRefStream into a separate package, so that another serializer could be substituted. The remainder of System remains intact until hopefully it can be factored into total oblivion.
These are just ideas..
On 26 July 2013 20:42, Chris Muller ma.chris.m@gmail.com wrote:
On Fri, Jul 26, 2013 at 12:47 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 26 July 2013 17:25, Chris Muller ma.chris.m@gmail.com wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are. Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
I mildly object to the description 'being driven by "any
place but here because it creates a cycle"' :). I think losing the cycle is more important than which edge goes, is all. While we're slicing things up, we'll get things wrong, but it's easy enough to move bits around. We'll only really get a proper idea of when we've messed up when we unload things and what's left breaks.
We're largely in agreement as to what's high- and what's low-level. Mainly we disagree about System: you _want_ it to be a low-level thing while I _see_ it as a high-level package. Of course, that's because it has low level parts and high level parts. Not surprising, given that the only packages larger (*) are Morphic, MorphicExtras and Etoys!
I'm just trying to think about responsibilities as much as levels. Even if MethodFinder didn't need any of the other packages Tools depends on, it fits into the responsibility of the Tools package.
If "System" is all the little engines and services needed to make the Smalltalk environment work, then being actually right in the _middle_ might be helpful so that factorings above or below it can slide right into this System "catch-all" package until they can be factored out at a future point.
For example, at some future point maybe we'd be able to factor out the SmartRefStream into a separate package, so that another serializer could be substituted. The remainder of System remains intact until hopefully it can be factored into total oblivion.
These are just ideas..
And they're good ideas too. A bit +1 to Dave's talking about approaching packages the way we do objects. So for instance, since you mention SmartRefStream, there's a whole pile of stuff concerned with moving objects into and out of the image. DiskProxy, the "System-Object Storage" subcategory, and so on. Breaking all those guys into a package focused just on this would (a) make a lot of sense because things that work together would be grouped together and (b) would make untangling the system as a whole much easier.
frank
On Fri, Jul 26, 2013 at 11:25:50AM -0500, Chris Muller wrote:
One thing that might help us sort methods and organize methods into packages is try to decide what we think the responsibilities of those packages are.
+1000
I have not put much thought into the specifics, so I won't try to comment on the suggested hierarchy (yet). But I do think that it is very important that packages make sense conceptually. Thinking about it in terms of responsibilities for a package seems like the right thing to do. That's the approach that any of us would take in thinking about e.g. the responsibilities of a class in an object oriented design. So it seems natural to think of packages in the same way.
Dave
Here is a suggested hierarchy where the most-indented are the lowest level packages and the most outdented are the highest level packages.
I might be helpful to be driven by where we think, *semantically*, the behaviors you're moving around belong rather than being driven by "any place but here because it creates a cycle".
It probably won't be possible to eliminate the cycles between the three lowest-level packages, but hopefully from the ones above that.
Morphic (and everything else) ST80 -- Not sure about this one, but seems like it should be "legacy" Smalltalk stuff rather than low-level stuff. Tools -- Domain models that describe and operate tool windows. System -- catch-all for System'y things. Does not include any tool-windows. Balloon -- Graphics framework. Graphics -- Things related to graphical output. Bit-blitting and canvas stuff. NOT Morphic stuff. Multilingual -- Things related to internationalization. Kernel -- Lowest-level things besides collections and error-handling. Collections -- collections. Exceptions -- Error-handling things.
Thoughts?
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Chris Muller -
David T. Lewis -
Frank Shearar -
H. Hirzel -
Jecel Assumpcao Jr. -
Juan Vuletich (mail lists) -
Nicolas Cellier -
tim Rowledge -
Tobias Pape