July 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work?

by Tim Mackinnon

This continues to be a fascination little problem with many angles and solutions. Tim Sent from my iPhone > On 28 Jul 2017, at 21:31, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > JuliÃ¡n > > Sorry, I should have checked my facts before sounding off. I think defining dayOfMonth in the way you show is very counter-intuitive, but that is the definition and I should have checked. > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of JuliÃ¡n Maestri > Sent: 28 July 2017 17:40 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work? > > It still works, probably because dayOfMonth is not what you expected at first glance. > > For a date, you have 3 accessors, and i think you were expecting #dayNumber > > (January third, 1990) day. "Wednesday". > (January third, 1990) dayOfMonth. "January 3" > (January third, 1990) dayNumber. "3" > > > > On 27 July 2017 at 16:43, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > JuliÃ¡n > > I donât know Chalten, but I wonder whether your definition of Person>>ageOn: will work correctly. Could I suggest you add two extra assertions to your test: > > assert: (john ageOn: February fifteenth , 2013) equals: (TimeUnits year with: 49); > assert: (john ageOn: April first , 2013) equals: (TimeUnits year with: 50); > > Clearly these should be true, but I think they will not be â unless Date>>dayOfMonth works in a very counter-intuitive way. > > HTH > > Peter Kenny > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of JuliÃ¡n Maestri > Sent: 27 July 2017 18:58 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work? > > Using https://github.com/ba-st/Chalten the solution was something like this: > > Person>>ageOn: aDate > | difference | > difference := (aDate year distanceFrom: self dateOfBirth year). > ^(aDate dayOfMonth < self dateOfBirth dayOfMonth) > ifTrue: [difference - TimeUnits year unitaryMeasurement] > ifFalse: [difference] > Test for that > testAge > | john | > john := Person namedFirst: 'John' last: 'Doe' born: March fourteenth , 1963. > self > assert: (john ageOn: March thirteenth , 2013) equals: (TimeUnits year with: 49); > assert: (john ageOn: March fourteenth , 2013) equals: (TimeUnits year with: 50); > assert: (john ageOn: March fifteenth , 2013) equals: (TimeUnits year with: 50) > > On 21 July 2017 at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: > Paul - this is very helpful, gosh you learn a lot from what seemed like simple question. > > Your suggestion along with Subbuâs gives an easy workable solution - I also wonder if the method should be in the image along with the comment explaining half open intervals like you have. Do you think there is another name for that end method - displayEnd sounds like it actively displays - I wonder if boundedEnd or completeEnd or finiteEnd might be correct alternatives (or is displayEnd a decent convention that everyone understands?) > > I really have to learn how to submit pull requests (although it seems rather complicated at the moment while the full git integration process is being sorted out). > > Thanks everyone > > Tim > > > On 21 Jul 2017, at 16:40, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > > > Tim Mackinnon wrote > >> I am also wondering if the issue with Timespan is concerning - I was > >> surprised that putting a start and end date left me something that didnât > >> answer my end date presumably down to rounding when itâs converted down to > >> a duration (making me wonder if its better to keep a start and end date > >> and calculate the duration on the fly). > >> > >> Tim > > > > > > The Timespans are half open intervals. > > (https://en.wikipedia.org/wiki/Interval_(mathematics)) > > > > Friday July 21st ends at 11:59:59.99999999999... etc etc etc ...9999PM and > > the 22nd starts at 12:00AM > > > > > > If Timespans were closed intervals like you expect then we'd be out of whack > > with our corner of the universe. That extra clock tick adds complexity. > > > > But I add a method to my image called #displayEnd because I also want them > > to print 3PM-4PM and not 3PM-3:59:59.999999999PM and use that in my print > > statements and rendering for Seaside. > > > > displayEnd > > ^ start + duration > > > > > > > > > > > > > > > > > > -- > > View this message in context: http://forum.world.st/How-to-calculate-someone-s-age-elegantly-Does-Duratio… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

July 28, 2017

Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work?

by PBKResearch

