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

Re: [Pharo-project] Automating issue tracker update when a package is published

by StÃ©phane Ducasse

this would be sooooo cooooool Stef On Mar 22, 2011, at 10:41 PM, Nicolas Cellier wrote: > I know what I gonna hear, www.squeasource.com is already overloaded > and we can't, > but it would be super-nice if the Pharo issue tracker were updated > automagically when a slice is commited in the inbox. > > Nicolas >

March 23, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

>> So, as i understood , a code like: >> >> someMethod >> >> | temp1 temp2 | >> >> ^ self send: temp1+temp2 with: temp2. >> >> could be represented by following: >> (we need 5 temps on stack: ) >> >> 1. temp1 >> 2. temp2 >> 3. receiver >> 4. - first arg for send >> 5. - second arg >> >> bytecode: >> >> 1.storeSelf: 3 >> 2. storeTemp: 1 to: 4 >> 3. storeTemp: 2 to: 5 >> 4. send #+ to: 4 >> 5. storeTemp: 2 to: 5 >> 6. send #send:with: to: 3 >> 7. return: 3 Exactly. You will probably need to say how many arguments you want to pass to +, for validation purposes. And yes, as you automatically did, you would get the return value back as the location of the first argument. This has as an advantage that a "return self" does not not to do anything at all; it was already the first "argument" of the send anyway. There are even more optimizations that could be done; such as knowing that the receiver is actually at location -1 if this is in the context of the method; thus not even needing to copy any values ... You could just apply the first send in 2, and the second one in -1 :) But obviously in that case I expect a lot of knowledge of what you do, and this might not always be possible. cheers, Toon

March 22, 2011

Re: [Pharo-project] Automating issue tracker update when a package is published

by Norbert Hartl

Am 22.03.2011 um 23:36 schrieb Igor Stasenko: > On 22 March 2011 22:41, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> I know what I gonna hear, www.squeasource.com is already overloaded >> and we can't, >> but it would be super-nice if the Pharo issue tracker were updated >> automagically when a slice is commited in the inbox. >> > Good idea :) > > No need to put that load to squeaksource.com > SqS could just send regular emails to special bot(a)somehost.com, > where you have a bot which parses incoming mail and do some extra > processing like one proposed by you. > How about a simple shell script that scans for directory changes and updates the bug tracker? Maybe too less of a complex solution :) Or http://inotify.aiken.cz/?section=incron&page=about&lang=en Norbert

March 22, 2011

Re: [Pharo-project] Automating issue tracker update when a package is published

by Igor Stasenko

On 22 March 2011 22:41, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I know what I gonna hear, www.squeasource.com is already overloaded > and we can't, > but it would be super-nice if the Pharo issue tracker were updated > automagically when a slice is commited in the inbox. > Good idea :) No need to put that load to squeaksource.com SqS could just send regular emails to special bot(a)somehost.com, where you have a bot which parses incoming mail and do some extra processing like one proposed by you. > Nicolas > > -- Best regards, Igor Stasenko AKA sig.

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Igor Stasenko

On 22 March 2011 23:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 March 2011 19:43, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: >> It's a very simple idea really. >> >> Where your bytecode would previously look like >> >> pushTemp: 1 >> pushTemp: 2 >> add >> >> now it looks like: >> >> add 1, 2, 3 >> >> where 3 is the start of your original stack, for example. >> >> So rather than pushing and popping etc, you just abstractly interpret the >> bytecodes and figure out the stack locations where they would be pushed. And >> then you use this number as arguments to a copy bytecode, rather than >> calling "push". This avoids having to maintain a stack where you up front >> already know what the target index will be. You know this up front since >> your code is static by itself. >> >> The advantage is that you don't need to do stack-tricks to keep data around, >> since all the operation are simple things such as copy, loadFromOuterScope, >> storeInOuterScope, loadFromField, storeInField, ... >> >> So conversely to what you might have thought beforehand, you don't have >> "real registers" around, you just consider a stackframe to be a set of >> registers. And you operate on them with easy bytecodes. The advantage, in >> addition to it being less work and thus slightly faster by itself, is that >> it will later on also map better on the real hardware. The operations >> already look like what normal assembler operations would look like. >> > > So, as i understood , a code like: > > someMethod > > Â | temp1 temp2 | > > Â ^ self send: temp1+temp2 with: temp2. > > could be represented by following: > (we need 5 temps on stack: ) > > 1. temp1 > 2. temp2 > 3. receiver > 4. - first arg for send > 5. - second arg > > bytecode: > > 1.storeSelf: 3 > 2. storeTemp: 1 to: 4 > 3. storeTemp: 2 to: 5 > 4. send #+ to: 4 > 5. storeTemp: 2 to: 5 > 6. send #send:with: to: 3 > 7. return: 3 > > (note here, that given bytecode already contains an optimization - a > context slot #5 are not overridden by #+ send, > the same argument temp2 is simply reused for subsequent send > (#send:with:), which is quite nice). > oh... a little mistake i meant that instruction #5 could be optimized away, because slot #5 contents == temp2 are unchanged. > >> cheers, >> Toon >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Igor Stasenko

