- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Loading of Baselines from GitHub in Metacello using pattern matching not working on Windows

by Dale Henrichs

Gabriel, Are you using the latest version of Metacello from github (these instructions work for versions 3.0 and newer[1])? The pattern matching feature is relatively new so unless you've loaded from github, you are likely not getting the needed support ... I think that Pharo5.0 should be built with the latest Metacello drop from github ... but it must not be happening yet .... Dale [1] https://github.com/dalehenrich/metacello-work#pharo30 On 10/26/2015 04:37 PM, Gabriel Cotelli wrote: > When trying to load a baseline using the Metacello API and version > pattern matching, using the gituhb:// scheme produces an error because > it's trying to create a directory with a question mark (?). > > To reproduce try in a Pharo4/5 image: > > Metacello new > baseline: 'RenoirSt'; > repository: 'github://gcotelli/RenoirSt:v1.?/source'; > load. > > Dale, Is this supposed to work? Tomorrow I will give it a try on Linux. > > Thanks, > Gabriel

Oct. 27, 2015

Loading of Baselines from GitHub in Metacello using pattern matching not working on Windows

by Gabriel Cotelli

When trying to load a baseline using the Metacello API and version pattern matching, using the gituhb:// scheme produces an error because it's trying to create a directory with a question mark (?). To reproduce try in a Pharo4/5 image: Metacello new baseline: 'RenoirSt'; repository: 'github://gcotelli/RenoirSt:v1.?/source'; load. Dale, Is this supposed to work? Tomorrow I will give it a try on Linux. Thanks, Gabriel

Oct. 26, 2015

Re: [Pharo-dev] feedback from J Brant

by stepharo

