Squeak-dev June 2016

squeak-dev@lists.squeakfoundation.org

39 participants
202 discussions

The Trunk: Morphic-mt.1186.mcz
by commits＠source.squeak.org 28 Jun '16

28 Jun '16

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1186.mcz ==================== Summary ==================== Name: Morphic-mt.1186 Author: mt Time: 28 June 2016, 11:39:43.639008 am UUID: 471c6534-59eb-c84c-8742-e4fa50706ebb Ancestors: Morphic-mt.1185 Account for broken morphs in the Object Explorer by catching in-computable icons. (Icons for morphs are usually their own graphical representation scaled down.) Comparable to error handling in ObjectExplorerWrapper >> #asString. Fixes a bug with columns cache invalidation in tree morphs. =============== Diff against Morphic-mt.1185 =============== Item was changed: ----- Method: ObjectExplorerWrapper>>icon (in category 'accessing') ----- icon "Answer a form to be used as icon" ^ Preferences visualExplorer + ifTrue: [([self object iconOrThumbnailOfSize: 12] on: Error do: [nil]) - ifTrue: [(self object iconOrThumbnailOfSize: 12) ifNil: [self class showContentsInColumns ifTrue: [ToolIcons iconNamed: #blank] ifFalse: [nil]]] ifFalse: [nil]! Item was changed: ----- Method: SimpleHierarchicalListMorph>>columns: (in category 'accessing') ----- columns: anArray "You can specify columns or specs for columns. This depends on the actual morph that is used as item. ObjectExplorers produce items that support exact numbers, blocks, and nil for max width." + columns := anArray. + self clearColumnsCache.! - columns := anArray!

1 0

Renaming Squeak's system version from 'Squeak*alpha' to 'SqueakTrunk'
by marcel.taeumel 28 Jun '16

28 Jun '16

Hi there, we have a system version: "SystemVersion current". For trunk images, it used to say 'Squeak4.1alpha' or something like it. Right now, it doesn't even add the 'alpha' suffix. Can we change that to 'SqueakTrunk'? What would break? Right now, SystemVersion works with a string rather than major/minor numbers. I assume that there is some code that parses that string. Metacello does that, for example. Any thoughts? Best, Marcel -- View this message in context: http://forum.world.st/Renaming-Squeak-s-system-version-from-Squeak-alpha-to… Sent from the Squeak - Dev mailing list archive at Nabble.com.

7 14

rounded corner morphs seem to be broken
by tim Rowledge 28 Jun '16

28 Jun '16

I’m trying to work out why the comment morphs in nuScratch are not getting the rounded corners that they should. This is something that changed a while ago without me really noticing. I think we’re talking late last year as best I can tell from trying out older releases to attempt to triangulate on the problem. In the olden days we used a CornerRounder class to handle things, which has gone away. So far as I can work out now we don’t really do the job thoroughly. Individual morphs can draw with rounded corners ok although the rounding is not very nicely drawn below a radius of 8 pixels, which is admittedly not a huge surprise. If you make a composite morph - like the comment morphs - the submorphs are not affected at all any more. This makes the comment morph fairy very sad. The comment fairy wants her morphs to look like this - and when the little magic triangle is tickled it should look like this - Instead we get this - and - The comment is currently implemented as an AlignmentMorph containing a topbar (another alignment containing the triangle and a usually empty string morph) and the lower area holding a ‘MultilineStringMorph’ and the resize icon morph. The lower-right corner looks ok because the resize icon is small enough not to overlap the rounding. I managed improve things a little by making the background to the lower text transparent; before that the lower left corner was squared off too. Looking around for rounding related code I note that the Morph>roundedCorners method which appears to be a way to designate which corners are actually rounded is no longer used. Which is a pity since it would possibly solve my problem by allowing me to round the top two corners of the upper alignment morph. Hmm, actually since the colours of the upper and lower backgrounds are very close it kinda-sorta looks acceptable if I just round the entire upper morph - but it ain’t proper I tell you! Can anyone recall messing about with rounding morphs over the last year or thereabouts? I think it happened between 4.5-13860 and 4.6-15102 tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BIB: Branch If Branch if branch...

2 1

Re: Become Identity Forward
by Eliot Miranda 27 Jun '16

27 Jun '16

