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

[Pharo 7.0-dev] Build #1376: 22656-Improve-ImageReadWriter-comments

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1376 was: SUCCESS. The Pull Request #1970 was integrated: "22656-Improve-ImageReadWriter-comments" Pull request url: https://github.com/pharo-project/pharo/pull/1970 Issue Url: https://pharo.fogbugz.com/f/cases/22656 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 11, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Denis Kudriashov

Ð¿Ð½, 29 Ð¾ÐºÑ. 2018 Ð³. Ð² 10:07, Guillermo Polito <guillermopolito(a)gmail.com>: > Well, there are still variants > - chooseFile* > - fileOpen* > - fileSave* > - chooseFileName* > - chooseFullFileName* > > I prefered rather to be explicit and to avoid confusion with the old API > (which I deprecated, not removed!) > Ok. For current situation it is probably the right thing to do. And monstrous names are easy to rename/deprecate in future. But I don't think that in clean system (without old API) using just a File in such names needs special explanation. Because we postulate that only file references are exposed to users. User chooses a file and Pharo gives him a reference to this file. > > On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> What about different names? >> >> UIManager default >> chooseFileIn: aFileReference >> withExtensions: #() >> title: 'title' >> >> UIManager default >> chooseFileForSaveIn: aFileReference >> withExtensions: #() >> title: 'title' >> >> We can just expect file references because it is what is exposed to users >> in pharo file system. Not neccessery to put it in method name. >> >> Ð¿Ñ, 26 Ð¾ÐºÑ. 2018 Ð³., 16:32 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Hi all, >>> >>> I've proposed a PR with some cleanups in this respect >>> >>> https://github.com/pharo-project/pharo/pull/1941 >>> >>> This is the proposed replacement API that returns file references >>> instead of streams or file names. >>> >>> "Get existing file reference" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: nil >>> path: FileSystem workingDirectory. >>> >>> "Get existing file reference filtering by extensions" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: #('log') >>> path: FileSystem workingDirectory. >>> >>> "Get existing file reference to file" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: nil >>> path: FileSystem workingDirectory / 'PharoDebug.log'. >>> >>> "Get file reference for save (not necessarily existing)" >>> UIManager default >>> chooseForSaveFileReference: 'title' >>> extensions: #('log') >>> path: 'PharoDebuasdg.log'. >>> >>> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Ok, so can we agree on deprecating the non compatible methods and >>>> redirect the user to the new ones? >>>> >>>> To me, the problem with returning a stream is that from a user >>>> perspective you don't know: >>>> - is the file encoded or binary >>>> - if it is encoded, in which encoding? >>>> - if i receive an open file stream, and I want to delete that file I >>>> have to close it, retrieve the file, delete it? >>>> - IMHO, what is the worst: whose responsibility is it to close the >>>> file? >>>> >>>> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>>> > It should return a FileReference, not an open stream. I believe >>>>> there are methods that do that. >>>>> >>>>> There are different APIs for that. >>>>> >>>>> fileOpen*, as the name implies, _opens the file_ and returns the >>>>> stream. (I think this should be the case for fileSave*) >>>>> >>>>> If you want file reference, then you can use e.g. >>>>> >>>>> UIManager default chooseFileMatching: #() label: nil >>>>> >>>>> or `chooseFileMatching:label:`, >>>>> `chooseFileName:extensions:path:preview:`, >>>>> `chooseFullFileName:extensions:path:preview:`, >>>>> `chooseFullFileNameMatching:label:`. >>>>> Also some methods for selecting directories >>>>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >>>>> >>>>> iirc some of them actually return String (file path) instead of >>>>> FileReference. ( >>>>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >>>>> ) >>>>> >>>>> So it can be confusing, but the API is already available. >>>>> >>>>> Also iirc UIManager should be preferred over UITheme builder. >>>>> >>>>> Peter >>>>> >>>>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > A question to those who worked on the new streams for Pharo 7: >>>>>> > >>>>>> > >>>>>> > In PHARO 6 I used the following expression to open a file dialog >>>>>> and let the user choose >>>>>> > a binary file: >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: >>>>>> #('exe'). >>>>>> > >>>>>> > This returned >>>>>> > - either nil (when file dialog was canceled) >>>>>> > - a "MultiByteFileStream" instance when a file was selected >>>>>> > >>>>>> > The MultiByteFileStream instance already had the name of the file >>>>>> (= full path) and I was >>>>>> > able to query it for further use: >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>>> > s name inspect >>>>>> > >>>>>> > (for instance to display which file is processed in a window by >>>>>> showing the full path) >>>>>> > >>>>>> > >>>>>> > >>>>>> > Now in PHARO 7 same expression returns an instance of >>>>>> ZnCharacterReadStream (as MultiByteFileStream >>>>>> > is deprecated): >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>>> > >>>>>> > and ZnCharacterReadStream does not understand #name - and in fact >>>>>> the info about the name is >>>>>> > totally lost/not available. To me this looks missing/broken. >>>>>> > >>>>>> > So what is the recommended way in Pharo 7 to open a file dialog, >>>>>> let the use choose a file >>>>>> > and get a file stream but also the name? IMHO this is either broken >>>>>> or missing... >>>>>> > >>>>>> > Thanks >>>>>> > T. >>>>>> >>>>>> It should return a FileReference, not an open stream. I believe there >>>>>> are methods that do that. >>>>>> >>>>>> But that is an incompatible API change (same selector, different >>>>>> return type). So hard to decide. >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 >>> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

I am quite happy with the new FileReference API. Le 11/11/2018 Ã 13:51, Sven Van Caekenberghe a Ã©critÂ : > API changes are always annoying, but splitting reading and writing as well as binary and character streams is a clear improvement overall. > -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Sven Van Caekenberghe

> On 11 Nov 2018, at 10:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > File is a low level API that is only used in limited circumstances, > e.g. bootstrapping when FileSystem isn't yet available. Another reason not to use File is because it is slower as it is unbuffered. For the following file $ file test.png test.png: PNG image data, 950 x 936, 8-bit/color RGBA, non-interlaced $ ls -la test.png -rw-r--r--@ 1 sven staff 241773 Nov 11 13:39 test.png I get [ ImageReadWriter formFromFileNamed: 'test.png' ] bench. "'8.725 per second'" [ ImageReadWriter formFromStream: 'test.png' asFileReference binaryReadStream ] bench. "'8.914 per second'" [ ImageReadWriter formFromStream: (File named: 'test.png') readStream ] bench. "'6.023 per second'" By preventing the auto detection of the type and the subclass lookup, we can improve a little bit more. [ PNGReadWriter formFromStream: 'test.png' asFileReference binaryReadStream ] bench. "'9.113 per second'" Sven

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Sven Van Caekenberghe

> On 11 Nov 2018, at 12:24, Hilaire <hilaire(a)drgeo.eu> wrote: > > Confusion from my part (it was 6 months ago), I have to use > #binaryReadStream to load PNG preview, and utf-8 based file (I was not > doing this distinction previously). > > I changed the code in P7 in several part as it broke and it was confusing. API changes are always annoying, but splitting reading and writing as well as binary and character streams is a clear improvement overall.

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

I filled a bug ticket about the change: https://bugs.launchpad.net/drgeo/+bug/1780820 -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

Confusion from my part (it was 6 months ago), I have to use #binaryReadStream to load PNG preview, and utf-8 based file (I was not doing this distinction previously). I changed the code in P7 in several part as it broke and it was confusing. https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/revision/608#src… Le 11/11/2018 Ã 11:41, Sven Van Caekenberghe a Ã©critÂ : > So how do you load you PNG's then in P7 ? -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Sven Van Caekenberghe

So how do you load you PNG's then in P7 ? > On 11 Nov 2018, at 11:25, Hilaire <hilaire(a)drgeo.eu> wrote: > > In P7, I have to change the code to load PNG image, and I end up not > using binary alternative... > > Le 11/11/2018 Ã 11:18, Sven Van Caekenberghe a Ã©crit : >> I don't understand what you are saying. > > -- > Dr. Geo > http://drgeo.eu > > >

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

In P7, I have to change the code to load PNG image, and I end up not using binary alternative... Le 11/11/2018 Ã 11:18, Sven Van Caekenberghe a Ã©critÂ : > I don't understand what you are saying. -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Sven Van Caekenberghe