Thanks!!! Le 26/10/15 12:07, Nicolai Hess a Ã©crit : > > > 2015-09-02 20:28 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > here is some feedback from John. I share it with you. > > > On 02 Sep 2015, at 16:05, John Brant <brant(a)refactoryworkers.com> > <mailto:brant@refactoryworkers.com> wrote: > > I've been writing some automated scripts to port SmaCC to Pharo. I > have it where I can file in the Dolphin .pac files directly into a > Pharo 5 image. Most things are working, but I've had to fight some > Pharo issues. Since I wasn't sure who should be notified, I > thought I'd complain to you :) > > > :) if you would see my list of complaints about Pharo you > would laugh a lot because it is huge and diverse. > I put thierry on CC because he is the guy maintaining and > using SmaCC a lot. > So may be you can help each others. > > > *) The BIConfigurableFormatter (aka RBConfigurableFormatter) sends > #asString to nodes. First, it should format the node if it wants > them formatted instead of relying on asString to return a > formatted string. Second, by sending #asString, formatting has > become exponential in the nesting level of blocks. For example, > Dolphin Smalltalk runs this in 4 milliseconds: > > | stream | > stream := WriteStream on: String new. > stream nextPutAll: 'foo ^true and: '. > 40 timesRepeat: [stream nextPutAll: '[true and: ']. > stream nextPutAll: 'false'. > 40 timesRepeat: [stream nextPut: $]]. > (RBParser parseMethod: stream contents) formattedCode > > I'm guessing that Pharo wouldn't finish in a day... It takes over > 4 seconds to format 16 nested blocks. > > Thanks indeed we will fix it. > https://pharo.fogbugz.com/f/cases/16462/BIConfigurableFormatter-should-not-… > > > > > finally (integrated in 50406) > > [ | stream | > stream := WriteStream on: String new. > stream nextPutAll: 'foo ^true and: '. > 40 timesRepeat: [stream nextPutAll: '[true and: ']. > stream nextPutAll: 'false'. > 40 timesRepeat: [stream nextPut: $]]. > (RBParser parseMethod: stream contents) formattedCode] timeToRun > " ---> 0:00:00:00.005" > > > *) Also on the formatter, its default doesn't appear to be > compliant with Kent's blocks should look like > blocks/rectangles/box rule. The way I interpret the rule is that > if I draw a rectangle around everything in the block including the > brackets, it should not include any text of anything outside of > the block. For example, this would fail that test: > > surroundedBy: aString > ^ self class > streamContents: [ :s | > s nextPutAll: aString. > s nextPutAll: self. > s nextPutAll: aString ] > > yes > > > Since the block starts at the end of the #streamContents: line, a > rectangle around all the contents in the block contains part of > the #streamContents: selector which isn't part of the block. > > I do not really like all the formattings of kent. Because > sometimes it just does not work. > But this is why we ask franck (an interns to start to have a > look). > > For example I do not like > > self xxx > ifTrue: > [ > self bla > self foo. > > in the current default formatter. > and I prefer > > self xxx > ifTrue: [ self bla. > self foo > But here the problem is that the self foo is not tab > aligned because ifTrue: [ > > self xxx > ifTrue: > [ self bla. > self foo > > So may be this one is a nice compromise > I think that we should change some settings. In fact in alpha > things are there to evolve until the release :) > > > > *) If I fileout a package, it doesn't fileout the metaclass > extension methods. The RPackage>>fileOut method needs to be > updated with the metaclassExtensionSelectors. > > Oops this is a bug. > Do you mean what I mean? the extensions done by the package on > metaclass that are not in the package. > > https://pharo.fogbugz.com/f/cases/16460/I-fileout-a-package-does-not-fileou… > > > > *) On windows, it appears that while the menus say Ctrl+..., they > really mean Ctrl+... or Alt+... -- you figure it out. > > Yes it sucks. We are in flux with the key essentially because > the VM often does not even gives us the correct information. > With the new OSWindow architecture we are putting in place we > will have all the events and not just the one the VM does not > eat (like shift pressed) > and we can manage all at the image level not deep into arcane > and old C- code. > > > *) It appears that Pharo is removing subString: in favor of > substring:. The ANSI standard defines subString:. > > I was not aware of it. In fact ANSI is bad and totally > incomplete (for example we studies strings and this is a mess > and totally incomplete). > Now we should probably add it. I will send the mail to the > mailing-list and let people decide. > > > > > *) The ChunkFileFormatParser>>parseNextDeclaration is hard coded > to handle only the Pharo format: > | substrings | > substrings := nextChunk parseLiterals. > (substrings includes: 'methodsFor:') > ifTrue: [ ^self parseMethodDeclarations: substrings ]. > (substrings includes: 'commentStamp:') > ifTrue: [ ^self parseCommentDeclaration: substrings ]. > (substrings includes: 'reorganize') > ifTrue: [ ^self parseClassOrganization: substrings ]. > Due to the hard coded nature of the types of strings accepted, I > have to overwrite this method to be able to file in Dolphin code. > In the other Smalltalk's, I can write an extension method or two > that I use to file in another dialect's code. > > https://pharo.fogbugz.com/f/cases/16461/ChunkFileParser > > If you have a solution please send it. Because we are focusing > on the bootstrap and spur the new object format plus a new > FFI. Plus a lot more. > So this keeps us really busy and many people left the team and > we are restarting to teach :) > > I personally hate this format and the hardcoding of these > strings and selectors everywhere so this is why the > ChunkFileFormatParser is already > a big step forward. > > > > I have several other things that annoy me, > > me too :) > But I tried that every couple of days I fix one. > > > but this is enough for now. :) > > Tx john :) > > > > John Brant > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > 03 59 57 78 50 > 03 59 35 86 16 > > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Oct. 26, 2015

Re: [Pharo-dev] feedback from J Brant

by Nicolai Hess

