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

Re: [Pharo-users] Always asking for developer initials in 4,0?

by Tim Mackinnon

Yes - there is definitely a problem - after not prompting me a few times - Iâve just made another text change in the comment and its asked me for âAuthor Identificationâ again. Tim On 8 Aug 2014, at 18:11, Tim Mackinnon <tim(a)testit.works> wrote: > Iâve noticed quite a few times now in the Pharo 4.0 images - that I keep getting multiple prompts to enter my developer initials. I canât put my finger on it - I think its when I open a SystemBrowser in a new image - and just edit a class comment (it then prompts me for initials which is correct). However, if I then open the World Help - and then go back to my class comment and enter some new text - it often prompts me again? > > After doing this a few times - it then seemed to stick - so Iâm not exactly sure what causes it (this was in build 40123 - so reasonably recent). > > I mention it in case someone else has noticed this as well. > > Tim

Aug. 8, 2014

Always asking for developer initials in 4,0?

by Tim Mackinnon

Iâve noticed quite a few times now in the Pharo 4.0 images - that I keep getting multiple prompts to enter my developer initials. I canât put my finger on it - I think its when I open a SystemBrowser in a new image - and just edit a class comment (it then prompts me for initials which is correct). However, if I then open the World Help - and then go back to my class comment and enter some new text - it often prompts me again? After doing this a few times - it then seemed to stick - so Iâm not exactly sure what causes it (this was in build 40123 - so reasonably recent). I mention it in case someone else has noticed this as well. Tim

Aug. 8, 2014

Re: [Pharo-users] [ANN] Bootstrap 0.10.0 with Twitter Bootstrap v3.2.0 and Lighthouse sample app

by Offray Vladimir Luna CÃ¡rdenas

Hi, Nice work with boostrap. I'm having problems to test it (detailed below). On 08/07/2014 05:14 AM, Torsten Bergmann wrote: > Hi, > > the Bootstrap project (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) > was updated to include the latest Twitter Bootstrap library v.3.2.0 > from http://getbootstrap.com > > Also you can now use: > - an RTL/LTR version included for BIDI language applications > (see #bootstraprtlminCss and #bootstraprtlCss > > - #tbsContainerFluid beside #tbsContainer. > > How to try out: > =============== > 1. load "Bootstrap" from Configuration browser in Pharo 3.0 I tried from Moose 5.0 beta using World > Tools > Configuration browser > "Load Configuration" and on the same path using "Install Stable Version" and also using: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gofer it url: 'http://mc.stfx.eu/ZincHTTPComponents'; configurationOf: 'ZincHTTPComponents'; loadStable. Gofer it smalltalkhubUser: 'SvenVanCaekenberghe' project: 'ZincHTTPComponents'; configurationOf: 'ZincHTTPComponents'; loadStable. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- In none of these cases I can get autocompletion for the following line: > 2. evaluate > > ZnZincServerAdaptor startOn: 8080 ZnZincServerAdaptor doesn't seem available. What I'm missing? Thanks Offray

Aug. 8, 2014

Re: [Pharo-users] PharoLauncher can only run 1 instance on OSX?

by Tim Mackinnon

Hi - thanks for suggesting that. Itâs actually set to true - and on OSX Mavericks, with that setting it seems that when I launch a new image (and it supposedly quits) - when I run the launcher again - it just takes me to the image that was just launched. (I swear it didnât do that at some point - and Iâm not sure if its since I updated to Mavericks - or whether my other OSX computer doesnât exhibit this behaviour). Anyway - if I uncheck it (and leave the launcher running) - then I can at least launch other images (and if I run the app again - it seems to bring the running launcher to the foreground). If I try and quit the launcher manually after launching an image - it still exhibit this same behaviour. Itâs quite strange? (but at least I have a workaround). By the way - do you know how you save that setting? I thought it save automatically, but it didnât seem to. I pressed the export button - but and that seemed to do it, but I wasnât convinced that is actually save? Tim On 8 Aug 2014, at 16:45, Baptiste Quide <baptiste.quide(a)inria.fr> wrote: > Hello, > > i think you select the option "Quit on Launch" (by default) on Pharo Launcher. That's why when you're clicking it just switches to your running image. > Try to deselect this option and retry. > > Regards, > > ----- Mail original ----- >> De: "Tim Mackinnon" <tim(a)testit.works> >> Ã: "Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org> >> EnvoyÃ©: Vendredi 8 AoÃ»t 2014 17:34:06 >> Objet: [Pharo-users] PharoLauncher can only run 1 instance on OSX? >> >> I really like the PharoLauncher project - itâs very handy. However Iâve >> noticed that on OSX when I launch an image and then try and run >> PhaorLauncher (e.g. pharo.app) again, it just switches me to my already >> running image? >> >> Anyone know why it does that - or if there is some way to avoid it? iâm >> wondering it its the way that the launcher, launches the images (is it an os >> sub-process or something - and so this is why it just switches back to that >> process if you try and run it again?). >> >> Tim >> >

