November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SystemChangeNotifier and Traits

by Igor Stasenko

On 16 November 2011 23:47, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Nov 16, 2011 at 1:14 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> + 1 >> >> and we should remove the old ones and a lot of old abstraction >> Â Â Â Â MethodReference, >> Â Â Â Â PseudoClass, FilePackage, and a lot more >> I hope that we will get into that mode soon. > > Â Â PseudoClass, FilePackage, may indeed be poor. Â But IMO MethodReference is > central and extremely useful. Yes. There's already a replacement for it in Ring model. >> >> Stef >> >> On Nov 16, 2011, at 3:55 PM, Fernando Olivero wrote: >> >> > Please note that eventually the system is going to be using solely >> > System announcements, instead of the old mechanism in place right now. >> > >> > Did you try hooking up to the SystemAnnouncements? >> > >> > For examples, check out Nautius. >> > >> > Fernando >> > >> > >> > >> > On Tue, Nov 15, 2011 at 9:02 PM, ezequiel lamonica >> > <lamonicaezequiel(a)gmail.com> wrote: >> >> Hello again, >> >> >> >> Now the problem is when I create a class that use Traits, >> >> SystemChangeNotifier sends two messages to report this creation: 1st >> >> for >> >> class added without traits, and 2nd for class modified to use this >> >> trait. >> >> And this last message has Object as old class instead of >> >> ClassForTesting >> >> without traits. >> >> >> >> For example: >> >> >> >> Object subclass: #ClassForTesting >> >> Â Â Â Â uses: TSortable >> >> Â Â Â Â instanceVariableNames: 'a' >> >> Â Â Â Â classVariableNames: '' >> >> Â Â Â Â poolDictionaries: '' >> >> Â Â Â Â category: 'OOSCM-ClientImageTest' >> >> >> >> >> >> Can I change those messages to use only one message that includes >> >> traits? Is >> >> not this better? >> >> >> >> What do you suggest? >> >> >> >> >> >> >> >> ----- >> >> eze >> >> -- >> >> View this message in context: >> >> http://forum.world.st/SystemChangeNotifier-and-Traits-tp4073962p4073962.html >> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> >> >> > >> >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Dennis Schetinin

So, the answer for the question "Is there a simple way to improve the performance?" would be "No", right? 2011/11/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > I think that there are several issues: > > 1) Character with codePoint < 256 are unique, but Wider are not. > The characters are not stored in the WideString (which instead stores > the code points), but any enumeration using at: rather than wordAt: > will create an overhead. I presume that it would be better to have a > #codePointAt: defined as #byteAt: in ByteString and #wordAt: in > WideString, so we could still define generic methods in String. > 2) A lot of ByteString methods are optimized with ad hoc optional > primitives, but very few WideString methods are. > 3) Some of these optimized operations work with 256 element masks and > cannot be generalized to WideString that easily > 4) Some Stream operations that copy one Collection to the stream > buffer or vice versa are also not optimized for mixed byte/word > collections > 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters > also are (because they can use more primitives in this case) > 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe > questionable from quality POV, but were not replaced from efficiency > POV. > > I would say that a new VM with immediate Character values might help, > but that won't be enough. > > Nicolas > > 2011/11/16 Sven Van Caekenberghe <sven(a)beta9.be>: > > Dennis, > > > > On 16 Nov 2011, at 19:30, Dennis Schetinin wrote: > > > >> Hi! > >> > >> Parsing a UTF-8 CSV file with Russian symbols (using CSVParser), I > found it really slow. It takes about 5 seconds to read a 53Kb file (136 > lines) and several minutes to parse a 3.4Mb file (about 8K lines). > >> > >> Profiler shows that nearly all the time is eaten by WideString >> > at:put: which is invoked from WriteStream>>nextPut:. If I'm not mistaken, > this means that <primitive: 66> there does not work in this caseâ¦ So, to be > short: is there a simple way to improve the performance? TIA > >> > >> -- > >> Dennis Schetinin > > > > I am interested in this problem. > > > > Would it be possible to provide a test file (not that I can read > Russian) and your test code ? > > > > I would like to try this myself. > > > > Sven > > > > -- Dennis Schetinin

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Dennis Schetinin

Sure. I've loaded CSVParser from http://www.squeaksource.com/CSVParser.html and patched one method there: nextRow | row | row := OrderedCollection new. stream skipSeparators. [self atEndOfLine] whileFalse: [row add: self nextValue]. *"stream skip: -1."* stream next = $, ifTrue: [row add: '']. ^ row This is how I test it: stream := FileStream readOnlyFileNamed: 'Data.csv'. [(CSVParser on: stream) useDelimiter: $;; rows ] ensure: [stream close]. I attach the bigger data file. The shorter one can be produced by deleting rows. 2011/11/16 Sven Van Caekenberghe <sven(a)beta9.be> > Dennis, > > On 16 Nov 2011, at 19:30, Dennis Schetinin wrote: > > > Hi! > > > > Parsing a UTF-8 CSV file with Russian symbols (using CSVParser), I found > it really slow. It takes about 5 seconds to read a 53Kb file (136 lines) > and several minutes to parse a 3.4Mb file (about 8K lines). > > > > Profiler shows that nearly all the time is eaten by WideString >> > at:put: which is invoked from WriteStream>>nextPut:. If I'm not mistaken, > this means that <primitive: 66> there does not work in this caseâ¦ So, to be > short: is there a simple way to improve the performance? TIA > > > > -- > > Dennis Schetinin > > I am interested in this problem. > > Would it be possible to provide a test file (not that I can read Russian) > and your test code ? > > I would like to try this myself. > > Sven > -- Dennis Schetinin

