- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Playground

by Alexandre Bergel

Hi Kilon, Yesterday, at a conference in software engineering, someone shown a new programming environment and made an experiment with users. The authors have shown that users with the _most experience_ in programming technologies are the most negative users. On the opposite, users with less experience in programming environment enjoyed it very much. Your email clearly goes in the first pattern. At the beginning I was also in the same situation: I could not make up my mind with GT. Including GT in Pharo is really what could happen the best of our future. Alexandre On Oct 2, 2014, at 12:19 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Is it just me or is the Playground a big step back in the usability of Pharo ? > > For me its Gui makes no sense. Gone is the right click menu which had tons of useful actions now you only get like a few options. The tab thing is weird to say the least with the navigation of the tabs being in the opposite side (bottom) of the navigation of the internal tabs(top). No more right arrow menu for shortcuts and many features that workspace had. No ability to resize the panel tabs . Weird terminolgy like "All ref" and "Meta". Meta tab you have to select the first item and then the other first item and then it displays fully . > > Also how one closes a tab panel ? Is it possible ? I tried everything but i cant get them to close. > > I click a method and instead of opening a panel on the bottom for the source as I would expect ,make my workspace area disappear and create a new panel that sends me to state, whatever this is. Then I have to click on the source tab. This is one of the most annoying guis I have used in an IDE. > > Ironically the meta tab has got this right , name of class - method names and source of methods . On the instance side tab there is a different kind of thinking , why ? > > Also the inspector seems to get in some kind of loop opening forever panels when it finds a dead end in its inspection.For example clicking self. > > It has some good ideas in it, but I dont like the execution. > > The big loss for me is the inability to create windows groups, this functionality provided a very nice solution to the windows mess of pharo. I can name my groups but also the individual windows and so the tabs have short names that I know what they are and names of course I can customise. > > I can disable it via settings but maybe I am missing something here, a some kind of usefulness because I don't understand or don't know how to use it properly. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 2, 2014

Playground

by kilon alios

Is it just me or is the Playground a big step back in the usability of Pharo ? For me its Gui makes no sense. Gone is the right click menu which had tons of useful actions now you only get like a few options. The tab thing is weird to say the least with the navigation of the tabs being in the opposite side (bottom) of the navigation of the internal tabs(top). No more right arrow menu for shortcuts and many features that workspace had. No ability to resize the panel tabs . Weird terminolgy like "All ref" and "Meta". Meta tab you have to select the first item and then the other first item and then it displays fully . Also how one closes a tab panel ? Is it possible ? I tried everything but i cant get them to close. I click a method and instead of opening a panel on the bottom for the source as I would expect ,make my workspace area disappear and create a new panel that sends me to state, whatever this is. Then I have to click on the source tab. This is one of the most annoying guis I have used in an IDE. Ironically the meta tab has got this right , name of class - method names and source of methods . On the instance side tab there is a different kind of thinking , why ? Also the inspector seems to get in some kind of loop opening forever panels when it finds a dead end in its inspection.For example clicking self. It has some good ideas in it, but I dont like the execution. The big loss for me is the inability to create windows groups, this functionality provided a very nice solution to the windows mess of pharo. I can name my groups but also the individual windows and so the tabs have short names that I know what they are and names of course I can customise. I can disable it via settings but maybe I am missing something here, a some kind of usefulness because I don't understand or don't know how to use it properly.

Oct. 2, 2014

Re: [Pharo-dev] Pharo days: date proposal

by CÃ©drick BÃ©ler

same day ^^ 2014-10-02 16:55 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Cool and the 31 we do my bday party. I love the idea! :D > > On Thu, Oct 2, 2014 at 4:54 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi pharoers and others happy hackers >> >> we would like to organize PharoDays a two days gathering mix between a >> conference and a huge sprint. >> We thought that the 29 and 30 of January 2015 is a good date. >> Now before launching the organization process we would like to know if >> there is not a huge conflict that >> we did not see. >> >> Stef on the behalf of the Pharo board >> >> > -- CÃ©drick

Oct. 2, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 2, 2014

