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

Re: [Pharo-dev] InterruptedContext vs suspendedContext

by Andrei Chis

Hi, >From what I remember they are not always redundant, but I'm not 100% sure they are both needed. `suspendedContext` from Process is always the top context of a process. After execution actions like Step Into, Step Over, Step Through it will be the same as interruptedContext in the debugger. They will be different when opening the debugger as a result of an exception. Exception>>#debug triggers the workflow for opening a debugger. This uses `self signalerContext` as the context that is being debugged. This is the context where the exception was raised and this will be put in the interruptedContext. As this point the execution of the current process is not over and it will continue up to `MorphicUIManager>>#debugProcess:context:label:fullView:notification: ` where the current process is suspended. At that point the two will be different, as suspendedContext will be the context of the method MorphicUIManager>>#debugProcess:context:label:fullView:notification: and the interruptedContext the context that triggered the exception. But it might be that they are not both needed. One possible option might be to force the process to step to the context that raised the exception when the debugger is created. For example in DebugSession>>process:context:. Apart from when opening the debugger I do not know if there is another situation where those two can diverge. Cheers, Andrei On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez < tdupriez(a)ens-paris-saclay.fr> wrote: > Hello, > > > Instances of DebugSession have an "interruptedContext" and an > "interruptedProcess" instance variable. > > Instances of Process have a "suspendedContext" instance variable. > > Does someone know if there is a relation between the interruptedContext of > a DebugSession and the suspendedContext of its interruptedProcess? At first > glance it seems like these two variables are redundant and store the same > Context. > > Thomas Dupriez >

Nov. 30, 2018

[Pharo 7.0-dev] Build #1429: 22679-Metacello-attributes-should-be-based-on-SystemVersion-instead-of-hardcoding

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

There is a new Pharo build available! The status of the build #1429 was: FAILURE. The Pull Request #1999 was integrated: "22679-Metacello-attributes-should-be-based-on-SystemVersion-instead-of-hardcoding" Pull request url: https://github.com/pharo-project/pharo/pull/1999 Issue Url: https://pharo.fogbugz.com/f/cases/22679 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 30, 2018

[Pharo 7.0-dev] Build #1428: 22679-Metacello-attributes-should-be-based-on-SystemVersion-instead-of-hardcoding

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

There is a new Pharo build available! The status of the build #1428 was: FAILURE. The Pull Request #1999 was integrated: "22679-Metacello-attributes-should-be-based-on-SystemVersion-instead-of-hardcoding" Pull request url: https://github.com/pharo-project/pharo/pull/1999 Issue Url: https://pharo.fogbugz.com/f/cases/22679 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 30, 2018

[Pharo 7.0-dev] Build #1427: 19927-scanFor-should-not-elide-extended-byte-codes

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

There is a new Pharo build available! The status of the build #1427 was: SUCCESS. The Pull Request #1872 was integrated: "19927-scanFor-should-not-elide-extended-byte-codes" Pull request url: https://github.com/pharo-project/pharo/pull/1872 Issue Url: https://pharo.fogbugz.com/f/cases/19927 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 30, 2018

[Pharo 7.0-dev] Build #1426: Fix the layout of Glamour tabulator rows and columns in the presence â¦

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

There is a new Pharo build available! The status of the build #1426 was: SUCCESS. The Pull Request #2004 was integrated: "Fix the layout of Glamour tabulator rows and columns in the presence â¦" Pull request url: https://github.com/pharo-project/pharo/pull/2004 Issue Url: https://pharo.fogbugz.com/f/cases/fixLayout Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 30, 2018

InterruptedContext vs suspendedContext

by Thomas Dupriez

Hello, Instances of DebugSession have an "interruptedContext" and an "interruptedProcess" instance variable. Instances of Process have a "suspendedContext" instance variable. Does someone know if there is a relation between the interruptedContext of a DebugSession and the suspendedContext of its interruptedProcess? At first glance it seems like these two variables are redundant and store the same Context. Thomas Dupriez

Nov. 30, 2018

[Pharo 7.0-dev] Build #1425: 22712-speed-up-mustBeBooleanDeOptimizeIn-by-a-factor-of-200-by-caching

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

There is a new Pharo build available! The status of the build #1425 was: SUCCESS. The Pull Request #2026 was integrated: "22712-speed-up-mustBeBooleanDeOptimizeIn-by-a-factor-of-200-by-caching" Pull request url: https://github.com/pharo-project/pharo/pull/2026 Issue Url: https://pharo.fogbugz.com/f/cases/22712 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 30, 2018

Re: [Pharo-dev] [Pharo-users] [Ann] TaskIt v1.0

by Santiago Bragagnolo

Hey those are good news :). Tell me if I can help you on that. Santiago El jue., 29 de nov. de 2018 17:55, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > Hi Santiago, > > > Am 29.11.2018 um 17:48 schrieb Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com>: > > Hi Norbert! > > We don't have yet implemented any nor all combinations. I will add it to > the list of things to do for next release. Looks like a simple and useful > thing to have. (Or if you have already something I wouldn't mind to > integrate it) > > I donât have it now but I think when we change to TaskIt we will make them > and we could provide it then. > > Norbert > > > > Thanks. > Santiago > > > El jue., 29 de nov. de 2018 17:36, Norbert Hartl via Pharo-users < > pharo-users(a)lists.pharo.org> escribiÃ³: > >> Great, thanks! >> >> Does TaskIt include implementations for combining futures such as the ALL >> and the ANY futures which resolve either when all or one future resolves? >> From the documentation it looks that rather not. >> >> Norbert >> >> >> Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com>: >> >> Hi everybody :). >> >> I am happy to announce TaskIt v1.0. >> >> In this version we add some new features, passed over the red tests and >> clean up some dead code. And did a pass in the documentation >> >> A bit from the DOC >> Downloading >> >> Current stable version of taskit can be downloaded using metacello as >> follows: >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit'; >> load. >> >> If you want a specific release such as v1.0, you can load the associated >> tag as follows >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit:v1.0'; >> load. >> >> Otherwise, if you want the latest development version, take a look at the >> development branchs and load the latest: >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit:dev-1.1'; >> load. >> >> >> <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major >> Features >> >> - Actors (ActIt) >> - Configuration Profiles >> - Service >> >> >> Check specially the configuration profiles. The default profile usage is >> #development, which sets up the environment for debugging exceptions in a >> process. >> >> I want to thank a lot to the contributors, Guillermo Polito Max Leske >> and Daniel Sasu. >> I want as well to thanks the users, specially to those that bring me >> feedback (blames and ideas) in person (Esteban, Pablo) or through the >> different channels (Holger Freyther, Juraj Kubelka, Philippe Back). >> >> >> I want also to apologise the delay of my responses on the issue board :) >> (Really, sorry). I am constantly using TaskIt in other projects, but much >> times I cannot do it my priority. >> >> >> thanks a lot, >> >> Santiago Bragagnolo. >> >> >> >> >> >> >> >> >> >> >> >

