- Pharo-dev - lists.pharo.org

[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