August 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Managing updates/patches in Pharo with Metacello

by Esteban A. Maringolo

I think you're mixing two concepts here, the project code and build artifact. Otherwise I didn't understand your explanation :) Esteban A. Maringolo 2014-08-08 10:01 GMT-03:00 stepharo <stepharo(a)free.fr>: > > On dev I used the latest > Once published, backport bugs produced specific version that are merged > > > Ex > released > V11PackageA > > dev latest > V21PackageA > > => > > released > V12PackageA (merged from V11 and V22) > > > dev latest > V22PackageA > > > > >> i, >> >> >> How do you manage released versions updates in Metacello?

Aug. 8, 2014

Re: [Pharo-users] Managing updates/patches in Pharo with Metacello

by Esteban A. Maringolo

I know this is the proper way of doing it according to semantic versioning. I was afraid of populating the Metacello config with lots of #version21: #version211: #version212, etc. But I also should be able to load a version with the bug, so I guess this is way. But... how do I load the latest "released" version of 2.1 ? Ej: I have: - 2.1.3 (released) - 2.2.4 (released) - 2.3... (development) If I want to load the latest released version of 2.1, how do I do it without knowing if the latest is 2.1.3 or 2.1.15? Regards! Esteban A. Maringolo 2014-08-08 10:09 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > wellâ¦ my advice is to use semantic versioning (http://semver.org) > > in essence: > - a package commit is just a commit. The number is a commit number (bah.. > is a little more complicated because the commit info is author-number, but > you got the idea). > - metacello configurations work as distribution artifacts, so they should > have an unique and unrepeatable number (unless you are using git and > baselines, in which case it changes). So you should not change the old > version. Instead, you should add a patch number. > In your case: > > 2.1 > will become: > 2.1.1 > > and then you can move the #stable symbolic version to 2.1.1 > > Esteban > > On 08 Aug 2014, at 14:53, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > Hi, > > > > How do you manage released versions updates in Metacello? > > > > E.g. > > > > I have a version 2.1, with its spec with a dependency to > 'PackageA.11.mcz'. > > Later I find a bug which requires a new version of PackageA.11.mcz, > everything goes ok as in the development/bleedingEdge version, which > doesn't specify the file name, but how should I "backport" the change? > > > > What I am doing now is changing the version spec for '2.1' and updating > the reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but I'm afraid > this isn't the proper way of doing this. > > > > How do you manage this? > > > > In git I'd merge the commit in the 2.1 version branch, and then the CI > that depends on such branch would incorporate the change. > > > > Regards! > > > > Esteban A. Maringolo > > >

Aug. 8, 2014

Re: [Pharo-users] Managing updates/patches in Pharo with Metacello

by Esteban Lorenzano