Nov. 29, 2018

Re: [Pharo-dev] [Pharo-users] [Ann] TaskIt v1.0

by Norbert Hartl

Hi Santiago, > Am 29.11.2018 um 17:48 schrieb Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > > Hi Norbert! > > We don't have yet implemented any nor all combinations. I will add it to the list of things to do for next release. Looks like a simple and useful thing to have. (Or if you have already something I wouldn't mind to integrate it) > I donât have it now but I think when we change to TaskIt we will make them and we could provide it then. Norbert > > > Thanks. > Santiago > > > El jue., 29 de nov. de 2018 17:36, Norbert Hartl via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> escribiÃ³: > Great, thanks! > > Does TaskIt include implementations for combining futures such as the ALL and the ANY futures which resolve either when all or one future resolves? From the documentation it looks that rather not. > > Norbert > > >> Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo <santiagobragagnolo(a)gmail.com <mailto:santiagobragagnolo@gmail.com>>: >> >> Hi everybody :). >> >> I am happy to announce TaskIt v1.0. >> >> In this version we add some new features, passed over the red tests and clean up some dead code. And did a pass in the documentation >> >> A bit from the DOC >> Downloading >> >> Current stable version of taskit can be downloaded using metacello as follows: >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit <>'; >> load. >> If you want a specific release such as v1.0, you can load the associated tag as follows >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit:v1.0 <>'; >> load. >> Otherwise, if you want the latest development version, take a look at the development branchs and load the latest: >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit:dev-1.1 <>'; >> load. >> <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major Features >> >> Actors (ActIt) >> Configuration Profiles >> Service >> >> Check specially the configuration profiles. The default profile usage is #development, which sets up the environment for debugging exceptions in a process. >> >> I want to thank a lot to the contributors, Guillermo Polito Max Leske and Daniel Sasu. >> I want as well to thanks the users, specially to those that bring me feedback (blames and ideas) in person (Esteban, Pablo) or through the different channels (Holger Freyther, Juraj Kubelka, Philippe Back). >> >> >> I want also to apologise the delay of my responses on the issue board :) (Really, sorry). I am constantly using TaskIt in other projects, but much times I cannot do it my priority. >> >> >> thanks a lot, >> >> Santiago Bragagnolo. >> >> >> >> >> >> >> >> >> >

Nov. 29, 2018

Re: [Pharo-dev] [Pharo-users] [Ann] TaskIt v1.0

by Santiago Bragagnolo

Hi Norbert! We don't have yet implemented any nor all combinations. I will add it to the list of things to do for next release. Looks like a simple and useful thing to have. (Or if you have already something I wouldn't mind to integrate it) Thanks. Santiago El jue., 29 de nov. de 2018 17:36, Norbert Hartl via Pharo-users < pharo-users(a)lists.pharo.org> escribiÃ³: > Great, thanks! > > Does TaskIt include implementations for combining futures such as the ALL > and the ANY futures which resolve either when all or one future resolves? > From the documentation it looks that rather not. > > Norbert > > > Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com>: > > Hi everybody :). > > I am happy to announce TaskIt v1.0. > > In this version we add some new features, passed over the red tests and > clean up some dead code. And did a pass in the documentation > > A bit from the DOC > Downloading > > Current stable version of taskit can be downloaded using metacello as > follows: > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit'; > load. > > If you want a specific release such as v1.0, you can load the associated > tag as follows > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit:v1.0'; > load. > > Otherwise, if you want the latest development version, take a look at the > development branchs and load the latest: > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit:dev-1.1'; > load. > > > <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major > Features > > - Actors (ActIt) > - Configuration Profiles > - Service > > > Check specially the configuration profiles. The default profile usage is > #development, which sets up the environment for debugging exceptions in a > process. > > I want to thank a lot to the contributors, Guillermo Polito Max Leske > and Daniel Sasu. > I want as well to thanks the users, specially to those that bring me > feedback (blames and ideas) in person (Esteban, Pablo) or through the > different channels (Holger Freyther, Juraj Kubelka, Philippe Back). > > > I want also to apologise the delay of my responses on the issue board :) > (Really, sorry). I am constantly using TaskIt in other projects, but much > times I cannot do it my priority. > > > thanks a lot, > > Santiago Bragagnolo. > > > > > > > > > > >

Nov. 29, 2018

Re: [Pharo-dev] [Ann] TaskIt v1.0

by Norbert Hartl

Great, thanks! Does TaskIt include implementations for combining futures such as the ALL and the ANY futures which resolve either when all or one future resolves? From the documentation it looks that rather not. Norbert > Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > > Hi everybody :). > > I am happy to announce TaskIt v1.0. > > In this version we add some new features, passed over the red tests and clean up some dead code. And did a pass in the documentation > > A bit from the DOC > Downloading > > Current stable version of taskit can be downloaded using metacello as follows: > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit'; > load. > If you want a specific release such as v1.0, you can load the associated tag as follows > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit:v1.0'; > load. > Otherwise, if you want the latest development version, take a look at the development branchs and load the latest: > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit:dev-1.1'; > load. > <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major Features > > Actors (ActIt) > Configuration Profiles > Service > > Check specially the configuration profiles. The default profile usage is #development, which sets up the environment for debugging exceptions in a process. > > I want to thank a lot to the contributors, Guillermo Polito Max Leske and Daniel Sasu. > I want as well to thanks the users, specially to those that bring me feedback (blames and ideas) in person (Esteban, Pablo) or through the different channels (Holger Freyther, Juraj Kubelka, Philippe Back). > > > I want also to apologise the delay of my responses on the issue board :) (Really, sorry). I am constantly using TaskIt in other projects, but much times I cannot do it my priority. > > > thanks a lot, > > Santiago Bragagnolo. > > > > > > > > >

