- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by serge.stinckwich＠gmail.com

Maybe on github: https://github.com/CARMinesDouai I would like to use PhaROS for a new project. I'm also interested to have access to last version ;-) EnvoyÃ© de mon iPhone > Le 24 dÃ©c. 2016 Ã 10:10, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > >> On 24 Dec 2016, at 10:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> http://car.mines-douai.fr/category/pharos/ >> >> no idea whatâs that status of all that, but I remember Santiago considered that version of Pharo as obsolete (but no idea if it was replaced). > > sorry: "that version of *PhaROS* obsolete". > >> >> Esteban >> >> >>> On 24 Dec 2016, at 09:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> Yes, i remember this.. But i never had a chance to look for details.. >>> Would be nice to hear what is there, since i complete noob with ROS :) >>> >>> Is Noury & others reading this mailing list? I thought they are.. >>> >>>> On 23 December 2016 at 17:15, stepharong <stepharong(a)free.fr> wrote: >>>> Hi igor >>>> >>>> Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago was working on it during 1,5 years. >>>> Noury Bouraqadi <noury.bouraqadi(a)mines-douai.fr> >>>> Luc Fabresse <luc.fabresse(a)gmail.com> >>>> >>>> Stef >>>> >>>> On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) >>>> i'm interested in any bits, starting from basic ones, >>>> since i'm gonna to work with it in closest future, so would be nice to use Pharo >>>> & stand on a shoulders of others, of course, to learn it fester and understand it better. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> >

Dec. 24, 2016

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by Esteban Lorenzano

> On 24 Dec 2016, at 10:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > http://car.mines-douai.fr/category/pharos/ <http://car.mines-douai.fr/category/pharos/> > > no idea whatâs that status of all that, but I remember Santiago considered that version of Pharo as obsolete (but no idea if it was replaced). sorry: "that version of *PhaROS* obsolete". > > Esteban > > >> On 24 Dec 2016, at 09:43, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: >> >> Yes, i remember this.. But i never had a chance to look for details.. >> Would be nice to hear what is there, since i complete noob with ROS :) >> >> Is Noury & others reading this mailing list? I thought they are.. >> >> On 23 December 2016 at 17:15, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: >> Hi igor >> >> Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago was working on it during 1,5 years. >> Noury Bouraqadi <noury.bouraqadi(a)mines-douai.fr <mailto:noury.bouraqadi@mines-douai.fr>> >> Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> >> >> Stef >> >> On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: >> >> Hi, >> >> i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) >> i'm interested in any bits, starting from basic ones, >> since i'm gonna to work with it in closest future, so would be nice to use Pharo >> & stand on a shoulders of others, of course, to learn it fester and understand it better. >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> >> >> >> -- >> Best regards, >> Igor Stasenko. >

Dec. 24, 2016

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by Esteban Lorenzano

http://car.mines-douai.fr/category/pharos/ <http://car.mines-douai.fr/category/pharos/> no idea whatâs that status of all that, but I remember Santiago considered that version of Pharo as obsolete (but no idea if it was replaced). Esteban > On 24 Dec 2016, at 09:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Yes, i remember this.. But i never had a chance to look for details.. > Would be nice to hear what is there, since i complete noob with ROS :) > > Is Noury & others reading this mailing list? I thought they are.. > > On 23 December 2016 at 17:15, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > Hi igor > > Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago was working on it during 1,5 years. > Noury Bouraqadi <noury.bouraqadi(a)mines-douai.fr <mailto:noury.bouraqadi@mines-douai.fr>> > Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> > > Stef > > On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > Hi, > > i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) > i'm interested in any bits, starting from basic ones, > since i'm gonna to work with it in closest future, so would be nice to use Pharo > & stand on a shoulders of others, of course, to learn it fester and understand it better. > > -- > Best regards, > Igor Stasenko. > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> > > > -- > Best regards, > Igor Stasenko.

Dec. 24, 2016

Re: [Pharo-dev] Epicea user experience report

by serge.stinckwich＠gmail.com

