Squeak-dev October 2017

squeak-dev@lists.squeakfoundation.org

40 participants
132 discussions

Re: [squeak-dev] How to submit something to the inbox
by Jakob Reschke 08 Oct '17

08 Oct '17

2017-10-08 13:26 GMT+02:00 Bob Arning <arning315(a)comcast.net>: > > > On 10/7/17 2:02 PM, David T. Lewis wrote: >> 2) Open the inbox repository >> A) In your Squeak 5.1 image, open a Monticello Browser. >> B) On the right hand side of the browser, highlight the "http://source.squeak.org.trunk" repository. > That's "/trunk" right? Correct. >> 3) Get ready to commit your changes to the inbox >> A) Make sure your image is updated (world -> help... -> update code from server) Or click the Squeak Mouse in the left corner of the main docking bar -> Update Squeak. >> B) In the Monticello browser, highlight package "Morphic" on the left, and > "Graphics" in this case? You have to pick the package that contains your changes. >> repository "http://source.squeak.org/trunk" on the right. > This is the same "trunk" that I renamed to "inbox" in the previous step? Short answer in the context of this how-to list: yes. I think "editing" the trunk repository is not the right way. Rather, one should copy the snippet that is displayed on "edit repository info", and create a new HTTP repository via the +Repository button, paste the copied snippet and then change trunk to inbox there. In the end, you should have both trunk and inbox in the right-hand list (at least when no package is selected in the left-hand list). But you must then also add the "new" inbox repository to your package by right-clicking on that package, choosing "add repository...", and selecting the inbox repository. It will then appear in the right-hand list for the package, so both trunk and inbox will be there. If this must be done by every new contributor, it is really complicated, so it ought to be already set up out-of-the-box, IMHO. That is, for all packages which are included in the trunk it should already be there. >> C) Click the "Changes" button on the top. >> D) The "changes" here are the differences between your image and the most >> recent version in the trunk repository. Verify that these are the changes >> that you want to submit, no more and no less. If something looks wrong, stop >> and ask for tips on the squeak-dev list. > If I get changes from trunk, it is one method. If I get changes from > inbox, it is a bazillion. So, if I save to inbox, am I saving one or a > bazillion? Phew Monticello... Short answer: you are saving one method, usually. Next to the package name in the left-hand list, there is a version indication in brackets: for example, "Graphics -->(topa.382)<--". This is your baseline version for the package (Graphics-topa.382). The changes that you see and select when you click "Save" are the ones that your new version will contain when compared to the base version. Regarding the contents and ancestry of your new version, it does not matter to which repository you save it. The "Changes" button gives you the list of changes that would transform the latest version from the selected repository to the state in your working copy/image. The latest Graphics version in the inbox might be old, so you get a bazillion of changes. Since the base version usually comes from trunk, especially if you updated beforehand, the "Changes" from trunk give you the better impression. People regularly criticize Git for being complicated and that it is unfortunate that one is advised to learn its inner workings to fully embrace it. But it seems that Monticello displays the same problem. Note that in step 4A... >> 4) Submit your changes to the inbox >> A) Now highlight the "http://source.squeak.org/inbox" repository on the right >> pane of the Monticello browser, and package "Morphic" on the left. ...you must first select the package on the left, and then select the repository on the right. The repository selection is cleared when you select the package. If the repository is not on the list, you have to "add repository" to the package, as described above.

2 1

Re: [squeak-dev] How to submit something to the inbox
by Jakob Reschke 08 Oct '17

08 Oct '17

Am 08.10.2017 08:04 schrieb "H. Hirzel" <hannes.hirzel(a)gmail.com>: Please also note that for inbox contributions to be useful you have to submit them from a fully updated latest trunk image. I would like to note that this is not strictly required. But it saves the inbox treaters the time for merging. New contributors should rather update before coding because they might find that the issue they are trying to solve has already been resolved. That being said, one could probably extend the inbox interface to prepare conflict-free merge versions automatically (as a post-upload or pre-treatment-inspection action). CI for the inbox would be nice, too... A useful fix for an older release could also come in via the inbox, but the author would have to name the target in the commit message because Monticello does not have branch names or targeted merge requests. Best regards, Jakob

1 0

Re: [squeak-dev] How to submit something to the inbox (was: Graphical oddities across image save (squeak 5.1))
by Jakob Reschke 07 Oct '17

07 Oct '17