Nov. 29, 2018

[Ann] TaskIt v1.0

by Santiago Bragagnolo

Hi everybody :). I am happy to announce TaskIt v1.0. In this version we add some new features, passed over the red tests and clean up some dead code. And did a pass in the documentation A bit from the DOC Downloading Current stable version of taskit can be downloaded using metacello as follows: Metacello new baseline: 'TaskIt'; repository: 'github://sbragagnolo/taskit'; load. If you want a specific release such as v1.0, you can load the associated tag as follows Metacello new baseline: 'TaskIt'; repository: 'github://sbragagnolo/taskit:v1.0'; load. Otherwise, if you want the latest development version, take a look at the development branchs and load the latest: Metacello new baseline: 'TaskIt'; repository: 'github://sbragagnolo/taskit:dev-1.1'; load. <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major Features - Actors (ActIt) - Configuration Profiles - Service Check specially the configuration profiles. The default profile usage is #development, which sets up the environment for debugging exceptions in a process. I want to thank a lot to the contributors, Guillermo Polito Max Leske and Daniel Sasu. I want as well to thanks the users, specially to those that bring me feedback (blames and ideas) in person (Esteban, Pablo) or through the different channels (Holger Freyther, Juraj Kubelka, Philippe Back). I want also to apologise the delay of my responses on the issue board :) (Really, sorry). I am constantly using TaskIt in other projects, but much times I cannot do it my priority. thanks a lot, Santiago Bragagnolo.

Nov. 29, 2018

[Pharo 7.0-dev] Build #1424: 22711-Improve-Cursor-class-comment

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

There is a new Pharo build available! The status of the build #1424 was: FAILURE. The Pull Request #2024 was integrated: "22711-Improve-Cursor-class-comment" Pull request url: https://github.com/pharo-project/pharo/pull/2024 Issue Url: https://pharo.fogbugz.com/f/cases/22711 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2018

[Pharo 7.0-dev] Build #1423: 22568-ContextcompleteCallee-is-dead-code-new-pr

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

There is a new Pharo build available! The status of the build #1423 was: SUCCESS. The Pull Request #1926 was integrated: "22568-ContextcompleteCallee-is-dead-code-new-pr" Pull request url: https://github.com/pharo-project/pharo/pull/1926 Issue Url: https://pharo.fogbugz.com/f/cases/22568 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2018

[Pharo 7.0-dev] Build #1422: 22708 Tag ManifestRingChunkImporter and related classes

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

There is a new Pharo build available! The status of the build #1422 was: SUCCESS. The Pull Request #2019 was integrated: "22708 Tag ManifestRingChunkImporter and related classes" Pull request url: https://github.com/pharo-project/pharo/pull/2019 Issue Url: https://pharo.fogbugz.com/f/cases/22708 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2018

[Pharo 7.0-dev] Build #1421: 22709 Tag ManifestRingCoreContainers and related classes

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

There is a new Pharo build available! The status of the build #1421 was: SUCCESS. The Pull Request #2020 was integrated: "22709 Tag ManifestRingCoreContainers and related classes" Pull request url: https://github.com/pharo-project/pharo/pull/2020 Issue Url: https://pharo.fogbugz.com/f/cases/22709 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Norbert Hartl

> Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr>: > > > > On Wed, 28 Nov 2018 at 10:23, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr <mailto:christopher.fuhrman@inria.fr>>: >> >> Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? >> > It is not a problem. I use this every day. Meaning all my repos have a scripts folder where I put my helper scripts. In the image I open this with > > âscriptsâ asFileReference inspect > > This is great. Thanks! > > so you get kind of a file browser of all the scripts. If you call the files with an extension of .st you get syntax highlighting. If you change a script with cmd-s the file gets modified and you can check into git. The problem here is that if you have modifications in the image you should commit that first because if you do on the scripts folder first the image working copy is detached and there is no easy way to commit your in-image changes. You would have to do a branch which is cumbersome. > > I'm a bit lost here: > > 1. Are you using Iceberg within Pharo (when you speak of "committing that first"), or are you using only git outside of Pharo? Also, I think it's possible to use a git repo with monticello? > 2. I'm not an advanced git user, so how do I set up my Pharo image directory to work with the 'scripts' folder (again, with Iceberg if possible, as it seems to be the most user-friendly)? > > Thanks for your patience with my beginner questions. > You are welcome. We like to share with people that want to know ;) The problem in understanding is a hard one. Using git means there are two repositories, one online in the git server and the working copy you checked out locally. When using pharo there is a third one and that is the working copy within your image. Having these two there is a number of conflicts possible. As pharo does not manage external resources like these scripts you can have trouble here. When you go to the command line and commit the script and you go back to pharo it tells you that you are in detached state. It means that the git index is not the same as it was when you loaded stuff via pharo. That is why I was saying that a good flow would first commit the pharo changes and then the ones on the command line. Hope this helps, Norbert > Cheers, > > Christopher > > With the scripts in place I have developed a workflow of creating new images. I have a script that downloads a new image and renames it for the project. And if it finds a script > > scripts/prepare-image.st <http://prepare-image.st/> > > it gets executed. This contains metacello commands to load the project code and settings I need in a new image. This way it is super easy to create a new image for your work. And as all the scripts you use are on the filesystem there is usually no state in the image that needs to be transferred to a new image. > > Norbert > >

Nov. 29, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Christopher Fuhrman

