- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #68: 22805-FTTableMorph-has-too-big-minimal-height

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #68 was: SUCCESS. The Pull Request #2096 was integrated: "22805-FTTableMorph-has-too-big-minimal-height" Pull request url: https://github.com/pharo-project/pharo/pull/2096 Issue Url: https://pharo.fogbugz.com/f/cases/22805 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #67: 22821 Cleanup Exception class

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #67 was: SUCCESS. The Pull Request #2111 was integrated: "22821 Cleanup Exception class" Pull request url: https://github.com/pharo-project/pharo/pull/2111 Issue Url: https://pharo.fogbugz.com/f/cases/22821 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #66: 22819 Cleanup TestReviver

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #66 was: FAILURE. The Pull Request #2110 was integrated: "22819 Cleanup TestReviver" Pull request url: https://github.com/pharo-project/pharo/pull/2110 Issue Url: https://pharo.fogbugz.com/f/cases/22819 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi Luke, I am happy this looks exciting :). About the confusion part: The Glamorous Toolkit we are working on right now is a complete new world built on a complete new graphical stack that does is not based on the existing stack that ships with Pharo. It is not an evolution. It is a leap. The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. But, in the new world, we are bringing the concept much further. For example, Documenter provides a whole new kind of a tool that can mold to unify multiple workflows (like data notebooks, code documentation, or tutorials) right in the IDE. Coder provides the infrastructure for manipulating code that can mold its shape as you type. Transcript allows you to embed various widgets to transform the otherwise dull experience of a console into a live one. Behind the scenes GT comes with several engines. The Examples engine enables example-driven development which also bridges the gap between testing and documentation effort, especially when combined with Documenter. Releaser is able to release deeply nested projects. Phlow offers an engine that shares similarities with Glamour. Completer provides moldable completion. Visualizer offers a couple of visualization engines such as Mondrian. All of these are possible because of the underlying graphical stack made of Sparta/Bloc/Brick. All in all, we believe that the new GT enables a new way of programming. Individual features can be attractive, but our goal is to reshape the development experience. Does this address the concern? Cheers, Doru > On Dec 19, 2018, at 2:09 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Please do let us know what you think .. and, of course, what you feel. > > I'm feeling excited and confused :). > > Excited because I love seeing all these new demos streaming out and I'm itching to put new capabilities to work. > > Confused about the roadmap. How does this "new" Glamorous Toolkit relate to the "old" one that I learned about last year from the Moldable Tools thesis? Is this a new version or a complete rewrite? Is it backwards compatible or completely reimagined? Is adopting the new version a seamless process or is porting required? Are frameworks like Glamour still there behind the scenes or were they replaced? etc. > > > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Things happen when they happen, not when you talk about them happening."

Dec. 20, 2018

[Pharo 7.0] Build #65: 22818 Cleanup Regex tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #65 was: FAILURE. The Pull Request #2109 was integrated: "22818 Cleanup Regex tests" Pull request url: https://github.com/pharo-project/pharo/pull/2109 Issue Url: https://pharo.fogbugz.com/f/cases/22818 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #64: 22814-Broken-comments-on-Cursor

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #64 was: SUCCESS. The Pull Request #2106 was integrated: "22814-Broken-comments-on-Cursor" Pull request url: https://github.com/pharo-project/pharo/pull/2106 Issue Url: https://pharo.fogbugz.com/f/cases/22814 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #63: 22811 Fix comment in ExternalBrowser

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #63 was: SUCCESS. The Pull Request #2102 was integrated: "22811 Fix comment in ExternalBrowser" Pull request url: https://github.com/pharo-project/pharo/pull/2102 Issue Url: https://pharo.fogbugz.com/f/cases/22811 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

[Pharo 7.0] Build #62: 22812 Clean the ImageCleaner

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #62 was: SUCCESS. The Pull Request #2103 was integrated: "22812 Clean the ImageCleaner" Pull request url: https://github.com/pharo-project/pharo/pull/2103 Issue Url: https://pharo.fogbugz.com/f/cases/22812 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

[Pharo 7.0] Build #61: 22809 Cleanup MethodFinderTest and related sample classes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #61 was: FAILURE. The Pull Request #2101 was integrated: "22809 Cleanup MethodFinderTest and related sample classes" Pull request url: https://github.com/pharo-project/pharo/pull/2101 Issue Url: https://pharo.fogbugz.com/f/cases/22809 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 19 Dec 2018, at 10:58, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> I know about master and what it means, but that is not exactly what I want. >>>> >>>> When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. >>>> >>>> The master branch can further evolve after a (latest) release. It is the next release candidate. >>>> >>>> I would like to depend on whatever released version is the latest. See the URLs in my previous email. >>> >>> I think your understanding of master is different from mine. master >>> should never be the next release candidate, it is only ever the latest >>> GA code. >>> >>> In that case, you can use master to mean "the latest GA version". >>> >>> If you want release candidates, they should be branches off >>> development (or tags). >>> >>> If you want to support multiple versions, e.g. be able to release a >>> 4.1 after 5.0 has been released, then each version should be branched >>> off master (at the GA commit for that version). >>> >>> If you want to know where a named GA version is (and there won't be >>> further updates), it is a tag on the master branch. >> >> I don't think/believe there is only one right way to use git, that is part of its power. > > Agreed, and I can see how you read my reply that way, but I didn't > mean to imply that "this is the one and only right way to do it". > > >> In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. > > OK, so what I understand you're try to achieve is to have a "released" > version and a "released and better tested" version. > > Doesn't this run the same risk of people just sticking to the > "released and better tested" version, so the "released" version never > gets the additional testing that's desired? Yes, that is the question ;-) >> I also want to make things as simple as possible. > > :-) > > Cheers, > Alistair

Dec. 19, 2018