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

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

> 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 where? > - the revert just does not work do you have a scenario > May be the rate of release could be slow down to get properly working > Image, no ? Not really. When you pay a person for 3 months of work you cannot ask him to work for a year slowler. We payed benjamin for a couple of months and after we can just be happy that he is doing post actions especially when the semester will restart it will be more difficult. > 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. Which patch? Where is the bug entry? On which image? breaking where? Stef > > 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

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

by StÃ©phane Ducasse

Excellent news! I love your process (as usual). STef On Jul 22, 2011, at 6:19 AM, NicolÃ¡s Paez wrote: > 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] I would like to have more contributors in the list on the web

by Johannes Rasche

Hi Stef, here is my offer: Johannes Rasche now doing what may be worth the effort both for myself and whoever appreciates it developing a smart and handy gadget to maintain virtual, taggable pin boards communicating P2P http://myNeat.org with Pharo and later Seaside as well Am 21.07.2011 um 15:43 schrieb StÃ©phane Ducasse: > hi guys > > > did you ever see this cool list > http://www.pharo-project.org/community/contributors? > > I want more names and picture on it. > Please consider sending a picture. > > Stef >

July 22, 2011

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

by Norbert Hartl

Great! Thanks, Eliot! That could change a lot of things. Norbert Am 22.07.2011 um 01:34 schrieb 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] 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 21, 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 21, 2011