2015-09-02 20:28 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > here is some feedback from John. I share it with you. > > > On 02 Sep 2015, at 16:05, John Brant <brant(a)refactoryworkers.com> > <brant(a)refactoryworkers.com> wrote: > > I've been writing some automated scripts to port SmaCC to Pharo. I have it > where I can file in the Dolphin .pac files directly into a Pharo 5 image. > Most things are working, but I've had to fight some Pharo issues. Since I > wasn't sure who should be notified, I thought I'd complain to you :) > > > :) if you would see my list of complaints about Pharo you would laugh a > lot because it is huge and diverse. > I put thierry on CC because he is the guy maintaining and using SmaCC a > lot. > So may be you can help each others. > > > *) The BIConfigurableFormatter (aka RBConfigurableFormatter) sends > #asString to nodes. First, it should format the node if it wants them > formatted instead of relying on asString to return a formatted string. > Second, by sending #asString, formatting has become exponential in the > nesting level of blocks. For example, Dolphin Smalltalk runs this in 4 > milliseconds: > > | stream | > stream := WriteStream on: String new. > stream nextPutAll: 'foo ^true and: '. > 40 timesRepeat: [stream nextPutAll: '[true and: ']. > stream nextPutAll: 'false'. > 40 timesRepeat: [stream nextPut: $]]. > (RBParser parseMethod: stream contents) formattedCode > > I'm guessing that Pharo wouldn't finish in a day... It takes over 4 > seconds to format 16 nested blocks. > > Thanks indeed we will fix it. > > https://pharo.fogbugz.com/f/cases/16462/BIConfigurableFormatter-should-not-… > > > finally (integrated in 50406) [ | stream | stream := WriteStream on: String new. stream nextPutAll: 'foo ^true and: '. 40 timesRepeat: [stream nextPutAll: '[true and: ']. stream nextPutAll: 'false'. 40 timesRepeat: [stream nextPut: $]]. (RBParser parseMethod: stream contents) formattedCode] timeToRun " ---> 0:00:00:00.005" > > *) Also on the formatter, its default doesn't appear to be compliant with > Kent's blocks should look like blocks/rectangles/box rule. The way I > interpret the rule is that if I draw a rectangle around everything in the > block including the brackets, it should not include any text of anything > outside of the block. For example, this would fail that test: > > surroundedBy: aString > ^ self class > streamContents: [ :s | > s nextPutAll: aString. > s nextPutAll: self. > s nextPutAll: aString ] > > yes > > > Since the block starts at the end of the #streamContents: line, a > rectangle around all the contents in the block contains part of the > #streamContents: selector which isn't part of the block. > > I do not really like all the formattings of kent. Because sometimes it > just does not work. > But this is why we ask franck (an interns to start to have a look). > > For example I do not like > > self xxx > ifTrue: > [ > self bla > self foo. > > in the current default formatter. > and I prefer > > self xxx > ifTrue: [ self bla. > self foo > But here the problem is that the self foo is not tab aligned because > ifTrue: [ > > self xxx > ifTrue: > [ self bla. > self foo > > So may be this one is a nice compromise > I think that we should change some settings. In fact in alpha things are > there to evolve until the release :) > > > > *) If I fileout a package, it doesn't fileout the metaclass extension > methods. The RPackage>>fileOut method needs to be updated with the > metaclassExtensionSelectors. > > Oops this is a bug. > Do you mean what I mean? the extensions done by the package on metaclass > that are not in the package. > > > https://pharo.fogbugz.com/f/cases/16460/I-fileout-a-package-does-not-fileou… > > > > *) On windows, it appears that while the menus say Ctrl+..., they really > mean Ctrl+... or Alt+... -- you figure it out. > > Yes it sucks. We are in flux with the key essentially because the VM often > does not even gives us the correct information. > With the new OSWindow architecture we are putting in place we will have > all the events and not just the one the VM does not eat (like shift pressed) > and we can manage all at the image level not deep into arcane and old C- > code. > > > *) It appears that Pharo is removing subString: in favor of substring:. > The ANSI standard defines subString:. > > I was not aware of it. In fact ANSI is bad and totally incomplete (for > example we studies strings and this is a mess and totally incomplete). > Now we should probably add it. I will send the mail to the mailing-list > and let people decide. > > > > > *) The ChunkFileFormatParser>>parseNextDeclaration is hard coded to handle > only the Pharo format: > | substrings | > substrings := nextChunk parseLiterals. > (substrings includes: 'methodsFor:') > ifTrue: [ ^self parseMethodDeclarations: substrings ]. > (substrings includes: 'commentStamp:') > ifTrue: [ ^self parseCommentDeclaration: substrings ]. > (substrings includes: 'reorganize') > ifTrue: [ ^self parseClassOrganization: substrings ]. > Due to the hard coded nature of the types of strings accepted, I have to > overwrite this method to be able to file in Dolphin code. In the other > Smalltalk's, I can write an extension method or two that I use to file in > another dialect's code. > > https://pharo.fogbugz.com/f/cases/16461/ChunkFileParser > > If you have a solution please send it. Because we are focusing on the > bootstrap and spur the new object format plus a new FFI. Plus a lot more. > So this keeps us really busy and many people left the team and we are > restarting to teach :) > > I personally hate this format and the hardcoding of these strings and > selectors everywhere so this is why the ChunkFileFormatParser is already > a big step forward. > > > > I have several other things that annoy me, > > me too :) > But I tried that every couple of days I fix one. > > > but this is enough for now. :) > > Tx john :) > > > > John Brant > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > 03 59 57 78 50 > 03 59 35 86 16 > > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Oct. 26, 2015

