August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] YAML parser (2017)

by Peter Uhnak

On Sat, Aug 19, 2017 at 02:45:28PM +0200, H. Hirzel wrote: > Peter, thanks for the confirmation that in your installation of the > PetitYAML grammar all tests are green. > > I wonder how you did it. As I've said, you need to update PetitParser; if there's no appropriate catalog entry, then ConfigurationOfPetitParser loadBleeding edge, or manually via Monticello Browser (the same way you loaded PetitYAML). Peter > > This is what I did: > > 1. I put Pillar on the back burner for the moment and > > 2. I went for a pristine Pharo 6.0 Latest update: #60510 image (a.k.a. 6.1). > > 3. Then I installed PetitParser only through the catalog -- > the entry is still tagged for Pharo 5.0 > > 4. Then I added PetitYAML > > Name: PetitYAML-PhilippeBack.11 > Author: PhilippeBack > Time: 29 May 2017, 12:53:55.994195 pm > UUID: d7658233-112c-754c-81a7-d60139bb9549 > > taken from > > MCSmalltalkhubRepository > owner: 'Moose' > project: 'PetitParser' > user: '' > password: '' > > > 5. Running the tests gave me > > 76 run -- 76 errors > > > What am I missing here? > > Is there an easy workaround to get PetitParser with PetitYAML into > 6.0-#60510 (a.k.a. 6.1) ? > > --Hannes

Aug. 19, 2017

Re: [Pharo-users] YAML parser (2017)

by H. Hirzel

P.S. I assume I need to get a developer version. How do I do that? On 8/19/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Peter, thanks for the confirmation that in your installation of the > PetitYAML grammar all tests are green. > > I wonder how you did it. > > This is what I did: > > 1. I put Pillar on the back burner for the moment and > > 2. I went for a pristine Pharo 6.0 Latest update: #60510 image (a.k.a. > 6.1). > > 3. Then I installed PetitParser only through the catalog -- > the entry is still tagged for Pharo 5.0 > > 4. Then I added PetitYAML > > Name: PetitYAML-PhilippeBack.11 > Author: PhilippeBack > Time: 29 May 2017, 12:53:55.994195 pm > UUID: d7658233-112c-754c-81a7-d60139bb9549 > > taken from > > MCSmalltalkhubRepository > owner: 'Moose' > project: 'PetitParser' > user: '' > password: '' > > > 5. Running the tests gave me > > 76 run -- 76 errors > > > What am I missing here? > > Is there an easy workaround to get PetitParser with PetitYAML into > 6.0-#60510 (a.k.a. 6.1) ? > > --Hannes >

Aug. 19, 2017

Tealight (similar to Teapot) installs fine in Pharo 6.1

by H. Hirzel

Hello Torsten Tealight installs very fine into the latest Pharo release (6.0 / 6.1). It is easy to use and the documentation is great! --Hannes On 8/15/17, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi sergio, > > why not use my existing "Tealight" project which is (similar to Teapot) also > available from Pharo catalog. > It is still lightweight as it is just a few extensions to Teapot. > > You will find it here: > > https://github.com/astares/Tealight > > the page includes the full documentation and after reading it you should be > able to see: > > - that you can even start the server quickly from the world menu after > loading > - how easy it is to tinker and experiment with dynamic routes and Teapot in > an interactive way > - how easy it is to provide a REST interface by having methods annotated > with REST specific pragmas > - to even provide a versioned REST interface (also defined using pragmas) > > The document should easily explain all this, esepcially read "Defining a > REST based interface". > > This project is around since last october now (see > http://forum.world.st/ANN-Tealight-td4918431.html) > > > Lately I even added the possibility to remove one or all the dynamic routes > in a teapot inspector > (see attached screenshot). That makes it even easier to experiment lively > with a teapot instance > and different URLs one wants to catch. > > Have fun > Torsten

Aug. 19, 2017

Re: [Pharo-users] YAML parser (2017)

by H. Hirzel

