- Pharo-dev - lists.pharo.org

Bloc consideration - TextActions

by Ben Coman

This is may not be worth investigating much in Morphic, but tips are welcome. Mainly this is a use case for consideration with the TextAction equivalent in Bloc. For the #text: of a TextEntryDialogWindow I wanted clickable link similar to the bottom of ```WelcomeHelp open``` which would open a link in a web browser using https://github.com/seandenigris/Pharo-Web-Browser. Experimenting in Playground, this[1] looked promising... ``` linkText := 'https://exercism.io/my/settings' asText addAttribute: (TextAction new actOnClickBlock: [ self inform: 'STUB: Invoke web browser here']); addAttribute: (TextColor new color: Color cyan). requestText := 'Enter your Exercism token (from ' asText, linkText, '):'. requestText inspect. ``` where clicking on the link displays the information message. But this[2] didn't work... ```UIManager default request: requestText``` or to be more explicit, diving in a few calls down and simplifying, neither did this... ```(TextEntryDialogWindow new text: requestText) openInWorld``` I tracked it down to [2] having a locked TextMorph for requestText. (observed using the following instrumentation...) TextMorph isLocked (text asString includesSubstring: 'Enter your Exercism token') ifTrue: [ Transcript show: (super isLocked ifTrue: 'x' ifFalse:'.')]. ^ super isLocked and confirmed with this experiment... ``` tm1 := TextMorph new newContents: requestText. tm2 := tm1 copy lock. tm1 openInWorld. "Test clicking the text - action is invoked" tm1 delete. tm2 openInWorld. "Test clicking the text - action not invoked" tm2 delete. ``` This is due to #isLocked call here...: ``` Morph>>rejectsEvent: anEvent "Return true to reject the given event. Rejecting an event means neither the receiver nor any of it's submorphs will be given any chance to handle it. If the event is a mouse wheel event then only reject if the receiver is not visible." (anEvent isMouse and: [anEvent isMouseWheel]) ifTrue: [^self visible not]. ^self isLocked or: [self visible not] ``` Now the functional paradox here is that: * an unlocked TextMorph is editable, which you don't want for a static UI label; * but a locked TextMorph doesn't pass events through to trigger the TextAction. Thus it you can't have a clickable link in a static UI label. Yet that is almost an essential feature in today's "linked" world and I hope Bloc will provide a facility for actions within static/locked text. cheers -ben P.S. Any tips on getting this to work in Pharo 6.1 would be appreciated.

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Alistair Grant