On Wed, 28 Nov 2018 at 10:23, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman < > christopher.fuhrman(a)inria.fr>: > > Knowing Playground files are saved on local disk, I got to thinking... > What would be the risk(s) of using git outside Pharo, on the Playground > files' directory? Has anyone tried that before? > > It is not a problem. I use this every day. Meaning all my repos have a > scripts folder where I put my helper scripts. In the image I open this with > > âscriptsâ asFileReference inspect > This is great. Thanks! > so you get kind of a file browser of all the scripts. If you call the > files with an extension of .st you get syntax highlighting. If you change a > script with cmd-s the file gets modified and you can check into git. The > problem here is that if you have modifications in the image you should > commit that first because if you do on the scripts folder first the image > working copy is detached and there is no easy way to commit your in-image > changes. You would have to do a branch which is cumbersome. > I'm a bit lost here: 1. Are you using Iceberg within Pharo (when you speak of "committing that first"), or are you using only git outside of Pharo? Also, I think it's possible to use a git repo with monticello? 2. I'm not an advanced git user, so how do I set up my Pharo image directory to work with the 'scripts' folder (again, with Iceberg if possible, as it seems to be the most user-friendly)? Thanks for your patience with my beginner questions. Cheers, Christopher > With the scripts in place I have developed a workflow of creating new > images. I have a script that downloads a new image and renames it for the > project. And if it finds a script > > scripts/prepare-image.st > > it gets executed. This contains metacello commands to load the project > code and settings I need in a new image. This way it is super easy to > create a new image for your work. And as all the scripts you use are on the > filesystem there is usually no state in the image that needs to be > transferred to a new image. > > Norbert > > >

Nov. 29, 2018

[Pharo 7.0-dev] Build #1420: 22710 Tag ManifestDeprecatedFileStream and related classes

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

There is a new Pharo build available! The status of the build #1420 was: SUCCESS. The Pull Request #2021 was integrated: "22710 Tag ManifestDeprecatedFileStream and related classes" Pull request url: https://github.com/pharo-project/pharo/pull/2021 Issue Url: https://pharo.fogbugz.com/f/cases/22710 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 29, 2018

Re: [Pharo-dev] Excel export with Tabular

by Ben Coman

On Tue, 13 Nov 2018 at 05:42, Hans-Martin Mosner <pharo-dev(a)fam-mosner.de> wrote: > I put it on ss3 because I'm not yet familiar with the way Pharo uses > github. Will look into it later. > > I'm unsure how git repositories are used in the Pharo context. Do you use > them just like you use git normally (i.e. I > use my git repository, you use yours and send me pull requests etc...). > Yes. Exactly like that. cheers -ben

Nov. 28, 2018

Re: [Pharo-dev] Excel export with Tabular

by Vincent.Blondeau＠lamresearch.com

Hi Norbert, I just converted the repository to git few days ago: https://github.com/VincentBlondeau/Tabular I missed to inform you on the mailing list. A thing that is now done! Thanks, Vincent -----Original Message----- From: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> On Behalf Of Norbert Hartl Sent: Wednesday, November 28, 2018 8:53 To: Pharo Dev <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Excel export with Tabular Is there any progress on this? Can you tell the S3 url you are using? Do you need help to put it on github? Norbert > Am 12.11.2018 um 22:41 schrieb Hans-Martin Mosner <pharo-dev(a)fam-mosner.de>: > > I put it on ss3 because I'm not yet familiar with the way Pharo uses github. Will look into it later. > > I'm unsure how git repositories are used in the Pharo context. Do you > use them just like you use git normally (i.e. I use my git repository, > you use yours and send me pull requests etc...). Are there any catalog > systems that allow one to register and find projects? This whole issue has always been a bit confusing in the Squeak/Pharo world due to the number of different options. > > Cheers, > Hans-Martin > > Am 11. November 2018 10:50:40 nachm. schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Hi Hans-Martin, >> >> This is great. I use Tabular too and was missing active >> development/maintenance. It would be very good to see this project move forward. It is quite important/useful in enterprise contexts. >> >> Thx, >> >> Sven >> >> PS: where did you commit the changes ? any chance of moving it to GitHub (too) ? >> >>> On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: >>> >>> Hello folks, >>> I have a need for creating excel files with more than 3 worksheets, >>> so I took the Tabular code and beefed up the exporter a little. It >>> does handle more worksheets now, uses XMLWriter to create all the >>> ZIP members, and is properly named now (the class was called >>> TabularXSLXExport, note swapped S and L). >>> Some tests have been added, there are a number of items that I plan >>> to to as time allows: >>> - Add (possibly limited) support for styles and formulas which I >>> specifically need for the project I'm working on so I could write >>> files with the desired layout and functionality. >>> - Add support for reading more aspects of XLSX files, preferrably as >>> much as needed to be able to read and write most files without loss. >>> - Add rendering, maybe at the basic morphic level, maybe using >>> something else as I'm not really up-to-date regarding the developments in Pharo. >>> - Add formula evaluation. >>> - Add editing capabilites to have a fully functional spreadsheet >>> (really far off). >>> >>> Cheers, >>> Hans-Martin >>> >>> >>> >>> -- >>> Sent from: >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__forum.world.st_P >>> haro-2DSmalltalk-2DDevelopers-2Df1294837.html&d=DwIFAg&c=RWI7EqL8K9l >>> qtga8KxgfzvOYoob76EZWE0yAO85PVMQ&r=kIZIYXBAA3fhM7P5HOuTC5w6mnEApTfXP >>> Tq3lR34ZiY&m=EPbX5TzJOZHDpUVDsq332xD1gqtrIVoQbAznjKQPUdA&s=dW_yz-tezHKlcwFvYmnlCbnMBIEdRMUYhIUjKF9XZSc&e= >>> > > > >

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

