June 2017 - Pharo-dev - lists.pharo.org

Epicea and #name in #behaviorAffectedName
by Torsten Bergmann July 6, 2017

July 6, 2017

Hi, in latest Pharo 6 image 60494 I run into some trouble today where the deprecation warning dialog popped up and repeated itself unstoppable due to Epicea. It is hard to reproduce but what I found out was that I had a class modification (represented by EpClassModification) which run into a state where "newClass" was nil and therefore in EpClassModification>>#behaviorAffectedName the message #name was sent to nil. So #name was found in Object and as we all know we deprecated it now which lead to the deprecation dialog, leading to the deprecation dialog, leading to the deprecation dialog, ... Nearly all implementors of Epiceas #behaviorAffectedName send #name which is ok if there is a valid object it is sent to. I do not know if we should protect them somehow in case something goes wrong (like having nil in newClass) or if we should keep this untouched. At least I wanted to inform because I do not know if this later gets others into trouble too and losing their changes because Epicea does not record. Thanks T.

2 1

Reflecting on data (literal) object syntax
by Stephane Ducasse July 5, 2017

July 5, 2017

Hi recently I started to read a book on machine learning and they manipulate dictionary of dictionary. (So I started my own implementation and I will switch to DataFrame). Now it occurred to me that when we program complex objects we do not need a compact literal syntax for our objects. But when we manipulate data objects it is super handy. I ended up doing a lot of self new addRow: 'Claudia Puig' withTaggedValues: {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me and Dupree' -> 2.5)}. And I was not in the mood to write a class for the taggedValues and writing a class would not have really help me. Now we also have STON but STON is not yet part of the language grammar. So we have to have an explicit conversion call. STON fromString: 'Point[10,20]' We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>> 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.

8 21

Fwd: [Vm-dev] multiple crashes on macOS Sierra
by Eliot Miranda July 3, 2017

July 3, 2017

---------- Forwarded message ---------- From: Tobias Pape <Das.Linux(a)gmx.de> Date: Mon, May 29, 2017 at 12:09 AM Subject: Re: [Vm-dev] multiple crashes on macOS Sierra To: John McIntosh <johnmci(a)smalltalkconsulting.com> Cc: Squeak Virtual Machine Development Discussion < vm-dev(a)lists.squeakfoundation.org> Hi John, all > On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > location:[theEvent locationInWindow] > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > timestamp:[theEvent timestamp] > windowNumber:[theEvent windowNumber] > context:nil > characters:@"" > charactersIgnoringModifiers:@"" > isARepeat:NO > keyCode:[theEvent keyCode]]); > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent That's correct. > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/ library/content/documentation/Cocoa/Conceptual/MemoryMgmt/ Articles/mmRules.html > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() I read this https://developer.apple.com/reference/appkit/nsevent/ 1533943-keyeventwithtype?language=objc and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. I now understand that I should only autorelease alloc/inited stuff. So you may be right here. Fixed in 0f07ffbed Best regards -Tobias > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. [snip]

5 5

[FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells
by Elhamer July 1, 2017

July 1, 2017

Dear Pharo community, I've been working on improving the FT package recently and i would like to get your opinions about introducing a new cell data source layer. The idea is to move some of the data source responsibilities to the <cell data source, cell morph> in order to have a 'less dumber cell morphs' and a better design that reduces the complexity of extending the functionalities of a fast table. The changes are kind of expensive and might break Glamour and some other FT-based packages out there (unless the new implementation is integrated in the FT package as an alternative way -the old implementation will be deprecated and removed progressively-). There three main parts in the fast table package: - The data source - The table Morph - The cell Morph In the current design, all data managements are centralized around the data source. The Data source has the following responsibilities (schema below): - Creates the cell Morphs and populate them (cellColumn: column row: rowIndex). - Creates the header cells Morphs. - Manipulates the data that will be used to populate the table. - Updates the cell data (when the strong selection announcement is handled for example). <http://forum.world.st/file/n4952783/old_impl.png> * Limitation of this design:* - A high level of complexity in the data source. - The cell morph is a dumb object and itâs not being used to its full potential. - Extending the cell functionalities (usually done from the data source) can be challenging. A better design would be for the cell morph to interact directly with a new layer of data source âthe cell data sourceâ, and the cell's data source will propagate to the tableâs data source (the table refresh will triggered from the table's data source). Here are the responsibilities for each part (schema below): *The cell Morph responsibilities:* - Handle mouse/keyboard events and fire announcements. *The cell data source responsibilities:* - Handles cellâs announcements and manage cellâs data. - Propagates the changes to the data source. - Creates the cell morphs. *The tableâs data source responsibilities:* - Send refresh messages to the table morph when data changed. - Create the cell data sources object for each data element. *The table morph responsibilities:* - Render the morphs/widgets â¦ - Handle column/row selection. - â¦ <http://forum.world.st/file/n4952783/new_impl.png> *Requirement changes:* *The cell data source:* - A light version of the data source package to manage cell content. - â¦ *Announcements:* - Create new cells announcements that propagate the required properties to the cell's data source to handle data changes. - Propagate those announcements when the required event is fired on the cell morph. - â¦ *The data source* - Creates cells' data sources instead of cell Morphs. - â¦ *The cell Morph* - Fires the announcements, plus some tiny changes to bound the morph to its data source. - â¦ *The table Morph* - The FTTableMorph doesnât need much modification, just few changes here and there, The FTTableContainerMorph might be improved as well to take advantage from the fact that the cell morph knows its data (probably a better exposed-rows updates). - â¦ *Notes:* - These updates will definitely break Glamour, so some changes to the Glamour FT package is also required. - The best way to introduce these changes is by adding this new cell data source layer side by side with the current implementation, and mark the old implementation as deprecated (will be removed progressively in the next versions). Thank you :) Best regards, Elhamer. -- View this message in context: http://forum.world.st/FT-improvements-GSoC-guidance-needed-move-some-of-the… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

2 2

Reviewing of the pull requests
by Pavel Krivanek June 30, 2017

June 30, 2017

Hi, the reviewing of the pull requests is currently not as easy as we would like to have. For simple changes it should be enough to go to the pull requests list (https://github.com/pharo-project/pharo/pulls) and review the changes from the GitHub web interface. In case that the PR passes tests and bootstrapping, it should be fine. However if you want to play with an image that contains the PR code, your options are more complicated. The basic and the most clean one is to bootstrap from the repository with the PR applied on it. But it takes A LOT of time (over 20 mins). You can use this script that you will run inside the clone. set -e export PR=122 export BRANCH=development export PHARO_VERSION=60 export BOOTSTRAP_ARCH=32 git fetch origin $BRANCH git fetch origin refs/pull/$PR/head git checkout -b pullrequest FETCH_HEAD git merge --no-edit origin/$BRANCH #git diff origin/$BRANCH..pullrequest > pullrequest.diff wget -O - get.pharo.org/${PHARO_VERSION}+vm | bash ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ prepare_image.st --save --quit ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit bash ./bootstrap/scripts/build.sh The other option is to take existing Pharo 7 image, have pharo-project/pharo clone next to it in a folder named 'pharo-core' and then create a new branch with the merged pull request. Currently it cannot be done from Iceberg directly so you need to use Git. You can use this script: set -e PR=119 COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d cd pharo-core git fetch origin refs/pull/$PR/head git checkout -b pr$PR-local FETCH_HEAD git checkout $COMMIT git checkout -b pr$PR-merged git merge --no-edit pr$PR-local #git diff $COMMIT...pr$PR-merged > pr$PR.diff Set the pull request name to the variable PR and the image commmit hash to the variable named COMMIT. It can be obtained by "SystemVersion current commitHash". As the result you are in a merged branch created for this pull requests (e.g. pr122-merged) and you need to reload all packages. It can be done from Iceberg where you will need to confirm several dialogs, or by this script: repo := MCFileTreeRepository new directory: './pharo-core/src' asFileReference; yourself. versions := OrderedCollection new. repo allFileNames do: [ :packageName | | wc | wc := MCWorkingCopy allManagers detect: [ :each | each packageName = (packageName withoutSuffix: '.package') ] ifNone: [nil]. wc ifNotNil: [ [(repo loadVersionFromFileNamed: packageName) load] on: MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. The other option is to let display the classical Monticello merging window. For that you can use this script: repo := MCFileTreeRepository new directory: './pharo-core/src' asFileReference; yourself. versions := OrderedCollection new. repo allFileNames do: [ :packageName | | wc | wc := MCWorkingCopy allManagers detect: [ :each | each packageName = (packageName withoutSuffix: '.package') ] ifNone: [nil]. wc ifNotNil: [ versions add: (repo loadVersionFromFileNamed: packageName) ]] displayingProgress: [:e | e ]. merger := MCVersionMerger new. versions do: [:each | merger addVersion: each ]. merger mergeWithNameLike: 'merged'. merger gatherChanges. (merger instVarNamed: #records) do: [ :each | each mergePatch operations do: [:operation | operation chooseRemote.]]. (merger instVarNamed: #merger) operations do: #chooseRemote. merger resolveConflicts. However I have seen cases where for example the PR deleted some class and the MC merging tool was not able to see this change. So be careful with this approach. We need to look at that. Do not look on this mail as something final. It's only a hint for brave sprinters. To find a good workflow how properly review our PR should be one of our priorities. Cheers, -- Pavel

2 2

About Fogbugz 20165 Support-segment-path-printing
by Stephane Ducasse June 30, 2017

June 30, 2017

Hi alistair I'm starting to review code that is in the PR pipeline. https://github.com/pharo-project/pharo/pull/126 I noticed that you wrote in the slice Changes since last slice: - Change Path>>fullName to just print the path - Fix absolute path strings - Bug fix Path class>>from:delimiter: - Add unit tests But I only see in the PR three methods. Can you check because I have the impression that we are losing code somewhere? BTW I could not see the contents of the AlistairGrant.1 package I tried on several images 70 and 60 latest Stef

3 5

[pharo-project/pharo-core]
by GitHub June 30, 2017

June 30, 2017

Branch: refs/tags/60505 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] d09696: 60505
by GitHub June 30, 2017

June 30, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d096961f099012edaa6a1447bb0868a7abfe34db https://github.com/pharo-project/pharo-core/commit/d096961f099012edaa6a1447… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-30 (Fri, 30 Jun 2017) Changed paths: M AST-Core.package/RBProgramNode.class/instance/accessing/comments_.st M CodeImport.package/ChunkReadStream.class/instance/decorated/parseLangTagFor_.st M Collections-Strings.package/String.class/instance/converting/withNoLineLongerThan_.st M ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/printing/printConfigurations_.st M Files.package/MultiByteFileStream.class/instance/fileIn%2FOut/nextChunk.st M Files.package/MultiByteFileStream.class/instance/fileIn%2FOut/nextPreamble.st M Graphics-Display Objects.package/Form.class/instance/other/fillAlpha_.st M Jobs.package/Job.class/class/examples/exampleCurrentValue.st M Kernel.package/Protocol.class/instance/initialization/initialize.st M Multilingual-TextConversion.package/UTF16TextConverter.class/instance/conversion/nextFromStream_.st M OpalCompiler-Core.package/IRBytecodeDecompiler.class/instance/instruction decoding/jump_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitPopIntoRemoteTemp_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitPushRemoteTemp_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitStoreRemoteTemp_.st M OpalCompiler-Core.package/IRReconstructor.class/instance/initialize/createTempVectorNamed_withVars_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60504.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60505.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60504.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60505.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/TemporaryVariable.class/instance/comparing/hash.st M System-Sources.package/PharoChangesCondenser.class/instance/initialization/reset.st M System-Sources.package/SourceFileArray.class/instance/private - copying/readOnlyCopy.st M Text-Core.package/Text.class/class/initialization/initialize.st M Text-Core.package/Text.class/class/instance creation/fromString_.st M Text-Core.package/TextFontChange.class/class/as yet unclassified/defaultFontChange.st M Traits.package/TBehaviorCategorization.class/instance/organization/category.st M UIManager.package/UIManager.class/instance/ui process/spawnNewProcess.st M Zinc-HTTP.package/ZnImageExampleDelegate.class/instance/accessing/html.st M Zodiac-Core.package/ZdcPluginSSLSession.class/instance/accessing/serverName_.st Log Message: ----------- 60505 20187 Request use of block in certain methods https://pharo.fogbugz.com/f/cases/20187 20188 Request representation of integer literal without float exponent https://pharo.fogbugz.com/f/cases/20188 20182 Extra dot in literal array https://pharo.fogbugz.com/f/cases/20182 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/18760 20186 Request removal of extra statement separators (dot) https://pharo.fogbugz.com/f/cases/20186 http://files.pharo.org/image/60/60505.zip

1 0

about expressions
by Stephane Ducasse June 30, 2017

June 30, 2017

I do not get why (Yes I know it is because it is not in the syntax.... but it is conceptually not nice). | d | d := Dictionary new. d at: #top at: #below1 put: 1. d at: #top at: #below1 put: 2. d at: #top at: #below1. is not an expression in Pharo. It means that I can manipulate 1 + 3, x + 3 as an expression but not a sequence. So it forces me to use a block to convert artificially a sequence in an expression. [ | d | d := Dictionary new. d at: #top at: #below1 put: 1. d at: #top at: #below1 put: 2. d at: #top at: #below1. ] value So if I want to build a repl executing expression then this is not a Pharo repl but just a stupid expression. I would like to know what would be impact to have sequence and declaration as expression. Stef

2 2

FileReference>>/ and path canonicalisation
by Alistair Grant June 30, 2017

June 30, 2017

Pharo's FileSystem behaviour is currently somewhat inconsistent in its treatment of path strings. To be able to demonstrate the limitations and fixes, I'm assuming that the following files and directories have been created (/dev/shm is a memory based file system in Ubuntu): cd /dev/shm mkdir -p d1/d2/d3/d4 touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt pushd d1 && ln -s d2/d3 ./s3 && popd 1. Path's are canonicalised during initial creation, but are not when extending the path, i.e. sending #/ E.g. '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" Automatic canonicalisation is problematic as the code doesn't handle symbolic links in the path name: ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" 2. In an attempt to be completely general, the argument to #/ is assumed to be a single directory / file. This is incorrect as the path delimiter is not allowed to be part of the file name. The result is that path comparisons and operations such as #parent give unexpected results. E.g. ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" My PR modified FileSystem so that: 1. Canonicalisation is separated out as an operation that has to be manually requested: '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" 2. The argument to #/ can be either a single file / directory name or a path. ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" 3. Adds unit tests to cover the changed behaviour. While I believe that these changes improve Pharo overall, making it more intuitive and consistent, modifying the path creation to remove canonicalisation is not backward compatible and requires a change to PathTest>>testRelativeFromStringNormalization and PathTest>>testRelativeFromStringNormalizationParent to manually canonicalise the paths. Before I submit the patch, does anyone have any strong objections to the changes as described above? Thanks, Alistair

4 10