[pharo-project/pharo-core] dcda09: 40278

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: dcda09a5d51ad3e6251169d21034861a03f31042 https://github.com/pharo-project/pharo-core/commit/dcda09a5d51ad3e6251169d2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-02 (Thu, 02 Oct 2014) Changed paths: M GroupManagerUI.package/DialogGroupAdderUI.class/instance/build items/text.st M HudsonBuildTools20.package/HDLintReport.class/instance/generating/generateClass_on_.st M HudsonBuildTools20.package/HDLintReport.class/instance/running/run.st M NECompletion.package/NECContext.class/instance/private-type-guessing/nonAbstractTypeOf_.st M Refactoring-Tests-Core.package/RBExtractMethodTest.class/instance/tests/testExtractMethodThatMovesTemporaryVariable.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script278.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40278.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40278 13718 Failing test: RBExtractMethodTest>>#testExtractMethodThatMovesTemporaryVariable https://pharo.fogbugz.com/f/cases/13718 13222 HDLintReport generates invalid output https://pharo.fogbugz.com/f/cases/13222 12774 DialogGroupAdderUI "item to add" list should be sorted, has superfluous periods after class names https://pharo.fogbugz.com/f/cases/12774 14134 ecompletion raises DNU for some input https://pharo.fogbugz.com/f/cases/14134 http://files.pharo.org/image/40/40278.zip

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by CÃ©drick BÃ©ler

FTI, as a complement, here is the web site where I found all the information about doing a SMS Gateway : http://domotique-info.fr/2014/01/un-script-python-comme-serveur-sms/ (french) https://translate.google.fr/translate?hl=fr&sl=auto&tl=en&u=http%3A%2F%2Fdo… Several parts can be done un smalltalk ... but using a NAS Synology, I'm quite forced to use Python (at least on the NAS) but once the bridge is done to use web request, one could use Pharo tu use the SMS Server. Still not happy with the PHP part though... Cheers, CÃ©drick 2014-10-02 16:40 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > Hi all, > > This is actually doable to use a POST request instead of a GET. > > ZnClient new > url: 'https://smsapi.free-mobile.fr/sendmsg'; > queryAt: #user put: '12345'; > queryAt: #pass put: 'sqsdqsfzedfqsd'; > queryAt: #msg put: 'Hi again From Pharo Ã©@Ã¨!Â§'; > post. > > Tested OK. > > BTW, I'm using a GSM modem with Gnokii deamon to use it as a SMS server on > a NAS Synology. The problem with the smsapi proposed before is that it can > only send to your mobile and it has a dependance on the internet connection. > > This is a more universal option, but then it's far more tricky to > interface. I right now use a script in python to expose a "webservice" url > so send message... But I need a better way to do it (my aim is to be able > to have a communication channel other than email so that I can send group > message, query and treat responses (YES NO...)). > > > Cheers, > > CÃ©drick > > > > 2014-10-02 15:34 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> >> Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> On 02 Oct 2014, at 15:19, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com >> >: >> >> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> >> ps: It is funny they use GET to send a message. :) >> >> >> I was going to comment on that as well. For an action, the common REST >> practice dictates doing a POST. GET is to request the contents of something. >> >> Putting authentication in headers is also better, because it is more >> orthogonal. >> >> In full REST speak, you POST to a /sender resource which creates a new >> resource like /sms/123123 which you can then query for state (because it >> can take a while to determine success of failure) - this could also contain >> delivery timestamp, number of retries, proof of delivery and full contents >> for future/historic reference. >> >> >> Exactly! >> >> GET (and HEAD) should be idempotent, so two identical GET requests >> shouldn't >> cause any resource/server state modification. [1] >> >> That's not true. It should not modify the resource identified by the URI. >> But is still possible to have side effects. Otherwise a GET request that >> produces a line in a logfile would be impossible, right? >> >> >> Nothing you said is wrong (including your other mail), but for us, a log >> service where a GET would add data would not fly, that would definitively >> have to be a POST. >> >> Sure. I don't think we need to argue here because we would mostly agree >> on all those things. I just wanted to clarify my point by providing a >> simple example. The log I meant is that of a frontend web server like >> apache, that adds a line to a log file even on GET request. Just food for >> thought about a statement "â¦shouldn't cause any resource/server state >> modificationâ¦" >> >> Norbert >> >> But yes, it is more about design, not about what is forbidden, it is >> about conventions. The whole HTTP design is a bit unclear. >> >> And btw. all verbs are idempotent except PATCH and POST. >> >> Norbert >> >> Esteban A. Maringolo >> >> [1] We all now Seaside also breaks this rule by design (hence its >> "heretic" tagline), and there isn't any foreseeable way of changing >> this to comply with HTTP recommended usage. >> >> >> > > > -- > CÃ©drick > -- CÃ©drick

Oct. 2, 2014

Re: [Pharo-dev] Pharo days: date proposal

by Guillermo Polito