wellâ¦ my advice is to use semantic versioning (http://semver.org) in essence: - a package commit is just a commit. The number is a commit number (bah.. is a little more complicated because the commit info is author-number, but you got the idea). - metacello configurations work as distribution artifacts, so they should have an unique and unrepeatable number (unless you are using git and baselines, in which case it changes). So you should not change the old version. Instead, you should add a patch number. In your case: 2.1 will become: 2.1.1 and then you can move the #stable symbolic version to 2.1.1 Esteban On 08 Aug 2014, at 14:53, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > How do you manage released versions updates in Metacello? > > E.g. > > I have a version 2.1, with its spec with a dependency to 'PackageA.11.mcz'. > Later I find a bug which requires a new version of PackageA.11.mcz, everything goes ok as in the development/bleedingEdge version, which doesn't specify the file name, but how should I "backport" the change? > > What I am doing now is changing the version spec for '2.1' and updating the reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but I'm afraid this isn't the proper way of doing this. > > How do you manage this? > > In git I'd merge the commit in the 2.1 version branch, and then the CI that depends on such branch would incorporate the change. > > Regards! > > Esteban A. Maringolo

Aug. 8, 2014

Re: [Pharo-users] Managing updates/patches in Pharo with Metacello

by stepharo

On dev I used the latest Once published, backport bugs produced specific version that are merged Ex released V11PackageA dev latest V21PackageA => released V12PackageA (merged from V11 and V22) dev latest V22PackageA > i, > > How do you manage released versions updates in Metacello? > > E.g. > > I have a version 2.1, with its spec with a dependency to > 'PackageA.11.mcz'. > Later I find a bug which requires a new version of PackageA.11.mcz, > everything goes ok as in the development/bleedingEdge version, which > doesn't specify the file name, but how should I "backport" the change? > > What I am doing now is changing the version spec for '2.1' and > updating the reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but > I'm afraid this isn't the proper way of doing this. > > How do you manage this? > > In git I'd merge the commit in the 2.1 version branch, and then the CI > that depends on such branch would incorporate the change. > > Regards! > > Esteban A. Maringolo

Aug. 8, 2014

Managing updates/patches in Pharo with Metacello

by Esteban A. Maringolo

Hi, How do you manage released versions updates in Metacello? E.g. I have a version 2.1, with its spec with a dependency to 'PackageA.11.mcz'. Later I find a bug which requires a new version of PackageA.11.mcz, everything goes ok as in the development/bleedingEdge version, which doesn't specify the file name, but how should I "backport" the change? What I am doing now is changing the version spec for '2.1' and updating the reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but I'm afraid this isn't the proper way of doing this. How do you manage this? In git I'd merge the commit in the 2.1 version branch, and then the CI that depends on such branch would incorporate the change. Regards! Esteban A. Maringolo

Aug. 8, 2014

Re: [Pharo-users] Seeing all the methods that is used in a method

by Aria AK

oh no, I am now accepted by the mailing list and I think I deleted this post after I got accepted by the mailing-list. I have no problem posting in mailing list now. thanks for your concern . On Fri, Aug 8, 2014 at 3:11 PM, stepharo <stepharo(a)free.fr> wrote: > which post? > We received several post from you. > As soon as you register to the mailing, sending a mail with the correct > account publish mails to the mailing-lists. > > On 7/8/14 04:52, aria2end wrote: > >> why is it that my post is not yet accepted by the mailing list yet. what >> should I do ? >> >> >> >> -- >> View this message in context: http://forum.world.st/Seeing- >> all-the-methods-that-is-used-in-a-method-tp4771587p4772097.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > >

Aug. 8, 2014

Re: [Pharo-users] Two Questions from a Newbie

by phil＠highoctane.be

Hi Ichiseki, Welcome! One can load the demo of the atoms like this: Gofer it url: 'http://smalltalkhub.com/mc/PharoExtras/MorphExamplesAndDemos/main' username: '' password: ''; package: 'MorphExamplesAndDemos'; load. BouncingAtomsMorph new openInWorld. ( https://gist.github.com/philippeback/7d760bb6882896a5bbff ) Some things were broken in there for loading in 3.0. If fixed what was needed to allow you to load it in. What I noticed: GraphMorph is missing (anyone having an version? Or maybe we could use Roassal ?) There are mentions of registration in flaps, which are obviously remnants of Squeak version. HTH Phil â

Aug. 8, 2014

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

by Thomas Bany

Okey, I found the issue and it was me doing lazy benchmark: I had forgot a debug printing function in the C code, that I had removed between the benchs. Thanks again for your time ! Thomas. 2014-08-07 21:56 GMT+02:00 stepharo <stepharo(a)free.fr>: > NativeBoost methods compiles native code only once (the first time they > are executed) and when sessionId changes (because you may be on a different > platform). > So this is already like that. The assembly code is cached in the method > literal. > > Stef > > On 7/8/14 17:25, Thomas Bany wrote: > >> Hi everyone, >> >> I'm trying to reduce the computation time of the following pseudo-code: >> >> - memory allocation (~40 doubles) >> - object heap to C heap copying >> - NativeBoost call (nbCall:) >> - memory freeing >> >> The time profiling results are bellow: >> >> - 24*3600 calls : > 1 minute >> - 24*3600 calls with only memory allocation and copying : < 1 second >> - 1 call with a 24*3600 loop inside de C code : < 1 second >> >> So it appears that the very coslty step is the transition from Pharo to >> C. And I was wondering if it was possible to drasticly reduce this time by >> doing something like, generate the the machine code once and call it >> multiple time ? >> >> Thanks in advance ! >> >> Thomas. >> > > >

Aug. 8, 2014

Re: [Pharo-users] Two Questions from a Newbie

by kilon alios

I have ported 4 of the 14 Chapters and have provided updated pictures and content. Damien has also ported a chapter and Stef has partially ported another. I will keep contributing , my goal is also to provide a new chapter for introducing newcomers to coding into basic OO concepts and I want to extend the documentation on Morphic too. You can view the book here. https://www.gitbook.io/book/kilon/pbe This will always have the latest version since I push from the main repo in github. On Fri, Aug 8, 2014 at 5:53 AM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > > Fortunately Smalltalk is a never ending journey into the land of weirdness > and Pharo is its champion. Pharo is by far the most actively developed open > source Smalltalk out there. Most likely more actively developed than the > commercial ones too. So the overlap is pretty minimum actually. > > Smalltalk is not a programming language. Its a live coding environment > that has also a very minimalistic language. Yeap documentation is a big > problem in Pharo. I was complaining about it a few days ago. However people > here are very helpful and very friendly to newcomers (unlike other > programming languages ) and stackoverflow questions never go unanswered so > you are not alone and people can help a lot. So its not that bad. Also > there is already a lot of documentation about Pharo. Pharo for The > Enterprise , Pharo By Example and Deep Into Pharo should keep you occupied > for months if not years. > > As a newcomer its important to keep an open mind, Pharo is actually easy > to learn but unlike other programming languages is not the same thing > repackaged diffirently . Its quite diffirent actually and I think that is > what makes it so productive and fun. > > In any case the secret of learning is very simple ... ask and you shall > receive ;) > > Oh and welcome to Pharo .And remember if you are not having fun then its > a Pharo bug and you should report it ;D > > > *grin* I like that a lot. It made me laugh. It almost would go well on > the web site somewhere. > > > > > On Thu, Aug 7, 2014 at 10:56 PM, Ichiseki <is076(a)outlook.com> wrote: > >> Konnichiwa >> First thanks to those that gave me some directions to start with Pharo / >> Smalltalk. >> Now I have some questions that I'm sure are very stupid. >> The first one is, is there a way to use the bouncing atoms and the lights >> on >> on Pharo 3? Because I tried to build it in there and it doesn't work >> > I guess you are referring to Pharo By Example. I strongly recommend > that use the Pharo Image that was used when the book was written, so that > the screen shots match. > http://pharobyexample.org/image/PBE-OneClick-1.1.app.zip > > kilon is kindly putting effort into updating PBE to Pharo 3 but I'm not > sure of the status. > https://github.com/SquareBracketAssociates/UpdatedPharoByExample > > > The second one is why there are like three different smalltalk >> environments? >> Pharo Squeek and Cuis? What are the differences? Is there a standard? I >> find >> this extremelly intriguing as it seems like there is a lot of dupplicate >> effort? >> > > You might also ask why there are several different C programming > environments - gcc, LVMM, Eclipse, Visual Studio > The answer is that philosophies differ. Pharo and Cuis are forks from > Squeak. To over simplify... Squeak has several major community projects > built on top which value the stability of their platform. Over many years > Squeak has grown and evolved in tandem with those projects and is strongly > coupled to them. Someone wanting to develop new projects on top of Squeak > viewed parts of that as bloat, but for those existing projects it was > essential behaviour. There have been many contributors over the years, and > as a large system there are parts that hard to support. So those wanting > to make Squeak leaner, more modular and cleaner for better long term > support forked Pharo from Squeak. Now Squeak is also progressing in these > directions, but without the constraint of those existing projects Pharo can > be more aggressive. To me it comes > > The third one is which is the line between the core language and >> frameworks >> and libraries in Pharo? >> > > That is a very good question and one we should probably work of defining > better. Many frameworks and libraries are part of the environment > delivered by Pharo, and personally I think of the whole package "as > Pharo". I had a hunt around and maybe [1] gives a good summary of the core > language itself. Now Smalltalk has been a continual evolution from the > 1970s. Squeak and Pharo are directly descended from Smalltalk-80 [2]. In > 1998 ANSI Smalltalk [3] defined a core language and libraries for half a > dozen commercial vendors, but of course the trouble with standards is they > dull innovation, and Pharo seeks to go beyond. > > [1] http://c2.com/cgi/wiki?SmalltalkTutorial > [1] stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf > [2] http://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf > [3] http://www.eli.sdsu.edu/courses/spring01/cs635/readingSmalltalk.pdf > > > > I found that, for instance Cuis has something like a basic image and >> some >> external frameworks, pharo has some internal frameworks and lots of >> externals. This is weird from someone comming from other languages. >> > > Could you provide some non-weird examples form other languages? > > One of the great advantages of Smalltalk is working in a live Image. > However this can be a disadvantage in terms of reproducibility and > dependencies forming between frameworks. Pharo seeks to break this by > separating frameworks out of the Image, to provide a minimal Image and a > means of automatically loading frameworks back in via continuous > integration. > > The fourth is I found that documentation is very, very scarce >> especially for >> some frameworks. This is also a major drawback for a newcomer to pharo. A >> very thick entry barrier. >> > > We need to do better here. Are there any particular frameworks that you > are looking at? > cheers -ben > > > >> Thank you >> Ichiro >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Two-Questions-from-a-Newbie-tp4772384.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > >

Aug. 8, 2014

Re: [Pharo-users] Seeing all the methods that is used in a method

by stepharo

which post? We received several post from you. As soon as you register to the mailing, sending a mail with the correct account publish mails to the mailing-lists. On 7/8/14 04:52, aria2end wrote: > why is it that my post is not yet accepted by the mailing list yet. what > should I do ? > > > > -- > View this message in context: http://forum.world.st/Seeing-all-the-methods-that-is-used-in-a-method-tp477… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 8, 2014