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

Re: [Pharo-project] Pharo for Professional Development

by StÃ©phane Ducasse

But gwenael did a complete GTK binding for Squeak/pharo and he moved everything to GNU. Too bad. So we/you could gain from that. Stef On Jan 11, 2010, at 8:18 AM, StÃ©phane Ducasse wrote: > Now for pharo people could ressurect the GTK port done by gwenael. > Or pay for that. > > Stef > > On Jan 11, 2010, at 2:40 AM, Stephen Taylor wrote: > >> Schwab,Wilhelm K wrote: >>> Dolphin is better than that<g> >> >> I've put my money where my mouth is with Dolphin - I think I've bought >> every product they've ever released, just to give them a hand - despite >> the fact that I've still got a Dolphin version4 image on the go! >> >> >>> The feature you are describing is what they call an idea space, and it is probably my least favorite features of Dolphin. >> >> And one of my favourites! If only everyone agreed with me all the time... >> >> >>> Bill >> >> >> Steve >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] [ANN] WorkingSet

by Romain Robbes

On Jan 11, 2010, at 5:33 PM, Lukas Renggli wrote: >>> - When opening classes/users/siblings they show up in the wrong >> >>> browser, e.g. not the one I configured. >> >> That's strange, since I use Toolset for these queries. Should I use something else? > > I am using OB, but I get the old system browser in some cases: for > senders, implementors and sets of classes. I guess the toolset should be fixed then, looks like it's not opening the right tool all the time. > >>> - I always have the same working set: WorkingSetMorph and a few >>> methods within that. I have no idea how to change that. >> >> It adapts to the code you change. If you modify a method or a class, it will show up in the list. > > Aha, I was not editing anything. Sort of makes sense :-) I still have to see how to integrate navigation. > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

Jan. 11, 2010

Re: [Pharo-project] Pharocore 1.1: Array DNU createMethod: header

by StÃ©phane Ducasse

ok On Jan 11, 2010, at 7:39 PM, Alain Plantec wrote: > ok, I've checked again, it comes from an old > package of mine that I'm trying to resurrect :) > sorry. > Alain > > > StÃ©phane Ducasse a Ã©crit : >> alain >> >> this is strange. >> normally the trailer should not be an array. >> how do you get this error. >> >> is here the method igor introduced for his transformation and remove at the end. >> >> >> ArrayedCollection>>createMethod: numberOfBytesForAllButTrailer header: headerWord >> | meth | >> meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + self size header: headerWord. >> "copy the encoded trailer data" >> 1 to: self size do: >> [:i | meth at: meth size - self size + i put: (self at: i)]. >> >> ^ meth! ! >> >> >> >> >> >> On Jan 11, 2010, at 5:53 PM, Alain Plantec wrote: >> >> >>> in >>> >>> CompiledMethod>> >>> newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: >>> nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex >>> "Answer an instance of me. The header is specified by the message >>> arguments. The remaining parts are not as yet determined." >>> | largeBit primBits | >>> nTemps > 63 ifTrue: >>> [^ self error: 'Cannot compile -- too many temporary >>> variables']. >>> nLits > 255 ifTrue: >>> [^ self error: 'Cannot compile -- too many literals variables']. >>> largeBit := (nTemps + stackSize) > SmallFrame ifTrue: [1] ifFalse: [0]. >>> primBits := primitiveIndex <= 16r1FF >>> ifTrue: [primitiveIndex] >>> ifFalse: ["For now the high bit of primitive no. is in the 29th >>> bit of header" >>> primitiveIndex > 16r3FF ifTrue: [self error: 'prim num >>> too large']. >>> (primitiveIndex bitAnd: 16r1FF) + ((primitiveIndex >>> bitAnd: 16r200) bitShift: 19)]. >>> >>> ^ trailer createMethod: numberOfBytes >>> header: (nArgs bitShift: 24) + >>> (nTemps bitShift: 18) + >>> (largeBit bitShift: 17) + >>> (nLits bitShift: 9) + >>> primBits. >>> >>> Alain >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] definition or getSource for Class and CompiledMethod

by StÃ©phane Ducasse

