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

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

Re: [Pharo-project] Time Profile mostly unusable

by Hilaire Fernandes

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. May be 1.3 should be marked as an intermediate release, not for production or things like that. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

July 23, 2011

[Pharo-project] [update 1.4] #14059

by stephane ducasse

14059 ----- - Issue 4546: Time Profiler copy. Second fix. http://code.google.com/p/pharo/issues/detail?id=4546 - Issue 4543: Wrong calculated size of objects in memory. http://code.google.com/p/pharo/issues/detail?id=4543 Stef

July 22, 2011

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

by Ricardo Moran

On Fri, Jul 22, 2011 at 1:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Fri, Jul 22, 2011 at 9:08 AM, Ricardo Moran <richi.moran(a)gmail.com>wrote: > >> Yes, indeed. Right now, for most use cases we use the SerialPort class, >> but we still have some FFI code for other stuff hanging around. I plan to >> write it as a plugin as soon as I have the time. > > > 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 :) > > Hi Eliot, I would love to help but I don't have the hardware nor the knowledge to do it. Sorry... Cheers, Richo > > >> Cheers, >> RIcho >> >> >> On Fri, Jul 22, 2011 at 10:37 AM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: >> >>> It's not part of Etoys yet. If its low-level interface indeed requires >>> FFI, then that interface would have to be rewritten as plugin for Etoys to >>> include it. >>> >>> - Bert - >>> >>> On 22.07.2011, at 14:55, karl ramberg wrote: >>> >>> What about the Physical Etoys project ? >>> http://tecnodacta.com.ar/gira/projects/physical-etoys/ >>> >>> Karl >>> >>> On Fri, Jul 22, 2011 at 2:20 PM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: >>> >>>> >>>> On 22.07.2011, at 02:10, Eliot Miranda wrote: >>>> >>>> > >>>> > >>>> > On Thu, Jul 21, 2011 at 4:57 PM, Igor Stasenko <siguctua(a)gmail.com> >>>> wrote: >>>> > On 22 July 2011 02:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> > > Hi All, >>>> > > today I committed the threaded FFI plugin along with the >>>> threaded VM and >>>> > > hope to be able to support people in doing threaded FFI work on the >>>> x86 >>>> > > platforms really soon now (Esteban, amongst others, this means you >>>> ;) ). >>>> > > But to put the image-level code that uses the new FFI plugin into >>>> > > production the standard VM needs to be upgraded to not crash with >>>> the >>>> > > ExternalFunction image changes the new threaded FFI plugin wants. >>>> The main >>>> > > change is that ExternalFunction changes size, gaining a stackSize >>>> inst var >>>> > > which is used to tell the FFI plugin how much stack spacer to >>>> reserve for >>>> > > marshalling (its computed on first use). The best way for this to >>>> happen is >>>> > > to start using the ThreadedFFIPlugin as the standard plugin in the >>>> > > Interpreter VM. The ThreadedFFIPlugin overall is simpler than the >>>> old FFI >>>> > > plugin (no assembler support code) and better (fully reentrant). >>>> But for >>>> > > this to happen we may need to implement the platform=specific parts >>>> of >>>> > > the ThreadedFFIPlugin (still entirely Smalltalk code) for PowerPC >>>> and ARM >>>> > > (and perhaps others, SPARC??). I understand what has to be done and >>>> I can >>>> > > explain it to anyone interested in working on the problem, but I >>>> don't have >>>> > > any hardware with which I can test the results so its pretty >>>> pointless my >>>> > > doing the work and producing something inevitably broken. So are >>>> there >>>> > > people out there who would be interested in doing the port to PPC >>>> and ARM? >>>> > > It means fleshing out the classes >>>> > > ThreadedARMFFIPlugin ThreadedFFICalloutStateForARM >>>> > > ThreadedPPCBEFFIPlugin ThreadedFFICalloutStateForPPC >>>> > > and having a solid understanding of how alloca works to do stack >>>> allocation >>>> > > and how the ABIs on ARM and PPC pass registers. >>>> > > here's hoping there are a few good low-level people who would be >>>> interested. >>>> > > Let me know. >>>> > >>>> > I wonder if you find anyone today using these archs, not saying using >>>> > squeak/pharo on them + knowing low-level details + wanting to help :) >>>> > >>>> > Right, chances are thin. But then if no one is interested then the >>>> work doesn't need to be done. Bert, you mentioned the other day that PPC >>>> was still relevant for etoys. But am I right in thinking etoys never uses >>>> the FFI? >>>> >>>> Right. Etoys should run on both ARM and PPC, but it does not use FFI. >>>> >>>> - Bert - >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > -- > best, > Eliot > > >

July 22, 2011

Re: [Pharo-project] About the site

by Igor Stasenko

On 22 July 2011 23:10, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Pharo 1.4 is not easily accessible from the site > http://www.pharo-project.org/home > Also true for the new Jenkins continuous integration server > https://ci.lille.inria.fr/pharo/ yeah.. it was down for a week .. delaying my work on migrating jobs from hudson :( > > Pharo 1.3 is listed as unstable, and not in released. Hasn't it been > released yet ? > Generally, where should problems with the site be reported ? > > Nicolas > -- Best regards, Igor Stasenko AKA sig.

July 22, 2011

[Pharo-project] [update 1.4] #14058

by stephane ducasse

14058 ----- Issue 4546: Time Profiler copy. Thanks Alain Plantec and Hilaire Fernandez.

July 22, 2011

Re: [Pharo-project] About the site

by StÃ©phane Ducasse

To this list. Thanks nicolas. Yes we should change that. Indeed we should improve. My problem is that I lost my password and I'm often unable to understand how to edit information (links and the rest) So adrian/marcus can you have a look? On Jul 22, 2011, at 10:10 PM, Nicolas Cellier wrote: > Pharo 1.4 is not easily accessible from the site > http://www.pharo-project.org/home > Also true for the new Jenkins continuous integration server > https://ci.lille.inria.fr/pharo/ > > Pharo 1.3 is listed as unstable, and not in released. Hasn't it been > released yet ? > Generally, where should problems with the site be reported ? > > Nicolas >

July 22, 2011