- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5

by Tudor Girba

Hi, Thanks for the reply. My reply is inlined below. It might appear that we are contradicting each other, but I am actually sure we are not :). > On Nov 4, 2015, at 11:54 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Doru, > > yes - but the concept of moldable tools is nothing new for Smalltalk - it's a long tradition. > Even in Java world we have them (NetBeans and Eclipse can be adopted to own needs as well). > The GT inspector with the tabs is similar to the known concept of custom inspectors in Smalltalk > and custom views in Eclipse. Almost, but not really :). Moldability means to have the tools and the mechanisms behind be extensible with little cost and ideally during usage. The tiny difference lies in the cost. Indeed, inspectors have been extensible in Smalltalk systems for a long time. But, if this would be enough why were there so few extensions before and why are there so many now? > The #act: methods who provide the buttons usually care on the current > GT presentation. In Eclipse one has explicit extension points so I can even add a button on > another tab view easily. > > Dont know how this can currently be done in GT tools as usually now a single extension method > represents the whole composite with the menues, context menues, â¦ In the current design, the actions of a presentation are defined within that presentation. If the presentation thinks it wants to be extensible, which is not the case for most presentations, it is the responsibility of that presentation to provide the extension points. As I said, it is so cheap now to create a new presentation that it is perhaps less worthwhile to introduce many way of extending to the detriment of understanding (people that have tried to debug Eclipse RCP projects might attest to the less than comfortable experience :)) However, the object actions can be customized by each class using the <gtInspectorAction> pragma. A concept that we have in Moose is that of a menu attached to each object. This is something that we would like to add to GT as well. > Also there are more concepts abstracted away in Eclipse (workbench, perspectives, actions, ...) > that allow one to customize the whole IDE for a rich client platform. Eclipse perspectives correspond to browsers in Pharo. > For sure it is easier to lively inspect/provide code in Pharo with less LOC than in Java. And yes > I know that in Eclipse there is a gap because extensions require a bad mix of XML and code in the > plugins and all that is based on a language with dead code in text files ;) This matters. In Pharo we have the opportunity to push the envelope significantly further than any other environment. And we have just started. I would like to see more innovation in this field. > Small issues I've found: > - the tabs constantly display a "a MyClass" followed by the #gtDisplayString in parantheses - > havent found where to adopt this > - I was not able to find out quickly how to avoid the "Browse" button at the top These ones are not being customizable because that need did not exist until now. Regarding the label: this one is decided by the object. In your case, you would like to specialize them depending on the inspector. Regarding object actions: you can find the list of current actions in: Object>>gtInspectorActions Both of these are being directly called from: GTInspector>>composite In both of these cases, we could imagine a double dispatch based on the inspector, or at least an extra hook that can be customized by Inspector subclasses. However, I would rather take a different route. The original idea was that if you need a browser that wants to do other things than what the inspector does, you simply create one using a Glamour Finder. That is why we wanted to keep the inspector code as small as possible. In the meantime that code of the GTInspector class reached 252 lines of code, which starts to be too much, and we should consider adding hooks to it, or to slim it down. > There is a much better approach/alternative to the way we do it now with less coding ... but I > can not talk about that further. Not yet ;) Ok :) Doru > Bye > T. > >> Gesendet: Mittwoch, 04. November 2015 um 23:09 Uhr >> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >> An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5 >> >> Hi, >> >> Nice work! >> >> I love the details you went through to implement this, especially given that the UI is just a custom inspector. Itâs naked objects on steroids :). >> >> I think this is a beautiful use case for moldable tools. It shows that once the cost of tools drops, unforeseen solutions will emerge. We need to focus on more support to make more things like this possible. >> >> Cheers, >> Doru >> >> >>> On Nov 4, 2015, at 10:35 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi, >>> >>> I quickly wrote yet another small tool to work faster with Pharo. I call it >>> "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you >>> to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc. >>> >>> You can load it from Spotter/Catalog in Pharo 5.0 beta. >>> >>> The following video demonstrates how to use it: >>> >>> http://youtu.be/j-dTp6i_P3s >>> >>> The defined structure including the scripts can be exported to a file >>> and send around. So far it is "complete" for my own requirements - if you >>> feel something is missing you can contribute and help moving it forward. >>> >>> The repo is at http://www.smalltalkhub.com/#!/~TorstenBergmann/QuickAccess >>> Contact me with your STHub account if you need access. >>> >>> The tool has some similarities with Playground/script cache, but GT tools >>> lack the category structuring for scripts that you find in QuickAccess. >>> It might be an inspiration for a future unified script management solution >>> in Playground. >>> >>> Have fun! >>> >>> Bye >>> T. >>> >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> > -- www.tudorgirba.com "Presenting is storytelling."

Nov. 5, 2015