Hi eliot > > my approach to this is to define ClassReference that sits alongside MethodReference and so allows the list browser tools (list browser, change list, etc) to compare class definitions. If you think this makes sense let me know and I'll extract the code (I no longer have a change set; this code is now integrated into our images). Yes at least this is coherent. How different are there from PseudoClass? Now don't you feel that it makes a lot of wrapper code? We had crazy discussions with marcus about MethodReference and CompiledMethod: meta object and object, runtime objects and ui objects, their causal connection. At one point we will have to clean that. I do not know in which direction. At least they should have a common interface selector class and we have that now in pharo so to a minimal but useful extent we can manipulate CM as MR and the inverse. Power to polymorphic interfaces. Brainstorming we could merge CompiledMethod and MethodReference if we do not need extra state and methodReference protocol can be packaged as an extension of compiledMethod and the behavior is ok (like manipulating a MethodReference which is not "installed" in the system) Now the same question arise with Class and ClassReference. In the same vein (but inverse logic) I was thinking that it would be cool that MCClassDefinitions share a common interface with Class and Pseudo class so that we could only only one browser to browse them all. After of course the two objects could have their own specific interface in addition to the share one. Now a potential problem is the mapping between a declarative code model (MC) and a runtime one in term of mismatch: MCVariableDefinition and no object to represent instance variables. Of course we want first class instance variable at the MOP level and it will come. But this mismatch is a problem I know and did not check any further. > On Mon, Jan 11, 2010 at 8:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yep! > I will do that > Stef > On Jan 11, 2010, at 4:49 PM, Gary Chambers wrote: > > > Saw that too. > > One or the other! Defniniton perhaps (also on PackageInfo would do the lot). > > > > Regards, Gary > > > > ----- Original Message ----- > > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > To: <Pharo-project(a)lists.gforge.inria.fr> > > Sent: Monday, January 11, 2010 2:57 PM > > Subject: [Pharo-project] definition or getSource for Class and > > CompiledMethod > > > > > >> Hi > >> > >> I was looking at the video of laurent and what stroke me is that > >> getting the source of class or a compiled method is not polymorphic. > >> It would be good to support that. > >> aClass getSource? > >> aCompiledMethod definition? > >> > >> Stef > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] Nanosecond-level profiling in Pharo?

by Alexandre Bergel

This is troubling indeed. I will ask. Alexandre On 9 Jan 2010, at 09:16, StÃ©phane Ducasse wrote: > ask him. I do not see how people can ask him like that while you > discussed with him > > On Jan 8, 2010, at 7:38 PM, Alexandre Bergel wrote: > >>> Do you have information if the "level" is resolution only or >>> effective accuracy? >> >> No idea. You can contact the guy who mentioned this to me: http://www.inf.usi.ch/faculty/binder/ >> >> Cheers, >> Alexandre >> >>> >>> -- >>> Cesar Rabak >>> >>> >>> Em 08/01/2010 15:56, Alexandre Bergel < alexandre(a)bergel.eu > >>> escreveu: >>> >>> >>> This is the level of state-of-the-Art Java profilers operate with. >>> >>> Cheers, >>> Alexandre >>> >>> On 8 Jan 2010, at 14:48, csrabak(a)bol.com.br wrote: >>> >>>> I don't want to rain in your folks party, but a nanosecond is a >>>> millionth of a millisecond. Also, it is at the timing of silicon >>>> memory access on present microcomputers. >>>> >>>> Isn't enough you increase the accuracy of the timing by one >>>> thousand >>>> looking for a solution to get *microsecond* resolution? >>>> >>>> HTH, >>>> >>>> -- >>>> Cesar Rabak >>>> >>>> >>>> >>>> Em 07/01/2010 20:57, Alexandre Bergel < alexandre(a)bergel.eu > >>>> escreveu: >>>> >>>> >>>> Ok, good to know. >>>> >>>> Thanks Igor, >>>> Alexandre >>>> >>>> >>>> On 7 Jan 2010, at 19:29, Igor Stasenko wrote: >>>> >>>>> 2010/1/7 Alexandre Bergel : >>>>>> Hi! >>>>>> >>>>>> I am currently working on a new profiler for Pharo. The idea is >>>>>> to >>>>>> graphically renders a profiling using Mondrian. I hope to release >>>>>> it >>>>>> soon. >>>>>> When discussing with an expert in the field (Walter Binder), the >>>>>> question about time grain was raised. I am partly based on >>>>>> MessageTally, which has a millisecond grain. Anyone is aware of a >>>>>> finer grain? At the level of nanosecond? Does it makes sense >>>>>> since >>>>>> there is no JIT (yet)? >>>>>> >>>>> >>>>> AFAIK, there's no primitives in VM, which provide timing with >>>>> nanosecond precision. >>>>> >>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 11, 2010

Re: [Pharo-project] Nanosecond-level profiling in Pharo?

by Alexandre Bergel