> On 28 Nov 2018, at 12:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Ah, I forget to say that this change we enter in effect today :) Ok, maybe tomorrow since I needed to refresh my groovy knowledge ;) Esteban > May the force be with us. > > Esteban > >> On 28 Nov 2018, at 12:25, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Ok, a new pass onto this, I decided that having just dev-Etc. branches and not having a clear stable one may lead to confusion. >> After checking some projects on GitHub, seems that what they do is to name their branches just with the version, not with âdevâ (like, for example "gtk-2.22â). >> >> So, I will name the version based branchs âPharo7.0â, âPharo8.0â and so on. >> >> (Without dash to keep coherence with the artefact naming) >> >> Cheers! >> Esteban >> >> >>> On 22 Nov 2018, at 13:25, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>> >>>> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>> >>>> >>>>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Why not following git flow? >>>>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>>>> This way, there is no change for most people. >>>> >>>> Because our scripts are automated in branch and tag basis. >>>> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. >>>> >>>> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) >>> >>> Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. >>> >>> Esteban >>> >>>> >>>> Esteban >>>> >>>>> >>>>> Christophe >>>>> >>>>>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>>>>> >>>>>> Hi list, >>>>>> >>>>>> Well, subject says pretty much all. >>>>>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>>>>> Then, it will be a âdev-8.0â and so onâ¦ >>>>>> >>>>>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>>>>> >>>>>> Cheers, >>>>>> Esteban >> >

Nov. 28, 2018

Re: [Pharo-dev] Excel export with Tabular

by Norbert Hartl

Is there any progress on this? Can you tell the S3 url you are using? Do you need help to put it on github? Norbert > Am 12.11.2018 um 22:41 schrieb Hans-Martin Mosner <pharo-dev(a)fam-mosner.de>: > > I put it on ss3 because I'm not yet familiar with the way Pharo uses github. Will look into it later. > > I'm unsure how git repositories are used in the Pharo context. Do you use them just like you use git normally (i.e. I > use my git repository, you use yours and send me pull requests etc...). Are there any catalog systems that allow one to > register and find projects? This whole issue has always been a bit confusing in the Squeak/Pharo world due to the number > of different options. > > Cheers, > Hans-Martin > > Am 11. November 2018 10:50:40 nachm. schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Hi Hans-Martin, >> >> This is great. I use Tabular too and was missing active development/maintenance. It would be very good to see this >> project move forward. It is quite important/useful in enterprise contexts. >> >> Thx, >> >> Sven >> >> PS: where did you commit the changes ? any chance of moving it to GitHub (too) ? >> >>> On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: >>> >>> Hello folks, >>> I have a need for creating excel files with more than 3 worksheets, so I >>> took the Tabular code and beefed up the exporter a little. It does handle >>> more worksheets now, uses XMLWriter to create all the ZIP members, and is >>> properly named now (the class was called TabularXSLXExport, note swapped S >>> and L). >>> Some tests have been added, there are a number of items that I plan to to as >>> time allows: >>> - Add (possibly limited) support for styles and formulas which I >>> specifically need for the project I'm working on so I could write files with >>> the desired layout and functionality. >>> - Add support for reading more aspects of XLSX files, preferrably as much as >>> needed to be able to read and write most files without loss. >>> - Add rendering, maybe at the basic morphic level, maybe using something >>> else as I'm not really up-to-date regarding the developments in Pharo. >>> - Add formula evaluation. >>> - Add editing capabilites to have a fully functional spreadsheet (really far >>> off). >>> >>> Cheers, >>> Hans-Martin >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> > > > >

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Stephan Eggermont

Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Why not following git flow? Because git flow has branches that donât add value? Stephan

Nov. 28, 2018

[Pharo 7.0-dev] Build #1419: 22702-support-before-after-intead-on-RBCascadeNode

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

There is a new Pharo build available! The status of the build #1419 was: SUCCESS. The Pull Request #2018 was integrated: "22702-support-before-after-intead-on-RBCascadeNode" Pull request url: https://github.com/pharo-project/pharo/pull/2018 Issue Url: https://pharo.fogbugz.com/f/cases/22702 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Ah, I forget to say that this change we enter in effect today :) May the force be with us. Esteban > On 28 Nov 2018, at 12:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Ok, a new pass onto this, I decided that having just dev-Etc. branches and not having a clear stable one may lead to confusion. > After checking some projects on GitHub, seems that what they do is to name their branches just with the version, not with âdevâ (like, for example "gtk-2.22â). > > So, I will name the version based branchs âPharo7.0â, âPharo8.0â and so on. > > (Without dash to keep coherence with the artefact naming) > > Cheers! > Esteban > > >> On 22 Nov 2018, at 13:25, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>> >>>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>>> >>>> Hi, >>>> >>>> Why not following git flow? >>>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>>> This way, there is no change for most people. >>> >>> Because our scripts are automated in branch and tag basis. >>> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. >>> >>> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) >> >> Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. >> >> Esteban >> >>> >>> Esteban >>> >>>> >>>> Christophe >>>> >>>>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>>>> >>>>> Hi list, >>>>> >>>>> Well, subject says pretty much all. >>>>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>>>> Then, it will be a âdev-8.0â and so onâ¦ >>>>> >>>>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>>>> >>>>> Cheers, >>>>> Esteban >

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Ok, a new pass onto this, I decided that having just dev-Etc. branches and not having a clear stable one may lead to confusion. After checking some projects on GitHub, seems that what they do is to name their branches just with the version, not with âdevâ (like, for example "gtk-2.22â). So, I will name the version based branchs âPharo7.0â, âPharo8.0â and so on. (Without dash to keep coherence with the artefact naming) Cheers! Esteban > On 22 Nov 2018, at 13:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>> >>> Hi, >>> >>> Why not following git flow? >>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>> This way, there is no change for most people. >> >> Because our scripts are automated in branch and tag basis. >> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. >> >> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) > > Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. > > Esteban > >> >> Esteban >> >>> >>> Christophe >>> >>>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>>> >>>> Hi list, >>>> >>>> Well, subject says pretty much all. >>>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>>> Then, it will be a âdev-8.0â and so onâ¦ >>>> >>>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>>> >>>> Cheers, >>>> Esteban

Nov. 28, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Norbert Hartl

> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr>: > > Hello, > > In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. > > However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. > > My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. > > I know how to save Playground files to the web, which is useful, but of course not version control per se. > > Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? > It is not a problem. I use this every day. Meaning all my repos have a scripts folder where I put my helper scripts. In the image I open this with âscriptsâ asFileReference inspect so you get kind of a file browser of all the scripts. If you call the files with an extension of .st you get syntax highlighting. If you change a script with cmd-s the file gets modified and you can check into git. The problem here is that if you have modifications in the image you should commit that first because if you do on the scripts folder first the image working copy is detached and there is no easy way to commit your in-image changes. You would have to do a branch which is cumbersome. With the scripts in place I have developed a workflow of creating new images. I have a script that downloads a new image and renames it for the project. And if it finds a script scripts/prepare-image.st <http://prepare-image.st/> it gets executed. This contains metacello commands to load the project code and settings I need in a new image. This way it is super easy to create a new image for your work. And as all the scripts you use are on the filesystem there is usually no state in the image that needs to be transferred to a new image. Norbert

Nov. 28, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Esteban Lorenzano

Hi, > On 28 Nov 2018, at 09:38, Christopher Fuhrman <christopher.fuhrman(a)inria.fr> wrote: > > Hello, > > In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. > > However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. > > My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. > > I know how to save Playground files to the web, which is useful, but of course not version control per se. > > Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? It should be possible without any risk. You should: a) Redirect playground cache to some place you want (option is somewhere in settingsâ¦) b) Version those from outside. And the only drawback is that you will need to ârepairâ your image project each time you do that, because the project will move to âdetached stateâ. But repair is easy: just merge with your branch (99% of the time it will do a fast forward). Esteban > > Cheers, > > Christopher >

