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
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! Thanks T.
Gesendet: Dienstag, 28. November 2017 um 15:41 Uhr Von: "Ben Coman" <btc@openinworld.com> An: "Pharo Development List" <pharo-dev@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
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. Bye T. [1] https://www.sohamkamani.com/blog/2015/08/21/frontend/ [2] https://maven.apache.org/guides/introduction/introduction-to-the-standard-di...
Gesendet: Dienstag, 28. November 2017 um 20:25 Uhr Von: stephan <stephan@stack.nl> An: pharo-dev@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
On 28 Nov 2017, at 22:08, Torsten Bergmann <astares@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-di...
Gesendet: Dienstag, 28. November 2017 um 20:25 Uhr Von: stephan <stephan@stack.nl> An: pharo-dev@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
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
Torsten Bergmann wrote
!- docker - for docker
Is anyone using a `docker` subfolder in a ST repo? I'm curious what one would store there and whether/how that would tie into GH/BB/GL CI infrastructures⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
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) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 29 November 2017 at 07:50, Sean P. DeNigris <sean@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
On 29 Nov 2017, at 07:19, Ben Coman <btc@openInWorld.com> wrote:
On 29 November 2017 at 07:50, Sean P. DeNigris <sean@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
Ben Coman wrote
That is cool to automate that, but these names seem a bit generic to take ownership across all domains in random projects.
I may have explained poorly. It merely guesses a default value in the repo creation form. One is free to change manually as always if needed. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 28 Nov 2017, at 20:25, stephan <stephan@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
On 29 November 2017 at 02:40, Torsten Bergmann <astares@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).
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. 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." 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. 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:" 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@openinworld.com> An: "Pharo Development List" <pharo-dev@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
Hi Ben, On 29 November 2017 at 06:51, Ben Coman <btc@openinworld.com> wrote:
On 29 November 2017 at 02:40, Torsten Bergmann <astares@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-tt4967262... Cheers, Alistair
On 29 Nov 2017, at 06:51, Ben Coman <btc@openInWorld.com> wrote:
On 29 November 2017 at 02:40, Torsten Bergmann <astares@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@openinworld.com> An: "Pharo Development List" <pharo-dev@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
On 28 Nov 2017, at 19:40, Torsten Bergmann <astares@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@openinworld.com> An: "Pharo Development List" <pharo-dev@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
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@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
participants (6)
-
Alistair Grant -
Ben Coman -
Esteban Lorenzano -
Sean P. DeNigris -
stephan -
Torsten Bergmann