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

[Pharo-project] readFrom: vs readFromString:

by Nicolas Cellier

There is a huge mess in #readFrom: implementation. Some classes will signal trailing characters as a bug, some other won't and will simply leave the stream positioned after the valid part. I propose to change this behaviour uniformly: - readFrom: aStream will never fail on trailing chars (hey, it's a stream, it's up to sender to interpret the tail) - readFromString: aString will always forbid trailing char (it's not a stream, so this garbage is most probably an error and cannot be ignored silently) What do you think ? Nicolas

Oct. 30, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Marcus Denker

On Oct 30, 2011, at 4:00 PM, Mariano Martinez Peck wrote: > Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. > Attach here the dump file and the PharoDebug.log no problem. That should have been fixed in 13315... Now what would be nice is to run automatically all tests on the last VM on all three architectures. Will we ever reach that goal? Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Mariano Martinez Peck

Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. Attach here the dump file and the PharoDebug.log no problem. Did you also try in pharo 1.4 ? just to see if it works there. thanks On Sun, Oct 30, 2011 at 3:49 PM, Ben Coman <btc(a)openinworld.com> wrote: > Ben Coman wrote: > >> Marcus Denker wrote: >> >>> Please test... >>> >>> https://gforge.inria.fr/frs/**download.php/29274/Pharo-1.3-** >>> 13315-OneClick.zip<https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> I've spent the weekend trying to isolate a VM crash varying the >> conditions under which pharo.exe runs. The user steps to reproduce are >> minimal: >> 1. Run pharo.exe >> 2. Open TestRunner >> 3. Click <Run Selected> >> ...but this leaves a lot of possibilities. >> >> I have Windows 7 and I usually operate under a non-admin account, but >> also did testing with an admin account. I got the feeling the problem is >> network related. During the test run a Windows Security Alert regarding >> the firewall blocking functionality would appear, and a fair while later >> the VM would crash. It seems under a non-admin account the OS then choses >> to deny by default because for subsequent runs of pharo.exe, the WSA did >> not appear and also the image did not crash the first time <Run Selected> >> was clicked from TestRunner, but a second click of <Run Selected> would >> still crash the image. >> >> I'm not sure on the list policy of attaching a 1.7MB file with report and >> crash dumps, >> so for interested parties I have sent the file direct to Marcus. >> >> cheers, Ben >> > btw, is there a way to match up a particular test run number with the > Testcase that produced it ? > > -- Mariano http://marianopeck.wordpress.com

Oct. 30, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Ben Coman

Ben Coman wrote: > Marcus Denker wrote: >> Please test... >> >> https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > I've spent the weekend trying to isolate a VM crash varying the > conditions under which pharo.exe runs. The user steps to reproduce > are minimal: > 1. Run pharo.exe > 2. Open TestRunner > 3. Click <Run Selected> > ...but this leaves a lot of possibilities. > > I have Windows 7 and I usually operate under a non-admin account, but > also did testing with an admin account. I got the feeling the problem > is network related. During the test run a Windows Security Alert > regarding the firewall blocking functionality would appear, and a fair > while later the VM would crash. It seems under a non-admin account > the OS then choses to deny by default because for subsequent runs of > pharo.exe, the WSA did not appear and also the image did not crash the > first time <Run Selected> was clicked from TestRunner, but a second > click of <Run Selected> would still crash the image. > > I'm not sure on the list policy of attaching a 1.7MB file with report > and crash dumps, > so for interested parties I have sent the file direct to Marcus. > > cheers, Ben btw, is there a way to match up a particular test run number with the Testcase that produced it ?

Oct. 30, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Ben Coman

