- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Order/priority of StartupAction

by Damien Pollet

And what if you have several first actions? On 9 February 2015 at 12:44, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Nope. Imagine (and this is my case) that I distribute a startup script to > my users and I want, on them machine, that my script runs last. How can you > achieve that? > > However, I believe that we need a mechanism for that and not workarounds ;) > > R > > On 09 Feb 2015, at 12:16, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Can't you as a workaround use only one startup action that performs both > actions sequentially? > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy second startup actionâ > code: [ > "the code of the *first* startup action" > > "the code of the *second* startup action" > ] > runOnce: true > } > > El Mon Feb 09 2015 at 12:07:04 PM, Roberto Minelli <roberto.minelli(a)usi.ch> > escribiÃ³: > >> Hi, >> >> I already asked this question a while ago, and Iâd love to know if >> something has changed: Is there any way to specify an order or priority >> of StartupAction? >> >> In my case, for example, I really need that one of my scripts gets >> executed last. Can I do that? >> >> I could imagine something like >> >> StartupPreferencesLoader default executeAtomicItems: { >> StartupAction >> name: âMy first startup actionâ >> code: [ âSome code here" ] >> * order: 1* >> runOnce: true >> } >> >> StartupPreferencesLoader default executeAtomicItems: { >> StartupAction >> name: âMy second startup actionâ >> code: [ âSome code here that gets executed after the code in My first >> startup actionâ ] >> * order: 2* >> runOnce: true >> } >> >> On top of my knowledge, after checking 'Deep into Pharo' and âPharo for >> the Enterpriseâ, it seems that this is not possible. >> >> Am I the only one needing this? I can also try to sketch a solution! >> >> Cheers, >> Roby >> >> >> -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Feb. 9, 2015

[JOB][Research] Inria "Starting Research Positions"

by Marcus Denker

Campaign 2015: "Starting Research Positions" Inria is hiring 5 starting research scientists for a three-year contract. Registration conditions ------------------------ - Have a French doctorate or an equivalent international degree; - From 2 to 7 years'experience in research (after the thesis); - No age or nationality conditions. Recruitment process: ------------------- Eligibility: Inria ensures that each applicant fulfils the registration conditions. File selection: a committee reviews applicant files and draws up a shortlist for interviews. Interviews: pre-selected applicants are interviewed. After deliberation, the committee compiles a list of selected applicants to the CEO. Acceptance results: the chairman and CEO draws up the list of selected applicants after the interviews. DEADLINE: April 1st, 2015 More information: http://www.inria.fr/en/institute/recruitment/offers/starting-research-posit…

Feb. 9, 2015

Re: [Pharo-dev] How can I specify the bindings when evaluating an expression?

by Marcus Denker

> On 05 Feb 2015, at 10:09, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-02-05 2:20 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > Nicolai Hess wrote > > We lost this feature in 40097 > > Which feature? Using bare associations instead of WorkspaceVariables? > > Yes, maybe feature is the wrong word - ability? > What is missing now is, convert an association into a "VariableBinding" > similiar to WorkspaceVariable or GlobalVariable, that implements the code generation methods > emitStore: and emitValue: > yes, we could move it up to Associationâ¦ but we should keep VariableBinding as a subclass of Literal so that people in the future e.g. can put a halt on a variable defined in the workspace. And yes, in general we need a nice API for the compiler to hand bindings to itâ¦ it is on my TODO list. Marcus

Feb. 9, 2015

Re: [Pharo-dev] Package cleaning

by Marcus Denker

> On 23 Jan 2015, at 13:00, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Marcus, Ben and others, > > how can we proceed on META issue https://pharo.fogbugz.com/f/cases/14447? > > Anyone with deeper knowdlege of Monticello and the integration process > able to help here? It's a merging issue although nothing to merge. I think there is a bug in RPackageâ¦ somewhere. Marcus

Feb. 9, 2015

Re: [Pharo-dev] Order/priority of StartupAction

by Roberto Minelli

