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

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

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

July 28, 2017

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

by Sven Van Caekenberghe

> 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. 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 <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 phil＠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.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

BaselineOfXxx equivalent of npm's devDependencies

by 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 <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] Critical issues for Dr. Geo on P6

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

July 28, 2017

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

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

[ANN] Mustache moved to github

by Norbert Hartl

In the spirit of git notificationâ¦I moved mustache to github. https://github.com/noha/mustache <https://github.com/noha/mustache> Enjoy! Norbert

July 28, 2017

Re: [Pharo-users] Shameful advertisement

by 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 <serge.stinckwich(a)gmail.com> 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/ >

July 28, 2017

Shameful advertisement

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

July 28, 2017

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

by Serge Stinckwich

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