[pharo-project/pharo-core] d43bb8: 50419

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d43bb88223b01f7733b72825998951c758b7166b https://github.com/pharo-project/pharo-core/commit/d43bb88223b01f7733b72825… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-05 (Thu, 05 Nov 2015) Changed paths: M Collections-Unordered.package/Dictionary.class/README.md A Monticello.package/MCRepositoryAdded.class/README.md A Monticello.package/MCRepositoryAdded.class/definition.st A Monticello.package/MCRepositoryAdded.class/instance/accessing/repository.st A Monticello.package/MCRepositoryAdded.class/instance/accessing/repository_.st M Monticello.package/MCRepositoryGroup.class/instance/accessing/removeRepository_.st M Monticello.package/MCRepositoryGroup.class/instance/adding/addBasicRepository_.st A Monticello.package/MCRepositoryGroup.class/instance/private/announceRepositoryAdded_.st A Monticello.package/MCRepositoryGroup.class/instance/private/announceRepositoryRemoved_.st A Monticello.package/MCRepositoryRemoved.class/README.md A Monticello.package/MCRepositoryRemoved.class/definition.st A Monticello.package/MCRepositoryRemoved.class/instance/accessing/repository.st A Monticello.package/MCRepositoryRemoved.class/instance/accessing/repository_.st M Monticello.package/MCStReader.class/instance/reading/commentStampFor_.st M Monticello.package/MCStReader.class/instance/reading/typeOfSubclass_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/addRepository_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/initialization/initialize.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/initialization/registerToAnnouncer.st A MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/updating/updateRepositoryList.st M Ring-Core-Kernel.package/extension/ChangeRecord/instance/createMethodDefinition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50418.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50419.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50418.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50419.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50419 16931 wrong "method class" for trait methods from a trait method changerecord https://pharo.fogbugz.com/f/cases/16931 16489 Monticello browser doesnt update others after adding repo https://pharo.fogbugz.com/f/cases/16489 16743 MCStReader cannot read trait definitions https://pharo.fogbugz.com/f/cases/16743 16910 Improve Dictionary comment https://pharo.fogbugz.com/f/cases/16910 http://files.pharo.org/image/50/50419.zip

Nov. 5, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 5, 2015

Re: [Pharo-dev] [ANN] QuickAccess for Pharo 5

by Stephan Eggermont

On 04-11-15 22:35, Torsten Bergmann wrote: > I quickly wrote yet another small tool to work faster with Pharo. I call it > "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you > to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc. Excellent! Stephan

Nov. 5, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5

by Torsten Bergmann

Hi Doru, yes - but the concept of moldable tools is nothing new for Smalltalk - it's a long tradition. Even in Java world we have them (NetBeans and Eclipse can be adopted to own needs as well). The GT inspector with the tabs is similar to the known concept of custom inspectors in Smalltalk and custom views in Eclipse. The #act: methods who provide the buttons usually care on the current GT presentation. In Eclipse one has explicit extension points so I can even add a button on another tab view easily. Dont know how this can currently be done in GT tools as usually now a single extension method represents the whole composite with the menues, context menues, ... Also there are more concepts abstracted away in Eclipse (workbench, perspectives, actions, ...) that allow one to customize the whole IDE for a rich client platform. For sure it is easier to lively inspect/provide code in Pharo with less LOC than in Java. And yes I know that in Eclipse there is a gap because extensions require a bad mix of XML and code in the plugins and all that is based on a language with dead code in text files ;) Small issues I've found: - the tabs constantly display a "a MyClass" followed by the #gtDisplayString in parantheses - havent found where to adopt this - I was not able to find out quickly how to avoid the "Browse" button at the top There is a much better approach/alternative to the way we do it now with less coding ... but I can not talk about that further. Not yet ;) Bye T. > Gesendet: Mittwoch, 04. November 2015 um 23:09 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5 > > Hi, > > Nice work! > > I love the details you went through to implement this, especially given that the UI is just a custom inspector. Itâs naked objects on steroids :). > > I think this is a beautiful use case for moldable tools. It shows that once the cost of tools drops, unforeseen solutions will emerge. We need to focus on more support to make more things like this possible. > > Cheers, > Doru > > > > On Nov 4, 2015, at 10:35 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > I quickly wrote yet another small tool to work faster with Pharo. I call it > > "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you > > to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc. > > > > You can load it from Spotter/Catalog in Pharo 5.0 beta. > > > > The following video demonstrates how to use it: > > > > http://youtu.be/j-dTp6i_P3s > > > > The defined structure including the scripts can be exported to a file > > and send around. So far it is "complete" for my own requirements - if you > > feel something is missing you can contribute and help moving it forward. > > > > The repo is at http://www.smalltalkhub.com/#!/~TorstenBergmann/QuickAccess > > Contact me with your STHub account if you need access. > > > > The tool has some similarities with Playground/script cache, but GT tools > > lack the category structuring for scripts that you find in QuickAccess. > > It might be an inspiration for a future unified script management solution > > in Playground. > > > > Have fun! > > > > Bye > > T. > > > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > >

Nov. 4, 2015

Re: [Pharo-dev] [Vm-dev] hello

by SebastiÃ¡n Krynski

