- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core] 896641: 40624

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 896641b25860fced7a3c39116a9128a702516d3a https://github.com/pharo-project/pharo-core/commit/896641b25860fced7a3c3911… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-26 (Mon, 26 Oct 2015) Changed paths: M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/-- all --/basicAsMCMethodDefinition.st M Ring-Monticello.package/extension/RGMethodDefinition/instance/basicAsMCMethodDefinition.st M ScriptLoader40.package/ScriptLoader.class/instance/-- all --/commentForCurrentUpdate.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script623.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script624.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40623.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40624.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script623.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script624.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40623.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40624.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40624 16813 Unclosed file streams https://pharo.fogbugz.com/f/cases/16813 http://files.pharo.org/image/40/40624.zip

Oct. 26, 2015

Re: [Pharo-dev] FastTable question

by Esteban Lorenzano

> On 22 Oct 2015, at 09:09, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > We will at least keep it for Synectique in order to have a widget with > an action button for now. I do not want it in the main distribution :S As we talked, for me correct way to implement such behaviour is: - Transmit to FTSearchFunction creation of search field (or filter, FTSearchFunction should be split in FTSearchFunction and FTFilterFunction in a hierarchy). - Then you can implement a child of FTFilterFunctionâ¦ like âFTActionFilterFunctionâ who adds the action buttons you want. no composed blabla! Esteban > I don't think you want an action button to be integrated inside the > FTTableMorph ? > > When we will integrate the next configuration of FT into Pharo I will > remove it from the FastTable package. > > > On Thu, Oct 22, 2015 at 8:55 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> I thought we were removing FTFastTableComposer, as is not such a great idea. >> >> Esteban >> >> > > -- > Cheers > Cyril Ferlicot >

Oct. 26, 2015

Re: [Pharo-dev] FastTable question

by Esteban Lorenzano

> 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. Esteban > > -- > Cheers > Cyril Ferlicot >

Oct. 26, 2015