January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 17:17, Mariano Martinez Peck a Ã©crit : > > > On Sat, Jan 23, 2016 at 12:42 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : > > Hi Thierry, > > The Metacello answer here would be "it's up to you" hahahaha. I > don't > have a strong opinion. Most of the times I am in the similar > situation, > I tend to use fixed versions when the projects are really > coupled and > one cannot work without the other. And use #stable when they are > less > coupled and I would not die if that dependency is broken for > some time > until fixed. > > What would be the problem of using #stable? That I may release new > versions which may break the user API, or I may introduce bugs > that I > didn't discover before, etc etc. It won't be fun if I update > GitFileTree > and suddenly I cannot commit anymore. But at the same time, you > don't > expect a user to be updating GitFileTree in his image. In > addition, you > have a CI that will tell you immediately if the build fail or > your tests > failed. > > If you ask me, I think I would use fixed versions. Then, whenever I > release a new version, you give it a try, you test it, you try > it in the > CI, etc. If everything seems to work, then I would update your > conf and > point to new version. > > > Yes. What is interesting is I can just target the baseline of > OSSubprocess in that case, using that url > > github://marianopeck/OSSubprocess:v0.2.0/repository > > which is convenient. > Yes, I know, I implemented part of that support into gitfiletree urls (commit ids and tags don't work with git clone, of course). > Yes, and not only tags, what everything (commits, branches, etc). See > this post: > http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… > > This is the supported pattern: > > github://<username>/<projectname>[:<branch>|<tag>|<SHA>][/<path>] I was thinking of the wildcard support Dale implemented ;) Thierry > :) > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Mariano Martinez Peck

On Sat, Jan 23, 2016 at 12:42 PM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : > >> Hi Thierry, >> >> The Metacello answer here would be "it's up to you" hahahaha. I don't >> have a strong opinion. Most of the times I am in the similar situation, >> I tend to use fixed versions when the projects are really coupled and >> one cannot work without the other. And use #stable when they are less >> coupled and I would not die if that dependency is broken for some time >> until fixed. >> >> What would be the problem of using #stable? That I may release new >> versions which may break the user API, or I may introduce bugs that I >> didn't discover before, etc etc. It won't be fun if I update GitFileTree >> and suddenly I cannot commit anymore. But at the same time, you don't >> expect a user to be updating GitFileTree in his image. In addition, you >> have a CI that will tell you immediately if the build fail or your tests >> failed. >> >> If you ask me, I think I would use fixed versions. Then, whenever I >> release a new version, you give it a try, you test it, you try it in the >> CI, etc. If everything seems to work, then I would update your conf and >> point to new version. >> > > Yes. What is interesting is I can just target the baseline of OSSubprocess > in that case, using that url > > github://marianopeck/OSSubprocess:v0.2.0/repository > > which is convenient. > > Yes, and not only tags, what everything (commits, branches, etc). See this post: http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… This is the supported pattern: github://<username>/<projectname>[:<branch>|<tag>|<SHA>][/<path>] :) -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Eliot Miranda