Aug. 8, 2014

Re: [Pharo-users] PharoLauncher can only run 1 instance on OSX?

by Baptiste Quide

Hello, i think you select the option "Quit on Launch" (by default) on Pharo Launcher. That's why when you're clicking it just switches to your running image. Try to deselect this option and retry. Regards, ----- Mail original ----- > De: "Tim Mackinnon" <tim(a)testit.works> > Ã: "Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org> > EnvoyÃ©: Vendredi 8 AoÃ»t 2014 17:34:06 > Objet: [Pharo-users] PharoLauncher can only run 1 instance on OSX? > > I really like the PharoLauncher project - itâs very handy. However Iâve > noticed that on OSX when I launch an image and then try and run > PhaorLauncher (e.g. pharo.app) again, it just switches me to my already > running image? > > Anyone know why it does that - or if there is some way to avoid it? iâm > wondering it its the way that the launcher, launches the images (is it an os > sub-process or something - and so this is why it just switches back to that > process if you try and run it again?). > > Tim >

Aug. 8, 2014

PharoLauncher can only run 1 instance on OSX?

by Tim Mackinnon

I really like the PharoLauncher project - itâs very handy. However Iâve noticed that on OSX when I launch an image and then try and run PhaorLauncher (e.g. pharo.app) again, it just switches me to my already running image? Anyone know why it does that - or if there is some way to avoid it? iâm wondering it its the way that the launcher, launches the images (is it an os sub-process or something - and so this is why it just switches back to that process if you try and run it again?). Tim

Aug. 8, 2014

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

by Dale Henrichs

Esteban, Take a look at the ConfigurationOfSeaside[1] in particular look at the `symbolic versions` protocol and note the release* symbolic versions: bleedingEdge: development: release30: release31: release3: stable: By using a version specific symbolic version you can get your cake and eat it to. In you case you would create version 2.1.1 with the bugfix and then update the release2 and release21 symbolic versions to point to 2.1.1. In you project load specification if you are interested in using the latest 2.1 then use #release21 and you will always get the latest bugfixes. On the other hand if you have gone into production with version 2.1 (as opposed to #release21), then you do not want version 2.1.1 loaded until you've validated the changes .... It's possible that a user of your project has chosen a different solution to the bug and your fix would break their fix, so you should never modify a version that has been released. Dale [1] http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main On Fri, Aug 8, 2014 at 7:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 08 Aug 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 08 Aug 2014, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > 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? > > > mmmâ¦ normally, you would move your stable symlink to the newer version. > or you can load explicitly. > or you can use something with #latestVersionMatching: and siblings (but > this one I donât know, I never used them). > > > forget it: > > ConfigurationOfBlah project latestVersion: #release. > > that will answer you the latest release version. > > Esteban > > > Esteban > > > 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

On 08 Aug 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 08 Aug 2014, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 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? > > mmmâ¦ normally, you would move your stable symlink to the newer version. > or you can load explicitly. > or you can use something with #latestVersionMatching: and siblings (but this one I donât know, I never used them). forget it: ConfigurationOfBlah project latestVersion: #release. that will answer you the latest release version. Esteban > > Esteban > >> >> 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

On 08 Aug 2014, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 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? mmmâ¦ normally, you would move your stable symlink to the newer version. or you can load explicitly. or you can use something with #latestVersionMatching: and siblings (but this one I donât know, I never used them). Esteban > > 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 Sean P. DeNigris

Esteban A. Maringolo wrote > I was afraid of populating the Metacello config with lots of #version21: > #version211: #version212, etc. Config classes are just the way we serialize projects. It is like reading binary :) I wouldn't contort your workflow to make them easier to read in a browser. Have you tried Versionner? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Managing-updates-patches-in-Pharo-with-Metacello-tp47… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 8, 2014