- Pharo-dev - lists.pharo.org

SmalltalkHub MCRepositoryError, ZnHttpUnsuccessful: 503 Service Temporarily Unavailable

by Juraj Kubelka

Hi, It has been already several days that SmalltalkHub say "ZnHttpUnsuccessful: 503 Service Temporarily Unavailableâ. Is it known problem? MCRepositoryError: Could not load ConfigurationOfGlamourCore-JurajKubelka.142.mcz: ZnHttpUnsuccessful: 503 Service Temporarily Unavailable It happens whenever FogBugz is checking case: https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6360//artifact/vali… What I can do about it? Cheers, Juraj

July 23, 2016

Re: [Pharo-dev] github-cache organisation

by Ben Coman

On Sat, Jul 23, 2016 at 8:48 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 7/22/16 8:02 PM, Ben Coman wrote: >> >> On Sat, Jul 23, 2016 at 2:29 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> >>> On 07/22/2016 11:19 AM, Ben Coman wrote: >>>>> >>>>> On 07/21/2016 08:40 PM, Ben Coman wrote: >>>>>> >>>>>> Just a general observation and first impression of installing a github >>>>>> hosted project. >>>>>> >>>>>> After installing OSSubprocess from the Catalog Browser on Pharo 50760, >>>>>> which uses repository... >>>>>> github://marianopeck/OSSubProcess:v0.2.4/repository >>>>>> >>>>>> ...I see file >>>>>> >>>>>> "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" >>>>>> sitting next to my .image file. That would seem to dirty up that area >>>>>> when I start to use git more often. I'd expect that file to be placed >>>>>> in >>>>>> one of the cache folders. >>>>>> >>>>>> cheers -ben >>>>> >>>>> >>>>> >>>> On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs >>>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>>> >>>>> Ben, >>>>> >>>>> I think I've found the bug ... Metacello intends that the zip file be >>>>> downloaded to /tmp, but the code as implemented 3 years ago for Pharo >>>>> was >>>>> not actually downloading the file to /tmp ... thanks for pointing this >>>>> out, >>>>> I've created a Metacello issue for this[1] ... I will probably fix this >>>>> shortly, but I'm not sure when (or if) my fix will be integrated into >>>>> the >>>>> Pharo-5.0 release. >>>> >>>> Cool. Thanks Dale. I created issues for Pharo 5 & 6 to track this our >>>> end. >>>> https://pharo.fogbugz.com/default.asp?18804 >>>> https://pharo.fogbugz.com/default.asp?18805 >>>> >>>> cheers -ben >>>> >>>> P.S.@All curious why "Area=divers" for "Project=Metacello" >>>> >>>> >>> Ben, >>> >>> Sorry ... I gave you the wrong issue # for this one ... I opened 3 new >>> issues for this message and only 2 of them applied directly '#405: Github >>> .zip download not downloaded to `/tmp` as expected ... Pharo-5.0' and >>> '#406: >>> Github .zip download file should be deleted after archive is extracted' >>> ... >>> #404 is not really an issue, since the pid is meant for disambiguation of >>> the file name, which is exactly the same thing that is supposed to be >>> done >>> by FileReference class>>newTempFilePrefix:suffix: ... >>> >>> Too many windows floating around:) >>> >>> Dale >>> >> @All, btw in the pharo-project swimlane here [1] it would be nice to >> have a branch tagged "Pharo5.0" showing the point that was integrated >> into Pharo 5. >> cheers -ben >> > Ben ... are you missing an url for [1]? I'm afraid I have no idea what a > "pharo-project swimlane" is. Whoops. Yes. [1] https://github.com/dalehenrich/metacello-work/network and from that you probably know or guess what a swimlane is, but to be clear... [2] https://en.wikipedia.org/wiki/Swim_lane cheers -ben > > As an aside, when these bugs are fixed in Metacello the fixes will apply to > Pharo3.0, Pharo4.0, Pharo5.0, and Pharo6.0 ...

July 23, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