Nov. 17, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Sean P. DeNigris

Tudor Girba wrote: > > The WeakAnnouncement are already on the agenda for 1.3. > Bump... What is the status of this? Also, what are people doing in the mean time? I don't see a way to safely use Announcements without automatic unsubscribing. I have not found a hook in Morphic that's guaranteed to be called. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4078804.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 17, 2011

Re: [Pharo-project] Can we display and input chinese?

by Serge Stinckwich

Hi Hilaire, there is two chinese Squeak mailing-lists : - http://groups.google.com/group/chinesesqueak - http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-cn The second one seems dead. Maybe you can ask your question here. Regards, On Wed, Nov 16, 2011 at 4:30 PM, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: > Hello > > A friend of me in Taiwan ask me about that because previous version of > DrGeo used to work with Chinese display and input. > > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 17, 2011

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>>> Does Toolbuilder make sense? To me it looked like yet another compatibility >>> layer that does not bring anything (other than forcing anyone to use something >>> that has to be compabtible to MVC). >> >> It is quite powerful given that it can run OmniBrowser. > > Of course Omnibrowser makes it easy by not allowing anything else than what is > in MVC (e.g, Trees). For sake of correctness: ToolBuilder supports trees since at least Squeak 3.9, but probably earlier. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

On Nov 16, 2011, at 7:09 PM, Lukas Renggli wrote: >>>> where? >>>> Because we removed it. >>> >>> It is contained in the Polymorph packages in Pharo 1.3, but it missing >>> some and has additional other features compared to the version in >>> Squeak. >>> >>> I was asking because OmniBrowser in Squeak is now using ToolBuilder, >>> the code works with a few changes in Pharo 1.3 too. >> >> Does Toolbuilder make sense? To me it looked like yet another compatibility >> layer that does not bring anything (other than forcing anyone to use something >> that has to be compabtible to MVC). > > It is quite powerful given that it can run OmniBrowser. Of course Omnibrowser makes it easy by not allowing anything else than what is in MVC (e.g, Trees). > And the extra > layer makes UI building trivially testable. This is not possible when > directly using Morphs. > What we need is a seperation between Morph and the Widgets on top of Morphic. This than will likely include some layer, too. But keeping Toolbuilder if you have no MVC and Tweak is not really useful. > For Pharo I will rewrite the OB UI builder to directly generate an > optimized Polymorph GUI. This buys more us more flexibility. > .. like trees. -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Eliot Miranda

On Wed, Nov 16, 2011 at 2:13 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > > > In general it abstracts away the specific UI used to present a tool and > I'd say that was generally useful. Anyone wanting to experiment with a > novel UI could benefit from ToolBuilder. In Squeak trunk there's even the > ability to test it against Morphic and MVC. MVC is still useful for those > trying to build minimal images. > > > MVC was removed in Pharo in 1.1... > Thta's not the point. ToolBuilder has backends for Morphic and MVC but one could add e.g. a backend for a native window/widget set, etc. The point is that it abstracts away from the specific widget/window set used to build a tool allowing one to experiment and evolve the system. > > Why not make Morphic compact instead of keeping MVC? There is quite a lot > of code everywhere in Squeak > dealing with MVC compatibility.. very hard to clean up anything. E.g we > removed Paragraph... and merged > all multiple Paragraph classes of Morphic into one (called, ahh... > Paragraph). > > E.g. getting a new Canvas would for shure be much harder if we would have > kept MVC. > > > I've found ToolBuilder useful for constructing new UIs, editing > > existing ones and being able to follow actions without needing to know > > much about about Morphic. > > Why not make Morphic easy to use instead? Wasn't it supposed to be easy? > That's not the alternative, nor is it the rationale for ToolBuilder. A compact, easy-to-understand Morphic is orthogonal to the utility of ToolBuilder. > > Marcus > > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

> > In general it abstracts away the specific UI used to present a tool and I'd say that was generally useful. Anyone wanting to experiment with a novel UI could benefit from ToolBuilder. In Squeak trunk there's even the ability to test it against Morphic and MVC. MVC is still useful for those trying to build minimal images. > MVC was removed in Pharo in 1.1... Why not make Morphic compact instead of keeping MVC? There is quite a lot of code everywhere in Squeak dealing with MVC compatibility.. very hard to clean up anything. E.g we removed Paragraph... and merged all multiple Paragraph classes of Morphic into one (called, ahh... Paragraph). E.g. getting a new Canvas would for shure be much harder if we would have kept MVC. > I've found ToolBuilder useful for constructing new UIs, editing > existing ones and being able to follow actions without needing to know > much about about Morphic. Why not make Morphic easy to use instead? Wasn't it supposed to be easy? Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>>> where? >>> Because we removed it. >> >> It is contained in the Polymorph packages in Pharo 1.3, but it missing >> some and has additional other features compared to the version in >> Squeak. >> >> I was asking because OmniBrowser in Squeak is now using ToolBuilder, >> the code works with a few changes in Pharo 1.3 too. > > Does Toolbuilder make sense? To me it looked like yet another compatibility > layer that does not bring anything (other than forcing anyone to use something > that has to be compabtible to MVC). It is quite powerful given that it can run OmniBrowser. And the extra layer makes UI building trivially testable. This is not possible when directly using Morphs. For Pharo I will rewrite the OB UI builder to directly generate an optimized Polymorph GUI. This buys more us more flexibility. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011