Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
(I'll not mention how Kernel's InputSensor >> #keyboard uses TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
Hi Frank,
On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
IMO they don't belong in the Kernel at all. I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there. I'd also consider Headful and Headless packages for precursors of headful and headless apps.
(I'll not mention how Kernel's InputSensor >> #keyboard uses
TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
_,,,^..^,,,_ best, Eliot
It’s probably time InputSensor was laid to rest, along with the ancient primitives supporting it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Wibble" said Pooh the stress beginning to show.
+1 for Kernel-Input or Kernel-Device. Sensors are concerned with bringing information from the outside world into the software system; like the eyes and ears of the computer.
User-interface is concerned with the interactions between the software and the user.
On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Frank,
On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
IMO they don't belong in the Kernel at all. I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there. I'd also consider Headful and Headless packages for precursors of headful and headless apps.
(I'll not mention how Kernel's InputSensor >> #keyboard uses TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
_,,,^..^,,,_ best, Eliot
That was my thinking, Chris. But InputSensor is, as far as I can tell, entirely ST80-specific. It's all about keyboards and pointers _for ST80_: the equivalent of Morphic's UserInputEvent.
The only packages that reference it are ST80 and System, and System references it only because of #initializeStartUpList & #initializeShutDownList. (System has, as far as I can see, had this "soft" dependency on ST80 since at least 2010.)
Given that, ST80 actually seems like the right place for these classes.
frank
On 27 January 2016 at 02:52, Chris Muller asqueaker@gmail.com wrote:
+1 for Kernel-Input or Kernel-Device. Sensors are concerned with bringing information from the outside world into the software system; like the eyes and ears of the computer.
User-interface is concerned with the interactions between the software and the user.
On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Frank,
On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
IMO they don't belong in the Kernel at all. I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there. I'd also consider Headful and Headless packages for precursors of headful and headless apps.
(I'll not mention how Kernel's InputSensor >> #keyboard uses TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
_,,,^..^,,,_ best, Eliot
On Wed, Jan 27, 2016 at 10:24:55AM +0000, Frank Shearar wrote:
That was my thinking, Chris. But InputSensor is, as far as I can tell, entirely ST80-specific. It's all about keyboards and pointers _for ST80_: the equivalent of Morphic's UserInputEvent.
The only packages that reference it are ST80 and System, and System references it only because of #initializeStartUpList & #initializeShutDownList. (System has, as far as I can see, had this "soft" dependency on ST80 since at least 2010.)
Given that, ST80 actually seems like the right place for these classes.
That sounds reasonable, but one sanity check: ST80 is a reloadable package (or at least it was, and it definitely /should/ be). I think that will still be the case if we move InputSensor to ST80, but I'd want to check and make sure we don't break the unloadable/reloadable aspect.
This is probably a non-issue, but I can't check it right now so I'm just mentioning it as a reminder.
Dave
frank
On 27 January 2016 at 02:52, Chris Muller asqueaker@gmail.com wrote:
+1 for Kernel-Input or Kernel-Device. Sensors are concerned with bringing information from the outside world into the software system; like the eyes and ears of the computer.
User-interface is concerned with the interactions between the software and the user.
On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Frank,
On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
IMO they don't belong in the Kernel at all. I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there. I'd also consider Headful and Headless packages for precursors of headful and headless apps.
(I'll not mention how Kernel's InputSensor >> #keyboard uses TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
_,,,^..^,,,_ best, Eliot
How could we possibly unload InputSensor? Isn't that what generates the events necessary to interact with the system? IOW, you wouldn't be able to reload ST80 without InputSensor, right?
On Wed, Jan 27, 2016 at 7:16 AM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 27, 2016 at 10:24:55AM +0000, Frank Shearar wrote:
That was my thinking, Chris. But InputSensor is, as far as I can tell, entirely ST80-specific. It's all about keyboards and pointers _for ST80_: the equivalent of Morphic's UserInputEvent.
The only packages that reference it are ST80 and System, and System references it only because of #initializeStartUpList & #initializeShutDownList. (System has, as far as I can see, had this "soft" dependency on ST80 since at least 2010.)
Given that, ST80 actually seems like the right place for these classes.
That sounds reasonable, but one sanity check: ST80 is a reloadable package (or at least it was, and it definitely /should/ be). I think that will still be the case if we move InputSensor to ST80, but I'd want to check and make sure we don't break the unloadable/reloadable aspect.
This is probably a non-issue, but I can't check it right now so I'm just mentioning it as a reminder.
Dave
frank
On 27 January 2016 at 02:52, Chris Muller asqueaker@gmail.com wrote:
+1 for Kernel-Input or Kernel-Device. Sensors are concerned with bringing information from the outside world into the software system; like the eyes and ears of the computer.
User-interface is concerned with the interactions between the software and the user.
On Mon, Jan 25, 2016 at 10:01 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Frank,
On Mon, Jan 25, 2016 at 8:18 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel-Processes has Delay, Process, Monitor, Mutex, FutureMaker, Promise, etc. All these work together. They fit nicely in the category.
And then there's InputSensor, EventSensor and EventSensorConstants. What.
Where _should_ these classes belong? Maybe we should have a Kernel-Device or Kernel-Input category?
IMO they don't belong in the Kernel at all. I would add a UserInterface package and put the prerequisites for Morphic, Smalltalk-80 and Graphics in there. I'd also consider Headful and Headless packages for precursors of headful and headless apps.
(I'll not mention how Kernel's InputSensor >> #keyboard uses TextConverter that causes a dependency on Multilingual, which of course has a dependency on Kernel... oh, wait, I did.)
frank
_,,,^..^,,,_ best, Eliot
On 29-01-2016, at 8:45 AM, Chris Muller asqueaker@gmail.com wrote:
How could we possibly unload InputSensor? Isn't that what generates the events necessary to interact with the system? IOW, you wouldn't be able to reload ST80 without InputSensor, right?
It’s been some time since I dug into it and I’m all wrapped up in transforms right now so I won’t be diverting back to it soon, but I’m reasonably certain that InputSensor is actually unused except as a superclass for EventSensor. I don't recall any places where an actual InputSensor ever gets to exist, let alone get used. In MVC projects the Sensor global is an EventSensor, for example. So ‘anyButtonPressed' as I recall uses something like primMouseButtons, which actually goes via the EventSensor version and fetches events to update the variable rather than the ancient primitive.
Some clean-up work could completely get rid of InputSensor
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Trojan: Storage device for replicating codes...
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
On Fri, Jan 29, 2016 at 11:35 AM, tim Rowledge tim@rowledge.org wrote:
On 29-01-2016, at 8:45 AM, Chris Muller asqueaker@gmail.com wrote:
How could we possibly unload InputSensor? Isn't that what generates the events necessary to interact with the system? IOW, you wouldn't be able to reload ST80 without InputSensor, right?
It’s been some time since I dug into it and I’m all wrapped up in transforms right now so I won’t be diverting back to it soon, but I’m reasonably certain that InputSensor is actually unused except as a superclass for EventSensor. I don't recall any places where an actual InputSensor ever gets to exist, let alone get used. In MVC projects the Sensor global is an EventSensor, for example. So ‘anyButtonPressed' as I recall uses something like primMouseButtons, which actually goes via the EventSensor version and fetches events to update the variable rather than the ancient primitive.
Some clean-up work could completely get rid of InputSensor
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Trojan: Storage device for replicating codes...
On 29-01-2016, at 9:43 AM, Chris Muller asqueaker@gmail.com wrote:
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
On 29 January 2016 at 18:07, tim Rowledge tim@rowledge.org wrote:
On 29-01-2016, at 9:43 AM, Chris Muller asqueaker@gmail.com wrote:
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
In a Trunk image, only Smalltalk at: #Sensor points to EventSensor. Nothing points to InputSensor. Nothing points to EventPointerConstants.
So why not in a postload of ST80, evaluate
Environment current bind: #Sensor to: EventSensor
?
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
On 29-01-2016, at 12:01 PM, Frank Shearar frank.shearar@gmail.com wrote:
In a Trunk image, only Smalltalk at: #Sensor points to EventSensor. Nothing points to InputSensor. Nothing points to EventPointerConstants.
So why not in a postload of ST80, evaluate
Environment current bind: #Sensor to: EventSensor
IIRC it’s just a global, so does even that much need doing?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Did you hear about Christopher Robin Hood? He stole from the rich to give to the Pooh
Hi Frank,
On Jan 29, 2016, at 12:01 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2016 at 18:07, tim Rowledge tim@rowledge.org wrote:
On 29-01-2016, at 9:43 AM, Chris Muller asqueaker@gmail.com wrote:
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
In a Trunk image, only Smalltalk at: #Sensor points to EventSensor. Nothing points to InputSensor. Nothing points to EventPointerConstants.
So why not in a postload of ST80, evaluate
Environment current bind: #Sensor to: EventSensor
?
Sounds reasonable, but why not use (or add) EventSensor class>>initialize? The post load strikes me as too fancy.
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
On 29 January 2016 at 20:41, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Frank,
On Jan 29, 2016, at 12:01 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2016 at 18:07, tim Rowledge tim@rowledge.org wrote:
On 29-01-2016, at 9:43 AM, Chris Muller asqueaker@gmail.com wrote:
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
In a Trunk image, only Smalltalk at: #Sensor points to EventSensor. Nothing points to InputSensor. Nothing points to EventPointerConstants.
So why not in a postload of ST80, evaluate
Environment current bind: #Sensor to: EventSensor
?
Sounds reasonable, but why not use (or add) EventSensor class>>initialize? The post load strikes me as too fancy.
Because I'd forgotten I could do that :) There is an EventSensor class>>install which sounds like it would do the right thing, but it doesn't. It seems like the right thing to do then is to add an initialize like this:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
frank
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
On 29.01.2016, at 22:28, Frank Shearar frank.shearar@gmail.com wrote:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
Nope.
You don’t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
The easiest thing would be to simply move InputSensor into the same package as EventSensor.
Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
Packaging-wise the result would be the same: no InputSensor in the St80 package.
- Bert -
On Fri, Jan 29, 2016 at 11:08:34PM +0100, Bert Freudenberg wrote:
On 29.01.2016, at 22:28, Frank Shearar frank.shearar@gmail.com wrote:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
Nope.
You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
The easiest thing would be to simply move InputSensor into the same package as EventSensor.
Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
Packaging-wise the result would be the same: no InputSensor in the St80 package.
- Bert -
It looks to me like the proposed removal of InputSensor is a tiny project that was started in 2000 (*) and probably should be brought to completion one of these days. If we agree that it is a good idea, and if there is no big time pressure to get it done right away, then I'm interested in doing the work.
Dave
(*) The accessors for eventQueue are in InputSensor, but the actual instance variable is already moved to subclass EventSensor. That looks like a work in progress to me. And I'm always happy to try to polish up something that Andreas started for us :-)
On 29 January 2016 at 22:08, Bert Freudenberg bert@freudenbergs.de wrote:
On 29.01.2016, at 22:28, Frank Shearar frank.shearar@gmail.com wrote:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
Nope.
You don’t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
The easiest thing would be to simply move InputSensor into the same package as EventSensor.
They are both in Kernel. Which is where I don't want them :)
Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
Packaging-wise the result would be the same: no InputSensor in the St80 package.
Let's wind back a bit. I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
But it turns out that while ST80 still refers to InputSensor - Controller class >> #initialize calls InputSensor default - InputSensor default actually returns an EventSensor.
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
And we don't need any package initialization or anything else like that.
As an aside, this investigation has revealed that Dependency Browser needs an upgrade: it's not enough to know which classes in a package reference which classes in other packages. Dependency Browser also needs to track dependencies induced via globals - "what globals does this package reference? what are the classes of those globals? in which packages are those classes defined? therefore this package depends on those packages.")
frank
- Bert -
Please hold off on moving anything for a few days. I'm working (in the inbox) on making InputSensor go away.
Dave
On Sat, Jan 30, 2016 at 06:49:17PM +0000, Frank Shearar wrote:
On 29 January 2016 at 22:08, Bert Freudenberg bert@freudenbergs.de wrote:
On 29.01.2016, at 22:28, Frank Shearar frank.shearar@gmail.com wrote:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
Nope.
You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
The easiest thing would be to simply move InputSensor into the same package as EventSensor.
They are both in Kernel. Which is where I don't want them :)
Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
Packaging-wise the result would be the same: no InputSensor in the St80 package.
Let's wind back a bit. I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
But it turns out that while ST80 still refers to InputSensor - Controller class >> #initialize calls InputSensor default - InputSensor default actually returns an EventSensor.
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
And we don't need any package initialization or anything else like that.
As an aside, this investigation has revealed that Dependency Browser needs an upgrade: it's not enough to know which classes in a package reference which classes in other packages. Dependency Browser also needs to track dependencies induced via globals - "what globals does this package reference? what are the classes of those globals? in which packages are those classes defined? therefore this package depends on those packages.")
frank
- Bert -
I will find another thread on which to pull, in the meantime :)
frank
On 30 January 2016 at 18:58, David T. Lewis lewis@mail.msen.com wrote:
Please hold off on moving anything for a few days. I'm working (in the inbox) on making InputSensor go away.
Dave
On Sat, Jan 30, 2016 at 06:49:17PM +0000, Frank Shearar wrote:
On 29 January 2016 at 22:08, Bert Freudenberg bert@freudenbergs.de wrote:
On 29.01.2016, at 22:28, Frank Shearar frank.shearar@gmail.com wrote:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
Nope.
You don???t need to do anything special. MVC works fine using EventSensor. In every image ever since Morphic took over, Sensor has been an instance of EventSensor. Only before that it was an instance of InputSensor.
The easiest thing would be to simply move InputSensor into the same package as EventSensor.
They are both in Kernel. Which is where I don't want them :)
Second-easiest would be to do the cleanup Tim suggested and get rid of InputSensor by moving all its still-needed methods to EventSensor and then deleting that class.
Packaging-wise the result would be the same: no InputSensor in the St80 package.
Let's wind back a bit. I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
But it turns out that while ST80 still refers to InputSensor - Controller class >> #initialize calls InputSensor default - InputSensor default actually returns an EventSensor.
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
And we don't need any package initialization or anything else like that.
As an aside, this investigation has revealed that Dependency Browser needs an upgrade: it's not enough to know which classes in a package reference which classes in other packages. Dependency Browser also needs to track dependencies induced via globals - "what globals does this package reference? what are the classes of those globals? in which packages are those classes defined? therefore this package depends on those packages.")
frank
- Bert -
On 30.01.2016, at 19:49, Frank Shearar frank.shearar@gmail.com wrote:
I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
Isn’t the Kernel’s purpose to provide things to be used by the rest of the system?
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
But yes, it looks odd compared to the other classes in “Kernel-Processes”. Probably it was put there originally because it provide the interrupt watcher process.
Being I/O related it would fit better in “System-Support” with Beeper and Clipboard. (although System-Support looks like a catch-all category … glad you’re thinking about better organization)
- Bert -
On 31 January 2016 at 13:42, Bert Freudenberg bert@freudenbergs.de wrote:
On 30.01.2016, at 19:49, Frank Shearar frank.shearar@gmail.com wrote:
I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
Isn’t the Kernel’s purpose to provide things to be used by the rest of the system?
Sure, but EventSensor isn't. "Kernel" means the most important/central part of something, and I'd argue that keyboards and mice aren't. I don't write interactive programs, I guess, so I don't want
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
But yes, it looks odd compared to the other classes in “Kernel-Processes”. Probably it was put there originally because it provide the interrupt watcher process.
Being I/O related it would fit better in “System-Support” with Beeper and Clipboard. (although System-Support looks like a catch-all category … glad you’re thinking about better organization)
Yeah, that sounds good. I had thought of "System-Sensor", as a possible alternative.
And I agree re System-Support being the "misc" bucket. I wouldn't mind figuring out how to split that category into more meaningful units.
frank
- Bert -
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
On Jan 31, 2016, at 12:49 PM, Chris Muller asqueaker@gmail.com wrote:
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
The inheritance relation won't let you do it. Collection would have to be in Kernel and that's completely wrong. And one can't represent Smalltalk programs without at least Kernel Numbers & Collections cuz all literals are either numbers or collections. So it is a pipe dream to be able to unload these.
It might be nice to split Numbers into Numbers-Kernel and Numbers-TheRestOfTheCoreLibrary to distinguish between those numbers that can be literals and those that aren't, but then you'd have to add Numbers-Base to hold the superclasses of large and small integers and the floats up to and including Number. And of course similarly for Collections. But it's pain for little gain. There are other levels of organization (such as implement its of #isLiteral) that make the finer grain structure visible.
On Jan 31, 2016, at 12:49 PM, Chris Muller asqueaker@gmail.com wrote:
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
The inheritance relation won't let you do it. Collection would have to be in Kernel and that's completely wrong.
Eliot, I just mentioned the concrete classes -- that all of their dependencies (up the inheritance chain) would have to go too, was implied. I see nothing wrong with Collection being defined in Kernel.
And one can't represent Smalltalk programs without at least Kernel Numbers & Collections cuz all literals are either numbers or collections. So it is a pipe dream to be able to unload these.
It might be nice to split Numbers into Numbers-Kernel and Numbers-TheRestOfTheCoreLibrary to distinguish between those numbers that can be literals and those that aren't,
Right! I meant the same with Collections, of course.
but then you'd have to add Numbers-Base to hold the superclasses of large and small integers and the floats up to and including Number.
No, just leave them in Numbers-Kernel. What need is there to distinguish between "Kernel" and "Base"? I don't see any..
And of course similarly for Collections. But it's pain for little gain. There are other levels of organization (such as implement its of #isLiteral) that make the finer grain structure visible.
I thought we were talking about identifying a minimal, "Kernel" Smalltalk system. My only comment was that Array, OC, Set and Dict, and all of the dependencies (superclasses, etc.) would need to be part of that.
On Sun, 31 Jan 2016, Chris Muller wrote:
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
You'd also have to move their superclass hierarchy, so that wouldn't really work. There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
Levente
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial?
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections?
Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system...
Hi Chris,
On Mon, Feb 1, 2016 at 7:55 AM, Chris Muller ma.chris.m@gmail.com wrote:
I guess the distinction between “Kernel” and “System” isn’t quite
clear
to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
There's no need to have a single "kernel" package containing all
essential
classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial?
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections?
Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system...
So let's imagine we're wise and we look forward and we structure the classes in Collections to play well with the category names in Collections, so that all the superclasses of classes in Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support that are themselves Collections classes are in just those categories. Now I can unload all Collections-blah categories except Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support. Because when I look at Collections I see that those six categories are those that provide the minimal subset of Collections that supports the core language's set of literal collections. It provides more, but it is the minimum to provide Array, ByteArray, ByteString, WideString, Symbol, ByteSymbol and WideSymbol.
Now, if that analysis is correct would it be better to change the package structure to have Collections-Kernel and Collections-PotPourri, with categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and so on, or have some other convention such as a class-side method on Collection that defines the kernel categories? I don't know. I do know that there's real pedagogical value in having the six (and other) categories above, and I don't think we should reduce the navigability and comprehensibility of the system to make package structure serve the needs of decomposition rather than the needs of the newbie. The bug is that packages use categories. It's a functional compromise, but it's a little uncomfortable. But the key point is that your point above about LRUCache is a bit of a straw man. If we manage the categories in Collections wisely we can do what you want without too much difficulty.
_,,,^..^,,,_ best, Eliot
Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work?
Using them as a semantic organisation for packages was a simplifying short-cut for Monticello but not a particularly good idea for ‘serious’ package specification. It wouldn’t (he said, waving appendages wildly) be very hard to revise MC to use a quite separate idea of category names from the browser. We’d need separated browsers for package-viewing and category viewing I guess. Is there anything terribly wrong about having a kernel-collections package that included a class or two from category Collections-Unordered, a few Collections-Processes, something from Compiler-Caches etc? And would that really require that every one of those have all the methods installed? Not to mention that an actual kernel system would require quite a few classes anyway
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Mommy! The cursor's winking at me!
Hi Tim,
On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge tim@rowledge.org wrote:
Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work?
Using them as a semantic organisation for packages was a simplifying short-cut for Monticello but not a particularly good idea for ‘serious’ package specification. It wouldn’t (he said, waving appendages wildly) be very hard to revise MC to use a quite separate idea of category names from the browser. We’d need separated browsers for package-viewing and category viewing I guess. Is there anything terribly wrong about having a kernel-collections package that included a class or two from category Collections-Unordered, a few Collections-Processes, something from Compiler-Caches etc? And would that really require that every one of those have all the methods installed? Not to mention that an actual kernel system would require quite a few classes anyway
This was a /huge/ bone of contention in the VisualWorks team when we went to 5i to provide Store, given parcels in 3.0. My position was that package structure was another orthogonal property and structure than class categories. Alan Knight's position was that this was unnecessarily complex and confusing and we should use class categories as packages, as does Monticello. While I think I was right, I want to be happy. I've used Monticello for 8 years and I love it. I do love the simplicity of categories being packages. Occasionally I chafe at the difficulty that categories make in slicing off a subcomponent (one often has to introduce a name like FuBar to carve off Fu-Bar from Fu and its underlings). So while you're right that packages could be separate, and the architecture of Monticello makes that quite straight-forward, it does mean introducing a whole new level of tooling to deal with the new packaging namespace, and a lot of work to reorganize a system that is pretty-well organized right now. So I think it's best to let sleeping dogs lie and live with the situation for now. When someone embarks on a really interesting bootstrap project that constructs minimal images and provides new insights into how the system should be packaged it could be worth revisiting, but I think we have fatter fish to fry right now.
tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Mommy! The cursor's winking at me!
2016-02-01 20:43 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Tim,
On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge tim@rowledge.org wrote:
Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work?
Using them as a semantic organisation for packages was a simplifying short-cut for Monticello but not a particularly good idea for ‘serious’ package specification. It wouldn’t (he said, waving appendages wildly) be very hard to revise MC to use a quite separate idea of category names from the browser. We’d need separated browsers for package-viewing and category viewing I guess. Is there anything terribly wrong about having a kernel-collections package that included a class or two from category Collections-Unordered, a few Collections-Processes, something from Compiler-Caches etc? And would that really require that every one of those have all the methods installed? Not to mention that an actual kernel system would require quite a few classes anyway
This was a /huge/ bone of contention in the VisualWorks team when we went to 5i to provide Store, given parcels in 3.0. My position was that package structure was another orthogonal property and structure than class categories. Alan Knight's position was that this was unnecessarily complex and confusing and we should use class categories as packages, as does Monticello. While I think I was right, I want to be happy. I've used Monticello for 8 years and I love it. I do love the simplicity of categories being packages. Occasionally I chafe at the difficulty that categories make in slicing off a subcomponent (one often has to introduce a name like FuBar to carve off Fu-Bar from Fu and its underlings). So while you're right that packages could be separate, and the architecture of Monticello makes that quite straight-forward, it does mean introducing a whole new level of tooling to deal with the new packaging namespace, and a lot of work to reorganize a system that is pretty-well organized right now. So I think it's best to let sleeping dogs lie and live with the situation for now. When someone embarks on a really interesting bootstrap project that constructs minimal images and provides new insights into how the system should be packaged it could be worth revisiting, but I think we have fatter fish to fry right now.
And now, the categories are kind of deprecated in VW... Absolutely not visible from any Browser. The browsers with double classification were somehow troubling. Maybe the two classifications were too close (more parallel than orthogonal), or said differently, not enough efforts had been put to distinguish the two (i.e. using different vocabulary) - too many efforts for undetermined value?
I too like very much the simplicity of Montiello. In regard, the efforts of Pharo for decoupling classification and package management only lead to trouble so far (compatibility oblige they didn't yet abandon classification oriented packaging if I understand it, but then they would face same problem as VW IMO).
Nicolas
tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Mommy! The cursor's winking at me!
-- _,,,^..^,,,_ best, Eliot
You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial?
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections?
Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system...
So let's imagine we're wise and we look forward and we structure the classes in Collections to play well with the category names in Collections, so that all the superclasses of classes in Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support that are themselves Collections classes are in just those categories. Now I can unload all Collections-blah categories except Collections-Abstract, Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable, Collections-Strings and Collections-Support. Because when I look at Collections I see that those six categories are those that provide the minimal subset of Collections that supports the core language's set of literal collections.
*You* can see that, a newbie couldn't. A newbie would have no way to know what all packages would be needed to simply have a "kernel" system. They would wonder why they couldn't just load "Kernel", huh? If the hierarchy for those would be reversed, as in, Kernel-Collections-Abstract, Kernel-Collections-Arrayed, Kernel-Collections-Exceptions, Kernel-Collections-Sequenceable, Kernel-Collections-Strings and Kernel-Collections-Support, THEN we've actually got a match between the newbie's semantic notion of a "Kernel" with the actual physical reality of what the system needs.
The top-level(s) of the category defines the Package. I don't believe this needs to be a compromise. Let the top-level(s) determine the package, based on *physical* dependency within the system, while the 2nd thru lower levels define the semantic (sub)categorical organization within the system.
It provides more, but it is the minimum to provide Array, ByteArray, ByteString, WideString, Symbol, ByteSymbol and WideSymbol.
Now, if that analysis is correct would it be better to change the package structure to have Collections-Kernel and Collections-PotPourri, with categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and so on, or have some other convention such as a class-side method on Collection that defines the kernel categories? I don't know. I do know that there's real pedagogical value in having the six (and other) categories above, and I don't think we should reduce the navigability and comprehensibility of the system to make package structure serve the needs of decomposition rather than the needs of the newbie. The bug is that packages use categories. It's a functional compromise, but it's a little uncomfortable. But the key point is that your point above about LRUCache is a bit of a straw man. If we manage the categories in Collections wisely we can do what you want without too much difficulty.
On Mon, 1 Feb 2016, Chris Muller wrote:
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
Because that would mean moving at least 20% of the classes of the Collections package.
There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking
No, we don't. We have some packages with mixed roles. Instead of moving the kernel-related collection classes from Colletions to Kernel, you could just create a new package, e.g. Kernel-Collections, which would contain these. Such smaller packages can greatly simplify the dependencies between packages.
Levente
about then? Just moving things around to different packages based on some "improved" notion of subjective semantic classification, with no regard for the physical system dependencies? Why would that be beneficial?
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is it to have it in Collections?
Is LRUCache part of any Smalltalk's Kernel? No, but if its in Collections along with Symbol, then I'm forced to remove it manually after loading "many kernel packages" if I just want a Kernel system...
On Mon, Feb 1, 2016 at 12:58 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Mon, 1 Feb 2016, Chris Muller wrote:
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
I guess, for me, Kernel contains those things that are essential to a running Smalltalk image. System contains stuff that's generally useful to most things - most, but not all.
I've long thought that we'll eventually move Array, OrderedCollection, Set and Dictionary to Kernel so that Collections could be unloaded...
You'd also have to move their superclass hierarchy,
Of course. That was implied.
so that wouldn't really work.
Why not?
Because that would mean moving at least 20% of the classes of the Collections package.
There's no need to have a single "kernel" package containing all essential classes, so IMHO it's better to have many kernel packages.
"Many kernel packages" is what we have now. So what are we talking
No, we don't. We have some packages with mixed roles. Instead of moving the kernel-related collection classes from Colletions to Kernel, you could just create a new package, e.g. Kernel-Collections, which would contain these. Such smaller packages can greatly simplify the dependencies between packages.
In my mind, the overarching goal at the end of the day is to have a system that is both navigable and comprehensible (as Eliot said), while at the same time being easy to configure and use. By making a bunch of new tiny packages for every node in the category-hierarchy (i.e., Collections-Abc, Collections-Xyz, Colections-Qrs, etc.), Pharo accomplished the former, while sacrificing the latter. The burden was simply offloaded to configuration.
Fine-grained packages represents the worst of both worlds -- they don't necessarily solve circular-dependency issues, and yet, they greatly increase configuration burden onto users.
(.. And still can't configure a truly minimal system, because even those tiny packages still contain more than is needed (albeit, not AS much more). /True/ minimalism can only be achieved by unloading behaviors (classes and methods), not packages.)
Hi Bert,
On Jan 31, 2016, at 5:42 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 30.01.2016, at 19:49, Frank Shearar frank.shearar@gmail.com wrote: I'm not really interested in InputSensor & EventSensor's relationship. I care that Kernel has these classes, when nothing in Kernel even uses them. They don't belong there.
Isn’t the Kernel’s purpose to provide things to be used by the rest of the system?
I think of Kernel as the core language in terms of its self-representation, so we have classes, methods, contexts and processes and the related support.
In this sense an input scheme that is specific to a given implementation isn't at all kernel, just as I don't expect to see stdio support in kernel. Would you agree?
Thing is, Sensor is referenced by a whole ton of packages - Tools, Graphics, Sound, Morphic. So clearly putting EventSensor in ST80 is wrong. Therefore, I think we need to put InputSensor, EventSensor and EventSensorConstants into _System_.
I guess the distinction between “Kernel” and “System” isn’t quite clear to me.
Alas the circular nature of Collections Numbers Kernel and System make it difficult to draw clear boundaries. These packages are rather incestuous but again for me the distinction between Kernel and System is between core language self-representation and core language semantics support and system semantics support. In System we have the Smalltalk namespace (& if environments weren't in their own package they would belong here) plus all the change support to allow clients to observe changes of the state of the system, logging of doors etc. some of this same support is in ClassDescription (compiling of source and writing it to the changes file) but that's just because we haven't done the work. Ideally kernel wouldn't include notions of compilation either, just what's needed to represent Smalltalk code.
But yes, it looks odd compared to the other classes in “Kernel-Processes”. Probably it was put there originally because it provide the interrupt watcher process.
Being I/O related it would fit better in “System-Support” with Beeper and Clipboard. (although System-Support looks like a catch-all category … glad you’re thinking about better organization)
- Bert -
On Jan 29, 2016, at 1:28 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2016 at 20:41, Eliot Miranda eliot.miranda@gmail.com wrote: Hi Frank,
On Jan 29, 2016, at 12:01 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 29 January 2016 at 18:07, tim Rowledge tim@rowledge.org wrote:
On 29-01-2016, at 9:43 AM, Chris Muller asqueaker@gmail.com wrote:
You can't unload a superclass without unloading its subclasses. So, let me rephrase the question: How could EventSensor be unloaded and then reloaded?
Ah, wrong question in this case. I suggest that we don’t need to even consider the issue of unloading either sensor class since it would be better to clean things up and simply get rid of InputSensor completely.
In a Trunk image, only Smalltalk at: #Sensor points to EventSensor. Nothing points to InputSensor. Nothing points to EventPointerConstants.
So why not in a postload of ST80, evaluate
Environment current bind: #Sensor to: EventSensor
?
Yes :)
Sounds reasonable, but why not use (or add) EventSensor class>>initialize? The post load strikes me as too fancy.
Because I'd forgotten I could do that :) There is an EventSensor class>>install which sounds like it would do the right thing, but it doesn't. It seems like the right thing to do then is to add an initialize like this:
initialize Environment current bind: #Sensor to: EventSensor.
Sound good?
frank
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier -
tim Rowledge