> On 11 Nov 2018, at 10:59, Hilaire <hilaire(a)drgeo.eu> wrote: > > I met that situation too with P7. It occurred to me that the precise > need of #binaryReadStream message vanished. I don't understand what you are saying. Like Alistair says, FileReference is the public interface. The messages to open streams are #readStream #writeStream for text streams (utf8 character encoded) and #binaryReadStream #binaryWriteStream for raw unencoded binary streams. In most cases, it is better to use the #xDo: variant. It is no longer possible to switch streams using #binary. > Hilaire > > Le 11/11/2018 Ã 10:03, Stephane Ducasse a Ã©crit : >> Hi >> >> I'm checking some of the mooc code in Pharo 70. >> >> The Pharo 50/60 version is >> >> PNGReadWriter createAFormFrom: 'Sprites.png' asFileReference >> binaryReadStream upToEnd >> >> I came up with >> >> PNGReadWriter formFromStream: (File named: 'Sprites.png') readStream >> >> And we can also have >> >> PNGReadWriter formFromStream: 'Sprites.png' asFileReference binaryReadStream >> >> I will add this in the comment of the formFromStream: method. >> >> Stef >> > -- > Dr. Geo > http://drgeo.eu > > >

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

I met that situation too with P7. It occurred to me that the precise need of #binaryReadStream message vanished. Hilaire Le 11/11/2018 Ã 10:03, Stephane Ducasse a Ã©critÂ : > Hi > > I'm checking some of the mooc code in Pharo 70. > > The Pharo 50/60 version is > > PNGReadWriter createAFormFrom: 'Sprites.png' asFileReference > binaryReadStream upToEnd > > I came up with > > PNGReadWriter formFromStream: (File named: 'Sprites.png') readStream > > And we can also have > > PNGReadWriter formFromStream: 'Sprites.png' asFileReference binaryReadStream > > I will add this in the comment of the formFromStream: method. > > Stef > -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Alistair Grant

Hi Stef, On Sun, 11 Nov 2018 at 10:04, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I'm checking some of the mooc code in Pharo 70. > > The Pharo 50/60 version is > > PNGReadWriter createAFormFrom: 'Sprites.png' asFileReference > binaryReadStream upToEnd > > I came up with > > PNGReadWriter formFromStream: (File named: 'Sprites.png') readStream > > And we can also have > > PNGReadWriter formFromStream: 'Sprites.png' asFileReference binaryReadStream > > I will add this in the comment of the formFromStream: method. FileReference is the normal public interface to the file system, while File is a low level API that is only used in limited circumstances, e.g. bootstrapping when FileSystem isn't yet available. Most users shouldn't have to worry about File, so I'd leave it out as an example. Cheers, Alistair

Nov. 11, 2018

How do I create a binary stream

by Stephane Ducasse

Hi I'm checking some of the mooc code in Pharo 70. The Pharo 50/60 version is PNGReadWriter createAFormFrom: 'Sprites.png' asFileReference binaryReadStream upToEnd I came up with PNGReadWriter formFromStream: (File named: 'Sprites.png') readStream And we can also have PNGReadWriter formFromStream: 'Sprites.png' asFileReference binaryReadStream I will add this in the comment of the formFromStream: method. Stef

Nov. 11, 2018

[Pharo 7.0-dev] Build #1375: 22561-uFFI-should-not-require-decompilation-to-extract-sender-selector

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1375 was: SUCCESS. The Pull Request #1897 was integrated: "22561-uFFI-should-not-require-decompilation-to-extract-sender-selector" Pull request url: https://github.com/pharo-project/pharo/pull/1897 Issue Url: https://pharo.fogbugz.com/f/cases/22561 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2018

Re: [Pharo-dev] WELL512 PRNG

by Stephane Ducasse

I remember that I collected many of them and put them in PolyMath. On Fri, Nov 9, 2018 at 6:40 PM Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > On Fri, Nov 9, 2018 at 5:54 PM Norbert Hartl <norbert(a)hartl.name> wrote: > >> I was about to say letâs add this to the Cryptography package ð >> >> > How much RNGs are implemented in the crypto packages ? > Maybe we need to sync one day :-) > > -- > Serge Stinckwic > h > > Int. Research Unit > on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University > (SU) > French National Research Institute for Sustainable Development (IRD) > U > niversity of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich >

Nov. 9, 2018

Action list for Pharo 70 release

by Stephane Ducasse

Hi The team got a meeting about the final points to address before the release. Here is the summary of action points one and to do to the meeting next month. Done: Release - version info from tag Calypso - Traits (In calypso repository, not yet in Pharo) - Extensions (In calypso repository, not yet in Pharo) Doing: Release - File name / repository should take tag information => Esteban - Launcher should be updated automatically without having to touch it => Christophe - Update Zeronconf => Esteban + Vincent Calypso - Review refactorings => Vincent - Integrated Spotter shortcut => Esteban - Selection/Navigation => ??? Selection glitches (see why sometimes focus is broken and cmd+W is wrong) => Pavel FFI recompilation of Structures => Guille Backport Unicode Support from Launcher => Guille FT2 bug, update Freetype library => Esteban Cleaning pharo-scripts repository => ??? Start preparing changes log => Marcus >From what I understood the window 64 bits is to unstable to be proposed. Stef

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Esteban Maringolo

El vie., 9 nov. 2018 a las 15:02, Alistair Grant (<akgrant0710(a)gmail.com>) escribiÃ³: > Hi Christophe, > > On Fri, 9 Nov 2018 at 15:15, Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: > > > > For now, to work around the problem, I will add a windows to easily > update the VMs from the launcher UI. > > It should be possible to check if there is a new VM by just requesting > the headers for the download URL. You could then add a "Check for > new VM" button / menu item, and maybe even have a setting to do it > each time the launcher is started. > > Or "check for new VMs on startup" kind of thing. I like that approach. Esteban A. Maringolo

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Alistair Grant

Hi Christophe, On Fri, 9 Nov 2018 at 15:15, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > For now, to work around the problem, I will add a windows to easily update the VMs from the launcher UI. It should be possible to check if there is a new VM by just requesting the headers for the download URL. You could then add a "Check for new VM" button / menu item, and maybe even have a setting to do it each time the launcher is started. Cheers, Alistair

Nov. 9, 2018

Re: [Pharo-dev] WELL512 PRNG

by Serge Stinckwich

On Fri, Nov 9, 2018 at 5:54 PM Norbert Hartl <norbert(a)hartl.name> wrote: > I was about to say letâs add this to the Cryptography package ð > > How much RNGs are implemented in the crypto packages ? Maybe we need to sync one day :-) -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Nov. 9, 2018

Re: [Pharo-dev] WELL512 PRNG

by Norbert Hartl

I was about to say letâs add this to the Cryptography package ð > Am 09.11.2018 um 15:34 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > Can you contribute your code to PolyMath: https://github.com/PolyMathOrg/PolyMath > We have other RNGs available. > > Thank you. > >> On Fri, Nov 9, 2018 at 3:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> By accident I came across a pseudo random number generator that I never heard off before. It is supposed to be pretty good and had a very simple implementation. So I ported it to Pharo. >> >> <class comment> >> >> I am RandomWELL512, a random number generator. >> >> I use the PRNG (Pseudo Randon Number Generator) WELL (Well equidistributed long-period linear) with a 512 bit state. >> >> https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear >> http://www.iro.umontreal.ca/~lecuyer/myftp/papers/wellrng.pdf >> >> Implementation algorithm (See #nextUInt32) >> >> http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf (Chris Lomont, www.lomont.org) >> >> Usage >> >> RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextUInt32 ] ]. >> >> RandomWELL512 new useUnixRandomGeneratorSeed; in: [ :r | (1 to: 10) collect: [ :i | r next ] ]. >> >> RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextInt: 1000 ] ]. >> >> RandomWELL512 new in: [ :random | | count all | >> random useUnixRandomGeneratorSeed. >> count := 1024 * 1024. >> all := Array new: count streamContents: [ :out | >> count timesRepeat: [ out nextPut: random next ] ]. >> { all min. all max. all average. all stdev } ]. >> >> [ RandomWELL512 new in: [ :random | 1 to: 1e6 do: [ :i | random next ] ] ] timeToRun. >> >> Note that you should create one instance, seed it properly, and keep using it. >> >> </class comment> >> >> It is acceptably fast, generating 1M [0,1) Floats in about 0.1s. I compared the output with a fixed initial state to the C code that I started from and I got the same numbers. Maybe some people find this interesting. >> >> I attached a file out. >> >> Sven >> >> >> > > > -- > Serge Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Mariano Martinez Peck

