December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] TextLint question

by Lukas Renggli

Yes, but unfortunately that's not easy to do with Glamour, AFAIK. Lukas On 15 December 2010 18:00, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > A cheap solution is to adjust the indexes according to the number of backslash key and non-backslash key that one press. > > Alexandre > > > On 15 Dec 2010, at 13:35, Fabrizio Perin wrote: > >> Hi Alex, >> well the text index is calculated when you run the rules so of course if you touch the text than the indexes are not precise anymore. When you accept the text is saved and the rules are recalculated so also the positions of the errors are calculated again. >> >> Unfortunately i don't have a nice solution for this problem. One way could be: >> - when you save instead running the rules you just save the modified document. >> - than all the indexes of all the errors are update with the difference in size between the old and the new document. >> >> I don't know if this is going to be faster than simply re-run the rules. Anyway I will give it a try and i will let you know. >> >> Cheers, >> >> Fabrizio >> >> >> 2010/12/15 Alexandre Bergel <alexandre(a)bergel.eu> >> hi! >> >> I am now using TextLint over my submissions. Each time I modify the text, the rest of the errors have a wrong text index. It makes it difficult to use. >> I do an accept, to save my .tex and run the rules again, but it takes time... >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 15, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Igor Stasenko

On 15 December 2010 19:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Dec 15, 2010 at 5:23 AM, Peter van Rooijen <peter(a)vanrooijen.com> > wrote: >> >> On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda >> <eliot.miranda(a)gmail.com> wrote: >> >> Note that not writing source to the changes file has ancilliary benefits; >> change recovery is now not polluted with package loads and the changes >> file >> does not grow as packages are added, only as one's changes are made. >> Unloading a package doesn't leave garbage in the changes files. >> >> There are downsides. Â Deploying a development image means deploying all >> the >> associated parcel source files as well, and for this a >> platform-independent >> Filename abstraction really helps. >>> >>> Thanks for the explanation. I wonder how the previous versions of a >>> method can be found using parcels. >> >> I hacked a dreadful implementation of overrides in vw3.0 and I don't think >> things are much better now. Â But >> inÂ http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.ht… >> I sketched how I think it should be done: >> Maintain a global package load order (a stack of loaded packages, removing >> interior elements on unload). >> Maintain a dictionary from method reference to set of package/method pairs >> for each method that is overridden. >> When a package is removed search overrides and compute the overridden >> methods to be reinstalled, computing the uppermost method depending on the >> new package order. >> So to answer your question, one finds the previous versions directly in >> the overrides dictionary, and sorts the results according to the current >> package load order. >> >> Wasn't Levente asking about "regular" replacing of methods? >> >> I thought his question was about that; if the source is not in >> >> the changes file but in a parcel source file, then when I save >> >> a new version of a method and want to look for the old one, >> >> that will not be in the changes file. > > No. Â Anything you write goes on the changes files including new method > definitions, doits, reorganizations, method removals class removals etc. > >> >> When I build up a new image >> >> from parcels, the load script copies all the sources to the >> >> changes file, so I have easy access to the history. > > Why bother? Â A published parcel is an immutable versioned artifact. Â It > doesn't change over time, so, like a release sources file, one can always > rely on its contents. +1 Instead of putting all methods and classes from package into .changes it could be just a simple doit, like: MC load: 'blahblah.mcz' It could be somewhat different during merge. > HTH > Eliot -- Best regards, Igor Stasenko AKA sig.

Dec. 15, 2010

[Pharo-project] Next installment posted: Redline Smalltalk in "small talks" - the setup ...

by James Ladd

The next installment in the series Redline: Smalltalk in "small talks" has been posted: Running code: http://blog.redline.st/2010/12/15/smalltalk-in-small-talks-the-setup/ I know the readers here have a lot of experience with current and future Smalltalk plans, so I'm hoping this is of interest and that your comments helps Redline. Rgs, James.