Hi, I don't see the bug. Look at this example: | a b ha hb | a := Object new. b := Object new. ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha }. #(false true true) So here a has indeed become b; all references to a are now references to b. But b's identityHash is now that of what a's was before the become. That's as specified. Let's extend the example: | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. *is add: b.* ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha. *is includes: a* }. #(false true true false) This is correct; a (and b) is (are) now in the set at the old hash of b, which is no longer its hash. So... | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. is add: b. ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. *is rehash.* { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true true true) Good. So instead what you might have meant to say was | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. *is add: a.* ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true true true) That looks good. On Mon, Jun 27, 2016 at 2:50 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > I'm trying to become forward some objects, these objects are stored > in IdentitySets so I need to copy the identityHash of the older objects to > the new ones. So that the IdentitySets are still well constructed. > > I have read the comments in Array >> elementsForwardIdentityTo: copyHash: > , and Array >> elementsForwardIdentityTo:, so I realise that the operation > I want to use is the first with copyHash in true or the later (that should > be doing the same, from the comments). > > But after trying it, it is not working as expected. > > If I try with: > > x := Object new. > y := Object new. > z := Object new. > > set := IdentitySet new. > set add: x. > set add: y. > > hash := x identityHash. > bhash := x basicIdentityHash. > > self assert:(set isHealthy). > > z becomeForward: x copyHash: true. > > set isHealthy "false" > > z basicIdentityHash = bhash. "false" > z identityHash = hash "false" > > It is not working, but if I changed the copyHash parameter to false, it > works. > > Something is not right (the comment or the implementation), because the > comment says: > > "If copyHash is true, the identityHashes remain with the pointers rather > than with the > objects so that the objects in the receiver should still be properly > indexed in any > existing hashed structures after the mutation. If copyHash is false, then > the hashes > of the objects in otherArray remain unchanged." > > Do I have understanded everything wrong or there is something that is not > working (or at least the comment is not clear) > > Is somebody using these operations? How do you expect to work? > > Maybe If you can help me to understand the situation I can fix the > comments. > > Thanks in advance. > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- _,,,^..^,,,_ best, Eliot

1 0

Re: [squeak-dev] Re: Renaming Squeak's system version from 'Squeak*alpha' to 'SqueakTrunk'
by Jakob Reschke 27 Jun '16

27 Jun '16

I didn't want to touch the build numbers issue directly because I did not read all of that recent, related discussion about the VM versions. What is the purpose of each number? I thought the release version number ("5.1", "5.2 Trunk", ...) exists for publicity reasons and to find out if you should consider to "upgrade" your Squeak. The build number allows you to refer to a specific version/configuration, mainly for issue hunting, right? Can't we treat build numbers and release numbers independently from each other then? If yes, we could simply apply the Maven style version numbering (with "mutable" and "immutable" versions) to the release version numbers. It is very similar to what Tobias suggested, though, so you might as well consider my Maven paragraph as supporting Tobias' suggestion. ;-) "Squeak x.y" then just happens to also have a build number z, by chance. That's the current situation anyway, is it? If the release branch is updated, I would prefer if the patch number of that release were increased at the same time, instead of referring to a different build number for that release from now on. I don't know how an update map is made up, but would it be possible to version its configuration/state just like regular configurations, packages, or baselines? Then you could just use its SCM version number (hash/uuid, consecutive number if available, or timestamp) instead of summing up contained version numbers. 2016-06-27 12:44 GMT+02:00 Taeumel, Marcel <Marcel.Taeumel(a)hpi.de>: > Jakob Reschke wrote >> 2016-06-27 10:12 GMT+02:00 Taeumel, Marcel < > >> Marcel.Taeumel@ > >> >: >>> >>> Would it make sense to keep track of the release build number and show >>> the >>> current increment in a separate way? Releases are basically branches from >>> Trunk. E.g.: >>> >>> source.squeak.org/trunk >>> source.squeak.org/squeak50 >>> >>> At release time, the code base is identical. Then, things might get >>> cherry-picked from trunk into the release branch (here "squeak50"). Then, >>> the summative build number would be confusing because "14023" in squeak50 >>> is >>> not the same as it is in trunk. >>> >>> What about doing it like GitHub branches and show "number of commits your >>> are behind the main branch"? It could displayed like this: >>> >>> "Squeak 5.0 (Build 14000 +23/-324)" >>> >>> This means that the current image is a release image, created from trunk >>> build 14000. There were 23 fixes in this branch since then and current >>> Trunk >>> is already 324 builds ahead. >>> >>> What do you think? >> >> That looks very cryptic to me. IMHO, if you need to see your build's >> detailed relation to the initial release or the current trunk, you >> should ask the SCM system (Monticello) itself. If I were a newcomer, >> these +/- numbers would confuse me when I want to download a specific >> image version from the website. I would not expect someone to read a >> manual to understand the version numbering. >> >> For reference, in the Maven/Java world, artifacts get a version >> suffixed with -SNAPSHOT until you do a "release". If you have an >> artifact with a version of 1.2.3-SNAPSHOT you know that there will be >> dozens of other builds with the same version number because the >> snapshot suffix indicates that this number "1.2.3" has not been fixed >> yet. That is, it is semantically equivalent to your current notion of >> (or suffix) "trunk". If you do a release, you strip the -SNAPSHOT from >> the version number (or rather jump to the intended fixed version >> number), commit, tag, publish that version, then bump the version >> number and append -SNAPSHOT again. The fixed version labelled "1.2.3" >> is not expected to ever change again, so if you download one of these >> artifacts, you can be quite sure it is identical to other "1.2.3"s of >> that artifact you download later. I consider this a sufficient scheme >> in many cases. However, it does not map to an alpha-beta-rc process, >> unless you put that into the less significant parts of the version >> number (which makes comparing versions harder for machines). > > Hi Jakob, > > you're right. This information would have to appear in the file name of the > downloads on the website. Hmm... right now, our build number is the sum of > all MCZ versions in the trunk update stream. The goal here is to find a > simple solution for that branching thing. Maybe the combination of release > number and build number is enough to discriminate. > > I do not quite get your example about Maven/Java. I think that you relate to > the ideas of suffixing the Trunk versions with alpha, beta, rc1, ..., rcn, > alpha, ... However, my previous comment addresses the naming of release > versions only and the role of the respective build number. :-) > > I think that an alternative to summing up the MCZ versions could be to only > show the most recent commit date/time of the packages in the update map. > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/Renaming-Squeak-s-system-version-from-Squeak-alpha-to… > Sent from the Squeak - Dev mailing list archive at Nabble.com. >