On Fri, Nov 9, 2018 at 11:15 AM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi, > > Le 9 nov. 2018 Ã 14:11, Mariano Martinez Peck <marianopeck(a)gmail.com> a > Ã©crit : > > > > On Fri, Nov 9, 2018, 10:06 Christophe Demarey <christophe.demarey(a)inria.fr > wrote: > >> Hi Mariano, >> >> Le 8 nov. 2018 Ã 20:47, Mariano Martinez Peck <marianopeck(a)gmail.com> a >> Ã©crit : >> > >> > Hi All, >> > >> > I am having this same problem with the #fileDescriptorType: in a >> PharoLauncher 1.4.6 64 bits trying to launch a >> Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 >> Bit). >> > >> > Any ideas? >> >> It is because your pharo 70 vm is too old. >> You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in >> pharo/vm/private) and it should work. >> >> >> >> > Hi Christophe, > > Thanks for the workaround. But let me ask.. Wasn't one of the launcher > purposes to automatically download the necessary correct VM for the image > you are creating? To avoid this exact kind of issue? > > > Launcher magic has its boundaries. > The information available to the launcher to determine the appropriate VM > to run an image is: > - the image format number (encoded in the image header) > - the pharo version (system version) of the image (need to run the image > to know that information). > > In your case, you have an image with the same image format number, same > pharo version (7.0) but with incompatible changes requiring a new VM. Pharo > Launcher has no way to get this information. > This problem only happens with moving Pharo versions : the development > version. > > The best option would be to encode the Pharo version as a semantic version > in the header of the image file but it requires a lot of changes. > > For now, to work around the problem, I will add a windows to easily update > the VMs from the launcher UI. > > OK, I understand. Thanks for the explanation Christophe. I can also confirm that the workaround of removing by hand the VM directory did fix my issue. Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2018

Re: [Pharo-dev] WELL512 PRNG

by Serge Stinckwich

Can you contribute your code to PolyMath: https://github.com/PolyMathOrg/PolyMath We have other RNGs available. Thank you. On Fri, Nov 9, 2018 at 3:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > By accident I came across a pseudo random number generator that I never > heard off before. It is supposed to be pretty good and had a very simple > implementation. So I ported it to Pharo. > > <class comment> > > I am RandomWELL512, a random number generator. > > I use the PRNG (Pseudo Randon Number Generator) WELL (Well equidistributed > long-period linear) with a 512 bit state. > > https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear > http://www.iro.umontreal.ca/~lecuyer/myftp/papers/wellrng.pdf > > Implementation algorithm (See #nextUInt32) > > http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf (Chris > Lomont, www.lomont.org) > > Usage > > RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextUInt32 ] > ]. > > RandomWELL512 new useUnixRandomGeneratorSeed; in: [ :r | (1 to: 10) > collect: [ :i | r next ] ]. > > RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextInt: 1000 > ] ]. > > RandomWELL512 new in: [ :random | | count all | > random useUnixRandomGeneratorSeed. > count := 1024 * 1024. > all := Array new: count streamContents: [ :out | > count timesRepeat: [ out nextPut: random next ] ]. > { all min. all max. all average. all stdev } ]. > > [ RandomWELL512 new in: [ :random | 1 to: 1e6 do: [ :i | random next ] ] > ] timeToRun. > > Note that you should create one instance, seed it properly, and keep using > it. > > </class comment> > > It is acceptably fast, generating 1M [0,1) Floats in about 0.1s. I > compared the output with a fixed initial state to the C code that I started > from and I got the same numbers. Maybe some people find this interesting. > > I attached a file out. > > Sven > > > > -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Nov. 9, 2018

WELL512 PRNG

by Sven Van Caekenberghe

Hi, By accident I came across a pseudo random number generator that I never heard off before. It is supposed to be pretty good and had a very simple implementation. So I ported it to Pharo. <class comment> I am RandomWELL512, a random number generator. I use the PRNG (Pseudo Randon Number Generator) WELL (Well equidistributed long-period linear) with a 512 bit state. https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear http://www.iro.umontreal.ca/~lecuyer/myftp/papers/wellrng.pdf Implementation algorithm (See #nextUInt32) http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf (Chris Lomont, www.lomont.org) Usage RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextUInt32 ] ]. RandomWELL512 new useUnixRandomGeneratorSeed; in: [ :r | (1 to: 10) collect: [ :i | r next ] ]. RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextInt: 1000 ] ]. RandomWELL512 new in: [ :random | | count all | random useUnixRandomGeneratorSeed. count := 1024 * 1024. all := Array new: count streamContents: [ :out | count timesRepeat: [ out nextPut: random next ] ]. { all min. all max. all average. all stdev } ]. [ RandomWELL512 new in: [ :random | 1 to: 1e6 do: [ :i | random next ] ] ] timeToRun. Note that you should create one instance, seed it properly, and keep using it. </class comment> It is acceptably fast, generating 1M [0,1) Floats in about 0.1s. I compared the output with a fixed initial state to the C code that I started from and I got the same numbers. Maybe some people find this interesting. I attached a file out. Sven

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Christophe Demarey

Hi, > Le 9 nov. 2018 Ã 14:11, Mariano Martinez Peck <marianopeck(a)gmail.com> a Ã©crit : > > > > On Fri, Nov 9, 2018, 10:06 Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr> wrote: > Hi Mariano, > > Le 8 nov. 2018 Ã 20:47, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> a Ã©crit : > > > > Hi All, > > > > I am having this same problem with the #fileDescriptorType: in a PharoLauncher 1.4.6 64 bits trying to launch a Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 Bit). > > > > Any ideas? > > It is because your pharo 70 vm is too old. > You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in pharo/vm/private) and it should work. > > > > > Hi Christophe, > > Thanks for the workaround. But let me ask.. Wasn't one of the launcher purposes to automatically download the necessary correct VM for the image you are creating? To avoid this exact kind of issue? Launcher magic has its boundaries. The information available to the launcher to determine the appropriate VM to run an image is: - the image format number (encoded in the image header) - the pharo version (system version) of the image (need to run the image to know that information). In your case, you have an image with the same image format number, same pharo version (7.0) but with incompatible changes requiring a new VM. Pharo Launcher has no way to get this information. This problem only happens with moving Pharo versions : the development version. The best option would be to encode the Pharo version as a semantic version in the header of the image file but it requires a lot of changes. For now, to work around the problem, I will add a windows to easily update the VMs from the launcher UI.

Nov. 9, 2018

[Pharo 7.0-dev] Build #1374: 22650-add-Operations-as-Reifications

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1374 was: SUCCESS. The Pull Request #1961 was integrated: "22650-add-Operations-as-Reifications" Pull request url: https://github.com/pharo-project/pharo/pull/1961 Issue Url: https://pharo.fogbugz.com/f/cases/22650 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Mariano Martinez Peck

On Fri, Nov 9, 2018, 10:06 Christophe Demarey <christophe.demarey(a)inria.fr wrote: > Hi Mariano, > > Le 8 nov. 2018 Ã 20:47, Mariano Martinez Peck <marianopeck(a)gmail.com> a > Ã©crit : > > > > Hi All, > > > > I am having this same problem with the #fileDescriptorType: in a > PharoLauncher 1.4.6 64 bits trying to launch a > Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 > Bit). > > > > Any ideas? > > It is because your pharo 70 vm is too old. > You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in > pharo/vm/private) and it should work. > > > > Hi Christophe, Thanks for the workaround. But let me ask.. Wasn't one of the launcher purposes to automatically download the necessary correct VM for the image you are creating? To avoid this exact kind of issue? Thanks! > > Cheers, > Christophe. >

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Christophe Demarey

Hi Mariano, Le 8 nov. 2018 Ã 20:47, Mariano Martinez Peck <marianopeck(a)gmail.com> a Ã©crit : > > Hi All, > > I am having this same problem with the #fileDescriptorType: in a PharoLauncher 1.4.6 64 bits trying to launch a Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 Bit). > > Any ideas? It is because your pharo 70 vm is too old. You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in pharo/vm/private) and it should work. Cheers, Christophe.

Nov. 9, 2018

Re: [Pharo-dev] PharoLauncher : Image version determination error

by Mariano Martinez Peck

Hi All, I am having this same problem with the #fileDescriptorType: in a PharoLauncher 1.4.6 64 bits trying to launch a Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 Bit). Any ideas? Thanks, On Thu, Aug 23, 2018 at 12:16 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > demarey wrote > > I just published a new version of the launcher > > Thanks! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Mariano http://marianopeck.wordpress.com

