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

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

by Janko MivÅ¡ek

I see ZeroMQ as a way to inter-process communicate easier with other programing languages, which seems to be one of the main ZeroMQ goals? Janko On 16. 01. 2011 05:45, Mike Hales wrote: > 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 <http://www.kscape.com> > > > On Tue, Jan 11, 2011 at 9:24 AM, Geoffroy Couprie <geo.couprie(a)gmail.com > <mailto:geo.couprie@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 -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 16, 2011

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

by Philippe Marschall

On 16.01.2011 05:45, Mike Hales wrote: > 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. No, see previous post. Cheers Philippe

Jan. 16, 2011

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

by Marcus Denker

On Jan 16, 2011, at 10:33 AM, StÃ©phane Ducasse wrote: > Dear marco > > can you give more information else vm people cannot do anything? > Which os > exact donwload link > pharo version.... > If it is 1.1.1, then we need to do a 1.1.2 for Cog... because of a missing method in MethodContext (numArgs, if I remember correctly). Marcus > Stef > > > On Jan 16, 2011, at 10:01 AM, Marco Schmidt wrote: > >> 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 >> <PharoDebug.log> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 16, 2011

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

by StÃ©phane Ducasse

Dear marco can you give more information else vm people cannot do anything? Which os exact donwload link pharo version.... Stef On Jan 16, 2011, at 10:01 AM, Marco Schmidt wrote: > 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 > <PharoDebug.log>

Jan. 16, 2011

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

by Sven Van Caekenberghe

On 16 Jan 2011, at 03:09, jaayer wrote: > 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. I had seen this as well in the past: this should be changed. I think this is a safe change, it just adds an alternative name to an existing encoding. Sven

Jan. 16, 2011

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