- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfPharoVM

by Sean P. DeNigris

Dale Henrichs wrote > > So I recommend against chaining... > Does chaining mean importing a version into another version, or the x.x-x thing? -- View this message in context: http://forum.world.st/ConfigurationOfPharoVM-tp4639007p4639052.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

Re: [Pharo-project] ConfigurationOfPharoVM

by Dale Henrichs

Keep in mind the fact that if you chain baselines or versions in this way, it is very difficult for humans to understand just what they are getting. It also makes it harder for tools to do the right thing as well ... So I recommend against chaining... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, July 7, 2012 3:28:22 PM | Subject: Re: [Pharo-project] ConfigurationOfPharoVM | | | | | On Sat, Jul 7, 2012 at 9:03 PM, Sean P. DeNigris < | sean(a)clipperadams.com > wrote: | | | I noticed the versions vary between x.x.x and x.x-x and that some of | the | versions import baselines and others import other versions. I've | never seen | it done like that... what's the intention? | | | | Usually, a version imports a baseline. However, imagine that you have | several packages/projects and between version X and Y only changed a | few packages. | Instead of having to re-put all versions of all packages in Y, you | make Y import X and you just change the ones you want. | | | | e.g. | "Baseline with dot imported by version with dash" | version145: spec | <version: '1.4-5' imports: #('1.4.1-baseline')> | | "version importing another version" | version143: spec | <version: '1.4-3' imports: #('1.4-2')> | | Cheers, | Sean | | -- | View this message in context: | http://forum.world.st/ConfigurationOfPharoVM-tp4639007.html | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

July 8, 2012

Re: [Pharo-project] OSProcess test failures in Pharo 1.4

by Sean P. DeNigris

EstebanLM wrote > > mmm... probably, but PharoVM needs an update too Please check this carefully. The changes are simple, but I'm not sure I fully understand the standard procedure here. Issue 6302: Update OSProcess Plugin http://code.google.com/p/pharo/issues/detail?id=6302 Fix in inbox: SLICE-Issue-6302-Update-OSProcess-Plugin-SeanDeNigris.1 ConfigurationOfCog * v. 4.7 - bless as release * v. 4.8 - bless as release (will be used by updated ConfigurationOfPharoVM) - merge in changes from v. 4.9 - import v. 4.7 instead of baseline and remove duplication * v. 4.9 - remove ConfigurationOfPharoVM - change stable version for #'pharo1.4.x' to version: '2.0-2', which loads v. 4.8 of ConfigurationOfCog Sean p.s. I forgot to mention in the commit comment that 4.8 updates the OSProcess plugin to 4.4.11 -- View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p463904… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Sean P. DeNigris

Sean P. DeNigris wrote > > - how do I remove an individual shortcut or shortcut category from a > morph? (so I can toggle the command/insert mode shortcuts) > I'm having trouble toggling insert mode... Right now I have AbstractNautilusUI class>>buildInsertModeKeymappingsOn: aBuilder <keymap> (aBuilder shortcut: #commandMode) category: #NautilusSourceCodeShortcuts "#VimInsertModeShortcuts" default: Character escape asShortcut do: [ :target | Editor dumbbellCursor: true. target sourceTextArea changed. target sourceTextArea attachKeymapCategory: #VimCommandModeShortcuts ]. The problem is that: * I think I have to put these shortcuts into #NautilusSourceCodeShortcuts to have them load without overriding anything * If I don't put them in their own category (i.e. #VimInsertModeShortcuts), I don't know how to remove them when entering command mode (I only see a way to remove whole categories) Guille, Ben - are those assumptions correct and how should I proceed? Thanks, Sean -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > > Those methods detach* has been moved from extension directly into KM. > They are still extension methods in 20193 (and seem to be broken) Issue 6300: Detach keymaping shortcuts http://code.google.com/p/pharo/issues/detail?id=6300 Nautilus has Morph>>detach*KeymapCategory* extension methods. These are generally useful and should be moved from Nautilus to KM Also, they are broken... Morph>>detachKeymapCategory: signals MessageNotUnderstood: KMDispatcher>>detachKeymapCategory: -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

Re: [Pharo-project] ConfigurationOfPharoVM

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Usually, a version imports a baseline. However... you make Y > import X and you just change the ones you want. > Oh, cool! I didn't know you could do that. Thanks :) That will simplify things... Mariano Martinez Peck wrote > > btw Sean, did you know that in Metacello internals baselines and versions > are (were?) the same thing? ;) > I suspected, but wasn't sure. Sean -- View this message in context: http://forum.world.st/ConfigurationOfPharoVM-tp4639007p4639030.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 7, 2012

Re: [Pharo-project] ConfigurationOfPharoVM

by Mariano Martinez Peck

btw Sean, did you know that in Metacello internals baselines and versions are (were?) the same thing? ;) On Sat, Jul 7, 2012 at 11:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > PharoVM configuration names are following this rule: > > pharoversion-buildversion > > so, 2.0-1 is the first build made for pharo 2.0... > > something like that. Yeah, I don't like the numbering, but I also don't > like the M.m (Major.minor) standard, because we don't know what is major > and what minor... so, right now is just 1.9 then 2.0 without actually > having a major change.. and it is confusing, because it looks like > important, but actually it does not means anything at all :) > > Esteban > > On Jul 7, 2012, at 9:03 PM, Sean P. DeNigris wrote: > > > I noticed the versions vary between x.x.x and x.x-x and that some of the > > versions import baselines and others import other versions. I've never > seen > > it done like that... what's the intention? > > > > e.g. > > "Baseline with dot imported by version with dash" > > version145: spec > > <version: '1.4-5' imports: #('1.4.1-baseline')> > > > > "version importing another version" > > version143: spec > > <version: '1.4-3' imports: #('1.4-2')> > > > > Cheers, > > Sean > > > > -- > > View this message in context: > http://forum.world.st/ConfigurationOfPharoVM-tp4639007.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- Mariano http://marianopeck.wordpress.com

