September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Issue validation: #Collection cannot be changed using the classbuilder....

by Marcus Denker

> On 15 Sep 2015, at 18:23, Henrik Nergaard <henrin10(a)uia.no> wrote: > > Hi, > > I uploaded a slice to fogbugz which includes removing the class side Ivars > from Collection to a new class managing a default random generator instance. > The Monkey throws this error while checking: /Error: #Collection cannot be > changed using the classbuilder. Use the reflective APi (e.g > #addClassVariable:). If you know what you are doing, you can use > #disableDuring: of DangerousClassNotifier/ > > Anyone know how to resolve this correctly? > Yes, you can add DangerousClassNotifier disable as a pre-load and a a postload: DangerousClassNotifier enable. This way the monkey can check it and we can integrate it using the integration tool. Marcus

Sept. 16, 2015

Re: [Pharo-dev] [Vm-dev] issue with large file path on windows

by David T. Lewis

On Tue, Sep 15, 2015 at 10:45:16AM -0700, Eliot Miranda wrote: > > Hi David, > > On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > > On 15 Sep 2015, at 14:13, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > > > > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote: > > >> > > >> Pharo uses them. > > >> > > >> Posix permissions are useful for both linux and mac. > > >> Windows uses also the posix permissions that came with MinGW??? I do > > not think they are useful but we provide them anyway :) > > > > > > > > > Posix permissions are based on Unix, and are very platform specific. The > > > Windows equivalents are semantically different, and other operating > > systems > > > may exist that are not Unix based at all. > > > > > > IMO, platform specific functions should go into separate plugins, and not > > > in FilePlugin. > > > > well, I disagree :) > > I do not find this approach practical??? because in general, there is no > > other systems that may exist using other permissions than POSIX. Except > > Windows, of course, but even for windows, there are compatibility layers > > that we can use. > > In the case of the FilePlugin extensions, we choose to stay POSIX because > > in general, as its been said before, the job of a virtual machine is been > > virtual: to provide an ???abstract machine??? common for everything in the > > image. I???m not saying that this is possible and even desirable in all > > cases, but it should be something to think about. > > In that case, we could design a common file permissions different to the > > one of Windows and different to POSIX, but I think POSIX does the job just > > fine. > > > > Also, the choice was: POSIX or nothing (because we didn???t have anything > > before). > > I would be very happy if we agree in a better solution, and we implement > > it. > > But in the mean time, a not perfect solution is better than none. > > > > I agree with Esteban. IMO, the model of files that the FilePlugin provides > access to can and should be a superset of facilities. By not supporting > facilities such as permissions or symbolic links or active mount-points we > hobble our core file functionality and that makes us a very weak scripting > platform. Putting these facilities in add-on packages makes configuration > more difficult and means that an elegant implementation in the core file > classes, with fallbacks for platforms that don't support the concepts, is > very difficult. I do not intend to suggest that these things are not wonderful and good and worthy of being done. What I said is that they should not be put into FilePlugin. Yes it is more difficult to implement features like this in packages, but with all due respect it's not all *that* terribly hard. And I think the too much work argument does not hold up when we are talking about something like FilePlugin that effectively defines minimal core functionality required to bring up an image on a new platform. > > If we want to support unix-style scripting in Pharo and Squeak (and I think > we very much do; there are many areas out there where good scripting is > essential) then we need a better File model, and that means not just > getting rid of FileDirectory et al, it also means providing the right > infrastructure in the FilePlugin, and that means extensions like the one > the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO. Again, I am not saying that these things should not be done. Just that with respect to platform-specific features that can only ever work on a Unix based system, allowing these to creep into the feature set of base system does not seem like a very good idea to me. That's all I am saying. Dave

Sept. 16, 2015

Re: [Pharo-dev] [Vm-dev] issue with large file path on windows

by Eliot Miranda