For better PR, this list should be shortened to a few concise steps when put on squeak.org, IMHO. The long list would make me think that contributing to Squeak were complicated. Even though not all of the steps have to be repeated every time... I am referring to the first impression when you see this. These more detailed instructions could be hidden behind a link, in the wiki, or in a help topic if you will. Also, why not include the inbox already added as a repository in the trunk image? Saves step 2. Since the box is open to everybody, this should not be a problem, or would it? 2017-10-07 20:19 GMT+02:00 karl ramberg <karlramberg(a)gmail.com>: > Hi, > Make a help topic and add this to the help browser :-) > > Best, > Karl > > > > On Sat, Oct 7, 2017 at 8:02 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Sat, Oct 07, 2017 at 11:12:10AM -0400, Bob Arning wrote: >> > I never learned how. :-( >> > >> >> I am sure you are not the only one. I guess we should get some very simple >> and clear instructions on the squeak.org page for How To Contribute to the >> Inbox. >> >> If you do not mind giving it a try, here is what you can do: >> >> 1) Create an account on source.squeak.org >> A) Using a web browser, go to http://source.squeak.org. >> B) On the left side of the web page, click on "Register Member". >> C) Fill in the information on the form. In the "Initials:" field, use >> your >> regular author initials, same as for method stamps. >> D) Click "Save". >> E) Remember the password that you just defined, because you will use it >> in step 2 below. >> >> 2) Open the inbox repository >> A) In your Squeak 5.1 image, open a Monticello Browser. >> B) On the right hand side of the browser, highlight the >> "http://source.squeak.org.trunk" repository. >> C) Do a right-click, select "edit repository info" >> D) In the edit dialog, change "trunk" to "inbox" in the location, put >> your author initials in the "user" field, and put your new password >> in the "password" field. >> E) Click "Accept" >> F) Verify that http://source.squeak.org/inbox now appears as a >> repository >> in the right hand pane of your Monticello browser. >> >> 3) Get ready to commit your changes to the inbox >> A) Make sure your image is updated (world -> help... -> update code from >> server) >> B) In the Monticello browser, highlight package "Morphic" on the left, >> and >> repository "http://source.squeak.org/trunk" on the right. >> C) Click the "Changes" button on the top. >> D) The "changes" here are the differences between your image and the >> most >> recent version in the trunk repository. Verify that these are the >> changes >> that you want to submit, no more and no less. If something looks >> wrong, stop >> and ask for tips on the squeak-dev list. >> >> 4) Submit your changes to the inbox >> A) Now highlight the "http://source.squeak.org/inbox" repository on the >> right >> pane of the Monticello browser, and package "Morphic" on the left. >> B) Click the "Save" button on the top of the Monticello browser. >> C) In the dialog that opens now, find the "empty log message" text. >> Replace >> it with your description of what you are changing. This would be the >> same >> kind of description that you would put into the preamble of a change >> set. >> D) Click "Accept" >> E) Wait for the changes to be sent to the inbox repository. >> >> 5) Follow ups >> A) Your new update should now appear in the inbox. In the Monticello >> browser, >> highlight the inbox repository and click the "Open" button at the >> top. >> A Repository Browser will open. Click the "Refresh" button, and you >> should >> see your new entry listed. You can also find in through the web >> interface >> for http://source.squeak.org. >> B) On the squeak-dev list, a mail notification should appear within a >> few minutes >> to notify the list about your new submission. >> C) You can reply to that notification on the list, or to your earlier >> mail thread >> to offer any other explanations or to ask someone to look at your >> inbox submission >> and move it to trunk (or to "treated inbox" if it is not suitable for >> trunk for >> some reason). >> >> >> Dave >> >> >> > >> > On 10/7/17 10:37 AM, Tobias Pape wrote: >> > >>On 07.10.2017, at 14:15, Bob Arning <arning315(a)comcast.net> wrote: >> > >> >> > >>It seems like rule 34 is handled differently by primitiveDisplayString >> > >>and primitiveCopyBits. If I add code as exists elsewhere to >> > >> unhibernate >> > >>forms and retry, all is working as expected: >> > >> >> > >This seems like a very reasonable thing. >> > >Care to put it into the inbox? >> > > >> > >Best regards >> > > -Tobias >> > > >> > >> >> > >> >> >

2 1

The Trunk: Help-Squeak-TerseGuide-topa.7.mcz
by commits＠source.squeak.org 07 Oct '17

07 Oct '17

