September 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A call for a library to script github.com

by Brainstorms

Christopher Fuhrman posted this on his blog last March. (I ran across it looking for his LibC blog post.) This doesn't cover the scope of what you listed, but as sort of a "proof of concept" it does show a couple of ways that the GitHub API can be scripted. https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 26, 2019

[Pharo 8.0] Build #790: Smalltalk at removal

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #790 was: FAILURE. The Pull Request #4721 was integrated: "Smalltalk at removal" Pull request url: https://github.com/pharo-project/pharo/pull/4721 Issue Url: https://github.com/pharo-project/pharo/issues/Smalltalk_at_removal Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2019

[Pharo 8.0] Build #789: 4735-Implement-pcRange-on-Context-using-sourceNodeExecuted

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #789 was: SUCCESS. The Pull Request #4740 was integrated: "4735-Implement-pcRange-on-Context-using-sourceNodeExecuted" Pull request url: https://github.com/pharo-project/pharo/pull/4740 Issue Url: https://github.com/pharo-project/pharo/issues/4735 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

by ducasse

> On 26 Sep 2019, at 20:14, Brainstorms <wild.ideas(a)gmail.com> wrote: > > I have found a project that I think is a good fit in size & complexity, one > that can operate at that "CLI level" (i.e., doesn't need a GUI or a web > front end). > > We ("we" being my group and a number of projects around the Laboratory we've > been associated with) are migrating code from a Subversion server to a > central "Enterprise" GitHub (not publicly accessible). I'm the admin for > this particular SVN server, so I'm doing the migrations. Having assumed > most all of the group's devops functions over the years, I frequently have > to write code to automate tasks like these. That puts me in an good > position to write these tools in Pharo instead of Bash or Lua or Python, > etc. as I normally have been doing. Pay attention because Pharo could be better for supplanting bash. > Some of the SVN repos convert nicely, using available migration tools (such > as 'svn2git' or 'git svn'). However, many developers are insufficiently > trained on VCS, and over the years many of the SVN repos have been choked > with inappropriate files and have had their history threads tangled up -- so > they will not covert. I've studied the internal structure of SVN repo dump > files, and I have algorithms (and some code in Bash & Python) that allow me > to edit these files to make them convertible. Still, it's a lot of > hand-work; a more comprehensive solution is needed. > > I'm going to make a tool, in Pharo, for general editing of SVN dump files: > to remove junk that doesn't belong, extract single projects from mixed-use > repos, simplify history for tangled moves, etc. The output will be clean > dump files containing the extracted project-specific commits that will then > roll into GitHub without issues and show up with branches, tags, etc. as > expected. > While researching how to do this, I've converted 3 of >80 repositories > (which resulted in 15 project repos grouped in 3 GitHub Organizations). My > methods work; I just need to fully automate the process so that I can > complete the remainder. > > Ironically, I'm not actually being funded to do this as one of my "normal" > job tasks -- certainly not the automation part. As a result, this has > become a "nights and weekends" effort. But that means I will own the code > -- so I plan to put it on the *public* GitHub, with an MIT/Apache > open-source license. Of course, everyone else who's been frustrated trying > to convert complicated SVN repos into GitHub will have my Pharo tool to use. > (That could result in a lot of exposure to Pharo..??) And it allows the > Pharo community to potentially help, since they'll have access to the source > code as well. > > This kind of project does not require a GUI (it will be run by Linux admin > types) and it does not benefit from a web interface. It's mostly file I/O, > with some parameters that need to be negotiated with the user once the SVN > dump file has been scanned. Challenging, but not too challenging. To help you, you can extend the inspector to provide specific view on data. > > From there I can advertise its use around the Lab. We're not the only group > that's been using SVN. Some other sysadmins are likely to want > modifications... A start? To me Pharo is not really at the level I would like to. But this is my view. Now we have nice binding to invoke shell and other like subOSProcess. We should also progress on that front. To me Pharo is super good at manipulating complex data and object and building nice abstraction. So I hope that you will not be disappointed. > > -t > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

by Brainstorms