Nov. 8, 2018

[Pharo 7.0-dev] Build #1373: 22639-Clean-ComposablePresenter-icon-API

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1373 was: SUCCESS. The Pull Request #1959 was integrated: "22639-Clean-ComposablePresenter-icon-API" Pull request url: https://github.com/pharo-project/pharo/pull/1959 Issue Url: https://pharo.fogbugz.com/f/cases/22639 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 8, 2018

glamorous toolkit - moldable method coder

by Tudor Girba

Hi, We design the Glamorous Toolkit to enable moldable development. This is a new take on programming that is predicated on the idea that tools must adapt to the context of the software system in order to be effective. Until now, we mainly applied moldability to how we inspect/debug/search existing code and objects. The first incarnation of GT, the tools that are present in the Pharo distribution, already showed how moldable development can provide dramatic productivity gains, especially when combined with examples. To make the experience complete, more recently we started to build moldability into Coder, the new set of tools for creating code. The first tool we created is Method Coder, an editor for a single method. This is a working editor that has multiple new features, one of which being that it can be collapsed to only see the method pattern (header), and that the body is editable without affecting the method pattern. This editor is versatile and can be used in various places, such as class coder or a search: https://twitter.com/feenkcom/status/1058003761262743552 Yesterday, we reached a new milestone. In the example below we see how adding/removing <gtExample> to a method changes the shape of the method Coder dynamically without requiring a save. In our case, the changes affect: the example status label, the in-place example expanding toggle, and the run button. https://twitter.com/feenkcom/status/1060290294749560833 This just an example that is specific to the examples engine, but it shows how typing can be linked live to all details that make the surrounding tool. Of course, the mechanism behind the scene is available for you to adapt the editor to your code. This is a whole new uncharted world, and we think there is a great deal of potential in this area. Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Nov. 8, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Esteban Lorenzano

Hi, > On 7 Nov 2018, at 22:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> It is not so easy. >> >> A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. > > This is because you want to see it like that. > Now issuing a new version of iceberg would just be integrated a branch > into Pharo. So I do not see why you could not commit to a branch and > work there > for Iceberg. Sorry but I do not buy your argument. > Why you want to have all the plugin of the VM at the same place and > not the core Pharo tool? I do want all sources in a single repository. Is just, I want it in a clean way, that will help us improve modularisation and task/team working. And in the case of VM, to be honest I would prefer to have the plugins separated, is just that is not possible as it is now because: - not all âpluginsâ are real plugins, in the sense I cannot take them out and expect the VM to work. Take âFilePluginâ as an example. This plugins are more like âmodulesâ that happens to use the same structure as real plugins. - plugins are all spread in the web. And they are split in two: Smalltalk part is in some place and platform files are all on osvm repository. *This* is annoying. A good organisation would be: - all VM sources with all required modules (mandatory plugins) together. - each real optional plugin in a separated repository along with their own makefiles, allowing the build of them without needing the full VM (but also allowing the build of the VM without needing to checkout the plugins). - and all of them organised under the same organisation (opensmalltalk) Also, having âall VM sources togetherâ does not means I want then all mixed. I would also like to have them correctly separated in something like: src vm smalltalk ... platform unix macOS windows modules filemodule smalltalk platforms unix macOS windows ... But this is a lot of work, and then we agreed in a solution that will work but is not the best. Now, I do believe we need to do steps to go there with the VM organisation and also with Pharo organisation. My proposal is to have all sources in a single repository, but organised in a way that enhance modularity and for the same price we can benefit of using subtrees (or submodules), but we do not need to do it, is your a choice. So, in my plans, I want to create this structure for Pharo sources: src kernel system graphics spec tools playground debugger calypso iceberg (this is just an example, whatever the tools are) â¦ And to achieve this, all we need is to add support to multiple directories to iceberg (which is something that is in our roadmap anyway). Cheers, Esteban > > The message is clear to me: I will not work on Pharo because I cannot. > You will show me how you do that trivially stupid bug fix without > several PR AND synchronisation point!!!!!! > Because if you do not see that the synchronisation point between a PR > in project and a PR in Pharo will kill us. > What can I say. Nothing I will shut up but do not ask my support for > anything in the future. > Sorry to be aggressive but this week I could have fixed several > totally totally stupid glitches and I could not > You will have to prove me that I'm wrong: > https://pharo.fogbugz.com/f/cases/22626/Should-not-hardcode-CmdCommandAbort… > > And at the end, you will win and I will let you play with your process. > And I will not work on Pharo. > > >> Now, imagine If iceberg would be integrated in pharo. >> >> 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. >> 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? >> Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. >> >> Situation is not ideal (even if it is a lot better as before). > > How better? We cannot fix simple crosscutting things in subparts of Pharo? > > >> But Iâm envisioning this solution: add multiple source directories capability. > > This does not resolve the synchronisation point. > And I do not see how it helps other projects like Moose with multiple > repo so we lose on two sides. > 1 Too complex for Pharo core and 2 not helping projects build out of > external projects. > > I think that we should work on more important things instead of > building our own new problems. (cleaning, better tools, Cargo, > headless, better VM, Modules?) > Merging the Pharo core projects would solved the first (1) problem above. > > But you are right let us look smart and increase the entropy for the > sake of it. > It will be without me. I started and I will not read bug entries and > PR anymore. > If doing nothing is the way to get heard then I will do nothing > because I'm hurt each time I want to do something and I have enough. > > >> Then we can have: >> >> src/kernel >> src/system >> src/spec >> src/iceberg >> src/calypso >> etc. >> >> This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. > > I do not believe you. If that would be so easy why Pablo and Guille > would tell me that this is around 8 months of work? > Seriously. > > > >> For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. >> Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). >> >> Esteban >> >> Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. >> >>> On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). >>> >>> When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. >>> >>> I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). >>> >>> For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. >>> >>> I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> I get the feeling what is needed is mirroring all dependent repos from >>>> the canonical location under http://github.com/pharo-project >>>> and a Slice-like tool (probably keeping the name "Slice") which... >>>> 1. Pulls all dependent repos to the local machine >>>> 2. Simultaneously commits to the local repos with the same commit message >>>> 3. Updates a bootstrap-configuration file holding commit-hashes of all >>>> the dependencies and commits with same commit message >>>> 4. Pushes that bootstrap-configuration file and all changed dependent >>>> repos to user's github account >>>> 5. Issues a pull request for the bootstrap-configuration file >>>> 6. Our CI then builds a test-image by commit-hash direct from each >>>> user's repo and if it passes, pulls dependent repo commits under >>>> pharo-project >>>> 7. CI can then issue PRs to the dependency canonical repos >>>> >>>> cheers -ben >>>> >>>>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Calypso is integral part of Pharo as Iceberg. >>>>> We started to discuss the problem in the team. Right now this project >>>>> spread kills us. >>>>> >>>>> Stef >>>>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: >>>>>> >>>>>> Tim Mackinnon <tim(a)testit.works> wrote: >>>>>>> >>>>>> >>>>>>> In retrospect, Iâm wondering if successful projects that have proved >>>>>>> integration usefulness should be moved into the core repo? >>>>>>> (Iceberg/Calypso?) or are we missing something to help easily track the >>>>>>> journey of a multi faceted change (although this sounds overkill?). Or >>>>>>> are there sprint days to try and knock these things through easily with >>>>>>> everyone on board to do it together? >>>>>>> >>>>>>> We are sort of damned if you do and damned if you donât. But certainly we >>>>>>> want to endure that progress can be made without losing the will to contribute. >>>>>>> >>>>>> >>>>>> Indeed. Putting things in one repo cannot scale and cannot be a solution >>>>>> for something that is neither core pharo nor an application. I encourage >>>>>> everyone who wants to get a good description of this problem to read >>>>>> >>>>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration >>>>>> Management, and Product Data Management" by Peter van den Hamer & Kees >>>>>> Lepoeter. >>>>>> >>>>>> With git and github a solution to decouple fast-moving from slow-moving >>>>>> projects seems to be indeed to fork and make PRs. >>>>>> That only works if the quality of the PRs is high enough and we manage to >>>>>> use the feedback from slower-moving projects well. >>>>>> >>>>>> Earlier, weâve seen projects like Magma being overwhelmed by the number of >>>>>> needed changes, and Pier being broken by Pillar not respecting its >>>>>> constraints. >>>>>> >>>>>> With tools like Travis, it is quickly clear if a PR would result in a green >>>>>> build in the original repo. >>>>>> >>>>>> With projects where Pharo uses only the core, and applications use more >>>>>> than that, the applications still have a dependency problem: if the core >>>>>> changes in Pharo influence the other parts, someone needs to do the work to >>>>>> make those parts work again. With forked repos, that can be a pharo >>>>>> maintainer, the project maintainer or the application maintainer. All three >>>>>> need to be able to make those changes. And they need to be decoupled from >>>>>> having to make them immediately. And being able to have the discussion >>>>>> about the exact implementation independently from implementing a stop-gap >>>>>> solution now is also valuable. >>>>>> >>>>>> So if Calypso is supposed to be extendable and only the core part is part >>>>>> of Pharo, having it as an external project makes sense. With a fork for >>>>>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having >>>>>> different branches for different Pharo versions, it sounds to me like it >>>>>> might be better of in the Pharo project. Tonel is supposed to be >>>>>> cross-platform so should be separate. >>>>>> >>>>>> Is this helpful? >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> >

