- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] github-cache organisation

by Ben Coman

> 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"

July 22, 2016

Re: [Pharo-dev] git feature request

by Dale Henrichs

On 07/22/2016 07:11 AM, Peter Uhnak wrote: > On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman 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)... >> > This would depend a bit on how you installed the project to start with. > > If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same. > > However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), > then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project). > > Luckily, you should be able to explicitly permit the conflict: > > Metacello new > baseline: 'MyProject'; > repository: 'gitfiletree://wherever'; > onConflict: [:ex | ex allow ]; > load > > We should be documenting these things somewhereâ¦ Or create tools ... the Monticello Browser was created to manage Monticello packages and Pharo really needs a tool that manages projects --- not from the code browsing perspective, but from the Metacello project (baseline/configuration) management perspective --- I've mentioned this before and will probably mention it again:) ... For tODE I've added a menu item to the `project list` that clones a `guthub://` project to the local disk, creates a new Metacello registration for the project, `locks` the project so that all references to the project moving forward will be mapped to your local clone, finally the working copy repository list is updated for each loaded package in the project so that it points to the git repo ... this is a hefty list of things that need to be done and a tool/gui is really needed to tie these kinds of operations up into a neat package ... I've described this `project list` before and if you care you can probalby find an old email of mine where I go into a bit more detail about the types of things that you are going to need to do as you start doing serious development with git ... I've been using git and Smalltalk for about 4 years now and there are a few lessons that I've learned along the way ... you'll want to take a slightly different route than what I've done, but it is really time to get serious about a 'Metacello Browser' of some kind ... Dale

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

Mariano, Could you describe this a bit more ... what expression are you using to "specify the github cache location"? 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 > <mailto:btc@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

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

On 07/22/2016 12:13 AM, Dimitris Chloupis wrote: > I don't have the problem you have, if I issue the command to > redownload the zip it does so and it installs it's code fine. At least > the last time I checked with my ChronosManager project to make sure > everything works as expected few months ago. I'd be interested to know exactly what you are doing here ... the Smalltalk expressions that you are using, because what you are saying does not match my understanding of how Metacello works, so I assume that I am not correctly guessing what you are doing. Dale

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

On 07/21/2016 11:54 PM, Dimitris Chloupis wrote: > The zip is not needed and it should be deleted after extraction cause > it serves no role. Agreed --- I've submitted a Metacello issue for this[1 [1] https://github.com/dalehenrich/metacello-work/issues/406 > This create a problem also because if you try to install agin the repo > it won't redownload the zip , instead it will use the same zip. I don't believe that this is true ... the zip file is not the culprit. the Metacello GitHub code does not re-download the zip file because the cache directory already exists ... As pointed out by Peter you need to use the `get` message to inform Metacello that you want the GitHub repo to be refreshed[1] ... [1] http://forum.world.st/how-to-update-monticello-cypress-repository-downloade…) > For me this make little sense because in the vast majority of cases > your intention would be to download the repo version containing the > latest commit. Except when you don't want it downloaded --- the download times can be significant and I chose the explicit download as the default. > There is a command to do this though. Personally I don't like this > behavior. if you always want to download a fresh version of the repo from github, then use `get; load` and you will be happy :) Dale

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dale Henrichs

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. Dale [1] https://github.com/dalehenrich/metacello-work/issues/404 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

July 22, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