On 7/22/16 8:02 PM, Ben Coman wrote: > On Sat, Jul 23, 2016 at 2:29 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> On 07/22/2016 11:19 AM, Ben Coman wrote: >>>> On 07/21/2016 08:40 PM, Ben Coman wrote: >>>>> Just a general observation and first impression of installing a github >>>>> hosted project. >>>>> >>>>> After installing OSSubprocess from the Catalog Browser on Pharo 50760, >>>>> which uses repository... >>>>> github://marianopeck/OSSubProcess:v0.2.4/repository >>>>> >>>>> ...I see file >>>>> "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" >>>>> sitting next to my .image file. That would seem to dirty up that area >>>>> when I start to use git more often. I'd expect that file to be placed >>>>> in >>>>> one of the cache folders. >>>>> >>>>> cheers -ben >>>> >>>> >>> On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>> Ben, >>>> >>>> I think I've found the bug ... Metacello intends that the zip file be >>>> downloaded to /tmp, but the code as implemented 3 years ago for Pharo was >>>> not actually downloading the file to /tmp ... thanks for pointing this >>>> out, >>>> I've created a Metacello issue for this[1] ... I will probably fix this >>>> shortly, but I'm not sure when (or if) my fix will be integrated into the >>>> Pharo-5.0 release. >>> Cool. Thanks Dale. I created issues for Pharo 5 & 6 to track this our >>> end. >>> https://pharo.fogbugz.com/default.asp?18804 >>> https://pharo.fogbugz.com/default.asp?18805 >>> >>> cheers -ben >>> >>> P.S.@All curious why "Area=divers" for "Project=Metacello" >>> >>> >> Ben, >> >> Sorry ... I gave you the wrong issue # for this one ... I opened 3 new >> issues for this message and only 2 of them applied directly '#405: Github >> .zip download not downloaded to `/tmp` as expected ... Pharo-5.0' and '#406: >> Github .zip download file should be deleted after archive is extracted' ... >> #404 is not really an issue, since the pid is meant for disambiguation of >> the file name, which is exactly the same thing that is supposed to be done >> by FileReference class>>newTempFilePrefix:suffix: ... >> >> Too many windows floating around:) >> >> Dale >> > @All, btw in the pharo-project swimlane here [1] it would be nice to > have a branch tagged "Pharo5.0" showing the point that was integrated > into Pharo 5. > cheers -ben > Ben ... are you missing an url for [1]? I'm afraid I have no idea what a "pharo-project swimlane" is. As an aside, when these bugs are fixed in Metacello the fixes will apply to Pharo3.0, Pharo4.0, Pharo5.0, and Pharo6.0 ... Dale Dale

July 23, 2016

Re: [Pharo-dev] github-cache organisation

by Ben Coman

On Sat, Jul 23, 2016 at 2:29 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 07/22/2016 11:19 AM, Ben Coman wrote: >>> >>> On 07/21/2016 08:40 PM, Ben Coman wrote: >>>> >>>> Just a general observation and first impression of installing a github >>>> hosted project. >>>> >>>> After installing OSSubprocess from the Catalog Browser on Pharo 50760, >>>> which uses repository... >>>> github://marianopeck/OSSubProcess:v0.2.4/repository >>>> >>>> ...I see file >>>> "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" >>>> sitting next to my .image file. That would seem to dirty up that area >>>> when I start to use git more often. I'd expect that file to be placed >>>> in >>>> one of the cache folders. >>>> >>>> cheers -ben >>> >>> >>> >> On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> Ben, >>> >>> I think I've found the bug ... Metacello intends that the zip file be >>> downloaded to /tmp, but the code as implemented 3 years ago for Pharo was >>> not actually downloading the file to /tmp ... thanks for pointing this >>> out, >>> I've created a Metacello issue for this[1] ... I will probably fix this >>> shortly, but I'm not sure when (or if) my fix will be integrated into the >>> Pharo-5.0 release. >> >> Cool. Thanks Dale. I created issues for Pharo 5 & 6 to track this our >> end. >> https://pharo.fogbugz.com/default.asp?18804 >> https://pharo.fogbugz.com/default.asp?18805 >> >> cheers -ben >> >> P.S.@All curious why "Area=divers" for "Project=Metacello" >> >> > Ben, > > Sorry ... I gave you the wrong issue # for this one ... I opened 3 new > issues for this message and only 2 of them applied directly '#405: Github > .zip download not downloaded to `/tmp` as expected ... Pharo-5.0' and '#406: > Github .zip download file should be deleted after archive is extracted' ... > #404 is not really an issue, since the pid is meant for disambiguation of > the file name, which is exactly the same thing that is supposed to be done > by FileReference class>>newTempFilePrefix:suffix: ... > > Too many windows floating around:) > > Dale > @All, btw in the pharo-project swimlane here [1] it would be nice to have a branch tagged "Pharo5.0" showing the point that was integrated into Pharo 5. cheers -ben