Hi David, On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 15 Sep 2015, at 14:13, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote: > >> > >> Pharo uses them. > >> > >> Posix permissions are useful for both linux and mac. > >> Windows uses also the posix permissions that came with MinGW??? I do > not think they are useful but we provide them anyway :) > > > > > > Posix permissions are based on Unix, and are very platform specific. The > > Windows equivalents are semantically different, and other operating > systems > > may exist that are not Unix based at all. > > > > IMO, platform specific functions should go into separate plugins, and not > > in FilePlugin. > > well, I disagree :) > I do not find this approach practicalâ¦ because in general, there is no > other systems that may exist using other permissions than POSIX. Except > Windows, of course, but even for windows, there are compatibility layers > that we can use. > In the case of the FilePlugin extensions, we choose to stay POSIX because > in general, as its been said before, the job of a virtual machine is been > virtual: to provide an âabstract machineâ common for everything in the > image. Iâm not saying that this is possible and even desirable in all > cases, but it should be something to think about. > In that case, we could design a common file permissions different to the > one of Windows and different to POSIX, but I think POSIX does the job just > fine. > > Also, the choice was: POSIX or nothing (because we didnât have anything > before). > I would be very happy if we agree in a better solution, and we implement > it. > But in the mean time, a not perfect solution is better than none. > I agree with Esteban. IMO, the model of files that the FilePlugin provides access to can and should be a superset of facilities. By not supporting facilities such as permissions or symbolic links or active mount-points we hobble our core file functionality and that makes us a very weak scripting platform. Putting these facilities in add-on packages makes configuration more difficult and means that an elegant implementation in the core file classes, with fallbacks for platforms that don't support the concepts, is very difficult. If we want to support unix-style scripting in Pharo and Squeak (and I think we very much do; there are many areas out there where good scripting is essential) then we need a better File model, and that means not just getting rid of FileDirectory et al, it also means providing the right infrastructure in the FilePlugin, and that means extensions like the one the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO. > Esteban > > > > > Dave > > > > > > > >> > >> Esteban > >> > >> ps: I do not know what are you doing there guys, but you broke my > builds (I???m taking a look at them now) :P > >> > >>> On 15 Sep 2015, at 09:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > >>> > >>> > >>> > >>> 2015-09-15 4:11 GMT+02:00 Ben Coman <btc(a)openinworld.com <mailto: > btc(a)openinworld.com>>: > >>> > >>> On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > >>>> > >>>> > >>>> > >>>> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > >>>>> > >>>>> > >>>>> Hi Nicolai, > >>>>> > >>>>> I'm a bit concerned that this is creating drift with the > "official" Cog source base at > http://www.squeakvm.org/svn/squeak/branches/Cog < > http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support > for win32 was recently added by Marcel Taumel in May of this year. Are you > tracking that? How can we keep the sources harmonized? > >>>> > >>>> > >>>> Ok, I removed all of my code again and merged with sqWin32Directory.c > and sqWin32FilePrims.c from the official cog source. > >>>> I left only pharos additions for the fileattributes > (posixpermissions) this should make it easier to merge which the > >>>> squeak vm main branch (wrapped with pharo vm ifdefs). > >>> > >>> What is the purpose of fileattributes? In the interests of further > >>> minimising drift, is this useful to Squeak? > >>> cheers -ben > >>> > >>> I don't know, I don't think we use it at all. And for the different > platforms, the permission attributes > >>> doesn't really *are the same*. For example, the read/write permissions > we are showing for > >>> win32 platform, don't have much to do with win32 access restrictions - > Idon't know about macos. > >>> > >>> > >>> > >>> > >>> > >> > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 15, 2015

Re: [Pharo-dev] PID of VM ?

by Martin Dias

On Mon, Sep 14, 2015 at 7:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 14 Sep 2015, at 18:46, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > >> On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > >> wrote: > >>> > >>>> On 14 Sep 2015, at 14:21, David T. Lewis <lewis(a)mail.msen.com> wrote: > >>>> > >>>> > >>>> No, OSProcess should not be included in the image. It is intended to be > >>>> an external package. > >>> > >>> mmmÃ¢â¬Â¦ we want to include it as more and more people requires it and we > >>> can profit from having it in the image (same as FFI). > >>> why do you think it should be external? > >> > >> We should distinguish between having it traditionally-in-Image where > >> that is the only place it exists and fixes are integrated, and the > >> current trend (e.g. in-Image Glamorous Tools) where fixes are > >> integrated "upstream" into an external package > >> > > > > Yes, that is what I meant. > > > > Dave > > Several packages are in that situation: Zinc, STON, FUEL, ... it works quite well. In fact, Fuel was integrated in the "traditionally-in-Image" style, but at some point we could switch to the new trend. MartÃn

Sept. 15, 2015

Issue validation: #Collection cannot be changed using the classbuilder....

by Henrik Nergaard

Hi, I uploaded a slice to fogbugz which includes removing the class side Ivars from Collection to a new class managing a default random generator instance. The Monkey throws this error while checking: /Error: #Collection cannot be changed using the classbuilder. Use the reflective APi (e.g #addClassVariable:). If you know what you are doing, you can use #disableDuring: of DangerousClassNotifier/ Anyone know how to resolve this correctly? Case 16577: https://pharo.fogbugz.com/f/cases/16577 <https://pharo.fogbugz.com/f/cases/16577> Error message: https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/13783//artifact/val… <https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/13783//artifact/val…> Best regards, Henrik -- View this message in context: http://forum.world.st/Issue-validation-Collection-cannot-be-changed-using-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 15, 2015

Rubric/Event handling issue?

by Stephan Eggermont

