June 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI problem

by Benoit St-Jean

Yep. Here's the dump file (see attachment). As you'll see, not much there! A nasty VM crash! Nothing in the stack dump section! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Mariano Martinez Peck <marianopeck(a)gmail.com> To: Andreas Raab <andreas.raab(a)gmx.de> Cc: Pharo-project(a)lists.gforge.inria.fr Sent: Saturday, June 27, 2009 6:24:25 PM Subject: Re: [Pharo-project] FFI problem On Fri, Jun 26, 2009 at 6:15 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: Mariano Martinez Peck wrote: Download latest Windows VM (Squeak 3.11.2) from Pharo webpage. Then evaluate ScriptLoader loadFFI and try to run FFI tests. The image will crash! Interesting. This appears to be a Pharo-only problem. I ran the FFI tests using the 3.11.2 VM on the current 3.10.2 release image and they works fine. I've also ran the test against a 3.10.2 closure converted image (on the off-chance that it might be closure related) and the tests pass too. So I don't really think it's an FFI problem. You'll probably have to ask Pharo people to help you with the problem; the FFI appears to be fully functional on both pre- and post-closure images. Ok. Pharo people is in this mail. Let's wait if someone can help us. I don't know why in mi Windows machine the dump file is not generated :( Benoit St-Jean can you attach the complete dump file? I tried this in Linux and it doesn't crash my image. So, only windows :( Cheers, Mariano Cheers, - Andreas __________________________________________________________________ The new Internet ExplorerÂ® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

June 28, 2009

Re: [Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by Schwab,Wilhelm K

GÃ¶ran, Pharo is not even at beta, and has some speed and (Stef's reaction) stability problems. Having read Stef's recent reply to me, I'm wondering whether some of the performance/response time problems are related to input starvation, or a false assumption of same. My vote would be to let Pharo mature under its current leadership and then worry about whether to merge the two projects. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of GÃ¶ran Krampe Sent: Saturday, June 27, 2009 4:45 PM To: pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: [Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean) Hi all! Matthew Fulmer wrote: > Awesome job guys. The volume of improvements Pharo has over Squeak > really makes me wonder if the latter has any real relevance anymore. Yes, it is quite an interesting situation IMHO, and one that most of us could foresee too I think. NOTE: Read the following with a nice bucket of love, ok? I don't intend to make anyone upset. :) And sorry for the long post. On one hand I really appreciate the Pharo project - lots of good people doing lots of good progress etc. It seems to be doing simply great. On the other hand the "negative" effect I can see is the "drain" it has caused (I think) from squeak.org/squeak-dev. In other words, squeak.org has lost a lot of momentum, and of course not only due to the birth of Pharo I should add. And in many ways Pharo may also be the "rescue" to squeak.org. God knows we have been trying to find "our way" lately and with... less impressive results. :) So... how will the future evolve? Does the Squeak community (in the large sense) have anything to gain from keeping both the squeak.org and the pharo fork "alive"? I presume we have at least the following three scenarios: 1. Continue as now and take no specific action. This will probably lead to Squeak.org going weaker and Pharo stronger by the day. Developers will want to be where the "action" is. Soon squeak.org turns irrelevant and dies a slow death. 2. Take some decisive action and "merge" the two in some *smart* way beneficial to both. Impossible? I hope not. 3. Just kill off squeak.org. A mercy kill :). Then people could move over to Pharo without having to think about it - there is no other "Squeak". Eh, well, my analysis is probably full of silly holes here. Looking at the above, 1 and 3 feels less nice. So how could a "merge" look that would be attractive to *both* camps? I call the theoretical merged project Phreak below (but I am not proposing name changes etc, but I need a name to use in the text). Pharo characteristics: - A small "benevolent dictator" board. Lots of action, less talk. - Has a very clear stated "direction". - Has a website using CMSBox. - Uses Google code for issue tracker and wiki. - Has Mailman mailinglists and downloads at gforge.inria.fr (I think) Squeak.org org characteristics: - Has an elected SOB, an election process and a Team model. The jury is still out I think, we seem to have lots of trouble "getting shit done". - Has very little stated "direction" at the moment. - Has a website using Swazoo. - Uses Mantis, Swiki, file archive and Mailman on a community paid Hetzner server. Now... why would Squeak.org want to merge with Pharo? Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important! Cons: The SOB & Team model would probably have to be dropped. The work made since Pharo forked may or may not be a "lost cause", that depends on if Phreak is interested in utilizing that work. Other cons? ...and Pharo? Pros: An influx of developers. A much stronger position as Phreak would be Squeak + Pharo. No "compatibility" to worry about, Squeak is out of the picture. Cons: Some people in Pharo may perceive such a merge as dangerous since they might be afraid that certain aspects of Squeak.org (that Pharo was created in order to escape from) is coming back "knocking on the door". I personally don't think there is such a danger if Phreak simply adopts the simple organisation of Pharo (with board and all) BUT... since it would make the Pharo community much *larger* the effects of that growth need to be taken into account. But Pharo should not fear growth, because that would be an odd position. How could a merge be done practically? I really don't know :). And I must stop typing now, this post is waaaaay to long anyway and I have probably stepped on too many toes already. regards, GÃ¶ran _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2009

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