Dec. 15, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Eliot Miranda

On Wed, Dec 15, 2010 at 5:23 AM, Peter van Rooijen <peter(a)vanrooijen.com>wrote: > On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Note that not writing source to the changes file has ancilliary benefits; > change recovery is now not polluted with package loads and the changes file > does not grow as packages are added, only as one's changes are made. > Unloading a package doesn't leave garbage in the changes files. > > There are downsides. Deploying a development image means deploying all the > associated parcel source files as well, and for this a platform-independent > Filename abstraction really helps. > > >> Thanks for the explanation. I wonder how the previous versions of a method >> can be found using parcels. >> > > I hacked a dreadful implementation of overrides in vw3.0 and I don't think > things are much better now. But in > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.ht… sketched how I think it should be done: > > Maintain a global package load order (a stack of loaded packages, removing > interior elements on unload). > Maintain a dictionary from method reference to set of package/method pairs > for each method that is overridden. > When a package is removed search overrides and compute the overridden > methods to be reinstalled, computing the uppermost method depending on the > new package order. > > So to answer your question, one finds the previous versions directly in the > overrides dictionary, and sorts the results according to the current package > load order. > > > Wasn't Levente asking about "regular" replacing of methods? > > I thought his question was about that; if the source is not in > > the changes file but in a parcel source file, then when I save > > a new version of a method and want to look for the old one, > > that will not be in the changes file. > No. Anything you write goes on the changes files including new method definitions, doits, reorganizations, method removals class removals etc. > > When I build up a new image > > from parcels, the load script copies all the sources to the > > changes file, so I have easy access to the history. > Why bother? A published parcel is an immutable versioned artifact. It doesn't change over time, so, like a release sources file, one can always rely on its contents. HTH Eliot > Just wondering... > > > Peter > > > best > Eliot > >> >> >> Levente >> >> >>> best >>> Eliot >>> >>> >>> >>>> Levente >>>> >>> > > > >

Dec. 15, 2010

Re: [Pharo-project] Gofer versus Installer

by Andreas Raab

On 12/15/2010 9:21 AM, Chris Muller wrote: > One question that came to my mind last night: What does> 1000 lines > of Gofer code bring to Monticello-loading that I can't already do with > just Monticello? or with a couple of facade methods added to plain > MC? I spent the evening yesterday to look at Gofer in detail and it is what led me to say that Gofer is really an API to Monticello, not an installer. First, there is nothing in there that should not be part of Monticello proper; contrary to Installer and Metacello I would expect all the stuff that is in Gofer to be readily available in Monticello itself. Gofer is simply a good facade to Monticello with a useful API. Secondly, much of the code in Gofer comes from the "command pattern gone wild" problem. Gofer simply overuses the command pattern. Every operation is wrapped in a separate class without any need for doing so. As a consequence, things that should be a simple "self foo" become unnecessarily complex in creation, setup, and execution. If you would take this out, it would reduce Gofer to 5 classes or so and the total code size by a significant amount while improving clarity. As an API to Monticello, Gofer is very nice and we should standardize on it. But as a "replacement" for Installer it's not even in the same ballpark. Cheers, - Andreas

Dec. 15, 2010

Re: [Pharo-project] [squeak-dev] Re: Gofer versus Installer

by Igor Stasenko

On 15 December 2010 17:46, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 12/15/2010 6:27 AM, Janko MivÅ¡ek wrote: >> >> What if someone: >> >> Â 1. adds to Gofer loading from SqueakMap and other >> Â 2. then Lukas is kindly asked to rename it to the Installer. >> >> That way we will have a maintained installer with a meaningful name and >> everyone will be happy. Because we really need one and only one >> installer for both Squeak and Pharo. > > Slightly wrong. Gofer isn't an installer. Gofer is the API for Monticello. > If you wanted to rename it you should rename it simply to "Monticello" and > merge it with the MC core packages. > +1 just had the same impression. Gofer looks like a fine-shaped MC frontend. > Cheers, > Â - Andreas -- Best regards, Igor Stasenko AKA sig.

