- Pharo-dev - lists.pharo.org

Re: [Pharo-project] does anybody want to continue the comment of the day effort?

by Max Leske

Although I haven't had anything to contribute up to now, I vote to continue it. If there is a comment I can help with, I will. Max On 24.07.2011, at 10:02, StÃ©phane Ducasse wrote: > HI guys > > does any of you want to continue the comment of the day effort? > Because it was really important. > > Stef >

July 24, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by StÃ©phane Ducasse

Doru can you add the page on morphic on this list? Marcus can you add a page to OPAL? with pending todo? Damien can you add one for Coral? > http://code.google.com/p/pharo/wiki/Teams I added RPackage http://code.google.com/p/pharo/wiki/RPackageRoadmap so that people can follow the effort. Stef Here is what I wrote. Introduction The current status is that RPackage works well with a one to one mapping package - category. Done: â¢ All the events have been migrated from systemNotifier to SystemAnnouncer?. The package SystemAnnouncement? is ready for inclusion. This means that RPackage does not rely on systemnotifier to keep its data in sync. This also means that SystemAnnouncer? can be folded in the system and that other tools can use it. And that we will be able to remove SystemNotifier?. Nautilus is only based on SystemNotifier?. â¢ A lot of tests. In addition tests are written in a way that the central RPackageOrganizer is not impacted by test running. â¢ Nautilus and Moose using RPackage. Nautilus is based on RPackage. Moose uses RPackage as a cache since months. â¢ Identification of the clients using PackageInfo?. We started to identify clients of PackageInfo? to prepare migration phase. Next steps: â¢ Clean RPackage (because some functionality were copied from PackageInfo?): â¢ Problem Gofer and the some package of RefactoringEngine? rely on this API â¢ Solution: include Refactoring packages in 1.4 and modify it there. In 1.4 we want OCompletion, Ecompletion and Refactoring in the image so this fits well. In subsequent versions we may republish them as separate packages. â¢ Adding Package Tags. Since people do not want (but have no time to do it - funny isn't) to have one -one mapping between category and package. We will add tags the idea is to be able to have classes sorted inside a package. Pack1 - Tag1 ClassA ClassB - Tag2 ClassC ClassD ClassA Pack2 - Tag1 - Tag3 â¢ MC shoud use RPackage to save information â¢ Tags should be saved in MC package â¢ New MC Browser

July 24, 2011

[Pharo-project] does anybody want to continue the comment of the day effort?

by StÃ©phane Ducasse

HI guys does any of you want to continue the comment of the day effort? Because it was really important. Stef

July 24, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Hilaire Fernandes

Don't worry, we are already building cool stuff with Pharo! Hilaire Le 23/07/2011 20:51, StÃ©phane Ducasse a Ã©crit : > A final word on this thread. We are not changing for the sake of it. With time we are just getting to lower parts of the system. > I imagine that slowly we will arrive to a fixpoint in certain areas. And this is good. I would like to be able to focus on my research > and build cool stuff on top of pharo. > Now we are working on a roadmap slideshow to show where we are working and what is on our radar so that you can understand it. > > Stef > > > -- Education 0.2 -- http://blog.ofset.org/hilaire

July 24, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Norbert Hartl

Am 23.07.2011 um 20:51 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > A final word on this thread. We are not changing for the sake of it. With time we are just getting to lower parts of the system. > I imagine that slowly we will arrive to a fixpoint in certain areas. And this is good. I would like to be able to focus on my research > and build cool stuff on top of pharo. > Now we are working on a roadmap slideshow to show where we are working and what is on our radar so that you can understand it. > great! Norbert

July 23, 2011

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

A final word on this thread. We are not changing for the sake of it. With time we are just getting to lower parts of the system. I imagine that slowly we will arrive to a fixpoint in certain areas. And this is good. I would like to be able to focus on my research and build cool stuff on top of pharo. Now we are working on a roadmap slideshow to show where we are working and what is on our radar so that you can understand it. Stef

July 23, 2011

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] help needed with the new FFI plugin...

