- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Iceberg workflow

by Esteban Lorenzano

> On 28 Nov 2017, at 20:25, stephan <stephan(a)stack.nl> wrote: > > 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? because you want to structure your projects as you want, and not as some tool (ours or other) forces to do it. Esteban > > Stephan > >

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by Esteban Lorenzano

> On 28 Nov 2017, at 19: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. > 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 > 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. > > If there are other groups defined you can use "Install baseline ..." > > So you missed the step 2c. > > Hope this helps! +1 :) > > 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

Hi Ben, we have been discussing a lot this issues in discord recently (expectations from git users, monticello users and what iceberg needs to do/show in which case). basically, we have a mess on terminology and some workflows needs to be enhanced. Now, about your observations: a) more than split âcloneâ, what I will do is to unify all that functionality into a single âadd repositoryâ. Now, it has to be clear for user that adding a repository (by cloning, creating or adding a local existing one) does not means injecting any sources into the image. You will need to do that explicitly (by telling âcheckoutâ or better âcheckout with baselineâ). Is important that people understands that checking out in pharo is a lot more complex than simply checking out some files in filesystem. And is not the job of iceberg. b) you are not seeing any package because you are not pointing to the source subdirectory. That needs to be explicit when declaring a repository (there are technics to detect the good one, but so far they are a bit naive ;) ) cheers, Esteban > On 28 Nov 2017, at 15:41, Ben Coman <btc(a)openInWorld.com> wrote: > > 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] I love the launcher!!!!

by Christophe Demarey

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

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

by Christophe Demarey

> Le 28 nov. 2017 Ã 21:53, Volkert <volkert(a)komponentenwerkstatt.de> a Ã©crit : > > > > On 28.11.2017 17:33, Christophe Demarey wrote: >> Hi, >> >> >>> Le 25 nov. 2017 Ã 21:45, Volkert <volkert(a)komponentenwerkstatt.de> a Ã©crit : >>> >>> The PharoLauncher is really nice ... >>> >>> Is it possible to use a 64Bit VM run an Image (6.1 >)? Per default a >>> 32bit VM is downloaded. >> Yes, Pharo Launcher manages 32-bits and 64-bits VM. (https://github.com/pharo-project/pharo-launcher/issues/35) >> Maybe you do not have the latest version? > i use PharoLauncher-user-stable-2017.11.24. > > How do i choose the 64-bit image? In ~/Pharo/vms if find only xx-x86 vms You can choose, from Pharo 6.0 templates group, latest-64 by example. Pharo Launcher will then download a 64-bits vm to run this image

Nov. 29, 2017

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

by Christophe Demarey

> Le 29 nov. 2017 Ã 00:52, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >>> pre Pharo-5 image >> It probably means that the command used to determine the image version >> failed! > > Oh, are Pharo 4 and prior supposed to work? I figured they were just not > intended to be supported Yes, I'm able to run pharo 1.4 images. Maybe it could be related to this bug: https://github.com/pharo-project/pharo-launcher/issues/52

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by Alistair Grant

Hi Ben, On 29 November 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). I haven't tried 64 bit for a couple of months, however I had similar behaviour, see http://forum.world.st/Iceberg-causes-64-bit-VM-core-dump-on-Ubuntu-tt496726… Cheers, Alistair

Nov. 29, 2017

Re: [Pharo-dev] Iceberg workflow

by Ben Coman

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? 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. 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. 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. cheers -ben

Nov. 29, 2017