November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] I love the launcher!!!!

by Torsten Bergmann

Unfortunately this fix did not work. Details are described in https://github.com/pharo-project/pharo-launcher/issues/55 Meanwhile I fixed it in an own commit: PharoLauncher-Core-TorstenBergmann.146 Launcher is now able to give the filter pattern not as global regex but now specific to the version: self name: 'Pharo 7.0 (development version)' url: 'http://files.pharo.org/image/70/' asZnUrl filterPattern: 'href="(Pharo-7.0.0-alpha.build.[^"]*.zip)"' and it works and filters the alpha version (see screenshot). So anyone who would like to test should give it a try. For sure it can be improved to support also the other images in the future. But at least one can download the standard release for Pharo 7 as it was for Pharo 6. Thx T. > Gesendet: Mittwoch, 29. November 2017 um 09:26 Uhr > Von: "Christophe Demarey" <christophe.demarey(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] I love the launcher!!!! > > Hi Torsten, > > I think I have a fix for your problem. I opened an issue fot it: https://github.com/pharo-project/pharo-launcher/issues/55. > Could you confirm if it is ok now? > > > Le 28 nov. 2017 Ã 20:11, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : > > > > Hi, > > > > Launcher is a power tool and has helped many of us so far. Thanks to all who helped moving > > it forward, especially Christophe who is currently caring a lot. > > > > Unfortunately one primary issue is not yet solved: > > > > The downloadable files for Pharo 7 are not correctly displayed (see Screenshot attached). > > > > I guess this is because the image file names have changed (initially the build process was set up > > to include the git hash but now we also have the build number returned again, see [1]) > > > > So with the current Launcher one can not directly load a specific build number for Pharo 7 or see which > > build number is the latest available. So for Pharo 7 it is usable to download "latest", "latest-32" > > or "latest-64" but it is not possible to really distinguish all the "Pharorpackage-7" entries. > > > > It would be really a step forward if this could be fixed somehow and also for Pharo 7 display the > > image build number to make Launcher usable also for contributors to Pharo 7 again. > > > > Thanks > > T. > > > > [1] http://forum.world.st/SystemVersion-cleanup-or-the-return-of-the-explicit-b…<launcher.png> > > >

Nov. 29, 2017

[Pharo 7.0-dev] Build #350: 20782-CompiledCode-misses-an-abstract-sourcePointer-method

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

There is a new Pharo build available! The status of the build #350 was: SUCCESS. The Pull Request #561 was integrated: "20782-CompiledCode-misses-an-abstract-sourcePointer-method" Pull request url: https://github.com/pharo-project/pharo/pull/561 Issue Url: https://pharo.fogbugz.com/f/cases/20782 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2017

[update 6.0] #60522

by Marcus Denker

60522 ----- 20339 Pharo6 test runs for CI fail with strange error in ClassRenameFixTest>>#testRenameClassUsingClass https://pharo.fogbugz.com/f/cases/20339 20279 AST-Core ASTCache not cleaned https://pharo.fogbugz.com/f/cases/20279

Nov. 29, 2017

[Pharo 7.0-dev] Build #349: -20785/Fix-the-names-of-uploaded-bootstrap-zip-files

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

There is a new Pharo build available! The status of the build #349 was: SUCCESS. The Pull Request #563 was integrated: "-20785/Fix-the-names-of-uploaded-bootstrap-zip-files" Pull request url: https://github.com/pharo-project/pharo/pull/563 Issue Url: https://pharo.fogbugz.com/f/cases/20785 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2017

[Pharo 7.0-dev] Build #348: 20783-upload-temporary-building-files-into-a-separate-repository

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

There is a new Pharo build available! The status of the build #348 was: SUCCESS. The Pull Request #562 was integrated: "20783-upload-temporary-building-files-into-a-separate-repository" Pull request url: https://github.com/pharo-project/pharo/pull/562 Issue Url: https://pharo.fogbugz.com/f/cases/20783 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2017

[Pharo 7.0-dev] Build #347: 20777-Fix-instVarAt-instVarAt-put-comment

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

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

Nov. 29, 2017

Re: [Pharo-dev] VoxelSpace

by Esteban Lorenzano

> On 29 Nov 2017, at 10:41, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > The problem is in the wrong Metacello version in Pharo 6.1 that has no proper Tonel support. It should be fixed with the next Iceberg update in Pharo 6.1. not really. it should be fixed with the next *metacello* update in Pharo 6.1 ;) Esteban > > -- Pavel > > 2017-11-28 22:37 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: > Hi, > > it should work in Pharo 7. In Pharo 6.1 it really has this issue, I will try to look at it tomorrow. It is really strange because there is no special about this baseline. > > Cheers > -- Pavel > > 2017-11-28 21:38 GMT+01:00 Volkert <volkert(a)komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>: > Dear Davel, > > have problems to load the engine. See screenshot ... Any hints? > Pharo 6.1 / VM - 64 Bit / Linux > > BW, > > Volkert > > <eaoogkdjfhmlhbmp.png> > > > > > On 26.11.2017 23:55, Pavel Krivanek wrote: >> Hi, >> >> I tried to port and optimize the extremely simple VoxelSpace engine into Pharo. >> >> https://github.com/pavel-krivanek/VoxelSpace <https://github.com/pavel-krivanek/VoxelSpace> >> >> How to load >> >> Metacello new >> baseline: 'VoxelSpace'; >> repository: 'github://pavel-krivanek/VoxelSpace/src'; >> load. >> >> How to run >> >> Copy maps into the image directory and then evaluate: >> >> VoxelSpaceMorph new openInWindow. >> >> <VoxelSpace.png> >> >> No external library is required. If you have some next ideas how to improve the rendering performace with the same image quality, please let me know. >> >> Cheers, >> -- Pavel > > >

Nov. 29, 2017

Re: [Pharo-dev] VoxelSpace

by Pavel Krivanek

The problem is in the wrong Metacello version in Pharo 6.1 that has no proper Tonel support. It should be fixed with the next Iceberg update in Pharo 6.1. -- Pavel 2017-11-28 22:37 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > it should work in Pharo 7. In Pharo 6.1 it really has this issue, I will > try to look at it tomorrow. It is really strange because there is no > special about this baseline. > > Cheers > -- Pavel > > 2017-11-28 21:38 GMT+01:00 Volkert <volkert(a)komponentenwerkstatt.de>: > >> Dear Davel, >> >> have problems to load the engine. See screenshot ... Any hints? >> >> Pharo 6.1 / VM - 64 Bit / Linux >> >> BW, >> >> Volkert >> >> >> On 26.11.2017 23:55, Pavel Krivanek wrote: >> >> Hi, >> >> I tried to port and optimize the extremely simple VoxelSpace engine into >> Pharo. >> >> https://github.com/pavel-krivanek/VoxelSpace >> >> How to load >> >> Metacello new >> baseline: 'VoxelSpace'; >> repository: 'github://pavel-krivanek/VoxelSpace/src'; >> load. >> >> How to run >> >> Copy maps into the image directory and then evaluate: >> >> VoxelSpaceMorph new openInWindow. >> >> [image: VloÅ¾enÃ½ obrÃ¡zek 2] >> >> No external library is required. If you have some next ideas how to >> improve the rendering performace with the same image quality, please let me >> know. >> >> Cheers, >> -- Pavel >> >> >> >

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by stephan

On 28-11-17 22:08, Torsten Bergmann wrote: > Having the code directly in the root is possible but not a good style > or to be recommended - because often projects include more than just > the source code and over time include more and more things like docu > or other. Thanks for the explanation for where this comes from. This helps me understand where my confusion comes from: the assumption that there would be one root for source. That is not always the case. There can be multiple sub projects (casually used, not in the git subproject terms), each with their own source root. Mapping from smalltalk code to file systems has all kinds of annoying/interesting aspects. And I understand the difficulty/impossibility/undesirability of supporting everything that git makes possible. I seem to have missed some design discussions/decisions and really like the mails here about them. And I like the booklets very much too. Stephan

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by Esteban Lorenzano

> On 29 Nov 2017, at 07:19, Ben Coman <btc(a)openInWorld.com> wrote: > > On 29 November 2017 at 07:50, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Stephan Eggermont-3 wrote >>>> 2c) Code subdirectory: enter "src" here !!! >>> Do we really need that? Why would I care about that? >> >> BTW in latest Iceberg this is automatically selected if it is one of the >> standard names (e.g. src, repository) > > That is cool to automate that, but these names seem a bit generic to > take ownership across all domains in random projects. > How does the system handle a "src" folder that is not an iceberg folder. > What about having an "iceberg.conf" or ".iceberg.conf" file in the > root folder? there will be one :) > or maybe be more generic cross-platform friendly and use "tonel.conf". > This file might also be a place to specify multiple folders containing > different packages. no, because tonel is the fileformat, it does not says anything about the repository structure (which is iceberg related, not fileformat) > A few other random thoughts... > > Maybe that "Clone repository by URL" dialog could be split in two. > The "code subdirectory" field does not impact the cloning operation > and is an extra cognitive load when someone new to Iceberg is not sure > how it works, which breeds uncertainty about using the tool. > After the clone completes, Iceberg could observe the directories in > the working copy and present a list of them for user selection (if it > wasn't already specified in iceberg.conf) > > Alternatively, rather than (or in addition to) the [Packages] tab, > maybe have a [Working Copy] tab that shows a tree structure from the > root directory. I will remove packages and branches and any extra information from repositories window. I will find a better place for them :) > The user would then browse into the "src" file to see the packages. > This could lead Iceberg in the direction of being a more generic tool > to manage other project resources, > and also facilitate having multiple packages within the one repo, > although synchronising those > packages to their own single package repo might get complicated. > Directories specified in iceberg.conf could be listed at the top of > the [Working Copy] tab for easy access. better than that, you need to forget there is an external working copy (but the tool needs to allow you to handle your repository by ignoring that). Esteban > > cheers -ben >

Nov. 29, 2017