I prefer option 2 because Epicea name is not really important and means nothing for the beginner. What is really important in then world menu is the function. EnvoyÃ© de mon iPhone > Le 24 dÃ©c. 2016 Ã 09:35, stepharong <stepharong(a)free.fr> a Ã©crit : > > On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias <tinchodias(a)gmail.com> wrote: > > Ben, yes, please create the issues if you want, and I will try to implement them soon. I guess if they are mostly UI changes and categorized to "first impression count" or something like that, they can still be included in Pharo 6, no? > > yes > > > One thing to discuss: what do you think about the fact that... > - the "Session changes" displays the changes of multiple log files in the same list widget (silently concatenated), versus > - the "All changes" way of displaying, where the changes of each log file are separated. > > That was my main reason to keep two windows by separate. I had the impression that in some cases > - the user wants to see all changes together and he/she doesn't care in which log file the changes are written, while in other cases > - the user wants to know the log files and see how are they connected, because they have some meaning > What do you think of this? > BTW I don't like the file names... hints are welcome to improve it > > Martin > >> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman <btc(a)openinworld.com> wrote: >> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > Hi, >> > >> > I think I would prefer to not have to think about this choice at all when in the world menu level. The user interface from the Epicea window already allows me to switch between current session and all sessions, and usually the decision of what to look at is based on whether I find what I am looking for or not. So, rather then asking the user to think about it upfront, I would prefer to have one command that opens the Epicea window on the current session and allow the user to dive deeper. This would also imply that we would have only one command in the menu item. What do you think? >> >> Good point. I had a similar thought earlier. The individual Session >> Changes window is almost completely embedded in the All Sessions >> window, so the former seems superfluous. The <Monitor> and <+> buttons >> would need to be added to the All Sessions window, probably above the >> "sesssion" pane. >> >> Two additional things I think are required to facilitate this... >> 1. The left-pane of the All Sessions windows needs to update when a >> new session is created - per <+> button. >> 2. It would be useful if a new session was created "when the image >> opened" rather than when a change is made, so that it can be >> preselected in the left-side pane when a fresh image is opened. But >> the file shouldn't be created until the first change, for the case >> like a web service image being invoked multiple times a second. >> >> Also one other request, That the current-session be tagged "Current" >> rather than just "Today". >> >> I can log issues if they all sound reasonable. >> >> cheers -ben >> >> > >> >> On Dec 20, 2016, at 10:16 PM, stepharong <stepharong(a)free.fr> wrote: >> >> >> >> I like the second because it associates the name with the function. >> >> >> >> Stef >> >> >> >> >> >> Hi all, >> >> >> >> One point of Ben's feedback is how Epicea code changes tool is presented in the World Menu. Below you can see the current state + 3 options to discuss it. >> >> >> >> >> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current state] >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 2. Attach purpose to the name: "Epicea Code Changes" >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 3. Just "Code Changes" + rephrase children: >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 4. Flatten >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> >> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a description of the tool and it's model. >> >> >> >> Cheers. >> >> Martin >> >> >> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hello Ben, >> >> >> >> About discussion points in 2 (a, b and c): I agree with your arguments... somebody that just moved from Pharo 5 to 6 and crashed an image will look for a "Recover lost changes" in the menu and can have a problem to discover it the replacement in a World->Tools->Epicea->... entry. >> >> >> >> Then, as a first step we could flatten the 2 menu entries and then at least anybody will easily find an entry related to changes in World->Tools. >> >> >> >> Second, we could try to merge both Epicea GUIs into one (suggestions are welcome). >> >> >> >> I still have to read more in detail the remaining of your report to answer. Anyway, thanks a lot for it. >> >> >> >> Cheers, >> >> Martin >> >> >> >> >> >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> 1. Created fresh Pharo image (build 60269) >> >> >> >> >> >> 2. Opened World > Tools > Epicea > All changes >> >> >> >> Points for discussion... >> >> >> >> a. How many submenu items are expected for Epicea? Can we push the >> >> current ones up so the Tools menu remains a flat menu. >> >> >> >> b. Do we need the two current menu items? "Current session" is >> >> encompassed by "All changes"? What expectations do people have of how >> >> often they'll use the former rather than the latter? >> >> >> >> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >> >> "recover changes" for a crashed image, they'll be looking for that >> >> familiar feature name, not a new app name. Could the app name be left >> >> out or placed in brackets "Changes (Epicea)". >> >> >> >> btw, the interface looks really slick! nice work. >> >> >> >> >> >> 3. Opened World > System Browser. >> >> >> >> 4. Added package AAA >> >> All Changes window - no dynamic change. >> >> On <refresh>, still no change, i.e. no sessions >> >> #New All Changes window - not visible, no sessions. >> >> >> >> 5. Added class AA. >> >> All Changes window - no dynamic change. >> >> On <refresh>, shows new session with AAA & AA. >> >> >> >> 5. Added method... >> >> AA>a >> >> ^'something' >> >> Prompted for author, entered 'BenComan' >> >> All Changes window with session selected - dynamic update showing AA>>a. >> >> >> >> 6. Added package BBB. >> >> All Changes window - no dynamic update. >> >> On <refresh>, BBB still not visible in session. >> >> >> >> 7. Added class A to package AAA. >> >> All Changes window - dynamic update showing A. >> >> On <refresh>, BBB still not visible in session. >> >> >> >> 8. Added class BB to package BBB. >> >> All Changes window - dynamic update showing BBB & BB. >> >> >> >> a. Package creation event seems not handled properly, being only >> >> pushed through when a class is created in it. >> >> >> >> b. Since there is a dynamic update for class and method >> >> modifications, could the session creation also dynamically update it >> >> UI. >> >> >> >> ----------- >> >> 9. Killed the vm from command line >> >> $ ps -ef | grep pharo >> >> $ kill 29349 >> >> Restarted Pharo image >> >> >> >> 10. World > Tools > Epica > All changes. >> >> Authorship is inconsistent: >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'BenComan'. >> >> >> >> a. I understand this follows on from Author not being requested until >> >> the first method was defined. Did the old changes track the author of >> >> packages and classes at all? >> >> >> >> b. Since Epicea can track package and class authors, can we trigger >> >> the author prompt earlier for them? >> >> >> >> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >> >> and did <Apply Changes>. >> >> Prompted for author. Entered 'DrWho' >> >> Existing All Changes window - no change >> >> New All Changes window - shows new session with all six changes. >> >> Authorship is a little inconsistent: >> >> * AAA and AA have author 'Unknown'. >> >> * AA>>a, A, BBB, B have blank author. >> >> >> >> 12. Killed the vm from command line >> >> $ ps -ef | grep pharo >> >> $ kill 30696 >> >> Restarted Pharo image >> >> >> >> 13. World > Tools > Epica > All changes. >> >> Authorship is a little inconsistent: >> >> First session >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'BenComan'. >> >> Second session >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'DrWho'. >> >> >> >> a. Epicea changes are reapplied as the current author. This seems a >> >> semantic change from Pharo 5 where changes were reapplied as their >> >> original author. Is this accidental or by design? Can we have some >> >> community discussion on this point (I don't remember seeing any)? >> >> >> >> cheers -ben >> >> >> >> P.S. I'll wait to see what arises out of discussion before creating any issues. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Using Opera's mail client: http://www.opera.com/mail/ >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "In a world where everything is moving ever faster, >> > one might have better chances to win by moving slower." >> > >> > >> > >> > >> > >> > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/