On Fri, Jun 26, 2009 at 6:15 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Mariano Martinez Peck wrote: > >> Download latest Windows VM (Squeak 3.11.2) from Pharo webpage. Then >> evaluate ScriptLoader loadFFI and try to run FFI tests. The image will >> crash! >> > > Interesting. This appears to be a Pharo-only problem. I ran the FFI tests > using the 3.11.2 VM on the current 3.10.2 release image and they works fine. > I've also ran the test against a 3.10.2 closure converted image (on the > off-chance that it might be closure related) and the tests pass too. So I > don't really think it's an FFI problem. You'll probably have to ask Pharo > people to help you with the problem; the FFI appears to be fully functional > on both pre- and post-closure images. > Ok. Pharo people is in this mail. Let's wait if someone can help us. I don't know why in mi Windows machine the dump file is not generated :( Benoit St-Jean can you attach the complete dump file? I tried this in Linux and it doesn't crash my image. So, only windows :( Cheers, Mariano > > Cheers, > - Andreas >

June 27, 2009

Re: [Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by Igor Stasenko

2009/6/28 GÃ¶ran Krampe <goran(a)krampe.se>: > Hi all! > > Matthew Fulmer wrote: >> Awesome job guys. The volume of improvements Pharo has over >> Squeak really makes me wonder if the latter has any real >> relevance anymore. > > Yes, it is quite an interesting situation IMHO, and one that most of us > could foresee too I think. > > NOTE: Read the following with a nice bucket of love, ok? I don't intend > to make anyone upset. :) And sorry for the long post. > > On one hand I really appreciate the Pharo project - lots of good people > doing lots of good progress etc. It seems to be doing simply great. > > On the other hand the "negative" effect I can see is the "drain" it has > caused (I think) from squeak.org/squeak-dev. In other words, squeak.org > has lost a lot of momentum, and of course not only due to the birth of > Pharo I should add. And in many ways Pharo may also be the "rescue" to > squeak.org. God knows we have been trying to find "our way" lately and > with... less impressive results. :) > > So... how will the future evolve? Does the Squeak community (in the > large sense) have anything to gain from keeping both the squeak.org and > the pharo fork "alive"? > > I presume we have at least the following three scenarios: > > 1. Continue as now and take no specific action. This will probably lead > to Squeak.org going weaker and Pharo stronger by the day. Developers > will want to be where the "action" is. Soon squeak.org turns irrelevant > and dies a slow death. > > 2. Take some decisive action and "merge" the two in some *smart* way > beneficial to both. Impossible? I hope not. > > 3. Just kill off squeak.org. A mercy kill :). Then people could move > over to Pharo without having to think about it - there is no other "Squeak". > > Eh, well, my analysis is probably full of silly holes here. Looking at > the above, 1 and 3 feels less nice. So how could a "merge" look that > would be attractive to *both* camps? I call the theoretical merged > project Phreak below (but I am not proposing name changes etc, but I > need a name to use in the text). > > Pharo characteristics: > > - A small "benevolent dictator" board. Lots of action, less talk. > - Has a very clear stated "direction". > - Has a website using CMSBox. > - Uses Google code for issue tracker and wiki. > - Has Mailman mailinglists and downloads at gforge.inria.fr (I think) > > Squeak.org org characteristics: > > - Has an elected SOB, an election process and a Team model. The jury is > still out I think, we seem to have lots of trouble "getting shit done". > - Has very little stated "direction" at the moment. > - Has a website using Swazoo. > - Uses Mantis, Swiki, file archive and Mailman on a community paid > Hetzner server. > > Now... why would Squeak.org want to merge with Pharo? > > Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important! > > Cons: The SOB & Team model would probably have to be dropped. The work > made since Pharo forked may or may not be a "lost cause", that depends > on if Phreak is interested in utilizing that work. Other cons? > > ...and Pharo? > > Pros: An influx of developers. A much stronger position as Phreak would > be Squeak + Pharo. No "compatibility" to worry about, Squeak is out of > the picture. > > Cons: Some people in Pharo may perceive such a merge as dangerous since > they might be afraid that certain aspects of Squeak.org (that Pharo was > created in order to escape from) is coming back "knocking on the door". > > I personally don't think there is such a danger if Phreak simply adopts > the simple organisation of Pharo (with board and all) BUT... since it > would make the Pharo community much *larger* the effects of that growth > need to be taken into account. But Pharo should not fear growth, because > that would be an odd position. > > How could a merge be done practically? I really don't know :). And I > must stop typing now, this post is waaaaay to long anyway and I have > probably stepped on too many toes already. > Hello Goran. You are definitely didn't stepped on any of my toes/toys. And i would certainly sacrifice my SOB membership (if this is a sacrifice), to see things moving & progressing as fast as they do in Pharo. As many others, i eagier to see the squeak/pharo/phreak shining - make it cool & modern software. The rest of things is barely bothering me. What i like in Pharo, that they make decisions on strictly technical basis - no politics. If code is good - it candidate to be included. If code stinks - its a candidate to be excluded. Simple concept :) For anyone, interested in my opinion: i would put a huge +1 for a merge on a Pharoer's conditions. > regards, GÃ¶ran > > > _______________________________________________ > 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.

June 27, 2009

[Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by GÃ¶ran Krampe

Hi all! Matthew Fulmer wrote: > Awesome job guys. The volume of improvements Pharo has over > Squeak really makes me wonder if the latter has any real > relevance anymore. Yes, it is quite an interesting situation IMHO, and one that most of us could foresee too I think. NOTE: Read the following with a nice bucket of love, ok? I don't intend to make anyone upset. :) And sorry for the long post. On one hand I really appreciate the Pharo project - lots of good people doing lots of good progress etc. It seems to be doing simply great. On the other hand the "negative" effect I can see is the "drain" it has caused (I think) from squeak.org/squeak-dev. In other words, squeak.org has lost a lot of momentum, and of course not only due to the birth of Pharo I should add. And in many ways Pharo may also be the "rescue" to squeak.org. God knows we have been trying to find "our way" lately and with... less impressive results. :) So... how will the future evolve? Does the Squeak community (in the large sense) have anything to gain from keeping both the squeak.org and the pharo fork "alive"? I presume we have at least the following three scenarios: 1. Continue as now and take no specific action. This will probably lead to Squeak.org going weaker and Pharo stronger by the day. Developers will want to be where the "action" is. Soon squeak.org turns irrelevant and dies a slow death. 2. Take some decisive action and "merge" the two in some *smart* way beneficial to both. Impossible? I hope not. 3. Just kill off squeak.org. A mercy kill :). Then people could move over to Pharo without having to think about it - there is no other "Squeak". Eh, well, my analysis is probably full of silly holes here. Looking at the above, 1 and 3 feels less nice. So how could a "merge" look that would be attractive to *both* camps? I call the theoretical merged project Phreak below (but I am not proposing name changes etc, but I need a name to use in the text). Pharo characteristics: - A small "benevolent dictator" board. Lots of action, less talk. - Has a very clear stated "direction". - Has a website using CMSBox. - Uses Google code for issue tracker and wiki. - Has Mailman mailinglists and downloads at gforge.inria.fr (I think) Squeak.org org characteristics: - Has an elected SOB, an election process and a Team model. The jury is still out I think, we seem to have lots of trouble "getting shit done". - Has very little stated "direction" at the moment. - Has a website using Swazoo. - Uses Mantis, Swiki, file archive and Mailman on a community paid Hetzner server. Now... why would Squeak.org want to merge with Pharo? Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important! Cons: The SOB & Team model would probably have to be dropped. The work made since Pharo forked may or may not be a "lost cause", that depends on if Phreak is interested in utilizing that work. Other cons? ...and Pharo? Pros: An influx of developers. A much stronger position as Phreak would be Squeak + Pharo. No "compatibility" to worry about, Squeak is out of the picture. Cons: Some people in Pharo may perceive such a merge as dangerous since they might be afraid that certain aspects of Squeak.org (that Pharo was created in order to escape from) is coming back "knocking on the door". I personally don't think there is such a danger if Phreak simply adopts the simple organisation of Pharo (with board and all) BUT... since it would make the Pharo community much *larger* the effects of that growth need to be taken into account. But Pharo should not fear growth, because that would be an odd position. How could a merge be done practically? I really don't know :). And I must stop typing now, this post is waaaaay to long anyway and I have probably stepped on too many toes already. regards, GÃ¶ran

June 27, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by StÃ©phane Ducasse

> Stef, > > Sometimes I wonder whether the response times are to blame. > <forDebate>Something that should happen in 0.1 seconds ends up > taking several seconds, user gets suspicious that image has locked > up, pokes around with the mouse (almost instinctive), and confuses > the image</forDebate>. I think that the input sensor was complex and that some existing code should be really fix and may be the sensor code contain some bugs. For example, we got some problem with moose and we could not bring a debugger. Stef >

June 27, 2009

Re: [Pharo-project] [ANN] Pharo MIT license clean

by StÃ©phane Ducasse

Matthew > Awesome job guys. Thanks. > The volume of improvements Pharo has over > Squeak really makes me wonder if the latter has any real > relevance anymore. I do not know and in itself this is not our goal. We do not do pharo against Squeak. We do pharo to be able to dream about Smalltalk. We are committed (even more than for 3.9 which I think was a success even if there are some points I would reconsider :)) Now people are welcome to pharo. But Pharo will not be squeak. We want to create a culture where better, faster, more tested, more documented, new, well-designed, not compatible changes are possible and wished. :) I'm still profoundly sad to remove etoy or complex related morphic stuff. May be some people will reimplement some solutions that were already in squeak, but this is the way to go. Cleaning and making the system lean so that we and other can invent their future. >> [1] http://code.google.com/p/pharo/wiki/ResultofRelicensing >> [2] http://code.google.com/p/pharo/wiki/LicenseCleanEffort > > It looks like you did the relicense perfectly. I'm glad the > image I put together was able to help you. I'm sorry I didn't > help more. it was great that you provided the resources. It helped a lot. I could play with the idea and this really lowered the barrier. So be sure that you participated. :) Stef PS: I should check some pending items of what you did (MC1.5.....) just life is too short. PSPS: I hope your master is going well.