Cool and the 31 we do my bday party. I love the idea! :D On Thu, Oct 2, 2014 at 4:54 PM, stepharo <stepharo(a)free.fr> wrote: > Hi pharoers and others happy hackers > > we would like to organize PharoDays a two days gathering mix between a > conference and a huge sprint. > We thought that the 29 and 30 of January 2015 is a good date. > Now before launching the organization process we would like to know if > there is not a huge conflict that > we did not see. > > Stef on the behalf of the Pharo board > >

Oct. 2, 2014

Pharo days: date proposal

by stepharo

Hi pharoers and others happy hackers we would like to organize PharoDays a two days gathering mix between a conference and a huge sprint. We thought that the 29 and 30 of January 2015 is a good date. Now before launching the organization process we would like to know if there is not a huge conflict that we did not see. Stef on the behalf of the Pharo board

Oct. 2, 2014

Re: [Pharo-dev] GT Playground/Inspect window menu

by Tudor Girba

Hi, The menu is consciously not there. The reason for that goes as follows: by default in Morphic every window gets the generic menu that nobody really uses, but some windows also put in there dedicated menu entries like the "show previous contents" from the old Workspace. The problem is that you have no chance of knowing which window actually hold useful entries from outside. That is why in Glamour you have to have a window specific action in order to get the menu at all. About save/load, this feature will come in some form. About the tabs: every presentation that has a title is shown like a tab. It is actually true that we would like to have multiple tabs, but we did not get to a proper solution yet :). Cheers, Doru On Thu, Oct 2, 2014 at 4:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > I've noticed that the window menu (in top right corner) is missing when I > create the window for the first time. But if I drag it inside window group > and then take it out it appears, in inspector's case it replaces the update > button with window menu button. > > The window group content was more rich in Workspace; the open / save > functionality in particular. (But maybe I was the last person using it and > I should use ScriptManager instead). > > The last thing... the top part looks like a Tab, so is it possible to add > second Playground next to it instead of using groups? > > And now to spend the rest of the day playing with it all, it looks amazing > ^^. > > Peter > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by CÃ©drick BÃ©ler

Hi all, This is actually doable to use a POST request instead of a GET. ZnClient new url: 'https://smsapi.free-mobile.fr/sendmsg'; queryAt: #user put: '12345'; queryAt: #pass put: 'sqsdqsfzedfqsd'; queryAt: #msg put: 'Hi again From Pharo Ã©@Ã¨!Â§'; post. Tested OK. BTW, I'm using a GSM modem with Gnokii deamon to use it as a SMS server on a NAS Synology. The problem with the smsapi proposed before is that it can only send to your mobile and it has a dependance on the internet connection. This is a more universal option, but then it's far more tricky to interface. I right now use a script in python to expose a "webservice" url so send message... But I need a better way to do it (my aim is to be able to have a communication channel other than email so that I can send group message, query and treat responses (YES NO...)). Cheers, CÃ©drick 2014-10-02 15:34 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 02 Oct 2014, at 15:19, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com > >: > > 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > ps: It is funny they use GET to send a message. :) > > > I was going to comment on that as well. For an action, the common REST > practice dictates doing a POST. GET is to request the contents of something. > > Putting authentication in headers is also better, because it is more > orthogonal. > > In full REST speak, you POST to a /sender resource which creates a new > resource like /sms/123123 which you can then query for state (because it > can take a while to determine success of failure) - this could also contain > delivery timestamp, number of retries, proof of delivery and full contents > for future/historic reference. > > > Exactly! > > GET (and HEAD) should be idempotent, so two identical GET requests > shouldn't > cause any resource/server state modification. [1] > > That's not true. It should not modify the resource identified by the URI. > But is still possible to have side effects. Otherwise a GET request that > produces a line in a logfile would be impossible, right? > > > Nothing you said is wrong (including your other mail), but for us, a log > service where a GET would add data would not fly, that would definitively > have to be a POST. > > Sure. I don't think we need to argue here because we would mostly agree on > all those things. I just wanted to clarify my point by providing a simple > example. The log I meant is that of a frontend web server like apache, that > adds a line to a log file even on GET request. Just food for thought about > a statement "â¦shouldn't cause any resource/server state modificationâ¦" > > Norbert > > But yes, it is more about design, not about what is forbidden, it is about > conventions. The whole HTTP design is a bit unclear. > > And btw. all verbs are idempotent except PATCH and POST. > > Norbert > > Esteban A. Maringolo > > [1] We all now Seaside also breaks this rule by design (hence its > "heretic" tagline), and there isn't any foreseeable way of changing > this to comply with HTTP recommended usage. > > > -- CÃ©drick

Oct. 2, 2014