Dec. 24, 2016

Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?

by Igor Stasenko

Yes, i remember this.. But i never had a chance to look for details.. Would be nice to hear what is there, since i complete noob with ROS :) Is Noury & others reading this mailing list? I thought they are.. On 23 December 2016 at 17:15, stepharong <stepharong(a)free.fr> wrote: > Hi igor > > Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago > was working on it during 1,5 years. > Noury Bouraqadi <noury.bouraqadi(a)mines-douai.fr> > Luc Fabresse <luc.fabresse(a)gmail.com> > > Stef > > On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > Hi, > > i wonder, are there any projects to run/connect Pharo with ROS(robot > operating system) > i'm interested in any bits, starting from basic ones, > since i'm gonna to work with it in closest future, so would be nice to use > Pharo > & stand on a shoulders of others, of course, to learn it fester and > understand it better. > > -- > Best regards, > Igor Stasenko. > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Best regards, Igor Stasenko.

Dec. 24, 2016

Re: [Pharo-dev] Epicea user experience report

by stepharong

On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias <tinchodias(a)gmail.com> wrote: > Ben, yes, please create the issues if you want, and I will try to > implement them soon. I guess if they are mostly UI changes and > categorized to "first impression count" or something like that, they > >can still be included in Pharo 6, no? yes > > One thing to discuss: what do you think about the fact that...- the > "Session changes" displays the changes of multiple log files in the same > list widget (silently concatenated), versus- the "All changes" way of > displaying, where the changes of each log file are separated. >That was my main reason to keep two windows by separate. I had the > impression that in some cases- the user wants to see all changes > together and he/she doesn't care in which log file the changes are > written, while in other cases > - the user wants to know the log files and see how are they connected, > because they have some meaning > What do you think of this? > BTW I don't like the file names... hints are welcome to improve it > > Martin > > On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman <btc(a)openinworld.com> wrote: >> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >>> Hi, >>> >>> I think I would prefer to not have to think about this choice at all >>> when in the world menu level. The user interface from the Epicea >>> window already allows me to switch between current >>session and all >>> sessions, and usually the decision of what to look at is based on >>> whether I find what I am looking for or not. So, rather then asking >>> the user to think about it upfront, I would >>prefer to have one >>> command that opens the Epicea window on the current session and allow >>> the user to dive deeper. This would also imply that we would have only >>> one command in the >>menu item. What do you think? >> >> Good point. I had a similar thought earlier. The individual Session >> Changes window is almost completely embedded in the All Sessions >> window, so the former seems superfluous. The <Monitor> and <+> buttons >> would need to be added to the All Sessions window, probably above the >> "sesssion" pane. >> >> Two additional things I think are required to facilitate this... >> 1. The left-pane of the All Sessions windows needs to update when a >> new session is created - per <+> button. >> 2. It would be useful if a new session was created "when the image >> opened" rather than when a change is made, so that it can be >> preselected in the left-side pane when a fresh image is opened. But >> the file shouldn't be created until the first change, for the case >> like a web service image being invoked multiple times a second. >> >> Also one other request, That the current-session be tagged "Current" >> rather than just "Today". >> >> I can log issues if they all sound reasonable. >> >> cheers -ben >> >>> >>>> On Dec 20, 2016, at 10:16 PM, stepharong <stepharong(a)free.fr> wrote: >>>> >>>> I like the second because it associates the name with the function. >>>> >>>> Stef >>>> >>>> >>>> Hi all, >>>> >>>> One point of Ben's feedback is how Epicea code changes tool is >>>> presented in the World Menu. Below you can see the current state + 3 >>>> options to discuss it. >>>> >>>> >>>> 1. "Epicea" main entry > "Session Changes" + "All Changes" children >>>> [current state] >>>> >>>> <Mail Attachment.png> >>>> >>>> >>>> 2. Attach purpose to the name: "Epicea Code Changes" >>>> >>>> <Mail Attachment.png> >>>> >>>> >>>> 3. Just "Code Changes" + rephrase children: >>>> >>>> <Mail Attachment.png> >>>> >>>> >>>> 4. Flatten >>>> >>>> <Mail Attachment.png> >>>> >>>> >>>> >>>> Reminder: In World Menu > Help > Help Browser > Epicea you can find a >>>> description of the tool and it's model. >>>> >>>> Cheers. >>>> Martin >>>> >>>> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchodias(a)gmail.com> >>>> wrote: >>>> Hello Ben, >>>> >>>> About discussion points in 2 (a, b and c): I agree with your >>>> arguments... somebody that just moved from Pharo 5 to 6 and crashed >>>> an image will look for a "Recover lost changes" in the >>menu and can >>>> have a problem to discover it the replacement in a >>>> World->Tools->Epicea->... entry. >>>> >>>> Then, as a first step we could flatten the 2 menu entries and then at >>>> least anybody will easily find an entry related to changes in >>>> World->Tools. >>>> >>>> Second, we could try to merge both Epicea GUIs into one (suggestions >>>> are welcome). >>>> >>>> I still have to read more in detail the remaining of your report to >>>> answer. Anyway, thanks a lot for it. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> >>>> wrote: >>>> 1. Created fresh Pharo image (build 60269) >>>> >>>> >>>> 2. Opened World > Tools > Epicea > All changes >>>> >>>> Points for discussion... >>>> >>>> a. How many submenu items are expected for Epicea? Can we push the >>>> current ones up so the Tools menu remains a flat menu. >>>> >>>> b. Do we need the two current menu items? "Current session" is >>>> encompassed by "All changes"? What expectations do people have of how >>>> often they'll use the former rather than the latter? >>>> >>>> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >>>> "recover changes" for a crashed image, they'll be looking for that >>>> familiar feature name, not a new app name. Could the app name be left >>>> out or placed in brackets "Changes (Epicea)". >>>> >>>> btw, the interface looks really slick! nice work. >>>> >>>> >>>> 3. Opened World > System Browser. >>>> >>>> 4. Added package AAA >>>> All Changes window - no dynamic change. >>>> On <refresh>, still no change, i.e. no sessions >>>> #New All Changes window - not visible, no sessions. >>>> >>>> 5. Added class AA. >>>> All Changes window - no dynamic change. >>>> On <refresh>, shows new session with AAA & AA. >>>> >>>> 5. Added method... >>>> AA>a >>>> ^'something' >>>> Prompted for author, entered 'BenComan' >>>> All Changes window with session selected - dynamic update showing >>>> AA>>a. >>>> >>>> 6. Added package BBB. >>>> All Changes window - no dynamic update. >>>> On <refresh>, BBB still not visible in session. >>>> >>>> 7. Added class A to package AAA. >>>> All Changes window - dynamic update showing A. >>>> On <refresh>, BBB still not visible in session. >>>> >>>> 8. Added class BB to package BBB. >>>> All Changes window - dynamic update showing BBB & BB. >>>> >>>> a. Package creation event seems not handled properly, being only >>>> pushed through when a class is created in it. >>>> >>>> b. Since there is a dynamic update for class and method >>>> modifications, could the session creation also dynamically update it >>>> UI. >>>> >>>> ----------- >>>> 9. Killed the vm from command line >>>> $ ps -ef | grep pharo >>>> $ kill 29349 >>>> Restarted Pharo image >>>> >>>> 10. World > Tools > Epica > All changes. >>>> Authorship is inconsistent: >>>> * AAA and AA have blank author >>>> * AA>>a, A, BBB, B have author 'BenComan'. >>>> >>>> a. I understand this follows on from Author not being requested until >>>> the first method was defined. Did the old changes track the author of >>>> packages and classes at all? >>>> >>>> b. Since Epicea can track package and class authors, can we trigger >>>> the author prompt earlier for them? >>>> >>>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >>>> and did <Apply Changes>. >>>> Prompted for author. Entered 'DrWho' >>>> Existing All Changes window - no change >>>> New All Changes window - shows new session with all six changes. >>>> Authorship is a little inconsistent: >>>> * AAA and AA have author 'Unknown'. >>>> * AA>>a, A, BBB, B have blank author. >>>> >>>> 12. Killed the vm from command line >>>> $ ps -ef | grep pharo >>>> $ kill 30696 >>>> Restarted Pharo image >>>> >>>> 13. World > Tools > Epica > All changes. >>>> Authorship is a little inconsistent: >>>> First session >>>> * AAA and AA have blank author >>>> * AA>>a, A, BBB, B have author 'BenComan'. >>>> Second session >>>> * AAA and AA have blank author >>>> * AA>>a, A, BBB, B have author 'DrWho'. >>>> >>>> a. Epicea changes are reapplied as the current author. This seems a >>>> semantic change from Pharo 5 where changes were reapplied as their >>>> original author. Is this accidental or by design? Can we have some >>>> community discussion on this point (I don't remember seeing any)? >>>> >>>> cheers -ben >>>> >>>> P.S. I'll wait to see what arises out of discussion before creating >>>> any issues. >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "In a world where everything is moving ever faster, >>> one might have better chances to win by moving slower." >>> >>> >>> >>> >>> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 24, 2016