Nov. 28, 2018

Version control of Playground scripts

by Christopher Fuhrman

Hello, In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. I know how to save Playground files to the web, which is useful, but of course not version control per se. Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? Cheers, Christopher

Nov. 28, 2018

[Pharo 7.0-dev] Build #1418: 22700-add-value-and-operation-for-Blocks

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

There is a new Pharo build available! The status of the build #1418 was: SUCCESS. The Pull Request #2017 was integrated: "22700-add-value-and-operation-for-Blocks" Pull request url: https://github.com/pharo-project/pharo/pull/2017 Issue Url: https://pharo.fogbugz.com/f/cases/22700 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1417: 22697-remove-oldvalue-reification

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

There is a new Pharo build available! The status of the build #1417 was: FAILURE. The Pull Request #2014 was integrated: "22697-remove-oldvalue-reification" Pull request url: https://github.com/pharo-project/pharo/pull/2014 Issue Url: https://pharo.fogbugz.com/f/cases/22697 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1416: 22640-Sending-links-to-an-AST-should-not-return-nil-if-there-is-no-link

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

There is a new Pharo build available! The status of the build #1416 was: FAILURE. The Pull Request #2013 was integrated: "22640-Sending-links-to-an-AST-should-not-return-nil-if-there-is-no-link" Pull request url: https://github.com/pharo-project/pharo/pull/2013 Issue Url: https://pharo.fogbugz.com/f/cases/22640 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1415: 22695-Make-value-for-work-method-after

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

There is a new Pharo build available! The status of the build #1415 was: FAILURE. The Pull Request #2012 was integrated: "22695-Make-value-for-work-method-after" Pull request url: https://github.com/pharo-project/pharo/pull/2012 Issue Url: https://pharo.fogbugz.com/f/cases/22695 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

Re: halos

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Then you need to be a bit more precise than just saying âit does not works anymoreâ :) > > Anyway, I canât reproduce your problem. > > Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 (64bit) > > And latestVM, still works for me on windows. > PharoLauncher Pharo 7 (development version) list isnât updated anymore, stuck at 1384. 1411 works for me too. Thanks, Stephan

Nov. 26, 2018

Re: [Pharo-dev] halos

by Esteban Lorenzano

Then you need to be a bit more precise than just saying âit does not works anymoreâ :) Anyway, I canât reproduce your problem. Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 (64bit) And latestVM, still works for me on windows. Esteban > On 26 Nov 2018, at 14:31, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> They work for me. >> Same combination as always (alt+shift+click) > > Not on 1384-64 in Windows with the latest vm > > Stephan > > > > >

Nov. 26, 2018

Re: [Pharo-dev] Fuel update for UTCDateAndTime

by Max Leske

Thanks Dave! I've opened an issue on Github: https://github.com/theseion/Fuel/issues/235. Max On 26 Nov 2018, at 14:20, David T. Lewis wrote: > The Fuel serializer is loadable in Squeak 5.2 from the SqueakMap loader, > and is supported for Pharo, Squeak, and Cuis (great kudos to the > maintainers for doing this). > > In order to change DateAndTime to a simpler UTC-based implementation in > Squeak, with two instance variables rather than four, an update will be > needed for Fuel to understand the new format. > > The attached change set provides the necessary support, while maintaining > compatibility with the traditional DateAndTime and interoperability > between images that support either format. For example, an image can > serialize a traditional DateAndTime with Fuel, and another image with > UTC DateAndTime can materialize it in the new UTC format. > > I am not yet sure how to submit this to the Fuel maintainers, so I'm > posting it here as a change set for now. > > Dave

Nov. 26, 2018

Re: [Pharo-dev] halos

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > They work for me. > Same combination as always (alt+shift+click) Not on 1384-64 in Windows with the latest vm Stephan

Nov. 26, 2018

Fuel update for UTCDateAndTime

by David T. Lewis

The Fuel serializer is loadable in Squeak 5.2 from the SqueakMap loader, and is supported for Pharo, Squeak, and Cuis (great kudos to the maintainers for doing this). In order to change DateAndTime to a simpler UTC-based implementation in Squeak, with two instance variables rather than four, an update will be needed for Fuel to understand the new format. The attached change set provides the necessary support, while maintaining compatibility with the traditional DateAndTime and interoperability between images that support either format. For example, an image can serialize a traditional DateAndTime with Fuel, and another image with UTC DateAndTime can materialize it in the new UTC format. I am not yet sure how to submit this to the Fuel maintainers, so I'm posting it here as a change set for now. Dave

Nov. 26, 2018

Re: [Pharo-dev] halos

by Esteban Lorenzano

They work for me. Same combination as always (alt+shift+click) Esteban > On 26 Nov 2018, at 13:48, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > What happened with halos in Pharo 7? They donât show up anymore > > Stephan > >

Nov. 26, 2018

halos

by Stephan Eggermont

