- Pharo-dev - lists.pharo.org

renaming Matrix to 2dArray
by Stephane Ducasse March 10, 2018

March 10, 2018

Hi long time ago I renamed 2DArray as Matrix. Now our Matrix class does not support any of the Matrix operations, so I was thinking that to avoid confusion (people should use polymath) we should rename it back to 2DArray. What do you think? Stef

5 4

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager
by philippe.back＠highoctane.be March 9, 2018

March 9, 2018

Vincent, When it comes to UnifiedFFI what would be your advice to have it working? I am using quite a few such calls. Thx for this cool tool, I'll try it out this week end for sure! Phil On Thu, Mar 8, 2018, 20:30 <Vincent.Blondeau(a)lamresearch.com> wrote: > Hi Pharoers! > > I pleased to announce you the first release of Cruiser: a tool to package > your Pharo applications. The idea is to quickly convert an application from > a development environment to a production one. A production environment > means: > > * No writing on the disk > * No access to the source code (by the shortcuts, debugger,...) > * No error displaying on the interface > * The only thing accessible is the user application > > I let you discover it on: https://github.com/VincentBlondeau/Cruiser > > [cid:image002.png@01D3B6D0.B0BAA0B0] > > Do not hesitate to ask me questions or contribute to improve it! > > Cheers, > > Vincent Blondeau > Software Engineer, Software and Controls | Global Product Group > Desk +1 510.572.7499 > > Lam Research Corporation > 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com > Connect with Lam Research: Facebook< > https://www.facebook.com/LamResearchCorporation> | Twitter< > https://twitter.com/lamresearch> | LinkedIn< > https://www.linkedin.com/company/lam-research> > > ________________________________ > > NOTICE: This e-mail transmission may contain confidential information. If > you are not the intended recipient, or a person responsible for delivering > it to the intended recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information contained in or > attached to this message is STRICTLY PROHIBITED. If you have received this > transmission in error, please immediately notify the sender and destroy the > original transmission and its attachments without reading them or saving > them to disk. Thank you. >

4 3

[Pharo 7.0-dev] Build #674: 21521-File-out-and-file-in-code-leads-to-wrong-line-ending-in-the-image2
by ci-pharo-ci-jenkins2＠inria.fr March 9, 2018

March 9, 2018

There is a new Pharo build available! The status of the build #674 was: SUCCESS. The Pull Request #1049 was integrated: "21521-File-out-and-file-in-code-leads-to-wrong-line-ending-in-the-image2" Pull request url: https://github.com/pharo-project/pharo/pull/1049 Issue Url: https://pharo.fogbugz.com/f/cases/21521 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #673: 21216-Now-Trait-isBehaviour-returns-true-and-it-affects-ChangeSet-method
by ci-pharo-ci-jenkins2＠inria.fr March 9, 2018

March 9, 2018

There is a new Pharo build available! The status of the build #673 was: SUCCESS. The Pull Request #1039 was integrated: "21216-Now-Trait-isBehaviour-returns-true-and-it-affects-ChangeSet-method" Pull request url: https://github.com/pharo-project/pharo/pull/1039 Issue Url: https://pharo.fogbugz.com/f/cases/21216 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #672: 21515-Update-bootstrap-to-bootstrapImage-1.4-and-7.0-VM
by ci-pharo-ci-jenkins2＠inria.fr March 9, 2018

March 9, 2018

There is a new Pharo build available! The status of the build #672 was: SUCCESS. The Pull Request #1048 was integrated: "21515-Update-bootstrap-to-bootstrapImage-1.4-and-7.0-VM" Pull request url: https://github.com/pharo-project/pharo/pull/1048 Issue Url: https://pharo.fogbugz.com/f/cases/21515 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #671: 21494-Change-boostrap-to-not-load-Spec-Debugger
by ci-pharo-ci-jenkins2＠inria.fr March 9, 2018

March 9, 2018

There is a new Pharo build available! The status of the build #671 was: SUCCESS. The Pull Request #1034 was integrated: "21494-Change-boostrap-to-not-load-Spec-Debugger" Pull request url: https://github.com/pharo-project/pharo/pull/1034 Issue Url: https://pharo.fogbugz.com/f/cases/21494 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #670: 21042-file-out-does-not-work-from-browser
by ci-pharo-ci-jenkins2＠inria.fr March 9, 2018

March 9, 2018