by Levente Uzonyi

On Fri, 22 Jul 2011, Eliot Miranda wrote: > But getting the FFI working on ARM and/or PPC is more effective than writing yet another plugin, no? Â We can always add security to the FFI (essentially some > way of disabling internal calls within the FFI plugin, e.g. based on cryptographic keys to enable it, or whatever). Â So I really do appeal to people to help me > put the effort in here. Â I can't justify working on the FFI on ARM or PPC in my Cadence Newspeak gig; we're entirely on x86. Â I /can/ work on the threaded FFI > as we need it at Cadence, just as many other people need it. Â But for me to move the threaded FFI ahead it needs to be on all platforms and that means I need > help on the platforms I can't justify working on. > > So folks, please give serious consideration to putting effort into something that may be a little harder at first but will yield major benefits slightly later. >Â Let's defer gratification :) QEMU can be used for emulating various CPUs, so if you don't have an ARM, PPC or SPARC hardware, you can still develop/test FFI with it. Threaded FFI is great, it opens new possibilities, but nowadays the feature I miss the most is the ability to call functions in 64-bit (x86_64) libraries (from a 32-bit VM/image). Levente

July 23, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Norbert Hartl

Am 22.07.2011 um 22:15 schrieb StÃ©phane Ducasse: >>> >> I don't know. But I think Hillaire had a point in here. > > what point? > We want to change and rewrite all the tools. Now we can only do that with people working. > Now we remove the inheritance class browser. and now if you want to see the implementor of add: then you do not use inheritance anymore. > You should use implementors or you help in nautilus and rpackage because nautilus implement inheritance. > >> There is a change rate a community can cover. As we like to change code it is ok that things break. If complaints about broken things raise than you should see that you overstretched your capability and need to think again. > > Yes but I do not think that we are in this situation. Ok. > The point is to consider the ratio of changes vs bugs. Well, that's what I'm saying. > I can pay Igor one and half year after igor may be forced to sell his PHP skills again :(. > So we can go slowly and play cards and watch videos, but this means that less will be done. > > Or we break some stuff from time to time and this is ok and we move at the speed we believe is good. > Right now I'm not even working a day a week on Pharo but if I would work more I would not catch more bugs because > these "bugs" are stuff that I never use. So if people use different scenario than us, how can we know it without them raising > problems? > Thanks Stef for always answering verbose :) I can see that you have more typical kind of project management problems combined with a community. I don't want to talk against anything. In the last weeks I just heard a lot of complaints from some "more core" developers about complaints from others "not so core". And I can't see much sense in "complaining about complaining". That's all. Norbert > > Stef > >> The type of replies I replied to just prove that someone is tired listening. And at least I'm pretty sure that listening is essential. >> >> Norbert > >

July 23, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Hilaire Fernandes

Le 23/07/2011 11:01, StÃ©phane Ducasse a Ã©crit : >> That's ok but beware enduser (developer) will not specially want to know >> about the detail about why it does not work. > > sorry but open-source dev is not like off the shelf tools. Knowing why things change are also important. > We are building in addition to software a social community. Sure, but the users in opensource are also very volatile, I know by experience how hard it can beat you. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

July 23, 2011

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

On Jul 23, 2011, at 9:40 AM, Hilaire Fernandes wrote: > Le 22/07/2011 22:17, StÃ©phane Ducasse a Ã©crit : > >>> - inheritance in the browser broken: >>> http://code.google.com/p/pharo/issues/detail?id=4545 >> >> sorry but I guess that in 1.3 you will not have that. May be we should ask for implementors instead. >> We will rewrite all the tools and the results will be different. We want to avoid to have to maintain >> two or three times the same behavior especially with the quality of the old code. > > That's ok but beware enduser (developer) will not specially want to know > about the detail about why it does not work. sorry but open-source dev is not like off the shelf tools. Knowing why things change are also important. We are building in addition to software a social community. > May be 1.3 should be marked > as an intermediate release, not for production or things like that. it is not an intermediate release > > Hilaire > > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

July 23, 2011