Nov. 8, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Esteban Maringolo

Isn't working with "core projects" in the Pharo repository an actual fork of each project? One thing is "Kernel" (which is seldom committed outside of the context of the Pharo repo) and another one is Calypso/Iceberg/Zinc, etc. What's the practical difference (in terms of code) between such a fork and depending on a particular commit/tag of the referenced project? ps: These are honest, maybe naive, questions, so please answer accordingly. Esteban A. Maringolo

Nov. 7, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Stephane Ducasse

> It is not so easy. > > A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. This is because you want to see it like that. Now issuing a new version of iceberg would just be integrated a branch into Pharo. So I do not see why you could not commit to a branch and work there for Iceberg. Sorry but I do not buy your argument. Why you want to have all the plugin of the VM at the same place and not the core Pharo tool? The message is clear to me: I will not work on Pharo because I cannot. You will show me how you do that trivially stupid bug fix without several PR AND synchronisation point!!!!!! Because if you do not see that the synchronisation point between a PR in project and a PR in Pharo will kill us. What can I say. Nothing I will shut up but do not ask my support for anything in the future. Sorry to be aggressive but this week I could have fixed several totally totally stupid glitches and I could not You will have to prove me that I'm wrong: https://pharo.fogbugz.com/f/cases/22626/Should-not-hardcode-CmdCommandAbort… And at the end, you will win and I will let you play with your process. And I will not work on Pharo. > Now, imagine If iceberg would be integrated in pharo. > > 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. > 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? > Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. > > Situation is not ideal (even if it is a lot better as before). How better? We cannot fix simple crosscutting things in subparts of Pharo? > But Iâm envisioning this solution: add multiple source directories capability. This does not resolve the synchronisation point. And I do not see how it helps other projects like Moose with multiple repo so we lose on two sides. 1 Too complex for Pharo core and 2 not helping projects build out of external projects. I think that we should work on more important things instead of building our own new problems. (cleaning, better tools, Cargo, headless, better VM, Modules?) Merging the Pharo core projects would solved the first (1) problem above. But you are right let us look smart and increase the entropy for the sake of it. It will be without me. I started and I will not read bug entries and PR anymore. If doing nothing is the way to get heard then I will do nothing because I'm hurt each time I want to do something and I have enough. > Then we can have: > > src/kernel > src/system > src/spec > src/iceberg > src/calypso > etc. > > This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. I do not believe you. If that would be so easy why Pablo and Guille would tell me that this is around 8 months of work? Seriously. > For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. > Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). > > Esteban > > Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. > > > On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: > > > > Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). > > > > When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. > > > > I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). > > > > For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. > > > > I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. > > > > Tim > > > > Sent from my iPhone > > > >> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> I get the feeling what is needed is mirroring all dependent repos from > >> the canonical location under http://github.com/pharo-project > >> and a Slice-like tool (probably keeping the name "Slice") which... > >> 1. Pulls all dependent repos to the local machine > >> 2. Simultaneously commits to the local repos with the same commit message > >> 3. Updates a bootstrap-configuration file holding commit-hashes of all > >> the dependencies and commits with same commit message > >> 4. Pushes that bootstrap-configuration file and all changed dependent > >> repos to user's github account > >> 5. Issues a pull request for the bootstrap-configuration file > >> 6. Our CI then builds a test-image by commit-hash direct from each > >> user's repo and if it passes, pulls dependent repo commits under > >> pharo-project > >> 7. CI can then issue PRs to the dependency canonical repos > >> > >> cheers -ben > >> > >>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>> > >>> Calypso is integral part of Pharo as Iceberg. > >>> We started to discuss the problem in the team. Right now this project > >>> spread kills us. > >>> > >>> Stef > >>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > >>>> > >>>> Tim Mackinnon <tim(a)testit.works> wrote: > >>>>> > >>>> > >>>>> In retrospect, Iâm wondering if successful projects that have proved > >>>>> integration usefulness should be moved into the core repo? > >>>>> (Iceberg/Calypso?) or are we missing something to help easily track the > >>>>> journey of a multi faceted change (although this sounds overkill?). Or > >>>>> are there sprint days to try and knock these things through easily with > >>>>> everyone on board to do it together? > >>>>> > >>>>> We are sort of damned if you do and damned if you donât. But certainly we > >>>>> want to endure that progress can be made without losing the will to contribute. > >>>>> > >>>> > >>>> Indeed. Putting things in one repo cannot scale and cannot be a solution > >>>> for something that is neither core pharo nor an application. I encourage > >>>> everyone who wants to get a good description of this problem to read > >>>> > >>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration > >>>> Management, and Product Data Management" by Peter van den Hamer & Kees > >>>> Lepoeter. > >>>> > >>>> With git and github a solution to decouple fast-moving from slow-moving > >>>> projects seems to be indeed to fork and make PRs. > >>>> That only works if the quality of the PRs is high enough and we manage to > >>>> use the feedback from slower-moving projects well. > >>>> > >>>> Earlier, weâve seen projects like Magma being overwhelmed by the number of > >>>> needed changes, and Pier being broken by Pillar not respecting its > >>>> constraints. > >>>> > >>>> With tools like Travis, it is quickly clear if a PR would result in a green > >>>> build in the original repo. > >>>> > >>>> With projects where Pharo uses only the core, and applications use more > >>>> than that, the applications still have a dependency problem: if the core > >>>> changes in Pharo influence the other parts, someone needs to do the work to > >>>> make those parts work again. With forked repos, that can be a pharo > >>>> maintainer, the project maintainer or the application maintainer. All three > >>>> need to be able to make those changes. And they need to be decoupled from > >>>> having to make them immediately. And being able to have the discussion > >>>> about the exact implementation independently from implementing a stop-gap > >>>> solution now is also valuable. > >>>> > >>>> So if Calypso is supposed to be extendable and only the core part is part > >>>> of Pharo, having it as an external project makes sense. With a fork for > >>>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having > >>>> different branches for different Pharo versions, it sounds to me like it > >>>> might be better of in the Pharo project. Tonel is supposed to be > >>>> cross-platform so should be separate. > >>>> > >>>> Is this helpful? > >>>> > >>>> Stephan > >>>> > >>>> > >>>> > >>> > >> > > > > > >

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Alistair Grant

Hi Marcus, On Wed, 7 Nov 2018 at 14:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On 7 Nov 2018, at 13:56, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > ... > > > Good point. How to get a list of all the methods that have MetaLinks? > > The following seems to work, but probably isn't the most efficient: > > > > Object allSubclasses flatCollect: [ :each | each methods select: [ > > :method | method ast links isNotNil ] ] > > > > you can ask the method directly > > Object allSubclasses flatCollect: [ :each | each methods select: [ > :method | method hasLinks ] ] > > this is much faster as it returns immediately nil for methods without links (without AST reification). Thanks! Cheers, Alistair

Nov. 7, 2018

[Pharo 7.0-dev] Build #1372: 22638-usage-of-readlink-f-breaks-macOS-bootstrap

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1372 was: SUCCESS. The Pull Request #1958 was integrated: "22638-usage-of-readlink-f-breaks-macOS-bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/1958 Issue Url: https://pharo.fogbugz.com/f/cases/22638 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Eliot Miranda