Thanks Max for reviewing it :) On Fri, Jul 22, 2016 at 11:08 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 22 Jul 2016, at 07:26, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > > > On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >>> Do you have some test code or a test image I could run to reproduce >>> the problem? >>> >> >> >> The problem is that I cannot reproduce it immediately. It takes me some >> days and likely some image save and start again until I reproduce it. >> > > Could you try > How about something that invokes > > >> >> >>> >>> Now I have one thing for you to try. In the move of DelaySchedulerXxx >>> from milliseconds to microseconds, the code for dealing with clock >>> wrap-around was removed, but I wonder if it was also covering clock >>> jitter as a side effect. Could you try again the SpinScheduler but >>> restore this code... >>> >>> From handletTimerEvent... >>> "Check for clock wrap-around." >>> millisecondNowTick < activeDelayStartTime ifTrue: [ >>> "clock wrapped" >>> self saveResumptionTimes. >>> self restoreResumptionTimes ]. >>> activeDelayStartTime := millisecondNowTick. >>> >>> From runTimerEventLoop... >>> Time millisecondClockValue < millisecondNowTick >>> ifTrue:[ timingSemaphore signal ]. "retry" >>> >>> From startup... >>> activeDelayStartTime := Time millisecondClockValue. >>> >>> >> OK, I put back the code into the spin scheduler. Then I kept using >> milisecond one until I finished the changes. Then I saved image and switch >> to spin one: the image hungs. I cannot even interrupt it. I attach my >> modifications. >> Do they look correct? >> > > I confirm that locked my image also. > > One change of milli to micro was missed at the bottom of > runTimeEventLoop... > That is... > Time millisecondClockValue < microsecondNowTick > to... > Time microsecondClockValue < microsecondNowTick > > (just a case of domestic blindness) [1] :) :) > > > And I reviewed your code and missed itâ¦ > > > cheers -ben > > [1] http://www.urbandictionary.com/define.php?term=domestic%20blindness > > P.S. A trick to debug delays is to bypass interCycleDelay by at the top of > it putting... > true ifTrue: [^self]. > > > > -- Mariano http://marianopeck.wordpress.com

July 22, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >>> Do you have some test code or a test image I could run to reproduce >>> the problem? >>> >> >> >> The problem is that I cannot reproduce it immediately. It takes me some >> days and likely some image save and start again until I reproduce it. >> > > Could you try > How about something that invokes > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate what I do for real but I failed: | commandString | commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 --page-size A4 --image-quality 100 --footer-spacing 10 --header-spacing 10 --margin-top 10 --header-html "http://google.com" --footer-html " http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'. 10 timesRepeat: [ 3 timesRepeat: [ OSSUnixSubprocess new shellCommand: commandString; redirectStdout; redirectStderr; runAndWaitOnExitDo: [ :command :outString :errString | Transcript show: errString. Transcript show: outString. ]. ]. Smalltalk saveSession. ] But...I could not yet reproduce it in the real case either....so I will keep you informed. > >> >>> >>> Now I have one thing for you to try. In the move of DelaySchedulerXxx >>> from milliseconds to microseconds, the code for dealing with clock >>> wrap-around was removed, but I wonder if it was also covering clock >>> jitter as a side effect. Could you try again the SpinScheduler but >>> restore this code... >>> >>> From handletTimerEvent... >>> "Check for clock wrap-around." >>> millisecondNowTick < activeDelayStartTime ifTrue: [ >>> "clock wrapped" >>> self saveResumptionTimes. >>> self restoreResumptionTimes ]. >>> activeDelayStartTime := millisecondNowTick. >>> >>> From runTimerEventLoop... >>> Time millisecondClockValue < millisecondNowTick >>> ifTrue:[ timingSemaphore signal ]. "retry" >>> >>> From startup... >>> activeDelayStartTime := Time millisecondClockValue. >>> >>> >> OK, I put back the code into the spin scheduler. Then I kept using >> milisecond one until I finished the changes. Then I saved image and switch >> to spin one: the image hungs. I cannot even interrupt it. I attach my >> modifications. >> Do they look correct? >> > > I confirm that locked my image also. > > One change of milli to micro was missed at the bottom of > runTimeEventLoop... > That is... > Time millisecondClockValue < microsecondNowTick > to... > Time microsecondClockValue < microsecondNowTick > > Thanks. That did the trick! > (just a case of domestic blindness) [1] :) :) > > cheers -ben > > [1] http://www.urbandictionary.com/define.php?term=domestic%20blindness > > P.S. A trick to debug delays is to bypass interCycleDelay by at the top of > it putting... > true ifTrue: [^self]. > > > -- Mariano http://marianopeck.wordpress.com

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Mariano Martinez Peck

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

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Mariano Martinez Peck

On Fri, Jul 22, 2016 at 11:24 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > > 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. > > That is all very nice! It really makes sense. The sooner we can detect a problem (like a new dependency), the better. > 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 ^^ > > Sure. But it indeed looks better than it was before. Thank you guys. > >> 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