May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [SURVEY] Pillar input/output files.

by Guillermo Polito

If I understand correctly... then, why the pillar.conf is not just a pillar file? (And the conf is the header if the file?) :) El lun., 4 de may. de 2015 a la(s) 2:50 p. m., Damien Cassou < damien.cassou(a)inria.fr> escribiÃ³: > > Cyril Ferlicot <cyril.ferlicot(a)gmail.com> writes: > > > Hi, > > I'm currently working on the way we manage the input files and the > output files. > > The way we manage the files now makes hard some improvement of Pillar. > > That's why with Damien we though about makes some changes. The changes > > are big so I wanted to talk about that with you. > > We propose to have always 1 file with all the work inside. That can > > use the inputFile tag. For example: > > > > "${inputFile:Chapter1.pillar}$ > > > > ${inputFile:Chapter2.pillar}$ > > > > ${inputFile:Chapter3.pillar}$ > > > > ${inputFile:Chapter4.pillar}$" > > > > And the option "separateOutputFiles" will now create 1 file each time > > we have a new Chapter. (!Level 1 header). > > That will make simpler the way to number everything and to create > > anchor because those 2 doesn't work well with the "separateOutputFile" > > option. > > > > What do you thing? That would be good with you? > > this change proposes to remove the option inputFiles from Pillar. Pillar > will now take only 1 Pillar input file that must include the rest. This > will simplify pillar.conf, this will simplify compile.sh, this will make > it easier for the author to understand the process, and this will > simplify Pillar's implementation. With this in place, we think we can > fix the problems with anchors and inter-chapter links. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Thierry Goubier