Tobias Pape uploaded a new version of Help-Squeak-TerseGuide to project The Trunk: http://source.squeak.org/trunk/Help-Squeak-TerseGuide-topa.7.mcz ==================== Summary ==================== Name: Help-Squeak-TerseGuide-topa.7 Author: topa Time: 7 October 2017, 1:20:21.797484 pm UUID: 043213fa-d7ab-49a1-ac2d-e370a65c54c7 Ancestors: Help-Squeak-TerseGuide-pre.6 Fix symbols =============== Diff against Help-Squeak-TerseGuide-pre.6 =============== Item was changed: ----- Method: TerseGuideHelp class>>symbol (in category 'pages') ----- symbol ^HelpTopic title: 'Symbol' contents: '"************************************************************************ * Symbol: * ************************************************************************" | b x y | x := #Hello. "symbol assignment" + y := #Symbol, ''Concatenation''. "symbol concatenation (result is string)" - y := ''String'', ''Concatenation''. "symbol concatenation (result is string)" b := x isEmpty. "test if symbol is empty" y := x size. "string size" y := x at: 2. "char at location" y := x copyFrom: 2 to: 4. "substring" y := x indexOf: $e ifAbsent: [0]. "first position of character within string" x do: [:a | Transcript show: a printString; cr]. "iterate over the string" b := x allSatisfy: [:a | (a >= $a) & (a <= $z)]. "test if all elements meet condition" y := x select: [:a | a > $a]. "return all elements that meet condition" y := x asString. "convert symbol to string" y := x asText. "convert symbol to text" y := x asArray. "convert symbol to array" y := x asOrderedCollection. "convert symbol to ordered collection" y := x asSortedCollection. "convert symbol to sorted collection" y := x asBag. "convert symbol to bag collection" y := x asSet. "convert symbol to set collection" '!

1 0

FileList2>listForPattern(s): and MessageSend abuse
by tim Rowledge 06 Oct '17

06 Oct '17

FileList2 has both #listForPattern: and #listForPatterns: I cannot find any usage of the #listForPattern: and it also looks like it might be a left over from some EToys experiment. Given the possibilities of confusion between the tow I’d prefer to remove it. Both methods also try to handle having the fileSelectionBlock be a MessagesSend, and do it horribly. Using #isKindOf: is not a nice thing. a) I can’t find any place where a MessageSend is actually meaningfully used except an EToys method where a Block would be at least as good and easier to understand, so why even have the option? b) the usage seems poor - why set the arguments, evaluate the MS and then empty the arguments instead of simply treating it as a Block? I might be missing some subtlety of MessageSend I suppose, but given the mess of code in that class I wouldn’t be surprised. Does anyone know why we shouldn’t remove #listForPattern: and clean out the (mis)use of MessageSend in #listForPatterns: ? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.

6 22

The Trunk: ToolBuilder-Morphic-tpr.196.mcz
by commits＠source.squeak.org 06 Oct '17

06 Oct '17

tim Rowledge uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-tpr.196.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-tpr.196 Author: tpr Time: 2 October 2017, 5:09:16.231117 pm UUID: 7036c368-757d-4824-ac4a-52ac133665f3 Ancestors: ToolBuilder-Morphic-nice.195 Rather than testing an argument for morphnicity, how about jaust making a morph do the right thing (ie nothing)? Not entirely clear that the 'problem' can ever really arise, but I can't see any way to prove either case. =============== Diff against ToolBuilder-Morphic-nice.195 =============== Item was added: + ----- Method: Morph>>buildWith: (in category '*ToolBuilder-Morphic-opening') ----- + buildWith: aToolBuilder + "A Morph is already built, so simply return myself" + ^self! Item was changed: ----- Method: MorphicToolBuilder>>open: (in category 'opening') ----- open: anObject "Build and open the object. Answer the widget opened." + + ^ (self build: anObject) morphicOpenWith: self! - | morph | - morph := anObject isMorph ifTrue: [anObject] ifFalse: [self build: anObject]. - ^ morph morphicOpenWith: self!

7 10

Small UI fix needed in OCompletion - ECPreferences>> menuSelectionColor
by H. Hirzel 06 Oct '17

06 Oct '17