Dec. 15, 2010

Re: [Pharo-project] [squeak-dev] Gofer versus Installer

by Chris Muller

I think my suggestion would be more palatable to folks concerned about tidiness: - Strip Installer of all features that can be handled by Gofer. - Make Installer USE Gofer for those things that Gofer does (Monticello packages). - That way folks like Miguel can have only Gofer loaded, old fogies like me can have Installer+Gofer loaded. One question that came to my mind last night: What does > 1000 lines of Gofer code bring to Monticello-loading that I can't already do with just Monticello? or with a couple of facade methods added to plain MC? 2010/12/15 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Hi guys, > > Cross posted to Squeak and Pharo. > > On 14. 12. 2010 22:56, Ken G. Brown wrote: > >>> Lukas maintains Gofer >>> and there are reasons to use it: closer relationship with Pharo, contemporary MC integration (Metacello). >> >> I can accept using Gofer in trunk, for things that require it like reading it's own scripts. >> But I don't want to see Installer go away... because of all the things Installer does that Gofer doesn't. > > What if someone: > > Â 1. adds to Gofer loading from SqueakMap and other > Â 2. then Lukas is kindly asked to rename it to the Installer. > > That way we will have a maintained installer with a meaningful name and > everyone will be happy. Because we really need one and only one > installer for both Squeak and Pharo. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

Dec. 15, 2010

[Pharo-project] Issue 3439 in pharo: Compiler error 'subscript is out of bounds: ...'

by pharo＠googlecode.com

Status: Accepted Owner: adrian.lienhard New issue 3439 by adrian.lienhard: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Evaluating the expression Object compile: 'self foo. [' yields an error 'subscript is out of bounds: 12' instead of a syntax error like 'self foo. [Period or right bracket expected ->'. This is broken in 1.1.1 and 1.2. In Parser>>#expected:, the hereMark is larger than the size of the source, which leads to a subsequent error when creating a syntax error notification.

Dec. 15, 2010

Re: [Pharo-project] TextLint question

by Alexandre Bergel

A cheap solution is to adjust the indexes according to the number of backslash key and non-backslash key that one press. Alexandre On 15 Dec 2010, at 13:35, Fabrizio Perin wrote: > Hi Alex, > well the text index is calculated when you run the rules so of course if you touch the text than the indexes are not precise anymore. When you accept the text is saved and the rules are recalculated so also the positions of the errors are calculated again. > > Unfortunately i don't have a nice solution for this problem. One way could be: > - when you save instead running the rules you just save the modified document. > - than all the indexes of all the errors are update with the difference in size between the old and the new document. > > I don't know if this is going to be faster than simply re-run the rules. Anyway I will give it a try and i will let you know. > > Cheers, > > Fabrizio > > > 2010/12/15 Alexandre Bergel <alexandre(a)bergel.eu> > hi! > > I am now using TextLint over my submissions. Each time I modify the text, the rest of the errors have a wrong text index. It makes it difficult to use. > I do an accept, to save my .tex and run the rules again, but it takes time... > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 15, 2010

Re: [Pharo-project] Gofer versus Installer

by Andreas Raab

On 12/15/2010 6:27 AM, Janko MivÅ¡ek wrote: > What if someone: > > 1. adds to Gofer loading from SqueakMap and other > 2. then Lukas is kindly asked to rename it to the Installer. > > That way we will have a maintained installer with a meaningful name and > everyone will be happy. Because we really need one and only one > installer for both Squeak and Pharo. Slightly wrong. Gofer isn't an installer. Gofer is the API for Monticello. If you wanted to rename it you should rename it simply to "Monticello" and merge it with the MC core packages. Cheers, - Andreas

Dec. 15, 2010