There is a new Pharo build available! The status of the build #670 was: SUCCESS. The Pull Request #1044 was integrated: "21042-file-out-does-not-work-from-browser" Pull request url: https://github.com/pharo-project/pharo/pull/1044 Issue Url: https://pharo.fogbugz.com/f/cases/21042 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[ANN] Cruiser: A Pharo app packager
by Vincent.Blondeau＠lamresearch.com March 9, 2018

March 9, 2018

Hi Pharoers! I pleased to announce you the first release of Cruiser: a tool to package your Pharo applications. The idea is to quickly convert an application from a development environment to a production one. A production environment means: * No writing on the disk * No access to the source code (by the shortcuts, debugger,...) * No error displaying on the interface * The only thing accessible is the user application I let you discover it on: https://github.com/VincentBlondeau/Cruiser [cid:image002.png@01D3B6D0.B0BAA0B0] Do not hesitate to ask me questions or contribute to improve it! Cheers, Vincent Blondeau Software Engineer, Software and Controls | Global Product Group Desk +1 510.572.7499 Lam Research Corporation 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com Connect with Lam Research: Facebook<https://www.facebook.com/LamResearchCorporation> | Twitter<https://twitter.com/lamresearch> | LinkedIn<https://www.linkedin.com/company/lam-research> ________________________________ NOTICE: This e-mail transmission may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.

5 5

Metacello locking system
by Cyril Ferlicot D. March 8, 2018

March 8, 2018

> Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it > completely avoids the need to edit a baseline for development purposes > and this approach works really well for me ... perhaps we can discuss > this in more detail in a separate thread or even private email? This all > seems to be more complicated for you guys than has been my experience > and of course you guys _appear_ to be completely ignoring the Metacello > locking feature so I'm curious why ... > > Dale > Hi Dale, As asked I start a new thread. I can see some possible reasons I do not use Metacello locking feature. 1) I did not understand well enough what it was 2) We have a way to work different and mine might be incompatible with the lock feature 3) I just did not see how it could help me To know which one is the reason I'll present you a little what I understood of the lock feature and how I usually work and you'll be able to advise me. For the lock feature: If I understood correctly it is a feature allowing to lock a certain version of a project in the Metacello registry. For example if I load Seaside 3.1, lock it and then install a project having Seaside 3.2 as dependency, the lock will block the update of Seaside. Now how do I usually work: Let's take the example of MaterialDesignLite that I maintain. The master branch is a branch that should only contains stable MDL versions. Ideally I would like for each commit of this branch to be tagged with a semantic versionning tag. The development happen in the development branch and new features are merged into this branch before making it to master. In general I prefer to have stricter dependencies in master than in development. So the baseline in the development branch can be different than in master. For all my projects I try to have a Jenkins building Pharo images for at least master and development, and potentially big feature branches before they are merged. The Jenkins also test the images. Then when I need to work on something, I download the Jenkins archive of the corresponding branch, double click on the image (some setting are then loaded) and I'm ready to develop because Jenkins and my settings have done all the setup. I try to keep my Jenkins script as simple as possible for the loading. Ideally I like to have something like this: ./pharo $PROJECT_NAME.image eval --save " Metacello new baseline: #MaterialDesignLite; githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: '$VERSION' path: 'src'; onWarningLog; load. ". With this way to work, I do not really see how locks can help me. Because I don't want to have to manage possible versions I accept from all the dependencies in **development**. I want to accept the maximum of update and when it breaks either I edit the code to work with the new version of the dependency or I fix the dependency version because it will be too much work. Just to explain why I don't want to manage by hand all the dependencies version in development: I work on a project that at one time had more than 70 dependencies (transitively). Now that you know what I understood of the lock feature and that you know my way to work: Did I miss something on the lock mechanism? Do you think it can help me during my development? If yes, how would you include it in my development workflow? Thank you for the time you spend to help us improve our way to work! -- Cyril Ferlicot https://ferlicot.fr

2 1

[Pharo 7.0-dev] Build #669: 21517-New-traits-copy-all-class-side-methods-of-TraitedClass-to-all-subclasses-of-trait-users
by ci-pharo-ci-jenkins2＠inria.fr March 8, 2018

March 8, 2018

There is a new Pharo build available! The status of the build #669 was: SUCCESS. The Pull Request #1047 was integrated: "21517-New-traits-copy-all-class-side-methods-of-TraitedClass-to-all-subclasses-of-trait-users" Pull request url: https://github.com/pharo-project/pharo/pull/1047 Issue Url: https://pharo.fogbugz.com/f/cases/21517 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0