January 2016 - Pharo-dev - lists.pharo.org

(Spec/Morphic) MorphTreeNodeMorph>>setSelectedSilently: does not seem to select silently.
by Skip Lentz Jan. 15, 2016

Jan. 15, 2016

Hi, I had some problems with TreeModel>>deselectAll. It appears that when one sends #deselectAll, the selectedItemsChanged block is passed a _non-empty_ selection. While debugging I saw that #setSelectedSilently: apart from setting a #selected instance variable, also sends #selected: to its âcomplexContentsâ, which triggers an Announcement chain causing the bug in the previous paragraph. When removing this statement from #setSelectedSilently: it seems to work properly. However I donât know if this âfixâ of mine has any side effects causing it to break at other parts of UI code which is not using Spec. I opened an issue on fogbugz: https://pharo.fogbugz.com/f/cases/17391 Thanks

1 0

#sum:, #detectSum:, #sumNumbers:
by Max Leske Jan. 15, 2016

Jan. 15, 2016

Hi guys, Collection defines #sum:, #detectSum: and #sumNumbers:, all of which accomplish the same (in principal) but with subtle differences: #sum: - uses #inject:into: with #anyOne as the injected element and will thus fail for empty collections #detectSum: - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot slower when dealing with large numbers (primitive fails and number conversion is necessary) #sumNumbers: - same as #sum but doesnât fail for empty collections. Only good for numbers though. Benchmarks: [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun 42391 [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun 18096 Can we settle for a single implementation? Such as (modified from #sumNumbers:): newSum: aBlock ^ self inject: (self ifEmpty: [ 0 ] ifNotEmpty: [ self anyOne ]) into: [ :sum :each | sum + (aBlock value: each) ] This implementation combines the best of the three implementations I think. Benchmark: [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 BTW, there is also the message #sum, which suffers from the same problem as #sum: (the implementation is basically a copy). #sum could be implemented as sum ^ self sum: [ :x | x ] As for the name for the new method, I suggest #sum:. Cheers, Max

21 96

Question about attribution under the MIT License
by Sven Van Caekenberghe Jan. 15, 2016

Jan. 15, 2016

Hi, I have a been wondering recently about attribution under the MIT License. Code in Pharo and code contributed to Pharo is and should be licensed under the MIT License. https://en.wikipedia.org/wiki/MIT_License Contributors sign an extra agreement. http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf Here, contributors give a license so Pharo can include their code. As I read the MIT license the original author keeps the copyright and about the only requirement is that that copyright shall be included when the code is used. The extra agreement does not transfer copyright. So, all authors should be mentioned in the general Pharo MIT license. The reason I was thinking about this is that many people on the list seems to be under the impression that MIT licensed code means that you can freely copy it, like most recently in the discussions about Dophin Smalltalk. I think copying MIT licensed code requires proper attribution. If people copy (my, someone else's) code from Pharo to somewhere else, I want them to at least acknowledge that fact, preferably include a general Pharo (contributors) copyright, but ideally (my, their) copyright. But that would also mean that Pharo has to do the same. I think we should list and update the official contributor list, including the historical list of original authors going back. Am I right or wrong ? How do other people feel about this ? Sven

4 4

[pharo-project/pharo-core] 0d016b: 50527
by GitHub Jan. 14, 2016

Jan. 14, 2016

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0d016b26ee0e42f8c1960fefefde84d9f1444739 https://github.com/pharo-project/pharo-core/commit/0d016b26ee0e42f8c1960fef… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-14 (Thu, 14 Jan 2016) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version083_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st R Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/toSelectionRow_primary_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateExposedRows.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing colors/colorForSelection_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/selectRowIndex_event_.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/definition.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/accessing/selectionColor_.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseEnter_.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseLeave_.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialization/initialize.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialize/defaultColor.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialize/selectionColor.st R Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/README.md R Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/class/instance creation/new.st R Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/class/instance creation/table_row_primary_.st R Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/definition.st R Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/instance/initialization/initializeTable_row_primary_.st M Nautilus.package/AbstractNautilusUI.class/instance/private/runTestsOfClass_notifying_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50526.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50527.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50526.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50527.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50527 17379 FastTable mouse over on highlighted item https://pharo.fogbugz.com/f/cases/17379 17386 Nautilus test notification should show test results https://pharo.fogbugz.com/f/cases/17386 http://files.pharo.org/image/50/50527.zip