1 0

Re: [squeak-dev] Re: Renaming Squeak's system version from 'Squeak*alpha' to 'SqueakTrunk'
by Jakob Reschke 27 Jun '16

27 Jun '16

2016-06-27 10:12 GMT+02:00 Taeumel, Marcel <Marcel.Taeumel(a)hpi.de>: > > Would it make sense to keep track of the release build number and show the > current increment in a separate way? Releases are basically branches from > Trunk. E.g.: > > source.squeak.org/trunk > source.squeak.org/squeak50 > > At release time, the code base is identical. Then, things might get > cherry-picked from trunk into the release branch (here "squeak50"). Then, > the summative build number would be confusing because "14023" in squeak50 is > not the same as it is in trunk. > > What about doing it like GitHub branches and show "number of commits your > are behind the main branch"? It could displayed like this: > > "Squeak 5.0 (Build 14000 +23/-324)" > > This means that the current image is a release image, created from trunk > build 14000. There were 23 fixes in this branch since then and current Trunk > is already 324 builds ahead. > > What do you think? That looks very cryptic to me. IMHO, if you need to see your build's detailed relation to the initial release or the current trunk, you should ask the SCM system (Monticello) itself. If I were a newcomer, these +/- numbers would confuse me when I want to download a specific image version from the website. I would not expect someone to read a manual to understand the version numbering. For reference, in the Maven/Java world, artifacts get a version suffixed with -SNAPSHOT until you do a "release". If you have an artifact with a version of 1.2.3-SNAPSHOT you know that there will be dozens of other builds with the same version number because the snapshot suffix indicates that this number "1.2.3" has not been fixed yet. That is, it is semantically equivalent to your current notion of (or suffix) "trunk". If you do a release, you strip the -SNAPSHOT from the version number (or rather jump to the intended fixed version number), commit, tag, publish that version, then bump the version number and append -SNAPSHOT again. The fixed version labelled "1.2.3" is not expected to ever change again, so if you download one of these artifacts, you can be quite sure it is identical to other "1.2.3"s of that artifact you download later. I consider this a sufficient scheme in many cases. However, it does not map to an alpha-beta-rc process, unless you put that into the less significant parts of the version number (which makes comparing versions harder for machines).

2 1

Daily Commit Log
by commits＠source.squeak.org 25 Jun '16

