- Pharo-dev - lists.pharo.org

Re: [Pharo-project] could you test the attached?

by StÃ©phane Ducasse

Thanks eliot Issue 4998: ContextPart>>#runUntilErrorOrReturnFrom: Definitively the kind of methods I want to understand. On Nov 16, 2011, at 8:58 PM, Eliot Miranda wrote: > Hi All, > > I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in a certain rare circumstance causes the method to peel back too much of the stack. This method is used in the debugger (e.g. completeStep: et al) but also in Process termination. So it is right at the heart of the system. I'm loath to simply commit it I'd really appreciate y'all testing with the fix and reporting any changes you see. It does not affect the trunk test suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart form that no observed effects). So, brave souls, please try with the attached and see if you come to grief or not. > -- > thanks, > Eliot > > <ContextPart-runUntilErrorOrReturnFrom.st>

Nov. 16, 2011

Re: [Pharo-project] pharo-xmlrpc samples fail in Pharo 1.3

by StÃ©phane Ducasse

German Can you have a look? Stef On Nov 15, 2011, at 1:16 PM, seamus wrote: > Hi all > > Just wondering what to do next. > I need a working xmlrpc library for a project I am working on but the latest > version of pharo-xmlrpc fails due to a DoesNotUnderstand #contentString > error. This is just testing the samples provided as below: > > | url proxy r | > > url := Url absoluteFromText: 'http://snipplr.com/xml-rpc.php'. > proxy := XMLRPCProxy new url: url. > > r := proxy invokeMethod: 'languages.list' withArgs: #('Your snipplr key'). > > r := proxy invokeMethod: 'user.checkkey' withArgs: #('Your snipplr key'). > r := proxy invokeMethod: 'snippet.list' withArgs: #('Your snipplr key' > 'pharo'). > > "To get a snippet you don't need key, but the Snippet ID" > r := proxy invokeMethod: 'snippet.get' withArgs: #('41365'). > > Any ideas to get this working? I see that someone mentioned that this may be > a missing method in the Dictionary object. > > Regards > > Seamus > > -- > View this message in context: http://forum.world.st/pharo-xmlrpc-samples-fail-in-Pharo-1-3-tp4042738p4042… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 16, 2011

Re: [Pharo-project] WideString performance

by Nicolas Cellier

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 >

Nov. 16, 2011

[Pharo-project] [update 1.4] #14227

by Marcus Denker

14227 ----- Issue 4976: MessageNotUnderstood: SolidFillStyle>>addFillStyleMenuItems:hand:from: http://code.google.com/p/pharo/issues/detail?id=4976 Issue 4972: NullStream breaks the debugger http://code.google.com/p/pharo/issues/detail?id=4972 -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

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

by Igor Stasenko

On 16 November 2011 09:30, 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. > Well, a more general question is does pharo supports unicode input/output: in general yes, but there could be some tweaks needed. For displaying chinese glyphs, first thing you need is to have a font with them, obviously. So, i would try first with changing font, and then see if there are more problems. > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > -- Best regards, Igor Stasenko.

Nov. 16, 2011

[Pharo-project] could you test the attached?

by Eliot Miranda

Hi All, I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in a certain rare circumstance causes the method to peel back too much of the stack. This method is used in the debugger (e.g. completeStep: et al) but also in Process termination. So it is right at the heart of the system. I'm loath to simply commit it I'd really appreciate y'all testing with the fix and reporting any changes you see. It does not affect the trunk test suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart form that no observed effects). So, brave souls, please try with the attached and see if you come to grief or not. -- thanks, Eliot

Nov. 16, 2011

[Pharo-project] [ANN] BSUG Meeting Monday November 21, 2011

by Sven Van Caekenberghe

Hi, The Belgian Smalltalk User Group (BSUG) is organizing its next meeting Monday, November 21, 2011, at the premises of MediaGeniX (Brussels). 18h00 Welcome 18h30 Pizza & drinks sponsored by MediaGeniX 19h00 Talks * Continuous integration - A practical approach (MaÃ¯kel Vandorpe) * Gemstone Smalltalk - A hands-on introduction (Johan Brichau) Remember to confirm your attendance to johan<AT>inceptive<DOT>be (preferably asap, and at least before Saturday 19th). for BSUG, Sven http://www.bsug.org

Nov. 16, 2011

Re: [Pharo-project] WideString performance

by Sven Van Caekenberghe

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

Nov. 16, 2011

Re: [Pharo-project] About Zinc API

by Sven Van Caekenberghe

Hi Esteban, On 16 Nov 2011, at 13:30, Esteban Lorenzano wrote: > I just updated my Zinc related projects to the latest version. This is a cool piece of software and I'm really enjoying using it! Thank you! Glad you like it ! That is why I put in all this effort. > but now... just an observation: I really don't like the ZnEasy facade :( > why? because it feels "overdesigned" for me: I think those methods should be on ZnNeoClient directly... of course, that's because you want to prevent a change in the api if something changes in the future... but I think precisely there is where you are overdesigning the framework. > Other thing: ZnNeoClient should be just ZnClient in next versions.... > > yeah... maybe I'm just talking too early and you are already thinking on do that... or maybe I'm just wrong... just wanted to say my impressions about something I think is, in general, really great and a really cool improvement over what we had before. The rename ZnNeoClient -> ZnClient was done in Zinc-HTTP-SvenVanCaekenberghe.218, the current version is Zinc-HTTP-SvenVanCaekenberghe.220 ;-) ZnEasy is a very simple, quick & dirty, one-shot API that is actually too 'thin' to expose/capture the full complexity of HTTP. ZnClient is a much better interface IMHO, based on some of the earlier clients that were in Zn (and that are now deprecated). Please have another look and tell use what you think or what your issues are. Sven

Nov. 16, 2011

[Pharo-project] WideString performance

by Dennis Schetinin

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

Nov. 16, 2011