Marcus Denker wrote: > Please test... > > https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip > > -- > Marcus Denker -- http://marcusdenker.de > I've spent the weekend trying to isolate a VM crash varying the conditions under which pharo.exe runs. The user steps to reproduce are minimal: 1. Run pharo.exe 2. Open TestRunner 3. Click <Run Selected> ...but this leaves a lot of possibilities. I have Windows 7 and I usually operate under a non-admin account, but also did testing with an admin account. I got the feeling the problem is network related. During the test run a Windows Security Alert regarding the firewall blocking functionality would appear, and a fair while later the VM would crash. It seems under a non-admin account the OS then choses to deny by default because for subsequent runs of pharo.exe, the WSA did not appear and also the image did not crash the first time <Run Selected> was clicked from TestRunner, but a second click of <Run Selected> would still crash the image. I'm not sure on the list policy of attaching a 1.7MB file with report and crash dumps, so for interested parties I have sent the file direct to Marcus. cheers, Ben

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

I agree now this is the path to arrive there that is important to me. Stef On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote: > Stephane, as i said before, i do not see problems with RPackage / naming. > These things are orthogonal, as to me. > We can keep naming scheme as we use today, but switch to RPackage. > > A package can keep the list of category names and that's it. They > could even be completely different, if people want it. > Say, package is named > Foo > and contain categories: > 'Foo-Core' > 'Bar' > > The rationale is simple: > it is up to human(s) to decide what a package should contain, and what > names to use. Let's just embrace the imperfection and do not dictate > people > how they should name their categories in order to make sure that > classes in that categories will be put into concrete package. > If people like to confuse themselves with category names, not matching > the package name , it should be their own choice and responsibility. > > -- > Best regards, > Igor Stasenko. >

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

I will check and take some notes to see what should be done so that we can remove package info and packageOrganizer and use instead Rpackage and RpackageOrganizer. It means that I will have to implement the matching semantics because monticello will ask to classes their categories via package info. RPackage is not related to categories so this is the problem. And to me this makes the system more complex. Stef > Hi, > > On 28 Oct 2011, at 21:30, Lukas Renggli wrote: > >>> Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following: >>> >>> Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones. >> >> If this works like this then that would be perfect, but I had a >> different impression from the mail ("yes people will have to change >> the configurations" and "does not tell me that this is easy but >> propose a real plan to get towards a solution"). To make RPackage >> usable there is the need to have both ways work simultaneously and >> transparently together for some time. Similar to how this was done >> with the transition of underscore assignments ... > > For all practical purposes, every change in the base system is reflected in RPackage. This was the point of the SystemAnnouncement. What does not work yet is the mechanism of having modifications at the level of RPackage reflected in categories. There are two ways around this: > 1. Have tools take care to only affect categories and not RPackage directly, and only read from RPackage. > 2. Build an intermediary support for this sole purpose. > > I think both are doable. Perhaps we can start from 1. and generalize a layer for 2. > > Cheers, > Doru > > > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > >

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by Igor Stasenko

Stephane, as i said before, i do not see problems with RPackage / naming. These things are orthogonal, as to me. We can keep naming scheme as we use today, but switch to RPackage. A package can keep the list of category names and that's it. They could even be completely different, if people want it. Say, package is named Foo and contain categories: 'Foo-Core' 'Bar' The rationale is simple: it is up to human(s) to decide what a package should contain, and what names to use. Let's just embrace the imperfection and do not dictate people how they should name their categories in order to make sure that classes in that categories will be put into concrete package. If people like to confuse themselves with category names, not matching the package name , it should be their own choice and responsibility. -- Best regards, Igor Stasenko.

Oct. 30, 2011

[Pharo-project] [TODO] Issues tagged 1.4

by Marcus Denker

58 Issues are tagged "1.4" http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 The idea is that issues tagged 1.4 are the ones that we need to fix to get 1.4 in a releasable state. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011

[Pharo-project] [TODO] Open bugs in 1.3

by Marcus Denker

http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.3 Core: 4840 Schedule>>between:and:do can iterate over the wrong dates. 4753 Implementors browser doesn't show decompiled source 4745 Debugger opens when trying to get unimplemented calls External Packages: 4889 RBSearchTest has undefined iVar reference 4947 Imported Script Manager scripts disappear 4926 Trait Browsing -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011