- Pharo-users - lists.pharo.org

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

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

by H. Hirzel

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. 18, 2017

Re: [Pharo-users] GTInspect auto-update in raw view?

by Andrei Chis

However, we still need the update button. The automatic refresh only works for the Raw view. A general solution for the update is not yet implemented. Cheers, Andrei On Fri, Aug 18, 2017 at 10:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Cooooool > Because I hate so much this update button :) > Stef > > > On Fri, Aug 18, 2017 at 7:22 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > > > On Thu, Aug 17, 2017 at 9:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > > wrote: > >> > >> > >> On 17 Aug 2017, at 01:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> > >> Hello Esteban, > >> > >> You can enable auto-refresh with: GTInspector enableStepRefresh > >> For performance reasons it is disabled by default. If you are curious > why > >> I think Andrei could explain a bit more :) > >> > >> > >> I want to know why is disabled and more than that, when will we be able > to > >> make it enabled by default, as before. > > > > > > Mostly because it was finished just before the Pharo 6 release. > > I'd say we can enable it by default for Pharo 7 and see if there are any > > issues. > > > > Cheers, > > Andrei > > > >> > >> > >> Esteban > >> > >> > >> Cheers, > >> Alex > >> > >> On 17 August 2017 at 00:56, Esteban A. Maringolo <emaringolo(a)gmail.com> > >> wrote: > >>> > >>> Hi all, > >>> > >>> Is there a way to enable the auto-update of instance variables display > in > >>> the GTInspector? > >>> > >>> There are cases where the instance is nil, I then initialize it > somehow, > >>> but the variable is still displayed as nil. > >>> > >>> I know there is an "Update" button, which BTW should be labeled > "refresh" > >>> instead, to do it manually, but hey, this is Smalltalk, we invented > MVC :D > >>> > >>> We can consider the previous as a feature, but what I think it is a bug > >>> is that if the variable is nil, and later it is initialized, nil is > still > >>> displayed, but when clicked the nodes below it shows the variables of > the > >>> new object in the instance variable. > >>> > >>> E.g. > >>> <image.png> > >>> > >>> Is this a bug or a feature? > >>> > >>> Regards! > >>> > >>> Esteban A. Maringolo > >> > >> > >> > > > >

Aug. 18, 2017

Re: [Pharo-users] Installation done last week: Do I have Pharo 6.0 or Pharo 6.1?

by Peter Uhnak

On Fri, Aug 18, 2017 at 07:16:30PM +0200, H. Hirzel wrote: > Thank you, Bernhard and Markus for confirming that Pharo is not > reporting the correct version number. > > But do you think I probably got 6.1 when I installed it on the 9th August with > > curl get.pharo.org | bash Yes, you will get the latest version which is 60510, which is 6.1. You can download previous versions here http://files.pharo.org/image/60/ Peter

Aug. 18, 2017

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

by Peter Uhnak

On Fri, Aug 18, 2017 at 09:50:35PM +0200, H. Hirzel wrote: > Hello Peter > > Thank you for the answer. Good news that Phil Back has an done > upgraded version of the PetitYAML parser recently. > > I think what you describe as "mostly complete" will be very fine for > my purposes. > > On 8/18/17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > Phil Back has kindly fixed the PetitYAML so it mostly works now. > > The only problem I've encountered was some weird misparsing of strings > > containing slashes, e.g. "5/". > > > > In any case: > > > > Install PetitParser (from Catalog or somewhere), load PetitYAML package > > (this is already loaded when loading PP from catalog). > > I just installed Pillar and that pulled in PetitParser. Not sure if it > is a good idea now to re-install PetitParser again. > > In particular there is only PetitParser catalog entry for Pharo 5.0, > not 6.0 or 6.1 I don't know about this, you'd have to ask the Moose team (or whoever is responsible for PetitParser now) > > 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

Aug. 18, 2017

Re: [Pharo-users] [Ann] Blog entry about using Pharo / Smalltalk to build a bot

by Stephane Ducasse

Hi sergio Tx for your nice article. I hope you got success with Pharo. Could we write a small success story? Stef On Fri, Aug 18, 2017 at 2:54 PM, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Oh! I like your approach.. > > Let me quickly clarify my situation. In that section of the article, I was > referring to my workplace. In my case, no one else in the dev department > knows smalltalk. In a great many workplaces, devs donât really want to learn > a new language / framework without going off to a developer summer camp or > something like that. > > I have found that once a developer gets to a certain level of competence, > they can quickly (in a weekend?) get up to speed on the use of a new > language / framework to get their project done. > > For a long time, I felt the sting of the âmost popular language listsâ as > companies wanted to start all projects in PHP so that if the senior devs > moved on, they could just hire some kids âcheap, just out of schoolâ to work > on the project. > > i do think there are lots of things about to change Pharoâs place in the > world, especially the Pharo MOOC.. > > there was one claim you made in that post that got me thinking > > ""No one else knows Smalltalk." > > So I wonder how many developers amount to "no one". > > > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.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. 18, 2017