There is an interesting bad interaction between my drag-and-drop code and Rubric. It kills all Rubric editors at the same time, so it looks to me like a problem with the Rubric background thread interacting with mouseMove or mouseEnter/Leave. https://vimeo.com/139353992 To reproduce, Load DragPanels from StephanEggermont/DragPanels and NewUI from StephanEggermont/Documentation In a Playground open a panel CodePanel new openInWindowLabeled:'Code Panel' add a few cards (drop them in the panel) (CodeCard class: CodeCard selector: #initialize) openInHand and expand them by clicking on the arrow Right click on the empty area in the CodePanel and open the colors. A fast drag from the color panel to the rubric area of the code card sometimes results in the rubric editors losing their content. Stephan

Sept. 15, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by Thierry Goubier

Hi Martin, Skip, it makes sense, sort of. ClassReorganized could be handled already by just either discarding whatever cache you would have on the protocols of the class (for example, in a browser) or comparing the new class organisation with the old one. You may be pointing to, however, another issue: ClassReorganized not carrying enough information (i.e. not the old set of protocols). I'm not sure your ProtocolRenamed solves that. But it won't do much harm... Unless Nautilus overeacts and refresh itself 20 times, that it :) Thierry 2015-09-15 16:26 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > Hi, > > On Mon, Sep 14, 2015 at 5:02 PM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > >> Hello, >> >> Right now, when you add or remove a protocol to a class you get two >> announcements (ignoring methods that may have been removed): >> >> 1. Protocol{Added,Removed} >> 2. ClassReorganized. >> >> But when you rename a protocol, you get just ClassReorganized (again, >> ignoring the method recategorizations). >> From this announcement, you only have access to the new class. So there >> is no way to tell the change. >> >> To resolve this, I think a ProtocolRenamed announcement should be added, >> just like there is a CategoryRenamed announcement. >> > > I think it makes sense, and it is harmless (I mean, shouldn't break > anything). > > MartÃn > > >> >> This way Epicea can also log this, which it currently does not do. It >> logs the recategorizations of the methods in the protocol, but not >> the rename of the protocol. So as far as we can tell from the log, we >> canât see if the renamed protocol still exists or not. >> >> Please share your thoughts, >> >> Skip >> > >

Sept. 15, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by Martin Dias

Hi, On Mon, Sep 14, 2015 at 5:02 PM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > Hello, > > Right now, when you add or remove a protocol to a class you get two > announcements (ignoring methods that may have been removed): > > 1. Protocol{Added,Removed} > 2. ClassReorganized. > > But when you rename a protocol, you get just ClassReorganized (again, > ignoring the method recategorizations). > From this announcement, you only have access to the new class. So there is > no way to tell the change. > > To resolve this, I think a ProtocolRenamed announcement should be added, > just like there is a CategoryRenamed announcement. > I think it makes sense, and it is harmless (I mean, shouldn't break anything). MartÃn > > This way Epicea can also log this, which it currently does not do. It logs > the recategorizations of the methods in the protocol, but not > the rename of the protocol. So as far as we can tell from the log, we > canât see if the renamed protocol still exists or not. > > Please share your thoughts, > > Skip >

Sept. 15, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50325 Home: https://github.com/pharo-project/pharo-core

Sept. 15, 2015

[pharo-project/pharo-core] c4c986: 50325

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c4c9866d08f0232442f00d99ed465a6247561045 https://github.com/pharo-project/pharo-core/commit/c4c9866d08f0232442f00d99… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-15 (Tue, 15 Sep 2015) Changed paths: M Monticello-Tests.package/MCMethodDefinitionTest.class/instance/testing/testRevertOldMethod.st A Monticello.package/MCMethodDefinition.class/instance/installing/overridenMethodOrNil.st R Monticello.package/MCMethodDefinition.class/instance/installing/scanForPreviousVersion.st M Monticello.package/MCMethodDefinition.class/instance/installing/unload.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/addWorkingCopy.st M Morphic-Base.package/MenuMorph.class/instance/construction-UIManager/addItem.st M Morphic-Base.package/MenuMorph.class/instance/construction-UIManager/addTitle.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterMethodPrimitive.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeMethodPrimitive.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadPrimitiveMethod.st M Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/examplePrimitiveMethod.st M Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50324.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50325.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50324.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50325.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/WorkingCopyToolBar.class/instance/initialization/createPackage.st Log Message: ----------- 50325 16576 more tests for Primitives https://pharo.fogbugz.com/f/cases/16576 14294 request: should be in charge of its argument translation and not its clients https://pharo.fogbugz.com/f/cases/14294 16572 Fix "-override" method unload https://pharo.fogbugz.com/f/cases/16572 http://files.pharo.org/image/50/50325.zip

Sept. 15, 2015