2015-05-04 14:36 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Thierry Goubier wrote > > How where those packages saved? > > I don't remember :/ > If I could suggest something, it would be to try to recreate the history... I'm allways worried to see that, in the configurations you're working with, history is cut. But I don't understand why ConfigurationOfTxText-NicolaiHess.42 is not in the repository :( Could that be a reason for some of the MC operations to have strange results? Thierry > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/MC-Strange-Problem-tp4824138p4824264.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Nicolai Hess

2015-05-04 14:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Ok, I had a look on > > ConfigurationOfTxText-SeanDeNigris.48 > > And, what I can see: > > - two rpackages are created upon loading: 'ConfigurationOfTxText' and 'a > MCWorkingCopy(ConfigurationOfTxText)'. > > - Two WorkingCopy(s) are created, but one is NicolaiHess.42 (the one > already in the image in Pharo 4). > > - History stops at NicolaiHess.42 ? > Ups! > > All packages newer than NicolaiHess.42 have their history cut at > NicolaiHess.42. And a few (SeanDeNigris.48 for sure) have 'a > MCWorkingCopy(ConfigurationOfTxText)' as package name instead of > 'ConfigurationOfTxText', and this is inside the .mcz. > > How where those packages saved? > Don't know what I did wrong, but I don't know much about this and don't have much experience with this. I just copied the packages from the repository to the inbox when I created a new configuration. > > Thierry > > > 2015-05-04 12:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Thierry Goubier wrote >> > can you point me towards one of those corrupt versions? >> >> Apparently the problem started with ConfigurationOfTxText-SeanDeNigris.48 >> and then ConfigurationOfTxText-SeanDeNigris.49 in >> http://smalltalkhub.com/mc/Pharo/TxText/main/ >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/MC-Strange-Problem-tp4824138p4824212.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

May 4, 2015

Re: [Pharo-dev] [Pharo-users] [SURVEY] Pillar input/output files.

by Damien Cassou

Cyril Ferlicot <cyril.ferlicot(a)gmail.com> writes: > Hi, > I'm currently working on the way we manage the input files and the output files. > The way we manage the files now makes hard some improvement of Pillar. > That's why with Damien we though about makes some changes. The changes > are big so I wanted to talk about that with you. > We propose to have always 1 file with all the work inside. That can > use the inputFile tag. For example: > > "${inputFile:Chapter1.pillar}$ > > ${inputFile:Chapter2.pillar}$ > > ${inputFile:Chapter3.pillar}$ > > ${inputFile:Chapter4.pillar}$" > > And the option "separateOutputFiles" will now create 1 file each time > we have a new Chapter. (!Level 1 header). > That will make simpler the way to number everything and to create > anchor because those 2 doesn't work well with the "separateOutputFile" > option. > > What do you thing? That would be good with you? this change proposes to remove the option inputFiles from Pillar. Pillar will now take only 1 Pillar input file that must include the rest. This will simplify pillar.conf, this will simplify compile.sh, this will make it easier for the author to understand the process, and this will simplify Pillar's implementation. With this in place, we think we can fix the problems with anchors and inter-chapter links. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

May 4, 2015

Re: [Pharo-dev] Validation Artifacts

by Mariano Martinez Peck

On Mon, May 4, 2015 at 8:11 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > It seems that only the report is saved. On failures, shouldn't we also save > the Fuel-outs e.g. of the failed tests? > > At one point in time, for sure we had that. Now I don't know. I remember some discussions about disk space. So maybe the fueled out stacks suffered from that cut in space? > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Validation-Artifacts-tp4824219.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Sean P. DeNigris

Thierry Goubier wrote > How where those packages saved? I don't remember :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/MC-Strange-Problem-tp4824138p4824264.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Thierry Goubier

Ok, I had a look on ConfigurationOfTxText-SeanDeNigris.48 And, what I can see: - two rpackages are created upon loading: 'ConfigurationOfTxText' and 'a MCWorkingCopy(ConfigurationOfTxText)'. - Two WorkingCopy(s) are created, but one is NicolaiHess.42 (the one already in the image in Pharo 4). - History stops at NicolaiHess.42 ? All packages newer than NicolaiHess.42 have their history cut at NicolaiHess.42. And a few (SeanDeNigris.48 for sure) have 'a MCWorkingCopy(ConfigurationOfTxText)' as package name instead of 'ConfigurationOfTxText', and this is inside the .mcz. How where those packages saved? Thierry 2015-05-04 12:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Thierry Goubier wrote > > can you point me towards one of those corrupt versions? > > Apparently the problem started with ConfigurationOfTxText-SeanDeNigris.48 > and then ConfigurationOfTxText-SeanDeNigris.49 in > http://smalltalkhub.com/mc/Pharo/TxText/main/ > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/MC-Strange-Problem-tp4824138p4824212.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 4, 2015

Re: [Pharo-dev] TxText: More Cleaning and Questions

by Sean P. DeNigris

Sean P. DeNigris wrote > > Sean P. DeNigris wrote >> a bit of cleaning... >> Issue 15475: TxText Cleanup for Pharo 5.0 #2 > Finally passed validation! Okay to include? Now there are: - Issue 15475: TxText Cleanup for Pharo 5.0 #2 - Issue 15481: TxText Cleanup for Pharo 5.0 #3 Both have passed validation. They are almost entirely cleanups. The only slight API change is in #3 (with a semantic minor version bump to the config): - [ENH]: Remove TxModel>>#getAttribute:, which makes no sense - you must ask a span or position for an attribute, not a text - [ENH]: Rename TxModel>>#import: -> #replaceAllWith: Actually managing via config is pretty cool because I was able to easily build #3 on #2. So, if we like both, only #3 has to be integrated. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-More-Cleaning-and-Questions-tp4823894p4824261.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 4, 2015

Re: [Pharo-dev] New Versionner Tool and Authentication

by Sean P. DeNigris

Sean P. DeNigris wrote > The easiest way would be to remove the www from the config :) Done. Problem solved... for the moment :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Versionner-Tool-and-Authentication-tp4824032p4824… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 4, 2015

[sligt improvement] New Binary File Stream

by Guillermo Polito

Hi guys, due to last week's discussions and some comments in the issue tracker, I wrote this morning the little improvement of the day: A simple BinaryFileStream. That is: A file stream that is - simple (no character encoding, no buffering) - binary (no automatic transformation to ascii characters) The good thing is that these features are not lost: this file stream is composable with Zn stream decorators: "encoding" fileStream := BinaryFileStream openFileNamed: 'test.txt'. writeStream := ZnCharacterWriteStream on: fileStream. writeStream nextPutAll: 'aÃ¡Ã¨OÃ»Ã¯'. writeStream nextPut: $a. fileStream := BinaryFileStream openFileNamed: 'test.txt'. readStream := ZnCharacterReadStream on: fileStream. readStream upToEnd. "Buffering" fileStream := BinaryFileStream openFileNamed: 'test.txt'. readStream := ZnBufferedReadStream on:(ZnCharacterReadStream on: fileStream). readStream upToEnd. On the other side, this stream does not handle UI (like the old FileStream that e.g., asks the user if a file already exists), since I believe this is a concern that should be of the tools and not the file stream ^^. This is related to issue 15486. A slice is in the inbox for it if you would like to try. Guille

May 4, 2015