Hello After loading the Vivide Framework / Toolset [1], [2], [3] into a recent trunk image I got a complaint about the menuSelection color. Marcel and I could identify that ECPreferences, package 'Ocompletion-ECSqueak' [4] needs to be fixed. ECPreferences>> menuSelectionColor Smalltalk at: #UITheme ifPresent: [ :uiTheme | "Pharo" ^uiTheme current settings selectionColor ]. Smalltalk at: #Preferences ifPresent: [ :preferences | "Squeak" ^preferences menuSelectionColor ] Could somebody with access rights (Levente?) help Kind regards Hannes [1] https://github.com/hpi-swa/vivide/ [2] https://github.com/hpi-swa/widgets [3] https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/vivide/ [4] http://www.squeaksource.com/OCompletion

2 1

Displaying the class outline of FileList in the Vivide IDE
by H. Hirzel 06 Oct '17

06 Oct '17

Hello Marcel attached is a screen shot of a 'class outline' of FileList done with Vivide (the version based on Squeak 5.1, [3]). On the right hand side is the script you posted earlier today. This helps to look at the system in a synoptic using screen estate well. Would it be possible to have a preconfigured Vivide version for the most recent trunk in [3] for finding out about current issues as well? Or even better - have Vivide as a loadable project type like what we are trying to do now with EtoysProject? Kind regards Hannes On 10/5/17, Marcel Taeumel <marcel.taeumel(a)hpi.de> wrote: > Hi, Hannes. > > Here is the script that produced the output. Just do-it in a workspace: > > { > > [:in :out | in do: [:class | out add: { > #object -> class. > #text -> (ViLabelService doObject: class). > #icon -> (ViIconService doObject: class) } ]] > -> { #isProperty -> true. > #view -> ViTreeViewExtended }. > > [:in :out | in do: [:class | out add: { > #object -> class. > #text -> (ViObjectOriginService doObject: class) } ]] > -> {(#isProperty -> true)}. > > [:in :out | in do: [:class | out addAll: class subclasses]]. > > 1. "reference to the first step" > } asScript openScriptWith: {StringHolder}. > > > Best, > Marcel > Am 05.10.2017 15:55:40 schrieb Marcel Taeumel <marcel.taeumel(a)hpi.de>: > I am using Vivide [1], whose standard scripts make use of Widgets [2]. There > are pre-configured Squeak images [3]. > > Best, > Marcel > > [1] https://github.com/hpi-swa/vivide/ [https://github.com/hpi-swa/vivide/] > [2] https://github.com/hpi-swa/widgets [https://github.com/hpi-swa/widgets] > [3] https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/vivide/ > [https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/vivide/] > Am 05.10.2017 15:50:58 schrieb H. Hirzel <hannes.hirzel(a)gmail.com>: > I agree, Marcel. Please, what is this nice tool you have been using > for the screen shot? > --Hannes >

2 16

Platform preferences survey (your chance to gripe about app stores!)
by Zak Fenton 06 Oct '17

06 Oct '17

Hi everyone! I'm launching a business offering new tools and services that might be of interest to users of scripting languages, so I'm interested in hearing your input (again). Thanks to those of you who participated in the earlier survey I've been busy improving the product suite to better match the needs of the community, so now I'm looking for more information about platform and distribution preferences in the lead-up to release. (Those of you who opted in for the beta trial are still on the list, I'll be in touch soon.) This survey should take less than 4 minutes to complete: https://www.surveymonkey.com/r/JGDJGRH Thanks! -Zak.

1 0

The Inbox: Kernel-hjh.1115.mcz
by commits＠source.squeak.org 05 Oct '17

05 Oct '17

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-hjh.1115.mcz ==================== Summary ==================== Name: Kernel-hjh.1115 Author: hjh Time: 5 October 2017, 1:03:22.023466 pm UUID: c80056e1-3f90-4dae-935f-2507eb2c0f94 Ancestors: Kernel-cmm.1114 Better to have only a short class comment than to have wrong content. Squeak 3.0 had message categories - code pane menu - message list menu. I did not verify if 'in some the text is a method' still applies or not. =============== Diff against Kernel-cmm.1114 =============== Item was changed: Model subclass: #StringHolder instanceVariableNames: 'contents' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Models'! + !StringHolder commentStamp: 'hjh 10/5/2017 13:00' prior: 0! - !StringHolder commentStamp: '<historical>' prior: 0! I am a kind of Model that includes a piece of text. In some cases, the text can be edited, and in some the text is a method. + ! - - Categories 'code pane menu' and 'message list menu' are messages that may be called by my menus when the text is a method, and when some pane is a list of methods. Other of my subclasses may ignore these two catagories altogether.!

3 6

Jump to page: