- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Epicea user experience report

by serge.stinckwich＠gmail.com

Sorry I'm for option 3 like Markus or Sean. EnvoyÃ© de mon iPhone > Le 27 dÃ©c. 2016 Ã 10:49, Martin Dias <tinchodias(a)gmail.com> a Ã©crit : > > In summary, we want to change the "Epicea" menu entry to: > > "Epicea Code Changes" (Option 2) > --> Stef, Serge > > or: > > "Code Changes" (Option 3) > --> Marcus, Sean > > I do not care a lot. BTW, what about other tools in the same manu such as Komitter and Versionner? > > > Apart from that, many agree on merging Epicea windows in one. > --> Doru, Norbert, Denis, Ben > > > Martin > >> On Sat, Dec 24, 2016 at 6:02 AM, <serge.stinckwich(a)gmail.com> wrote: >> 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. 27, 2016

Re: [Pharo-dev] Epicea user experience report

by Esteban Lorenzano

this is a debate we have with Stef time to time: my side: just descriptive names that explain them selves what they do. Stefâs side: cool fantasy names, that have some âpunchâ. After more than 2 years arguing... both arguments have pros and cons :) for example we can have several browsers then we need to identify them and just call them âclass browserâ is not enough. But of course, a newbie will have a hard time trying to figure out what âNautilusâ meansâ¦ (btwâ¦ the world many says "system browserâ and not âNautilusâ but then we have âmonticello browserâ and not âSCM package browserââ¦ and later we will have âIcebergâ and not âSCM project browserââ¦ so is not consistent either... also if everything is a browser then nothing is, etc., etc., etc. :) â¦ now, what I would like is a way to find tools both from his fantasy name and function (for example: âEpicea" and "change loggerâ)â¦ and a way to list those tools/components in both waysâ¦ Yeah, Iâm aware this approach âsolvesâ a problem by adopting both solutions instead proposing a synthesis, but wellâ¦ this is the better I was able to elaborate :) Any ideas are welcome, both on whatâs better and how to implement it. Esteban > On 27 Dec 2016, at 11:03, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 27.12.2016 um 10:49 schrieb Martin Dias <tinchodias(a)gmail.com>: >> >> I do not care a lot. BTW, what about other tools in the same manu such as Komitter and Versionner? > > It has a cool name that describes what it does. Putting Epicea in front of it does not add information only confusion. Versionner and Kommiter carry some meaning in their name. But have a better descriptive/more generic name would be good. > > Norbert >

Dec. 27, 2016

Re: [Pharo-dev] Epicea user experience report

by Norbert Hartl

> Am 27.12.2016 um 10:49 schrieb Martin Dias <tinchodias(a)gmail.com>: > > I do not care a lot. BTW, what about other tools in the same manu such as Komitter and Versionner? It has a cool name that describes what it does. Putting Epicea in front of it does not add information only confusion. Versionner and Kommiter carry some meaning in their name. But have a better descriptive/more generic name would be good. Norbert

Dec. 27, 2016

Re: [Pharo-dev] Epicea user experience report

by Martin Dias

In summary, we want to change the "Epicea" menu entry to: "Epicea Code Changes" (Option 2) --> Stef, Serge or: "Code Changes" (Option 3) --> Marcus, Sean I do not care a lot. BTW, what about other tools in the same manu such as Komitter and Versionner? Apart from that, many agree on merging Epicea windows in one. --> Doru, Norbert, Denis, Ben Martin On Sat, Dec 24, 2016 at 6:02 AM, <serge.stinckwich(a)gmail.com> wrote: > 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. 27, 2016

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

by Max Mattone

Hi Igor, I played with PhaROS quite a bit while I was working at Mines Douai. But at the time, cleanning instances was quite an issue.. I use to tend to work with rosMaster instances that already exists or build a new image everytime it get too slow because of those ros master instances... You can try: ''' PhaROSSystem cleanAll. ''' But I think it keeps some instances anyway. As far as I remember, I think they were working on rebuilding the networking interface to solve this issue. And Santi was also working on PhaROS2 looking for robustness... I dont know the statut of those projects. regards, maxmattone Le lun. 26 dÃ©c. 2016 Ã 00:09, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > > Hmm okay, i created own ros package > and started an example nodelet that prints 'hello world' , when i push > messages from outside by ros.. > now the question is how i should gracefully stop these nodelets and let > them unsubscribe/die gracefully.. > because i now have 4 instances of ROSMaster in my image and all locked by > waiting for some mutex/semaphores and > telling them 'stop' waits forever and blocks everything.. > How i can clean this up? > > > > -- > Best regards, > Igor Stasenko. >

Dec. 27, 2016

Re: [Pharo-dev] Minheadless VM flavour status update

by stepharong

this is supercool. Ronie do you think that we will be able to open in headless get a window on demand close it and continue headless and repeat the process? Because I have a super cool scenario for such feature :) Stef > Hi all, > > I am happy to announce that my latest VM refactoring experiment is > almost complete. I am only missing adding traditional style Makefiles to > make Eliot happy ;), and making this work with >MSVC. > > The minheadless is a VM variant that unifies a lot of the code for > Windows, Linux and OS X. To the point that I am using the same CMake > scripts for building on the three platforms. > The minheadless VM is a completely headless by default VM, unless the > configure script finds SDL2. > > If the configure script finds SDL2, and the legacy display interface is > enabled(which is by default), then this VM will be built using SDL2 to > implement the normal diplay primitives. The SDL2 >backend work with > normal Pharo and Squeak image. > > If SDL2 is not found by the configure script, or the legacy display > primitives are disabled in the configure script, or the VM is started in > headless mode, then the traditional display primitives are >just going > to be a /dev/null. > > Currently I am commiting this VM variant to the MinimalisticHeadless > branch at: > https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless > > For building using CMake it can be done in two ways: > > ------------------------------------ > Calling CMake directly > > mkdir build > cmake .. -DCMAKE_BUILD_TYPE=<The build type> (or cmake-gui ..) > make > > The supported build types are: > - Debug > - Assert > - RelWithDebInfo > - Release > > If you are on an x86_64 system and you want to build 32 bits version, > you have to pass the -DBUILD_I386_VERSION=True option to cmake. > > mkdir build > cmake .. (or cmake-gui ..) > make > > ------------------------------------ > Using mvm style scripts > > Easy mode: > > cd build.minheadless.cmake/<x86 or x64>/vm_variant > ./mvm > > A bit more complicated/flexible mode: > > This mvm will configure and build the vm for the four build types. This > behavior was present on the mvm for Windows, so I am replicating it. > > In these same folders that are two other scripts: mvm_configure (calls > cmake to only configure the build types), and mvm_configure_variant > > mvm_configure_variant is used to actually call cmake and configure the > VM for building. The syntax of mvm_configure_variant is the following: > > mvm_configure_variant <BuildDirectory> <BuildType> > > Currently my workflow for using these scripts is the following with > MSys/Cygwin/Linux: > > ./mvm_configure > make -j8 > > The makefile at build.minheadless.cmake/<x86 or x64>/vm_variant is only > used for delegating to the makefiles created by CMake. > > ------------------------------------ > I am leaving some prebuilt Pharo VMs with the SDL2 backend for Windows > for experimenting at: http://ronie.cl/files/vm/ > > Using OSWindow with this VM requires loading the latest version of > OSWindow by reloading the ConfigurationOfOSWindow manually in > Monticello, and then doing ConfigurationOfOSWindow >load. With this VM, > there are finally no more duplicated events. > > My TODO list for this includes adding plain Makefile. BTW: during the > following week I will continue working with Lowcode. I really need it > working again. > > Happy longest/shortest day of the year > Ronie -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 26, 2016