Re: [Pharo-dev] Epicea user experience report

by Ben Coman

On Sat, Dec 24, 2016 at 2:46 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Ben, yes, please create the issues if you want, and I will try to implement > them soon. I guess if they are mostly UI changes and categorized to "first > impression count" or something like that, they can still be included in > Pharo 6, no? > > One thing to discuss: what do you think about the fact that... > - the "Session changes" displays the changes of multiple log files in the > same list widget (silently concatenated), versus Well the biggest thing is probably that I did not realise it did this. So this is a problem for intuitive use of the tool. Actually it seems adverse to show multiple sessions where "Session Changes" implies "This Session". > - the "All changes" way of displaying, where the changes of each log file > are separated. > > That was my main reason to keep two windows by separate. I had the > impression that in some cases > - the user wants to see all changes together and he/she doesn't care in > which log file the changes are written, while in other cases > - the user wants to know the log files and see how are they connected, > because they have some meaning > What do you think of this? You are right, that is useful feature. But I keep "intuitively wanting**" to do this is to multi-select sessions in the "All changes" window. My use case is yesterday playing with sockets, the image froze half way through saving (hung at blank white window). So after killing the pharo process, the Image would not open. So before recreating the Image in PharoLauncher, I copied the ombu-sessions folder and copied into a fresh Image folder and selected each session in turn. (So btw that was a nice benefit of epicea versus the changes file needing to be kept more in sync with image file.) I only had half a dozen sessions so it wasn't too much trouble. But potentially there could be a lot more sessions and being able to do them all at once would be useful. ** i.e. I didn't learn the first time I tried this and it didn't work, and found I accidentally tried doing it a few more times after that. > BTW I don't like the file names... hints are welcome to improve it Which file names do you mean? cheers -ben > > Martin > > On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > Hi, >> > >> > I think I would prefer to not have to think about this choice at all >> > when in the world menu level. The user interface from the Epicea window >> > already allows me to switch between current session and all sessions, and >> > usually the decision of what to look at is based on whether I find what I am >> > looking for or not. So, rather then asking the user to think about it >> > upfront, I would prefer to have one command that opens the Epicea window on >> > the current session and allow the user to dive deeper. This would also imply >> > that we would have only one command in the menu item. What do you think? >> >> Good point. I had a similar thought earlier. The individual Session >> Changes window is almost completely embedded in the All Sessions >> window, so the former seems superfluous. The <Monitor> and <+> buttons >> would need to be added to the All Sessions window, probably above the >> "sesssion" pane. >> >> >> Two additional things I think are required to facilitate this... >> 1. The left-pane of the All Sessions windows needs to update when a >> new session is created - per <+> button. >> 2. It would be useful if a new session was created "when the image >> opened" rather than when a change is made, so that it can be >> preselected in the left-side pane when a fresh image is opened. But >> the file shouldn't be created until the first change, for the case >> like a web service image being invoked multiple times a second. >> >> Also one other request, That the current-session be tagged "Current" >> rather than just "Today". >> >> I can log issues if they all sound reasonable. >> >> cheers -ben >> >> > >> >> On Dec 20, 2016, at 10:16 PM, stepharong <stepharong(a)free.fr> wrote: >> >> >> >> I like the second because it associates the name with the function. >> >> >> >> Stef >> >> >> >> >> >> Hi all, >> >> >> >> One point of Ben's feedback is how Epicea code changes tool is >> >> presented in the World Menu. Below you can see the current state + 3 options >> >> to discuss it. >> >> >> >> >> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children >> >> [current state] >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 2. Attach purpose to the name: "Epicea Code Changes" >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 3. Just "Code Changes" + rephrase children: >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> 4. Flatten >> >> >> >> <Mail Attachment.png> >> >> >> >> >> >> >> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a >> >> description of the tool and it's model. >> >> >> >> Cheers. >> >> Martin >> >> >> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchodias(a)gmail.com> >> >> wrote: >> >> Hello Ben, >> >> >> >> About discussion points in 2 (a, b and c): I agree with your >> >> arguments... somebody that just moved from Pharo 5 to 6 and crashed an image >> >> will look for a "Recover lost changes" in the menu and can have a problem to >> >> discover it the replacement in a World->Tools->Epicea->... entry. >> >> >> >> Then, as a first step we could flatten the 2 menu entries and then at >> >> least anybody will easily find an entry related to changes in World->Tools. >> >> >> >> Second, we could try to merge both Epicea GUIs into one (suggestions >> >> are welcome). >> >> >> >> I still have to read more in detail the remaining of your report to >> >> answer. Anyway, thanks a lot for it. >> >> >> >> Cheers, >> >> Martin >> >> >> >> >> >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> 1. Created fresh Pharo image (build 60269) >> >> >> >> >> >> 2. Opened World > Tools > Epicea > All changes >> >> >> >> Points for discussion... >> >> >> >> a. How many submenu items are expected for Epicea? Can we push the >> >> current ones up so the Tools menu remains a flat menu. >> >> >> >> b. Do we need the two current menu items? "Current session" is >> >> encompassed by "All changes"? What expectations do people have of how >> >> often they'll use the former rather than the latter? >> >> >> >> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >> >> "recover changes" for a crashed image, they'll be looking for that >> >> familiar feature name, not a new app name. Could the app name be left >> >> out or placed in brackets "Changes (Epicea)". >> >> >> >> btw, the interface looks really slick! nice work. >> >> >> >> >> >> 3. Opened World > System Browser. >> >> >> >> 4. Added package AAA >> >> All Changes window - no dynamic change. >> >> On <refresh>, still no change, i.e. no sessions >> >> #New All Changes window - not visible, no sessions. >> >> >> >> 5. Added class AA. >> >> All Changes window - no dynamic change. >> >> On <refresh>, shows new session with AAA & AA. >> >> >> >> 5. Added method... >> >> AA>a >> >> ^'something' >> >> Prompted for author, entered 'BenComan' >> >> All Changes window with session selected - dynamic update showing >> >> AA>>a. >> >> >> >> 6. Added package BBB. >> >> All Changes window - no dynamic update. >> >> On <refresh>, BBB still not visible in session. >> >> >> >> 7. Added class A to package AAA. >> >> All Changes window - dynamic update showing A. >> >> On <refresh>, BBB still not visible in session. >> >> >> >> 8. Added class BB to package BBB. >> >> All Changes window - dynamic update showing BBB & BB. >> >> >> >> a. Package creation event seems not handled properly, being only >> >> pushed through when a class is created in it. >> >> >> >> b. Since there is a dynamic update for class and method >> >> modifications, could the session creation also dynamically update it >> >> UI. >> >> >> >> ----------- >> >> 9. Killed the vm from command line >> >> $ ps -ef | grep pharo >> >> $ kill 29349 >> >> Restarted Pharo image >> >> >> >> 10. World > Tools > Epica > All changes. >> >> Authorship is inconsistent: >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'BenComan'. >> >> >> >> a. I understand this follows on from Author not being requested until >> >> the first method was defined. Did the old changes track the author of >> >> packages and classes at all? >> >> >> >> b. Since Epicea can track package and class authors, can we trigger >> >> the author prompt earlier for them? >> >> >> >> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >> >> and did <Apply Changes>. >> >> Prompted for author. Entered 'DrWho' >> >> Existing All Changes window - no change >> >> New All Changes window - shows new session with all six changes. >> >> Authorship is a little inconsistent: >> >> * AAA and AA have author 'Unknown'. >> >> * AA>>a, A, BBB, B have blank author. >> >> >> >> 12. Killed the vm from command line >> >> $ ps -ef | grep pharo >> >> $ kill 30696 >> >> Restarted Pharo image >> >> >> >> 13. World > Tools > Epica > All changes. >> >> Authorship is a little inconsistent: >> >> First session >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'BenComan'. >> >> Second session >> >> * AAA and AA have blank author >> >> * AA>>a, A, BBB, B have author 'DrWho'. >> >> >> >> a. Epicea changes are reapplied as the current author. This seems a >> >> semantic change from Pharo 5 where changes were reapplied as their >> >> original author. Is this accidental or by design? Can we have some >> >> community discussion on this point (I don't remember seeing any)? >> >> >> >> cheers -ben >> >> >> >> P.S. I'll wait to see what arises out of discussion before creating any >> >> issues. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Using Opera's mail client: http://www.opera.com/mail/ >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "In a world where everything is moving ever faster, >> > one might have better chances to win by moving slower." >> > >> > >> > >> > >> > >> >