2 1

[pharo-project/pharo-core]
by GitHub Jan. 14, 2016

Jan. 14, 2016

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

1 0

Launcher 0.2.9 opens Spur images
by Damien Cassou Jan. 14, 2016

Jan. 14, 2016

Hi list, thanks to the awesome work of Vincent Blondeau, Stephan Eggermont and Cyril Ferlicot, Pharo Launcher 0.2.9 can be configured to open both spur and pre-spur Pharo images. You can download this version from http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher. You can safely replace your existing Launcher installation with the new one. Your images won't be affected and you will still be able to launch them. The VM coming with these builds is a pre-spur VM because Launcher is based on Pharo 4. If you want to launch Pharo 5 spur images, you need to separately download a Pharo 5 Spur VM from http://get.pharo.org/vm50 and configure the location of this VM in the Launcher settings (icon at the bottom left of the Launcher window). What I like about this release is that I didn't do anything but changing the version number in https://ci.inria.fr/pharo/view/all/job/Launcher :-). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

1 0

Bug in protocol and method selection
by stepharo Jan. 14, 2016

Jan. 14, 2016

Hi There is a problem in latest Pharo. I cannot select (and keep the selection selected) of a method and method protocol. To me it looks like QA is interferring but I do not know. This is the kind of glitches that can kill our effort doing videos. We have a strong deadline for producing such videos. beginning of march but we want to get done before any help is welcome. Stef

3 6

About LayoutFrame>>fractions:offsets:
by stepharo Jan. 14, 2016

Jan. 14, 2016

Here is the new class comments I'm trying to write. I hope that it will help people to understand the circumstances under which they should use fractions:offset: creation API. I define a transformation frame relative to some rectangle. I'm basic data structure used for graphics. I represent two groups of distances: - The fractional distance (between 0 and 1) to place the morph in its owner's bounds - Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") !! API usage It is important to understand that it is better to use the fine grained API using elementary distances (bottomFraction:, bottomOffset:, leftFraction: ....) than the ones (historical) using points and rectangles (fractions:offsets:) The reason is that the old API (fractions:offsets:) is only interesting if you already have a rectangle and points at hand. If you need to create new ones, then they are created for nothing because they will be destructured to extract their information to be feed into the layoutFrame. So please do not blindly copy and paste code! Example: Favor (LayoutFrame identity leftFraction: 0; yourself); (LayoutFrame identity leftFraction: 0.5; rightFraction: 0.95; (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: 1) over (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) because you are creating for nothing a new rectangle and some points. !! Implementation Instance variables: The fractional distance (between 0 and 1) to place the morph in its owner's bounds is represented by the following instance variables: leftFraction topFraction rightFraction bottomFraction <Float> Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") is represented by the following instance variables: leftOffset topOffset rightOffset bottomOffset <Integer>

4 8

ANN - Pre-compiled Pharo Spur32 VM for Debian Stable
by Jan Vrany Jan. 14, 2016

Jan. 14, 2016

Hi there,Â the Pharo Spur VM provided by the Pharo team does not runÂ Debian Stable and possibly on other more conservative Linux distributions.Â You may find a pre-compiled Spur32 Pharo VM that runs onÂ Debian Stable (and possibly on other distros) at:Â https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/ Zeroconf for those is also available:Â curl http://swing.fit.cvut.cz/download/pharo/vm-spur-swing | bash wget -O- http://swing.fit.cvut.cz/download/pharo/vm-spur-swing | bash Thanks a lot to Esteban and Damien for their help! Have fun!Â Jan