What happened with halos in Pharo 7? They donât show up anymore Stephan

Nov. 26, 2018

[Pharo 7.0-dev] Build #1414: 22690-32-vs-64-bits-and-large-integer-hash

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

There is a new Pharo build available! The status of the build #1414 was: FAILURE. The Pull Request #2009 was integrated: "22690-32-vs-64-bits-and-large-integer-hash" Pull request url: https://github.com/pharo-project/pharo/pull/2009 Issue Url: https://pharo.fogbugz.com/f/cases/22690 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 26, 2018

Esteban's ChangeLog week of 19 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 19 November 2018 to 25 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=19/11/2018&to=25/11/2018 ChangeLog ========= 22 November 2018: ----------------- * I made a change in the VM to modify [freetype version to 2.9.1](https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/307). We have the suspicion that some bugs we are finding in our use of freetype fonts may be already fixed on newer versions of freetype library (we were using 2.6.5). And well, if that is not the case, at least we will be up-to-date :) 19 November 2018: ----------------- * I made a [PR](https://github.com/pharo-project/pharo/pull/2002) to improve the logic in callbacks. They were not returning in case of error, and that was leading to a system crash almost inevitably. cheers! Esteban

Nov. 26, 2018

Re: [Pharo-dev] [squeak-dev] 32 vs 64 bits and large integer hash

by Luciano Notarfrancesco

Hi Eliot! On Sat, Nov 24, 2018 at 9:18 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > On Sat, Nov 24, 2018 at 7:40 AM Luciano Notarfrancesco <luchiano(a)gmail.com> > wrote: > >> >> Yes! I had this problem blow in my face a couple of years ago, and Juan >> agreed to include the change in Cuis to make SmallIntegers NOT their own >> hash. >> > > This seems to be a basic error. The idea of a hash function is to produce > a well-distributed set of integers for some set of values. Since the > SmallIntegers are themselves perfectly distributed (each unique > SmallInteger is a unique value), it is impossible to produce a better > distributed hash function than the integers themselves. For some > application it may indeed be possible to produce a better distributed set > of hashes for the integers; for example an application which considers only > powers of two could use the log base 2 to produce a smaller and better > distributed set fo values modulo N than the integers themselves. But in > general the integers are definitionally well-distributed. In fact, unless > one has a perfect hash function one is in danger of producing a less > well-distributed set of values from a hash function than the SmallIntegers > themselves. > > The problem I see is that sequences of SmallIntegers that we humans tend add to hashed collections are not usually uniformly distributed. Hopefully they have some meaning, and thus some patterns to them, most of the time they don't look random, and thus if they are their own hash the performance of hashed collections will most likely suffer. I found this problem when profiling my code. I guess some people might assume that Sets or Dictionaries are fast and use them with SmallIntegers without much care, and never discover that their code could be orders of magnitude faster. So, another option might be to modify scanFor: to randomize the hash of the argument (for example sending an additional hashMultiply). This is because scanFor: is assuming the arguments of successive calls will have uniformly distributed hashes: start := anObject hash \\ array size + 1. the algorithm needs 'start' to be uniformly distributed between 1 and array size, and in the case of SmallIntegers current hash this is very unlikely and lookups degenerate in linear searches. Also, any cryptographic hash will do great in pretty much ALL use cases. Finding a sequence of integers that produces non-uniform hashes is very hard, and is equivalent to breaking the cryptographic hash and make it unusable for cryptography. This is a sort of silver bullet, I seem to remember that Java does this now, but I think it is overkill and something like hashMultiply is enough (plus, it is cheaper). My 2 maos, Luciano

Nov. 25, 2018

Re: [Pharo-dev] [squeak-dev] 32 vs 64 bits and large integer hash

by Eliot Miranda

On Sat, Nov 24, 2018 at 7:40 AM Luciano Notarfrancesco <luchiano(a)gmail.com> wrote: > On Fri, Nov 23, 2018 at 12:36 AM Chris Muller <asqueaker(a)gmail.com> wrote: > >> > >> I'm a bit puzzled. I thought (small)Integers being their own hash >> is a good thing? >> >> I was wondering exactly the same thing! >> >> > > I would call it simple but not necessarily good. >> > > The problem with it is that consecutive numbers generate long chains >> in HashedCollections: >> > > >> > > a := (1 to: 1000) asArray. >> > > s := Set withAll: a. >> > > [ 1 to: 1000000 do: [ :each | s includes: each ] ] timeToRun. >> > > "==> 7014" >> > > >> > > The solution in Squeak is to use PluggableSet instead of Set, because >> it applies #hashMultiply on the hash value: >> > > >> > > ps := PluggableSet integerSet. >> > > ps addAll: a. >> > > [ 1 to: 1000000 do: [ :each | ps includes: each ] ] timeToRun. >> > > "==> 95" >> > > >> > > IIRC in Pharo SmallInteger's hash is based on #hashMultiply to avoid >> the long chains. That was probably the main reason for the push to make >> #hashMultply a numbered primitive. >> > > >> > >> > Interesting! >> >> Indeed! When making a #hash methods, one always focuses on hash >> distribution and finding the elements, but its easy to forget about >> performance of NOT finding an element. >> >> > Yes! I had this problem blow in my face a couple of years ago, and Juan > agreed to include the change in Cuis to make SmallIntegers NOT their own > hash. > This seems to be a basic error. The idea of a hash function is to produce a well-distributed set of integers for some set of values. Since the SmallIntegers are themselves perfectly distributed (each unique SmallInteger is a unique value), it is impossible to produce a better distributed hash function than the integers themselves. For some application it may indeed be possible to produce a better distributed set of hashes for the integers; for example an application which considers only powers of two could use the log base 2 to produce a smaller and better distributed set fo values modulo N than the integers themselves. But in general the integers are definitionally well-distributed. In fact, unless one has a perfect hash function one is in danger of producing a less well-distributed set of values from a hash function than the SmallIntegers themselves. This argument doesn't apply as integers grow beyond the SmallInteger, but not because we want better distribution of values than the large integers themselves, but b because we want to avoid large integer arithmetic. > I think it is a good idea in general when programming a hash method in > Smalltalk to make it somewhat random. > As I've indicated, I think this is impossible in general. It is only in specific applications, using specific subsets of the SmallIn tigers for which a better hash function could be derived, but this would be specific to that application. For purposes such as these we have PluggableDictionary et al which can exploit an application-specific hash. But in general the SmallIntegers are ideal values for their own hashes. > It will never be perfect for every use case, and it doesn't need to be > cryptographically secure, but there shouldn't be simple use cases (e.g., > consecutive integers) that produce hashes that are not uniformly > distributed. This can be achieved with minimal performance impact (and > potentially big performance gains in hashed collections) quite simply by > sending some hashMultiply message in your hash method. > > Regards, > Luciano > _,,,^..^,,,_ best, Eliot

