[Pharo-users] Iceberg needs to gracefully revert to readonly

[Herby Vojčík]

Hello!

IMNSHO, now that Iceberg has three vendor-specific protocol (and before 
as well, because of people like me who do not have github account), 
Iceberg needs to gracefully revert to readonly access in case 
credentials are not present or do not allow full access to repository.


This is primarily for dependencies of Configurations and Baselines. If 
any of them is github://, bitbucket:// or gitlab:// and the user happens 
not to have account on those systems, he will get LGit ssh credential error.


Thoughts? ETA?

Herby

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

[Hilaire]

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.


Hilaire

Le 27/07/2017 à 21:28, Stephane Ducasse a écrit :

Indeed.
I dreamed about the bootstrap in 2002:)  so now I enjoy it:)
What I can tell you is that we will do another pass because we want
Pharo core around 200 k + 300 k for a slow vm. And we will have one
guy working on it during his PhD.
We will continue to push with Pavel, christophe and guille too.


--
Dr. Geo
http://drgeo.eu

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

[Serge Stinckwich]

On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  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/

[Pharo-users] Shameful advertisement

[Serge Stinckwich]

Hi all,

I was talking about Twitter in my previous email. This is a nice way to
advertise the work of the community to others communities.

Now some **shameful advertisement** : you can subscribe to my Twitter
account here:
https://twitter.com/SergeStinckwich

I try my best to publish info about Pharo/Smalltalk community and with my
1733 followers I can have some impact sometimes.

Please send me a private email if you want to advertise something specific
about your work.

They are other interesting accounts to follow:
- PharoProject: https://twitter.com/pharoproject
- PharoJS: https://twitter.com/pharojs
​- Stéphane Ducasse: https://twitter.com/stephaneducasse
- Tudor Girba : https://twitter.com/girba
​- ObjectProfile : https://twitter.com/ObjectProfile

​and many others !​

​Regards,​

-- 
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-users] Shameful advertisement

[Luke Gorrie]

Hi Serge,

Just wanted to say that you guys do a really nice job of advocating for
Pharo and promoting it :).

I joined the association now and will be sure to plug Pharo. It's great. I
wouldn't build my current application at all if I didn't have
Pharo/Glamour/Roassal as a base... it would be too much work.




On 28 July 2017 at 11:10, Serge Stinckwich 
wrote:

> Hi all,
>
> I was talking about Twitter in my previous email. This is a nice way to
> advertise the work of the community to others communities.
>
> Now some **shameful advertisement** : you can subscribe to my Twitter
> account here:
> https://twitter.com/SergeStinckwich
>
> I try my best to publish info about Pharo/Smalltalk community and with my
> 1733 followers I can have some impact sometimes.
>
> Please send me a private email if you want to advertise something specific
> about your work.
>
> They are other interesting accounts to follow:
> - PharoProject: https://twitter.com/pharoproject
> - PharoJS: https://twitter.com/pharojs
> ​- Stéphane Ducasse: https://twitter.com/stephaneducasse
> - Tudor Girba : https://twitter.com/girba
> ​- ObjectProfile : https://twitter.com/ObjectProfile
>
> ​and many others !​
>
> ​Regards,​
>
> --
> Serge Stinckwich
> UCN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>

[Pharo-users] [ANN] Mustache moved to github

[Norbert Hartl]

In the spirit of git notification…I moved mustache to github.

https://github.com/noha/mustache 

Enjoy!

Norbert

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

[Tim Mackinnon]

Just to chip in - I hope we can get past this bump (and I think it is a bump).

I am actually ecstatic that recent improvements - a 64bit vm, a minimal image 
and git integration, have opened the door to Pharo working on AWS Lambda. Also 
having a CI system to help crank these things out is also a big win.

So I applaud the work, progress and vision that has got us here !

All large systems accrue infrastructure and unexpected dependencies that take 
effort to modernise. I don't think this is solely a Pharo thing. (I just 
recently worked with a Java team that used SnapCI for builds, and when it was 
shut down it was 6+ weeks to migrate off it and stabilise things).

We are close - we just need to rally around to get a good stable base that can 
support the next round of revolution (aka P7).

Tim

Sent from my iPhone

> On 28 Jul 2017, at 11:00, Serge Stinckwich  wrote:
> 
> 
> 
>> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  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/

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

[Stephane Ducasse]

Hilaire

We invested 3 years of PhD of Guillermo + 8 months of hard work of christophe
and guillermo. Pavel spent years to produce the mini image and now
with the bootstrap
it is opening a lot of possibilities. We will do it and it will work.
And ***I LOVE THEIR WORK***. I DREAMED about it more than 15 years ago
and they make it
true. This is a game changer. It forces the system to be a lot more
modular and cleaner.

In the future people will take a core and their own configuration and
build whatever they want.
And we will build Pharo based on this core.

I understand that you want to focus on DrGeo but the situation is like that.
There is no magic. Stay in Pharo 30 but do not expect people will help
you because Pharo
is now more than 4 years old.

I think that Pavel was really supportive with you.
Now when I see your emails, I often see you ranting and people takes
on their free time to help you
so the more you rant the less people will help you. Ask yourself when
it is the last time that you fixed a typo in Pharo and proposed a fix
or just reproduce a bug that is not on your direct interest.
You see people are sensible to this matter.

I imagine that you know the soup of stone story. Pharo is our common
goods and this is important
that we all pay attention to it.