Hi Both, Hi Dale, > On Jan 23, 2016, at 7:42 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >> Hi Thierry, >> >> The Metacello answer here would be "it's up to you" hahahaha. I don't >> have a strong opinion. Most of the times I am in the similar situation, >> I tend to use fixed versions when the projects are really coupled and >> one cannot work without the other. And use #stable when they are less >> coupled and I would not die if that dependency is broken for some time >> until fixed. >> >> What would be the problem of using #stable? That I may release new >> versions which may break the user API, or I may introduce bugs that I >> didn't discover before, etc etc. It won't be fun if I update GitFileTree >> and suddenly I cannot commit anymore. But at the same time, you don't >> expect a user to be updating GitFileTree in his image. In addition, you >> have a CI that will tell you immediately if the build fail or your tests >> failed. >> >> If you ask me, I think I would use fixed versions. Then, whenever I >> release a new version, you give it a try, you test it, you try it in the >> CI, etc. If everything seems to work, then I would update your conf and >> point to new version. > > Yes. What is interesting is I can just target the baseline of OSSubprocess in that case, using that url > > github://marianopeck/OSSubprocess:v0.2.0/repository > > which is convenient. > > Thierry Maybe soon enough we can find a way of integrating CI server test results for specific packages with Metacello and talk not about #stable, but #greenest. Green means tests have passed, but i think the connotation of green=young is common too, no? (viÃ±o verde). This doesn't protect against API changes, when the tests get changed to match the new API, but that implies versioning the API separately from the package so one can ask for #greenest #api=1.23.

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : > Hi Thierry, > > The Metacello answer here would be "it's up to you" hahahaha. I don't > have a strong opinion. Most of the times I am in the similar situation, > I tend to use fixed versions when the projects are really coupled and > one cannot work without the other. And use #stable when they are less > coupled and I would not die if that dependency is broken for some time > until fixed. > > What would be the problem of using #stable? That I may release new > versions which may break the user API, or I may introduce bugs that I > didn't discover before, etc etc. It won't be fun if I update GitFileTree > and suddenly I cannot commit anymore. But at the same time, you don't > expect a user to be updating GitFileTree in his image. In addition, you > have a CI that will tell you immediately if the build fail or your tests > failed. > > If you ask me, I think I would use fixed versions. Then, whenever I > release a new version, you give it a try, you test it, you try it in the > CI, etc. If everything seems to work, then I would update your conf and > point to new version. Yes. What is interesting is I can just target the baseline of OSSubprocess in that case, using that url github://marianopeck/OSSubprocess:v0.2.0/repository which is convenient. Thierry

Jan. 23, 2016

Re: [Pharo-dev] Add to Package

by Mariano Martinez Peck

On Sat, Jan 23, 2016 at 12:02 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 23/1/16 15:14, Esteban A. Maringolo a Ã©crit : > >> 2016-01-23 4:48 GMT-03:00 stepharo <stepharo(a)free.fr>: >> >>> Hi >>> >>> in MC add to package should use a FastList because the logic right now is >>> really stupid. >>> >> I would also add the "add repo" to the package, with a list of the >> recently used repos. Or add the repo to a multiple number of packages. >> > > That too :) > >> >> Also...previously, when you typed in the text input, it would hide/filter out/gray the none matching ones and only let highlighted the ones matching what you typed. That doesn't seem to work anymore :( -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] Use cases for methods with optional parameters

by stepharo

Le 23/1/16 03:38, Ben Coman a Ã©crit : > Sounds interesting, but my head hurts trying to think about this more > deeply :) > so I'm going to keep at a superficial level on this for now. > So just thinking out loud... > > If you have > mother1 := foo:(bar:zork:fork) > mother2 := foo:bar:(zork:bork:) I'm not sure that this is allows in the same class. We should check that in Python or ruby. > When you search for senders of #foo:bar: what do you get back and how > to display it? We should display every caller. > > Maybe a two level tree list with the option combinations appearing at > the top level and each of their senders at the second level, hiding > any top level items that don't have children. > foo:bar: > foo:bar:zork: > foo:bar:fork: > foor:bar:bork > foo:bar:zork:fork: > foo:bar:fork:zork: > foo:bar:zork:bork: > foo:bar:bork:zork: > > Actually, full any order combination probably becomes unwieldly. > Maybe there should be a constraint that optional arguments can be > skipped but when used must be used in sequence. > > cheers -ben > > btw, how do you mean relationship? I mean knowing the mother from the children > Do you mean using a Slots > mechanism like the relationship demo in the Flexible Object layouts > paper? no > https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayou… > > On Sat, Jan 23, 2016 at 3:29 AM, stepharo <stepharo(a)free.fr> wrote: >> Ben >> >> We were thinking also about reflection. >> >> >> So may be we should introduce a relationship between the method and its >> actual implementation. >> >> Imagine that >> mother := foo:(bar:zork:) >> mother children >> foo:bar: >> foo:bar:zork: >> >> then >> senders (foo:bar:) >> => >> sender (motherOf(foo:bar:)) >> >> where motherOf is a back pointer from the expanded method into its mother >> But it means that method using foo:bar: should somehow "mention" that they >> will >> use motherOf (foo:bar:). >> >> >> >> Le 22/1/16 01:41, Ben Coman a Ã©crit : >> >>> I don't have any use cases right now, but I'll keep my eyes open. But >>> an example (that is maybe too basic to mess with) is the >>> #at:ifAbsent: pattern. For example, the following would be >>> "deleted" >>> >>> Dictionary>>.at: key >>> ^ self at: key ifAbsent: [self errorKeyNotFound: key] >>> >>> and you would only have.... >>> >>> Dictionary>>at: key ifAbsent: aBlock >>> <optional: ifAbsent default: [ self errorKeyNotFound: key]> >>> >>> The big in-Image example would be... >>> >>> TClass>> >>> subclass: aName >>> uses: aTraitCompositionOrArray >>> instanceVariableNames: someInstanceVariableNames >>> classVariableNames: someClassVariableNames >>> poolDictionaries: someSharedPoolNames >>> package: aCategory >>> <optional: uses default: {}> >>> <optional: instanceVariableNames default: ''> >>> <optional: classVariableNames default: ''> >>> <optional: poolDictionaries default:''> >>> <optional: package 'Unclassified'> >>> >>> Now I wonder about senders & implementers searchability, and if >>> "virtual" methods are generated in all combinations of optional >>> parameters and show up in the system browser list, but show the "main" >>> method as their source. >> >> >