JuliÃ¡n Sorry, I should have checked my facts before sounding off. I think defining dayOfMonth in the way you show is very counter-intuitive, but that is the definition and I should have checked. From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of JuliÃ¡n Maestri Sent: 28 July 2017 17:40 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work? It still works, probably because dayOfMonth is not what you expected at first glance. For a date, you have 3 accessors, and i think you were expecting #dayNumber (January third, 1990) day. "Wednesday". (January third, 1990) dayOfMonth. "January 3" (January third, 1990) dayNumber. "3" On 27 July 2017 at 16:43, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > wrote: JuliÃ¡n I donât know Chalten, but I wonder whether your definition of Person>>ageOn: will work correctly. Could I suggest you add two extra assertions to your test: assert: (john ageOn: February fifteenth , 2013) equals: (TimeUnits year with: 49); assert: (john ageOn: April first , 2013) equals: (TimeUnits year with: 50); Clearly these should be true, but I think they will not be â unless Date>>dayOfMonth works in a very counter-intuitive way. HTH Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> ] On Behalf Of JuliÃ¡n Maestri Sent: 27 July 2017 18:58 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work? Using https://github.com/ba-st/Chalten the solution was something like this: Person>>ageOn: aDate | difference | difference := (aDate year distanceFrom: self dateOfBirth year). ^(aDate dayOfMonth < self dateOfBirth dayOfMonth) ifTrue: [difference - TimeUnits year unitaryMeasurement] ifFalse: [difference] Test for that testAge | john | john := Person namedFirst: 'John' last: 'Doe' born: March fourteenth , 1963. self assert: (john ageOn: March thirteenth , 2013) equals: (TimeUnits year with: 49); assert: (john ageOn: March fourteenth , 2013) equals: (TimeUnits year with: 50); assert: (john ageOn: March fifteenth , 2013) equals: (TimeUnits year with: 50) On 21 July 2017 at 14:25, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works> > wrote: Paul - this is very helpful, gosh you learn a lot from what seemed like simple question. Your suggestion along with Subbuâs gives an easy workable solution - I also wonder if the method should be in the image along with the comment explaining half open intervals like you have. Do you think there is another name for that end method - displayEnd sounds like it actively displays - I wonder if boundedEnd or completeEnd or finiteEnd might be correct alternatives (or is displayEnd a decent convention that everyone understands?) I really have to learn how to submit pull requests (although it seems rather complicated at the moment while the full git integration process is being sorted out). Thanks everyone Tim > On 21 Jul 2017, at 16:40, Paul DeBruicker <pdebruic(a)gmail.com <mailto:pdebruic@gmail.com> > wrote: > > Tim Mackinnon wrote >> I am also wondering if the issue with Timespan is concerning - I was >> surprised that putting a start and end date left me something that didnât >> answer my end date presumably down to rounding when itâs converted down to >> a duration (making me wonder if its better to keep a start and end date >> and calculate the duration on the fly). >> >> Tim > > > The Timespans are half open intervals. > (https://en.wikipedia.org/wiki/Interval_(mathematics)) > > Friday July 21st ends at 11:59:59.99999999999... etc etc etc ...9999PM and > the 22nd starts at 12:00AM > > > If Timespans were closed intervals like you expect then we'd be out of whack > with our corner of the universe. That extra clock tick adds complexity. > > But I add a method to my image called #displayEnd because I also want them > to print 3PM-4PM and not 3PM-3:59:59.999999999PM and use that in my print > statements and rendering for Seaside. > > displayEnd > ^ start + duration > > > > > > > > > -- > View this message in context: http://forum.world.st/How-to-calculate-someone-s-age-elegantly-Does-Duratio… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 28, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by phil＠highoctane.be

