- Pharo-dev - lists.pharo.org

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

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

by Sven Van Caekenberghe

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, .. 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] about ~=

by phil＠highoctane.be

Couldn't we just have an expression evaluator done with PetitParser doing these things? Tcl and Bash have this expr: thing. (Expression parse: '5+3*2') value. (Expression parse: ':a | 5+:a*2') value:10. (Expression parse: ':a | 5+:a*2') value:self x. With the thesis of Lukas Renggli these was this Helvetia story. Is there any chance we see something around these lines now that there is a new compiler thing inside Pharo? So: someMethod: anX <expr> ^ 5 + anX * 2 Phil On Thu, Jun 26, 2014 at 6:11 PM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > Esteban A. Maringolo wrote > > If one thing confuses people in that realm is non arithmetic precedence: > > Eg. 2 + 3 * 4 = 20 instead of the "expected" 14. > > > > And we're not going to change that either. It's not worthy, and I > > doubt if it is possible at all. > > I'm probably late to the party with this reply. The primary reason for not > changing this is that it would be incorrect. It comes down to intrinsic > versus extrinsic meaning. A multiple operator has an intrinsic meaning: it > means multiple. But a message name does not have intrinsic meaning (other > than it is a good idea to have the name represent what it does). The > meaning > of a message is determined by the receiver. e.g. if PetitParser defines #* > to mean "0 or more repetitions", what happens when someone has decided that > it should be evaluated before #+? > > Message sending precedence can only be defined in terms of the type of > message: unary, binary (or infix), and keyword, since the interpretation of > the message is the receiver's responsibility, not the compiler's. > > > > > -- > View this message in context: > http://forum.world.st/about-tp4764892p4765070.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 26, 2014

Re: [Pharo-dev] evicted zombie process from run queue

by Esteban Lorenzano

On 26 Jun 2014, at 15:39, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > 2014-06-26 10:09 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > you are basically creating 1000 * 100000 morphs (and complex ones). > > Actually, I want to create about 20 million of rows. > > I would just do a matrix morph with just one morph and rendering the matrix in the canvas (overriding the #drawOn:) > > > Yes, that seems to be the path. > > BTW, I do not think VW would work like that either: IMO, that design (pre-generating the cells) is bad and it never works. > Other frameworks use a datasource design (like cocoa, swtâ¦ and basically all the serious frameworks I know about). > and no, we do not have a default design for this kind of big components (a serious absence, IMO). > > > Do you have an example of those frameworks displaying millions of rows? How they manage scrolling? > Thanks for the tips. https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Appli… (and around) nowâ¦ how it is implemented, I always take cocotron project (http://www.cocotron.org) as an inspiration (even if in ObjC, you can take a lot of ideas from there) Esteban > > HernÃ¡n >

June 26, 2014

Re: [Pharo-dev] evicted zombie process from run queue

by Esteban A. Maringolo

2014-06-26 15:39 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 2014-06-26 10:09 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> you are basically creating 1000 * 100000 morphs (and complex ones). > Actually, I want to create about 20 million of rows. Cool :) > Do you have an example of those frameworks displaying millions of rows? How > they manage scrolling? They recycle the views, showing only views for the items that fit on screen and, maybe, a few extra at the edges. Using callbacks to get the view and bind the data for each one. There was a way to use Dolphin Smalltalk ListView to use its underlying SysListView32 in virtual mode (I can't find it now). There are HTML list widgets that also do that. Here is a case of how to it with C# <http://www.codeproject.com/Articles/42229/Virtual-Mode-ListView> Of course nothing of this helps you immediately, unless you're going to implement such virtual/recycling lists in Morph. Regards! Esteban A. Maringolo

June 26, 2014

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

by Esteban Lorenzano

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] evicted zombie process from run queue

by Esteban A. Maringolo

2014-06-26 15:13 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-06-26 13:39 GMT-03:00 stepharo <stepharo(a)free.fr>: > >>>> Other frameworks use a datasource design (like cocoa, swtâ¦ and basically >>>> all the serious frameworks I know about). >> can you give a pointer? > ps: There is a forthcoming RecyclerView in the next Android SDK. It is > being announced in this very moment in Google I/O, Room 8. http://developer.android.com/intl/es/preview/material/ui-widgets.html#recyc… Esteban A. Maringolo

June 26, 2014

Re: [Pharo-dev] evicted zombie process from run queue

by HernÃ¡n Morales Durand

2014-06-26 10:09 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > you are basically creating 1000 * 100000 morphs (and complex ones). > Actually, I want to create about 20 million of rows. > I would just do a matrix morph with just one morph and rendering the > matrix in the canvas (overriding the #drawOn:) > > Yes, that seems to be the path. > BTW, I do not think VW would work like that either: IMO, that design > (pre-generating the cells) is bad and it never works. > Other frameworks use a datasource design (like cocoa, swtâ¦ and basically > all the serious frameworks I know about). > and no, we do not have a default design for this kind of big components (a > serious absence, IMO). > > Do you have an example of those frameworks displaying millions of rows? How they manage scrolling? Thanks for the tips. HernÃ¡n

June 26, 2014