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

Re: [Pharo-dev] Iceberg workflow

by Ben Coman

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). > 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(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

(no subject)

by Ben Coman

A minor thing, but a fix is probably easy... I have... FFIExternalStructure subclass: #CXSourceLocation instanceVariableNames: '' classVariableNames: 'VoidPointer2' package: 'Libclang' initialize "self initialize" VoidPointer2 := FFITypeArray ofType: 'void*' size: 2. fieldsDesc "self rebuildFieldAccessors" ^#( VoidPointer2 ptr_data; uint int_data; ) Now when I debug into "self rebuildFieldAccessors" into #compileFields:withAccessors: through "fieldSpec fieldsAndTypesDo: [ :fieldName :type | " the [Variables] tab shows... type "FFITypeArrayType(a subclass of FFITypeArray)" and my perception is that this is wrong since FFITypeArrayType is not a subclass FFITypeArray. Intuitively I'm reading the text in the round brackets as a commentary on FFITypeArrayType. But debugging into "type printString" bring me to FFITypeArrayType(FFIExternalReferenceType) >> printOn: aStream aStream << self className << '(' << objectClass name << ')' where objectClass is an instance variable, so the commentary is about composition rather than inheritance. Now I properly understand the truth, I still have trouble with perceiving the printString the wrong way, so I'd like to add a visual cue that this is composition. Do we have such a standard convention? Options... 1. Square brackets a. FFITypeArrayType[a subclass of FFITypeArray] b. FFITypeArrayType([a subclass of FFITypeArray]) 2. Curly brackets a. FFITypeArrayType{a subclass of FFITypeArray} b. FFITypeArrayType({a subclass of FFITypeArray}) 3. Array-ish a. FFITypeArrayType#(a subclass of FFITypeArray) b. FFITypeArrayType(#(a subclass of FFITypeArray)) 4. Text a. FFITypeArrayType(holding a subclass of FFITypeArray) I'm tending towards [2a] or [2b] since two brackets together seem more distinct. It may be easy to overlook a difference in a single bracket, and also it feels more like holding something inside the object. cheers -ben P.S. Regarding the existing Libclang bindings. I'm not trying to compete but more along the line... "its worthwhile reinventing the wheel when you want to learn more about how a wheel works." I'll switch over to existing bindings in a while.

Nov. 29, 2017

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

by Sean P. DeNigris

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 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 28, 2017

Re: [Pharo-dev] Iceberg workflow

by Sean P. DeNigris

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

Nov. 28, 2017

[Pharo 7.0-dev] Build #346: 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 #346 was: FAILURE. 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. 28, 2017

Re: [Pharo-dev] VoxelSpace

by Pavel Krivanek

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. 28, 2017

Re: [Pharo-dev] Iceberg workflow

by Torsten Bergmann

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-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. 28, 2017

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

by Volkert

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

Nov. 28, 2017

Re: [Pharo-dev] VoxelSpace

by Volkert

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. > > 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. 28, 2017

Re: [Pharo-dev] Iceberg workflow

by stephan

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. 28, 2017