I have found a project that I think is a good fit in size & complexity, one that can operate at that "CLI level" (i.e., doesn't need a GUI or a web front end). We ("we" being my group and a number of projects around the Laboratory we've been associated with) are migrating code from a Subversion server to a central "Enterprise" GitHub (not publicly accessible). I'm the admin for this particular SVN server, so I'm doing the migrations. Having assumed most all of the group's devops functions over the years, I frequently have to write code to automate tasks like these. That puts me in an good position to write these tools in Pharo instead of Bash or Lua or Python, etc. as I normally have been doing. Some of the SVN repos convert nicely, using available migration tools (such as 'svn2git' or 'git svn'). However, many developers are insufficiently trained on VCS, and over the years many of the SVN repos have been choked with inappropriate files and have had their history threads tangled up -- so they will not covert. I've studied the internal structure of SVN repo dump files, and I have algorithms (and some code in Bash & Python) that allow me to edit these files to make them convertible. Still, it's a lot of hand-work; a more comprehensive solution is needed. I'm going to make a tool, in Pharo, for general editing of SVN dump files: to remove junk that doesn't belong, extract single projects from mixed-use repos, simplify history for tangled moves, etc. The output will be clean dump files containing the extracted project-specific commits that will then roll into GitHub without issues and show up with branches, tags, etc. as expected. While researching how to do this, I've converted 3 of >80 repositories (which resulted in 15 project repos grouped in 3 GitHub Organizations). My methods work; I just need to fully automate the process so that I can complete the remainder. Ironically, I'm not actually being funded to do this as one of my "normal" job tasks -- certainly not the automation part. As a result, this has become a "nights and weekends" effort. But that means I will own the code -- so I plan to put it on the *public* GitHub, with an MIT/Apache open-source license. Of course, everyone else who's been frustrated trying to convert complicated SVN repos into GitHub will have my Pharo tool to use. (That could result in a lot of exposure to Pharo..??) And it allows the Pharo community to potentially help, since they'll have access to the source code as well. This kind of project does not require a GUI (it will be run by Linux admin types) and it does not benefit from a web interface. It's mostly file I/O, with some parameters that need to be negotiated with the user once the SVN dump file has been scanned. Challenging, but not too challenging. >From there I can advertise its use around the Lab. We're not the only group that's been using SVN. Some other sysadmins are likely to want modifications... A start? -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

by ducasse

