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

Re: [Pharo-dev] Adding build info into pharo runtime

by Torsten Bergmann

Aug. 17, 2017

Re: [Pharo-dev] ZnEasy question

by Sven Van Caekenberghe

Hi Milton, > On 5 Aug 2017, at 03:15, milton mamani <akevalion(a)gmail.com> wrote: > > Hi to all > > I want to use the next instruction in my code > > response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.co…'. > response. > > The previous code works from command line or in a webbrowser, but I does not work with ZnEasy > Because it takes the previous link as: > a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) > > Could you please tell me what can I do for this situation? > > Cheers, > Milton ZnUrl has indeed a problem parsing this URL. It skips empty path segments, we'll have to create an issue for that and we should try to fix it, maintaining current behaviour. The parser is hand written and has evolved a bit over the years, so it is a bit brittle. Seaside's WAUrl seems to have the same problem. It is funny that this only now comes up. Thanks for reporting it. Here is a workaround, by manually creating a ZnUrl object from its elementary components. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself. You can use this as follows. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); retrieveContents. ZnEasy get: (ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself). Regards, Sven

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Esteban Lorenzano

> On 17 Aug 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote: >> >> >> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: >> >> Hi, >> >> even when contributing to Pharo 7.0 is still very very cumbersome I was >> able >> to sort out most of the problems and contribute already a few smaller >> things. >> >> Unfortunately there is not much communication on what is currently in the >> pipe >> or planned on easing the process - which can easily lead to the impression >> that we do not really move or slow us down. >> >> I know step by step it goes and at least we have again the build process >> rolling >> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- >> starting-to-roll-for-real/ >> >> Nonetheless one of my PRs was already integrated and the integration of my >> WebBrowser >> package is still in the pipe (https://github.com/pharo-project/pharo/pull/ >> 193) >> >> The descriptions from Guille helped me - but there are still things I need >> answers to: >> >> 1. Will or is it still possible to automatically update" an image in Pharo >> 7 >> or in the future? >> The World menu entry "System" -> "System update" has been removed? >> >> Is this temporary of will it return once we know how it could be done >> again? >> >> >> You can update your image in Iceberg by switching to the updated #development >> branch and then to reload all packages. In most cases it will probably work >> fine but it does not know the right packages loading order, does not know >> changes in the packages structure etc. >> And some updates cannot be done at all (e.g. https://github.com/pharo-project/ >> pharo/pull/205). So you can expect troubles. >> With Cargo we can get smoother updating process but trying to maintain it now >> would be IMHO waste of resources. >> >> -- Pavel > > If the order is important... > > Iceberg models the commits, so it should be possible to start at the > head and trace back to the commit used to build the image. The > resulting list of commits could then be loaded in the correct order. > (I don't know if this would help in the case of PR #205) hehâ¦ no. Order of commits has nothing to do with order of loading packages. also: - class initialization has to happen - migrate changed instances needs to be prepared pre and post change. while most of the time update packages âjust worksâ, the case of slots for example will not work no matter the loading order, because we need to ensure some pre actions and post actions to happen. Iâm playing with the idea to extend iceberg with the capability of processing some information at package and class level (in package with manifests and in classes with class methods). Like adding #iceLoad, #iceUpdate methods (or #iceUpdateBefore and #iceUpdateAfter) so we can handle thisâ¦ but this will not happen immediately (in case we decide it worths to have it) :) > > Just to add a positive note to the conversation: I'm not very > knowledgable about git, but it seems to be the best source control tool > by far (based on my limited experience), and I've seen steady > improvement in Iceberg since Esteban indicated that it would be the > basis of source control for Pharo. What I've seen so far makes me think > that we are going down a good path, even if it is taking longer we would > like and is causing some pain along the way. nice! and yes, this kind of changes take a lot of timeâ¦ we are always too optimists and when we said âat least 3 monthsâ we should have said double that timeâ¦ but Iâm happy with things as they are starting to fit. And in a couple of months we will be a full speed :) cheers! Esteban > > > Cheers, > Alistair >

Aug. 17, 2017

Adding build info into pharo runtime

by Guillermo Polito

Hi all, as asked by Torsten, I spent some time adding build info into the pharo runtime. https://pharo.fogbugz.com/f/cases/20321/Add-build-number-to-SystemVersion https://github.com/pharo-project/pharo/pull/212 Tests are green https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… The built image can be tested from here: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… The build info is also shown in the About dialog. We show the same than what is found in built pharo artifacts in the file server. [image: Inline image 2] Please review or go on and propose a change based on that. Remember that I'm leaving on vacations tomorrow. Hope this is useful, Guille -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

by Alistair Grant

Hi Stef, On Thu, Aug 17, 2017 at 05:08:40PM +0200, Stephane Ducasse wrote: > I do not know but I imagine that I added basenameWithoutExtension because > I found the name much much clearer. I would have never guessed that > base is the basename without the extension. > > Stef Thanks for the clarification. Although #base isn't the name without the extension, it is the portion of the name up to the first extension delimiter (for names with a single extension delimiter the two will of course be the same, but for names with multiple extension delimiters they will be different). In that case, assuming no one else comes up with additional information, I would argue that the issue should be closed (rejected), and Michael should change his code to use #basenameWithoutExtension instead of #base. It would be nice to improve the comments in the code - I'll add it to my list. :-) Cheers, Alistair > On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > > > I've just taken a look at issue 19609 FileReference>>base should be > > before last separator and wonder whether it is a correct interpretation > > of the original intentions. > > > > The original author of the issue, Michael, seems to feel that > > FileReferene>>base and FileReference>>basenameWithoutExtension are the > > same. > > > > My reading of the comments is that they perform a different function, > > i.e.: > > > > > > '/a/b/c.d.e' asFileReference base. "c" > > '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" > > > > > > are both the expected values, i.e.: > > > > - #base answers the name up to the first extensionDelimiter. > > - #basenameWithoutExtension answers the name without what is typically > > considered the file extension (the bit after the last > > extensionDelimiter). > > > > Not shown above, but: > > > > - #basename answers the entire filename, i.e. "c.d.e". > > > > > > Does anyone know the history of these methods? > > > > > > Cheers, > > Alistair > > >

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Alistair Grant

On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote: > > > 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > > Hi, > > even when contributing to Pharo 7.0 is still very very cumbersome I was > able > to sort out most of the problems and contribute already a few smaller > things. > > Unfortunately there is not much communication on what is currently in the > pipe > or planned on easing the process - which can easily lead to the impression > that we do not really move or slow us down. > > I know step by step it goes and at least we have again the build process > rolling > https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- > starting-to-roll-for-real/ > > Nonetheless one of my PRs was already integrated and the integration of my > WebBrowser > package is still in the pipe (https://github.com/pharo-project/pharo/pull/ > 193) > > The descriptions from Guille helped me - but there are still things I need > answers to: > > 1. Will or is it still possible to automatically update" an image in Pharo > 7 > or in the future? > The World menu entry "System" -> "System update" has been removed? > > Is this temporary of will it return once we know how it could be done > again? > > > You can update your image in Iceberg by switching to the updated #development > branch and then to reload all packages. In most cases it will probably work > fine but it does not know the right packages loading order, does not know > changes in the packages structure etc. > And some updates cannot be done at all (e.g. https://github.com/pharo-project/ > pharo/pull/205). So you can expect troubles. > With Cargo we can get smoother updating process but trying to maintain it now > would be IMHO waste of resources. > > -- Pavel If the order is important... Iceberg models the commits, so it should be possible to start at the head and trace back to the commit used to build the image. The resulting list of commits could then be loaded in the correct order. (I don't know if this would help in the case of PR #205) Just to add a positive note to the conversation: I'm not very knowledgable about git, but it seems to be the best source control tool by far (based on my limited experience), and I've seen steady improvement in Iceberg since Esteban indicated that it would be the basis of source control for Pharo. What I've seen so far makes me think that we are going down a good path, even if it is taking longer we would like and is causing some pain along the way. Cheers, Alistair

Aug. 17, 2017

Re: [Pharo-dev] Issue that may break Epicea

by Guillermo Polito

Ahh!! Yes, there is a test that fails from time to time, but nothing to do with that PR I think. Actually, Martin if you have some time to check, there is a cyclothymic test that fails randomly on the CI. Maybe the test needs to be more robust. On Thu, Aug 17, 2017 at 5:03 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not know but tests broke when I integrated the changes. > > On Thu, Aug 17, 2017 at 10:59 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Why would it break epicea? >> >> There is no major change in API. Only the method #createDirectory is >> removed, but the only users are internal to the library. In my latest image >> there are no Epicea users of it. >> >> On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Hi martin >>> >>> >>> https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >>> https://github.com/pharo-project/pharo/pull/133 >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

by Stephane Ducasse

I do not know but I imagine that I added basenameWithoutExtension because I found the name much much clearer. I would have never guessed that base is the basename without the extension. Stef On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi All, > > I've just taken a look at issue 19609 FileReference>>base should be > before last separator and wonder whether it is a correct interpretation > of the original intentions. > > The original author of the issue, Michael, seems to feel that > FileReferene>>base and FileReference>>basenameWithoutExtension are the > same. > > My reading of the comments is that they perform a different function, > i.e.: > > > '/a/b/c.d.e' asFileReference base. "c" > '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" > > > are both the expected values, i.e.: > > - #base answers the name up to the first extensionDelimiter. > - #basenameWithoutExtension answers the name without what is typically > considered the file extension (the bit after the last > extensionDelimiter). > > Not shown above, but: > > - #basename answers the entire filename, i.e. "c.d.e". > > > Does anyone know the history of these methods? > > > Cheers, > Alistair >

Aug. 17, 2017

Re: [Pharo-dev] Issue that may break Epicea

by Stephane Ducasse

I do not know but tests broke when I integrated the changes. On Thu, Aug 17, 2017 at 10:59 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Why would it break epicea? > > There is no major change in API. Only the method #createDirectory is > removed, but the only users are internal to the library. In my latest image > there are no Epicea users of it. > > On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi martin >> >> >> https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> https://github.com/pharo-project/pharo/pull/133 >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 17, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Dimitris Chloupis

I remember my 10 year self struggling learning to code basic back in 1988 on an Amstrad CPC 6128 with Locomotive Basic that required entering line numbers before the code statement. IDEs , code editors and what else were unheard of for me at least and even if they did exist would be nowhere near the budget of a 10 year old. Nowdays we have a ton of options, easy access to it, its free , its open source, insanely powerful and even documented. You can even find Youtube tutorials if too lazy to read text and also a ton of examples and snippets to get you started. I agree 1000% with your argument that "batteries included" version is super important, its one of the major reason why Python exploded in popularity. But yeah I turn to Hulk every time I hear these dreaded 3 words "too many options". I am willing to endure this hell of too many options and even pray it gets much much worse. But then it may be just me :) On Thu, Aug 17, 2017 at 5:50 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > On Thu, Aug 17, 2017 at 4:25 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> hi Dimitris (good to see you around ;) ), >> >> > Not going anywhere , just taking a break from Pharo :) > > >> thing isâ¦ we want to improve our tools. >> >> great > > >> And improve tools sometime means to add stuff (Iâm not very happy with it >> either, I would like to remove more than what I add, but it is like that). >> For example, if we want to have good class comments, we need some markup >> format, then the best thing we have is pillar and then we need a parser and >> then the easiest to use thing we have is petit parser. >> > > Yeah.. about that. See the issue is exactly what you just mentioned , > improvement. Sometimes improving makes things worse. Markdown class > comments is an excellent example of this. You do the logical thing and > offer markdown for class comments , you make the image more complex by > adding a feature the average user would need but you greatly improve your > ability for class comments. > > But your average user does not even bother adding one line comment on the > main class what are the chances that will use markdown ? I am willing to > bet big money on "close to zero chance". Hence you end up making things > actually worse by adding code that your user wont use and instead > increasing the complexity and his motivation to explore and fall in love > with your project. > > >> Which means we will need an image that have a core PetitParser and a >> basic Pillarâ¦ so we can have proper documentation. Of course, maybe the >> full pillar is too much (as it is the full petit parser, probably) so we >> need to think carefully what we put inside and what we left outside. Same >> is with everything: why to put athens, or glamour, or X, Y, Z. (things that >> few people use, but are very important for our echosystem in general). >> > > Well if few people use them, how they are important to your ecosystem ? If > you talking about dependencies then that means the ecosystem is deeply > flawed and we go back to the modularity question. I fail to see how Athens > is important to the Pharo ecosystem , apart from Roassal people I have not > seen anyone else using it consistently. > > If you were talking about the UFFI I would agree 100% but I cannot agree > by any means that Athens is so important for Pharo that must be included in > the image. By the way I am a graphics guy so biased in favour of Athens. > > >> >> > Now, along with this âbloatingâ movements, that adds more elements to the >> system and because of that increases essential complexity, we are working >> on the other direction: bootstrapping and modularising Pharo so in the near >> future (it should be done for P7 or as late to P8) you will be able to >> create an image with the elements you want. >> >> Another thing we need to work on (but thatâs in part documentation and in >> part modifications to be done) we need to work on overall >> availability/comprehensibility of the system. >> >> Soâ¦ we need to continue adding things, in order to continue improving. We >> also need to remove a lot of things that are duplicated or obsolete. >> Pharo will always be âthe deliverable we makeâ (including all things we >> officially support as âpart of itâ)â¦ but we are making possible that >> everybody can also do âthe Pharo they wantâ. >> > > I can understand having a Parser in image to parse Pharo syntax and other > things, big thumbs up for that I think that would justify the inclusion for > the average user. Parsing and dealing with text is a big deal afterall. > > I am ok with offering a minimal image and not being the default one. As > long it exists I am happy. >

Aug. 17, 2017