On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 28 Jul 2017, at 15:13, phil(a)highoctane.be wrote: > > > > Changing too many things at once is indeed annoying. > > > > Now, I am ready to live with that but at one point, I think that we will > have to move to something like I see done in other fast evolving ecosystems. > > > > In Hadoop for example, Hortonworks (a distribution) moved to a set of > slow evolving substrate that is stable and know to stay stable for a long > period (HDFS, YARN) and a set fast moving releases for projects that do > build on top (Spark). > > > > Holding back on the new things makes you feel like you use a tool of the > past. Living on the bleeding edge is not doable because you need to solve > too many non business centric issues. > > > > There needs to be a combination. > > > > As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 > ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not > develop production code on it at the moment. 7.0 looks okay but there are > lot of changing things there, so, that is also too much for me. > > > > 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on > large collections. I need a platform I can understand and build upon. > > > > There needs to be a semblance of LTS in this. > > But even the LTS concept does not solve all problems. > > Every 2 years there is a new LTS, which is supported for 5 years. > You are a Ubuntu user. I am a CentOS|RHEL user. There support is 10 years. Check this: https://wiki.centos.org/About/Product Official party line here: https://access.redhat.com/support/policy/updates/errata TL;DR: CentOS6: until 2020 for maintenance updates CentOS7, until 2024 for maintenance updates. Using the recent/latest is possible with e.g. * Software Collections https://www.softwarecollections.org/en/ * LXC If one needs a 4.x kernel that is doable too via elrepo. But there is a lot of backport happening by RedHat. There is a reason these guys are making gobs of money: they support business. Frankly I wouldn't touch Ubuntu with a 10 feet pole anymore now that I have 100+ servers running CentOS under management. > But in most projects (the same happened here), you are lazy and wait 5 > years until you *have* to upgrade. > > And by then the difference between what you started with (say 12.04) and > the current stable (say 16.04) can already be huge (remember, you skipped > one LTS release) and the next one is already coming (18.04). > To be frank 14.04 is the only decent release I know. All of the other ones have issues of one kind or another. > > Change is unavoidable, it is not just part of life, it *is* life. > Sure. But change is to be managed and the business is what makes money. So, not catering to business needs is a losing proposition. There is this business by Clement and Esteban that apparently will come to life at one point. I guess business forces may have more impact at that time frame. Wait and see. Phil > > > Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what > not. > > > > 6.x is a great platform and has a lot going for it if stable enough. > > > > I have projects coming my way and using Pharo is an option. Now, I need > something that is not going to shift under my feet. > > > > Especially if I want to embark crew along. > > > > Phil > > > > On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > > > > > > On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > I don't share your enthusiasm. > > > > I once set up a satisfactory build environment for DrGeo, based on P3. > As long as I stay with P3, I can concentrate on DrGeo code: write the code, > then fire up a build script to deploy the application. Now porting to P6 is > a pain: the infrastructure to deploy a desktop application has not evolve > since P3, I have to build again a deployment environment from scratch (VM > support, shrinked/built image, I don't know the promise of minimal image > build up is not palpable for me). > > > > Now If I have to spend days on that, I am not sure I will do it again, I > can't compete against other geometry application if I have to fight against > pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry > to make it explicit but I can't much offer to do both. > > > > > > âI have sometimes the same concerns with Pharo or some tools of the > Pharo ecosystem. I know that we are trying to do our best and regarding the > number of core developers we have already an incredible platform. But > sometimes, you need to very simple updates and because of subtle problems > with VM/configurations/CI/ etc ... this is not that simple and we need to > spend times on boring stuff. > > > > There is no simple solution. > > > > One solution might be that the core developers only focus on core Pharo > functionalities but I think this is somewhat difficult, because most of the > dev are from RMOD. RMOD is a research unit and could not spend all his > money/effort on an engineering process. > > > > Another solution is to grow our community. More people, more companies > to sustain more engineers through the consortium. The more people we are > able to attract, the more people will help to develop working solutions for > problems like deployment or to have bug-fixing intermediate releases. > > > > âThis is why we all need âin the community to do as much as possible > advertisements: lectures at universities, talk to your colleague about > Pharo, do demos in companies, at open-source forums, use Twitter do talk > about Pharo ecosystem, the software you are developing with Pharo. > > Don't hide problems but talk about our nice platform and our community. > > > > We have done this with Stephane in the early days of Pharo at > open-source forums in France and I remember that you come in the community > after we meet you in one of these forums :-) > > So DrGeo2 exists because of this kind of advertisement. > > > > Regards, > > > > -- > > Serge Stinckwich > > UCN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > > > > >

July 28, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by serge.stinckwich＠gmail.com