June 27, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Schwab,Wilhelm K

Stef, Sometimes I wonder whether the response times are to blame. <forDebate>Something that should happen in 0.1 seconds ends up taking several seconds, user gets suspicious that image has locked up, pokes around with the mouse (almost instinctive), and confuses the image</forDebate>. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, June 27, 2009 3:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Fix to issue 825 argh. Let us know if you can reproduce that. I think that we changed a lot and pharo 1.0 may be less stable than Squeak3.9

June 27, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Schwab,Wilhelm K

Hernan, I've had some hangups, some of which I think were OB related; either it took a terribly long time to respond, or it got confused over package names - not sure which - I finally recovered what I could and started a new image. A few times, I have successfully broken out of an apparent lockup. BTW, that's another argument for keeping notifiers - why add add an extra second or two for the full debugger to open when a notifier is enough to let the user know the interrupt was "seen." The other place I have lost work is accepts in either the debugger or (less of a problem) a browser going into the ether. In the case of the browser, I wonder whether the category or other context was correctly set?? Concerns over response times aside, which OS are you using? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hernan Wilkinson Sent: Saturday, June 27, 2009 2:24 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Fix to issue 825 > > With this fix, all changes made to classes like adding instance > variables, class variables, changing method categories, changing > class package, etc. are saved to the changes file. I spend some time > trying to find the best way to do it, like Stef said some time ago, > the code is not easy to understand, so I decided to do it the > simplest way. So each method that changes something in the class, it > also logs the change. The good thing is that no matter where the > change is made, it is saved. Did you pay attention that certain operation are silent (do not add to the change) right now is saving all the changes to the log. I saw something about doit silent but I do not understand why a change should not be save, why is that? > The drawback is that when changing a class from the browser's code > panel, it saves the definition twice. All the changes are saved as > "doit", so no change to the file in was necessary. What do you mean by doit? Normally only class def (which is a mistake) are saved like doit. I agree that it is a mistake, but I think that the first steep is to save everything. The next one should be to change the format. I needed this fix becuase I lost a lot of work because pharo hanged on me many times... > Ironically, I had a power down issue when testing it, so I did not > loose anything! (and help me to find a bug). > All the changes are tested. See ClassOrganizerTest, ClassTest and > StandardSourceFileArrayTest Hernan can you open an issue in the Bugtracker I did, it is the 825, it is in the subject :-) Stef > > Bye, > Hernan. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by StÃ©phane Ducasse