On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > > Maybe we could have a package with release tests that are not executed > by the CI but that are executed at the moment of the feature freeze and > some time before the Pharo release to ensure the quality of the code > base for tests that are too long? The drawback of this approach is that it relies on the original author going back and submitting a fix in a timely manner (quite possibly after they've moved on to other things). If the tests could be run on a specified set of classes / methods, perhaps we could run them as part of Iceberg, i.e. when going to commit code, these tests are run on the classes in the commit and a warning opened prompting the user to fix them before actually committing. Cheers, Alistair

Sept. 7, 2018

Iceberg > review pull request & repo name clash

by Ben Coman

Two concerns from one flow of events... I was trying out "review a pull request" feature for the first time. This looks very promising, but I got stuck. In Pharo 6.1... Downloaded http://files.pharo.org/platform/Pharo6.1-win.zip Updated Icerberg per https://github.com/pharo-vcs/iceberg#update-iceberg Iceberg > Settings > Use custom keys = Enabled > Add > Clone remote repository Remote URL = git@github.com:exercism/pharo.git ==> "pharo" repo appears, status "Not loaded" > "pharo" repo > Packages ==> BaselineOfExercism, Exercism, etc > "pharo" repo > Github > View pull request > origin > enter github account password ==> shows PR#98 "Move setup to class initialization..." > right-click 98 > Review pull request ==> an empty window titled "Browsing pull request: #98...." appeared (see attached) Trying the same in Pharo 7 gave a different problem... >From Launcher started Pharo-7.0.0-alpha.build.1231.sha.cf8aa48.arch.32bit... Iceberg > Settings > Use custom keys = Enabled > "pharo" repo > Forget Repository > Ticked "Also remove repository from file system" > Add > Clone remote repository Remote URL = git@github.com:exercism/pharo.git ==> "pharo" appears, status = "Fetch required. Unknown cf8aa48" > "pharo" repo > Fetch ==> no change in status, but I do see the the expected files in repo on disk > "pharo" repo > Packages ==> only shows LICENSE and README.md. Why did this "just work" in 6.1 ? It seems the source directory is wrong. From this point is it possible to update the source directory to "dev/src/" ? Maybe its due to the name clash "pharo-project/pharo" versus "exercism/pharo" and something was retained after the "Forget Repository". Such a name clash is unfortunate, but is a corner case that should be handled. This could be a useful test case. Before I log an issue, could someone check I'm not doing something wrong. cheers -ben P.S. A work around might have been giving a custom local name for the exercism/pharo repo, much like you can specify the folder created by command line 'git clone'. Is such a feature planned for Iceberg?

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Gabriel Cotelli

In my experience this is not a good idea. When you're in the pressure of the release the last thing you want it's to fix things that shouldn't be merged in that form. It sends the wrong message to the people contributing, If you have this fail in your own PR you can easily fix it and learn for it for the next time. But at the time Pharo enter feature freeze probably is someone else who has to fix it. Maintaining code quality is way easier if you keep it in good shape everyday. > Hi, > > Maybe we could have a package with release tests that are not executed > by the CI but that are executed at the moment of the feature freeze and > some time before the Pharo release to ensure the quality of the code > base for tests that are too long? > > > Thanks > > T. > > > > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

Sept. 6, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Cyril Ferlicot D.

Le 06/09/2018 Ã 17:50, Torsten Bergmann a Ã©critÂ : > Hi, > > the very nice contribution on GIFReadWriter/animated images (see https://pharo.manuscript.com/f/cases/22137) > unfortunately introduced some methods that had no sender, were uncategorized and had unused temporary variables, etc. > > Something that is meanwhile shown by our tools and easy to fix. I guess it was some overseen leftover. Unfortunately this > also slipped through the integration process as it was merged without an approval from a community reviewer. > > I dont want to lament too much on this specifc case (especially as I now fixed it in https://pharo.fogbugz.com/f/cases/22426) > > But after I cleaned the P7 image this spring to not have unused temporaries anymore I was suprised to find such > glitches again now. So to me it shows that we need to write more tests to detect violations and keep our achieved quality standards > up and also should not solely rely on the review process. > > Otherwise we need to invest our time in cleaning up our own stuff afterwards again and again. > > To be specific one can evaluate: > > CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: [:x | x binding isUnused ]]. > > to find unused temps - which would be easy to package up into one of the release test to ensure no unused temp vars are left > (the tearDown would require an "ASTCache reset"). > > The problem is that this simple test would take around 20-30 seconds depending on machine and I do not know if it would be a > good idea/good solution to integrate. Especially I'm not sure if it is worth the issue or will kill the CI again and again. > > What do you think about it? Comments appreciated? > Hi, Maybe we could have a package with release tests that are not executed by the CI but that are executed at the moment of the feature freeze and some time before the Pharo release to ensure the quality of the code base for tests that are too long? > Thanks > T. > > > > -- Cyril Ferlicot https://ferlicot.fr

Sept. 6, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Gabriel Cotelli

Hi Torsten, We experienced some similar problems with our builds at Mercap, because all the tests involving code analysis are orders of magnitude slower than the unit tests. What we do is: - When the programmer closes a unit of work (in that case it will be equivalent to create a PR) we run the tests involving this kind of code analysis only over the changed code - In the global build this tests are run in parallel (this wouldn't solve the pressure over the infrastructure, but improves the troughput of the whole build) I think this kind of tests totally worth the effort. Gabriel On Thu, Sep 6, 2018 at 12:51 PM Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > the very nice contribution on GIFReadWriter/animated images (see > https://pharo.manuscript.com/f/cases/22137) > unfortunately introduced some methods that had no sender, were > uncategorized and had unused temporary variables, etc. > > Something that is meanwhile shown by our tools and easy to fix. I guess it > was some overseen leftover. Unfortunately this > also slipped through the integration process as it was merged without an > approval from a community reviewer. > > I dont want to lament too much on this specifc case (especially as I now > fixed it in https://pharo.fogbugz.com/f/cases/22426) > > But after I cleaned the P7 image this spring to not have unused > temporaries anymore I was suprised to find such > glitches again now. So to me it shows that we need to write more tests to > detect violations and keep our achieved quality standards > up and also should not solely rely on the review process. > > Otherwise we need to invest our time in cleaning up our own stuff > afterwards again and again. > > To be specific one can evaluate: > > CompiledMethod allInstances select: [:m | m ast temporaries > anySatisfy: [:x | x binding isUnused ]]. > > to find unused temps - which would be easy to package up into one of the > release test to ensure no unused temp vars are left > (the tearDown would require an "ASTCache reset"). > > The problem is that this simple test would take around 20-30 seconds > depending on machine and I do not know if it would be a > good idea/good solution to integrate. Especially I'm not sure if it is > worth the issue or will kill the CI again and again. > > What do you think about it? Comments appreciated? > > Thanks > T. > > > > >

Sept. 6, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Peter Uhnak

> It should return a FileReference, not an open stream. I believe there are methods that do that. There are different APIs for that. fileOpen*, as the name implies, _opens the file_ and returns the stream. (I think this should be the case for fileSave*) If you want file reference, then you can use e.g. UIManager default chooseFileMatching: #() label: nil or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`, `chooseFullFileName:extensions:path:preview:`, `chooseFullFileNameMatching:label:`. Also some methods for selecting directories (`chooseDirectory:path:`, chooseDirectory:from:`, ...) iirc some of them actually return String (file path) instead of FileReference. ( https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… ) So it can be confusing, but the API is already available. Also iirc UIManager should be preferred over UITheme builder. Peter On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > A question to those who worked on the new streams for Pharo 7: > > > > > > In PHARO 6 I used the following expression to open a file dialog and let > the user choose > > a binary file: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > This returned > > - either nil (when file dialog was canceled) > > - a "MultiByteFileStream" instance when a file was selected > > > > The MultiByteFileStream instance already had the name of the file (= > full path) and I was > > able to query it for further use: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > s name inspect > > > > (for instance to display which file is processed in a window by showing > the full path) > > > > > > > > Now in PHARO 7 same expression returns an instance of > ZnCharacterReadStream (as MultiByteFileStream > > is deprecated): > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > and ZnCharacterReadStream does not understand #name - and in fact the > info about the name is > > totally lost/not available. To me this looks missing/broken. > > > > So what is the recommended way in Pharo 7 to open a file dialog, let the > use choose a file > > and get a file stream but also the name? IMHO this is either broken or > missing... > > > > Thanks > > T. > > It should return a FileReference, not an open stream. I believe there are > methods that do that. > > But that is an incompatible API change (same selector, different return > type). So hard to decide. > > >

Sept. 6, 2018

Re: [Pharo-dev] Status fo Stream changes in Pharo 7

by Sven Van Caekenberghe

> On 6 Sep 2018, at 21:42, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > In Pharo 7 there were changes applied to rework the streams. I understand that we might have > reasons to change it - but to me this looks incomplete and not finished. > > For instance "FileStream" is a deprecated class - but still a lot of code in the > image is referencing it instead, > > Is there a guide or plan for all these methods being reworked to use a (hopefully > compatible) alternative. > > Can anyone involved in this topic give an update on the status? Yes, the transition is incomplete. There is an umbrella issue somewhere. Not all of it is easy ... > Thanks > T. >

Sept. 6, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Sven Van Caekenberghe

> On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > A question to those who worked on the new streams for Pharo 7: > > > In PHARO 6 I used the following expression to open a file dialog and let the user choose > a binary file: > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > This returned > - either nil (when file dialog was canceled) > - a "MultiByteFileStream" instance when a file was selected > > The MultiByteFileStream instance already had the name of the file (= full path) and I was > able to query it for further use: > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > s name inspect > > (for instance to display which file is processed in a window by showing the full path) > > > > Now in PHARO 7 same expression returns an instance of ZnCharacterReadStream (as MultiByteFileStream > is deprecated): > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > and ZnCharacterReadStream does not understand #name - and in fact the info about the name is > totally lost/not available. To me this looks missing/broken. > > So what is the recommended way in Pharo 7 to open a file dialog, let the use choose a file > and get a file stream but also the name? IMHO this is either broken or missing... > > Thanks > T. It should return a FileReference, not an open stream. I believe there are methods that do that. But that is an incompatible API change (same selector, different return type). So hard to decide.

Sept. 6, 2018

Re: [Pharo-dev] [Moose-dev] Re: [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

by Nick Papoylias

On Thu, Sep 6, 2018 at 9:28 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Bloc is a new world and the intention is to build a new stack on it. It > can be embedded in Morphic, This will have to do for now ;) Thanx for your great efforts ! > but not the other way around. Higher level frameworks, like Spec would > have to build a renderer for Bloc. > Cheers, > Doru > > > > > On Sep 6, 2018, at 8:45 PM, Nick Papoylias <npapoylias(a)gmail.com> wrote: > > > > Thanx Doru ! > > > > Any pointers on embeding Morphs/Specs/RTViews to the > > new GT tools (and vice versa), if possible ? > > > > I am looking to achive smth similar to what Johan and Stef did > > on Sec 9.1 of the Spec Book: "Integrating the different UI frameworks", > > but with the Bloc version of GT. > > > > > > > > On Thu, Sep 6, 2018 at 8:24 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Nice job! > > > > Doru > > > > > > > > > On Sep 6, 2018, at 8:10 PM, Nick Papoylias <npapoylias(a)gmail.com> > wrote: > > > > > > Some of this tech, will soon make it to Cormas ;) > > > > > > So we can work together to make it even better ! > > > > > > Best, > > > > > > Nick > > > > > > On Thu, Sep 6, 2018 at 7:59 PM HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > Impressive work! > > > > > > Congratulations Nick. > > > > > > Cheers, > > > > > > HernÃ¡n > > > > > > 2018-09-06 14:17 GMT-03:00 Nick Papoylias <npapoylias(a)gmail.com>: > > > > A nice example of how Pharo can be used for > > > > domain-specific modeling and simulation. Short > > > > session from one of our projects at Rochelle: > > > > > > > > https://www.youtube.com/watch?v=Z7wJNhAIaVQ > > > > > > > > Some additional info here: https://goo.gl/jS4NjB > > > > > > > > Currently investigating how to incorporate the new Bloc based > > > > widgets of @feenkcom into the workflow. > > > > > > > > Cheers, > > > > > > > > Nick > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups > > > > "cormas-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, > send an > > > > email to cormas-dev+unsubscribe(a)googlegroups.com. > > > > To post to this group, send email to cormas-dev(a)googlegroups.com. > > > > To view this discussion on the web visit > > > > > https://groups.google.com/d/msgid/cormas-dev/CACEStOjqbQt96qeae_4Nsf%3DEBqr… > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "cormas-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to cormas-dev+unsubscribe(a)googlegroups.com. > > > To post to this group, send email to cormas-dev(a)googlegroups.com. > > > To view this discussion on the web visit > https://groups.google.com/d/msgid/cormas-dev/CAKHmnHuSE38ureMsiAO5gHj5AJVzk… > . > > > For more options, visit https://groups.google.com/d/optout. > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > -- > > www.feenk.com > > > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > âThe smaller and more pervasive the hardware becomes, the more physical > the software gets." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Sept. 6, 2018