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

Re: [Pharo-dev] FFIIntegerTypes inheritance hierarchy

by Esteban Lorenzano

> On 28 Nov 2017, at 16:25, Ben Coman <btc(a)openInWorld.com> wrote: > > I just bumped into... > FFUInt64>>basicHandle: aHandle at: index > ^ aHandle signedLongLongAt: index thatâs probably a bug :) Esteban > > and I'm curious why #unsignedLongLongAt: is not used. > Seems I had the same question a year ago... > > On 1 September 2016 at 22:09, Ben Coman <btc(a)openinworld.com> wrote: >> I'm looking through the keyhole at something new to me, so maybe this >> is off base, but looking at the inheritance hierarchy... >> >> FFIIntegerType >> FFIUint16 >> FFIUint16 >> FFIUInt32 >> FFIInt32 >> FFIUint64 >> FFIInt64 >> FFIUint8 >> FFIInt8 >> >> I'm curious... why the all the Ints inherit from the UInts? >> >> Each of those classes has the same two methods #basicHandle:at: and >> #basicHandle:at:put. So the Int subclasses fully override the >> superclass methods. So there in no inherited behaviour on the instance >> side. >> >> On the class side, I see #externalTypeSize is inherited by the Ints, >> but evaluating... >> FFIIntegerType allSubclasses collect: [ :class | >> class externalType byteSize -> class externalTypeSize ] >> produces... >> 4->4 >> 2->2 >> 4->4 >> 8->8 >> 1->1 >> 2->2 >> 4->4 >> 8->8 >> 1->1 >> >> So naively the extra inheritance level seems unnecessary >> and perhaps having... >> FFIIntegerType class >> externalTypeSize >> ^ self externalType byteSize >> >> would allow the hierarchy to be flattened. Maybe not a great benefit, >> except to avoid the next person wondering the same thing :P > > Perhaps its significantly faster to have the method directly return > the integer rather than do a few more message sends (??) > > cheers -ben > >> >> >> Also, it is surprising that that FFUInt64 uses #signedLongLongAt: >> rather than #unsignedLongLongAt: . This seems on-purpose rather than >> accidental since its inherited by FFIInt64, so it seems there is >> something interesting to learn here that would benefit a method >> comment. >> >> cheers -ben >

Nov. 28, 2017

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

by Torsten Bergmann

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…

Nov. 28, 2017

Re: [Pharo-dev] Iceberg workflow

by Torsten Bergmann

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

Re: [Pharo-dev] Would it be possible to also launch templates in PharoLauncher?

by Mariano Martinez Peck

On Tue, Nov 28, 2017 at 2:05 PM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi Mariano, > > > Le 27 nov. 2017 Ã 03:08, Mariano Martinez Peck <marianopeck(a)gmail.com> > a Ã©crit : > > > > Hi guys, > > > > Thank you Christophe for continue pushing this useful tool! > > > > One small request which might be easy to do... Quite frequently I want > to do something and re-save an image I have previosuly saved as a custom > template (under Local root tree). Right now what I have to do so: > > > > 1) Make a new image from that template > > 2) remove template > > 2) do the thing and save the opened image. > > 3) go back to laucher and save that image as a new template (with the > same name of the one I deleted) > > 4) delete the created image > > > > All that would be simplified if I could also launch my local templates. > Is there any reason why is that not allowed? (at least for Local tree). > > I needed to get a bit into the code to see what is done. > In PharoLauncher, when you download a template from the we, the template > is stored in a folder (e.g. /Users/john/Library/Preferences/pharo/templateCache/) > as well as some metadata for it. > PhLLocalTemplate class is used to build a list of locally available > templates from the metadata file store in this folder. > As this folder is intended to be a cache, thatâs why you cannot run it > directly. You first need to unzip the template, create its metadata file. > > Maybe an action on images: Â« create template from image and delete image Â» > would help you (if it allows overriding of an existing template)? > Yeah, that would work for me. So the only manual thing I would have to do is 1) right? that is, I would need to first create an image from the template, do whatever I want with that image, and then Â« create template from image and delete image Â» which would save that image as template (override it if exists) and delete the created image. If I understood correct, yes, it would achieve what I want. BTW, as a separate matter, even if you the templates as a cache, I think it still would be nice to be able to delete a given one. > You also have a Â« recreate Â» action on images able to recreate the image > from the specified origin template. > OK thanks in advance, -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-dev] Would it be possible to also launch templates in PharoLauncher?

by Christophe Demarey