On Wed, Nov 7, 2018 at 6:28 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: [snip] > Forgive me, but may I beg you to post the text of stack back traces in > future not screenshots? The screenshots have two major disadvantages; a) > they're huge and b) one cannot search email messages for the text they > contain. You can use e.g. shell level tools to copy the text, eg from the > terminal or from the console. > i.e.: Your mail to 'Pharo-dev' with the subject Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 1522650 bytes with a limit of 1000 KB [snip] _,,,^..^,,,_ best, Eliot

Nov. 7, 2018

[Pharo 7.0-dev] Build #1371: 22641-Semantic-analysis-needs-to-take-instead-preambles-into-account

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1371 was: SUCCESS. The Pull Request #1960 was integrated: "22641-Semantic-analysis-needs-to-take-instead-preambles-into-account" Pull request url: https://github.com/pharo-project/pharo/pull/1960 Issue Url: https://pharo.fogbugz.com/f/cases/22641 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2018

Re: [Pharo-dev] [ANN] Iceberg v1.4.0

by Ben Coman

On Wed, 7 Nov 2018 at 17:09, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hello! > > This week we are releasing the version v1.4.0 of Iceberg. > (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0) > > This version is available in the latest Pharo 7. > > This release fixes a bug introduced in v1.3. It also add new features > in the repository view, add some cleaning and also re-introduce a > feature that was lost. > > Thanks to all contributors. > > Enjoy! > > Full changelog: > > Bugfixes > > #1068 'There is no associated repository configured.' warning on right > clicking missing repository > > Features > > #1077 Repository view: Allow to collapse branches/remotes/tags trees > #847 Move tags under remotes in Repository view Ohh, those two are very nice. I'm meant to be working on something else but needed to try those out. That long list of tags had been mildly annoying me for a while, but not enough for me to get around to complaining about it. Glad its fixed already. > #1070 set upstream if missing > > Cleanups > > #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest" > #1015 Replace usages of Glamour in the Github Plugin > #1063 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons Cool. I like the way the changes are reported and the semantic versioning. cheers -ben

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Eliot Miranda

Hi Alex, I think Marcus is right. The run:with:in: mechanism is invoked when the VM looks up a message and finds something other than a CompiledMethod in the relevant method dictionary as the value of the selector. Occasionally this can happen from stack corruption, otherwise it implies method dictionary corruption. Either could be caused by an FFI bug, a VM bug, etc. Do you have the image still live? We could meet on Slack and i could perhaps use lldb to look at the stack. If not, the approach would be to find a reproducible case (painful, given that you're trying to get work done and save it) and then run the reproducible case with assertions and heap leak checking turned on to try and catch the error as early as possible. Forgive me, but may I beg you to post the text of stack back traces in future not screenshots? The screenshots have two major disadvantages; a) they're huge and b) one cannot search email messages for the text they contain. You can use e.g. shell level tools to copy the text, eg from the terminal or from the console. On Wed, Nov 7, 2018 at 1:16 AM Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hello, > > When saving one of the latest pharo70 image I got an infinite recursion > loop due to message not understood. Force closing it probably lead to image > corruption and it became un-openable anymore. Any idea what is going on? It > does not look like a unique case because there are a few pharo70 images > that already died in front of me... > > [image: Screen Shot 2018-11-07 at 09.55.07.png] > > VM: Mac OS - x64 - 1013.5 - CoInterpreter VMMaker.oscog-eem.2461 uuid: >> b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 31 2018 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: >> 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 31 2018 >> VM: 201810311808 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> Date: Wed Oct 31 11:08:29 2018 CommitHash: c7a9b1f Plugins: 201810311808 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> Image: Pharo7.0.0alpha [Build information: >> Pharo-7.0.0+alpha.build.1361.sha.011b7c939adeb52338baad16a694cab2e7a54d74 >> (64 Bit)] > > > Cheers, > Alex > -- _,,,^..^,,,_ best, Eliot

Nov. 7, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Esteban Lorenzano

> On 7 Nov 2018, at 14:19, Ben Coman <btc(a)openinworld.com> wrote: > > On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> It is not so easy. >> >> A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. >> >> Now, imagine If iceberg would be integrated in pharo. >> >> 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. >> 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? >> Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. >> >> Situation is not ideal (even if it is a lot better as before). >> But Iâm envisioning this solution: add multiple source directories capability. >> >> Then we can have: >> >> src/kernel >> src/system >> src/spec >> src/iceberg >> src/calypso >> etc. >> >> This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. >> For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. >> Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). > > Why not a submodule approach? Donât know, donât care for the moment :) We need to add multiple subdirectories capability. Then we will be able to chose whatever we want: submodules, subtrees, nothing at all. > I do vaguely remember you having some > pain with it integrating the opensmalltalk-vm repo under the pharo-vm > repo before Pharo started more directly using the opensmallk-vm CI > products. That was my own stupidity, not subtree problems ;) > I thought I might have something useful to contribute to discussion by > finding the good article [1] I remembered > that compared subtree and submodule, the summary of which is... > > * Is the external repository something you own yourself and are > likely to push code back to? > Then use a submodule. This gives you the quickest and easiest way > for you to push your changes back. > > * Is the external repository third party code that you are unlikely > to push anything back to? > Then use a subtree. This gives the advantage of not having to > give people permissions to an extra repo when you are giving them > access to the code base, and also reduces the chance that someone will > forget to run a git submodule update. [But this could be automated in > Pharo] > > > But then I came across [2] which says... > * Submodules [...] work well when you want to include a > third-party library in your project that only occasionally needs to be > updated. > > so I don't know. > [1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/ <https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/> > [2] http://www.mos6581.org/git_subtree_alternative <http://www.mos6581.org/git_subtree_alternative> > > > I think main issues to consider between the two options are: > A. the effect on history between Pharo repo and dependent repos, > of commits to either repo > B. how branching is handled between Pharo repo and dependent repos > and I don't know really have my head around that, so for now I'll shut it. :) > > > anyway, my understanding was that subtree was implemented in shell > scripts and not libgit so does that make it more difficult? > https://stackoverflow.com/a/25474895 <https://stackoverflow.com/a/25474895> Everything in git is implemented as shell scripts (thatâs why libgit2 exists, in fact). In any case, we will not handle the subtree (or submodule) pushing/pulling from iceberg. Doing a proper tooling on subtree will be complicated and time-effort consuming and sadly we do not have time to prioritise that now, then it will be an external task, at least for the moment. Esteban > > cheers -ben > > >> >> Esteban >> >> Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. >> >>> On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). >>> >>> When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. >>> >>> I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). >>> >>> For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. >>> >>> I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> I get the feeling what is needed is mirroring all dependent repos from >>>> the canonical location under http://github.com/pharo-project >>>> and a Slice-like tool (probably keeping the name "Slice") which... >>>> 1. Pulls all dependent repos to the local machine >>>> 2. Simultaneously commits to the local repos with the same commit message >>>> 3. Updates a bootstrap-configuration file holding commit-hashes of all >>>> the dependencies and commits with same commit message >>>> 4. Pushes that bootstrap-configuration file and all changed dependent >>>> repos to user's github account >>>> 5. Issues a pull request for the bootstrap-configuration file >>>> 6. Our CI then builds a test-image by commit-hash direct from each >>>> user's repo and if it passes, pulls dependent repo commits under >>>> pharo-project >>>> 7. CI can then issue PRs to the dependency canonical repos >>>> >>>> cheers -ben >>>> >>>>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Calypso is integral part of Pharo as Iceberg. >>>>> We started to discuss the problem in the team. Right now this project >>>>> spread kills us. >>>>> >>>>> Stef >>>>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: >>>>>> >>>>>> Tim Mackinnon <tim(a)testit.works> wrote: >>>>>>> >>>>>> >>>>>>> In retrospect, Iâm wondering if successful projects that have proved >>>>>>> integration usefulness should be moved into the core repo? >>>>>>> (Iceberg/Calypso?) or are we missing something to help easily track the >>>>>>> journey of a multi faceted change (although this sounds overkill?). Or >>>>>>> are there sprint days to try and knock these things through easily with >>>>>>> everyone on board to do it together? >>>>>>> >>>>>>> We are sort of damned if you do and damned if you donât. But certainly we >>>>>>> want to endure that progress can be made without losing the will to contribute. >>>>>>> >>>>>> >>>>>> Indeed. Putting things in one repo cannot scale and cannot be a solution >>>>>> for something that is neither core pharo nor an application. I encourage >>>>>> everyone who wants to get a good description of this problem to read >>>>>> >>>>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration >>>>>> Management, and Product Data Management" by Peter van den Hamer & Kees >>>>>> Lepoeter. >>>>>> >>>>>> With git and github a solution to decouple fast-moving from slow-moving >>>>>> projects seems to be indeed to fork and make PRs. >>>>>> That only works if the quality of the PRs is high enough and we manage to >>>>>> use the feedback from slower-moving projects well. >>>>>> >>>>>> Earlier, weâve seen projects like Magma being overwhelmed by the number of >>>>>> needed changes, and Pier being broken by Pillar not respecting its >>>>>> constraints. >>>>>> >>>>>> With tools like Travis, it is quickly clear if a PR would result in a green >>>>>> build in the original repo. >>>>>> >>>>>> With projects where Pharo uses only the core, and applications use more >>>>>> than that, the applications still have a dependency problem: if the core >>>>>> changes in Pharo influence the other parts, someone needs to do the work to >>>>>> make those parts work again. With forked repos, that can be a pharo >>>>>> maintainer, the project maintainer or the application maintainer. All three >>>>>> need to be able to make those changes. And they need to be decoupled from >>>>>> having to make them immediately. And being able to have the discussion >>>>>> about the exact implementation independently from implementing a stop-gap >>>>>> solution now is also valuable. >>>>>> >>>>>> So if Calypso is supposed to be extendable and only the core part is part >>>>>> of Pharo, having it as an external project makes sense. With a fork for >>>>>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having >>>>>> different branches for different Pharo versions, it sounds to me like it >>>>>> might be better of in the Pharo project. Tonel is supposed to be >>>>>> cross-platform so should be separate. >>>>>> >>>>>> Is this helpful? >>>>>> >>>>>> Stephan

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Marcus Denker