July 23, 2016

Re: [Pharo-dev] A taste of bootstrap

by Nicolas Passerini

Hey! This is great news! I am anxious to work with you for integrating git and bootstrap. On Fri, Jul 22, 2016 at 8:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2016-07-22 16:42 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Fri, Jul 22, 2016 at 11:38 AM, Pavel Krivanek < >> pavel.krivanek(a)gmail.com> wrote: >> >>> >>> >>> 2016-07-22 16:24 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> >>>> >>>> On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> Hi Pavel, >>>>> >>>>> Congrats for your hard work! You know me well, so don't take my next >>>>> question as negative. >>>>> You have been working in minimal images since years. Guille has also >>>>> done quite some work, and many other people as well. >>>>> My question is.... have we decreased the effort to keep it working as >>>>> Pharo evolves? Previously, there were always problems with the >>>>> dependencies: a single commit to Pharo would add or break a dependency and >>>>> so we cannot bootstrap anymore. In other words...there was still a lot of >>>>> human action needed to check and fix dependencies. Is this still the case? >>>>> >>>> >>>> Complex questions requires complex answers :). It's not a yes, neither >>>> a no. >>>> >>>> - We have automatized the dependency analyses >>>> - We added Lint rules that ensure that no new dependencies are added to >>>> the kernel because of an integration >>>> - We will be adding soon enough more tools to automatically validate >>>> and ensure the health of the bootstrap, and to detect possible problems. >>>> >>>> Buuut, >>>> >>>> - Lint rules can (and sometimes are) ignored >>>> - Not everybody is aware of how to maintain dependencies or even they >>>> do not know they should care about it >>>> >>>> So the human factor is still of big importance (and risk), and >>>> educating people is harder than machines ^^ >>>> >>> >>> I must say that current need of human work required for proper reloading >>> of all Pharo packages is too high. It can be better only as soon as the >>> bootstrapping will be part of our development/release process. >>> >> >> Exactly!!! Totally agree. And..what are the plans of getting the >> bootstrapping as part of the development and release process? I am sure it >> is on the roadmap. >> > > Simply as soon as possible :-) I will work on preparation of it in the > next weeks. > > -- Pavel > > >> >> >>> >>> On the other hand, dependency problems are now quite rare and are very >>> rare in the kernel packages. >>> >>> >> That's very good to hear! >> >> >>> -- Pavel >>> >>> >>>> >>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek < >>>>> pavel.krivanek(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >>>>>> >>>>>>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >>>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>>> > Hi, >>>>>>> > >>>>>>> > as you maybe know, we are working on Pharo image bootstrap - the >>>>>>> process >>>>>>> > that can generate an image from source codes and initialize it >>>>>>> correctly. >>>>>>> > Because of practical reasons we do not bootstrap the standard >>>>>>> image at once >>>>>>> > but we are trying to bootstrap a small headless kernel image and >>>>>>> then load >>>>>>> > the rest of the system into it. >>>>>>> > >>>>>>> > The good news is that we are successful in our effor. We are >>>>>>> already able to >>>>>>> > produce well usable images as you can test here: >>>>>>> >>>>>>> Great to hear of your continuing progress. >>>>>>> >>>>>>> > >>>>>>> > https://goo.gl/fn1VbP >>>>>>> > >>>>>>> > From the Pharo/Squeak point of view this image is very special >>>>>>> because it >>>>>>> > doesn't contain any object inherited from 70's. Pharo lost its >>>>>>> umbilical >>>>>>> > cord. >>>>>>> >>>>>>> Does this mean you are starting with a zero byte file and adding nil, >>>>>>> true, false, etc...? >>>>>>> Or what is the size of the image you start with? >>>>>>> >>>>>> >>>>>> No, we are not generating image file directly. We use special VM >>>>>> simulator and then save its object memory. >>>>>> Our bootstrapped image has about 5MB now (in Spur format). >>>>>> >>>>>> >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>>> > >>>>>>> > Notice that the initial display width is too narrow and and we >>>>>>> still need a >>>>>>> > lot of work on the building process, but In the next weeks and >>>>>>> months it >>>>>>> > will change a lot the Pharo development - especially as soon as it >>>>>>> will be >>>>>>> > combined with Git support. >>>>>>> > >>>>>>> > Cheers, >>>>>>> > -- Pavel >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

