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

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

by CÃ©drick BÃ©ler

Le 11 janv. 2011 Ã 20:20, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> a Ã©crit : > On 11.01.2011 16:58, CÃ©drick BÃ©ler wrote: >>> >>>> Create a file "test.xml" with the following >>>> contents (german umlaut): >>>> >>>> >>>> <?xml version="1.0" encoding="iso-8859-1"?> >>>> <test><![CDATA[ZaunkÃ¶nig]]></test> >>>> >>>> After loading ConfigurationOfXML try to parse it: >>>> >>>> |fs| >>>> fs := FileStream fileNamed: 'test.xml'. >>>> XMLDOMParser parseDocumentFrom: Actually, I tried from a file, and it works too. Pharo 1.1, Cog, OSX, recent version of XML support (from squeaksource) Cheers, CÃ©drick >>>> >>>> >>>> => 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... >>>> >>> the problem seems not to be the xml parser. If you use FileStream>>fileNamed: the fileNamed: is delegated to FileStream class>>concreteStream which is MultiByteStream. This stream initializes itself with the utf8 converter if it isn't set intentionally. >>> >>> Besides that I'm not sure if the parsing of the xml parser works correctly if the setup is properly done for latin1 encoding. >>> >>> Norbert >> yes, I think the same as the following works without problem (note I have the last squeaksource version for XML related stuff) >> >> string := '<?xml version="1.0" encoding="iso-8859-1"?> >> <test><![CDATA[ZaunkÃ¶nig]]></test>'. >> >> XMLDOMParser parseDocumentFrom: fs contents. >> >> hth, >> >> CÃ©drick > Of course it is the job of the parser: > http://www.w3.org/TR/REC-xml/#charencoding > > The XMLSupport package is oblivious to this however, and only works on internal streams. > > Cheers, > Henry >

Jan. 12, 2011

[Pharo-project] Xtreams up to date

by mkobetic＠gmail.com

Hope it's OK to cross-post this, I figured there might be interested people on both sides. I finished the updates of the Xtreams port to match the VW version, so everything (that is available) should work as advertised in the documentation (http://code.google.com/p/xtreams/) Besides the implementation updates this last round of changes includes: * repackaging to match the docs and VW better, the dialect specific parts are now (mostly) gathered in Xtreams-Support * there is now a Gofer expression on the project page (http://www.squeaksource.com/Xtreams.html) to help people loading it, it shouldn't be hard to keep it up to date it shouldn't change very much * the source code is now identical between the dialects as much as possible, to help keeping it up to date. * one significant API change is that we renamed XTIncomplete to Incomplete to make code that uses Xtreams more portable. This is the only class that is very prominent in the API and hard to avoid in any sufficiently complex application, hopefully this is acceptable. I don't anticipate any significant changes in the port for next little while. I'd like to play with Squeak FFI next to see if I can bring the cryptographic streams from Xtreams-Xtras over and then see what it would take to get Xtreams-SSH2 running on Squeak and how it would perform. If you're curious how it went on VW side, I wrote about that in a blog post here: http://www.cincomsmalltalk.com/userblogs/cst/blogView. If you find bugs or issues, feel free to file an issue on the google project page (http://code.google.com/p/xtreams/issues/list) I'm monitoring both of these lists now as well and will try to answer any questions promptly. Cheers! Martin

Jan. 12, 2011

Re: [Pharo-project] PHP Fog ...

by Geoffroy Couprie

On Tue, Jan 11, 2011 at 10:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jan 11, 2011, at 5:57 PM, Steven Baker wrote: > >> About 6 months ago I shelved a project for doing Heroku-style >> deployments from Pharo to Seaside. Perhaps I should dig out my backup >> and pick it up. I thought I was the only one that might want this, and >> I got caught up with some issues serializing and sending objects over >> the network. > Please share your code :) Heroku didn't get there in a day, and used lots of good tools provided by the community. What we need now is those tools. > I would love to see money raised for doing this kind of startup over pharo. > Let's find some million dollar projects only Pharo can solve :)

Jan. 11, 2011

[Pharo-project] BitmapFillStyle does not support translucent form

by Denis Kudriashov