Jan. 23, 2016

Re: [Pharo-dev] Add to Package

by stepharo

Le 23/1/16 15:14, Esteban A. Maringolo a Ã©crit : > 2016-01-23 4:48 GMT-03:00 stepharo <stepharo(a)free.fr>: >> Hi >> >> in MC add to package should use a FastList because the logic right now is >> really stupid. > I would also add the "add repo" to the package, with a list of the > recently used repos. Or add the repo to a multiple number of packages. That too :) > > Regards! > > Esteban A. Maringolo > >

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Mariano Martinez Peck

Hi Thierry, The Metacello answer here would be "it's up to you" hahahaha. I don't have a strong opinion. Most of the times I am in the similar situation, I tend to use fixed versions when the projects are really coupled and one cannot work without the other. And use #stable when they are less coupled and I would not die if that dependency is broken for some time until fixed. What would be the problem of using #stable? That I may release new versions which may break the user API, or I may introduce bugs that I didn't discover before, etc etc. It won't be fun if I update GitFileTree and suddenly I cannot commit anymore. But at the same time, you don't expect a user to be updating GitFileTree in his image. In addition, you have a CI that will tell you immediately if the build fail or your tests failed. If you ask me, I think I would use fixed versions. Then, whenever I release a new version, you give it a try, you test it, you try it in the CI, etc. If everything seems to work, then I would update your conf and point to new version. Cheers, On Sat, Jan 23, 2016 at 9:09 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi, > > I'm looking at OSSubprocess use as a requirement for GitFileTree and I > wonder if it is wise to list the dependency on OSSubprocess #stable or to > set to a specific version (v0.2)? > > Thanks, > > Thierry > > -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] Add to Package

by Esteban A. Maringolo

2016-01-23 4:48 GMT-03:00 stepharo <stepharo(a)free.fr>: > Hi > > in MC add to package should use a FastList because the logic right now is > really stupid. I would also add the "add repo" to the package, with a list of the recently used repos. Or add the repo to a multiple number of packages. Regards! Esteban A. Maringolo

Jan. 23, 2016

Re: [Pharo-dev] Get an image from monkey job

by Ben Coman

On Sat, Jan 23, 2016 at 7:12 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: > Hi, > > With the current configuration, it is not possible: the workspace is deleted > after the execution (so the image generated too...). > Maybe it should be nice to delete the workspace only before the job, in this > way, one can be able to retrieve the generated image and debug it? But if there are several FixReviewNeeded, wouldn't all except the last get bumped out? Maybe workspaces could be kept for a short time ~ 6 to 24 hours? I guess it all depends on CI space available. cheers -ben > Can a Pharo CI admin change this configuration? > > Cheers, > Vincent > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Yuriy Tymchuk > Sent: samedi 23 janvier 2016 11:52 > To: Pharo Development List > Subject: [Pharo-dev] Get an image from monkey job > > Hi, > > sometimes some strange tests fail while money is checking the > slice/configuration. And while the failures are not related to the > contribution sometimes I want to know what happened and maybe fix it. Is it > possible to get the resulting image to investigate it? > > Cheers. > Uko > >

Jan. 23, 2016