Peter, thanks for the confirmation that in your installation of the PetitYAML grammar all tests are green. I wonder how you did it. This is what I did: 1. I put Pillar on the back burner for the moment and 2. I went for a pristine Pharo 6.0 Latest update: #60510 image (a.k.a. 6.1). 3. Then I installed PetitParser only through the catalog -- the entry is still tagged for Pharo 5.0 4. Then I added PetitYAML Name: PetitYAML-PhilippeBack.11 Author: PhilippeBack Time: 29 May 2017, 12:53:55.994195 pm UUID: d7658233-112c-754c-81a7-d60139bb9549 taken from MCSmalltalkhubRepository owner: 'Moose' project: 'PetitParser' user: '' password: '' 5. Running the tests gave me 76 run -- 76 errors What am I missing here? Is there an easy workaround to get PetitParser with PetitYAML into 6.0-#60510 (a.k.a. 6.1) ? --Hannes

Aug. 19, 2017

Re: [Pharo-users] How to find where pharo is killing processor power?

by Ben Coman

On Thu, Aug 17, 2017 at 7:53 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Are you aware of the profile tools inside Pharo ? They capture execution > and offer detailed analysis of how much time is spent on each task. One of > it can be found in World Menu -> Tools -> Time Profiler > Thats good for a normal behaving process, but I'm not sure it helps identify a currently-misbehaving process. A (virtual)CPU % could be useful addition to Process Browser. cheers -ben > > Generally speaking a while loop that runs all the time without any kind of > delays is a very popular way to consume 100%. Even if the while loop does > nothing it will still consume %100 because even executing an empty loops > has costs. Two solution is inserting a delay in the loop so the loop have > to wait for 1 millisecond or less depending your demands or just make sure > the loop has a very specific condition so it executes only when you need > to. > > On Wed, Aug 16, 2017 at 10:04 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > >> >> hey all.. my current pharo implementation is running super serious >> processor power, but it shouldnât be doing much. >> >> [image: Activity_Monitor__All_Processes__and_Pharo_image.jpg] >> >> how would I go about tracking this inside the pharo image? >> >> Thanks! >> >> >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: http://bit.ly/29z9fG0 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> http://www.Village-Buzz.com <http://www.village-buzz.com/> >> http://www.ThoseOptimizeGuys.com <http://www.thoseoptimizeguys.com/> >> http://www.coffee-black.com >> http://www.painlessfrugality.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 >> >

Aug. 19, 2017

Re: [Pharo-users] YAML parser (2017)

by Peter Uhnak

All my tests are green, so maybe you need to update PetitParser too to the latest (PetitParser-JanKurs.290) It is probable that Pillar loaded older version of PetitParser. Peter On Fri, Aug 18, 2017 at 10:56:30PM +0200, H. Hirzel wrote: > Hello again > > On 8/18/17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > [...] > >> I assume that can directly load the PetitYAML from the repository > >> instead. > >> Where do I find it? > > > > Open Monticello Browser, find PetitParser repository and open it, select > > PetitYAML package, select the latest version, right click and load. > > > > Peter > > > Thank you for the instructions. > Loading PetitYAML-PhilippeBack.11.mcz went fine. > > But out of 76 tests I get 57 errors. This are so many error that that > it is quite possible that they have a single cause. I did not start > debugging. > > Something similar happens if I go back to > PetitYAML-JanKurs.8 > Author: JanKurs > Time: 15 June 2016 > > What I aiming at is > > - to have Pillar loaded (was successful, see other thread) > - get a working PetitYAML version > > --Hannes > > P.S. Note that the screen shot shows a Pharo 6.0 version. But it > actually is 6.1 (see other thread).

Aug. 19, 2017

Re: [Pharo-users] Loading and saving packages to filetree repos

by Dimitris Chloupis