> On 7 Nov 2018, at 13:56, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Wed, 7 Nov 2018 at 10:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 7 Nov 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Alex, >>> >>> >>> On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>>> >>>> Hello, >>>> >>>> When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... >>> >>> This looks like your image changes the definition of >>> Number>>raisedToInteger: somewhere along the line. In the standard >>> image it doesn't call #run:with:in:. >> >> I don't think that definition got overwritten, check the implementers of #run:with:in: is seems to have to do with meta links or proxies or something like that ... > Or it could be a bug where the VM ends up getting a SmallInteger instead of a CompiledMethod as the result of a method lookup. That would be bad... > Good point. How to get a list of all the methods that have MetaLinks? > The following seems to work, but probably isn't the most efficient: > > Object allSubclasses flatCollect: [ :each | each methods select: [ > :method | method ast links isNotNil ] ] > you can ask the method directly Object allSubclasses flatCollect: [ :each | each methods select: [ :method | method hasLinks ] ] this is much faster as it returns immediately nil for methods without links (without AST reification). Marcus

Nov. 7, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Ben Coman

On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > It is not so easy. > > A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. > > Now, imagine If iceberg would be integrated in pharo. > > 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. > 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? > Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. > > Situation is not ideal (even if it is a lot better as before). > But Iâm envisioning this solution: add multiple source directories capability. > > Then we can have: > > src/kernel > src/system > src/spec > src/iceberg > src/calypso > etc. > > This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. > For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. > Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). Why not a submodule approach? I do vaguely remember you having some pain with it integrating the opensmalltalk-vm repo under the pharo-vm repo before Pharo started more directly using the opensmallk-vm CI products. I thought I might have something useful to contribute to discussion by finding the good article [1] I remembered that compared subtree and submodule, the summary of which is... * Is the external repository something you own yourself and are likely to push code back to? Then use a submodule. This gives you the quickest and easiest way for you to push your changes back. * Is the external repository third party code that you are unlikely to push anything back to? Then use a subtree. This gives the advantage of not having to give people permissions to an extra repo when you are giving them access to the code base, and also reduces the chance that someone will forget to run a git submodule update. [But this could be automated in Pharo] But then I came across [2] which says... * Submodules [...] work well when you want to include a third-party library in your project that only occasionally needs to be updated. so I don't know. [1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/ [2] http://www.mos6581.org/git_subtree_alternative I think main issues to consider between the two options are: A. the effect on history between Pharo repo and dependent repos, of commits to either repo B. how branching is handled between Pharo repo and dependent repos and I don't know really have my head around that, so for now I'll shut it. :) anyway, my understanding was that subtree was implemented in shell scripts and not libgit so does that make it more difficult? https://stackoverflow.com/a/25474895 cheers -ben > > Esteban > > Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. > > > On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: > > > > Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). > > > > When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. > > > > I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). > > > > For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. > > > > I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. > > > > Tim > > > > Sent from my iPhone > > > >> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> I get the feeling what is needed is mirroring all dependent repos from > >> the canonical location under http://github.com/pharo-project > >> and a Slice-like tool (probably keeping the name "Slice") which... > >> 1. Pulls all dependent repos to the local machine > >> 2. Simultaneously commits to the local repos with the same commit message > >> 3. Updates a bootstrap-configuration file holding commit-hashes of all > >> the dependencies and commits with same commit message > >> 4. Pushes that bootstrap-configuration file and all changed dependent > >> repos to user's github account > >> 5. Issues a pull request for the bootstrap-configuration file > >> 6. Our CI then builds a test-image by commit-hash direct from each > >> user's repo and if it passes, pulls dependent repo commits under > >> pharo-project > >> 7. CI can then issue PRs to the dependency canonical repos > >> > >> cheers -ben > >> > >>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>> > >>> Calypso is integral part of Pharo as Iceberg. > >>> We started to discuss the problem in the team. Right now this project > >>> spread kills us. > >>> > >>> Stef > >>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > >>>> > >>>> Tim Mackinnon <tim(a)testit.works> wrote: > >>>>> > >>>> > >>>>> In retrospect, Iâm wondering if successful projects that have proved > >>>>> integration usefulness should be moved into the core repo? > >>>>> (Iceberg/Calypso?) or are we missing something to help easily track the > >>>>> journey of a multi faceted change (although this sounds overkill?). Or > >>>>> are there sprint days to try and knock these things through easily with > >>>>> everyone on board to do it together? > >>>>> > >>>>> We are sort of damned if you do and damned if you donât. But certainly we > >>>>> want to endure that progress can be made without losing the will to contribute. > >>>>> > >>>> > >>>> Indeed. Putting things in one repo cannot scale and cannot be a solution > >>>> for something that is neither core pharo nor an application. I encourage > >>>> everyone who wants to get a good description of this problem to read > >>>> > >>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration > >>>> Management, and Product Data Management" by Peter van den Hamer & Kees > >>>> Lepoeter. > >>>> > >>>> With git and github a solution to decouple fast-moving from slow-moving > >>>> projects seems to be indeed to fork and make PRs. > >>>> That only works if the quality of the PRs is high enough and we manage to > >>>> use the feedback from slower-moving projects well. > >>>> > >>>> Earlier, weâve seen projects like Magma being overwhelmed by the number of > >>>> needed changes, and Pier being broken by Pillar not respecting its > >>>> constraints. > >>>> > >>>> With tools like Travis, it is quickly clear if a PR would result in a green > >>>> build in the original repo. > >>>> > >>>> With projects where Pharo uses only the core, and applications use more > >>>> than that, the applications still have a dependency problem: if the core > >>>> changes in Pharo influence the other parts, someone needs to do the work to > >>>> make those parts work again. With forked repos, that can be a pharo > >>>> maintainer, the project maintainer or the application maintainer. All three > >>>> need to be able to make those changes. And they need to be decoupled from > >>>> having to make them immediately. And being able to have the discussion > >>>> about the exact implementation independently from implementing a stop-gap > >>>> solution now is also valuable. > >>>> > >>>> So if Calypso is supposed to be extendable and only the core part is part > >>>> of Pharo, having it as an external project makes sense. With a fork for > >>>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having > >>>> different branches for different Pharo versions, it sounds to me like it > >>>> might be better of in the Pharo project. Tonel is supposed to be > >>>> cross-platform so should be separate. > >>>> > >>>> Is this helpful? > >>>> > >>>> Stephan > >>>> > >>>> > >>>> > >>> > >> > > > > > >

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Alistair Grant