The main problem is DrGeo is one a few software in the community to be deployed as a desktop app. All the others are dev software (Calypso, Roassal, MOOSE) or web-based app that don't need specific work for deployment. I need to deployed simulation engines that we are building with my team outside the community to people who are not CS experts, so I guess I will need something similar to DrGeo or use a web app. EnvoyÃ© de mon iPhone > Le 28 juil. 2017 Ã 18:43, Hilaire <hilaire(a)drgeo.eu> a Ã©crit : > > Serge, > > The only reason I decided to port DrGeo from Squeak to Pharo is because the project wanted to be business centric with features evolution. Changes was not annoying me, it is one reason I decided to switch to Pharo. But still after many years, I find Pharo frustrating for one willing to develop and deploy a desktop application. > > Hilaire > >> Le 28/07/2017 Ã 11:00, Serge Stinckwich a Ã©crit : >> We have done this with Stephane in the early days of Pharo at open-source forums in France and I remember that you come in the community after we meet you in one of these forums :-) >> So DrGeo2 exists because of this kind of advertisement. >> > > -- > Dr. Geo > http://drgeo.eu > > >

July 28, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Hilaire

Serge, The only reason I decided to port DrGeo from Squeak to Pharo is because the project wanted to be business centric with features evolution. Changes was not annoying me, it is one reason I decided to switch to Pharo. But still after many years, I find Pharo frustrating for one willing to develop and deploy a desktop application. Hilaire Le 28/07/2017 Ã 11:00, Serge Stinckwich a Ã©crit : > We have done this with Stephane in the early days of Pharo at > open-source forums in France and I remember that you come in the > community after we meet you in one of these forums :-) > So DrGeo2 exists because of this kind of advertisement. > -- Dr. Geo http://drgeo.eu

July 28, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Hilaire

Changes is ok. What annoying is announced new feature of P6, but not palpable for common mortal as me (whose main occupation is teaching to teenagers and programming a hobby): * Pharo can now be bootstrapped from source code managed by Git Will a new Pharo user entering Pharo programming get any chance to understand or use it? I don't and it is frustrating. Hilaire Le 28/07/2017 Ã 15:13, phil(a)highoctane.be a Ã©crit : > Changing too many things at once is indeed annoying. > -- Dr. Geo http://drgeo.eu

July 28, 2017

Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work?

by JuliÃ¡n Maestri

It still works, probably because dayOfMonth is not what you expected at first glance. For a date, you have 3 accessors, and i think you were expecting #dayNumber (January third, 1990) day. "Wednesday". (January third, 1990) dayOfMonth. "January 3" (January third, 1990) dayNumber. "3" On 27 July 2017 at 16:43, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > JuliÃ¡n > > > > I donât know Chalten, but I wonder whether your definition of > Person>>ageOn: will work correctly. Could I suggest you add two extra > assertions to your test: > > > > assert: (john ageOn: February fifteenth , 2013) equals: (TimeUnits year > with: 49); > assert: (john ageOn: April first , 2013) equals: (TimeUnits year with: 50); > > > > Clearly these should be true, but I think they will not be â unless > Date>>dayOfMonth works in a very counter-intuitive way. > > > > HTH > > > > Peter Kenny > > > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *JuliÃ¡n Maestri > *Sent:* 27 July 2017 18:58 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] How to calculate someone's age elegantly? > Does Duration work? > > > > Using https://github.com/ba-st/Chalten the solution was something like > this: > > > > Person>>ageOn: aDate > | difference | > difference := (aDate year distanceFrom: self dateOfBirth year). > ^(aDate dayOfMonth < self dateOfBirth dayOfMonth) > ifTrue: [difference - TimeUnits year unitaryMeasurement] > ifFalse: [difference] > > Test for that > > testAge > | john | > john := Person namedFirst: 'John' last: 'Doe' born: March fourteenth , > 1963. > self > assert: (john ageOn: March thirteenth , 2013) equals: (TimeUnits year > with: 49); > assert: (john ageOn: March fourteenth , 2013) equals: (TimeUnits year > with: 50); > assert: (john ageOn: March fifteenth , 2013) equals: (TimeUnits year with: > 50) > > > > On 21 July 2017 at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: > > Paul - this is very helpful, gosh you learn a lot from what seemed like > simple question. > > Your suggestion along with Subbuâs gives an easy workable solution - I > also wonder if the method should be in the image along with the comment > explaining half open intervals like you have. Do you think there is another > name for that end method - displayEnd sounds like it actively displays - I > wonder if boundedEnd or completeEnd or finiteEnd might be correct > alternatives (or is displayEnd a decent convention that everyone > understands?) > > I really have to learn how to submit pull requests (although it seems > rather complicated at the moment while the full git integration process is > being sorted out). > > Thanks everyone > > Tim > > > > On 21 Jul 2017, at 16:40, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > > > Tim Mackinnon wrote > >> I am also wondering if the issue with Timespan is concerning - I was > >> surprised that putting a start and end date left me something that > didnât > >> answer my end date presumably down to rounding when itâs converted down > to > >> a duration (making me wonder if its better to keep a start and end date > >> and calculate the duration on the fly). > >> > >> Tim > > > > > > The Timespans are half open intervals. > > (https://en.wikipedia.org/wiki/Interval_(mathematics)) > > > > Friday July 21st ends at 11:59:59.99999999999... etc etc etc ...9999PM > and > > the 22nd starts at 12:00AM > > > > > > If Timespans were closed intervals like you expect then we'd be out of > whack > > with our corner of the universe. That extra clock tick adds complexity. > > > > But I add a method to my image called #displayEnd because I also want > them > > to print 3PM-4PM and not 3PM-3:59:59.999999999PM and use that in my print > > statements and rendering for Seaside. > > > > displayEnd > > ^ start + duration > > > > > > > > > > > > > > > > > > -- > > View this message in context: http://forum.world.st/How-to- > calculate-someone-s-age-elegantly-Does-Duration-work- > tp4955990p4956114.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