July 22, 2016

Re: [Pharo-dev] git feature request

by Nicolas Passerini

In Iceberg you currently can: 1) Download a project using metacello github:// protocol 2) Use Iceberg to make it "writable" (i.e. transform it to an Iceberg repository, pointing to the same remote repository), this is just one step. 3) Commit and push using the new repo, etc. What it is not done yet is the integration with github (or whatever) fork/pr capabilities, it is in the roadmap but not just now because those are not standard git operations, so it will involve communicating directly to the github rest api (and others, we will not be attached to git nor github). So you should add two extra steps which are forking and pull requesting from outside Pharo (or requesting access to the respository to commit right there). This should be a normal flow for contributing to a tool you are using, right now is partially supported to be done from a git(hub) repository, I intend to extend it to be done also from tools installed from smalltalkhub, etc. Should be the same thing. About the discussion between commits and PRs... I've seen both models working right, I think that both have their advantages and I would like to build tools to support both schemas. Personally, I prefer to give people the possibility to commit, but even so I am used to work with PRs, because it really helps the code review. Yes you can have your own branch, and I can see the changes introduced by any commit, but usually is a PR that moves people towards looking to the code, and I think that it is a nice model that works well in practice. In other projects, you have to fork, commit there, then PR, if two people want to work together in an issue is not obvious how to do it... it adds more bureaucracy, it might be necessary for a large project like Pharo, but normally I prefer to avoid it. On Fri, Jul 22, 2016 at 4:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > This flow is taken into account in the new iceberg... I cannot go into > details because I'm still on holidays (and no internet) until Monday... And > Nico is also taking some days. > Anyway, yes... We had this flow in mind (and others, of course) when we > worked in the use cases we want to support. > > Cheers, > Esteban > > > On 22 Jul 2016, at 15:14, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >>> On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: > >>> I'm not sure what the roadmap is for git integration, but just a use > case > >>> that occurs to me while I work "a bit with git" for the first time from > >>> Pharo. > >>> > >>> I install a project via a Baseline from git and makes a small > improvement. > >>> What is the easiest way to contribute back? I can't push back to the > >>> personal repo I downloaded from, so the easiest thing would be a single > >>> menu item to: > >>> 1. Fork original repository > >>> 2. Push current in-Image code to a new branch in that fork. > >>> > >>> Maybe even... > >>> 3. Issue a pull request to the original repository. > >> > >> This is indeed the idiomatic way to contribute on GitHub. > >> > >> 1. fork > >> 2. install _your fork_ with gitfiletree/remote git repo > >> 3. make an improvement (you can use master branch, since it's your > repo, but that's a detail) > >> 4. issue a pull request > > > > That is how you do it if you *already* know you want to be contribute > > to an application or package. But what if I was just planning to *use* > > an application or package, only later I ended up tracing down a bug to > > that application and fixed it. What is the *easiest* for me to push > > to my personal github account from where I make the Pull Request. > > Something like this [1] from within Pharo (disclaimer, I've not > > performed these action before, I had to hunt a bit to find it as an > > example)... > > > > [1] https://gist.github.com/jagregory/710671 > > > >> Maybe IceBerg (https://github.com/npasserini/iceberg) could have some > nice interface for this eventually. > > > > Thanks for the link. This will be interesting to watch. > > > > cheers -ben > > > >

