- Pharo-users - lists.pharo.org

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

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