Hi Mariano, > Le 27 nov. 2017 Ã 03:08, Mariano Martinez Peck <marianopeck(a)gmail.com> a Ã©crit : > > Hi guys, > > Thank you Christophe for continue pushing this useful tool! > > One small request which might be easy to do... Quite frequently I want to do something and re-save an image I have previosuly saved as a custom template (under Local root tree). Right now what I have to do so: > > 1) Make a new image from that template > 2) remove template > 2) do the thing and save the opened image. > 3) go back to laucher and save that image as a new template (with the same name of the one I deleted) > 4) delete the created image > > All that would be simplified if I could also launch my local templates. Is there any reason why is that not allowed? (at least for Local tree). I needed to get a bit into the code to see what is done. In PharoLauncher, when you download a template from the we, the template is stored in a folder (e.g. /Users/john/Library/Preferences/pharo/templateCache/) as well as some metadata for it. PhLLocalTemplate class is used to build a list of locally available templates from the metadata file store in this folder. As this folder is intended to be a cache, thatâs why you cannot run it directly. You first need to unzip the template, create its metadata file. Maybe an action on images: Â« create template from image and delete image Â» would help you (if it allows overriding of an existing template)? You also have a Â« recreate Â» action on images able to recreate the image from the specified origin template. Christophe

Nov. 28, 2017

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

by Christophe Demarey

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?

Nov. 28, 2017

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

by Christophe Demarey

> Le 25 nov. 2017 Ã 20:08, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > bpi wrote >> UndefinedObject(Object)>>doesNotUnderstand: #, >> PhLVirtualMachineManager>>vmFileName > > I usually get an error that looks like that when I try to launch a pre > Pharo-5 image. IIUC when Launcher is determining which VM to useâ¦ It probably means that the command used to determine the image version failed! Could you reproduce with the latest version? If so, please open an issue and a way to reproduce. Thanks, Christophe

Nov. 28, 2017

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

by Christophe Demarey

Hi Bernhard, > Le 25 nov. 2017 Ã 16:24, Bernhard Pieber <bernhard(a)pieber.com> a Ã©crit : > > Hi Stef, > > I just found download links on this page: > https://github.com/pharo-project/pharo-launcher > They point to Jenkins build artefacts. > > Thank you for implementing the launcher. As a newbie I ran into some questions: > > I guess the launcher is not self-updating, right? right. > If not, how can I find out if I already have the latest version? There is no way for now: https://github.com/pharo-project/pharo-launcher/issues/23 What you can do is to open Monticello and see if you have latest versions of the Launcher packages. Latest version is available at: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg (os X) http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip (linux) http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe (win) > I donât really understand what Local means. Is there a difference between Local > Pharo 6.1 (stable) and Official distributions > Pharo 6.1 (stable)? Local category lists templates you have on your machine. > And what is the difference between Local > Pharo6.1 (stable) and Local > latest? Hmm, when I launched Local > latest I got a debugger[1]. Probably you downloaded an image called Latest with the Launcher. It then has been added to the local category. > What also bothers me is that I cannot switch to the white theme in the settings. I just canât read the UI on the dark theme. We could add these setting easily. Could you open an issue ? https://github.com/pharo-project/pharo-launcher/issues Regards, Christophe.

Nov. 28, 2017

Re: [Pharo-dev] FFIIntegerTypes inheritance hierarchy

by Ben Coman

I just bumped into... FFUInt64>>basicHandle: aHandle at: index ^ aHandle signedLongLongAt: index and I'm curious why #unsignedLongLongAt: is not used. Seems I had the same question a year ago... On 1 September 2016 at 22:09, Ben Coman <btc(a)openinworld.com> wrote: > I'm looking through the keyhole at something new to me, so maybe this > is off base, but looking at the inheritance hierarchy... > > FFIIntegerType > FFIUint16 > FFIUint16 > FFIUInt32 > FFIInt32 > FFIUint64 > FFIInt64 > FFIUint8 > FFIInt8 > > I'm curious... why the all the Ints inherit from the UInts? > > Each of those classes has the same two methods #basicHandle:at: and > #basicHandle:at:put. So the Int subclasses fully override the > superclass methods. So there in no inherited behaviour on the instance > side. > > On the class side, I see #externalTypeSize is inherited by the Ints, > but evaluating... > FFIIntegerType allSubclasses collect: [ :class | > class externalType byteSize -> class externalTypeSize ] > produces... > 4->4 > 2->2 > 4->4 > 8->8 > 1->1 > 2->2 > 4->4 > 8->8 > 1->1 > > So naively the extra inheritance level seems unnecessary > and perhaps having... > FFIIntegerType class >> externalTypeSize > ^ self externalType byteSize > > would allow the hierarchy to be flattened. Maybe not a great benefit, > except to avoid the next person wondering the same thing :P Perhaps its significantly faster to have the method directly return the integer rather than do a few more message sends (??) cheers -ben > > > Also, it is surprising that that FFUInt64 uses #signedLongLongAt: > rather than #unsignedLongLongAt: . This seems on-purpose rather than > accidental since its inherited by FFIInt64, so it seems there is > something interesting to learn here that would benefit a method > comment. > > cheers -ben

Nov. 28, 2017

Iceberg workflow

by Ben Coman

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