July 22, 2016

Re: [Pharo-dev] [Ann] ObjectTravel. A tool to traverse object references

by HernÃ¡n Morales Durand

Hi Denis, Looks very cool, thank you very much for sharing! A couple of questions. Can you comment how (if) you've applied your ObjectTravel? Or some use cases you have in mind? Have you tried to implement travelling methods of the Composite design pattern with your package? Cheers, HernÃ¡n PS: It would be nice if this ANN goes also to the pharo-users mailing list. 2016-07-22 7:45 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > This is side project of my work on Seamess and RemoteDebuggingTools. You > can load it by: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ObjectTravel'; > configuration; > loadStable > > ObjectTravel is a tool to deeply traverse "native" references of given > object through instance variables and "array contents". > > Usage is quite simple: > > traveler := ObjectTraveler on: (1@2 corner: 3@4). > traveler referencesDo: [:eachRef | eachRed logCr]. > > > Here is list of suitable methods: > > - collectReferences > - countReferences > - skip: anObject > - traverseOnly: predicateBlock > - copyObject > - findAllPathsTo: targetObject > - replaceCurrentReferenceWith: anObject > > Details are here > http://dionisiydk.blogspot.fr/2016/07/objecttravel-tool-to-traverse-object.… > . > > Best regards, > Denis >

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Mariano Martinez Peck

On Fri, Jul 22, 2016 at 3:04 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Mariano, > > Could you describe this a bit more ... what expression are you using to > "specify the github cache location"? > > Hi Dale, https://github.com/dalehenrich/metacello-work/issues/407 If you want you can open a Metacello issue and work through details there... > > Dale > > > On 07/22/2016 07:58 AM, Mariano Martinez Peck wrote: > > > > On Fri, Jul 22, 2016 at 12:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> Just a general observation and first impression of installing a github >> hosted project. >> >> After installing OSSubprocess from the Catalog Browser on Pharo 50760, >> which uses repository... >> github://marianopeck/OSSubProcess:v0.2.4/repository >> >> ...I see file >> "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" >> sitting next to my .image file. That would seem to dirty up that area >> when I start to use git more often. I'd expect that file to be placed in >> one of the cache folders. >> >> > Hi Ben, > > Just to say I very much hate that as well. Even more when I have specified > the github cache location and seems to be ignored... > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Pavel Krivanek