Nov. 24, 2018

[ANN] Live type information for Smalltalk

by Hernan Wilkinson

Hi all!, I wanted to let you know that I have implemented a "feature" to have type information "live". Currently it is implemented on Cuis but the idea is to port it to Pharo and Squeak as well. This feature is based on a few changes on the VM that collects the class of the object assigned to a variable, a parameter or when returning from a method. That information is available from the image and allows to improve the tools radically, like the autocompletion on the browser, looking for senders/implementors and even "scoping" the refactorings based on the type info. I presented it at the last Smalltalks (the argentinean smalltalk conference) and I'm happy to announce its alpha version (1/1000) asFloat :-) Here is a link to the repo that has the VM and a Cuis image to play with it: https://github.com/hernanwilkinson/Cuis-Smalltalk-DynamicTypeInformation It also has the source of the VM's changes if you want to see how it is implemented. Currently it is implemented only in the stack VM and the VMs I compiled and uploaded to the repo are 64 bits for MacOs and Linux. (I don't have a Windows machine to compile it :-) ) Here is a link to a video that shows how it is implemented and how to use it: https://t.co/n8FQuo7pKZ If you want to see the slides of the presentation, here is the link: https://www.slideshare.net/hernanwilkinson/dynamic-type-information I would love for you to try it and get feedback, ideas, etc. I really believe it is a "killer feature", something that could take Smalltalk one step further and show the way to other dynamically typed languages. Cheers! Hernan -- *HernÃ¡n WilkinsonAgile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125 *Mobile: +54 - 911 - 4470 - 7207email: hernan.wilkinson(a)10Pines.comsite: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 24, 2018

[Pharo 7.0-dev] Build #1413: 22686-Open-browser-fails-without-sources-file-

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

There is a new Pharo build available! The status of the build #1413 was: SUCCESS. The Pull Request #2008 was integrated: "22686-Open-browser-fails-without-sources-file-" Pull request url: https://github.com/pharo-project/pharo/pull/2008 Issue Url: https://pharo.fogbugz.com/f/cases/22686 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 23, 2018

[Pharo 7.0-dev] Build #1412: 22692-Improve-after-operation-for-Array

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

There is a new Pharo build available! The status of the build #1412 was: FAILURE. The Pull Request #2011 was integrated: "22692-Improve-after-operation-for-Array" Pull request url: https://github.com/pharo-project/pharo/pull/2011 Issue Url: https://pharo.fogbugz.com/f/cases/22692 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 23, 2018

[ANN] Next Pharo Sprint: Nov 30

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Nov 30, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973626

Nov. 23, 2018

Re: [Pharo-dev] [squeakland] strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Bernhard HÃ¶fner

Hello Tim and the group thank you for your reply. It is very good to hear, that it is effort in the Smalltalk Scratch, especially when it has such good results. By the way: can I see it as the new Smalltalk Scratch version also for other platforms than Raspberry Pi? I ask, because also other Smalltalk based implementations could profit from it, for example the ipad-version Pyonkee or the Version with Smalltalk-code-view Phratch. Speed would be a matter when programming serious Apps for tablets or smartphones. By using all its sensors children could make nice tools with it and they experiment not only with Software but with the real world objects (which also brings them closer to Smalltalks object orientation). But this detaches me from my real concern: how is it possible to bundle all the initiatives and power to have realized such a continuous Scratch / Smalltalk tool, that I tried to describe with my Topic. Unfortunately nobody answered on my question if such a tool is welcome. Maybe I am the only one with that vision. Best Regards, Bernhard I just replied in the squeak-list, that I shift the discussion to pharo list. I wrote there: â...Because there is no discussion started about my underlying question, I try to continue it on pharo list. I think, many of the participants in squeak list are also participants there. Further I think, that scratch could be a good starting point Tobias mentioned the https://programmieren.wdrmaus.de <https://programmieren.wdrmaus.de/> project which again shows that Scratch is spread and willingly used. Maybe it is not such important, which porting is used as long the "project" code is interchangeable, which means that the Smalltalk-based implementation should be maintained and always be up to date. I dont know if someone takes care about that." > Am 03.11.2018 um 04:27 schrieb tim Rowledge <tim(a)rowledge.org>: > > > >> On 2018-11-02, at 3:22 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> Hi Tim >> >> I think you do not read the Pharo list. > > This is true. Only so much time in one life... > >> >> Below post from somebody who is not aware that you ported Scratch to >> the freshly release Squeak 5.2 easily loadable through SqueakMap.... > > Hi Bernhard - I spent some time working for the Raspberry Pi Foundation to significantly rewrite the original Scratch/Squeak implementation so it would perform well on the Pi (back then of course the original Pi with the single core 700MHz cpu) and I was able to make it really quite a lot faster. I also made it possible to run on a modern version of Squeak and indeed it currently runs on Squeak 5.2 - which makes it *very* nice on a Pi3B+. > > You can find it on SqueakMap as 'nuscratch' along with the gpio server and gpio driver libraries I developed. You might also be interested in the 'Whiskers' project by someone I only know as 'NoMod'; google is your friend in this case. They developed some further extensions to read .sb2 files, change the UI to closely match that of Scratch 2 (which as you likely know was a rewrite by MIT in *Flash*, of all horrible things) and add some new blocks. > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: CBA: Compare if Biorhythms Amenable > >

Nov. 23, 2018