On Jun 27, 2009, at 9:24 PM, Hernan Wilkinson wrote: > > > > With this fix, all changes made to classes like adding instance > > variables, class variables, changing method categories, changing > > class package, etc. are saved to the changes file. I spend some time > > trying to find the best way to do it, like Stef said some time ago, > > the code is not easy to understand, so I decided to do it the > > simplest way. So each method that changes something in the class, it > > also logs the change. The good thing is that no matter where the > > change is made, it is saved. > > Did you pay attention that certain operation are silent (do not add to > the change) > > right now is saving all the changes to the log. I saw something > about doit silent but I do not understand why a change should not be > save, why is that? because sometimes you want to install code without polluting the changes set - halt - breakpoint and all kinds of trickery > > The drawback is that when changing a class from the browser's code > > panel, it saves the definition twice. All the changes are saved as > > "doit", so no change to the file in was necessary. > > What do you mean by doit? > Normally only class def (which is a mistake) are saved like doit. > > I agree that it is a mistake, but I think that the first steep is to > save everything. The next one should be to change the format. yes having something more declarative and object-oriented > I needed this fix becuase I lost a lot of work because pharo hanged > on me many times... argh. Let us know if you can reproduce that. I think that we changed a lot and pharo 1.0 may be less stable than Squeak3.9 > > > Ironically, I had a power down issue when testing it, so I did not > > loose anything! (and help me to find a bug). > > All the changes are tested. See ClassOrganizerTest, ClassTest and > > StandardSourceFileArrayTest > > Hernan can you open an issue in the Bugtracker > > I did, it is the 825, it is in the subject :-) OK :) > > > > > > Stef > > > > Bye, > > Hernan. > > > > > > _______________________________________________ > > 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

June 27, 2009