[pharo-project/pharo-core] c8e490: 50406

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c8e490ae15abe6d84d84663db416779793a59e76 https://github.com/pharo-project/pharo-core/commit/c8e490ae15abe6d84d84663d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-26 (Mon, 26 Oct 2015) Changed paths: M BlueInk-Core.package/BIConfigurableFormatter.class/instance/private/handleLineForArgument_.st M Collections-Strings.package/String.class/instance/formatting/expandMacrosWithArguments_.st A Collections-Tests.package/StringTest.class/instance/testing - formatting/testExpandMacros.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50405.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50406.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50405.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50406.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50406 16863 Make expandMacros more consistent with general use https://pharo.fogbugz.com/f/cases/16863 16462 BIConfigurableFormatter should not use asString https://pharo.fogbugz.com/f/cases/16462 http://files.pharo.org/image/50/50406.zip

Oct. 26, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50406 Home: https://github.com/pharo-project/pharo-core

Oct. 26, 2015

Re: [Pharo-dev] FastTable question

by Thierry Goubier

Le 26/10/2015 14:09, Esteban Lorenzano a Ã©crit : > >> On 26 Oct 2015, at 14:05, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 26/10/2015 11:37, Esteban Lorenzano a Ã©crit : >>> >>>> On 22 Oct 2015, at 09:13, Cyril Ferlicot <cyril.ferlicot(a)gmail.com >>>> <mailto:cyril.ferlicot@gmail.com>> wrote: >>>> >>>> For now >>>> >>>> On Thu, Oct 22, 2015 at 8:57 AM, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>>> Excellent >>>>> >>>>> How did you do it? >>>>> >>>> >>>> I removed the hardcode value of the default row height in order use >>>> the size of the default font. "StandardFont defaultfont pixelSize" or >>>> something like that. (Can't check now). >>>> But as Esteban said this is maybe not the best solution since a FT can >>>> store something else than a string. >>> >>> Yesâ¦ this *has* to be transmitted to the data source. Just there you >>> can know how to calculate height. >> >> I have a nagging feeling that basing FT on the knowledge of all rows >> height is not scalable for very large datasources. > > I have the same feeling, thatâs why I put it out at the first timeâ¦ at > first moment, datasource should answer a constant, not a variable size > (FT does not know what to do with them right now). > But then, is a good place to start doing experiments :) Yes, the FT core code is a very interesting base to work on. I can highly recommend what you did there :) Thierry

Oct. 26, 2015

Re: [Pharo-dev] FastTable question

by Esteban Lorenzano

> On 26 Oct 2015, at 14:05, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 26/10/2015 11:37, Esteban Lorenzano a Ã©crit : >> >>> On 22 Oct 2015, at 09:13, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >>> >>> For now >>> >>> On Thu, Oct 22, 2015 at 8:57 AM, stepharo <stepharo(a)free.fr> wrote: >>>> Excellent >>>> >>>> How did you do it? >>>> >>> >>> I removed the hardcode value of the default row height in order use >>> the size of the default font. "StandardFont defaultfont pixelSize" or >>> something like that. (Can't check now). >>> But as Esteban said this is maybe not the best solution since a FT can >>> store something else than a string. >> >> Yesâ¦ this *has* to be transmitted to the data source. Just there you can know how to calculate height. > > I have a nagging feeling that basing FT on the knowledge of all rows height is not scalable for very large datasources. I have the same feeling, thatâs why I put it out at the first timeâ¦ at first moment, datasource should answer a constant, not a variable size (FT does not know what to do with them right now). But then, is a good place to start doing experiments :) Esteban > > I'll let you try and see where you end up ;) > > Thierry

Oct. 26, 2015

Re: [Pharo-dev] FastTable question

by Thierry Goubier

Le 26/10/2015 11:37, Esteban Lorenzano a Ã©crit : > >> On 22 Oct 2015, at 09:13, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> >> For now >> >> On Thu, Oct 22, 2015 at 8:57 AM, stepharo <stepharo(a)free.fr> wrote: >>> Excellent >>> >>> How did you do it? >>> >> >> I removed the hardcode value of the default row height in order use >> the size of the default font. "StandardFont defaultfont pixelSize" or >> something like that. (Can't check now). >> But as Esteban said this is maybe not the best solution since a FT can >> store something else than a string. > > Yesâ¦ this *has* to be transmitted to the data source. Just there you can know how to calculate height. I have a nagging feeling that basing FT on the knowledge of all rows height is not scalable for very large datasources. I'll let you try and see where you end up ;) Thierry

Oct. 26, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40624 Home: https://github.com/pharo-project/pharo-core

Oct. 26, 2015