- Pharo-dev - lists.pharo.org

Pharo 5 Catalog Down?

by Sean P. DeNigris

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] MQTT for Pharo

by Sean P. DeNigris

timrowledge wrote > Hi Sven, > yes, the code in SqueakSource/MQTT is very early stuff. It's improving > quickly though. I'd be happy to get together to work on an as common as > possible versions for both Squeak and Pharo. ----- Cheers, Sean -- View this message in context: http://forum.world.st/MQTT-for-Pharo-tp4927759p4928045.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 23, 2016

Re: [Pharo-dev] Epicea user experience report

by Martin Dias

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 - 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." > > > > > > > > > > > >

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Ben Coman

On Fri, Dec 23, 2016 at 9:27 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I always catch myself that I am completely lost in method versions (and > feel pain :)). > There is no clue what at the left pane and what at the right pane. > > Now I realize that VersionBrowser is trying to compare selected version > versus next version (according to list order). > So right pane shows selected version and left pane shows next one. > For me all of these is super non intuitive but maybe it is only my > problem. So here I want to ask about your experience. Do you feel same? > > I would prefer if VersionBrowser will always compare selected version > versus current version in image with actual image version on the left and > selected version on the right. > > What you think? > Thanks for bringing this up. I often find it awkward and non-intuitive, but have lived with it. Your idea to keep the left had code permanently the current-version would definitely make it more intuitive, but just another idea... In the bottom panes, both "side-by-side" and "diff", there is green & red highlighting. What about using the same highlight colours in the top pane to show which "version" the coloured code relates to. So for example, when opened, in the top pane the first line as the current-version would be highlighted green, as would the left pane. The second line would be highlighted red as the most recent previous-version, as would the right-pane. Now selecting an item in the top-pane moves the red highlight and changes the right-pane - which would effectively per Denis' proposal. But you might also ctrl-click in the top pane to move the green-highlight which changes the left-pane. Then perhaps "Revert" should not be a menu item in the top-pane (since there are two selections), but should have Revert menu item in both left-pane and right-pane. cheers -ben

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Thierry Goubier

Le 23/12/2016 Ã 16:16, Denis Kudriashov a Ã©crit : > > 2016-12-23 16:04 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > > In short, what you describe replaces a non-obvious, arbitrary pane > allocation by another one... maybe just more familiar to you. > > > No. I suggest current image version on left pane with visible label > "current version". And selected version on the right pane. > Also when you will switch from one version to another left pane will be > never changed which will be visible and intuitive indication that new > selected method is on the right pane because only right pane will change. Given that you're already watching the method in the image (because you selected it in Nautilus before calling versions), a simpler display is just a single pane showing the old version code with removal and additions / changes markers. Note: intuitive is a bad word for UI design. Nothing in UI is "intuitive". Learned / Familiar / has visible feedback / respect common ui guidelines are correct values. Thierry

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Thierry Goubier

Le 23/12/2016 Ã 18:13, Nicolas Passerini a Ã©crit : > I agree, current version is not intuitive. I'd like to see someone come with an idea that covers both uses of the version browser: 1- Revert to a previous version of a method 2- Study and compare the various changes the method went through Denis wants 1-. Current version browser focuses on 2- in a rather uintuitive way, especially if you are trying to do 1-. > Moreover, is it possible to consider a design that could allow Iceberg > or other tools to contribute older versions from repository? This one is easy and has been working for GitFileTree for a long time already. Technically, a few years ago, the version browser was rewritten to use Ring as its underlying code model; filling the version browser with RGMethodDefinition(s) allow you to use any source for past versions of a method. The API in gitfiletree is: MCFileTreeGitRepository>>#gitVersionsForDefinition:in: And you just need to change a single line in the version browser, as in: AltVersionBrowser>>#buildChangeList[2](*) Regards, Thierry [1] https://github.com/dalehenrich/filetree/blob/pharo6.0_dev/repository/Montic… [2] https://github.com/ThierryGoubier/AltBrowser/blob/pharo6/Alt-Browser.packag… > 2016-12-23 16:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > > 2016-12-23 16:04 GMT+01:00 Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: > > > In short, what you describe replaces a non-obvious, arbitrary > pane allocation by another one... maybe just more familiar to you. > > > No. I suggest current image version on left pane with visible label > "current version". And selected version on the right pane. > Also when you will switch from one version to another left pane will > be never changed which will be visible and intuitive indication that > new selected method is on the right pane because only right pane > will change. > >

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Denis Kudriashov

2016-12-23 18:30 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Moreover, is it possible to consider a design that could allow Iceberg or >> other tools to contribute older versions from repository? > > > I don't know. I not look into code But we of course need to improve it for upcoming git integration

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Denis Kudriashov

2016-12-23 18:13 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > Moreover, is it possible to consider a design that could allow Iceberg or > other tools to contribute older versions from repository? I don't know. I not look into code

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Nicolas Passerini

I agree, current version is not intuitive. Moreover, is it possible to consider a design that could allow Iceberg or other tools to contribute older versions from repository? 2016-12-23 16:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-12-23 16:04 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> In short, what you describe replaces a non-obvious, arbitrary pane >> allocation by another one... maybe just more familiar to you. > > > No. I suggest current image version on left pane with visible label > "current version". And selected version on the right pane. > Also when you will switch from one version to another left pane will be > never changed which will be visible and intuitive indication that new > selected method is on the right pane because only right pane will change. >

Dec. 23, 2016

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

by Denis Kudriashov

2016-12-23 16:04 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > In short, what you describe replaces a non-obvious, arbitrary pane > allocation by another one... maybe just more familiar to you. No. I suggest current image version on left pane with visible label "current version". And selected version on the right pane. Also when you will switch from one version to another left pane will be never changed which will be visible and intuitive indication that new selected method is on the right pane because only right pane will change.

Dec. 23, 2016