- Pharo-users - lists.pharo.org

Trying to understand OSProcess on MacOS Yosemite

by Dimitris Chloupis

So I try to understand how OSProcess work exactly to find why filetree seems not able to use it and generating the error I already reported earlier. Using something simple like OSProcess command:'pwd' works great , I have the terminal open and I can see the correct return value of the command in my terminal but for some reason I can find no such info when I inspect the above example. So how exactly OSProcess returns the output of the terminal ? Is there an instance variable of some sort ? Because I tried to inspect it deeply and I found nothing . Can you help me understand how OSProcess work ? Because If I do understand it then I can find what the problem is .

Nov. 5, 2015

Re: [Pharo-users] Using Google service discovery API's with Pharo Smalltalk by Richard J. Prinz

by Sean P. DeNigris

Andy Burnett wrote > Using Google service discovery API's with Pharo Smalltalk by Richard J. > Prinz Cool! I noticed a small bug. GoogleGmailApiUsersMessages>>#send: does not accept an argument for the actual message. Maybe it has to do with that requirement is defined in the Message definition? "Message": { ... "raw": { ... "required": [ "gmail.users.drafts.create", "gmail.users.drafts.update", "gmail.users.messages.insert", "gmail.users.messages.send" ] } ----- Cheers, Sean -- View this message in context: http://forum.world.st/Using-Google-service-discovery-API-s-with-Pharo-Small… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 5, 2015

Re: [Pharo-users] Documentations for Garage

by Alexandre Bergel

Excellent! Go go go! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 5, 2015, at 8:54 AM, lionelakue(a)gmail.com wrote: > > Hello > I have attended a formation with Stephane Ducass in LomÃ©-Togo. And I am about to start a new project: an immobilier management application built in pharo with a pgsql database for a company here. > So I am looking for some Documentation on Garage. For the basic purposes: > -connection > -queries > -etc > Thank you

Nov. 5, 2015

Smalltalkhub password reset?

by Euan Mee

How do you get a password reset for a SmalltalkHub account? (I'm convinced the EuanM who has an account is me, but I cannot manage to log in)

Nov. 5, 2015

Documentations for Garage

by lionelakue＠gmail.com

Hello I have attended a formation with Stephane Ducass in LomÃ©-Togo. And I am about to start a new project: an immobilier management application built in pharo with a pgsql database for a company here. So I am looking for some Documentation on Garage. For the basic purposes: -connection -queries -etc Thank you

Nov. 5, 2015

Re: [Pharo-users] [Pharo-dev] [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

Re: [Pharo-users] [Pharo-dev] [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-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-users] [ANN] Working with Pharo on the Raspberry Pi

by th72＠dds.nl

I use the vm already installed on the RPI. That works fine with pharo 5 image, not with pharo 4. There is a problem with saving the image with a different name (save as). It's not possible to select / type a different name. Tim Sven Van Caekenberghe <sven(a)stfx.eu> schreef: >> On 04 Nov 2015, at 08:14, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> For me this combination worked and was faster than the one that >> I described in the article: >> >> => Image >> https://ci.inria.fr/pharo/job/Pharo-5.0-spur32/lastSuccessfulBuild/artifact… > > Since when is a Pharo Spur image ready for general consumption ? > >> => VM >> http://www.mirandabanda.org/files/Cog/VM/VM.r3427/cogspurlinuxhtARM-15.33.3… >> >> So I happily run Pharo 5 on the Pi now. >> >> Bye >> Torsten

Nov. 4, 2015