- Pharo-users - lists.pharo.org

Re: [Pharo-users] STON question

by Sven Van Caekenberghe

First question is, why do anything at all ? STON toStringPretty: <your game collector object> Then loading is as simple as STON fromString: '...' Next step is to customise how STON output is generated (but again, why ?). You do that by writing both an #stonOn: and a #fromSton: method (look for implementors for examples). If you really want, you could get something like: GameCollector [ GameItem { #name : 'Final Fantasy X', #console : #PS2, #hasDocumentation : false, #hasBox : true, #finished : true, #condition : 'Good', #quotation : 10, #critics : 18, #comments : 'quite cool in fact' }, GameItem { #name : 'Final Fantasy XII', #console : '', #hasDocumentation : true, #hasBox : false, #finished : false, #condition : 'Good', #quotation : 10, #critics : 15, #comments : '' } ] to work. Something like (untested): GameCollector>>stonOn: stonWriter stonWriter writeObject: self do: [ stonWriter encodeList: self items ] GameCollector class>>fromSton: stonReader | collector | collector := self new. stonReader parseListDo: [ :each | collector addGameItem: each ]. ^ collector > On 30 Jul 2017, at 17:39, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi sven > > I'm coding with my son a game collector application :) > We want to save our collection with STON > > So far we have > > GameCollector asSTON >> > > String streamContents: [ :s | STON put: self onStreamPretty: s ] > > and we get > > GameCollector { > #items : OrderedCollection [ > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > ] > } > > And this is good. > Now I wanted to use STON to save the items without the class structure > > to get something like > > OrderedCollection [ > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > ] > > > I coded as > > GameCollector >> asSTON > > ^ String streamContents: [ :s | STON put: items onStreamPretty: s ] > > and STON is not happy on reload. > > I know that we are bending the rules. > Is there a way to do simply what I want? > > I could leave also with > > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > > Stef >

July 30, 2017

Re: [Pharo-users] STON question

by Cyril Ferlicot D.

Le 30/07/2017 Ã 17:39, Stephane Ducasse a Ã©crit : > Hi sven > > I'm coding with my son a game collector application :) > We want to save our collection with STON > > So far we have > > GameCollector asSTON >> > > String streamContents: [ :s | STON put: self onStreamPretty: s ] > > and we get > > GameCollector { > #items : OrderedCollection [ > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > ] > } > > And this is good. > Now I wanted to use STON to save the items without the class structure > > to get something like > > OrderedCollection [ > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > ] > > > I coded as > > GameCollector >> asSTON > > ^ String streamContents: [ :s | STON put: items onStreamPretty: s ] > > and STON is not happy on reload. > > I know that we are bending the rules. > Is there a way to do simply what I want? > > I could leave also with > > GameItem { > #name : 'Final Fantasy X', > #console : #PS2, > #hasDocumentation : false, > #hasBox : true, > #finished : true, > #condition : 'Good', > #quotation : 10, > #critics : 18, > #comments : 'quite cool in fact' > }, > GameItem { > #name : 'Final Fantasy XII', > #console : '', > #hasDocumentation : true, > #hasBox : false, > #finished : false, > #condition : 'Good', > #quotation : 10, > #critics : 15, > #comments : '' > } > > Stef > Hi, Maybe you can just create a new GameCollector on the reading. "protocol: instance-creation" GameCollector class>>importFromFile: aFile ^ self new items: (STON fromString: aFile contents); yourself -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 30, 2017

STON question

by Stephane Ducasse

Hi sven I'm coding with my son a game collector application :) We want to save our collection with STON So far we have GameCollector asSTON >> String streamContents: [ :s | STON put: self onStreamPretty: s ] and we get GameCollector { #items : OrderedCollection [ GameItem { #name : 'Final Fantasy X', #console : #PS2, #hasDocumentation : false, #hasBox : true, #finished : true, #condition : 'Good', #quotation : 10, #critics : 18, #comments : 'quite cool in fact' }, GameItem { #name : 'Final Fantasy XII', #console : '', #hasDocumentation : true, #hasBox : false, #finished : false, #condition : 'Good', #quotation : 10, #critics : 15, #comments : '' } ] } And this is good. Now I wanted to use STON to save the items without the class structure to get something like OrderedCollection [ GameItem { #name : 'Final Fantasy X', #console : #PS2, #hasDocumentation : false, #hasBox : true, #finished : true, #condition : 'Good', #quotation : 10, #critics : 18, #comments : 'quite cool in fact' }, GameItem { #name : 'Final Fantasy XII', #console : '', #hasDocumentation : true, #hasBox : false, #finished : false, #condition : 'Good', #quotation : 10, #critics : 15, #comments : '' } ] I coded as GameCollector >> asSTON ^ String streamContents: [ :s | STON put: items onStreamPretty: s ] and STON is not happy on reload. I know that we are bending the rules. Is there a way to do simply what I want? I could leave also with GameItem { #name : 'Final Fantasy X', #console : #PS2, #hasDocumentation : false, #hasBox : true, #finished : true, #condition : 'Good', #quotation : 10, #critics : 18, #comments : 'quite cool in fact' }, GameItem { #name : 'Final Fantasy XII', #console : '', #hasDocumentation : true, #hasBox : false, #finished : false, #condition : 'Good', #quotation : 10, #critics : 15, #comments : '' } Stef

July 30, 2017

Re: [Pharo-users] Iceberg and removing packages

by Esteban A. Maringolo

I got into the pharo-local/iceberg/... and git rm'ed the directory, commited and synchronized the project in Iceberg. I hope it doesn't break anything since I don't know how much "magic" does Iceberg behind the scenes other than automating the git commands and providing a centralized UI. What is the "This is all you need to read to understand Iceberg?" document I should read? I read its wiki, but it seems there is more to go. Regards! Esteban A. Maringolo 2017-07-30 11:28 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: > This was supposedly fixed in April https://github.com/pharo-vcs/iceberg/issues/317 > > however I had the same issue ~two months ago, so I had to delete the packages by hand. > > P > > > On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote: >> Hi, >> >> I'm playing around with Iceberg in Pharo 6, and even when I find the >> workflow streamlined, but since it doesn't map 1:1 with git workflow >> from other IDEs or command line, I find myself not knowing how to do >> certain tasks. >> >> One thing that happened is that I published a few packages to one of >> my repos in Github, then I decided to remove one of the packages from >> the repo, then I synchronized it but in the repo there is still is the >> package folder for the package I removed. >> >> What should I do to definitely remove those files from the commit? >> >> Regards! >> >> Esteban A. Maringolo >> >

July 30, 2017

Re: [Pharo-users] Iceberg and removing packages

by Peter Uhnak

This was supposedly fixed in April https://github.com/pharo-vcs/iceberg/issues/317 however I had the same issue ~two months ago, so I had to delete the packages by hand. P On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote: > Hi, > > I'm playing around with Iceberg in Pharo 6, and even when I find the > workflow streamlined, but since it doesn't map 1:1 with git workflow > from other IDEs or command line, I find myself not knowing how to do > certain tasks. > > One thing that happened is that I published a few packages to one of > my repos in Github, then I decided to remove one of the packages from > the repo, then I synchronized it but in the repo there is still is the > package folder for the package I removed. > > What should I do to definitely remove those files from the commit? > > Regards! > > Esteban A. Maringolo >

July 30, 2017

Re: [Pharo-users] Pharo 61 crashes on iceberg history

by Stephane Ducasse

Thanks Julian Esteban is on vacation right now. But this is the right place. Thanks again. On Sun, Jul 30, 2017 at 3:51 AM, JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: > I'm almost sure this is not the right place to report it. > > Im having a vm crash when looking at the history of a repository on iceberg. > >> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) >> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse >> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. >> ./pharo-ui: line 11: 2011 Aborted (core dumped) >> "$DIR"/"pharo-vm/pharo" "$@" > > > Pharo downloaded from get.pharo.org/64/ on Ubuntu 16.04 (64bit) > > Has somebody had this problem? > Where's the right place to report this? > > Thanks, JuliÃ¡n

July 30, 2017

Re: [Pharo-users] Pharo Seaside RESTful services pragma question

by Stephane Ducasse

Argh I will try to migrate it to Pillar for real. On Sun, Jul 30, 2017 at 10:21 AM, Johan Brichau <johan(a)inceptive.be> wrote: > The Seaside book REST chapter should be deprecated or changed. > > Take a look here for the updated info: https://github.com/ > SeasideSt/Seaside/wiki/Seaside-REST > > Johan > > > On 30 Jul 2017, at 01:46, Greg Hutchinson <the.greg.hutchinson(a)gmail.com> > wrote: > > That worked - thanks very much. > > On 29 July 2017 at 16:13, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > >> Did you try setting the pragma <path: '/'> in the list method? >> Esteban A. Maringolo >> >> >> 2017-07-28 18:40 GMT-03:00 Greg Hutchinson <the.greg.hutchinson(a)gmail.com >> >: >> > I am new to Pharo/Seaside and it has been a long time since I have used >> > Smalltalk. I am trying to make a RESTful service and canât get the >> pragmas >> > to work the way I think it should. (This might be the problem already). >> > >> > >> > >> > Ie Here is my list method within class TeamMembers which is a direct >> > subclass of WARestfulHandler. >> > >> > list >> > >> > <get> >> > >> > ^ String streamContents: [ :stream | >> > >> > self teamMembers do: [ :each | >> > >> > stream nextPutAll: each ; crlf ] >> > >> > ] >> > >> > >> > >> > and >> > >> > >> > >> > listJson >> > >> > <get> >> > >> > <produces: 'text/json'> >> > >> > >> > >> > ^ (Array streamContents: [ :stream | >> > >> > self teamMembers do: [ :each | >> > >> > stream nextPut: (Dictionary new >> > >> > at: 'name' put: each ; >> > >> > yourself) ] ]) >> > >> > asJavascript >> > >> > >> > >> > >> > >> > >> > >> > After doing all the proper registration WAAdmin register: TeamMembers >> at: >> > 'team-members' when I execute in the browser >> > (http://localhost:8080/team-members) I received the message >> > >> > /team-members not found >> > but if I execute (http://localhost:8080/team-members/list) it brings >> back >> > the team member list. (However, I didnât think I would have to add >> /list to >> > the URL). >> > >> > >> > >> > This seems to contradict the documentation in >> > http://book.seaside.st/book/advanced/restful/getting-started >> /define-handler. >> > >> > >> > >> > >> > >> > However, If I override the TeamMembers>> >> > >> > createRoutes >> > >> > | route pType| >> > >> > pType := WAFullMimeTypeMatch main:'text' sub: 'json' . >> > >> > route := WASimpleRoute method: 'GET' selector: #listJson >> > produces: pType consumes: WAWildcardMimeTypeMatch new. >> > >> > ^ OrderedCollection new >> > >> > "GET" >> > >> > add: route; >> > >> > add: (WARoute get: #list); >> > >> > yourself. >> > >> > >> > >> > Then I get the expected behaviour when I browse to >> > (http://localhost:8080/team-members) and using curl. (ie. >> > >> > curl -H "Accept: text/json" http://localhost:8080/team-members >> > >> > to get the Json response. >> > >> > >> > >> > When I debug the difference in the routes, it looks like using the >> pragmas, >> > I get WAComplexRoute(s) but of course in the overridden method >> createRoutes, >> > I get WASimpleRoutes. >> > >> > >> > >> > Is this the way it is supposed to work? >> > >> > >> > >> > >> > >> > Thanks in advance for any hints. >> > >> >> > > > -- > > >

July 30, 2017

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

by 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 <stepharo.self(a)gmail.com> wrote: > + 100 > > On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 28 Jul 2017, at 15:13, phil(a)highoctane.be wrote: >>> >>> Changing too many things at once is indeed annoying. >>> >>> Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. >>> >>> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). >>> >>> Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. >>> >>> There needs to be a combination. >>> >>> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. >>> >>> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. >>> >>> There needs to be a semblance of LTS in this. >> >> But even the LTS concept does not solve all problems. >> >> Every 2 years there is a new LTS, which is supported for 5 years. >> >> 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 30, 2017

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

by Stephane Ducasse

+ 100 On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 28 Jul 2017, at 15:13, phil(a)highoctane.be wrote: >> >> Changing too many things at once is indeed annoying. >> >> Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. >> >> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). >> >> Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. >> >> There needs to be a combination. >> >> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. >> >> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. >> >> There needs to be a semblance of LTS in this. > > But even the LTS concept does not solve all problems. > > Every 2 years there is a new LTS, which is supported for 5 years. > > 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 30, 2017

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

by 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, phil(a)highoctane.be <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. > > 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 30, 2017