First lets get a basic understanding of git, filetree and metadata. The process of using both filetree and git are simple and short , the only problem is Monticello with a GUI that is not well designed. With filetree you do what you would have done anyway 1) You pick a package 2) You create a filetree repo for it 3) You tell to filetree where to save your files 4) You edit/add code 5) You tell filetree to save your files In another language you would have done something similar using an IDE 1) Create a project 2) Tell to the IDE where to save your project 3) Create new source files 4) edit code in those source files 5) save those source files Git is also very simple , git is a version control system which basically what it does is create a history of changes (= versions) which calls commits , it also allows you to have versions of your history which calls branches which are basically variations of the same project and you end up with a nice history tree Git has 3 basic actions , push, pull and commit The first thing is pull which what it does is that it pull from another git repo, usually this is a github or other online repo used as the main repo but it can be also local too. In a pull git does again what you would expect , it takes a look at the history of the other repo and the history of the repo you want to pull to and first makes sure that the repos do not contain different histories. If they do then git ask 2 logical questions 1) Are these commits just additional commits that the receiver repo does not have ? If yes then just bring this commits and add them to the receiving repo history 2) Are these commits not only additional but also in between , which means they can be the commits for example no 1, 6 , 23 , 45 and 64 ? if yes then I do not know what to do , alert the user there are conflicts, which commits do conflict and exactly which code and which source files git commit just add commits to your repo history. git push does the opposite of git pull its sends your commits to the other repo but again it asks those two questions There is also git clone which basically creates a repo and git pulls from another repo This means that conflicts cannot exist , under usual circumstances, for single user repos. Because a user cannot create randomly diffirent commits in his/her own repo unless she works from different computers and forgets to git pull and thus creates different histories. Commits appear when you have multiple people with their own repos pushing to the same repo, in that case its much easier to create conflicts. However it may surprise people that if you remove the metadata you will not greatly reduce git conflicts. What greatly reduces conflicts is first to always remember to git pull BEFORE adding new commits , this way there is less chance for histories to go out of sync and of course having small teams. The less people the less chance to create conflicts. A way around this is to make branches or forks, it does not actually solve the problem. A branch as we said is a version of the history of a repo and it evolves separately. A fork is basically another repo that has its own history and also of course its own branches. Both branches and forks can merge with another history at any point along the way, still they will have conflicts. The big diffirence here is that you deal with those conflicts only when you do that merge (in the case of a fork we call it "pull request" because you request from another repo to pull your commits). So basically what you do is delay the inevitable. If you work alone you don't need to worry about conflicts and thus not need to worry about metadata. There is very little chance to cause conflicts , close to zero. if you work as a team, conflicts will be more and more frequent , the less properly your teammates use git, aka forget to git pull and push often, thus metadata will end up being the lest of your concerns. Basically because metadata are just information about your code and your project, there is nothing really complex about it and thus a conflict with metadata will be a minor concern. A conflict on the code on the other hand is a big deal, if your teammate forgets to git push and pull often , there is also a big chance he does an even bigger mistakes and commits less often. This is a huge deal because that means his commits will contain huge chunks of code which in return will make conflict resolution a nightmare. Again the problem does not originate from git or filetree , the problem is understanding the code and making sure that what you merge which basically means you decide which code is rejected and which is accepted inside the history is code that works, is reliable and does not create a stream of bugs and mostly does not take your project backward instead of forward. So complexity is multiplied much more by the human factor and much less from the technology factor. A work around this is to use powerful git tools that make some common decisions for you and help you understand those conflicts , but in the end conflict resolution is an art and a science by itself and its directly related on how well you understand not only the code of the project itself but also the code others provide. Why all this lengthy post ? I am not saying you do not know all this, I have no means to know what you do or what you do not know . My purpose is to make sure people reading this post realise this is not a metadata, git or filetree problem . The problem is the actual code conflicts. It does not matter so much if metadata is removed from the equation if your or anyone else reading does not understands the nature of those code conflicts. Where this leaves you with your initial question how to do this easier for newcomers ? DONT Because any means to simplify a already simple process is hiding important steps of that process which means the confusion your will try to avoid know will multiply later for the newcomer when he end up not only having to learn all you tried to help me avoid to learn but also having to resolve an army of problems he generates because of his or her ignorance. Or to put this entire lengthy post in one sentence Laziness always comes with a high price to pay ;) On the matter of auto save, sure you can do that but again its not that necessary because any change you make to the code is already saved to changes files. But yes sure you can make filetree auto save to files , that could make things a tiny bit easier. Hoi, > > I want to have a quick "cheat mode" for loading and saving the Smalltalk > packages in my project. This is to make life easy for newbies who are not > very familiar with Monticello and Metacello. > > The "cheat" is to assume that there is one filetree:// repository that > contains all of the relevant packages, and all we need to do is load or > save each of those packages in that repository. > > I have the loading part working already: > > repo := MCFileTreeRepository new directory: '/foo/bar/baz' > asFileReference. > repo allFileNames do: [ :file | > (repo versionFromFileNamed: file) load. > ]. > > but now I am wondering how to do the saving part? That is, given a path to > a filetree repo like '/foo/bar/baz', how do I save each package in that > repo i.e. export the code in the image? > > Ideally I would like the same operation to skip metadata that is likely to > cause conflicts when the code is checked into Git later e.g. package > timestamps and versions. > > Tips would be appreciated :). > >