Nope. Imagine (and this is my case) that I distribute a startup script to my users and I want, on them machine, that my script runs last. How can you achieve that? However, I believe that we need a mechanism for that and not workarounds ;) R > On 09 Feb 2015, at 12:16, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Can't you as a workaround use only one startup action that performs both actions sequentially? > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy second startup actionâ > code: [ > "the code of the first startup action" > > "the code of the second startup action" > ] > runOnce: true > } > > El Mon Feb 09 2015 at 12:07:04 PM, Roberto Minelli <roberto.minelli(a)usi.ch> escribiÃ³: >> Hi, >> >> I already asked this question a while ago, and Iâd love to know if something has changed: Is there any way to specify an order or priority of StartupAction? >> >> In my case, for example, I really need that one of my scripts gets executed last. Can I do that? >> >> I could imagine something like >> >> StartupPreferencesLoader default executeAtomicItems: { >> StartupAction >> name: âMy first startup actionâ >> code: [ âSome code here" ] >> order: 1 >> runOnce: true >> } >> >> StartupPreferencesLoader default executeAtomicItems: { >> StartupAction >> name: âMy second startup actionâ >> code: [ âSome code here that gets executed after the code in My first startup actionâ ] >> order: 2 >> runOnce: true >> } >> >> On top of my knowledge, after checking 'Deep into Pharo' and âPharo for the Enterpriseâ, it seems that this is not possible. >> >> Am I the only one needing this? I can also try to sketch a solution! >> >> Cheers, >> Roby

Feb. 9, 2015

Re: [Pharo-dev] Order/priority of StartupAction

by Guillermo Polito

Can't you as a workaround use only one startup action that performs both actions sequentially? StartupPreferencesLoader default executeAtomicItems: { StartupAction name: âMy second startup actionâ code: [ "the code of the *first* startup action" "the code of the *second* startup action" ] runOnce: true } El Mon Feb 09 2015 at 12:07:04 PM, Roberto Minelli <roberto.minelli(a)usi.ch> escribiÃ³: > Hi, > > I already asked this question a while ago, and Iâd love to know if > something has changed: Is there any way to specify an order or priority > of StartupAction? > > In my case, for example, I really need that one of my scripts gets > executed last. Can I do that? > > I could imagine something like > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy first startup actionâ > code: [ âSome code here" ] > * order: 1* > runOnce: true > } > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy second startup actionâ > code: [ âSome code here that gets executed after the code in My first > startup actionâ ] > * order: 2* > runOnce: true > } > > On top of my knowledge, after checking 'Deep into Pharo' and âPharo for > the Enterpriseâ, it seems that this is not possible. > > Am I the only one needing this? I can also try to sketch a solution! > > Cheers, > Roby > > >

Feb. 9, 2015

Re: [Pharo-dev] Order/priority of StartupAction

by Max Leske

> On 09 Feb 2015, at 12:06, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Hi, > > I already asked this question a while ago, and Iâd love to know if something has changed: Is there any way to specify an order or priority of StartupAction? > > In my case, for example, I really need that one of my scripts gets executed last. Can I do that? âLastâ in terms of all possible actions or only w.r.t. your own scripts? > > I could imagine something like > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy first startup actionâ > code: [ âSome code here" ] > order: 1 > runOnce: true > } > > StartupPreferencesLoader default executeAtomicItems: { > StartupAction > name: âMy second startup actionâ > code: [ âSome code here that gets executed after the code in My first startup actionâ ] > order: 2 > runOnce: true > } > > On top of my knowledge, after checking 'Deep into Pharo' and âPharo for the Enterpriseâ, it seems that this is not possible. > > Am I the only one needing this? I can also try to sketch a solution! > > Cheers, > Roby > >

Feb. 9, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40484 Home: https://github.com/pharo-project/pharo-core

Feb. 9, 2015

[pharo-project/pharo-core] 17f546: 40484

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 17f546926505f515046d518de35948090c3cc228 https://github.com/pharo-project/pharo-core/commit/17f546926505f515046d518d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-09 (Mon, 09 Feb 2015) Changed paths: A Kernel.package/Class.class/instance/instance variables/addSlot_.st A KernelTests.package/ClassDescriptionTest.class/instance/tests - slots/testHasSlot.st A KernelTests.package/ClassTest.class/instance/testing/testAddSlot.st A Morphic-Widgets-Basic.package/SimpleSwitchMorph.class/instance/switching/onColor_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script484.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40484.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TClassDescription.class/instance/slots/hasSlot_.st Log Message: ----------- 40484 14894 SimpleSwitchMorph lost onColor: aColor https://pharo.fogbugz.com/f/cases/14894 14891 Slots: add #addSlot and #hasSlots https://pharo.fogbugz.com/f/cases/14891 http://files.pharo.org/image/40/40484.zip

Feb. 9, 2015

Morph click method

by Stephan Eggermont

When I look at all implementors of mouseDown: , I think that most will not like this implementation of click. They send messages to the event that nil doesn't understand. Morph>>click "Pretend the user clicked on me." (self handlesMouseDown: nil) ifTrue: [ self mouseDown: nil. self mouseUp: nil]. I would like to be able to use click in driving a design from tests. Can we replace nil by some NullObject here? Stephan

Feb. 9, 2015