Dec. 24, 2016

19489 Socket-GTInspector-Instance-of-LinkedList-did-not-understand-key

by Ben Coman

I've bumped into a minor glitch ticketed with the GTInspector embedded in the debugger. https://pharo.fogbugz.com/f/cases/19489 Henrik has kindly tried to reproduce it but was unable. But he is on Windows and I'm on Linux. Could someone on Linux take 10 minutes try to reproduce the following... Open fresh build 60334. Load the ST file attached to issue, then in playground, do this once... s := Server new. s start. "listens on port 9999" and this once for each trial... socket := Socket newTCP. [ socket connectTo: NetNameResolver localHostAddress port: 9999; sendData: 'test'. ] ensure: [ socket closeAndDestroy ] This brings up an expected debugger (okay) "ShouldBeImplemented: #newFromStream: should have been implemented in Packet class" >From top stack select Packet class>>newFromStream: then select variable aSocketStream, then in next pane, select #isConnected, then click on [Raw] tab, and I get an error "Instance of LinkedList did not understand #key" Now a few times the error did not occur, but did >90% of the time. cheers -ben

Dec. 24, 2016

Re: [Pharo-dev] Pharo 5 Catalog Down?

by Esteban Lorenzano

Crap, I will restart it when I arrive home :( > On 23 Dec 2016, at 22:16, Volkert <volkert(a)nivoba.de> wrote: > > Down > > >> On 23.12.2016 20:14, Sean P. DeNigris wrote: >> Bringing it up from the World Menu -> 503 error. Only me? >> >> macOS 10.12.1 >> Image >> ----- >> /Users/sean/Dynabook/Working Images/Pomodoro 5/Pomodoro 5.image >> Pharo5.0 >> Latest update: #50765 >> Unnamed >> >> Virtual Machine >> --------------- >> /Applications/Pharo.app/Contents/MacOS/Pharo >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> git@github.com:pharo-project/pharo-vm.git Commit: >> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: >> GitHub <noreply(a)github.com> >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString git@github.com:pharo-project/pharo-vm.git Commit: >> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: >> GitHub <noreply(a)github.com> >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Pharo-5-Catalog-Down-tp4928046.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

Dec. 23, 2016

Re: [Pharo-dev] Pharo 5 Catalog Down?

by Volkert

Down On 23.12.2016 20:14, Sean P. DeNigris wrote: > Bringing it up from the World Menu -> 503 error. Only me? > > macOS 10.12.1 > Image > ----- > /Users/sean/Dynabook/Working Images/Pomodoro 5/Pomodoro 5.image > Pharo5.0 > Latest update: #50765 > Unnamed > > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > git@github.com:pharo-project/pharo-vm.git Commit: > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: > GitHub <noreply(a)github.com> > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString git@github.com:pharo-project/pharo-vm.git Commit: > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: > GitHub <noreply(a)github.com> > CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-Catalog-Down-tp4928046.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 23, 2016