- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Iceberg workflow

by Esteban Lorenzano

> On 29 Nov 2017, at 06:51, Ben Coman <btc(a)openInWorld.com> wrote: > > On 29 November 2017 at 02:40, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Ben, >> >> I think you forgot to give Iceberg the "src" subdirectory where all the code packages reside. > > Not such much forgot and not being aware of the impact of that field :P ;) > >> When you forget to give the "Code subdirectory" in the dialog the repo points to the >> bencoman/libclang-pharo-bindings root which has no packages. Thats why the packages >> pane is empty. >> >> So I think you should: >> >> 1. World Menu -> Iceberg >> 2. In the dialog >> 2a) Set Remote URL: https://github.com/bencoman/libclang-pharo-bindings.git >> 2b) Local directory: shows where the repo is locally clone to (keep it or change as you like) >> 2c) Code subdirectory: enter "src" here !!! >> 3. Then click on/select the repository "libclang-pharo-bindings" in the upper pane of Iceberg >> 4. Click on the "Packages" pane in the lower part - you now will see all packages in the repo > > Thx. That worked in 32 bit. > However in 64 bit when I do step 2 the Image exits (i.e. no debug log). weird, Iâm using exclusively 64bits since some time and I do not experiment this problems :S > >> 5. You can either select each package and right click to "Load package" the package one by one >> OR you select the "BaselineOfLibClang" and right click to "Metacello" -> "Install baseline (default)" which >> would load the "default" group of what is defined in the baseline. This usually loads all dependencies >> and the necessary packages in the right order. > > I did BaselineOfLibClang > Metacello > Install baseline (default) > and got error "#addTo: was sent to nilâ > > So I had heard about enabling Metacello integration**, and after enabling that, > BaselineOfLibClang > Metacello > Install baseline (default) > proceeded fine. System Browser now shows the LIbClang package. Ah yesâ¦ this is an ongoing bug since some time :( > However Iceberg did not refresh. All packages still show "Not Loaded". > and clicking on the [Branches] tab gives error... > "Instance of IcePackageModel did not understand #isBranchModel.â this is a glamour transition bug (ongoing too). I plan to fix that by just removing that tab (I will move branches out of repositories window). > > However a newly opened Iceberg fixes both these, showing "Up to date" > in [packages] tab, > and several branches in [Branches] tab. > > Now "LibClang-FFI-Types" already shows dirty with "Uncommited changes" > maybe due to class initialisation updating some methods. > How do I then view the changes? I was hoping to see a "View changes" item > in the "LibClang-FF-Types" context menu. > > I see the context menu for the repo has "Synchronize repository...." > which brings up a [Local changes] tab, but it is empty. yeah, this is because when installing packages were marked as âdirtyâ but in fact there is nothing changed (this is a monticello historical problem, not icebeg relatedâ¦) > > In Monticello if I select the dirty package and the disk repo then > click <Changes> > I get error... "Instance of IceMetacelloRepositoryAdapter did not > understand #closestAncestorVersionFor:ifNone:â you should not be able to use monticello with iceberg repositories. the error here is not showing a correct error message, not not showing the changes :) cheers, Esteban > > Can anyone reproduce this? > > cheers -ben > > ** Maybe if Metacello integration is disabled the menu option in > Iceberg should greyed out. > > >> >> If there are other groups defined you can use "Install baseline ..." >> >> So you missed the step 2c. >> >> Hope this helps! >> >> Thanks >> T. >> >> >> >> >>> Gesendet: Dienstag, 28. November 2017 um 15:41 Uhr >>> Von: "Ben Coman" <btc(a)openinworld.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: [Pharo-dev] Iceberg workflow >>> >>> I'm still struggling with Iceberg workflow for a personal repo. >>> >>> World menu > Iceberg >>> Clicked <Clone Repository> >>> Remote URL <-- git@github.com:bencoman/libclang-pharo-bindings.git >>> Clicked <Create Repository> >>> >>> So now I have a new row... >>> Name = libclang-pharo-bindings >>> Current Branch = master >>> Loaded version = No package loaded >>> Status = Not loaded >>> >>> but nothing loaded into Image, which seems expected from Iceberg >>> Operations Overview... >>> * http://forum.world.st/Iceberg-operations-overview-td5036218.html >>> (even though "Clone" is not shown there, I guess its the same as "Checkout") >>> but I can't work out how to load it. >>> >>> In the filesystem I see the repo has been checked out, under... >>> /home/ben/Pharo/images/latest-64-02/pharo-local/iceberg/bencoman/libclang-pharo-bindings >>> >>> Now from Iceberg Operations Overview, I guess I need to either load, >>> merge, reload or pull. These all are apparently exposed in the UI. >>> Right-clicking on the repo, the only one I see is "Pull incoming >>> commits" and... Pharo quietly exits, with no debug log. >>> >>> Restarting to gather more info, after selecting the repo, the >>> [Packages] tab is empty (maybe that is normal). Then I try >>> Right-click>Refresh Repository with no effect. >>> >>> Right-click > Synchronize Repository takes me to three tabs with empty >>> list views. >>> The [Update] tab has a <Pull> button which also causes Pharo to exit. >>> >>> Versions... >>> Ubuntu 16.04-64bit >>> Pharo-7.0+alpha.build.300.sha.f81891fbde76d6a92e2827229293cb377d3b2c1c (64 Bit) >>> Unix built on Aug 27 2017 20:00:40 Compiler: 4.6.3 >>> VMMaker versionString VM: 201708271955 >>> >>> cheers -ben >>> >>> >> >

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by Esteban Lorenzano

> On 28 Nov 2017, at 22:08, Torsten Bergmann <astares(a)gmx.de> wrote: > > You do not have to use "src" or "repository" - you can store your packages directly in the root if you > like. You are free to choose. But over time it can "bloat" the topmost level of your project with the > Smalltalk packages folders and it might get confusing the more packages you have or the more other > stuff you add to your project. > > Often it depends on personal style or the complexity of the overall contents of the project. > > 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. > > Thats why usually projects are STRUCTURED with subdirectories and these subfolders helping you or a user of your > project to easily find out about what to expect as contents. Some possible subdirectories you might find in one or the > other projects are: > > root (Project root dir) > !- src - for source code and source packages > !- bin - for built binaries or executables > !- doc - for documentation, sometimes also "docs" > !- www - for web related stuff that is served via HTTP/webserver > ! !-- css - for stylesheets > ! !-- js - for javascript scripts > ! > !- templates - for templates > !- include - includes (for instance in C/C++ projects) > !- lib - for libraries > !- test - for tests or test drivers > !- third_party - for third party stuff (that is required to run the project) > !- ci - for CI related scripts or other > !- docker - for docker > !- media - for video, pictures or other related project media > !- benchmark - for speed tests and benchmarks > !- config - for configurations > !- etc - for anything else > !- ... > > This is not a complete list and different people prefer a different project layout. There might be other subfolders. > Often the name varies depending on language or framework. Also some build technologies enforce a specific layout. > > For example if you work with web applications you often have a layout as described in [1], with Java software > like maven you usually have no "bin" but a "target" folder, see [2]. There never was an agreement of a layout that > fits all the needs - so we can only speak about a "typical folder structure". > > Same for files. As files in the root folder I "typically" would expect only a few files: > - a README.txt or README.md > - a license file > - config files for build systems (like pom.xml for Maven, package.json in NodeJs/npm, Gruntfile.js for Grunt, bower.json for bower, ...) > - a .travis.yml for travis builds > - ... > > A "src" or "source" subdir is very often used to host the code. Thats why the Iceberg dialog just allows > to tell in which subfolder of the project Iceberg will find the code if you structure your project with such > a layout. If you leave it blank all packages are expected in the root folder. > > So you can either put the packages directly into the root like in > > https://github.com/astares/iceberg > > or have a "src" subdirectory or other as in > > https://github.com/pharo-project/pharo > > or many of the other Pharo or non-Pharo projects on GitHub. > > Hope this explains it. +1000 thanks Torsten :) Esteban > > Bye > T. > > [1] https://www.sohamkamani.com/blog/2015/08/21/frontend/ > [2] https://maven.apache.org/guides/introduction/introduction-to-the-standard-d… > > >> Gesendet: Dienstag, 28. November 2017 um 20:25 Uhr >> Von: stephan <stephan(a)stack.nl> >> An: pharo-dev(a)lists.pharo.org >> Betreff: Re: [Pharo-dev] Iceberg workflow >> >> On 28-11-17 19:40, Torsten Bergmann wrote: >>> 2c) Code subdirectory: enter "src" here !!! >> >> Do we really need that? Why would I care about that? >> >> Stephan >> >> >> >

Nov. 29, 2017