I remember to have seen once at a keynote that some people use statistic to reach that level of granularity. Something like, if executing n instructions took 1 second, and in 1 second you have so many CPU cycle, then you can deduce the average number of CPU cycle to execute a fraction of the whole computation. Cheers, Alexandre On 9 Jan 2010, at 09:15, StÃ©phane Ducasse wrote: > really? > When I read what elliot said also with the precision I have some > doubts. > >> This is the level of state-of-the-Art Java profilers operate with. >> >> Cheers, >> Alexandre >> >> On 8 Jan 2010, at 14:48, csrabak(a)bol.com.br wrote: >> >>> I don't want to rain in your folks party, but a nanosecond is a >>> millionth of a millisecond. Also, it is at the timing of silicon >>> memory access on present microcomputers. >>> >>> Isn't enough you increase the accuracy of the timing by one thousand >>> looking for a solution to get *microsecond* resolution? >>> >>> HTH, >>> >>> -- >>> Cesar Rabak >>> >>> >>> >>> Em 07/01/2010 20:57, Alexandre Bergel < alexandre(a)bergel.eu > >>> escreveu: >>> >>> >>> Ok, good to know. >>> >>> Thanks Igor, >>> Alexandre >>> >>> >>> On 7 Jan 2010, at 19:29, Igor Stasenko wrote: >>> >>>> 2010/1/7 Alexandre Bergel : >>>>> Hi! >>>>> >>>>> I am currently working on a new profiler for Pharo. The idea is to >>>>> graphically renders a profiling using Mondrian. I hope to >>>>> release it >>>>> soon. >>>>> When discussing with an expert in the field (Walter Binder), the >>>>> question about time grain was raised. I am partly based on >>>>> MessageTally, which has a millisecond grain. Anyone is aware of a >>>>> finer grain? At the level of nanosecond? Does it makes sense since >>>>> there is no JIT (yet)? >>>>> >>>> >>>> AFAIK, there's no primitives in VM, which provide timing with >>>> nanosecond precision. >>>> >>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 11, 2010

Re: [Pharo-project] [ANN] WorkingSet

by Lukas Renggli

>> - When opening classes/users/siblings they show up in the wrong > >> browser, e.g. not the one I configured. > > That's strange, since I use Toolset for these queries. Should I use something else? I am using OB, but I get the old system browser in some cases: for senders, implementors and sets of classes. >> - I always have the same working set: WorkingSetMorph and a few >> methods within that. I have no idea how to change that. > > It adapts to the code you change. If you modify a method or a class, it will show up in the list. Aha, I was not editing anything. Sort of makes sense :-) -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 11, 2010

[Pharo-project] IPhone and other tablet PC ..or about Genie with the New event mechanism

by StÃ©phane Ducasse

Genie was a great recognition engine developed by nathanael when he was at disney. It was impressive compared with HP tablet pc software. You could steer the complete UI with it. Nathanael went to show it to Smasung research labs and HP at that time. Just before the layoff of SqueakC from HP Genie - learns in one pass a gesture no need to rehearse or you to adapt - had sophisticated settings (display size, battery consumption, speed of the stroke) - context dictionary so the same gesture could have different meaning in different contexts - has a really good documentation this are some of the class comments http://www.iam.unibe.ch/~schaerli/smalltalk/genie/genieIntroduction.htm Now Genie needed a hook in the min event pasteUp loops so we removed the patch because it was slowly the complete UI. Now that we have a cleaner event model and hook I would really love to see how we could hook Genie in Pharo. Since they is an interest for iPhone and may be new tablet. Stef

Jan. 11, 2010

Re: [Pharo-project] Pckage names

by StÃ©phane Ducasse

No problem I closed one :) On Jan 11, 2010, at 7:15 PM, Torsten Bergmann wrote: > Issue created: > > http://code.google.com/p/pharo/issues/detail?id=1776 > (unfortunately twice through webbrowser, see 1777) > -- > Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] 1.0 and 1.1. on Download page

by Mariano Martinez Peck

On Mon, Jan 11, 2010 at 8:05 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > The Pharo download page does not include the 1.1 unstable > images/setups anymore. Who removed them and why? > Did I miss some discussion? > > Yes, it was intentionally removed because: - They were REALLY unstable. Think that even the 1.1 core is unstable so...image external tools. - External packages maintainers didn't want to spend the time to maintain their packages running in both versions, which makes a lot of sense. So, it doesn't make sense to build dev image if you even won't have an OB and RB working. - It takes a lot of times to manage issues ans answering mails that maybe they don't help - After Pharo 1.0 is released, I guess external packages maintainers can work on 1.1 so that to make packages to work there. I know it is not the best solution, but it is what we have. Those people who are working in stuff from 1.1 must use the core even to develop (I had to do this). Bye > T. > > > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 > - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 11, 2010