July 7, 2012

Re: [Pharo-project] ConfigurationOfPharoVM

by Mariano Martinez Peck

On Sat, Jul 7, 2012 at 9:03 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I noticed the versions vary between x.x.x and x.x-x and that some of the > versions import baselines and others import other versions. I've never seen > it done like that... what's the intention? > > Usually, a version imports a baseline. However, imagine that you have several packages/projects and between version X and Y only changed a few packages. Instead of having to re-put all versions of all packages in Y, you make Y import X and you just change the ones you want. > e.g. > "Baseline with dot imported by version with dash" > version145: spec > <version: '1.4-5' imports: #('1.4.1-baseline')> > > "version importing another version" > version143: spec > <version: '1.4-3' imports: #('1.4-2')> > > Cheers, > Sean > > -- > View this message in context: > http://forum.world.st/ConfigurationOfPharoVM-tp4639007.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

July 7, 2012

Re: [Pharo-project] ConfigurationOfPharoVM

by Esteban Lorenzano

PharoVM configuration names are following this rule: pharoversion-buildversion so, 2.0-1 is the first build made for pharo 2.0... something like that. Yeah, I don't like the numbering, but I also don't like the M.m (Major.minor) standard, because we don't know what is major and what minor... so, right now is just 1.9 then 2.0 without actually having a major change.. and it is confusing, because it looks like important, but actually it does not means anything at all :) Esteban On Jul 7, 2012, at 9:03 PM, Sean P. DeNigris wrote: > I noticed the versions vary between x.x.x and x.x-x and that some of the > versions import baselines and others import other versions. I've never seen > it done like that... what's the intention? > > e.g. > "Baseline with dot imported by version with dash" > version145: spec > <version: '1.4-5' imports: #('1.4.1-baseline')> > > "version importing another version" > version143: spec > <version: '1.4-3' imports: #('1.4-2')> > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/ConfigurationOfPharoVM-tp4639007.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 7, 2012

Re: [Pharo-project] OSProcess test failures in Pharo 1.4

by Esteban Lorenzano

mmm... probably, but PharoVM needs an update too (btw, PharoVM is just a branded version of the cogvm, not more) Esteban On Jul 7, 2012, at 9:18 PM, Sean P. DeNigris wrote: > > Igor Stasenko wrote >> >> yeah.. it is a matter of changing the package version in >> configurationofcog >> > > VMConstruction-Plugins-OSProcessPlugin.oscog-eem.35 corresponds to > OSProcessPlugin 4.4.11 > > ConfigurationOfCog has three versions blessed development: > 4.7 - loaded by the stable version of ConfigurationOfPharoVM > 4.8 - declared as the development version for #common > 4.9 > > Since ConfigurationOfPharoVM is loading 4.7 explicitly already, it seems we > should change it from development to release, so that it is clear that it > should not be changed anymore [1]. > > Also, since 4.8 is still blessed development, why don't we merge the changes > from 4.9 into 4.8 and remove 4.9? > > If you agree with these changes, is 4.8 ready to be loaded by > ConfigurationOfPharoVM stable? > > Let me know... > Sean > > [1] After many conversations with Dale, it has sunk in that once a version > is released, it should not be changed. > > -- > View this message in context: http://forum.world.st/OSProcess-test-failures-in-Pharo-1-4-tp4638907p463901… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 7, 2012