Re: [Pharo-dev] [Vm-dev] Minheadless VM flavour status update

by Ronie Salgado

Hello, I just compared size of VM: 1.3 mb vs 4 mb (current PharoVM). It is really > nice result. This probably because I am building with a less number of internal plugins. 2016-12-26 15:36 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btwâ¦ I do not think the VM should open any windowing system in any way. > This should be a task performed at image level, IMO. > I agree. I am doing the SDL2 backend as a stepping stone until we can get rid completely of it. With this VM, to disable the legacy backend completely is just a matter of building with the -DSUPPORT_TRADITIONAL_DISPLAY=Off. BTW, I forgot to mention that I did basic embedding interface available at: https://github.com/ronsaldo/opensmalltalk-vm/blob/MinimalisticHeadless/incl… . For usage ordering, take a look at the squeak_main function at: https://github.com/ronsaldo/opensmalltalk-vm/blob/MinimalisticHeadless/plat… . My main(and WinMain) functions are used to only call squeak_main. Best regards, Ronie

Dec. 26, 2016

Re: [Pharo-dev] [Vm-dev] Minheadless VM flavour status update

by Esteban Lorenzano

Hi Ronie, this is cool :) btwâ¦ I do not think the VM should open any windowing system in any way. This should be a task performed at image level, IMO. Esteban > On 24 Dec 2016, at 22:25, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi all, > > I am happy to announce that my latest VM refactoring experiment is almost complete. I am only missing adding traditional style Makefiles to make Eliot happy ;), and making this work with MSVC. > > The minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X. To the point that I am using the same CMake scripts for building on the three platforms. > > The minheadless VM is a completely headless by default VM, unless the configure script finds SDL2. > > If the configure script finds SDL2, and the legacy display interface is enabled(which is by default), then this VM will be built using SDL2 to implement the normal diplay primitives. The SDL2 backend work with normal Pharo and Squeak image. > > If SDL2 is not found by the configure script, or the legacy display primitives are disabled in the configure script, or the VM is started in headless mode, then the traditional display primitives are just going to be a /dev/null. > > Currently I am commiting this VM variant to the MinimalisticHeadless branch at: https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless <https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless> > > For building using CMake it can be done in two ways: > > ------------------------------------ > Calling CMake directly > > mkdir build > cmake .. -DCMAKE_BUILD_TYPE=<The build type> (or cmake-gui ..) > make > > The supported build types are: > - Debug > - Assert > - RelWithDebInfo > - Release > > If you are on an x86_64 system and you want to build 32 bits version, you have to pass the -DBUILD_I386_VERSION=True option to cmake. > > mkdir build > cmake .. (or cmake-gui ..) > make > > ------------------------------------ > Using mvm style scripts > > Easy mode: > > cd build.minheadless.cmake/<x86 or x64>/vm_variant > ./mvm > > A bit more complicated/flexible mode: > > This mvm will configure and build the vm for the four build types. This behavior was present on the mvm for Windows, so I am replicating it. > > In these same folders that are two other scripts: mvm_configure (calls cmake to only configure the build types), and mvm_configure_variant > > mvm_configure_variant is used to actually call cmake and configure the VM for building. The syntax of mvm_configure_variant is the following: > > mvm_configure_variant <BuildDirectory> <BuildType> > > Currently my workflow for using these scripts is the following with MSys/Cygwin/Linux: > > ./mvm_configure > make -j8 > > The makefile at build.minheadless.cmake/<x86 or x64>/vm_variant is only used for delegating to the makefiles created by CMake. > > ------------------------------------ > I am leaving some prebuilt Pharo VMs with the SDL2 backend for Windows for experimenting at: http://ronie.cl/files/vm/ <http://ronie.cl/files/vm/> > > Using OSWindow with this VM requires loading the latest version of OSWindow by reloading the ConfigurationOfOSWindow manually in Monticello, and then doing ConfigurationOfOSWindow load. With this VM, there are finally no more duplicated events. > > My TODO list for this includes adding plain Makefile. BTW: during the following week I will continue working with Lowcode. I really need it working again. > > Happy longest/shortest day of the year > Ronie