Hi Eliot, I'm sorry for the delay, I seem to have missed this email. Just to put you in context, the idea of implementing this operator came from Igor. I think the goals are being able to implement lock free algorithms so in the future we can have real concurrent threads. I'll make sure to read the works you suggested. About the communication, I will write different mails one per list (pharodev, squeakdev ,squeakvm and rmod). Is that ok? By the way,this is for my Phd (I'm just starting) Seba 2015-10-12 16:04 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi SebastiÃ¡n, > > and welcome! Forgive me for not replying earlier. > > On Mon, Oct 12, 2015 at 4:54 AM, SebastiÃ¡n Krynski <skrynski(a)gmail.com> > wrote: > >> >> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >> Just writing to let you know that I'm starting to work on adding an >> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >> The operator will be used this way: >> >> a :=: b >> >> meaning 'swap variable a with variable b'. >> In order to do this I will be modifying the VM and the Compiler . >> >> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >> > > Give my regards to Gabriela! > > One thing is to consider multiple approaches. My friend Maurice Rabb (in > the cc line) did a concurrent VM for a smalltalk-like language a few years > ago now and he used something more akin to compare-and-swap. e.g. > > var ?= value := expr > > would set var to expire if it held the value var and answer true, > otherwise it would not change the value of var and answer false. > > Talk also to Igor Stasenko (also in the cc line) who has thought a lot > about this and has written a prototype image-level scheduler based on > (IIRC) a couple of different atomic operators. > > Another thing to think about is goals. Making it convenient to implement > lock-free data structures such as a lock-free thread-safe dictionary would > be very good. Make sure you look at Cliff Click's work, e.g. at Azul such > as A Lock-Free, Wait-Free Hash Table > <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB4QFj…>. > Google cliff click azul lock-free data structures > <https://www.google.com/search?client=safari&rls=en&q=cliff+click+azul+lock-…> > . > > Finally, decide where you want to discuss this. My preference is for you > to at least include vm-dev, since this is definitely to do with the byte > code set and the VM. But the data structure piece and the use is more > generally useful. So I see no problem including vm-dev, pharos-dev and the > general purpose squeak list. The more the merrier. > > > A couple of questions: How long will your work with Gabriela last? Is > this a master's project or a PhD or...? > > Good luck! > _,,,^..^,,,_ > best, Eliot > >

Nov. 4, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5

by Tudor Girba

Hi, Nice work! I love the details you went through to implement this, especially given that the UI is just a custom inspector. Itâs naked objects on steroids :). I think this is a beautiful use case for moldable tools. It shows that once the cost of tools drops, unforeseen solutions will emerge. We need to focus on more support to make more things like this possible. Cheers, Doru > On Nov 4, 2015, at 10:35 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > I quickly wrote yet another small tool to work faster with Pharo. I call it > "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you > to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc. > > You can load it from Spotter/Catalog in Pharo 5.0 beta. > > The following video demonstrates how to use it: > > http://youtu.be/j-dTp6i_P3s > > The defined structure including the scripts can be exported to a file > and send around. So far it is "complete" for my own requirements - if you > feel something is missing you can contribute and help moving it forward. > > The repo is at http://www.smalltalkhub.com/#!/~TorstenBergmann/QuickAccess > Contact me with your STHub account if you need access. > > The tool has some similarities with Playground/script cache, but GT tools > lack the category structuring for scripts that you find in QuickAccess. > It might be an inspiration for a future unified script management solution > in Playground. > > Have fun! > > Bye > T. > -- www.tudorgirba.com "Obvious things are difficult to teach."

Nov. 4, 2015

[ANN] QuickAccess for Pharo 5

by Torsten Bergmann

Hi, I quickly wrote yet another small tool to work faster with Pharo. I call it "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc. You can load it from Spotter/Catalog in Pharo 5.0 beta. The following video demonstrates how to use it: http://youtu.be/j-dTp6i_P3s The defined structure including the scripts can be exported to a file and send around. So far it is "complete" for my own requirements - if you feel something is missing you can contribute and help moving it forward. The repo is at http://www.smalltalkhub.com/#!/~TorstenBergmann/QuickAccess Contact me with your STHub account if you need access. The tool has some similarities with Playground/script cache, but GT tools lack the category structuring for scripts that you find in QuickAccess. It might be an inspiration for a future unified script management solution in Playground. Have fun! Bye T.

Nov. 4, 2015

Re: [Pharo-dev] Measuring width string

by Stephan Eggermont

On 04/11/15 15:51, Aliaksei Syrel wrote: > Ok, answer is quite simple. > Current string rendering on athens does not support kerning. Because it > is not cairo's job. Kerning should be took into account _after_ creating > glyphs with cairo but _before_ extent measurement and obviously > rendering. It can be done with FreeType. > I made small refactoring of text measurement and added kerning support. Really nice. Stephan

Nov. 4, 2015

Resolving issue 16760

by monty

https://pharo.fogbugz.com/f/cases/16760/Dictionary-breaks-when-comparing-id… The newest fix that changes Dictionary>>= and related = methods to use species == tests can go in. or I can redo the older more complex fix that allows some cross class equality comparisons (like between Dictionary and SmallDictionary and between IdentityDictionary and OrderedIdentityDictionary). But the current behavior is clearly wrong and needs to be changed.

Nov. 4, 2015