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

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