July 28, 2017

Re: [Pharo-users] BaselineOfXxx equivalent of npm's devDependencies

by herby＠mailbox.sk

On July 28, 2017 3:41:37 PM GMT+02:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >And if you really have Towergame-Tests package then you will probably >define it as > > spec package: 'Towergame-Tests' with: [ spec requires: #('Towergame' >'Mocketry') ]. > >And then Tests group can include only Towergame-Tests package because >Mocketry will be loaded as dependency. And I presume I can make the core the default and one including the tests as #dev if I felt like it (don't know the cultural pattern though, if default is always including tests and production is always special in Pharo world, I am nor going to break it; in js/npm world, prod is the default). Thanks, Herby > >2017-07-28 15:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> You need to specify groups for your project: >> >> spec >> group: 'default' with: #('Core' 'Tests' ); >> group: 'Core' with: #('Towergame' ); >> group: 'Tests' with: #('Towergame-Tests' 'Mocketry') >> >> >> Then your script will load default group with everything. And to load >Core >> group use "load: #(Core)" instread of simple #load message. >> >> 2017-07-28 14:33 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: >> >>> Hello! >>> >>> I'd like to ask what is the equivalent of devDependencies >(dependencies >>> to be loaded only when developing, but not when in profuction / used >as a >>> dependency) of a baseline. >>> >>> My baseline method looks like: >>> >>> baseline: spec >>> <baseline> >>> spec for: #common do: [ >>> spec package: 'Towergame' with: [ spec requires: >>> 'GarageGlorp'; requires: 'NeoJSON' ]. >>> spec project: 'GarageGlorp' with: [ >>> spec >>> className: >'ConfigurationOfGarageGlorp'; >>> version: #stable; >>> repository: ' >>> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >>> spec project: 'NeoJSON' with: [ >>> spec >>> className: 'ConfigurationOfNeoJSON'; >>> version: #stable; >>> repository: ' >>> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >>> spec >>> baseline: 'Mocketry' >>> with: [ spec repository: >>> 'github://dionisiydk/Mocketry:v4.0.x' ] >>> ] >>> >>> and I want to have Mocketry as dev-only dependency. How to write it >and >>> how to load it with dev / without dev dependencies? Atm I load it >this way: >>> >>> Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', >(hereRef >>> / 'src') fullName; load. >>> >>> where hereRef is file reference to project dir. >>> >>> Thanks, Herby >>> >>> >>

July 28, 2017

Re: [Pharo-users] BaselineOfXxx equivalent of npm's devDependencies

by herby＠mailbox.sk

On July 28, 2017 3:41:37 PM GMT+02:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >And if you really have Towergame-Tests package then you will probably >define it as > > spec package: 'Towergame-Tests' with: [ spec requires: #('Towergame' >'Mocketry') ]. > >And then Tests group can include only Towergame-Tests package because >Mocketry will be loaded as dependency. Thank you sir. I don't have Towergame-Tests in its own package but I presume I can save it as one (category I do have of course). Herby > >2017-07-28 15:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> You need to specify groups for your project: >> >> spec >> group: 'default' with: #('Core' 'Tests' ); >> group: 'Core' with: #('Towergame' ); >> group: 'Tests' with: #('Towergame-Tests' 'Mocketry') >> >> >> Then your script will load default group with everything. And to load >Core >> group use "load: #(Core)" instread of simple #load message. >> >> 2017-07-28 14:33 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: >> >>> Hello! >>> >>> I'd like to ask what is the equivalent of devDependencies >(dependencies >>> to be loaded only when developing, but not when in profuction / used >as a >>> dependency) of a baseline. >>> >>> My baseline method looks like: >>> >>> baseline: spec >>> <baseline> >>> spec for: #common do: [ >>> spec package: 'Towergame' with: [ spec requires: >>> 'GarageGlorp'; requires: 'NeoJSON' ]. >>> spec project: 'GarageGlorp' with: [ >>> spec >>> className: >'ConfigurationOfGarageGlorp'; >>> version: #stable; >>> repository: ' >>> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >>> spec project: 'NeoJSON' with: [ >>> spec >>> className: 'ConfigurationOfNeoJSON'; >>> version: #stable; >>> repository: ' >>> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >>> spec >>> baseline: 'Mocketry' >>> with: [ spec repository: >>> 'github://dionisiydk/Mocketry:v4.0.x' ] >>> ] >>> >>> and I want to have Mocketry as dev-only dependency. How to write it >and >>> how to load it with dev / without dev dependencies? Atm I load it >this way: >>> >>> Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', >(hereRef >>> / 'src') fullName; load. >>> >>> where hereRef is file reference to project dir. >>> >>> Thanks, Herby >>> >>> >>

July 28, 2017

Re: [Pharo-users] BaselineOfXxx equivalent of npm's devDependencies

by Denis Kudriashov

And if you really have Towergame-Tests package then you will probably define it as spec package: 'Towergame-Tests' with: [ spec requires: #('Towergame' 'Mocketry') ]. And then Tests group can include only Towergame-Tests package because Mocketry will be loaded as dependency. 2017-07-28 15:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > You need to specify groups for your project: > > spec > group: 'default' with: #('Core' 'Tests' ); > group: 'Core' with: #('Towergame' ); > group: 'Tests' with: #('Towergame-Tests' 'Mocketry') > > > Then your script will load default group with everything. And to load Core > group use "load: #(Core)" instread of simple #load message. > > 2017-07-28 14:33 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > >> Hello! >> >> I'd like to ask what is the equivalent of devDependencies (dependencies >> to be loaded only when developing, but not when in profuction / used as a >> dependency) of a baseline. >> >> My baseline method looks like: >> >> baseline: spec >> <baseline> >> spec for: #common do: [ >> spec package: 'Towergame' with: [ spec requires: >> 'GarageGlorp'; requires: 'NeoJSON' ]. >> spec project: 'GarageGlorp' with: [ >> spec >> className: 'ConfigurationOfGarageGlorp'; >> version: #stable; >> repository: ' >> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >> spec project: 'NeoJSON' with: [ >> spec >> className: 'ConfigurationOfNeoJSON'; >> version: #stable; >> repository: ' >> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]. >> spec >> baseline: 'Mocketry' >> with: [ spec repository: >> 'github://dionisiydk/Mocketry:v4.0.x' ] >> ] >> >> and I want to have Mocketry as dev-only dependency. How to write it and >> how to load it with dev / without dev dependencies? Atm I load it this way: >> >> Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef >> / 'src') fullName; load. >> >> where hereRef is file reference to project dir. >> >> Thanks, Herby >> >> >

July 28, 2017