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

[Stephane Ducasse]

Hilaire

We were discussing this with Esteban and he will do a stab at making
sure that we can
deploy desktop applications much easier with Pharo. Because we need it.
Esteban deployed several desktop apps in the past and we should
leverage this knowledge.
I also wants to write this in a forthcoming tutorial.

Stef

On Sun, Jul 30, 2017 at 4:20 PM, Stephane Ducasse
 wrote:
> + 100
>
> 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.
>>
>> 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 

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

[Stephane Ducasse]

+ 100

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

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

[Stephane Ducasse]

We understand that perfectly. Now for us we get money now and may be
not the same in the future.
Then there are the things that
  - must be done and consume a lot: 64bits, uFFI,
  - super important to do git
  - also super important: cleaning and improving the system.
So we pay attention for backward compatibilities but we cannot cover
everything.

Stef

On Fri, Jul 28, 2017 at 3:13 PM, 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.
>
> 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] 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, 

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

[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

[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

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

[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

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

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

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

[Stephane Ducasse]

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.

Stef

On Wed, Jul 26, 2017 at 9:15 PM, Holger Freyther  wrote:
>
>> On 22. Jul 2017, at 12:07, Stephane Ducasse  wrote:
>>
>> Hi holger
>
> Hey Stef!
>
>
>
>> "the growth from Pharo3->Pharo6" us too :)
>> this is why we invested in the bootstrap and this is why we will
>> remove (and we started) packages and classes.
>> And this is also why we will continue to repackage the system.
>
> yes this is very fascinating for Pharo7. It would be nice if we could track 
> size (image+changes but also ram usage, object count) over time to see our 
> progress. I recently added ordinary metric upload to my "bob-bench.org" test 
> and metric tracking. ;)
>
>
> holger

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

[Holger Freyther]

> On 22. Jul 2017, at 12:07, Stephane Ducasse  wrote:
> 
> Hi holger

Hey Stef!



> "the growth from Pharo3->Pharo6" us too :)
> this is why we invested in the bootstrap and this is why we will
> remove (and we started) packages and classes.
> And this is also why we will continue to repackage the system.

yes this is very fascinating for Pharo7. It would be nice if we could track 
size (image+changes but also ram usage, object count) over time to see our 
progress. I recently added ordinary metric upload to my "bob-bench.org" test 
and metric tracking. ;)


holger

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

[Hilaire]

I really find it hard to believe !!

Le 22/07/2017 à 12:04, Stephane Ducasse a écrit :

Yes but there are not concrete enough for me:)


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

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

[Hilaire]

Hi Holger,

With Pharo3 I was proceeding like this, by uninstallation of packages. 
However there is the promise of building from a minimal image, but it is 
not documented AFAIK.


By curiosity, what is the size of your resulting image.

Hilaire

Le 22/07/2017 à 10:43, Holger Freyther a écrit :

I am concerned with the growth from Pharo3->Pharo6 as well and triggered by your mail 
looked at it again. In contrast to ImageCleaner>>#cleanUpForRelease I want to keep 
the Monticello/Metacello packages for now (and don't want to unload them after test).

I call this with "pharo Image eval clean.st" and for whatever reason if I pass 
--save bad things (can't talk to mongod) happen during my system test but that is another 
story (maybe the save is executed at the_next_  image start again).


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

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

[Hilaire]

You are welcome. I also wrote here a few days ago about it. The bug is 
Morphic specific.


Hilaire

Le 22/07/2017 à 09:03, Tudor Girba a écrit :

Aha. Thanks for the clarification.

Doru



On Jul 21, 2017, at 8:59 PM, Hilaire  wrote:

The problem is explained in the ticket: there is a bug in the position where 
the drgeo menu shows up when encapsulated in the Playground. It is not related 
to Glamour however. I may just decide to remove the Dr. Geo menu to avoid the 
bug.


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

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

[Stephane Ducasse]

Hi holger

"the growth from Pharo3->Pharo6" us too :)
this is why we invested in the bootstrap and this is why we will
remove (and we started) packages and classes.
And this is also why we will continue to repackage the system.

Stef

On Sat, Jul 22, 2017 at 10:43 AM, Holger Freyther  wrote:
>
>> On 21. Jul 2017, at 11:19, Hilaire  wrote:
>>
>> Hello people,
>
> Hi!
>
>
>> Here are a few critical issues due to bugs or lack of information or feature 
>> for porting Dr. Geo to P6. There were others critical issues from P6 but 
>> were resolved and will be hopefully integrated, when ?
>>
>>   • Minimal Dr. Geo image
>
> I am concerned with the growth from Pharo3->Pharo6 as well and triggered by 
> your mail looked at it again. In contrast to ImageCleaner>>#cleanUpForRelease 
> I want to keep the Monticello/Metacello packages for now (and don't want to 
> unload them after test).
>
> I call this with "pharo Image eval clean.st" and for whatever reason if I 
> pass --save bad things (can't talk to mongod) happen during my system test 
> but that is another story (maybe the save is executed at the _next_ image 
> start again).
>
>
> World closeAllWindowsDiscardingChanges.
> (RPackage organizer packages select: [:package | package packageName 
> includesSubstring: 'Test'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> beginsWith: 'Versionner'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> beginsWith: 'ProfStef'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> beginsWith: 'Ice'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> beginsWith: 'BaselineOf'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> beginsWith: 'ConfigurationOf'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> endsWith: '-Help'])
> do: [:each | each removeFromSystem ].
> (RPackage organizer packages select: [:package | package packageName 
> endsWith: 'Examples'])
> do: [:each | each removeFromSystem ].
>
> ImageCleaner new cleanUpForRelease.
> Smalltalk snapshot: true andQuit: true.

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

[Stephane Ducasse]

Yes but there are not concrete enough for me :)

On Fri, Jul 21, 2017 at 7:37 PM, Hilaire  wrote:
> Hi Stefane,
>
> Did you read the bug tickets in my previous email?
>
> Hilaire
>
> Le 21/07/2017 à 18:08, Stephane Ducasse a écrit :
>
> I do not understand what the issues that you need in Pharo 60.
>
>
> --
> Dr. Geo
> http://drgeo.eu

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

[Holger Freyther]

> On 21. Jul 2017, at 11:19, Hilaire  wrote:
> 
> Hello people, 

Hi!


> Here are a few critical issues due to bugs or lack of information or feature 
> for porting Dr. Geo to P6. There were others critical issues from P6 but were 
> resolved and will be hopefully integrated, when ?
> 
>   • Minimal Dr. Geo image

I am concerned with the growth from Pharo3->Pharo6 as well and triggered by 
your mail looked at it again. In contrast to ImageCleaner>>#cleanUpForRelease I 
want to keep the Monticello/Metacello packages for now (and don't want to 
unload them after test).

I call this with "pharo Image eval clean.st" and for whatever reason if I pass 
--save bad things (can't talk to mongod) happen during my system test but that 
is another story (maybe the save is executed at the _next_ image start again).


World closeAllWindowsDiscardingChanges.
(RPackage organizer packages select: [:package | package packageName 
includesSubstring: 'Test'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName 
beginsWith: 'Versionner'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName 
beginsWith: 'ProfStef'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName 
beginsWith: 'Ice'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName 
beginsWith: 'BaselineOf'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName 
beginsWith: 'ConfigurationOf'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName endsWith: 
'-Help'])
do: [:each | each removeFromSystem ].
(RPackage organizer packages select: [:package | package packageName endsWith: 
'Examples'])
do: [:each | each removeFromSystem ].

ImageCleaner new cleanUpForRelease.
Smalltalk snapshot: true andQuit: true.

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

[Tudor Girba]

Aha. Thanks for the clarification.

Doru


> On Jul 21, 2017, at 8:59 PM, Hilaire  wrote:
> 
> The problem is explained in the ticket: there is a bug in the position where 
> the drgeo menu shows up when encapsulated in the Playground. It is not 
> related to Glamour however. I may just decide to remove the Dr. Geo menu to 
> avoid the bug.
> 
> 
> Le 21/07/2017 à 20:50, Tudor Girba a écrit :
>> Can you detail your needs regarding the integration with Playground?
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com 

“Live like you mean it."

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

[Hilaire]

The problem is explained in the ticket: there is a bug in the position 
where the drgeo menu shows up when encapsulated in the Playground. It is 
not related to Glamour however. I may just decide to remove the Dr. Geo 
menu to avoid the bug.



Le 21/07/2017 à 20:50, Tudor Girba a écrit :

Can you detail your needs regarding the integration with Playground?


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

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

[Tudor Girba]

Hi,

Can you detail your needs regarding the integration with Playground?

Cheers,
Doru


> On Jul 21, 2017, at 11:19 AM, Hilaire  wrote:
> 
> Hello people, 
> 
> Here are a few critical issues due to bugs or lack of information or feature 
> for porting Dr. Geo to P6. There were others critical issues from P6 but were 
> resolved and will be hopefully integrated, when ?
> 
>   • Minimal Dr. Geo image
>   • Integration with Playground
>   • Export bitmap to clipboard <-- it will be really cool to have.
>   • Universal package for 64 bits
> Other issues: https://launchpad.net/drgeo/+milestone/17.09
> 
> My  initial plane and need is to finish the porting and test by the end of 
> August. Not sure it sounds realistic.
> 
> Hilaire
> 
> -- 
> Dr. Geo
> 
> http://drgeo.eu

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

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

[Hilaire]

Hi Stefane,

Did you read the bug tickets in my previous email?

Hilaire

Le 21/07/2017 à 18:08, Stephane Ducasse a écrit :

I do not understand what the issues that you need in Pharo 60.


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

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

[Stephane Ducasse]

Hilaire

I do not understand what the issues that you need in Pharo 60.

Stef

On Fri, Jul 21, 2017 at 11:19 AM, Hilaire  wrote:
> Hello people,
>
> Here are a few critical issues due to bugs or lack of information or feature
> for porting Dr. Geo to P6. There were others critical issues from P6 but
> were resolved and will be hopefully integrated, when ?
>
> Minimal Dr. Geo image
> Integration with Playground
> Export bitmap to clipboard <-- it will be really cool to have.
> Universal package for 64 bits
>
> Other issues: https://launchpad.net/drgeo/+milestone/17.09
>
> My  initial plane and need is to finish the porting and test by the end of
> August. Not sure it sounds realistic.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu

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

[Hilaire]

Hello people,

Here are a few critical issues due to bugs or lack of information or 
feature for porting Dr. Geo to P6. There were others critical issues 
from P6 but were resolved and will be hopefully integrated, when ?


 * Minimal Dr. Geo image 
 * Integration with Playground 
 * Export bitmap to clipboard
   <-- it will be really cool
   to have.
   
 * Universal package for 64 bits 

Other issues: https://launchpad.net/drgeo/+milestone/17.09

My  initial plane and need is to finish the porting and test by the end 
of August. Not sure it sounds realistic.


Hilaire

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