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

Re: [Pharo-dev] about ~=

by Andres Valloud

Sp, speaking of mathematical precedence and all that, anyone up to looking at the IEEE-754 spec and making one's Smalltalk of choice comply with _all_ the requirements? Or how about implementing decimal floats? On 6/26/14 12:01 , phil(a)highoctane.be wrote: > > 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 > <mailto:richard.sargent@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 27, 2014

Re: [Pharo-dev] super initialize

by Stefan Marr

Hi: On 26 Jun 2014, at 18:48, stepharo <stepharo(a)free.fr> wrote: > I prefer to have a super call for consistency reasons. Igor jokes me usually on that. > Now there should not be an initialize in ProtoObject and Object in the future. Just curios, whatâs the reasoning behind not having #initialize in Object? Initialization isnât a core concept Object should support? I am asking because in SOM, Object indeed does not have #initialize, and well, I find that a little annoying. Because often enough I need to add a #new method that sends #initialize, but since it is not available implicitly everywhere, the system is rather inconsistent in that regard. Different classes end up using slightly different approaches to initialization, which is confusing. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

June 27, 2014

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

by Dale Henrichs

Sven, You don't believe that it is worthwhile ... that's okay ... you are entitled to your beliefs. Frankly, when you integrate git into a Smalltalk environment (and I have) you are not messing with 100's of little files ... you are working with methods and packages and classes ... the stuff that Smalltalk programmers work with every day ... and I don't even think about how the source is being stored because in my environment I work with methods, classes and packages and I rarely look at the disk (just like most Smalltalk programmers and unlike most Java/C#/Go programmers:)... Git brings another dimension to my smalltalk development experience in a couple of very critical areas, so I don't have to believe, I know... I do believe that it is worthwhile to integrate git into Smalltalk development environments and I'm doing something about that and I am willing to help other folks with similar beliefs ... So at the end of the day you can be as negative or as positive as you like and I will continue to plug away:) Dale On Thu, Jun 26, 2014 at 2:04 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 27, 2014

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

by Richard Sargent

Sven Van Caekenberghe-2 wrote > 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. > > ... > > I don't want to sound too negative, I just don't belief it will actually > make that much difference. I've seen the work that Dale's done with tODE. Can you manage a merge with so many files? Yes, without a doubt. Does git do an excellent job of merging and differencing? Absolutely. In terms of making a difference, I'm of the opinion that git provides something modern, universal, and comparable to ENVY (which I have used for most of the last 20 years and admire immensely). Are there more important things to do? Without a doubt. Is this worth too little to bother with? Absolutely not. git will facilitate configuration management (not just versionning) and will also greatly facilitate cross-dialect compatibility. The ability to easily pick up an offering from one Smalltalk and fork it with small changes for another dialect will be nirvana for many of us. -- View this message in context: http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p47651… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2014

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

by Sebastian Sastre

On Jun 26, 2014, at 7:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > @Sebastian > > So we are on github, gemstone even more, cuis too. And Squeak is not. Did anything change dramatically ? > > There are thousands of languages and systems on github, I like it too, but just being there makes little difference. It is just a tool, a good one, but no more. Itâs a tool that isnât too interesting as tool But it is in the part that it leverages the social aspect of coding Dramatic changes why expect that? You are only creating the chances to make your code more accessible and less alien to fresh eyes Did I say social already? Should say social one more time? like when people talk about things and collaboration might emerge?

June 27, 2014

Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Facundo Vozzi

Incredible Work! Thanks for sharing, FV p.s.: I used one HP-35 at school from my father. I love the RPN method when I understood it :-) On Thu, Jun 26, 2014 at 5:13 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Jun 2014, at 09:24, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > > > Great job Sven, I felt young again. > > > > Thank you. > > > > Lorenzo > > Yeah, I am beginning to realise that being interested in historic > calculators puts you in a certain age bracket ;-) > > I am glad you liked it. > > Sven > > >

June 26, 2014

Re: [Pharo-dev] spec question

by Pablo R. Digonzelli

For example, it works m := DynamicComposableModel new. m instantiateModels: #(listModel ListModel ). m listModel backgroundColorBlock: [ Color blue ]. m listModel displayBlock: [ :it | it printString]. l := ( SpecLayout composed newRow: #listModel ; yourself ). m listModel items: (1 to: 10). m listModel backgroundColorBlock: [:item :index | Color blue]. m layout: l. m openWithSpec . but it does not work m := DynamicComposableModel new. m instantiateModels: #(listModel MultiColumnListModel ). m listModel backgroundColorBlock: [ Color blue ]. m listModel displayBlock: [ :it | { it printString. it printString} ]. l := ( SpecLayout composed newRow: #listModel ; yourself ). m listModel items: (1 to: 10). m listModel backgroundColorBlock: [:item :index | Color blue]. m layout: l. m openWithSpec . 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 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Jueves, 26 de Junio 2014 19:53:06 Asunto: Re: [Pharo-dev] spec question Someone knows how to set backgroundColorBlock: in an MultiColumnListBox?. 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 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: nicolaihess(a)web.de, "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Jueves, 26 de Junio 2014 19:13:57 Asunto: Re: [Pharo-dev] spec question 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] How to get started with Git and Pharo?

by Sven Van Caekenberghe

That is cool, but you/we can do that today, Pharo's full source is on github for quite some time now. @Sebastian So we are on github, gemstone even more, cuis too. And Squeak is not. Did anything change dramatically ? There are thousands of languages and systems on github, I like it too, but just being there makes little difference. It is just a tool, a good one, but no more. On 27 Jun 2014, at 00:16, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > My favorite feature by far is the ability to look at the git history of the methods themselves ... just the other day I had a bug that I was tracking down, and by looking at the git history I discovered that a critical change had been made to that method 1 year 12 days ago ... from that I was able to look at all of the changes to all of the packages that had been made in the same commit (the critical code had not only been moved to a different class but the critical method had been moved to a separate package ... and from that I was able to see that a bug had been introduced when not all of the critical method was moved ... bug fixed ... > > Besides method versions, you can look at the git history for a class, package or metacello project .... these are thing that would take a bit of work to accomplish using just Monticello ... and if you were to attempt to do it, the simplest thing to do would be to copy all of the packages into a git repository and just use git:) Frank Shearar wrote some code that did something along these lines a couple of years ago ... > > Dale > > > > On Thu, Jun 26, 2014 at 2:21 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > 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] spec question

by Pablo R. Digonzelli

Someone knows how to set backgroundColorBlock: in an MultiColumnListBox?. 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 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: nicolaihess(a)web.de, "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Jueves, 26 de Junio 2014 19:13:57 Asunto: Re: [Pharo-dev] spec question 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] How to get started with Git and Pharo?

by Dale Henrichs

My favorite feature by far is the ability to look at the git history of the methods themselves ... just the other day I had a bug that I was tracking down, and by looking at the git history I discovered that a critical change had been made to that method 1 year 12 days ago ... from that I was able to look at all of the changes to all of the packages that had been made in the same commit (the critical code had not only been moved to a different class but the critical method had been moved to a separate package ... and from that I was able to see that a bug had been introduced when not all of the critical method was moved ... bug fixed ... Besides method versions, you can look at the git history for a class, package or metacello project .... these are thing that would take a bit of work to accomplish using just Monticello ... and if you were to attempt to do it, the simplest thing to do would be to copy all of the packages into a git repository and just use git:) Frank Shearar wrote some code that did something along these lines a couple of years ago ... Dale On Thu, Jun 26, 2014 at 2:21 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > 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