On 22 March 2011 19:43, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > It's a very simple idea really. > > Where your bytecode would previously look like > > pushTemp: 1 > pushTemp: 2 > add > > now it looks like: > > add 1, 2, 3 > > where 3 is the start of your original stack, for example. > > So rather than pushing and popping etc, you just abstractly interpret the > bytecodes and figure out the stack locations where they would be pushed. And > then you use this number as arguments to a copy bytecode, rather than > calling "push". This avoids having to maintain a stack where you up front > already know what the target index will be. You know this up front since > your code is static by itself. > > The advantage is that you don't need to do stack-tricks to keep data around, > since all the operation are simple things such as copy, loadFromOuterScope, > storeInOuterScope, loadFromField, storeInField, ... > > So conversely to what you might have thought beforehand, you don't have > "real registers" around, you just consider a stackframe to be a set of > registers. And you operate on them with easy bytecodes. The advantage, in > addition to it being less work and thus slightly faster by itself, is that > it will later on also map better on the real hardware. The operations > already look like what normal assembler operations would look like. > So, as i understood , a code like: someMethod | temp1 temp2 | ^ self send: temp1+temp2 with: temp2. could be represented by following: (we need 5 temps on stack: ) 1. temp1 2. temp2 3. receiver 4. - first arg for send 5. - second arg bytecode: 1.storeSelf: 3 2. storeTemp: 1 to: 4 3. storeTemp: 2 to: 5 4. send #+ to: 4 5. storeTemp: 2 to: 5 6. send #send:with: to: 3 7. return: 3 (note here, that given bytecode already contains an optimization - a context slot #5 are not overridden by #+ send, the same argument temp2 is simply reused for subsequent send (#send:with:), which is quite nice). > cheers, > Toon > -- Best regards, Igor Stasenko AKA sig.

March 22, 2011

Re: [Pharo-project] Automating issue tracker update when a package is published

by Henrik Sperre Johansen

On 22.03.2011 22:41, Nicolas Cellier wrote: > I know what I gonna hear, www.squeasource.com is already overloaded > and we can't, > but it would be super-nice if the Pharo issue tracker were updated > automagically when a slice is commited in the inbox. > > Nicolas > http://code.google.com/p/support/wiki/IssueTrackerAPI I guess we at least need working SSL + some labour first :) Cheers, Henry

March 22, 2011

[Pharo-project] Issue 3851 in pharo: Remove all classes in Network-RemoteDirectory

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3851 by marcus.d...(a)gmail.com: Remove all classes in Network-RemoteDirectory http://code.google.com/p/pharo/issues/detail?id=3851 All the ServerDirectory crap is now just used in FileList, FtpUrl and MCConfigurationBrowser.

March 22, 2011

[Pharo-project] Issue 3850 in pharo: remove HTTPServerDirectory PseudoFileStream

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3850 by marcus.d...(a)gmail.com: remove HTTPServerDirectory PseudoFileStream http://code.google.com/p/pharo/issues/detail?id=3850 After Issue 3638 is closed, we can remove PseudoFileStream and HTTPServerDirectory (not used anymore). Attachments: CleanHttpServerDirectory.1.cs 194 bytes

March 22, 2011

Re: [Pharo-project] Issue 3847 in pharo: The absolute value of a negativeZero should behave like a positive zero

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3847 by nicolas....(a)gmail.com: The absolute value of a negativeZero should behave like a positive zero http://code.google.com/p/pharo/issues/detail?id=3847 Test and fix in the inbox

March 22, 2011