2016-07-22 16:42 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Fri, Jul 22, 2016 at 11:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com > > wrote: > >> >> >> 2016-07-22 16:24 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> >>> >>> On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> Hi Pavel, >>>> >>>> Congrats for your hard work! You know me well, so don't take my next >>>> question as negative. >>>> You have been working in minimal images since years. Guille has also >>>> done quite some work, and many other people as well. >>>> My question is.... have we decreased the effort to keep it working as >>>> Pharo evolves? Previously, there were always problems with the >>>> dependencies: a single commit to Pharo would add or break a dependency and >>>> so we cannot bootstrap anymore. In other words...there was still a lot of >>>> human action needed to check and fix dependencies. Is this still the case? >>>> >>> >>> Complex questions requires complex answers :). It's not a yes, neither a >>> no. >>> >>> - We have automatized the dependency analyses >>> - We added Lint rules that ensure that no new dependencies are added to >>> the kernel because of an integration >>> - We will be adding soon enough more tools to automatically validate and >>> ensure the health of the bootstrap, and to detect possible problems. >>> >>> Buuut, >>> >>> - Lint rules can (and sometimes are) ignored >>> - Not everybody is aware of how to maintain dependencies or even they do >>> not know they should care about it >>> >>> So the human factor is still of big importance (and risk), and educating >>> people is harder than machines ^^ >>> >> >> I must say that current need of human work required for proper reloading >> of all Pharo packages is too high. It can be better only as soon as the >> bootstrapping will be part of our development/release process. >> > > Exactly!!! Totally agree. And..what are the plans of getting the > bootstrapping as part of the development and release process? I am sure it > is on the roadmap. > Simply as soon as possible :-) I will work on preparation of it in the next weeks. -- Pavel > > >> >> On the other hand, dependency problems are now quite rare and are very >> rare in the kernel packages. >> >> > That's very good to hear! > > >> -- Pavel >> >> >>> >>> >>>> Cheers, >>>> >>>> >>>> >>>> On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek < >>>> pavel.krivanek(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >>>>> >>>>>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > as you maybe know, we are working on Pharo image bootstrap - the >>>>>> process >>>>>> > that can generate an image from source codes and initialize it >>>>>> correctly. >>>>>> > Because of practical reasons we do not bootstrap the standard image >>>>>> at once >>>>>> > but we are trying to bootstrap a small headless kernel image and >>>>>> then load >>>>>> > the rest of the system into it. >>>>>> > >>>>>> > The good news is that we are successful in our effor. We are >>>>>> already able to >>>>>> > produce well usable images as you can test here: >>>>>> >>>>>> Great to hear of your continuing progress. >>>>>> >>>>>> > >>>>>> > https://goo.gl/fn1VbP >>>>>> > >>>>>> > From the Pharo/Squeak point of view this image is very special >>>>>> because it >>>>>> > doesn't contain any object inherited from 70's. Pharo lost its >>>>>> umbilical >>>>>> > cord. >>>>>> >>>>>> Does this mean you are starting with a zero byte file and adding nil, >>>>>> true, false, etc...? >>>>>> Or what is the size of the image you start with? >>>>>> >>>>> >>>>> No, we are not generating image file directly. We use special VM >>>>> simulator and then save its object memory. >>>>> Our bootstrapped image has about 5MB now (in Spur format). >>>>> >>>>> >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> > >>>>>> > Notice that the initial display width is too narrow and and we >>>>>> still need a >>>>>> > lot of work on the building process, but In the next weeks and >>>>>> months it >>>>>> > will change a lot the Pharo development - especially as soon as it >>>>>> will be >>>>>> > combined with Git support. >>>>>> > >>>>>> > Cheers, >>>>>> > -- Pavel >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

On 07/22/2016 11:19 AM, Ben Coman wrote: >> On 07/21/2016 08:40 PM, Ben Coman wrote: >>> Just a general observation and first impression of installing a github >>> hosted project. >>> >>> After installing OSSubprocess from the Catalog Browser on Pharo 50760, >>> which uses repository... >>> github://marianopeck/OSSubProcess:v0.2.4/repository >>> >>> ...I see file >>> "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" >>> sitting next to my .image file. That would seem to dirty up that area >>> when I start to use git more often. I'd expect that file to be placed in >>> one of the cache folders. >>> >>> cheers -ben >> >> > On Sat, Jul 23, 2016 at 1:38 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> Ben, >> >> I think I've found the bug ... Metacello intends that the zip file be >> downloaded to /tmp, but the code as implemented 3 years ago for Pharo was >> not actually downloading the file to /tmp ... thanks for pointing this out, >> I've created a Metacello issue for this[1] ... I will probably fix this >> shortly, but I'm not sure when (or if) my fix will be integrated into the >> Pharo-5.0 release. > Cool. Thanks Dale. I created issues for Pharo 5 & 6 to track this our end. > https://pharo.fogbugz.com/default.asp?18804 > https://pharo.fogbugz.com/default.asp?18805 > > cheers -ben > > P.S.@All curious why "Area=divers" for "Project=Metacello" > > Ben, Sorry ... I gave you the wrong issue # for this one ... I opened 3 new issues for this message and only 2 of them applied directly '#405: Github .zip download not downloaded to `/tmp` as expected ... Pharo-5.0' and '#406: Github .zip download file should be deleted after archive is extracted' ... #404 is not really an issue, since the pid is meant for disambiguation of the file name, which is exactly the same thing that is supposed to be done by FileReference class>>newTempFilePrefix:suffix: ... Too many windows floating around:) Dale

July 22, 2016