Hello, I try BitmapFillStyle with translucent form for my morph object. And It's does not work. There is AlphaInfiniteForm in polymorph package that work good as translucent fill styles. BitmapFillStyle used by Morph>>useBitmapFill. This method try set default bitmap form fill: fill := BitmapFillStyle fromForm: self defaultBitmapFillForm. "Note: Must fix the origin due to global coordinates" fill origin: self bounds origin. self fillStyle: fill. For my application I change #useBitmapFill to open file choose dialog and using user selection for fill style (by AlphaInfiniteForm). I want to share this little code. But I don't know how to package this? AlphaInfiniteForm is from Polymorph-... package. But useBitmapFill is from Morphic-.. package. Maybe AlphaInfiniteForm can be moved to Graphics-Display Objects package? What you think?

Jan. 11, 2011

Re: [Pharo-project] PHP Fog ...

by StÃ©phane Ducasse

On Jan 11, 2011, at 5:57 PM, Steven Baker wrote: > About 6 months ago I shelved a project for doing Heroku-style > deployments from Pharo to Seaside. Perhaps I should dig out my backup > and pick it up. I thought I was the only one that might want this, and > I got caught up with some issues serializing and sending objects over > the network. I would love to see money raised for doing this kind of startup over pharo. > So that's my first question: what's the best way to serialize and send > an object over the network? Would it perhaps be better to just tell > the deployed image to use Monticello to update? Can Monticello roll > back in case of error (so it can be headless)? not as far as I know. Now I think that we are making progress to be able to load code in a separate environment so we could really load everything in an environment and not install it in case of problem. It just takes more times than expected. Stef > > -Steven > > On Tue, Jan 11, 2011 at 6:36 AM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: >> >> >> Nick Ager wrote: >>> >>> there's always EC2 and Gemstone: http://www.vimeo.com/18375790 >>> >> >> Yep, I reckon the screencast you made is great ... but ... it's not quite >> the same though :) >> >> -- >> View this message in context: http://forum.world.st/PHP-Fog-tp3208657p3209078.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

Jan. 11, 2011

Re: [Pharo-project] Issue 3523 in pharo: Nested comments

by pharo＠googlecode.com

Comment #6 on issue 3523 by stephane.ducasse: Nested comments http://code.google.com/p/pharo/issues/detail?id=3523 I was sure somebody would find the problem :). There was a lng thread a while ago in VW about that but now "* *" looks good to me because this is just a comment so :)

Jan. 11, 2011

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

by StÃ©phane Ducasse

Thanks goran It would be good to structure a bit all these data. I hope that we will have a new squeaksource that helps us to get a better visibility for us but also from others Stef On Jan 11, 2011, at 9:51 PM, GÃ¶ran Krampe wrote: > Not at all the same thing as ZeroMQ but I did implement STOMP a while back: > > http://www.squeaksource.com/StompProtocol.html > > regards, GÃ¶ran >

Jan. 11, 2011

Re: [Pharo-project] [Vm-dev] Re: Waste of CPU Power by polling events?

by Igor Stasenko

On 11 January 2011 20:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 2011/1/11 Levente Uzonyi <leves(a)elte.hu> >> >> >> On Tue, 11 Jan 2011, Eliot Miranda wrote: >> >> (Pine can't quote your mail, sorry.) >> >> "The problem with linux is that the pthreads implementation doesn't allow a normal user-level process to create high-priroity threads so that as >> soon as the Vm starts to spin doing some computation the heartbeat thread is shut-out and if the spinning computation only interrupted when a delay >> expires it'll never get interrupted because it is blocking the very thread that would signal the delay. Â So until linux's pthreads implementation >> supports multiple priorities we're stuck with hacks like the interval timer based itimer in the linux Cog VMs." >> >> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly? > > Linux doesn't allow more than /one/ thread priority for threads in a user-level process. Â So one /can't/ have multiple priorities. Â All threads run at the same priority. Â This is a horrible bug in the linux pthreads implementation but there it is. So, why not use signals & POSIX timer [1] for same purpose? Or do signals having other issues which even worse than using heartbeat process? [1] http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html > best > Eliot >> >> Levente > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 11, 2011

Re: [Pharo-project] Issue 3531 in pharo: [FIX]ParseNodeEnumerator does not visits ivar nodes

by pharo＠googlecode.com

Comment #2 on issue 3531 by siguctua: [FIX]ParseNodeEnumerator does not visits ivar nodes http://code.google.com/p/pharo/issues/detail?id=3531 - added right changeset Attachments: ParseNodeEnumerator-fix-ivar-visiting.1.cs 902 bytes

Jan. 11, 2011

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

by GÃ¶ran Krampe

Not at all the same thing as ZeroMQ but I did implement STOMP a while back: http://www.squeaksource.com/StompProtocol.html regards, GÃ¶ran

Jan. 11, 2011