Stef


On Fri, Jul 28, 2017 at 10:34 AM, Hilaire  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.
>
> Hilaire
>
> Le 27/07/2017 à 21:28, Stephane Ducasse a écrit :
>
> Indeed.
> I dreamed about the bootstrap in 2002 :) so now I enjoy it :)
> What I can tell you is that we will do another pass because we want
> Pharo core around 200 k + 300 k for a slow vm. And we will have one
> guy working on it during his PhD.
> We will continue to push with Pavel, christophe and guille too.
>
>
> --
> Dr. Geo
> http://drgeo.eu

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

[Herby Vojčík]

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

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

[p...@highoctane.be]

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.

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.stinckw...@gmail.com> wrote:

>
>
> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  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/
>

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

[Sven Van Caekenberghe]

> On 28 Jul 2017, at 15:13, p...@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.

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).

Change is unavoidable, it is not just part of life, it *is* life.

> 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 
>  wrote:
> 
> 
> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  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/
> 

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

[Denis Kudriashov]

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 :

> 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
>
> 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/Ph
> aro/MetaRepoForPharo60/main' ].
> spec project: 'NeoJSON' with: [
> spec
> className: 'ConfigurationOfNeoJSON';
> version: #stable;
> repository: 'http://smalltalkhub.com/mc/Ph
> aro/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
>
>

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

[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 :

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

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

[herby]

On July 28, 2017 3:41:37 PM GMT+02:00, Denis Kudriashov  
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 :
>
>> 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 :
>>
>>> 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
>>>
>>> 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
>>>
>>>
>>

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

[herby]

On July 28, 2017 3:41:37 PM GMT+02:00, Denis Kudriashov  
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 :
>
>> 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 :
>>
>>> 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
>>>
>>> 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
>>>
>>>
>>

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

[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  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-boun...@lists.pharo.org] *On
> Behalf Of *Julián Maestri
> *Sent:* 27 July 2017 18:58
> *To:* Any question about pharo is welcome 
> *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  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  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.999... etc etc etc ...PM
> 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.9PM 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.
> >
>
>
>

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

[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, p...@highoctane.be a 
écrit :

Changing too many things at once is indeed annoying.



--
Dr. Geo
http://drgeo.eu

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

[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

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

[serge . stinckwich]

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

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

[p...@highoctane.be]

On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe  wrote:

>
> > On 28 Jul 2017, at 15:13, p...@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.stinckw...@gmail.com> wrote:
> >
> >
> > On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  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 R

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

[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-boun...@lists.pharo.org] On Behalf Of 
Julián Maestri
Sent: 28 July 2017 17:40
To: Any question about pharo is welcome 
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 mailto:pe...@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-boun...@lists.pharo.org 
 ] On Behalf Of Julián Maestri
Sent: 27 July 2017 18:58
To: Any question about pharo is welcome 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 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   > 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.999... etc etc etc ...PM 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.9PM 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.
>

 

 

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

[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  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-boun...@lists.pharo.org] On Behalf Of 
> Julián Maestri
> Sent: 28 July 2017 17:40
> To: Any question about pharo is welcome 
> 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  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-boun...@lists.pharo.org] On Behalf Of 
> Julián Maestri
> Sent: 27 July 2017 18:58
> To: Any question about pharo is welcome 
> 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  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  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.999... etc etc etc ...PM 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.9PM 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.
> >
> 
>  
>  

[Pharo-users] Pharo Seaside RESTful services pragma question

[Greg Hutchinson]

I am new to Pharo/Seaside and it has been a long time since I have used
Smalltalk. I am trying to make a RESTful service and can’t get the pragmas
to work the way I think it should. (This might be the problem already).



 Ie Here is my list method within class TeamMembers which is a direct
subclass of WARestfulHandler.

list

   

  ^ String streamContents: [ :stream |

   self teamMembers do: [ :each |

   stream nextPutAll: each ; crlf ]

   ]



and



listJson







   ^ (Array streamContents: [ :stream |

  self teamMembers do: [ :each |

 stream nextPut: (Dictionary new

at: 'name' put: each ;

yourself) ] ])

  asJavascript







After doing all the proper registration WAAdmin register: TeamMembers at:
'team-members' when I execute in the browser (
http://localhost:8080/team-members) I received the message

/team-members not found
but if I execute (http://localhost:8080/team-members/list), it brings back
the team member list. (However, I didn’t think I would have to add /list to
the URL).



This seems to contradict the documentation in
http://book.seaside.st/book/advanced/restful/getting-started/define-handler.





However, If I override the TeamMembers>>

createRoutes

| route pType|

pType := WAFullMimeTypeMatch main:'text' sub: 'json' .

route := WASimpleRoute method: 'GET' selector: #listJson
produces: pType consumes: WAWildcardMimeTypeMatch new.

^ OrderedCollection new

"GET"

add: route;

add: (WARoute get: #list);

yourself.



Then I get the expected behaviour when I browse to (
http://localhost:8080/team-members) and using curl. (ie.

curl -H "Accept: text/json" http://localhost:8080/team-members

to get the Json response.



When I debug the difference in the routes, it looks like using the pragmas,
I get WAComplexRoute(s) but of course in the overridden method
createRoutes, I get WASimpleRoutes.



Is this the way it is supposed to work?




Thanks in advance for any hints.