- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] Re: html parser

by stephane ducasse

Thanks for the pointer I should also have a look. Are there tests/comments? > >> Soup ? >> http://www.squeaksource.com/Soup > > This one is good. > > http://www.squeaksource.com/htmlcssparser > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

Jan. 16, 2011

[Pharo-project] Crash running test suite with latest cog vm

by Marco Schmidt

I have a crashing cog vm. I run the all tests in the current pharo-core downloaded from the server. See attached PharoDebug.log Marco Schmidt

Jan. 16, 2011

Re: [Pharo-project] XML packages, CDATA and encoding

by StÃ©phane Ducasse

I created http://code.google.com/p/pharo/issues/detail?id=3541 to avoid to forget. Stef On Jan 16, 2011, at 3:09 AM, jaayer wrote: > > Sorry, I accidentally hit reply before typing anything. > > Torsten, what you are trying to do is not incorrect and should work as you expected it to. The reason why it didn't has less to do with XMLSupport per se and more to do with its reliance on Pharo's TextConverter system. The problem is faulty matching of the "encoding" attribute value to the appropriate subclass of TextConverter. The code responsible for this in XMLSupport is: > converterClass := > (Smalltalk > at: #TextConverter > ifAbsent: [^ self]) > defaultConverterClassForEncoding: anEncodingName asLowercase. > > But as you can see, the matching is actually done by TextConverter and its class-side #defaultConverterClassForEncoding: method, which works by sending #encodingNames to all subclasses and testing the array returned to see if it includes the specified encoding name. If you browse Latin1TextConverter, the right class for the encoding you specified, and look at its #encodingNames message, you will see the array it returns does not include "ISO-8859-1": > ^ #('latin-1' 'latin1') copy. > > Change it to this (note the lowercase): > ^ #('latin-1' 'latin1' 'iso-8859-1') copy. > > and everything now works. > > So this is really a bug in TextConverter and its Latin1TextConverter subclass, not XMLSupport. Also, the #allSubclassesDo: test in #defaultConverterClassForEncoding: should probably be augmented with a Dictionary cache to speed-up lookups for known encoding-converter pairs. Can someone forward this message to whoever maintains TextConverter? > > ---- On Mon, 10 Jan 2011 04:38:23 -0800 Torsten Bergmann wrote ---- > >> Create a file "test.xml" with the following >> contents (german umlaut): >> >> >> >> >> >> After loading ConfigurationOfXML try to parse it: >> >> |fs| >> fs := FileStream fileNamed: 'test.xml'. >> XMLDOMParser parseDocumentFrom: fs. >> >> >> => gives an error: 'Invalid utf8 input detected' >> => it works if you remove the CDATA section >> >> Looks like UTF8TextConverter is used independent >> from the encoding of the XML... >> >> Bye >> T. >> -- >> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >> Jetzt informieren: http://www.gmx.net/de/go/freephone >> >> > >

Jan. 16, 2011

[Pharo-project] Issue 3541 in pharo: TextConverter should take into account iso

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3541 by stephane...(a)gmail.com: TextConverter should take into account iso http://code.google.com/p/pharo/issues/detail?id=3541 After loading ConfigurationOfXML try to parse it: |fs| fs := FileStream fileNamed: 'test.xml'. XMLDOMParser parseDocumentFrom: fs. => gives an error: 'Invalid utf8 input detected' => it works if you remove the CDATA section Looks like UTF8TextConverter is used independent from the encoding of the XML... -------------- Torsten, what you are trying to do is not incorrect and should work as you expected it to. The reason why it didn't has less to do with XMLSupport per se and more to do with its reliance on Pharo's TextConverter system. The problem is faulty matching of the "encoding" attribute value to the appropriate subclass of TextConverter. The code responsible for this in XMLSupport is: converterClass := (Smalltalk at: #TextConverter ifAbsent: [^ self]) defaultConverterClassForEncoding: anEncodingName asLowercase. But as you can see, the matching is actually done by TextConverter and its class-side #defaultConverterClassForEncoding: method, which works by sending #encodingNames to all subclasses and testing the array returned to see if it includes the specified encoding name. If you browse Latin1TextConverter, the right class for the encoding you specified, and look at its #encodingNames message, you will see the array it returns does not include "ISO-8859-1": ^ #('latin-1' 'latin1') copy. Change it to this (note the lowercase): ^ #('latin-1' 'latin1' 'iso-8859-1') copy. and everything now works. So this is really a bug in TextConverter and its Latin1TextConverter subclass, not XMLSupport. Also, the #allSubclassesDo: test in #defaultConverterClassForEncoding: should probably be augmented with a Dictionary cache to speed-up lookups for known encoding-converter pairs. Can someone forward this message to whoever maintains TextConverter?