Hi Sven, On Wed, 7 Nov 2018 at 10:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 7 Nov 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Alex, > > > > > > On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> > >> Hello, > >> > >> When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... > > > > This looks like your image changes the definition of > > Number>>raisedToInteger: somewhere along the line. In the standard > > image it doesn't call #run:with:in:. > > I don't think that definition got overwritten, check the implementers of #run:with:in: is seems to have to do with meta links or proxies or something like that ... Good point. How to get a list of all the methods that have MetaLinks? The following seems to work, but probably isn't the most efficient: Object allSubclasses flatCollect: [ :each | each methods select: [ :method | method ast links isNotNil ] ] Cheers, Alistair

Nov. 7, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Stephan Eggermont

Chris Muller <asqueaker(a)gmail.com> wrote: >> Earlier, weâve seen projects like Magma being overwhelmed by the number of >> needed changes, > > I'm curious what you meant by this. I'm not aware of Magma ever > having been overwhelmed. Its design has made it easy to be one of the > most-available and consumable pieces of software for every version of > Squeak from 2007 to today. Did you mean the Pharo port? It doesn't > really do any magic, I'd be surprised if it would be very difficult to > port to Pharo, but I don't know. Several people have been working on a Magma version for Pharo. At the time (Pharo 1.0-1.2) the Pharo CI infrastructure was not giving enough feedback to keep the port running. Once a year or so someone comes along who tries fixing the port, and that appears to be too difficult or time consuming for them. It needs pretty deep knowledge about internals. I agree that it would probably not be very difficult for a long time pharo/squeak developer. Finding out what exactly changed and why in the past 8 years is not so easy for someone new. Without someone using it in production on Pharo, there is not enough incentive to keep up with what changes in Pharo. Thereâs a chicken and egg problem there Stephan

Nov. 7, 2018

[Pharo 7.0-dev] Build #1370: 22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1370 was: FAILURE. The Pull Request #1953 was integrated: "22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme" Pull request url: https://github.com/pharo-project/pharo/pull/1953 Issue Url: https://pharo.fogbugz.com/f/cases/22629 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2018

Slow writing to Transcript (stderr) in Windows 10 PharoConsole.exe -headless

by Christopher Fuhrman

Hello, I encountered a performance bug in Pharo 6 under Windows 10 with Moose, starting from the Moose 6.1 (beta) image in Pharo Launcher. I migrated my code from Pharo 5 and it uses a PharoCommandLineHandler to load an MSE file, which sometimes has many (15K) warnings/errors. It was taking over a minute to run something that in Moose takes only a few seconds. To debug and make a minimal example, I removed the Moose file part of my CommandLineHandler and simulated the writing of errors (i/o) with a loop. I believe the I/O to the stderr is why the performance is bad. In Windows 10 Task Manager, I can see that the process is not using much CPU. As I recall, my code didn't have this performance problem in Pharo 5. The command in windows to execute my minimal sample is something like: C:\Users\me>Documents\Pharo\vms\61-x86\PharoConsole.exe -headless "C:\Users\me\Documents\Pharo\images\Moose Suite 6.1 (beta)\CommandHandler VM slow bug.image" mooseminer --msefile blah The last part (--msefile blah) is needed because I didn't want to remove the argument validation. Here's a copy of the image: https://www.dropbox.com/s/7cgt37lef2xh2ut/CommandHandler%20VM%20slow%20bug.… A workaround is to run without -headless (or to not have so many errors). I hope this is useful to someone. For RMOD people I'm happy to demo this on my machine. Cheers, -- Christopher Fuhrman, P.Eng, PhD *Professor in the DÃ©partement of Software and IT EngineeringÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Sven Van Caekenberghe

> On 7 Nov 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Alex, > > > On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hello, >> >> When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... > > This looks like your image changes the definition of > Number>>raisedToInteger: somewhere along the line. In the standard > image it doesn't call #run:with:in:. I don't think that definition got overwritten, check the implementers of #run:with:in: is seems to have to do with meta links or proxies or something like that ... > HTH, > Alistair >

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Alistair Grant

Hi Alex, On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello, > > When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... This looks like your image changes the definition of Number>>raisedToInteger: somewhere along the line. In the standard image it doesn't call #run:with:in:. HTH, Alistair

Nov. 7, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Esteban Lorenzano

It is not so easy. A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. Now, imagine If iceberg would be integrated in pharo. 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. Situation is not ideal (even if it is a lot better as before). But Iâm envisioning this solution: add multiple source directories capability. Then we can have: src/kernel src/system src/spec src/iceberg src/calypso etc. This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). Esteban Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. > On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: > > Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). > > When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. > > I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). > > For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. > > I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. > > Tim > > Sent from my iPhone > >> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: >> >> I get the feeling what is needed is mirroring all dependent repos from >> the canonical location under http://github.com/pharo-project >> and a Slice-like tool (probably keeping the name "Slice") which... >> 1. Pulls all dependent repos to the local machine >> 2. Simultaneously commits to the local repos with the same commit message >> 3. Updates a bootstrap-configuration file holding commit-hashes of all >> the dependencies and commits with same commit message >> 4. Pushes that bootstrap-configuration file and all changed dependent >> repos to user's github account >> 5. Issues a pull request for the bootstrap-configuration file >> 6. Our CI then builds a test-image by commit-hash direct from each >> user's repo and if it passes, pulls dependent repo commits under >> pharo-project >> 7. CI can then issue PRs to the dependency canonical repos >> >> cheers -ben >> >>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Calypso is integral part of Pharo as Iceberg. >>> We started to discuss the problem in the team. Right now this project >>> spread kills us. >>> >>> Stef >>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> Tim Mackinnon <tim(a)testit.works> wrote: >>>>> >>>> >>>>> In retrospect, Iâm wondering if successful projects that have proved >>>>> integration usefulness should be moved into the core repo? >>>>> (Iceberg/Calypso?) or are we missing something to help easily track the >>>>> journey of a multi faceted change (although this sounds overkill?). Or >>>>> are there sprint days to try and knock these things through easily with >>>>> everyone on board to do it together? >>>>> >>>>> We are sort of damned if you do and damned if you donât. But certainly we >>>>> want to endure that progress can be made without losing the will to contribute. >>>>> >>>> >>>> Indeed. Putting things in one repo cannot scale and cannot be a solution >>>> for something that is neither core pharo nor an application. I encourage >>>> everyone who wants to get a good description of this problem to read >>>> >>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration >>>> Management, and Product Data Management" by Peter van den Hamer & Kees >>>> Lepoeter. >>>> >>>> With git and github a solution to decouple fast-moving from slow-moving >>>> projects seems to be indeed to fork and make PRs. >>>> That only works if the quality of the PRs is high enough and we manage to >>>> use the feedback from slower-moving projects well. >>>> >>>> Earlier, weâve seen projects like Magma being overwhelmed by the number of >>>> needed changes, and Pier being broken by Pillar not respecting its >>>> constraints. >>>> >>>> With tools like Travis, it is quickly clear if a PR would result in a green >>>> build in the original repo. >>>> >>>> With projects where Pharo uses only the core, and applications use more >>>> than that, the applications still have a dependency problem: if the core >>>> changes in Pharo influence the other parts, someone needs to do the work to >>>> make those parts work again. With forked repos, that can be a pharo >>>> maintainer, the project maintainer or the application maintainer. All three >>>> need to be able to make those changes. And they need to be decoupled from >>>> having to make them immediately. And being able to have the discussion >>>> about the exact implementation independently from implementing a stop-gap >>>> solution now is also valuable. >>>> >>>> So if Calypso is supposed to be extendable and only the core part is part >>>> of Pharo, having it as an external project makes sense. With a fork for >>>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having >>>> different branches for different Pharo versions, it sounds to me like it >>>> might be better of in the Pharo project. Tonel is supposed to be >>>> cross-platform so should be separate. >>>> >>>> Is this helpful? >>>> >>>> Stephan >>>> >>>> >>>> >>> >> > >

Nov. 7, 2018

[ANN] Iceberg v1.4.0

by Cyril Ferlicot

Hello! This week we are releasing the version v1.4.0 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0) This version is available in the latest Pharo 7. This release fixes a bug introduced in v1.3. It also add new features in the repository view, add some cleaning and also re-introduce a feature that was lost. Thanks to all contributors. Enjoy! Full changelog: Bugfixes #1068 'There is no associated repository configured.' warning on right clicking missing repository Features #1077 Repository view: Allow to collapse branches/remotes/tags trees #847 Move tags under remotes in Repository view #1070 set upstream if missing Cleanups #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest" #1015 Replace usages of Glamour in the Github Plugin #1063 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons -- Cyril Ferlicot https://ferlicot.fr

Nov. 7, 2018