- Pharo-dev - lists.pharo.org

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

by Janko MivÅ¡ek

Wow, Eliot, thanks for that so long waited function a lot! Threaded FFI is namelly a must for Squeak/Pharo to be used seriously everywhere where a connection to the other worlds is needed. Which is a common situation when working on "enterprise" level information systems. Thanks again! Thanks also to all investors/donators who invested to this so important work! Janko S, Eliot Miranda piÅ¡e: > 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. > -- > best, > Eliot > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 22, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Norbert Hartl

Am 21.07.2011 um 20:29 schrieb Mariano Martinez Peck: > > > On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it depends on your scenario and when users do not use or use the tool differently you get different feedback. > > Or even better: if noboy says anything in the last 6 months while Pharo 1.3 was being developed/tested then we cannot do magic. > I am tired of saying that anything that YOU don't test, can be broken. Seems I learned something today. I never understood TDD as "I develop, YOU test" type of development. Thanks for clarifying. Norbert > > > Stef > > On Jul 21, 2011, at 1:48 PM, Hilaire Fernandes wrote: > > > In Pharo 1.3, the new Time Profile is unusable (the one you get from > > profiling the UI): > > > > - In the resulting window clicking in a line cause an error > > - WORST: there is no way (at least obvious one) to copy and past the > > resulting profile in an external file. > > > > When replacing the tools, beware to replace with working ones otherwise > > developers may run away. > > > > I am updating my image to see if it is a temporary problem. > > > > Hilaire > > > > -- > > Education 0.2 -- http://blog.ofset.org/hilaire > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 22, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Hilaire Fernandes

Given the amount of changes in Pharo it is normal stuffs get broken and some tests need to be human conducted, therefore a list of features to test before release could be used to review the needed working features. Wiki shared, the workload on this list can be easily contributed by anyone. I just see problem in the the version tool of the browser: - the tool does not show the diff properly: no way to read what is new and old - the revert just does not work May be the rate of release could be slow down to get properly working Image, no ? Regarding the problem with the Time Profile, I see a patch from Bert, but upgrading my image just broke, so I can't test it for now. Hilaire Le 21/07/2011 21:09, StÃ©phane Ducasse a Ã©crit : > this is mainly a ui concern. > > On Jul 21, 2011, at 8:58 PM, Igor Stasenko wrote: > >> On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> it depends on your scenario and when users do not use or use the tool >>>> differently you get different feedback. >>> >>> Or even better: if noboy says anything in the last 6 months while Pharo 1.3 >>> was being developed/tested then we cannot do magic. >>> I am tired of saying that anything that YOU don't test, can be broken. >>> >> >> why "can be"? it definitely will be broken. >> >> What would be nice is to write tests for TimeProfileBrowser to prevent >> regressions. >> Any ideas? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Education 0.2 -- http://blog.ofset.org/hilaire

July 22, 2011

[Pharo-project] [PBE-Spanish] Status update 2011-07-21

by NicolÃ¡s Paez

Hello everyone, I glad to announce that we have reached Code Complete, that is, ALL the chapters has been translated. Now is time to start with the revision phase in order to have the final version before Smalltalks 2011 (November). If you want to help with the revision and have enough time to read 3* chapters within a month, just contact me. *(we want each reviewer to read 3 chapters in order to ensure not only the translation itself but also the consistency between chapter, and the time frame of n1 month is just to be able to complete the work before November) Saludos! NicoPaez. blog: nicopaez.wordpress.com

July 22, 2011

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

by Igor Stasenko

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 :) > -- > best, > Eliot > -- Best regards, Igor Stasenko AKA sig.

July 22, 2011

[Pharo-project] help needed with the new FFI plugin...

by Eliot Miranda

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

July 22, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Schwab,Wilhelm K

I was able to write some pretty reasonable tests for gui elements in Dolphin. Getting something to open/close and in between, firing a few commands at it can be informative, sometimes ~:0 ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, July 21, 2011 3:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Time Profile mostly unusable this is mainly a ui concern. On Jul 21, 2011, at 8:58 PM, Igor Stasenko wrote: > On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> it depends on your scenario and when users do not use or use the tool >>> differently you get different feedback. >> >> Or even better: if noboy says anything in the last 6 months while Pharo 1.3 >> was being developed/tested then we cannot do magic. >> I am tired of saying that anything that YOU don't test, can be broken. >> > > why "can be"? it definitely will be broken. > > What would be nice is to write tests for TimeProfileBrowser to prevent > regressions. > Any ideas? > > -- > Best regards, > Igor Stasenko AKA sig. >

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 21.07.2011 21:03, Philippe Marschall wrote: > On 21.07.2011 09:08, Lukas Renggli wrote: >>> Good energy is not going the fix the Seaside repository. >> >> Stop complaining. >> >> Let's build a Gofer script that resaves a series of versions. If we >> load each version from the last correct one and safe each over the >> existing one everything should be fine again. I can help, but I only >> have an iPhone available right now :-) > > Yeah, but we must not load the new versions using Monticello otherwise > they'll be in the ancestry again. We must extract the source.st from the > .mcz file and then file that in. However this will not work for > removed/renamed methods or classes, they'll stay in the image. We could > just unload the package but then we get undeclareds and we'd have to > recompile all dependencies. Also, you have to take care computing the ancestry because of the duplicate UUIDs. I guess for merges you could get away with following just one path. Cheers Philippe

July 21, 2011

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

this is mainly a ui concern. On Jul 21, 2011, at 8:58 PM, Igor Stasenko wrote: > On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> it depends on your scenario and when users do not use or use the tool >>> differently you get different feedback. >> >> Or even better: if noboy says anything in the last 6 months while Pharo 1.3 >> was being developed/tested then we cannot do magic. >> I am tired of saying that anything that YOU don't test, can be broken. >> > > why "can be"? it definitely will be broken. > > What would be nice is to write tests for TimeProfileBrowser to prevent > regressions. > Any ideas? > > -- > Best regards, > Igor Stasenko AKA sig. >

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 21.07.2011 09:08, Lukas Renggli wrote: >> Good energy is not going the fix the Seaside repository. > > Stop complaining. > > Let's build a Gofer script that resaves a series of versions. If we > load each version from the last correct one and safe each over the > existing one everything should be fine again. I can help, but I only > have an iPhone available right now :-) Yeah, but we must not load the new versions using Monticello otherwise they'll be in the ancestry again. We must extract the source.st from the .mcz file and then file that in. However this will not work for removed/renamed methods or classes, they'll stay in the image. We could just unload the package but then we get undeclareds and we'd have to recompile all dependencies. Cheers Philippe

July 21, 2011