1 0

poor first Monticello experience (was Fwd: (off list) Bad layoutFrame>>#hash)
by Ben Coman Jan. 14, 2016

Jan. 14, 2016

On Thu, Jan 14, 2016 at 7:59 PM, David Allouche <david(a)allouche.net> wrote: > On 14 Jan 2016, at 04:26, Ben Coman <btc(a)openinworld.com> wrote: > hi David, > Since you seem keen to jump into some code reviews, just > a prompt you might like to make this your first one... > https://pharo.fogbugz.com/default.asp?17363 > >> ---------- Forwarded message ---------- >> From: Stephan Eggermont <stephan(a)stack.nl> >> Date: Thu, Jan 14, 2016 at 1:09 AM >> Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash >> To: pharo-dev(a)lists.pharo.org >> >> SLICE-Issue-17363-LayoutFrame-fractions-0--0-corner-1--1--LayoutFrame-identity-should-be-true-and-it-is-not-StephanEggermont.2 >> >> Better hash both in distribution and in working with Float coordinates >> > > Thank you. That should be easy, since it was a change I suggested and which > was already reviewed informally on the ML :-) > > I think I figured out how it's supposed to work. Can you confirm? First let me say ouch! and secondly I'm impressed you typed that all out in detail. It portrays a much better picture than a general comment. So it seems we have some tuning to do. > From the issue page, copy the slice name: > SLICE-Issue-17363-LayoutFrame-fractions-0--0-corner-1--1--LayoutFrame-identity-should-be-true-and-it-is-not-StephanEggermont.2 > Go to the image. Open Monticello Browser. > In right (repositories) pane, select > http://smalltalkhub.com/mc/Pharo/Pharo50Inbox/main > Try double clicking, see that it does not work This is probably a good idea to have. Give a chance for others to comment, then could you open an issue for it on Fogbugz (Milestone=Pharo5, Category=Enhancement, Project=Monticello) > Guess that one should click the Open button in the top right of the > Monticello Browser window. > Come back to the web browser to copy the slice name again, because, I used > the clipboard to paste the repository name in this email. > Paste the slice name in the search pane on the right. > See no result, because there was a trailing newline in the clipboard. I guess this field should exclude returns and even all trailing whitespace. Maybe this should be the default for all such controls (?) Could you open another issue (or actually search a bit first see if its already been noted) > Click on the search pane. Notice it selected all. Click again to put the > caret at the end. > Backspace, okay, one result, that should hopefully be it, but it's too long > to fit in the window. I guess its not intuitive, but I only ever type the Issue Number of the slice, since that is unique and there is usually only a couple of items > Double click on it, nothing happens. Choosing a default double-click action would need some community discussion. Maybe <Merge> ?? > Remember that thing appears to think double clicks do not matter. > Right click on it, see only sorting options, nothing relevant. I don't think I have ever used the sort options. Does anyone else use them so often they couldn't be a submenu of a context menu? > Look at the buttons on the top of the window. Browse, maybe? > Get confused by a class browser that somehow does not have syntax > highlighting, and also shows a lot of things that have nothing to do with > the code I want to review. That was probably not the right button. Close the > window. I never use <Browse>. I'm no sure of its value but note however that Monticello is a general tool for loading packages, which has been pressed into service to load slices (which is just a package binding a set of dependent packages together.) <Browse> might be good for exploring a completely new package before its loaded the first time. > Click on History. Get a window with only the description of the selected > slice, what use could that possibly have? Not so much for reviewing slices which have a shallow history. But again Monticello is a general package management tool. For this, search on 'strings' , then select package Collections-Strings. Observe how version Lorenzano.385 is underlined. This version is the one currently loaded in the image. Observe also Polito.383 is bolded. This is not an an ancestor of the currently loaded package version. You can see Lorenzano.385 has ancestor Lorenzano.384 which has ancestor Lorenzano.383. Select Lorenzano.385 and click <History> and you will see Polito.383 missing from the list. > Click on Changes. Stuff blinks on screen for a couple seconds, to fast to > read. Lucky you ;) it takes a while from Australia. I'm not sure of best practice, but personally, to review slices I only ever use <Merge> in the repository window since this provides a three-way diff. I'm not sure... but I don't think <Changes> does (?) Back when I started with Pharo using this repository <Changes> button gave different results depending on factors I couldn't track down. I've never had a problem with <Merge> and <Merge> is what the CI monkey uses. Now I regularly use the <Changes> button back in the first Monticello window. It compares to the selected repository, so as Stef mentioned on Fogbugz, when you do come to submit your first slice select to compare Pharo50/main rather than Pharo50Inbox/main. If its the first time this release cycle a package is updated, the ancestor won't be in Inbox and so every method is counted as a change (probably it should be better) btw, the CI monkey copies integrated packages from the latter to the former. > I guess that means to reassure me. I wonder how hard it would be to > have a single progress bar. I don't know. Others might chip in. > A window opens with three panes. Too narrow to read. > Maximize the window. Still to narrow. > Maximize the world window. Did not change the size of the window. > Maximize the window again. Weird that changed the size and position a bit. I > guess that unmaximized that window that was not really maximized. > Maximize the window again. Okay now I can see the diff. Interesting find. You probably worked this out, but just to be clear... When the window was first maximized it recorded this was its state, and that was not reset when the world was maximized. So the next click of the button unmaximized it. And the final click properly maximized. So I see two alternatives: * a maximized window should follow the resizing of the world's native window * the maximized state of windows is reset when the world is resized. Lets see what others think. > Okay now, how I am supposed to post comments? I guess I should copy the > relevant bit of code, paste it in the browser, and add my comment. That's > going to make reviewing larger changes painful, but that's something, I > guess. We have some way to go here. Some innovation is needed. > Mh, actually that turned into a step by step account of all the trouble I > had. > > And that's only this long because I already figured how to get a working dev > image (needing the source files was not really obvious at first), and some > notion about finding changes in the Pharo50Inbox. None of which is obvious > to the aspiring contributor nor simply explained on a "how to contribute" > page. Thanks for sticking with it. Human nature is to adapt, and after a while become oblivious to these issues - like automatically stepping over that wobbly cobblestone in your front path without thinking about it. Fresh eyes are really valuable. In case its useful to adap, I'll summarize the workflow I've optimised for me personally: 1. Refresh PharoLauncher. 2. Right-click on latest numeric build and <Create Image> 3. For image name keep build number and replace left with issue number. e.g. "Case17363-50526". Sometimes I append the issue title from fogbugz. Sometimes I need a few images for a case e.g. "Case17363-50526b" usually created from "Local" templates, and its annoying when I forget. 4. Open Image, Monticello, Pharo5Inbox repository. The issue number shows in the native window title, so type that into search. 5. Select latest slice and <Merge> to review changes. I don't proceed with pushing the final execute <Merge> button in this window. I leave it open so after merging I retain a list of the changes. 6. From first Monticello window open a second Pharo5Inbox repository window. Select same slice and <Merge>, then push final <Merge> button to execute. ((For a long time I've been meaning to put a "Keep open" checkbox next to the final <Merge> execute button so I don't need to do this dance. Maybe soon)) 7. Browse from listing changes in retained window, insert appropriate breakpoints to understand the changes and form the questions to ask to learn more. > > Feel free to forward this message to the mailing list. I answered privately > because I was not sure exactly why you sent your message privately. Your new here. I didn't want you to feel pressured being publicly volunteered for something you weren't ready for. But obviously your up for it, so cool. cheers -ben > > Now, I'll post my comment on the slice on fogzbugz.

1 0