> > Schmidt Pro looks like a U.S. firm. no this is a german one. > There are multiple Lifewares, but I > think you may be referring to the INRIA associate? Lifeware.ch > >> Also what is important is that Mooc is a key assets: why because it >> represents >> 15 years of teaching experience. There are OOP teachers that are learning >> things on OOP >> when watching the mooc. So the mooc is not only about pharo. > > This is understandable; many universities use Smalltalk to teach the > principles of OOP. Seems logical that this would lead to using ST > afterwards to follow through. (But I know this doesn't often happen.) I've > gotten through all but the last two weeks of the MOOC so far, and it is > quite good. I will be suggesting it to people here. > >> Now a smart guy can learn Pharo in two days (Henrique Rocha did it and we >> hired him :), >> and after 2 weeks to play with the ide you can start to get fluent. > > Pharo has a different sort of learning curve: The language is simple, and > only requires different thinking to grasp some of the concepts. Most of the > learning involves how to make use of the IDE and what are the base classes > needed to make useful things. My frustrations have all involved things like > "How do I build a deployable application, start to finish?â Yes we should improve on this. > Most of the teaching materials seem focused on how to write Pharo code, but > that's really the easy part (if you've programmed with anything else > before). I will need to make tools in Pharo, but then I have to give > something to another engineer to run on his own. There are levels, of > course: Run from the CLI, run from a native (Spec) GUI, run from a web > browser (by building a web app in Pharo) -- in increasing order of > complexity and experience/skills needed. I /want/ to be able to do all of > these, of course. Thanks. We will have to do something there. > > The challenge of enrolling other developers into the Pharo ecosystem (with > all its advantages, many hidden at first) will revolve around how quickly > they can make something, even if CLI-based. I should add a CLI to one of my project and I will use it to write a small tutorial. > They will want to see early > results, then they get hooked and want to invest to learn how to do more. > Still, the early results will involve "How do I make a simple application > with this, like the way I can script something?" I would really love to see > a booklet that covers this subject (and I'm sure others would, too). > >> BTW the Mooc value is around 150 Keuros and it is free because we did it >> and it was sponsored >> by our institute and some other universities. > > Good training materials are very, very important. (And should be free, as > the MOOC is.) One of the things I've mentioned to others about the MOOC is > that it shows you how easy it is to build a professional-looking web > application using Pharo and its web libraries. (Of course all trainings > teach you the syntax and semantics of any language; the MOOC is also showing > you /how to build things/, and how many of us have built web apps before? I > never did.) > >> Yes this is why we can help to show how we do things. >> We will tell you also where we are not so good and where we want to go. > > I see this as a "mutually beneficial" possibility. I'm not looking to see > "What can Pharo do for me to make my job easier?" I'm interested in "How > can I help JPL benefit from what Pharo offers, while at the same time > contributing back to Pharo & its community to make a better ecosystem?" Let us know :) > Because when powerful, productive tools such as Pharo improve, everyone > benefits, directly and indirectly. JPL is an FFRDC (Federally-Funded > Research & Development Center), and our mission includes advancing > technology and assisting industry in ways that they cannot do themselves, or > cannot afford to do. We don't just "send spacecraft to the planets". Many > don't realize this. I prefer this "business model", so I've worked here my > entire career. > >> Right now we are starting a real effort for the following years on the >> virtual machine. >> One day we will revise the Pharo vision document (should be on internet >> somewhere) >> but it shows that we have a vision/roadmap and that we built it. > > The virtual machine intrigues me, so starting my contributions on the UFFI > docs (and maybe code, too) is a good place for me. > >> You see you can play it the way you want. >> The first ticket for a company is 1000 euros and else you can play as >> an official academic member of the consortium. > > We would be academic, I'm sure. But that's on the horizon, at this point. > >> Now what is more important is that we listen to our users. So the >> consortium roadmap is >> validated by the consortium >> members and we are helping as much as we can. Our goal is to make people >> succeed with their >> Pharo projects. We want to create a vertuous ecosystem. > > Excellent -- You don't just "write Pharo and throw it over the wall". > Here's what I would like to see happen: I start a "interest group" here, > find like-minded engineers & developers who want to learn "this new thing" > (which isn't new, of course), and encourage the use of Pharo. Almost > everything we do here is custom-built one way or another, so there are > tools, scripts, web apps, etc. that we built as a matter of course. Many > languages are used for this; Pharo can easily be one of them. There will be > both a "newness" hurdle, but also a "strangeness" hurdle to deal with. The > strengths and "cool tools" of Pharo (along with the ease of making GUIs and > web apps, and cool graphics from Roassal, etc.) will pull strongly to > overcome these hurdles and motivate interest -- IF this is presented, > marketed, supported properly AND if some early successes come out of it. > > "Nothing sells like success." > > We have some very creative, very smart people here, who love "cool > technology" and "toys to play with", but they are also very busy people... > and there's always that need to be successful, so invest wisely. There is a > joke that goes like this: "JPL has only two products: Photographs and press > releases." Another one is "JPL's successes end up on the front page of all > the world's newspapers. JPL's failures end up on the front page of all the > world's newspapers.â :) > > It it works, super. Good for you. If does something I can't do (and need > to), you've got my attention. If it's fast & easy to learn, I'll try it > out. If it's complicated, you're losing me. If it doesn't work.. See ya > later! > > And this has to be addressed at the level of developers and then at the > level of managers... > > Building on that is where the issues of reliability, the Pharo Association & > its support, community, and so forth come into play. As an analogy, we have > processes we must go through with vendor or custom hardware to establish > electrical safety, fail-safe, and so forth before such hardware can be > connected to spacecraft to do its job. Software has similar risk-mitigating > requirements, and if Pharo were to play a prominent role, that kind of > trustworthiness must be established as well. Financial organizations are > concerned with "We don't want a flaw to cause us to lose our money"; we're > concerned with "We don't want a flaw to cause us to lose a mission". That > sort of thing... > > So the kinds of support you're mentioning are good to hear. > >> A super concrete example, feenk reported that the windows update 1903/4 >> changed something >> and that their guys working on windows could not access git via libgit >> anymore. >> Pablo and Guille put this on their highest priority just after ESUG and it >> was solved within >> a couple of days. > > I did follow that thread. (I've been reading almost all the Dev & Users > mailing list postings for this past year.) > >> Feenk got problems with a binding or headless VM and pablo pair programmed >> with one of >> their engineering during ESUG. > > That's also strong evidence of significant support. We're used to having > "field engineers" show up on-site to help work out some of our tougher > problems with vendor's products. > > Thanks again for your responses. (And for the support from other community > members I've talked to.) I see nothing so far that doesn't continue to > encourage me. I've looked at the community, the tools, the documents, the > code, the MOOC and other trainings & examples, and played with it myself -- > all good (even if some areas are still evolving). > > What's turning over in my mind is how to best present this, how to market it > and get developers here "hooked" enough to spend time getting over that > initial hill of understanding. At first, Pharo is just /weird/, if > intriguing. There is *definitely* an ROI for those who will make the > effort, carve out the time, and try it. Pick up something that help you and build it. Be your first success story like that you will have something to show and we can help too :) > > -t > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 26, 2019

A call for a library to script github.com

by ducasse

Hi I know several people that would like to script from Pharo the github API. - for the new review tools - for posting bugs from pharo - for dashboard - for moose scripting There is also stargate and I would like to know whether there exist a library to build on top to script github because I think that there is need for a nice lib for that Stef

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

by Brainstorms

Hi Stef, > What I can tell you is that we are growing :). > When a company with more than 30 millions lines of code wants to migrate > to Pharo. > It means something :) and we are helping them and they actively support > the consortium > with immediate impact. Pablo is working full time to improve pharo and we > feel it. That */is/* an impressive show of confidence in Pharo and its community! The risk + expense of that is just mind-boggling... I think it also shows that "Pharo is a big-league language". > Yes there is a strong support from the community and from the consortium. > This is why we create the consortium (since 2012). It is here to support > companies and pharo development and pharo and its community are growing > steadily. This will certainly help at larger scales of Pharo use, at the point where a mission realizes they have a dependency on Pharo, similar to how they depend on other vendors for "product support" when there are issues that might impact delivery schedules, etc. I'm thinking of starting out small: introduce Pharo as a means of producing support tools, performing analysis & presentation, and so forth -- places where there is not much concern what languages are used to build a needed app, or where the output is the focus rather than the means. By demonstrating speed, ease of use, easy maintenance, features, etc. this can lead to requests for more Pharo work. Then it grows from there. (Pharo improves, too, as this is occurring.) > Esteban went to give special lectures or coaching to companies in the > past. > Since a year the consortium is supporting Schmidt Pro and Lifeware based > on contract > and so far this is working well. We will continue. Schmidt Pro looks like a U.S. firm. There are multiple Lifewares, but I think you may be referring to the INRIA associate? > Also what is important is that Mooc is a key assets: why because it > represents > 15 years of teaching experience. There are OOP teachers that are learning > things on OOP > when watching the mooc. So the mooc is not only about pharo. This is understandable; many universities use Smalltalk to teach the principles of OOP. Seems logical that this would lead to using ST afterwards to follow through. (But I know this doesn't often happen.) I've gotten through all but the last two weeks of the MOOC so far, and it is quite good. I will be suggesting it to people here. > Now a smart guy can learn Pharo in two days (Henrique Rocha did it and we > hired him :), > and after 2 weeks to play with the ide you can start to get fluent. Pharo has a different sort of learning curve: The language is simple, and only requires different thinking to grasp some of the concepts. Most of the learning involves how to make use of the IDE and what are the base classes needed to make useful things. My frustrations have all involved things like "How do I build a deployable application, start to finish?" Most of the teaching materials seem focused on how to write Pharo code, but that's really the easy part (if you've programmed with anything else before). I will need to make tools in Pharo, but then I have to give something to another engineer to run on his own. There are levels, of course: Run from the CLI, run from a native (Spec) GUI, run from a web browser (by building a web app in Pharo) -- in increasing order of complexity and experience/skills needed. I /want/ to be able to do all of these, of course. The challenge of enrolling other developers into the Pharo ecosystem (with all its advantages, many hidden at first) will revolve around how quickly they can make something, even if CLI-based. They will want to see early results, then they get hooked and want to invest to learn how to do more. Still, the early results will involve "How do I make a simple application with this, like the way I can script something?" I would really love to see a booklet that covers this subject (and I'm sure others would, too). > BTW the Mooc value is around 150 Keuros and it is free because we did it > and it was sponsored > by our institute and some other universities. Good training materials are very, very important. (And should be free, as the MOOC is.) One of the things I've mentioned to others about the MOOC is that it shows you how easy it is to build a professional-looking web application using Pharo and its web libraries. (Of course all trainings teach you the syntax and semantics of any language; the MOOC is also showing you /how to build things/, and how many of us have built web apps before? I never did.) > Yes this is why we can help to show how we do things. > We will tell you also where we are not so good and where we want to go. I see this as a "mutually beneficial" possibility. I'm not looking to see "What can Pharo do for me to make my job easier?" I'm interested in "How can I help JPL benefit from what Pharo offers, while at the same time contributing back to Pharo & its community to make a better ecosystem?" Because when powerful, productive tools such as Pharo improve, everyone benefits, directly and indirectly. JPL is an FFRDC (Federally-Funded Research & Development Center), and our mission includes advancing technology and assisting industry in ways that they cannot do themselves, or cannot afford to do. We don't just "send spacecraft to the planets". Many don't realize this. I prefer this "business model", so I've worked here my entire career. > Right now we are starting a real effort for the following years on the > virtual machine. > One day we will revise the Pharo vision document (should be on internet > somewhere) > but it shows that we have a vision/roadmap and that we built it. The virtual machine intrigues me, so starting my contributions on the UFFI docs (and maybe code, too) is a good place for me. > You see you can play it the way you want. > The first ticket for a company is 1000 euros and else you can play as > an official academic member of the consortium. We would be academic, I'm sure. But that's on the horizon, at this point. > Now what is more important is that we listen to our users. So the > consortium roadmap is > validated by the consortium > members and we are helping as much as we can. Our goal is to make people > succeed with their > Pharo projects. We want to create a vertuous ecosystem. Excellent -- You don't just "write Pharo and throw it over the wall". Here's what I would like to see happen: I start a "interest group" here, find like-minded engineers & developers who want to learn "this new thing" (which isn't new, of course), and encourage the use of Pharo. Almost everything we do here is custom-built one way or another, so there are tools, scripts, web apps, etc. that we built as a matter of course. Many languages are used for this; Pharo can easily be one of them. There will be both a "newness" hurdle, but also a "strangeness" hurdle to deal with. The strengths and "cool tools" of Pharo (along with the ease of making GUIs and web apps, and cool graphics from Roassal, etc.) will pull strongly to overcome these hurdles and motivate interest -- IF this is presented, marketed, supported properly AND if some early successes come out of it. "Nothing sells like success." We have some very creative, very smart people here, who love "cool technology" and "toys to play with", but they are also very busy people... and there's always that need to be successful, so invest wisely. There is a joke that goes like this: "JPL has only two products: Photographs and press releases." Another one is "JPL's successes end up on the front page of all the world's newspapers. JPL's failures end up on the front page of all the world's newspapers." It it works, super. Good for you. If does something I can't do (and need to), you've got my attention. If it's fast & easy to learn, I'll try it out. If it's complicated, you're losing me. If it doesn't work.. See ya later! And this has to be addressed at the level of developers and then at the level of managers... Building on that is where the issues of reliability, the Pharo Association & its support, community, and so forth come into play. As an analogy, we have processes we must go through with vendor or custom hardware to establish electrical safety, fail-safe, and so forth before such hardware can be connected to spacecraft to do its job. Software has similar risk-mitigating requirements, and if Pharo were to play a prominent role, that kind of trustworthiness must be established as well. Financial organizations are concerned with "We don't want a flaw to cause us to lose our money"; we're concerned with "We don't want a flaw to cause us to lose a mission". That sort of thing... So the kinds of support you're mentioning are good to hear. > A super concrete example, feenk reported that the windows update 1903/4 > changed something > and that their guys working on windows could not access git via libgit > anymore. > Pablo and Guille put this on their highest priority just after ESUG and it > was solved within > a couple of days. I did follow that thread. (I've been reading almost all the Dev & Users mailing list postings for this past year.) > Feenk got problems with a binding or headless VM and pablo pair programmed > with one of > their engineering during ESUG. That's also strong evidence of significant support. We're used to having "field engineers" show up on-site to help work out some of our tougher problems with vendor's products. Thanks again for your responses. (And for the support from other community members I've talked to.) I see nothing so far that doesn't continue to encourage me. I've looked at the community, the tools, the documents, the code, the MOOC and other trainings & examples, and played with it myself -- all good (even if some areas are still evolving). What's turning over in my mind is how to best present this, how to market it and get developers here "hooked" enough to spend time getting over that initial hill of understanding. At first, Pharo is just /weird/, if intriguing. There is *definitely* an ROI for those who will make the effort, carve out the time, and try it. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 26, 2019

[Pharo 8.0] Build #788: 4736-MethodMapExamples-should-not-use-MethodMap-directly

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #788 was: FAILURE. The Pull Request #4738 was integrated: "4736-MethodMapExamples-should-not-use-MethodMap-directly" Pull request url: https://github.com/pharo-project/pharo/pull/4738 Issue Url: https://github.com/pharo-project/pharo/issues/4736 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] [ANN] New Windows VM - Fixes 1903 error

by Serge Stinckwich

Yes this what I want to know. How to know there is an update, without downloading the update ? On Fri, Sep 20, 2019 at 10:26 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > I understood Serge Stinkwich's question to be "at any given time, how do > we know whether > the VM we have is the latest one for our platform?" Certainly that was > what I wanted to > know. When I use the Launcher, I don't see any way to ask "is this VM > I've selected up- > to-date". If I click on Update, the Launcher starts an HTTP request or > not, and after > enough time to make me think it is downloading quite a lot, just stops. > If I repeat the > action, the whole process repeats. This makes me think that the Launcher > is not looking > to see whether there is a new version, just downloading whatever is latest > at the other > end. > > It would be nice to have an "is this image/VM up todate?" button > somewhere, that just > gets a few bytes of version number + checksum. > > On Sat, 21 Sep 2019 at 01:40, Pablo Tesone <tesonep(a)gmail.com> wrote: > >> Hi Serge, >> >> in any Pharo Image (7 or 8) in the Option System / System Reporter >> >> There should be something like: >> >> >> Cheers, >> >> Pablo >> >> >> On 20/09/2019 13:24, Serge Stinckwich wrote: >> >> >> >> On Fri, Sep 20, 2019 at 11:07 AM tesonep(a)gmail.com <tesonep(a)gmail.com> >> wrote: >> >>> Hello, >>> a new stable VM has been deployed. This VM uses a new version of >>> libSSH allowing us to work in the latest Windows version. >>> >>> It can be directly updated using Pharo Launcher or downloaded using >>> ZeroConf scripts. >>> >>> To update from Pharo Launcher you have to access to the VM Manager >>> window. >>> Just click on the marked button and then in "Update" >>> [image: updateVM.png] >>> >>> >> This great Pablo, I didn't know that there is a VM manager. >> I want to save my bandwidth. >> How do we know, we have the last VM ? >> >> >> -- >> Serge Stinckwic >> h >> >> Int. Research Unit >> on Modelling/Simulation of Complex Systems (UMMISCO) >> Sorbonne University >> (SU) >> French National Research Institute for Sustainable Development (IRD) >> U >> niversity of YaoundÃ© I, Cameroon >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> https://twitter.com/SergeStinckwich >> >> -- Serge Stinckwic âhâ Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) âSorbonne University (SU) French National Research Institute for Sustainable Development (IRD)â U âniversity of YaoundÃ© Iâ, Cameroon "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich â

Sept. 26, 2019