Jan. 16, 2011

Re: [Pharo-project] XML packages, CDATA and encoding

by StÃ©phane Ducasse

Hi jaayer > Sorry, I accidentally hit reply before typing anything. no problem :) > > Torsten, what you are trying to do is not incorrect and should work as you expected it to. The reason why it didn't has less to do with XMLSupport per se and more to do with its reliance on Pharo's TextConverter system. The problem is faulty matching of the "encoding" attribute value to the appropriate subclass of TextConverter. The code responsible for this in XMLSupport is: > converterClass := > (Smalltalk > at: #TextConverter > ifAbsent: [^ self]) > defaultConverterClassForEncoding: anEncodingName asLowercase. > > But as you can see, the matching is actually done by TextConverter and its class-side #defaultConverterClassForEncoding: method, which works by sending #encodingNames to all subclasses and testing the array returned to see if it includes the specified encoding name. If you browse Latin1TextConverter, the right class for the encoding you specified, and look at its #encodingNames message, you will see the array it returns does not include "ISO-8859-1": > ^ #('latin-1' 'latin1') copy. > > Change it to this (note the lowercase): > ^ #('latin-1' 'latin1' 'iso-8859-1') copy. > > and everything now works. > > So this is really a bug in TextConverter and its Latin1TextConverter subclass, not XMLSupport. Also, the #allSubclassesDo: test in #defaultConverterClassForEncoding: should probably be augmented with a Dictionary cache to speed-up lookups for known encoding-converter pairs. Can someone forward this message to whoever maintains TextConverter? nobody maintain TextConverter. If you have some fixes I would be really glad to integrate them. > > ---- On Mon, 10 Jan 2011 04:38:23 -0800 Torsten Bergmann wrote ---- > >> Create a file "test.xml" with the following >> contents (german umlaut): >> >> >> >> >> >> After loading ConfigurationOfXML try to parse it: >> >> |fs| >> fs := FileStream fileNamed: 'test.xml'. >> XMLDOMParser parseDocumentFrom: fs. >> >> >> => gives an error: 'Invalid utf8 input detected' >> => it works if you remove the CDATA section >> >> Looks like UTF8TextConverter is used independent >> from the encoding of the XML... >> >> Bye >> T. >> -- >> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >> Jetzt informieren: http://www.gmx.net/de/go/freephone >> >> > >

Jan. 16, 2011

Re: [Pharo-project] ZeroMQ, Mongrel2...

by Mike Hales

I'd be really interested in zmq for pharo/squeak too. I've been playing with it to replace mutexes and semaphores for multiprocessing in a c program, and would love to be able to tie in some smalltalk too. Mongrel2 and seaside could be interesting too, especially for websocket support. Mike Mike Hales Engineering Manager KnowledgeScape www.kscape.com On Tue, Jan 11, 2011 at 9:24 AM, Geoffroy Couprie <geo.couprie(a)gmail.com>wrote: > Hello, > > What would you think of a ZeroMQ frontend to Pharo? I was playing with > ZeroMQ, and more specifically the Mongrel2 web server, and I thought > that would be cool to use it, but the only reference of ZeroMQ and > Smalltalk I saw was about some code from Thomas GagnÃ©, which is not > available anymore. > > Anyhow, would you be interested in a port to Pharo? It looks like the > protocol is not really hard to implement. > > Best regards, > > Geoffroy > >

Jan. 16, 2011

Re: [Pharo-project] XML packages, CDATA and encoding

by jaayer

Sorry, I accidentally hit reply before typing anything. Torsten, what you are trying to do is not incorrect and should work as you expected it to. The reason why it didn't has less to do with XMLSupport per se and more to do with its reliance on Pharo's TextConverter system. The problem is faulty matching of the "encoding" attribute value to the appropriate subclass of TextConverter. The code responsible for this in XMLSupport is: converterClass := (Smalltalk at: #TextConverter ifAbsent: [^ self]) defaultConverterClassForEncoding: anEncodingName asLowercase. But as you can see, the matching is actually done by TextConverter and its class-side #defaultConverterClassForEncoding: method, which works by sending #encodingNames to all subclasses and testing the array returned to see if it includes the specified encoding name. If you browse Latin1TextConverter, the right class for the encoding you specified, and look at its #encodingNames message, you will see the array it returns does not include "ISO-8859-1": ^ #('latin-1' 'latin1') copy. Change it to this (note the lowercase): ^ #('latin-1' 'latin1' 'iso-8859-1') copy. and everything now works. So this is really a bug in TextConverter and its Latin1TextConverter subclass, not XMLSupport. Also, the #allSubclassesDo: test in #defaultConverterClassForEncoding: should probably be augmented with a Dictionary cache to speed-up lookups for known encoding-converter pairs. Can someone forward this message to whoever maintains TextConverter? ---- On Mon, 10 Jan 2011 04:38:23 -0800 Torsten Bergmann wrote ---- >Create a file "test.xml" with the following >contents (german umlaut): > > > > > >After loading ConfigurationOfXML try to parse it: > > |fs| > fs := FileStream fileNamed: 'test.xml'. > XMLDOMParser parseDocumentFrom: fs. > > >=> gives an error: 'Invalid utf8 input detected' >=> it works if you remove the CDATA section > >Looks like UTF8TextConverter is used independent >from the encoding of the XML... > >Bye >T. >-- >NEU: FreePhone - kostenlos mobil telefonieren und surfen! >Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Jan. 16, 2011

Re: [Pharo-project] XML packages, CDATA and encoding

by jaayer

---- On Mon, 10 Jan 2011 04:38:23 -0800 Torsten Bergmann wrote ---- >Create a file "test.xml" with the following >contents (german umlaut): > > > > > >After loading ConfigurationOfXML try to parse it: > > |fs| > fs := FileStream fileNamed: 'test.xml'. > XMLDOMParser parseDocumentFrom: fs. > > >=> gives an error: 'Invalid utf8 input detected' >=> it works if you remove the CDATA section > >Looks like UTF8TextConverter is used independent >from the encoding of the XML... > >Bye >T. >-- >NEU: FreePhone - kostenlos mobil telefonieren und surfen!Â Â Â Â Â Â Â Â Â Â Â Â >Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Jan. 16, 2011

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

Hi All, I've uploaded new VMs to VM.r2348/<http://www.mirandabanda.org/files/Cog/VM/VM.r2348/> (SimpleStackBasedCogit) and VM.r2349/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2349/> (StackToRegisterMappingCogit). The former are simply to be up-to-date with svn & Monticello. The latter also fix a bad bug with the StackToRegisterMappingCogit where e.g. 16r10 bitOr: 16r20 would evaluate to 1. I've smoke-tested the 2349 VMs on the Squeak4.2 beta test suite and things look good. best Eliot

Jan. 15, 2011

Re: [Pharo-project] [update 1.2] #12305

by Francisco Ortiz PeÃ±aloza

Hi, i don't like the orange theme to be the default one. IMHO it looks like a high contrast one. I prefer Glamour or even Watery! Regards, Francisco On Sat, Jan 15, 2011 at 5:39 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > I really don't like the orange theme to become the default pharo theme... is to "alien" for me, and I'm sure it will be also for newcomers. May I suggest to let the standard glamour theme as the default, and keep the orange just as an option? > > Cheers, > Esteban > > El 15/01/2011, a las 4:05p.m., StÃ©phane Ducasse escribiÃ³: > >> why not :) >> even if the orange is too orange :) >> Stef >> >>> Why don't you call the GLMOrangeUITheme the PharoTheme or something in this direction? >>> >>> Cheers, >>> Doru >>> >>> >>> On 14 Jan 2011, at 15:46, StÃ©phane Ducasse wrote: >>> >>>> 12305 >>>> ----- >>>> >>>> - GLMOrangeUITheme beCurrent. >>>> - Issue 3417: Â Â Â BehaviorTest>>#testAllLocalCallsOn fails. >>>> >>>> Stef >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >> >> > > >

Jan. 15, 2011