25 Jun '16

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2016-June/068238.html Name: Morphic-mt.1185 Ancestors: Morphic-mt.1184 Fixes several bugs with selection and hovering in menus and docking-bar menus and their sub-menus. =============================================

1 0

ESUG 2016, 13th Innovation Technology Awards
by Jordi Delgado 25 Jun '16

25 Jun '16

*ESUG 2016, 13th Innovation Technology Awards* Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 22, 2016, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.) The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event. Applicants should provide the following information on the conference registration server (registration.esug.org). Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. Info to provide: - Name of the software - Licence information (free, shareware, or commercial) - Name of the Smalltalk dialect used - Name, Affiliation and Country of developers Besides, it would be great if the submission could include: - URL for a video (3-5 min) showing a screencast / demo of the software - URL for downloading the software or at least a runnable demo - Deadline: *August 21, 2016* Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner. Bests, Jordi

1 0

The Trunk: Morphic-mt.1185.mcz
by commits＠source.squeak.org 25 Jun '16

25 Jun '16

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1185.mcz ==================== Summary ==================== Name: Morphic-mt.1185 Author: mt Time: 25 June 2016, 8:51:08.59647 am UUID: 05385b8c-0ff4-6443-9c57-52be6dc91bbb Ancestors: Morphic-mt.1184 Fixes several bugs with selection and hovering in menus and docking-bar menus and their sub-menus. =============== Diff against Morphic-mt.1184 =============== Item was changed: ----- Method: DockingBarItemMorph>>mouseEnter: (in category 'events') ----- mouseEnter: evt + "Do not hover docking bar items directory. Mouse-down required. But if you already see a submenu, support hovering." - "The mouse entered the receiver" + owner selectedItem ifNotNil: [owner selectItem: self event: evt]! - super mouseEnter: evt. - (owner selectedItem notNil and: [ owner selectedItem ~~ self ]) ifTrue: [ - owner selectItem: self event: evt. ]! Item was removed: - ----- Method: DockingBarItemMorph>>mouseLeaveDragging: (in category 'events') ----- - mouseLeaveDragging: evt ! Item was changed: StringMorph subclass: #MenuItemMorph + instanceVariableNames: 'isEnabled subMenu isSelected target selector arguments icon' - instanceVariableNames: 'isEnabled subMenu isSelected target selector arguments icon lastMousePosition' classVariableNames: 'SubMenuMarker' poolDictionaries: '' category: 'Morphic-Menus'! !MenuItemMorph commentStamp: '<historical>' prior: 0! I represent an item in a menu. Instance variables: isEnabled <Boolean> True if the menu item can be executed. subMenu <MenuMorph | nil> The submenu to activate automatically when the user mouses over the item. isSelected <Boolean> True if the item is currently selected. target <Object> The target of the associated action. selector <Symbol> The associated action. arguments <Array> The arguments for the associated action. icon <Form | nil> An optional icon form to be displayed to my left. If I have a dynamic marker, created by strings like <yes> or <no> in my contents, it will be installed as a submorph.! Item was changed: ----- Method: MenuItemMorph>>activateSubmenu: (in category 'events') ----- activateSubmenu: evt "Activate our submenu; e.g., pass control to it" subMenu ifNil:[^false]. "not applicable" (subMenu fullContainsPoint: evt position) ifFalse:[^false]. subMenu activate: evt. - self removeAlarm: #deselectTimeOut:. ^true! Item was changed: ----- Method: MenuItemMorph>>deselect: (in category 'selecting') ----- deselect: evt self isSelected: false. - lastMousePosition := nil. subMenu ifNotNil: [ owner ifNotNil: [ owner activeSubmenu: nil ] ].! Item was removed: - ----- Method: MenuItemMorph>>deselectTimeOut: (in category 'events') ----- - deselectTimeOut: evt - "Deselect timout. Now really deselect" - owner selectedItem == self - ifTrue:[ - evt hand newMouseFocus: nil. - owner selectItem: nil event: evt]. - ! Item was changed: ----- Method: MenuItemMorph>>mouseEnter: (in category 'events') ----- mouseEnter: evt "The mouse entered the receiver" + owner ifNotNil: [ owner selectItem: self event: evt ]! - owner ifNotNil: [ owner stayUp ifFalse: [ self mouseEnterDragging: evt ] ]! Item was changed: ----- Method: MenuItemMorph>>mouseEnterDragging: (in category 'events') ----- mouseEnterDragging: evt + + self mouseEnter: evt.! - "The mouse entered the receiver. Do nothing if we're not in a 'valid menu transition', meaning that the current hand focus must be aimed at the owning menu." - evt hand mouseFocus == owner ifTrue:[owner selectItem: self event: evt]! Item was removed: - ----- Method: MenuItemMorph>>mouseLeave: (in category 'events') ----- - mouseLeave: evt - "The mouse has left the interior of the receiver..." - - owner ifNotNil: [owner stayUp ifFalse: [self mouseLeaveDragging: evt]]! Item was removed: - ----- Method: MenuItemMorph>>mouseLeaveDragging: (in category 'events') ----- - mouseLeaveDragging: evt - "The mouse left the receiver. Do nothing if we're not in a 'valid menu transition', meaning that the current hand focus must be aimed at the owning menu." - - owner ifNil: [^self]. - evt hand mouseFocus == owner ifFalse: [ ^self ]. - lastMousePosition := evt position. - owner selectItem: nil event: evt! Item was removed: - ----- Method: MenuItemMorph>>releasesSelection: (in category 'events') ----- - releasesSelection: evt - " Returns a boolean indicating that this menu item is ready to go deselected. - It answers false if the mouse is moving towards its submenu. - We check this by testing that the current mouse position lays in the triangle of - the last mouse position and the two corners of the submenu facing our menu item. " - - | triangle submenuIsOnTheRightSide | - self hasSubMenu ifFalse: [ - lastMousePosition := nil. - ^true ]. - lastMousePosition ifNil: [ - lastMousePosition := evt position. - ^false ]. - submenuIsOnTheRightSide := self left < subMenu left. - triangle := { - lastMousePosition. - submenuIsOnTheRightSide - ifTrue: [ subMenu topLeft ] - ifFalse: [ subMenu topRight ]. - submenuIsOnTheRightSide - ifTrue: [ subMenu bottomLeft ] - ifFalse: [ subMenu bottomRight ] }. - lastMousePosition := evt position. - (self triangle: triangle containsPoint: evt position) - ifTrue: [ ^false ] - ifFalse: [ - lastMousePosition := nil. - ^true ]! Item was changed: ----- Method: MenuItemMorph>>veryDeepInner: (in category 'copying') ----- veryDeepInner: deepCopier "Copy all of my instance variables. Some need to be not copied at all, but shared. Warning!!!! Every instance variable defined in this class must be handled. We must also implement veryDeepFixupWith:. See DeepCopier class comment." super veryDeepInner: deepCopier. isEnabled := isEnabled veryDeepCopyWith: deepCopier. subMenu := subMenu veryDeepCopyWith: deepCopier. isSelected := isSelected veryDeepCopyWith: deepCopier. icon := icon veryDeepCopyWith: deepCopier. "target := target. Weakly copied" "selector := selector. a Symbol" + arguments := arguments.! - arguments := arguments. - lastMousePosition := nil! Item was added: + ----- Method: MenuMorph>>handlesMouseOver: (in category 'events') ----- + handlesMouseOver: evt + ^ true! Item was added: + ----- Method: MenuMorph>>mouseLeave: (in category 'events') ----- + mouseLeave: evt + self selectItem: nil event: evt.! Item was removed: - ----- Method: MenuMorph>>releasesSelection: (in category 'events') ----- - releasesSelection: evt - " The MenuMorph releases its selection if the selected item releases it. - Used in #selectItem:event: " - - self selectedItem ifNil: [ ^true ]. - evt ifNil: [ ^true ]. - evt isKeyboard ifTrue: [ ^true ]. - (self selectedItem containsPoint: evt position) ifTrue: [ ^true ]. - ^self selectedItem releasesSelection: evt! Item was changed: ----- Method: MenuMorph>>selectItem:event: (in category 'control') ----- selectItem: aMenuItem event: anEvent + "Change the selected item." + - - " Change the selected item, but first ask the currently selected item - if it want to release it. " - (self releasesSelection: anEvent) ifFalse: [ ^self ]. selectedItem ifNotNil:[selectedItem deselect: anEvent]. selectedItem := aMenuItem. selectedItem ifNotNil:[selectedItem select: anEvent].!

1 0

Interesting Windows menu bug...
by Eliot Miranda 25 Jun '16

25 Jun '16

In an updated trunk open two Monticello browsers. Now try and select the second one through the Windows menu... :-) _,,,^..^,,,_ best, Eliot

2 4

← Newer
1
2
3
4
5
6
7
...
21
Older →

Jump to page: