From ma.chris.m at gmail.com Mon Feb 1 00:35:26 2016 From: ma.chris.m at gmail.com (Chris Muller) Date: Mon Feb 1 00:36:08 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: <8B4C3402-17D8-4746-AFF9-EE6011653428@gmail.com> References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> <8B4C3402-17D8-4746-AFF9-EE6011653428@gmail.com> Message-ID: > On Jan 31, 2016, at 12:49 PM, 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... > > 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. From commits at source.squeak.org Mon Feb 1 01:30:26 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Feb 1 01:30:28 2016 Subject: [squeak-dev] The Trunk: Graphics-dtl.322.mcz Message-ID: David T. Lewis uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-dtl.322.mcz ==================== Summary ==================== Name: Graphics-dtl.322 Author: dtl Time: 1 February 2016, 8:30:11.24536 pm UUID: 72d5d729-f6ef-47f3-b637-1271b82fe528 Ancestors: Graphics-eem.321 Move #testJoystick: to EventSensor because InputSensor will be removed. =============== Diff against Graphics-eem.321 =============== Item was added: + ----- Method: EventSensor>>testJoystick: (in category '*Graphics-KernelExtensions') ----- + testJoystick: index + "Sensor testJoystick: 3" + + | f pt buttons status | + f := Form extent: 110@50. + [Sensor anyButtonPressed] whileFalse: [ + pt := Sensor joystickXY: index. + buttons := Sensor joystickButtons: index. + status := + 'xy: ', pt printString, ' + buttons: ', buttons printStringHex. + f fillWhite. + status displayOn: f at: 10@10. + f displayOn: Display at: 10@10. + ]. + ! Item was removed: - ----- Method: InputSensor>>testJoystick: (in category '*Graphics-KernelExtensions') ----- - testJoystick: index - "Sensor testJoystick: 3" - - | f pt buttons status | - f := Form extent: 110@50. - [Sensor anyButtonPressed] whileFalse: [ - pt := Sensor joystickXY: index. - buttons := Sensor joystickButtons: index. - status := - 'xy: ', pt printString, ' - buttons: ', buttons printStringHex. - f fillWhite. - status displayOn: f at: 10@10. - f displayOn: Display at: 10@10. - ]. - ! From commits at source.squeak.org Mon Feb 1 09:23:58 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Feb 1 09:24:00 2016 Subject: [squeak-dev] The Trunk: Morphic-mt.1070.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1070.mcz ==================== Summary ==================== Name: Morphic-mt.1070 Author: mt Time: 1 February 2016, 10:22:48.528285 am UUID: 820409c5-06df-43bb-aae0-ee27057ead43 Ancestors: Morphic-tpr.1069 Fixes bounds issue regarding refreshed items in object explorer and other tree applications. Thanks to Karl Ramberg for the idea. =============== Diff against Morphic-tpr.1069 =============== Item was changed: ----- Method: IndentingListItemMorph>>refresh (in category 'initialization') ----- refresh self contents: self getLabel. icon := self getIcon. + self width: container preferredSubmorphWidth. (self valueOfProperty: #wasRefreshed ifAbsent: [false]) ifFalse: [ self setProperty: #wasRefreshed toValue: true. self color: Color yellow. "Indicate refresh operation."].! Item was changed: ----- Method: SimpleHierarchicalListMorph>>adjustSubmorphPositions (in category 'private') ----- adjustSubmorphPositions | p | p := 0@0. scroller submorphsDo: [ :each | | h | each visible ifTrue: [ h := each height. + each privateBounds: (p extent: self preferredSubmorphWidth@h). - each privateBounds: (p extent: 9999@h). p := p + (0@h) ]]. self changed; layoutChanged; setScrollDeltas. ! Item was added: + ----- Method: SimpleHierarchicalListMorph>>preferredSubmorphWidth (in category 'private') ----- + preferredSubmorphWidth + + ^ 9999! From commits at source.squeak.org Mon Feb 1 09:30:32 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Feb 1 09:30:33 2016 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.158.mcz Message-ID: Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.158.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.158 Author: mt Time: 1 February 2016, 10:29:47.512285 am UUID: 6aa4ffd8-7313-4369-a342-7b7a64f3cc63 Ancestors: ToolBuilder-Morphic-mt.157 Adds support for selective refreshing in pluggable tree morphs that make use of the generic PluggableTreeItemNode. To use, send "self changed: #objectChanged with: anObject" in the tool's model. See ObjectExplorer >> #step for an example. Note that ObjectExplorer uses the customized ObjectExplorerWrapper instead of the PluggableTreeItemNode. However, this does not affect the basic idea behind #objectChanged. =============== Diff against ToolBuilder-Morphic-mt.157 =============== Item was changed: ListItemWrapper subclass: #PluggableTreeItemNode + instanceVariableNames: 'parent index' - instanceVariableNames: 'parent' classVariableNames: '' poolDictionaries: '' category: 'ToolBuilder-Morphic'! + !PluggableTreeItemNode commentStamp: 'mt 2/1/2016 10:24' prior: 0! + Tree item for PluggableTreeMorph. My model is the tree morph. I keep track of my parent item and the index in my parent's list of children to support selective refreshing.! - !PluggableTreeItemNode commentStamp: 'mt 3/7/2015 09:15' prior: 0! - Tree item for PluggableTreeMorph. My model is the tree morph.! Item was added: + ----- Method: PluggableTreeItemNode>>index (in category 'accessing') ----- + index + + ^ index! Item was added: + ----- Method: PluggableTreeItemNode>>index: (in category 'accessing') ----- + index: anInteger + + index := anInteger.! Item was changed: ----- Method: PluggableTreeItemNode>>refresh (in category 'as yet unclassified') ----- refresh + + self setItem: (self parent contents + at: self index + ifAbsent: [self error: 'No support for changed child count yet!!']) + item.! - "Todo. See ObjectExplorerWrapper >> #refresh."! Item was changed: ----- Method: PluggableTreeMorph>>contentsOfNode: (in category 'node access') ----- contentsOfNode: node | children | getChildrenSelector ifNil:[^#()]. children := model perform: getChildrenSelector with: node item. + ^children collectWithIndex: [:item :index | + (self nodeClass with: item model: self) + index: index; + parent: node]! - ^children collect: [:item| - (self nodeClass with: item model: self) parent: node]! From commits at source.squeak.org Mon Feb 1 09:45:33 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Feb 1 09:45:34 2016 Subject: [squeak-dev] The Trunk: Tools-mt.668.mcz Message-ID: Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.668.mcz ==================== Summary ==================== Name: Tools-mt.668 Author: mt Time: 1 February 2016, 10:44:38.861285 am UUID: 88b24b27-f952-4e86-9bd5-be64c8e309e2 Ancestors: Tools-mt.667 Adds support for selective refreshing to object explorer. Just re-select the current selection to refresh it. Item will get highlighted just like automatic monitor refresh to indicate inconsistency of displayed information. Make the still existing deficiency with volatile object state more descriptive with a pop-up instead of a generic assert error. Now that we support selective refreshing, the user is actually able to refresh and THEN invoke the context menu again. =============== Diff against Tools-mt.667 =============== Item was changed: ----- Method: ObjectExplorer>>currentSelection: (in category 'accessing') ----- currentSelection: anObject + self currentSelection == anObject ifTrue: [ + self changed: #objectChanged with: anObject. + ^ self]. + - self currentSelection == anObject ifTrue: [^ self]. currentSelection := anObject. self changed: #currentSelection. self changed: #style.! Item was changed: ----- Method: ObjectExplorer>>explorerKey:from:event: (in category 'menus') ----- explorerKey: aChar from: view event: event event anyModifierKeyPressed ifFalse: [^ false]. currentSelection ifNotNil: [ + self updateInspectorForSelection ifFalse: [^ true]. - self updateInspectorForSelection. aChar == $i ifTrue: [self inspector inspectSelection. ^ true]. aChar == $I ifTrue: [self inspector exploreSelection. ^ true]. aChar == $b ifTrue: [self inspector browseMethodFull. ^ true]. aChar == $h ifTrue: [self inspector classHierarchy. ^ true]. aChar == $c ifTrue: [Clipboard clipboardText: self currentSelection key. ^ true]. aChar == $p ifTrue: [self inspector browseFullProtocol. ^ true]. aChar == $N ifTrue: [self inspector browseClassRefs. ^ true]. aChar == $t ifTrue: [self inspector tearOffTile. ^ true]. aChar == $v ifTrue: [self inspector viewerForValue. ^ true]]. ^ false! Item was changed: ----- Method: ObjectExplorer>>genericMenu: (in category 'menus') ----- genericMenu: aMenu "Borrow a menu from my inspector" currentSelection ifNil: [ aMenu add: '*nothing selected*' target: self selector: #yourself] ifNotNil: [ + self updateInspectorForSelection ifFalse: [^ aMenu]. - self updateInspectorForSelection. aMenu defaultTarget: self inspector. self inspector fieldListMenu: aMenu. aMenu addLine; add: 'monitor changes' target: self selector: #monitor: argument: currentSelection]. monitorList isEmptyOrNil ifFalse: [aMenu addLine; add: 'stop monitoring all' target: self selector: #stopMonitoring]. ^ aMenu! Item was changed: ----- Method: ObjectExplorer>>updateInspectorForSelection (in category 'accessing - other') ----- updateInspectorForSelection "Reuse the inspector for some callbacks." self inspector inspect: (self parentObject ifNil: [self object]). self parentObject ifNil: [self inspector toggleIndex: 1. "self"] ifNotNil: [ self inspector toggleIndex: (self inspector fieldList indexOf: self currentSelection key)]. + + self inspector selection == self object + ifTrue: [ + ^ true] + ifFalse: [ + self inform: 'Object has changed. Please refresh\before invoking the context menu.' withCRs. + ^ false].! - self assert: self inspector selection == self object.! From Marcel.Taeumel at hpi.de Mon Feb 1 09:23:28 2016 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Feb 1 09:47:01 2016 Subject: [squeak-dev] Re: The Trunk: Tools-mt.668.mcz In-Reply-To: References: Message-ID: <1454318608109-4875140.post@n4.nabble.com> Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Tools-mt-668-mcz-tp4875137p4875140.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Mon Feb 1 10:00:39 2016 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Feb 1 10:24:12 2016 Subject: [squeak-dev] Re: DamageRecorder>recordInvalidRect: one truncate too far? In-Reply-To: References: <73704474-4EC0-45D9-855C-84C3BCE3B1FA@rowledge.org> <1454141800226-4874904.post@n4.nabble.com> Message-ID: <1454320839542-4875147.post@n4.nabble.com> You're right. #truncated is wrong here. We need #ceiling and #floor calls. We have to fix that. Additionally, I wonder whether the magic numbers 40, 4, and 15 still hold for modern systems/VMs. Best, Marcel -- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-tp4874894p4875147.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Mon Feb 1 10:21:02 2016 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Feb 1 10:44:35 2016 Subject: [squeak-dev] Re: DamageRecorder>recordInvalidRect: one truncate too far? In-Reply-To: <1454320839542-4875147.post@n4.nabble.com> References: <73704474-4EC0-45D9-855C-84C3BCE3B1FA@rowledge.org> <1454141800226-4874904.post@n4.nabble.com> <1454320839542-4875147.post@n4.nabble.com> Message-ID: <1454322062167-4875151.post@n4.nabble.com> There are other calls of #truncated to rectangles, where IMO #expanded is needed. And there is #truncated in #transformBy:clippingTo:#during:#smoothing in FormCanvas where one really should decide for #ceiling OR #floor to avoid shrinking thinks by accident. Best, Marcel -- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-tp4874894p4875151.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From leves at caesar.elte.hu Mon Feb 1 14:08:22 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Mon Feb 1 14:08:32 2016 Subject: [squeak-dev] Squeak Board 2016 Candidates wanted In-Reply-To: <008801d15aa6$fb7e3b80$f27ab280$@usmedrec.com> References: <008801d15aa6$fb7e3b80$f27ab280$@usmedrec.com> Message-ID: I'm also running this year. Levente On Fri, 29 Jan 2016, Ron Teitelbaum wrote: > > Hi all, > > ? > > We currently have 7 candidates for 7 board seats. > > ? > > By order of announcement: > > ? > > Tim Rowledge > > Marcel Taeumel > > Craig Latta > > Bert Freudenberg > > Chris Muller > > David T. Lewis > > Edgar J. De Cleene > > ? > > That is great but it would be nice to have more candidates!? You have until Monday to announce your candidacy.? If you are going to run now is the time! > > ? > > Also please remember that it is important to VOTE!? Even if we have 7 candidates and 7 seats please VOTE!? I have heard from some of you that you feel very well represented by your board, which is great!? Voting is one way to tell them you support them! > > ? > > You can follow the details of this election here: > > http://wiki.squeak.org/squeak/6346 > > ? > > All the best, > > ? > > Ron Teitelbaum > > Head Of Engineering > > 3D Immersive Collaboration Consulting > > ron@3Dicc.com > > Follow Me On Twitter: @RonTeitelbaum > > www.3Dicc.com > > https://www.google.com/+3Dicc > > ? > > ? > > > From leves at caesar.elte.hu Mon Feb 1 15:20:09 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Mon Feb 1 15:20:12 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: 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 From karlramberg at gmail.com Mon Feb 1 15:43:44 2016 From: karlramberg at gmail.com (karl ramberg) Date: Mon Feb 1 15:43:47 2016 Subject: [squeak-dev] Re: The Trunk: Tools-mt.668.mcz In-Reply-To: <1454318608109-4875140.post@n4.nabble.com> References: <1454318608109-4875140.post@n4.nabble.com> Message-ID: Really nice changes for ObjectExplorer. Thank you Best, Karl On Mon, Feb 1, 2016 at 10:23 AM, marcel.taeumel wrote: > > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/The-Trunk-Tools-mt-668-mcz-tp4875137p4875140.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/4d0387b2/attachment.htm From ma.chris.m at gmail.com Mon Feb 1 15:55:46 2016 From: ma.chris.m at gmail.com (Chris Muller) Date: Mon Feb 1 15:56:29 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: >>>> 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... From asqueaker at gmail.com Mon Feb 1 16:45:56 2016 From: asqueaker at gmail.com (Chris Muller) Date: Mon Feb 1 16:46:38 2016 Subject: [squeak-dev] The Trunk: Tools-mt.668.mcz In-Reply-To: <56af2941.8fea8c0a.27e93.ffffcea8SMTPIN_ADDED_MISSING@mx.google.com> References: <56af2941.8fea8c0a.27e93.ffffcea8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Wouldn't it be better to just silently refresh it FOR the user in that case, rather than bother them with a pop up? On Mon, Feb 1, 2016 at 3:45 AM, wrote: > Marcel Taeumel uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-mt.668.mcz > > ==================== Summary ==================== > > Name: Tools-mt.668 > Author: mt > Time: 1 February 2016, 10:44:38.861285 am > UUID: 88b24b27-f952-4e86-9bd5-be64c8e309e2 > Ancestors: Tools-mt.667 > > Adds support for selective refreshing to object explorer. Just re-select the current selection to refresh it. Item will get highlighted just like automatic monitor refresh to indicate inconsistency of displayed information. > > Make the still existing deficiency with volatile object state more descriptive with a pop-up instead of a generic assert error. Now that we support selective refreshing, the user is actually able to refresh and THEN invoke the context menu again. > > =============== Diff against Tools-mt.667 =============== > > Item was changed: > ----- Method: ObjectExplorer>>currentSelection: (in category 'accessing') ----- > currentSelection: anObject > > + self currentSelection == anObject ifTrue: [ > + self changed: #objectChanged with: anObject. > + ^ self]. > + > - self currentSelection == anObject ifTrue: [^ self]. > currentSelection := anObject. > > self changed: #currentSelection. > self changed: #style.! > > Item was changed: > ----- Method: ObjectExplorer>>explorerKey:from:event: (in category 'menus') ----- > explorerKey: aChar from: view event: event > > event anyModifierKeyPressed ifFalse: [^ false]. > > currentSelection ifNotNil: [ > + self updateInspectorForSelection ifFalse: [^ true]. > - self updateInspectorForSelection. > > aChar == $i ifTrue: [self inspector inspectSelection. ^ true]. > aChar == $I ifTrue: [self inspector exploreSelection. ^ true]. > > aChar == $b ifTrue: [self inspector browseMethodFull. ^ true]. > aChar == $h ifTrue: [self inspector classHierarchy. ^ true]. > aChar == $c ifTrue: [Clipboard clipboardText: self currentSelection key. ^ true]. > aChar == $p ifTrue: [self inspector browseFullProtocol. ^ true]. > aChar == $N ifTrue: [self inspector browseClassRefs. ^ true]. > aChar == $t ifTrue: [self inspector tearOffTile. ^ true]. > aChar == $v ifTrue: [self inspector viewerForValue. ^ true]]. > > ^ false! > > Item was changed: > ----- Method: ObjectExplorer>>genericMenu: (in category 'menus') ----- > genericMenu: aMenu > "Borrow a menu from my inspector" > > currentSelection > ifNil: [ > aMenu > add: '*nothing selected*' > target: self > selector: #yourself] > ifNotNil: [ > + self updateInspectorForSelection ifFalse: [^ aMenu]. > - self updateInspectorForSelection. > aMenu defaultTarget: self inspector. > self inspector fieldListMenu: aMenu. > > aMenu addLine; > add: 'monitor changes' > target: self > selector: #monitor: > argument: currentSelection]. > monitorList isEmptyOrNil > ifFalse: [aMenu addLine; > add: 'stop monitoring all' > target: self > selector: #stopMonitoring]. > ^ aMenu! > > Item was changed: > ----- Method: ObjectExplorer>>updateInspectorForSelection (in category 'accessing - other') ----- > updateInspectorForSelection > "Reuse the inspector for some callbacks." > > self inspector inspect: (self parentObject ifNil: [self object]). > > self parentObject > ifNil: [self inspector toggleIndex: 1. "self"] > ifNotNil: [ > self inspector toggleIndex: (self inspector fieldList indexOf: self currentSelection key)]. > + > + self inspector selection == self object > + ifTrue: [ > + ^ true] > + ifFalse: [ > + self inform: 'Object has changed. Please refresh\before invoking the context menu.' withCRs. > + ^ false].! > - self assert: self inspector selection == self object.! > > From Marcel.Taeumel at hpi.de Mon Feb 1 17:02:11 2016 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Feb 1 17:25:48 2016 Subject: [squeak-dev] Re: The Trunk: Tools-mt.668.mcz In-Reply-To: References: Message-ID: <1454346131949-4875210.post@n4.nabble.com> Hi Chris, sure, but it is still an indication for a volatile object. HandMorphs, for example, will still change things even if the context menu appears after a refresh. Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Tools-mt-668-mcz-tp4875137p4875210.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From eliot.miranda at gmail.com Mon Feb 1 17:51:47 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Feb 1 17:51:50 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: Hi Chris, On Mon, Feb 1, 2016 at 7:55 AM, 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? > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/20234f80/attachment.htm From leves at caesar.elte.hu Mon Feb 1 18:58:30 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Mon Feb 1 18:58:35 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: 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... > From leves at caesar.elte.hu Mon Feb 1 19:02:27 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Mon Feb 1 19:02:35 2016 Subject: [squeak-dev] The Trunk: Tools-mt.668.mcz In-Reply-To: References: <56af2941.8fea8c0a.27e93.ffffcea8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: I'd hate if Explorers were not able to keep their state when the explored obejcts changed. This would make it impossible to explore an object, change its structure, then open another explorer on it to compare the old state with the new. I haven't checked this new "reselect to refresh" feature, but I think it breaks what I described above. Levente On Mon, 1 Feb 2016, Chris Muller wrote: > Wouldn't it be better to just silently refresh it FOR the user in that > case, rather than bother them with a pop up? > > On Mon, Feb 1, 2016 at 3:45 AM, wrote: >> Marcel Taeumel uploaded a new version of Tools to project The Trunk: >> http://source.squeak.org/trunk/Tools-mt.668.mcz >> >> ==================== Summary ==================== >> >> Name: Tools-mt.668 >> Author: mt >> Time: 1 February 2016, 10:44:38.861285 am >> UUID: 88b24b27-f952-4e86-9bd5-be64c8e309e2 >> Ancestors: Tools-mt.667 >> >> Adds support for selective refreshing to object explorer. Just re-select the current selection to refresh it. Item will get highlighted just like automatic monitor refresh to indicate inconsistency of displayed information. >> >> Make the still existing deficiency with volatile object state more descriptive with a pop-up instead of a generic assert error. Now that we support selective refreshing, the user is actually able to refresh and THEN invoke the context menu again. >> >> =============== Diff against Tools-mt.667 =============== >> >> Item was changed: >> ----- Method: ObjectExplorer>>currentSelection: (in category 'accessing') ----- >> currentSelection: anObject >> >> + self currentSelection == anObject ifTrue: [ >> + self changed: #objectChanged with: anObject. >> + ^ self]. >> + >> - self currentSelection == anObject ifTrue: [^ self]. >> currentSelection := anObject. >> >> self changed: #currentSelection. >> self changed: #style.! >> >> Item was changed: >> ----- Method: ObjectExplorer>>explorerKey:from:event: (in category 'menus') ----- >> explorerKey: aChar from: view event: event >> >> event anyModifierKeyPressed ifFalse: [^ false]. >> >> currentSelection ifNotNil: [ >> + self updateInspectorForSelection ifFalse: [^ true]. >> - self updateInspectorForSelection. >> >> aChar == $i ifTrue: [self inspector inspectSelection. ^ true]. >> aChar == $I ifTrue: [self inspector exploreSelection. ^ true]. >> >> aChar == $b ifTrue: [self inspector browseMethodFull. ^ true]. >> aChar == $h ifTrue: [self inspector classHierarchy. ^ true]. >> aChar == $c ifTrue: [Clipboard clipboardText: self currentSelection key. ^ true]. >> aChar == $p ifTrue: [self inspector browseFullProtocol. ^ true]. >> aChar == $N ifTrue: [self inspector browseClassRefs. ^ true]. >> aChar == $t ifTrue: [self inspector tearOffTile. ^ true]. >> aChar == $v ifTrue: [self inspector viewerForValue. ^ true]]. >> >> ^ false! >> >> Item was changed: >> ----- Method: ObjectExplorer>>genericMenu: (in category 'menus') ----- >> genericMenu: aMenu >> "Borrow a menu from my inspector" >> >> currentSelection >> ifNil: [ >> aMenu >> add: '*nothing selected*' >> target: self >> selector: #yourself] >> ifNotNil: [ >> + self updateInspectorForSelection ifFalse: [^ aMenu]. >> - self updateInspectorForSelection. >> aMenu defaultTarget: self inspector. >> self inspector fieldListMenu: aMenu. >> >> aMenu addLine; >> add: 'monitor changes' >> target: self >> selector: #monitor: >> argument: currentSelection]. >> monitorList isEmptyOrNil >> ifFalse: [aMenu addLine; >> add: 'stop monitoring all' >> target: self >> selector: #stopMonitoring]. >> ^ aMenu! >> >> Item was changed: >> ----- Method: ObjectExplorer>>updateInspectorForSelection (in category 'accessing - other') ----- >> updateInspectorForSelection >> "Reuse the inspector for some callbacks." >> >> self inspector inspect: (self parentObject ifNil: [self object]). >> >> self parentObject >> ifNil: [self inspector toggleIndex: 1. "self"] >> ifNotNil: [ >> self inspector toggleIndex: (self inspector fieldList indexOf: self currentSelection key)]. >> + >> + self inspector selection == self object >> + ifTrue: [ >> + ^ true] >> + ifFalse: [ >> + self inform: 'Object has changed. Please refresh\before invoking the context menu.' withCRs. >> + ^ false].! >> - self assert: self inspector selection == self object.! >> >> > > From karlramberg at gmail.com Mon Feb 1 19:15:08 2016 From: karlramberg at gmail.com (karl ramberg) Date: Mon Feb 1 19:15:11 2016 Subject: [squeak-dev] The Trunk: Tools-mt.668.mcz In-Reply-To: References: <56af2941.8fea8c0a.27e93.ffffcea8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, Feb 1, 2016 at 8:02 PM, Levente Uzonyi wrote: > I'd hate if Explorers were not able to keep their state when the explored > obejcts changed. This would make it impossible to explore an object, change > its structure, then open another explorer on it to compare the old state > with the new. > I haven't checked this new "reselect to refresh" feature, but I think it > breaks what I described above. It does still work as before, except if you click a second time on a line item you already selected. Then it updates it's content. I think you get the best of both worlds with this change. Best, Karl > > Levente > > > On Mon, 1 Feb 2016, Chris Muller wrote: > > Wouldn't it be better to just silently refresh it FOR the user in that >> case, rather than bother them with a pop up? >> >> On Mon, Feb 1, 2016 at 3:45 AM, wrote: >> >>> Marcel Taeumel uploaded a new version of Tools to project The Trunk: >>> http://source.squeak.org/trunk/Tools-mt.668.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Tools-mt.668 >>> Author: mt >>> Time: 1 February 2016, 10:44:38.861285 am >>> UUID: 88b24b27-f952-4e86-9bd5-be64c8e309e2 >>> Ancestors: Tools-mt.667 >>> >>> Adds support for selective refreshing to object explorer. Just re-select >>> the current selection to refresh it. Item will get highlighted just like >>> automatic monitor refresh to indicate inconsistency of displayed >>> information. >>> >>> Make the still existing deficiency with volatile object state more >>> descriptive with a pop-up instead of a generic assert error. Now that we >>> support selective refreshing, the user is actually able to refresh and THEN >>> invoke the context menu again. >>> >>> =============== Diff against Tools-mt.667 =============== >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>currentSelection: (in category >>> 'accessing') ----- >>> currentSelection: anObject >>> >>> + self currentSelection == anObject ifTrue: [ >>> + self changed: #objectChanged with: anObject. >>> + ^ self]. >>> + >>> - self currentSelection == anObject ifTrue: [^ self]. >>> currentSelection := anObject. >>> >>> self changed: #currentSelection. >>> self changed: #style.! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>explorerKey:from:event: (in category >>> 'menus') ----- >>> explorerKey: aChar from: view event: event >>> >>> event anyModifierKeyPressed ifFalse: [^ false]. >>> >>> currentSelection ifNotNil: [ >>> + self updateInspectorForSelection ifFalse: [^ true]. >>> - self updateInspectorForSelection. >>> >>> aChar == $i ifTrue: [self inspector inspectSelection. ^ >>> true]. >>> aChar == $I ifTrue: [self inspector exploreSelection. ^ >>> true]. >>> >>> aChar == $b ifTrue: [self inspector >>> browseMethodFull. ^ true]. >>> aChar == $h ifTrue: [self inspector classHierarchy. >>> ^ true]. >>> aChar == $c ifTrue: [Clipboard clipboardText: self >>> currentSelection key. ^ true]. >>> aChar == $p ifTrue: [self inspector browseFullProtocol. >>> ^ true]. >>> aChar == $N ifTrue: [self inspector browseClassRefs. ^ >>> true]. >>> aChar == $t ifTrue: [self inspector tearOffTile. ^ true]. >>> aChar == $v ifTrue: [self inspector viewerForValue. ^ >>> true]]. >>> >>> ^ false! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>genericMenu: (in category 'menus') ----- >>> genericMenu: aMenu >>> "Borrow a menu from my inspector" >>> >>> currentSelection >>> ifNil: [ >>> aMenu >>> add: '*nothing selected*' >>> target: self >>> selector: #yourself] >>> ifNotNil: [ >>> + self updateInspectorForSelection ifFalse: [^ >>> aMenu]. >>> - self updateInspectorForSelection. >>> aMenu defaultTarget: self inspector. >>> self inspector fieldListMenu: aMenu. >>> >>> aMenu addLine; >>> add: 'monitor changes' >>> target: self >>> selector: #monitor: >>> argument: currentSelection]. >>> monitorList isEmptyOrNil >>> ifFalse: [aMenu addLine; >>> add: 'stop monitoring all' >>> target: self >>> selector: #stopMonitoring]. >>> ^ aMenu! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>updateInspectorForSelection (in category >>> 'accessing - other') ----- >>> updateInspectorForSelection >>> "Reuse the inspector for some callbacks." >>> >>> self inspector inspect: (self parentObject ifNil: [self object]). >>> >>> self parentObject >>> ifNil: [self inspector toggleIndex: 1. "self"] >>> ifNotNil: [ >>> self inspector toggleIndex: (self inspector >>> fieldList indexOf: self currentSelection key)]. >>> + >>> + self inspector selection == self object >>> + ifTrue: [ >>> + ^ true] >>> + ifFalse: [ >>> + self inform: 'Object has changed. Please >>> refresh\before invoking the context menu.' withCRs. >>> + ^ false].! >>> - self assert: self inspector selection == self object.! >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/faf163d2/attachment.htm From tim at rowledge.org Mon Feb 1 19:25:50 2016 From: tim at rowledge.org (tim Rowledge) Date: Mon Feb 1 19:25:54 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: <92292DE9-CF1D-4F81-80D3-535EA74958AB@rowledge.org> 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! From ma.chris.m at gmail.com Mon Feb 1 19:26:53 2016 From: ma.chris.m at gmail.com (Chris Muller) Date: Mon Feb 1 19:27:35 2016 Subject: [squeak-dev] The Trunk: Tools-mt.668.mcz In-Reply-To: References: <56af2941.8fea8c0a.27e93.ffffcea8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: +1. Marcel, we should really try to remove pop-ups from the system, not add new ones. How about rendering the out-of-date stuff in a different color? On Mon, Feb 1, 2016 at 1:02 PM, Levente Uzonyi wrote: > I'd hate if Explorers were not able to keep their state when the explored > obejcts changed. This would make it impossible to explore an object, change > its structure, then open another explorer on it to compare the old state > with the new. > I haven't checked this new "reselect to refresh" feature, but I think it > breaks what I described above. > > Levente > > On Mon, 1 Feb 2016, Chris Muller wrote: > >> Wouldn't it be better to just silently refresh it FOR the user in that >> case, rather than bother them with a pop up? >> >> On Mon, Feb 1, 2016 at 3:45 AM, wrote: >>> >>> Marcel Taeumel uploaded a new version of Tools to project The Trunk: >>> http://source.squeak.org/trunk/Tools-mt.668.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Tools-mt.668 >>> Author: mt >>> Time: 1 February 2016, 10:44:38.861285 am >>> UUID: 88b24b27-f952-4e86-9bd5-be64c8e309e2 >>> Ancestors: Tools-mt.667 >>> >>> Adds support for selective refreshing to object explorer. Just re-select >>> the current selection to refresh it. Item will get highlighted just like >>> automatic monitor refresh to indicate inconsistency of displayed >>> information. >>> >>> Make the still existing deficiency with volatile object state more >>> descriptive with a pop-up instead of a generic assert error. Now that we >>> support selective refreshing, the user is actually able to refresh and THEN >>> invoke the context menu again. >>> >>> =============== Diff against Tools-mt.667 =============== >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>currentSelection: (in category >>> 'accessing') ----- >>> currentSelection: anObject >>> >>> + self currentSelection == anObject ifTrue: [ >>> + self changed: #objectChanged with: anObject. >>> + ^ self]. >>> + >>> - self currentSelection == anObject ifTrue: [^ self]. >>> currentSelection := anObject. >>> >>> self changed: #currentSelection. >>> self changed: #style.! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>explorerKey:from:event: (in category >>> 'menus') ----- >>> explorerKey: aChar from: view event: event >>> >>> event anyModifierKeyPressed ifFalse: [^ false]. >>> >>> currentSelection ifNotNil: [ >>> + self updateInspectorForSelection ifFalse: [^ true]. >>> - self updateInspectorForSelection. >>> >>> aChar == $i ifTrue: [self inspector inspectSelection. ^ >>> true]. >>> aChar == $I ifTrue: [self inspector exploreSelection. ^ >>> true]. >>> >>> aChar == $b ifTrue: [self inspector browseMethodFull. >>> ^ true]. >>> aChar == $h ifTrue: [self inspector classHierarchy. ^ >>> true]. >>> aChar == $c ifTrue: [Clipboard clipboardText: self >>> currentSelection key. ^ true]. >>> aChar == $p ifTrue: [self inspector browseFullProtocol. ^ >>> true]. >>> aChar == $N ifTrue: [self inspector browseClassRefs. ^ >>> true]. >>> aChar == $t ifTrue: [self inspector tearOffTile. ^ true]. >>> aChar == $v ifTrue: [self inspector viewerForValue. ^ >>> true]]. >>> >>> ^ false! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>genericMenu: (in category 'menus') ----- >>> genericMenu: aMenu >>> "Borrow a menu from my inspector" >>> >>> currentSelection >>> ifNil: [ >>> aMenu >>> add: '*nothing selected*' >>> target: self >>> selector: #yourself] >>> ifNotNil: [ >>> + self updateInspectorForSelection ifFalse: [^ >>> aMenu]. >>> - self updateInspectorForSelection. >>> aMenu defaultTarget: self inspector. >>> self inspector fieldListMenu: aMenu. >>> >>> aMenu addLine; >>> add: 'monitor changes' >>> target: self >>> selector: #monitor: >>> argument: currentSelection]. >>> monitorList isEmptyOrNil >>> ifFalse: [aMenu addLine; >>> add: 'stop monitoring all' >>> target: self >>> selector: #stopMonitoring]. >>> ^ aMenu! >>> >>> Item was changed: >>> ----- Method: ObjectExplorer>>updateInspectorForSelection (in category >>> 'accessing - other') ----- >>> updateInspectorForSelection >>> "Reuse the inspector for some callbacks." >>> >>> self inspector inspect: (self parentObject ifNil: [self object]). >>> >>> self parentObject >>> ifNil: [self inspector toggleIndex: 1. "self"] >>> ifNotNil: [ >>> self inspector toggleIndex: (self inspector >>> fieldList indexOf: self currentSelection key)]. >>> + >>> + self inspector selection == self object >>> + ifTrue: [ >>> + ^ true] >>> + ifFalse: [ >>> + self inform: 'Object has changed. Please >>> refresh\before invoking the context menu.' withCRs. >>> + ^ false].! >>> - self assert: self inspector selection == self object.! >>> >>> >> >> > From asqueaker at gmail.com Mon Feb 1 19:41:36 2016 From: asqueaker at gmail.com (Chris Muller) Date: Mon Feb 1 19:42:20 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: >> > 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. From asqueaker at gmail.com Mon Feb 1 19:41:47 2016 From: asqueaker at gmail.com (Chris Muller) Date: Mon Feb 1 19:42:30 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> Message-ID: On Mon, Feb 1, 2016 at 12:58 PM, Levente Uzonyi 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.) From eliot.miranda at gmail.com Mon Feb 1 19:43:27 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Feb 1 19:43:30 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: <92292DE9-CF1D-4F81-80D3-535EA74958AB@rowledge.org> References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> <92292DE9-CF1D-4F81-80D3-535EA74958AB@rowledge.org> Message-ID: Hi Tim, On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge 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! > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/943d268c/attachment.htm From ron at usmedrec.com Mon Feb 1 20:31:56 2016 From: ron at usmedrec.com (Ron Teitelbaum) Date: Mon Feb 1 20:31:57 2016 Subject: [squeak-dev] Squeak Oversight Board 2016 Message-ID: <072501d15d2f$98816d00$c9844700$@usmedrec.com> Hi all, The final candidates for the Squeak Oversight Board 2016 are: In the order they were announced. Tim Rowledge Marcel Taeumel Craig Latta Bert Freudenberg Chris Muller David T. Lewis Edgar J. De Cleene Levente Uzonyi You will soon be receiving a ballot. Please watch for the email from: andru@cs.cornell.edu on behalf of; Ron Teitelbaum (CIVS poll supervisor) ron@usmedrec.com Titled: Poll: Squeak Oversight Board Election 2016 Voting is important Please take the time to find the email, check your junk box, and vote! All the best, Ron Teitelbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/614ccd80/attachment.htm From ron at usmedrec.com Mon Feb 1 20:54:43 2016 From: ron at usmedrec.com (Ron Teitelbaum) Date: Mon Feb 1 20:54:43 2016 Subject: [squeak-dev] Squeak Oversight Board 2016 In-Reply-To: <072501d15d2f$98816d00$c9844700$@usmedrec.com> References: <072501d15d2f$98816d00$c9844700$@usmedrec.com> Message-ID: <073f01d15d32$c75fd730$561f8590$@usmedrec.com> Hi all, It looks like the email will come from: Condorcet Internet Voting Service on behalf of; Ron Teitelbaum (CIVS poll supervisor) ron@usmedrec.com Which is nice. Please watch for the ballot email and Vote. All the best, Ron Teitelbaum From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ron Teitelbaum Sent: Monday, February 01, 2016 3:32 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] Squeak Oversight Board 2016 Hi all, The final candidates for the Squeak Oversight Board 2016 are: In the order they were announced. Tim Rowledge Marcel Taeumel Craig Latta Bert Freudenberg Chris Muller David T. Lewis Edgar J. De Cleene Levente Uzonyi You will soon be receiving a ballot. Please watch for the email from: andru@cs.cornell.edu on behalf of; Ron Teitelbaum (CIVS poll supervisor) ron@usmedrec.com Titled: Poll: Squeak Oversight Board Election 2016 Voting is important Please take the time to find the email, check your junk box, and vote! All the best, Ron Teitelbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/00646c3d/attachment.htm From nicolas.cellier.aka.nice at gmail.com Mon Feb 1 22:33:22 2016 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Mon Feb 1 22:33:24 2016 Subject: [squeak-dev] InputSensor, EventSensor miscategorised? In-Reply-To: References: <20160127131627.GA52108@shell.msen.com> <8812AA41-16B4-4848-8485-4B6A20ADEA51@rowledge.org> <908F9109-63B4-4567-A4B2-CC37FF9C47DF@gmail.com> <390E1DBC-BEB4-4592-B9E3-CF9ACC20AE15@freudenbergs.de> <093249CD-2E98-4046-B36E-86EC02C5302B@freudenbergs.de> <92292DE9-CF1D-4F81-80D3-535EA74958AB@rowledge.org> Message-ID: 2016-02-01 20:43 GMT+01:00 Eliot Miranda : > Hi Tim, > > On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/00e58815/attachment.htm From commits at source.squeak.org Mon Feb 1 22:55:03 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Feb 1 22:55:05 2016 Subject: [squeak-dev] Daily Commit Log Message-ID: <20160201225503.17630.qmail@box4.squeak.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2016-February/009284.html Name: Graphics-dtl.322 Ancestors: Graphics-eem.321 Move #testJoystick: to EventSensor because InputSensor will be removed. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2016-February/009285.html Name: Morphic-mt.1070 Ancestors: Morphic-tpr.1069 Fixes bounds issue regarding refreshed items in object explorer and other tree applications. Thanks to Karl Ramberg for the idea. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2016-February/009286.html Name: ToolBuilder-Morphic-mt.158 Ancestors: ToolBuilder-Morphic-mt.157 Adds support for selective refreshing in pluggable tree morphs that make use of the generic PluggableTreeItemNode. To use, send "self changed: #objectChanged with: anObject" in the tool's model. See ObjectExplorer >> #step for an example. Note that ObjectExplorer uses the customized ObjectExplorerWrapper instead of the PluggableTreeItemNode. However, this does not affect the basic idea behind #objectChanged. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2016-February/009287.html Name: Tools-mt.668 Ancestors: Tools-mt.667 Adds support for selective refreshing to object explorer. Just re-select the current selection to refresh it. Item will get highlighted just like automatic monitor refresh to indicate inconsistency of displayed information. Make the still existing deficiency with volatile object state more descriptive with a pop-up instead of a generic assert error. Now that we support selective refreshing, the user is actually able to refresh and THEN invoke the context menu again. ============================================= From tim at rowledge.org Tue Feb 2 02:48:26 2016 From: tim at rowledge.org (tim Rowledge) Date: Tue Feb 2 02:48:28 2016 Subject: [squeak-dev] DamageRecorder>recordInvalidRect: one truncate too far? In-Reply-To: <1454322062167-4875151.post@n4.nabble.com> References: <73704474-4EC0-45D9-855C-84C3BCE3B1FA@rowledge.org> <1454141800226-4874904.post@n4.nabble.com> <1454320839542-4875147.post@n4.nabble.com> <1454322062167-4875151.post@n4.nabble.com> Message-ID: > On 01-02-2016, at 2:21 AM, marcel.taeumel wrote: > > There are other calls of #truncated to rectangles, where IMO #expanded is > needed. Ah, I?d forgotten about #expanded. Should be perfect. > And there is #truncated in > #transformBy:clippingTo:#during:#smoothing in FormCanvas where one really > should decide for #ceiling OR #floor to avoid shrinking thinks by accident. I suspect there are many places needing attention. I am glad somebody else sees the issue, makes me more confident of the likely solution. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The substance "Hey Y'all, watch this!" is known by the state of California to be hazardous to your health. From goran at krampe.se Tue Feb 2 12:40:03 2016 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Tue Feb 2 12:41:12 2016 Subject: [squeak-dev] Not Squeak but... Ni goes multithreaded Message-ID: <56B0A3A3.6080806@krampe.se> Hey guys! I am unfortunately not hacking in Squeak/Pharo anymore but I am instead playing along with my Ni-language in my spare time. But the Squeak community is still very dear to me and I just couldn't help sharing some fun I had last night! ;) As we all know native threads (multicore) and Smalltalk is not a "common combo" but Ni is now sporting a first trivial native threading mechanism! Last night I threw together a first hack on utilizing the native threadpool module in the underlying Nim. So in the REPL this works: gokr@yoda:~/nim/ni/src$ ./nirepl We are the knights who say... Ni! Enter shrubbary... eh, code and an empty line will evaluate previous lines, so hit enter twice. >>> 5 timesRepeat: [spawn [echo "yo"]] >>> yo yo yo yo yo nil >>> The "nil" at the end is the return value from timesRepeat: so nothing "wrong". If the code looks odd (spawn and echo) it's because Ni can use prefix syntax for functions as well as Smalltalkish style. This is "shared nothing" threading, the spawned block gets run in a completely separate instance of the Ni interpreter inside its own native thread. The code block passed over is deep copied. Each native thread has its own GC etc. Of course Nim has MUCH more advanced mechanisms for intercommunication so... this is just a toe dipping. ...but the larger commented trixier example below runs fine too! Next up is probably to try to make Ni "stackless" (rewrite the interpreter so that it doesn't nest the calls so). This would enable even more fun stuff. regards, G?ran --------------------------------- # This is called a block in Ni. It is like an OrderedCollection. # At this point the block is just a series of nested words and literals. # Assignment is actually an infix function! code = [ # This is a local function to recursively calculate factorial. # ifelse is currently a 3-argument prefix function, but Ni could use # Smalltalk syntax for that too. factorial = func [ # Arguments are sucked in as we go, so no need to declare n first ifelse (:n > 0) [n * factorial (n - 1)] [1] ] # Echo is a prefix function. echo factorial 1 ] # Ni has keyword messages that can take the first argument from the left. # Ni also has closures and non local returns so we can implement Smalltalkish # control structures and things like select: or reject: easily. Or we can write # them as Nim primitive functions. 10 timesRepeat: [ # Ni is homoiconic so we can modify the block as if it is code. # We remove the last element of the code block (the number) and add # a random number from 1-20. code removeLast # In Ni the parenthesis is currently needed, evaluation is strict from left to right. code add: (20 random) # Spawn fires upp a native thread from a threadpool and # inside that thread a new fresh interpreter is created. # Spawn will deep copy the Ni node being passed and will # then run it as code in the new interpreter. # Currently the result value is not handled. spawn code ] echo "Spawned off threads" # Sleeping this thread to wait for the 10 above sleep 1000 echo "Done sleeping, bye" From lewis at mail.msen.com Tue Feb 2 13:48:06 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Feb 2 13:48:11 2016 Subject: [squeak-dev] Not Squeak but... Ni goes multithreaded In-Reply-To: <56B0A3A3.6080806@krampe.se> References: <56B0A3A3.6080806@krampe.se> Message-ID: <20160202134806.GA32099@shell.msen.com> Cool. Are the numbers in the factorial example values on the stack, or are they "objects" in the Smalltalk sense? I'm curious how Ni might be approaching a shared object space for the interpreters. Thanks for posting. Dave On Tue, Feb 02, 2016 at 01:40:03PM +0100, G??ran Krampe wrote: > Hey guys! > > I am unfortunately not hacking in Squeak/Pharo anymore but I am instead > playing along with my Ni-language in my spare time. But the Squeak > community is still very dear to me and I just couldn't help sharing some > fun I had last night! ;) > > As we all know native threads (multicore) and Smalltalk is not a "common > combo" but Ni is now sporting a first trivial native threading mechanism! > > Last night I threw together a first hack on utilizing the native > threadpool module in the underlying Nim. So in the REPL this works: > > gokr@yoda:~/nim/ni/src$ ./nirepl > We are the knights who say... Ni! Enter shrubbary... eh, code and > an empty line will evaluate previous lines, so hit enter twice. > >>>5 timesRepeat: [spawn [echo "yo"]] > >>> > yo > yo > yo > yo > yo > nil > >>> > > The "nil" at the end is the return value from timesRepeat: so nothing > "wrong". If the code looks odd (spawn and echo) it's because Ni can use > prefix syntax for functions as well as Smalltalkish style. > > This is "shared nothing" threading, the spawned block gets run in a > completely separate instance of the Ni interpreter inside its own native > thread. The code block passed over is deep copied. Each native thread > has its own GC etc. Of course Nim has MUCH more advanced mechanisms for > intercommunication so... this is just a toe dipping. > > ...but the larger commented trixier example below runs fine too! > > Next up is probably to try to make Ni "stackless" (rewrite the > interpreter so that it doesn't nest the calls so). This would enable > even more fun stuff. > > regards, G??ran > --------------------------------- > > # This is called a block in Ni. It is like an OrderedCollection. > # At this point the block is just a series of nested words and literals. > # Assignment is actually an infix function! > code = [ > # This is a local function to recursively calculate factorial. > # ifelse is currently a 3-argument prefix function, but Ni could use > # Smalltalk syntax for that too. > > factorial = func [ > # Arguments are sucked in as we go, so no need to declare n first > ifelse (:n > 0) > [n * factorial (n - 1)] > [1] > ] > # Echo is a prefix function. > echo factorial 1 > ] > > # Ni has keyword messages that can take the first argument from the left. > # Ni also has closures and non local returns so we can implement > Smalltalkish > # control structures and things like select: or reject: easily. Or we > can write > # them as Nim primitive functions. > 10 timesRepeat: [ > # Ni is homoiconic so we can modify the block as if it is code. > # We remove the last element of the code block (the number) and add > # a random number from 1-20. > code removeLast > > # In Ni the parenthesis is currently needed, evaluation is strict > from left to right. > code add: (20 random) > > # Spawn fires upp a native thread from a threadpool and > # inside that thread a new fresh interpreter is created. > # Spawn will deep copy the Ni node being passed and will > # then run it as code in the new interpreter. > # Currently the result value is not handled. > spawn code > ] > echo "Spawned off threads" > > # Sleeping this thread to wait for the 10 above > sleep 1000 > echo "Done sleeping, bye" From goran at krampe.se Tue Feb 2 15:44:46 2016 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Tue Feb 2 15:45:43 2016 Subject: [squeak-dev] Not Squeak but... Ni goes multithreaded In-Reply-To: <20160202134806.GA32099@shell.msen.com> References: <56B0A3A3.6080806@krampe.se> <20160202134806.GA32099@shell.msen.com> Message-ID: <56B0CEEE.4070501@krampe.se> Hey! On 02/02/2016 02:48 PM, David T. Lewis wrote: > Cool. > > Are the numbers in the factorial example values on the stack, or are > they "objects" in the Smalltalk sense? I'm curious how Ni might be > approaching a shared object space for the interpreters. In Ni everything is a "node" as in an AST Node. ints and floats are boxed Nim ints/floats. Strings are boxed Nim strings and blocks are boxed Nim seq (dynamic array). Dictionaries are boxed Nim OrderedTables. true, false, nil and undef are singleton objects. So they are Nim objects (which means the VM can actually do dynamic dispatch on them using Nim's mechanism for that) but in Ni they are "primitive types". BUT... the model I am working on for "OO" in Ni is centered around instance tagging (!) and dynamic dispatch using these tags of Ni funcs. Since everything (ints floats etc) are nodes, they can be tagged and thus "methods" can be polymorphically dispatched on everything. And since Ni (just like Nim) offers "infix functions with more than one argument, optionally using keyword syntax" you should get a very OO-ish model. So Ni uses Nim objects for the AST nodes and thus also uses Nim's GC (it has 5 different ones!). The reified stack is also built with Nim objects as a spaghetti stack so it too is GCd by Nim. Nim has several interesting things going in the multithreading space. It has an asynch model and it also has channels one can use between native threads - the latter is used in a very nice article that Dennis Felsing just wrote: http://hookrace.net/blog/writing-an-async-logger-in-nim/ In fact, Dennis blog has a whole slew of brilliant Nim articles. Exactly how Ni will piggy back on all these options is unclear at this point - and oh, it uses FlowVars too. But do note that the Nim GC runs *per thread* so to do memory sharing between native threads in Nim you would need to use special shared constructs. However... stuff is brewing in that area too in Nim. But generally I am inclined towards a shared nothing model between native threads (as I have now) but perhaps implementing coroutines or something within a single thread. That is also why I need to go stackless, so that I can manipulate the Ni stack without being hindered by the Nim (C) stack. regards, G?ran PS. I am still waiting for someone to join me in this coding adventure. :) This is fresh ground here, but we have a tremendous solid base in the Nim eco system. From Marcel.Taeumel at hpi.de Tue Feb 2 16:01:23 2016 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Tue Feb 2 16:25:09 2016 Subject: [squeak-dev] Re: DamageRecorder>recordInvalidRect: one truncate too far? In-Reply-To: References: <73704474-4EC0-45D9-855C-84C3BCE3B1FA@rowledge.org> <1454141800226-4874904.post@n4.nabble.com> <1454320839542-4875147.post@n4.nabble.com> <1454322062167-4875151.post@n4.nabble.com> Message-ID: <1454428883799-4875422.post@n4.nabble.com> Only 184 calling methods to check. :-) Best, Marcel -- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-tp4874894p4875422.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From ron at usmedrec.com Tue Feb 2 16:37:27 2016 From: ron at usmedrec.com (Ron Teitelbaum) Date: Tue Feb 2 16:37:25 2016 Subject: [squeak-dev] Time to Vote Message-ID: <092c01d15dd8$00e12810$02a37830$@usmedrec.com> Hi All, Thank you for your participation in the Squeak Oversight Board 2016 election. It is time to vote! Please check your email for a message from: Condorcet Internet Voting Service on behalf of; Ron Teitelbaum (CIVS poll supervisor) ron@usmedrec.com Voting is important! It is your way to show your community you support the efforts of the Board! Please find the email and vote. All the best, Ron Teitelbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160202/086e4331/attachment.htm From karlramberg at gmail.com Tue Feb 2 16:39:34 2016 From: karlramberg at gmail.com (karl ramberg) Date: Tue Feb 2 16:39:37 2016 Subject: [squeak-dev] Time to Vote In-Reply-To: <092c01d15dd8$00e12810$02a37830$@usmedrec.com> References: <092c01d15dd8$00e12810$02a37830$@usmedrec.com> Message-ID: And thank you Ron for all your work with the voteing Best, Karl On Tue, Feb 2, 2016 at 5:37 PM, Ron Teitelbaum wrote: > Hi All, > > > > Thank you for your participation in the Squeak Oversight Board 2016 > election. It is time to vote! > > > > Please check your email for a message from: Condorcet Internet Voting > Service on behalf of; Ron Teitelbaum (CIVS poll > supervisor) ron@usmedrec.com > > > > Voting is important! It is your way to show your community you support > the efforts of the Board! Please find the email and vote. > > > > All the best, > > > > Ron Teitelbaum > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160202/3c737f05/attachment.htm From commits at source.squeak.org Tue Feb 2 17:25:56 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Feb 2 17:25:59 2016 Subject: [squeak-dev] The Trunk: Kernel-dtl.981.mcz Message-ID: David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.981.mcz ==================== Summary ==================== Name: Kernel-dtl.981 Author: dtl Time: 30 January 2016, 11:08:34.12478 am UUID: f28a2de4-862d-4499-90cd-5eb04e0649d3 Ancestors: Kernel-eem.980 InputSensor removal step 1. Move instance methods to EventSensor, eliminate super calls, resolve primitive fallbacks, recategorize. Preserve original method stamps where possible. Class variables and system startup/shutdown to be addressed next. =============== Diff against Kernel-eem.980 =============== Item was added: + ----- Method: EventSensor>>anyButtonPressed (in category 'mouse') ----- + anyButtonPressed + "Answer whether at least one mouse button is currently being pressed." + + ^ self primMouseButtons anyMask: 7 + ! Item was added: + ----- Method: EventSensor>>anyModifierKeyPressed (in category 'modifier keys') ----- + anyModifierKeyPressed + "ignore, however, the shift keys 'cause that's not REALLY a command key" + + ^ self primMouseButtons anyMask: 16r70 "cmd | opt | ctrl"! Item was added: + ----- Method: EventSensor>>blueButtonPressed (in category 'mouse') ----- + blueButtonPressed + "Answer whether only the blue mouse button is being pressed. + This is the third mouse button or cmd+click on the Mac." + + ^ (self primMouseButtons bitAnd: 7) = 1 + ! Item was added: + ----- Method: EventSensor>>characterForKeycode: (in category 'keyboard') ----- + characterForKeycode: keycode + "Map the given keycode to a Smalltalk character object. Encoding: + A keycode is 12 bits: <4 modifer bits><8 bit ISO character> + Modifier bits are: