June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] spec question

by Pablo R. Digonzelli

thanks Nicolai! Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Nicolai Hess" <nicolaihess(a)web.de> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> CC: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: Jueves, 26 de Junio 2014 18:55:26 Asunto: Re: [Pharo-dev] spec question 2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli < pdigonzelli(a)gmail.com > : Hi all, two questions about Spec. 1) How can i change the font for a ListModel or TextModel? 2) I try , but nothing happend . I does not work but there is no error also l := ListModel new. l backgroundColorBlock: [ Color red ]. l openWithSpec . Can I change de backcolor of ListModel ? Sorry for my english. TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 About the font: I don't know if this is possible. For the background color: This works only for the background of the list cells. If there is no entry in your listmodel list, the list view is empty as well and there is nothing to show. This works: ListModel new items: (1 to: 10); backgroundColorBlock: [ :item :index |Color red ]; openWithSpec. or with more colors :) ListModel new items: Color registeredColorNames ; backgroundColorBlock: [ :item :index | Color named:item]; openWithSpec.

June 26, 2014

Re: [Pharo-dev] spec question

by Nicolai Hess

2014-06-26 23:13 GMT+02:00 Pablo R. Digonzelli <pdigonzelli(a)gmail.com>: > > Hi all, two questions about Spec. > > 1) How can i change the font for a ListModel or TextModel? > > 2) I try , but nothing happend . I does not work but there is no error > also > > l := ListModel new. > l backgroundColorBlock: [ Color red ]. > l openWithSpec . > > Can I change de backcolor of ListModel ? > > Sorry for my english. > > TIA > > > > ------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > > About the font: I don't know if this is possible. For the background color: This works only for the background of the list cells. If there is no entry in your listmodel list, the list view is empty as well and there is nothing to show. This works: ListModel new items: (1 to: 10); backgroundColorBlock: [ :item :index |Color red ]; openWithSpec. or with more colors :) ListModel new items: Color registeredColorNames ; backgroundColorBlock: [ :item :index | Color named:item]; openWithSpec.

June 26, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by kilon alios

another advantage of git is source code searches. It will essentially allow pharoers to search pharo code online and not just being isolated in their image. The search does not return just a whole library but even code fragments. On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > > On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 Jun 2014, at 19:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > I think that it is possible to most if not all of the git work support > into the Smalltalk development environment ... I am doing that for GemStone > with tODE[6] and I do find myself going to the go to the command line much > less frequently ... but in tODE I have built a git merge tool and a git > diff tool ... you can get the git history of a method from the browser, etc. > > > Without a relatively high degree of tool integration it can be clunky to > use git ... I am very willing to share what I've done/learned in tODE with > Pharo tool builders and of course I think Thierry Goubier has actually been > ahead of me in several different areas ... > > > That is my analysis: it works today, 'perfectly', but there is not enough > tools support to make it as easy as Monticello as a whole is today. > > If these tools exist, or we can build them quickly based Dale's code, that > would be cool (I guess its all OSProcess underneath, which I find so/so, a > direct integration is better) that would be good. > > Would having this change our world fundamentally ? No, IMHO > Is it worth the effort, is the ROI there ? I don't think so > > > I disagree here. I think moving our development to git will change deeply > (for good) our community processes and then I think it totally worths the > effort. > > > > big +1 here > > The social benefit of having your code exposed in places like github > outweighs by at an astronomical scale the current lack of amazing mergetools > > If your code cannot be exposed without friction youâre done > > The noise of the jungle of > 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make > your work invisible > > > > >

June 26, 2014

Re: [Pharo-dev] Configuration critical warnings and errors in 40047

by stepharo

thanks this is a really nice script! On 26/6/14 22:38, Stephan Eggermont wrote: > |errors| > errors := OrderedCollection new. > SystemNavigation default allClassesDo: [ :each | > (each name beginsWith: 'ConfigurationOf' ) ifTrue: [ |list| > list := MetacelloToolBox validateConfiguration: each. > list do: [ :warning | > warning isCritical ifTrue:[errors add: each -> warning ]] > ]]. > errors an OrderedCollection(ConfigurationOf->Error: No usable baseline or versions defined. { noVersionsDefined } [ #validatePragmas ] ConfigurationOfVersionnerTestBitmapCharacterSet->Critical Warning: The name of package 'Collections-BitmapCharacterSet' does not match the file name ' Collections-BitmapCharacterSet-JAA.5' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of package 'VersionnerTestXML-Parser' does not match the file name 'XML-Parser-NorbertHartl.141' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of package 'VersionnerTestXML-Tests-Parser' does not match the file name 'XML-Tests-Parser-JAA.14' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 'Collections-Support' in version '2.0.0' { noVersionSpecified } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 'Collections-Support' in version '2.1.0' { noVersionSpecified } [ #validateVersionSpec: ]) >

June 26, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sebastian Sastre

On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 26 Jun 2014, at 19:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> I think that it is possible to most if not all of the git work support into the Smalltalk development environment ... I am doing that for GemStone with tODE[6] and I do find myself going to the go to the command line much less frequently ... but in tODE I have built a git merge tool and a git diff tool ... you can get the git history of a method from the browser, etc. >>> >>> Without a relatively high degree of tool integration it can be clunky to use git ... I am very willing to share what I've done/learned in tODE with Pharo tool builders and of course I think Thierry Goubier has actually been ahead of me in several different areas ... >> >> That is my analysis: it works today, 'perfectly', but there is not enough tools support to make it as easy as Monticello as a whole is today. >> >> If these tools exist, or we can build them quickly based Dale's code, that would be cool (I guess its all OSProcess underneath, which I find so/so, a direct integration is better) that would be good. >> >> Would having this change our world fundamentally ? No, IMHO >> Is it worth the effort, is the ROI there ? I don't think so > > I disagree here. I think moving our development to git will change deeply (for good) our community processes and then I think it totally worths the effort. big +1 here The social benefit of having your code exposed in places like github outweighs by at an astronomical scale the current lack of amazing mergetools If your code cannot be exposed without friction youâre done The noise of the jungle of 3-new-libraries-per-day-that-can-be-installed-in-one-shot will make your work invisible

June 26, 2014

spec question

by Pablo R. Digonzelli

Hi all, two questions about Spec. 1) How can i change the font for a ListModel or TextModel? 2) I try , but nothing happend . I does not work but there is no error also l := ListModel new. l backgroundColorBlock: [ Color red ]. l openWithSpec . Can I change de backcolor of ListModel ? Sorry for my english. TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 26, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sven Van Caekenberghe

On 26 Jun 2014, at 22:28, phil(a)highoctane.be wrote: > > Le 26 juin 2014 21:54, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > > > > > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > I know you, and some others, have that opinion and that is OK. > > > I also think that it would be nice to have (better git integration). > > > > > > But we essentially have it today, although a bit cumbersome, awkward (cfr https://github.com/pharo-project/pharo-core) Some of us store all their code in git all the time. > > > > > > My opinion is that it is not per se the most important thing. We have to focus on the aspects where we are better, not try being more the same as everybody else. > > > > > > We need modularisation, better tools, new ways of working with live objects, new interactive representations, mouldable tools, remote image tools, automatic cloud deploys, magic stuff, .. > > > > yesâ¦ and better git integration is part of âbetter toolsâ. > > and IMO, with the âplusâ that it can boost the other areas. > > Yes, Git enables all of code and assets in one single place and tooling that helps a lot with changes ( e.g. gitk ). That is huge in practice. I know that there are lots of git tools out there, but how do these help - they are disconnected from the image, and thus disconnected from our regular way of working (senders, implementors, references, ...). The current source code format in git is cool, but can you manage a merge or diff like that, with all the different parts scattered over 10s, 100s of files, with no matter what tool ? Apart from the fact that such bigger merge is always very difficult, no other tools will support our world view, ever. https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d8… You and I understand the above, no Java/C#/Go programmer will. The next discussion will be: what are all those silly method files, why not put them all in one file ? Then the question is, what are all those silly exclamation marks in our file out format ? And so on. I don't want to sound too negative, I just don't belief it will actually make that much difference. > Phil > > > > > Esteban > > > > > > > > On 26 Jun 2014, at 20:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > >> > > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> > > >>> > > >>> On 26 Jun 2014, at 19:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > >>> > > >>>> I think that it is possible to most if not all of the git work support into the Smalltalk development environment ... I am doing that for GemStone with tODE[6] and I do find myself going to the go to the command line much less frequently ... but in tODE I have built a git merge tool and a git diff tool ... you can get the git history of a method from the browser, etc. > > >>>> > > >>>> Without a relatively high degree of tool integration it can be clunky to use git ... I am very willing to share what I've done/learned in tODE with Pharo tool builders and of course I think Thierry Goubier has actually been ahead of me in several different areas ... > > >>> > > >>> That is my analysis: it works today, 'perfectly', but there is not enough tools support to make it as easy as Monticello as a whole is today. > > >>> > > >>> If these tools exist, or we can build them quickly based Dale's code, that would be cool (I guess its all OSProcess underneath, which I find so/so, a direct integration is better) that would be good. > > >>> > > >>> Would having this change our world fundamentally ? No, IMHO > > >>> Is it worth the effort, is the ROI there ? I don't think so > > >> > > >> I disagree here. I think moving our development to git will change deeply (for good) our community processes and then I think it totally worths the effort. > > >> Of course, important part of the advantages came from the tools around git (like github) more than git itself, but all is one and the same :) > > >> A couple of examples of what I think will improve our work: > > >> - pull requests instead SLICES > > >> - submodules (with different people taking care of them) > > >> - traceability: you can map an issue with a pull requests directly making it a lot better to query > > >> > > >> Then there is other kind of advantages like: > > >> - better entry-point for newbies to the community (they all expect something like git this days) > > >> - better visibility > > >> - confidence. This is subjective but important: companies feel more confident with something like git than a specific tool to keep their sources. > > >> - we can stop maintaining things like smalltalkhub and important parts of monticello itself and concentrate our efforts in other, more interesting areas > > >> > > >> â¦ and there are more. > > >> > > >> In conclusion, I think expending time in git integration is one of the best ways to contribute to the develop of Pharo nowadays. > > >> > > >> Esteban > > >> > > >>> > > >>> Anyway, it is a delicate subject as it also touches on the representation of the file format. > > > > > > > > > >

June 26, 2014

Configuration critical warnings and errors in 40047

by Stephan Eggermont

|errors| errors := OrderedCollection new. SystemNavigation default allClassesDo: [ :each | (each name beginsWith: 'ConfigurationOf' ) ifTrue: [ |list| list := MetacelloToolBox validateConfiguration: each. list do: [ :warning | warning isCritical ifTrue:[errors add: each -> warning ]] ]]. errors an OrderedCollection(ConfigurationOf->Error: No usable baseline or versions defined. { noVersionsDefined } [ #validatePragmas ] ConfigurationOfVersionnerTestBitmapCharacterSet->Critical Warning: The name of package 'Collections-BitmapCharacterSet' does not match the file name ' Collections-BitmapCharacterSet-JAA.5' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of package 'VersionnerTestXML-Parser' does not match the file name 'XML-Parser-NorbertHartl.141' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLParserTemplate->Critical Warning: The name of package 'VersionnerTestXML-Tests-Parser' does not match the file name 'XML-Tests-Parser-JAA.14' in version '1.0' { packageNameMismatch } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 'Collections-Support' in version '2.0.0' { noVersionSpecified } [ #validateVersionSpec: ] ConfigurationOfVersionnerTestXMLWriter->Critical Warning: No version specified for the package 'Collections-Support' in version '2.1.0' { noVersionSpecified } [ #validateVersionSpec: ])

June 26, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by phil＠highoctane.be

Le 26 juin 2014 21:54, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > I know you, and some others, have that opinion and that is OK. > > I also think that it would be nice to have (better git integration). > > > > But we essentially have it today, although a bit cumbersome, awkward (cfr https://github.com/pharo-project/pharo-core) Some of us store all their code in git all the time. > > > > My opinion is that it is not per se the most important thing. We have to focus on the aspects where we are better, not try being more the same as everybody else. > > > > We need modularisation, better tools, new ways of working with live objects, new interactive representations, mouldable tools, remote image tools, automatic cloud deploys, magic stuff, .. > > yesâ¦ and better git integration is part of âbetter toolsâ. > and IMO, with the âplusâ that it can boost the other areas. Yes, Git enables all of code and assets in one single place and tooling that helps a lot with changes ( e.g. gitk ). That is huge in practice. Phil > > Esteban > > > > > On 26 Jun 2014, at 20:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> > >>> On 26 Jun 2014, at 19:07, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > >>> > >>>> I think that it is possible to most if not all of the git work support into the Smalltalk development environment ... I am doing that for GemStone with tODE[6] and I do find myself going to the go to the command line much less frequently ... but in tODE I have built a git merge tool and a git diff tool ... you can get the git history of a method from the browser, etc. > >>>> > >>>> Without a relatively high degree of tool integration it can be clunky to use git ... I am very willing to share what I've done/learned in tODE with Pharo tool builders and of course I think Thierry Goubier has actually been ahead of me in several different areas ... > >>> > >>> That is my analysis: it works today, 'perfectly', but there is not enough tools support to make it as easy as Monticello as a whole is today. > >>> > >>> If these tools exist, or we can build them quickly based Dale's code, that would be cool (I guess its all OSProcess underneath, which I find so/so, a direct integration is better) that would be good. > >>> > >>> Would having this change our world fundamentally ? No, IMHO > >>> Is it worth the effort, is the ROI there ? I don't think so > >> > >> I disagree here. I think moving our development to git will change deeply (for good) our community processes and then I think it totally worths the effort. > >> Of course, important part of the advantages came from the tools around git (like github) more than git itself, but all is one and the same :) > >> A couple of examples of what I think will improve our work: > >> - pull requests instead SLICES > >> - submodules (with different people taking care of them) > >> - traceability: you can map an issue with a pull requests directly making it a lot better to query > >> > >> Then there is other kind of advantages like: > >> - better entry-point for newbies to the community (they all expect something like git this days) > >> - better visibility > >> - confidence. This is subjective but important: companies feel more confident with something like git than a specific tool to keep their sources. > >> - we can stop maintaining things like smalltalkhub and important parts of monticello itself and concentrate our efforts in other, more interesting areas > >> > >> â¦ and there are more. > >> > >> In conclusion, I think expending time in git integration is one of the best ways to contribute to the develop of Pharo nowadays. > >> > >> Esteban > >> > >>> > >>> Anyway, it is a delicate subject as it also touches on the representation of the file format. > > > > > >

June 26, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Esteban Lorenzano

On 26 Jun 2014, at 16:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I know you, and some others, have that opinion and that is OK. > I also think that it would be nice to have (better git integration). > > But we essentially have it today, although a bit cumbersome, awkward (cfr https://github.com/pharo-project/pharo-core) Some of us store all their code in git all the time. > > My opinion is that it is not per se the most important thing. We have to focus on the aspects where we are better, not try being more the same as everybody else. > > We need modularisation, better tools, new ways of working with live objects, new interactive representations, mouldable tools, remote image tools, automatic cloud deploys, magic stuff, .. yesâ¦ and better git integration is part of âbetter toolsâ. and IMO, with the âplusâ that it can boost the other areas. Esteban > > On 26 Jun 2014, at 20:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 26 Jun 2014, at 19:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>>> I think that it is possible to most if not all of the git work support into the Smalltalk development environment ... I am doing that for GemStone with tODE[6] and I do find myself going to the go to the command line much less frequently ... but in tODE I have built a git merge tool and a git diff tool ... you can get the git history of a method from the browser, etc. >>>> >>>> Without a relatively high degree of tool integration it can be clunky to use git ... I am very willing to share what I've done/learned in tODE with Pharo tool builders and of course I think Thierry Goubier has actually been ahead of me in several different areas ... >>> >>> That is my analysis: it works today, 'perfectly', but there is not enough tools support to make it as easy as Monticello as a whole is today. >>> >>> If these tools exist, or we can build them quickly based Dale's code, that would be cool (I guess its all OSProcess underneath, which I find so/so, a direct integration is better) that would be good. >>> >>> Would having this change our world fundamentally ? No, IMHO >>> Is it worth the effort, is the ROI there ? I don't think so >> >> I disagree here. I think moving our development to git will change deeply (for good) our community processes and then I think it totally worths the effort. >> Of course, important part of the advantages came from the tools around git (like github) more than git itself, but all is one and the same :) >> A couple of examples of what I think will improve our work: >> - pull requests instead SLICES >> - submodules (with different people taking care of them) >> - traceability: you can map an issue with a pull requests directly making it a lot better to query >> >> Then there is other kind of advantages like: >> - better entry-point for newbies to the community (they all expect something like git this days) >> - better visibility >> - confidence. This is subjective but important: companies feel more confident with something like git than a specific tool to keep their sources. >> - we can stop maintaining things like smalltalkhub and important parts of monticello itself and concentrate our efforts in other, more interesting areas >> >> â¦ and there are more. >> >> In conclusion, I think expending time in git integration is one of the best ways to contribute to the develop of Pharo nowadays. >> >> Esteban >> >>> >>> Anyway, it is a delicate subject as it also touches on the representation of the file format. > >

June 26, 2014