Aug. 19, 2017

Re: [Pharo-users] ZnConstants class>>#httpStatusCodes and cloudflare

by Holger Freyther

> On 18. Aug 2017, at 20:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Holger, > > It is probably not a good idea to be too strict here. I committed the following to #bleedingEdge thank you! holger

Aug. 19, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Ben Coman

> Normally you have a CI that builds from the latest pharo image + the latest commit from your repo and you start with that all couple of days/weeks (This is important to make sure that you have a reproduce build, too). This is expected for production code, but maybe not the workflow for everyone (e.g. hobbyists or people exploring datasets.) On Fri, Aug 18, 2017 at 10:36 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 18 Aug 2017, at 15:41, Tim Mackinnon <tim(a)testit.works> wrote: > > If you donât mind - let me try a second attempt at paraphrasing what you > are saying (just to make sure Iâm clear, but it might help others too). > > We start each yearly cycle with an X0 new release (our current release is > 6). Then there may be point releases 6.1, 6.2 etc where there is a breaking > change (typically a new VM. Our last point release was 6.1). > > Thought the year (typically every few days) there are âhot fixesâ that > causes an image number change (these have worked there way through the CI, > and have triggered a new artefect). These images can be found at > http://files.pharo.org/image/60/ (where 60 designates the last release > cycle, we donât use point designations for this directory name). > > When you download the latest point release, you are getting all the major > elements of that release plus any of the hot fixes that have occurred since > that official release. *So you have the most up to date version of a > stable Pharo at the time that you download this file from: * > http://pharo.org/download > > > yes > > The implication of the above, is that if you want to revert to exactly > what was present in the launch of an official point release, you will need > to download the latest release from Pharo.org <http://pharo.org/> and > then find the image number that corresponded to that release at > http://files.pharo.org/image/60/ (is there an easy way to determine this > and then find that file? Or is there an official archive of the first point > release?). > > If you want to say up to date, you should periodically download the latest > point release (or you can simply find that latest named image file from: > http://files.pharo.org/image/60/ and use your current VM). > > If the above is the case - it seems like a reasonable way of operating, > although it might be good to know what the exact image number was in the > first issued point release (just for traceability). > > Have I now got it straight now? > > Yes. > And maybe it is not goodâ¦ maybe it would be better to accumulate the > changes between the point release without changing the download and have > the version numbers > more prominent in the downloaded files (so that it is easy to find old > versions, too). > For major.minor.hotfix versioning, maybe the hotfixes that pass CI could accumulate in a list that is loaded similar to the old System > Software Update method, so hotfixes are available without without having to throw away an image - i.e. a new download is only required for a "major.minor" update. A user might individually select a hotfix, but the default list gives a standard order to load them. Each change to that default list is essentially a ".hotfix" point release. This may provide the mechanism to provide more longevity of Pharo versions. As part of their CI, anyone can download the major.minor release and then the default hotfix list (or their own list). Older Pharo versions would tend to become more community-supported. cheers -ben

Aug. 19, 2017

Re: [Pharo-users] Pharo for Android

by Ricardo Pacheco

Thanks a lot. I will give it a try!! 2017-08-18 15:15 GMT-05:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Santiago Bragagnolo updated the VM but it is still using an old > pulling event system. > It is on our large todo to address this but it means a lot of work. > We want a better Android support for sure but .... > Now you can use Pharo on Android. > > I do not know if we have a jenkins job :( > > https://github.com/sbragagnolo/pharo-android-wrapper > > Stef > > On Fri, Aug 18, 2017 at 5:00 PM, Ricardo Pacheco > <ricardo.pacheco.roldan(a)gmail.com> wrote: > > I read some info dated 2014 that there where some efforts to make Pharo > able > > to run on Android. Will new versions of Pharo (6.1 & 7) support Android. > > Does anybody use succesfully the most recent version of Pharo on a > Android > > tablet? > > > > Thanks > >

Aug. 18, 2017