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

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

by pharo＠googlecode.com

Comment #1 on issue 3531 by nicolas.cellier.aka.nice: [FIX]ParseNodeEnumerator does not visits ivar nodes http://code.google.com/p/pharo/issues/detail?id=3531 Hi Igor, sounds like the wrong .cs

Jan. 11, 2011

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

by csrabak＠bol.com.br

Geert, Even before we get into the sizing of market, we need to see if injecting Venture Capital into Pharo will do for the better or not... -- Cesar Rabak Em 11/01/2011 07:19, Geert Claes < geert.wl.claes(a)gmail.com > escreveu: I reckon a Smalltalk-type Heroku/PHP Fog (http://techcrunch.com/2011/01/10/php-fog-raises-1-8-million-to-be-the-herok…) would be nice :) Would there be a viable business opportunity there or is the market simply too small? -- View this message in context: http://forum.world.st/PHP-Fog-tp3208657p3208657.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 11, 2011

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

by pharo＠googlecode.com

Status: Fixed Owner: siguctua CC: stephane.ducasse, marcus.denker, eliot.miranda Labels: Milestone-1.2 New issue 3531 by siguctua: [FIX]ParseNodeEnumerator does not visits ivar nodes http://code.google.com/p/pharo/issues/detail?id=3531 i found that enumerator does not does not visits the instance variable node: visitInstanceVariableNode: anInstanceVariableNode (self shouldVisit: anInstanceVariableNode) ifFalse: [^nil]. " theBlock value: anInstanceVariableNode. <<<< missing " ^super visitInstanceVariableNode: anInstanceVariableNode I thought that it was left on purpose, but Eliot confirmed that its a bug. The fix is in attachment. Attachments: CompilerParser-class-fix.1.cs 408 bytes

Jan. 11, 2011

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

by csrabak＠bol.com.br

I hope this does look like nitpicking, but C comments are /* */ not */ /* HTH -- Cesar Rabak Em 10/01/2011 05:23, pharo(a)googlecode.com escreveu: Status: Accepted Owner: aplantec New issue 3523 by aplantec: Nested comments http://code.google.com/p/pharo/issues/detail?id=3523 Now let me open a big can of worms but we truly need it. When you write documentation (I did several experiments with Soup) the documentation in class comment is cool because you to not have to have " and " and '' ' ' '' '" everytimes you manipulate a string or a comment. Now you do not want to have huge class comments I would prefer to have a couple of methods and it does not work: you put back the crappy unnestable " ugly boring.... better not putting comments. So I would really like to have */ this is a nice nestable comment "hkjkhhkjh " 'hkjjkh' 1 + 2 */yet another comment: increbile this is a nested ones: yes you know Smalltalkers are discovering the world/* /* As you see stealing the C comment syntax is a plus because everybody knows it. I remember a discussion on VW about possible syntax to support that. Before replying to this point thing hard because we need that support.

Jan. 11, 2011

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

by Eliot Miranda

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. best Eliot > > > Levente >

Jan. 11, 2011

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

by Henrik Sperre Johansen

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: 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... >>> >> 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. 11, 2011

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

by Levente Uzonyi

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? Levente

Jan. 11, 2011

Re: [Pharo-project] Issue 3528 in pharo: TestRunner button height not fixed

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.2 Comment #2 on issue 3528 by marianopeck: TestRunner button height not fixed http://code.google.com/p/pharo/issues/detail?id=3528 thanks Bernhard. I put it as fixed so that they can integrate it. Not sure which milestone. I put 1.2 but it can be moved to 1.3

Jan. 11, 2011

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

by Philippe Marschall

On 01/11/2011 05:24 PM, Geoffroy Couprie 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. There is no protocol, you wrap a C library. What's suboptimal from a Seaside point of view is that Mongrel2 assumes handlers are stateless which Seaside is not. Cheers Philippe

Jan. 11, 2011

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

by Eliot Miranda

On Fri, Nov 26, 2010 at 6:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > In Hydra, i merged the heartbeat and delay timeout logic into single > routine, which were running in high-priority thread. > It simply picks the nearest possible time to wait (sleep) - either > heartbeat cycle delay, or scheduled Delay timeout, > then signals VM to interrupt and handle delay or do regular event > processing using ioHandleEvents(). > > What is good in Windows, that there are special event mask for > WaitForMultipleEvents() function, > which could put a thread in wait till keyboard/mouse input available. > In that way, on Windows, VM could avoid frequent interrupts to for > polling events, and instead use waiting thread(s), > and interrupt only if some event signaled. > Yes, that's what I did in the VW VM. WaitForMultipleEvents also takes a timeout so one can wait until an event or the next delay with a single call. > FreeBSD also introduced a kernel events, so instead of polling, one > could simply wait for I/O activity (like file, socket etc). Not sure > about mouse/keyboard input. I'm not sure, but think i heard linux > kernel also integrated that recently. > 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. > > On 27 November 2010 00:40, John M McIntosh > <johnmci(a)smalltalkconsulting.com> wrote: > > > > Eliot, I had looked at turn off the heartbeat when we did the nanosleep, > then turned it back on. The problem was actually trying to figure out if > > it did any good since the cost of pausing/restarting the heartbeat task > was high. I think first we have to quantify the costs. This is difficult to > do on desktop > > machines since they are so fast, so I was working with an iPod touch > which is 1000x (wild guess number) times slower. > > I'm also unsure of the pattern for when > the ioRelinquishProcessorForMicroseconds is called and for how long. Further > to that we do attempt to calculate the next wake up time, but sometime it's > in the past, so why is ioRelinquishProcessorForMicroseconds being called? > Even if we sleep then how long and what wakes us up early? > > On 2010-11-26, at 8:39 AM, Eliot Miranda wrote: > > > > Yes, we need to change this, but I think one has to change the background > process and/or nothing to run behavior. In the VW VM the VM disables the > heartbeat and enters some blocking call when there's nothing to do. Squeak > runs the background process which calls a primitive that sleeps for a short > time. The former is much better. If a delay is active as the VM does to > sleep it schedules a wakeup event or supplies a timeout so that it blocks > until input is available or the next delay. > > We could still keep the background process and do something similar to > VW, disabling the heartbeat until after the relinquish, and factoring the > delay into the relinquish timeout. > > Also the heartbeat already has facilities to change its frequency, so one > could modify things to slow down the heartbeat, again ensuring that it ticks > before the next delay expiry. > > What approach (not necessarily from the above) appeals to you John? > > best > > Eliot > > > > -- > > > =========================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > > > =========================================================================== > > > > > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 11, 2011