Dec. 26, 2016

Re: [Pharo-dev] Minheadless VM flavour status update

by Alexandre Bergel

Thanks Ronie! Alexandre > On Dec 24, 2016, at 10:25 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi all, > > I am happy to announce that my latest VM refactoring experiment is almost complete. I am only missing adding traditional style Makefiles to make Eliot happy ;), and making this work with MSVC. > > The minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X. To the point that I am using the same CMake scripts for building on the three platforms. > > The minheadless VM is a completely headless by default VM, unless the configure script finds SDL2. > > If the configure script finds SDL2, and the legacy display interface is enabled(which is by default), then this VM will be built using SDL2 to implement the normal diplay primitives. The SDL2 backend work with normal Pharo and Squeak image. > > If SDL2 is not found by the configure script, or the legacy display primitives are disabled in the configure script, or the VM is started in headless mode, then the traditional display primitives are just going to be a /dev/null. > > Currently I am commiting this VM variant to the MinimalisticHeadless branch at: https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless > > For building using CMake it can be done in two ways: > > ------------------------------------ > Calling CMake directly > > mkdir build > cmake .. -DCMAKE_BUILD_TYPE=<The build type> (or cmake-gui ..) > make > > The supported build types are: > - Debug > - Assert > - RelWithDebInfo > - Release > > If you are on an x86_64 system and you want to build 32 bits version, you have to pass the -DBUILD_I386_VERSION=True option to cmake. > > mkdir build > cmake .. (or cmake-gui ..) > make > > ------------------------------------ > Using mvm style scripts > > Easy mode: > > cd build.minheadless.cmake/<x86 or x64>/vm_variant > ./mvm > > A bit more complicated/flexible mode: > > This mvm will configure and build the vm for the four build types. This behavior was present on the mvm for Windows, so I am replicating it. > > In these same folders that are two other scripts: mvm_configure (calls cmake to only configure the build types), and mvm_configure_variant > > mvm_configure_variant is used to actually call cmake and configure the VM for building. The syntax of mvm_configure_variant is the following: > > mvm_configure_variant <BuildDirectory> <BuildType> > > Currently my workflow for using these scripts is the following with MSys/Cygwin/Linux: > > ./mvm_configure > make -j8 > > The makefile at build.minheadless.cmake/<x86 or x64>/vm_variant is only used for delegating to the makefiles created by CMake. > > ------------------------------------ > I am leaving some prebuilt Pharo VMs with the SDL2 backend for Windows for experimenting at: http://ronie.cl/files/vm/ > > Using OSWindow with this VM requires loading the latest version of OSWindow by reloading the ConfigurationOfOSWindow manually in Monticello, and then doing ConfigurationOfOSWindow load. With this VM, there are finally no more duplicated events. > > My TODO list for this includes adding plain Makefile. BTW: during the following week I will continue working with Lowcode. I really need it working again. > > Happy longest/shortest day of the year > Ronie -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 26, 2016

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

by Igor Stasenko

Hmm okay, i created own ros package and started an example nodelet that prints 'hello world' , when i push messages from outside by ros.. now the question is how i should gracefully stop these nodelets and let them unsubscribe/die gracefully.. because i now have 4 instances of ROSMaster in my image and all locked by waiting for some mutex/semaphores and telling them 'stop' waits forever and blocks everything.. How i can clean this up? -- Best regards, Igor Stasenko.

Dec. 25, 2016