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

Re: [Pharo-dev] PID of VM ?

by Torsten Bergmann

Sven wrote: > OK, that works, thanks. > > Pretty straightforward NativeBoost based code, small. > > I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects). > > How does this relate to OSProcess ? Why did you start it ? What is the goal ? OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself. I started "OS" because I required more and more things from Windows that OSProcess does not cover. Later beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu". The "OS" project tries to provide the same interface for things that are close in each operating system but still includes things that are available on specific platforms only like Windows. For instance in Windows there is the Windows registry - you can access it with this project. It would not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if you are on this particular platform by evaluating UbuntuShell systemMonitor If on another platform it would not make sense to use it. Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by Tests (because of the lack of "interfaces" in Smalltalk) and similar naming: UnixProcess currentProcessId WinProcess currentProcessId Anything other is explained in http://www.smalltalkhub.com/#!/~OS/OS-Windows I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to an iOS machine). Currently I do not invest too much into it - especially because of this bad feeling that was given that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later. So far NativeBoost served all my needs well and it would be a pitty if I would have to redo all bindings later. :( Bye T.

Sept. 16, 2015

Re: [Pharo-dev] PID of VM ?

by Torsten Bergmann

Sven wrote: > OK, that works, thanks. > > Pretty straightforward NativeBoost based code, small. > > I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects). > > How does this relate to OSProcess ? Why did you start it ? What is the goal ? OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself. I started "OS" because I required more and more things from Windows that OSProcess can never cover. Later beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu". The "OS" project tries to provide the same interface for things that are close in each operating system but still includes things that are available on specific platforms only like Windows. For instance in Windows there is the Windows registry - you can access it with this project. It would not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if you are on this particular platform by evaluating UbuntuShell systemMonitor If on another platform it would not make sense to use it. Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by Tests (because of the lack of "interfaces" in Smalltalk) and similar naming: UnixProcess currentProcessId WinProcess currentProcessId Anything other is explained in http://www.smalltalkhub.com/#!/~OS/OS-Windows I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to an iOS machine). Currently I do not invest too much into it - especially because of this bad feeling that was given that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later. So far NativeBoost served all my needs well and it would be a pitty if I would have to redo all bindings later. :( Bye T.

Sept. 16, 2015

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

by stepharo

Hi guys could you have a look at the SciSmalltalk random package because it would be nice to make sure that the one in the image is in ysnc with the ones in the package. Stef PS preparing to leav to teach pharo in africa :) Le 15/9/15 18:23, Henrik Nergaard a Ã©crit : > 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. 16, 2015

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

by Ben Coman

On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard <henrin10(a)uia.no> wrote: > The method #nextValue actually calculates the next value the seed should be, > the current value can be accessed by sending #seed. > > I do agree that #nextValue might not be the clearest method name for its > use; perhaps #nextSeed would be a better name? Yes. Thats better again. Now its a private method, so there should be problem changing it ;) ??anyone Continuing on another Random topic related to.. https://pharo.fogbugz.com/default.asp?16577 I notice that Collection>>atRandom is protected by a mutex but Collection>>atRandom: is not. This makes me believe the protection is for the Random generator and not for the actual picking of the element from the collection. So it seems that #atRandom holds the mutex too long - for both random generation and element picking. Thus I wonder if rather than copying the existing pattern of Collection>>atRandom to GlobalSharedRandom>>generateFor: it might be better to make a more generic SharedRandom as follows... "Old calls to #next changed to private #nextValue" Random>>nextValue | lo hi aLoRHi answer | hi := (seed quo: q) asFloat. lo := seed - (hi * q). " = seed rem: q" aLoRHi := (a * lo) - (r * hi). seed := (aLoRHi > 0.0) ifTrue: [aLoRHi] ifFalse: [aLoRHi + m]. ^ seed / m "this line moved here from old #next" Random>>next ^ self nextValue Random>>next: anInteger into: anArray 1 to: anInteger do: [:index | anArray at: index put: self nextValue]. ^ anArray Random>>nextInt: anInteger anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' ]. anInteger asFloat isInfinite ifTrue: [^(self nextValue asFraction * anInteger) truncated + 1]. ^ (self nextValue * anInteger) truncated + 1 "SharedRandom protects all calls to private #nextValue" Random subclass: SharedRandom instanceVariableNames: 'mutex' SharedRandom>>initialize mutex := Semaphore forMutualExclusion. SharedRandom>>next ^ mutex critical: [ self nextValue ] SharedRandom>>next: anInteger into: anArray ^ mutex critical: [ super next: anInteger into: anArray ]. SharedRandom>>nextInt: anInteger ^ mutex critical: [ nextInt: anInteger ]. Then... Object subclass: GlobalSharedRandom classVariables: 'sharedRandom' GlobalSharedRandom class>>initialize sharedRandom := SharedRandom new. GlobalSharedRandom class>>generator ^ sharedRandom And finally... Collection>>atRandom ^ self randomAt: GlobalSharedRandom generator. What do you think? cheers, Ben

Sept. 16, 2015

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

by Henrik Nergaard

Thanks Marcus, that fixed the issue. 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. 16, 2015

Re: [Pharo-dev] Configuration Madness

by Dale Henrichs

On 9/16/15 8:07 AM, Max Leske wrote: >> On 16 Sep 2015, at 16:39, roberto.minelli(a)usi.ch wrote: >> >> Dear all, >> >> I have a question about the ConfigurationOf my project, and I really hope you can help. >> >> In my project I have a package called âDevFlow-Extensionsâ that is a âplaceholderâ for code that is dependent on the Pharo version. >> >> On the ConfigurationOf, according to the Pharo version I do something like >> >> spec for: #'pharo3.x' >> do: [ >> >> spec blessing: #baseline. >> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >> >> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions30'. >> ]. >> >> spec for: #'pharo4.x' >> do: [ >> >> spec blessing: #baseline. >> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >> >> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions40'. >> ]. >> >> In this way, in Pharo 3.0 Iâd load DevFlow-Extensions30 and in Pharo 4.0 Iâd load DevFlow-Extensions40. Super cool. >> I am using a single package (âDevFlow-Extensionsâ) to specify of groups, for example: >> >> spec group: 'User' with: #( >> 'DevFlow-Meta' >> ... >> 'DevFlow-Announcement' >> 'DevFlow-Extensions'). >> >> Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40â and 'DevFlow-Extensions50â. >> I read the chapter on Metacello, but didnât find a solution. I tried some combinations of #includes: and #requires: but with no luck. >> >> Any help is appreciated, thank you very much! >> >> Roberto > Shouldnât this work? > > spec package: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50). > > > Good idea, but it's not quite correct, I think this will work: spec for: #'pharo5.x' do: [ spec package: 'DevFlow-Extensions40' . spec package: 'DevFlow-Extensions50' . spec group: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50) ]. Dale

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Ben Coman

On Wed, Sep 16, 2015 at 4:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? What is the result in other dialects? This is a potential incompatibility for little gain. Anyway I would guess Opal is wrong. cheers -ben

Sept. 16, 2015

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

by Henrik Nergaard

The method #nextValue actually calculates the next value the seed should be, the current value can be accessed by sending #seed. I do agree that #nextValue might not be the clearest method name for its use; perhaps #nextSeed would be a better name? Best regards, Henrik -- View this message in context: http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2015

Re: [Pharo-dev] Configuration Madness

by Max Leske

> On 16 Sep 2015, at 16:39, roberto.minelli(a)usi.ch wrote: > > Dear all, > > I have a question about the ConfigurationOf my project, and I really hope you can help. > > In my project I have a package called âDevFlow-Extensionsâ that is a âplaceholderâ for code that is dependent on the Pharo version. > > On the ConfigurationOf, according to the Pharo version I do something like > > spec for: #'pharo3.x' > do: [ > > spec blessing: #baseline. > spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. > > spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions30'. > ]. > > spec for: #'pharo4.x' > do: [ > > spec blessing: #baseline. > spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. > > spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions40'. > ]. > > In this way, in Pharo 3.0 Iâd load DevFlow-Extensions30 and in Pharo 4.0 Iâd load DevFlow-Extensions40. Super cool. > I am using a single package (âDevFlow-Extensionsâ) to specify of groups, for example: > > spec group: 'User' with: #( > 'DevFlow-Meta' > ... > 'DevFlow-Announcement' > 'DevFlow-Extensions'). > > Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40â and 'DevFlow-Extensions50â. > I read the chapter on Metacello, but didnât find a solution. I tried some combinations of #includes: and #requires: but with no luck. > > Any help is appreciated, thank you very much! > > Roberto Shouldnât this work? spec package: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50).

Sept. 16, 2015

Configuration Madness

by roberto.minelli＠usi.ch

Dear all, I have a question about the ConfigurationOf my project, and I really hope you can help. In my project I have a package called âDevFlow-Extensionsâ that is a âplaceholderâ for code that is dependent on the Pharo version. On the ConfigurationOf, according to the Pharo version I do something like spec for: #'pharo3.x' do: [ spec blessing: #baseline. spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions30'. ]. spec for: #'pharo4.x' do: [ spec blessing: #baseline. spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions40'. ]. In this way, in Pharo 3.0 Iâd load DevFlow-Extensions30 and in Pharo 4.0 Iâd load DevFlow-Extensions40. Super cool. I am using a single package (âDevFlow-Extensionsâ) to specify of groups, for example: spec group: 'User' with: #( 'DevFlow-Meta' ... 'DevFlow-Announcement' 'DevFlow-Extensions'). Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40â and 'DevFlow-Extensions50â. I read the chapter on Metacello, but didnât find a solution. I tried some combinations of #includes: and #requires: but with no luck. Any help is appreciated, thank you very much! Roberto

Sept. 16, 2015

Pedantic on Random>>nextValue method name

by Ben Coman

In Random>>nextValue I notice the comment: "This method does NOT update the seed; repeated sends answer the same value." Thus the following produces all the same values... oc := OrderedCollection new. r := Random new. 5 timesRepeat: [ oc add: r nextValue ] . oc inspect. Am I being too pedantic thinking this ancient method should be named #currentValue. Are there historical constraints to be wary of? Its only significant in-Image sender is Random>>next which would then be... ^ (seed := self currentValue) / m cheers -ben

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Christophe Demarey

The PackageAnalyzer is now maintained by me (especially because it is so usefull for the bootstrap). I just fixed that. Indeed, the code was wrong. Christophe Le 16 sept. 2015 Ã 15:05, Nicolai Hess a Ã©crit : > OK, I think Sven is right and a cascade needs at least one message send > > "self ; yourself" > > doesn't work too (both parser don't accept this). > > There are currently two methods in Pharo 5.0 with this > syntax: > > DAPackageAnalyzerWindow class>>#onPackagesNamed: > DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: > > @Yuri, can you change that. > > > And I think we should fix RBParser. > > 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Nicolai, > > can you try with the RBParser directly? I believe Opal uses the RBParser. > > RBParser parseMethod: 'createRedMorph > ^ (self new color:Color red); yourself' > > Oh, RBParser sees it as: > > self new > color: Color red; > yourself > > :) > > Thierry > > > 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai > > >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Thierry Goubier

Argh, sent too early: self new color: Color red; yourself est bien une cascade, non? Thierry 2015-09-16 15:12 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> OK, I think Sven is right and a cascade needs at least one message send >> >> "self ; yourself" >> >> doesn't work too (both parser don't accept this). >> > > But > > > >> >> There are currently two methods in Pharo 5.0 with this >> syntax: >> >> DAPackageAnalyzerWindow class>>#onPackagesNamed: >> DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: >> >> @Yuri, can you change that. >> >> >> And I think we should fix RBParser. >> >> >> 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Nicolai, >>> >>> can you try with the RBParser directly? I believe Opal uses the RBParser. >>> >>> RBParser parseMethod: 'createRedMorph >>> ^ (self new color:Color red); yourself' >>> >>> Oh, RBParser sees it as: >>> >>> self new >>> color: Color red; >>> yourself >>> >>> :) >>> >>> Thierry >>> >>> >>> 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> The following method compiles with Opal: >>>> >>>> createRedMorph >>>> ^ (self new color:Color red); yourself >>>> >>>> but gives a syntax error with the old compilers parser >>>> >>>> createRedMorph >>>> ^ (self new color:Color red)End of block expected -> ; yourself >>>> >>>> >>>> removing the parenthesis of course works for both. >>>> Who is right ? >>>> >>>> >>>> (for those who understand the ParseTreeSearcher syntax, how would >>>> a search expression look, for finding code like: >>>> >>>> "(some expression);yourself" >>>> >>>> >>>> nicolai >>>> >>>> >>> >> >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Thierry Goubier

2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > OK, I think Sven is right and a cascade needs at least one message send > > "self ; yourself" > > doesn't work too (both parser don't accept this). > But > > There are currently two methods in Pharo 5.0 with this > syntax: > > DAPackageAnalyzerWindow class>>#onPackagesNamed: > DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: > > @Yuri, can you change that. > > > And I think we should fix RBParser. > > > 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Nicolai, >> >> can you try with the RBParser directly? I believe Opal uses the RBParser. >> >> RBParser parseMethod: 'createRedMorph >> ^ (self new color:Color red); yourself' >> >> Oh, RBParser sees it as: >> >> self new >> color: Color red; >> yourself >> >> :) >> >> Thierry >> >> >> 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> The following method compiles with Opal: >>> >>> createRedMorph >>> ^ (self new color:Color red); yourself >>> >>> but gives a syntax error with the old compilers parser >>> >>> createRedMorph >>> ^ (self new color:Color red)End of block expected -> ; yourself >>> >>> >>> removing the parenthesis of course works for both. >>> Who is right ? >>> >>> >>> (for those who understand the ParseTreeSearcher syntax, how would >>> a search expression look, for finding code like: >>> >>> "(some expression);yourself" >>> >>> >>> nicolai >>> >>> >> >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

Arrg, sorry Yuri, this (too) isn't from QualityAssistance, but DependencyAnalyzer 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > OK, I think Sven is right and a cascade needs at least one message send > > "self ; yourself" > > doesn't work too (both parser don't accept this). > > There are currently two methods in Pharo 5.0 with this > syntax: > > DAPackageAnalyzerWindow class>>#onPackagesNamed: > DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: > > @Yuri, can you change that. > > > And I think we should fix RBParser. > > > 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Nicolai, >> >> can you try with the RBParser directly? I believe Opal uses the RBParser. >> >> RBParser parseMethod: 'createRedMorph >> ^ (self new color:Color red); yourself' >> >> Oh, RBParser sees it as: >> >> self new >> color: Color red; >> yourself >> >> :) >> >> Thierry >> >> >> 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> The following method compiles with Opal: >>> >>> createRedMorph >>> ^ (self new color:Color red); yourself >>> >>> but gives a syntax error with the old compilers parser >>> >>> createRedMorph >>> ^ (self new color:Color red)End of block expected -> ; yourself >>> >>> >>> removing the parenthesis of course works for both. >>> Who is right ? >>> >>> >>> (for those who understand the ParseTreeSearcher syntax, how would >>> a search expression look, for finding code like: >>> >>> "(some expression);yourself" >>> >>> >>> nicolai >>> >>> >> >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

OK, I think Sven is right and a cascade needs at least one message send "self ; yourself" doesn't work too (both parser don't accept this). There are currently two methods in Pharo 5.0 with this syntax: DAPackageAnalyzerWindow class>>#onPackagesNamed: DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: @Yuri, can you change that. And I think we should fix RBParser. 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Nicolai, > > can you try with the RBParser directly? I believe Opal uses the RBParser. > > RBParser parseMethod: 'createRedMorph > ^ (self new color:Color red); yourself' > > Oh, RBParser sees it as: > > self new > color: Color red; > yourself > > :) > > Thierry > > > 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> The following method compiles with Opal: >> >> createRedMorph >> ^ (self new color:Color red); yourself >> >> but gives a syntax error with the old compilers parser >> >> createRedMorph >> ^ (self new color:Color red)End of block expected -> ; yourself >> >> >> removing the parenthesis of course works for both. >> Who is right ? >> >> >> (for those who understand the ParseTreeSearcher syntax, how would >> a search expression look, for finding code like: >> >> "(some expression);yourself" >> >> >> nicolai >> >> >

Sept. 16, 2015

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by Tudor Girba

This is really beautiful :). Doru On Wed, Sep 16, 2015 at 10:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > This is just a one-liner to add to the framework, but that makes it even > more fun: One-Shot links. > > A link now can have the #optionOneShot, which means that it will > de-install itself when activated for > the first time: > > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > > The full test looks like this: > > testLinkOneShot > | sendNode link | > sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first. > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > sendNode link: link. > self assert: sendNode hasMetalink. > self assert: tag isNil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: (tag = #yes). > self deny: sendNode hasMetalink. > tag := nil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: tag isNil. > > > https://pharo.fogbugz.com/f/cases/16581/one-shot-links > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 16, 2015

[Ann] Phratch 4.1 is here !

by jannik laval

Based on Phratch 4.0 we made some bug fixes and added new small features. Phratch is now on top of Pharo 4.0. The new features are: - languages are more stable. Thanks to the community for the feedback and the enhancement of the language files. - Add a "follow" option that allows one to see which block is currently executed. Phratch 4.1 is already available on phratch.com. If you detect an issue, you can submit a description on https://github.com/janniklaval/phratch/issues And you can always download the latest build on the continuous integration server: https://ci.inria.fr/pharo-contribution/view/Phratch/ See you on phratch.com -- ~~Jannik Laval~~ Enseignant-chercheur IUT LumiÃ¨re <http://iut.univ-lyon2.fr/>, UniversitÃ© Lyon LumiÃ¨re <http://www.univ-lyon2.fr/> laboratoire DISP <http://disp-lab.fr/> http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

Sept. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 16, 2015

[pharo-project/pharo-core] 313e4a: 50327

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 313e4a2da2d22b03bcd18e80acf64a1692cc0250 https://github.com/pharo-project/pharo-core/commit/313e4a2da2d22b03bcd18e80… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-16 (Wed, 16 Sep 2015) Changed paths: M Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeSend.st M Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testUnsubscribeSend.st M Announcements-Tests-Core.package/WeakAnnouncerTest.class/instance/testing/testWeakObject.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui/addAll_.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/noteNewOwner_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50326.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50327.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50326.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50327.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TabManagerModel.class/instance/api/addTab_.st M Spec-Core.package/TabManagerModel.class/instance/private/basicRemoveTab_.st M Spec-Core.package/TabModel.class/README.md M Spec-Core.package/TabModel.class/instance/api/model_.st A Spec-Tests.package/TabManagerModelTest.class/README.md A Spec-Tests.package/TabManagerModelTest.class/definition.st A Spec-Tests.package/TabManagerModelTest.class/instance/running/setUp.st A Spec-Tests.package/TabManagerModelTest.class/instance/running/tearDown.st A Spec-Tests.package/TabManagerModelTest.class/instance/tabs creation/redMorphTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabOpened.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabSetOwner.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabUnopened.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testInitialSelectedTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromManager.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromManager2.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromMorphic.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabUnsetOwner.st A Spec-Tests.package/TabManagerModelTest.class/instance/utility/morphicTabsFor_.st R Spec-Tests.package/TabModelTest.class/instance/tests/testAddTabOpened.st R Spec-Tests.package/TabModelTest.class/instance/tests/testAddTabUnopened.st R Spec-Tests.package/TabModelTest.class/instance/tests/testInitialSelectedTab.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTab.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromManager.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromManager2.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromMorphic.st A Spec-Tests.package/TabModelTest.class/instance/tests/testSetOwner.st R Spec-Tests.package/TabModelTest.class/instance/utility/morphicTabsFor_.st M Tool-FileList.package/FileList.class/instance/user interface/morphicFileContentsPane.st M Tool-Workspace.package/Workspace.class/instance/view/textView.st Log Message: ----------- 50327 16500 Remove senders of subscribe:send:to: in the image https://pharo.fogbugz.com/f/cases/16500 16564 Remove senders of Announcer>>#subscribe:send:to: in Tool-Workspace https://pharo.fogbugz.com/f/cases/16564 16562 Remove senders of Announcer>>#subscribe:send:to: in Tool-FileList https://pharo.fogbugz.com/f/cases/16562 16553 TabModel/TabModelManager are not setting owner: https://pharo.fogbugz.com/f/cases/16553 http://files.pharo.org/image/50/50327.zip

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Thierry Goubier

Nicolai, can you try with the RBParser directly? I believe Opal uses the RBParser. RBParser parseMethod: 'createRedMorph ^ (self new color:Color red); yourself' Oh, RBParser sees it as: self new color: Color red; yourself :) Thierry 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai > >

Sept. 16, 2015

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

by Thierry Goubier

2015-09-16 11:05 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr>: ... > > One more thing. I hope that when renaming the protocol, the relevant > MethodRecategorized are sent, because many things depend on that one. > > > Yes, those are already sent. ProtocolRenamed, if implemented, should be > announced in addition to those. > > I need to check AltBrowser behavior on this one. Renaming a protocol is > not what I expected. It looks harmless, but it has important consequences > if the protocol is an extension or an override. > > > Alright, let me know. > I think you can go forward. If the MethodRecategorized is sent, then it should be OK. > > > >> >> Thanks for your reply :) >> >> PS: Thereâs something else related to System-Announcements, namely that >> when I rename a category I get no CategoryRenamed announcement. >> I will send an e-mail about that later. >> > > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). > > > Indeed it does, but RPackageTag>>#renameTo:category: suspends the > SystemAnnouncer while it sends SystemOrganizer>>#renameCategory:toBe:. > I donât know why, Iâm interested to know. Because > RPackageTag>>#renameTo:category: is used when you rename a category (in > Nautilus, at least). > I would heed Esteban advice on that. If the system announcer is suspended, then this is probably because we may have some kind of infinite loop and / or a incoherent state while renaming the system category. I'll have a look too. Thierry > > Skip >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Sven Van Caekenberghe

Interesting. I think that for a cascade you need more than one message send. > On 16 Sep 2015, at 10:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai >

Sept. 16, 2015

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

by Skip Lentz

> On Sep 16, 2015, at 10:36 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-09-16 10:18 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > > As far as I know, you canât compare to the old class organization because it is already changed to the new one.. > > Yes but: the receiver of the announcement may have a copy of the old one. For example, when AltBrowser receives that, it clears its current knowledge of the class organisation and rebuilts it. Ah yes, that way it is possible. > > > > I'm not sure your ProtocolRenamed solves that. > > While it may not solve the problem of ClassReorganized lacking information, it does give extra information as to what happened. Right now you simply donât know when a protocol was renamed. > > Because, up to know, we managed by either: rebuilding what depends on the organisation, or use it for something else. > > For example, usually in Smalltalk, protocols are ordered and a user may reorder them by hand -> ClassReorganized. Nautilus takes a different view (order alphabetically, add a all protocol), hence Pharo protocols have integrated the Nautilus viewpoint (the 'all' protocol), and AltBrowser disregard this (the 'all' protocol and the ordering) because I prefer a different way of ordering. > > > > But it won't do much harm... Unless Nautilus overeacts and refresh itself 20 times, that it :) > > If Nautilus does not subscribe to ProtocolRenamed then nothing happens, no? > I am willing to create an issue, propose a slice, etc. > > One more thing. I hope that when renaming the protocol, the relevant MethodRecategorized are sent, because many things depend on that one. Yes, those are already sent. ProtocolRenamed, if implemented, should be announced in addition to those. > I need to check AltBrowser behavior on this one. Renaming a protocol is not what I expected. It looks harmless, but it has important consequences if the protocol is an extension or an override. Alright, let me know. > > > Thanks for your reply :) > > PS: Thereâs something else related to System-Announcements, namely that when I rename a category I get no CategoryRenamed announcement. > I will send an e-mail about that later. > > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). Indeed it does, but RPackageTag>>#renameTo:category: suspends the SystemAnnouncer while it sends SystemOrganizer>>#renameCategory:toBe:. I donât know why, Iâm interested to know. Because RPackageTag>>#renameTo:category: is used when you rename a category (in Nautilus, at least). Skip

Sept. 16, 2015

SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

The following method compiles with Opal: createRedMorph ^ (self new color:Color red); yourself but gives a syntax error with the old compilers parser createRedMorph ^ (self new color:Color red)End of block expected -> ; yourself removing the parenthesis of course works for both. Who is right ? (for those who understand the ParseTreeSearcher syntax, how would a search expression look, for finding code like: "(some expression);yourself" nicolai

Sept. 16, 2015

Reflectivity: Links that de-install themselves (oneShot)

by Marcus Denker

Hi, This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links. A link now can have the #optionOneShot, which means that it will de-install itself when activated for the first time: link := MetaLink new metaObject: self; options: #(optionOneShot); selector: #tagExec. The full test looks like this: testLinkOneShot | sendNode link | sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first. link := MetaLink new metaObject: self; options: #(optionOneShot); selector: #tagExec. sendNode link: link. self assert: sendNode hasMetalink. self assert: tag isNil. self assert: (ReflectivityExamples new exampleMethod = 5). self assert: (tag = #yes). self deny: sendNode hasMetalink. tag := nil. self assert: (ReflectivityExamples new exampleMethod = 5). self assert: tag isNil. https://pharo.fogbugz.com/f/cases/16581/one-shot-links Marcus

Sept. 16, 2015

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

by Thierry Goubier

2015-09-16 10:18 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr>: > > > On Sep 15, 2015, at 4:40 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 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. > > As far as I know, you canât compare to the old class organization because > it is already changed to the new one.. > Yes but: the receiver of the announcement may have a copy of the old one. For example, when AltBrowser receives that, it clears its current knowledge of the class organisation and rebuilts it. > > > You may be pointing to, however, another issue: ClassReorganized not > carrying enough information (i.e. not the old set of protocols). > > Yesâ¦ it only has the class which has been affected. No way to compare it. > This is it. But ClassReorganized can be used for reordering the protocols. > > > I'm not sure your ProtocolRenamed solves that. > > While it may not solve the problem of ClassReorganized lacking > information, it does give extra information as to what happened. Right now > you simply donât know when a protocol was renamed. > Because, up to know, we managed by either: rebuilding what depends on the organisation, or use it for something else. For example, usually in Smalltalk, protocols are ordered and a user may reorder them by hand -> ClassReorganized. Nautilus takes a different view (order alphabetically, add a all protocol), hence Pharo protocols have integrated the Nautilus viewpoint (the 'all' protocol), and AltBrowser disregard this (the 'all' protocol and the ordering) because I prefer a different way of ordering. > > > But it won't do much harm... Unless Nautilus overeacts and refresh > itself 20 times, that it :) > > If Nautilus does not subscribe to ProtocolRenamed then nothing happens, no? > I am willing to create an issue, propose a slice, etc. > One more thing. I hope that when renaming the protocol, the relevant MethodRecategorized are sent, because many things depend on that one. I need to check AltBrowser behavior on this one. Renaming a protocol is not what I expected. It looks harmless, but it has important consequences if the protocol is an extension or an override. > > Thanks for your reply :) > > PS: Thereâs something else related to System-Announcements, namely that > when I rename a category I get no CategoryRenamed announcement. > I will send an e-mail about that later. > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). Thierry

Sept. 16, 2015

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

by Skip Lentz

> On Sep 15, 2015, at 4:40 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > 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. As far as I know, you canât compare to the old class organization because it is already changed to the new one.. > You may be pointing to, however, another issue: ClassReorganized not carrying enough information (i.e. not the old set of protocols). Yesâ¦ it only has the class which has been affected. No way to compare it. > I'm not sure your ProtocolRenamed solves that. While it may not solve the problem of ClassReorganized lacking information, it does give extra information as to what happened. Right now you simply donât know when a protocol was renamed. > But it won't do much harm... Unless Nautilus overeacts and refresh itself 20 times, that it :) If Nautilus does not subscribe to ProtocolRenamed then nothing happens, no? I am willing to create an issue, propose a slice, etc. Thanks for your reply :) PS: Thereâs something else related to System-Announcements, namely that when I rename a category I get no CategoryRenamed announcement. I will send an e-mail about that later.

Sept. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 16, 2015

[pharo-project/pharo-core] 9d1a28: 50326

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9d1a28602740b615dee3455b0f71f6893afccd8b https://github.com/pharo-project/pharo-core/commit/9d1a28602740b615dee3455b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-16 (Wed, 16 Sep 2015) Changed paths: M NautilusCommon.package/AnnotationRequest.class/instance/requests/priorVersionsCount.st M RecentSubmissions.package/RecentMessageList.class/instance/actions/revertLastMethodSubmission.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterBlockSequence.st M Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double dispatching/visitSequenceNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50325.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50326.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50325.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50326.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/LayoutAbstractScope.class/instance/extending/extend_as_.st R Slot.package/Slot.class/instance/accessing/parentScopeFor_.st A Slot.package/Slot.class/instance/accessing/scope_.st M Spec-Tools.package/NewVersionBrowser.class/instance/instance creation/buildChangeList.st R System-Changes.package/extension/TBehavior/instance/changeRecordsAt_.st A System-Sources.package/SourceFileArray.class/instance/public - string reading/changeRecordsFor_.st M System-Sources.package/SourceFileArray.class/instance/public - string reading/changeRecordsFor_do_.st M Tool-Finder.package/MethodFinder.class/instance/initialize/initialize.st Log Message: ----------- 50326 16420 Remove #changeRecordsAt: from TBehavior https://pharo.fogbugz.com/f/cases/16420 16580 #after block sequence https://pharo.fogbugz.com/f/cases/16580 16579 parentScopeFor: not used https://pharo.fogbugz.com/f/cases/16579 http://files.pharo.org/image/50/50326.zip

Sept. 16, 2015

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

[pharo-project/pharo-core]

by GitHub

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

Sept. 15, 2015

[pharo-project/pharo-core] 8cc29c: 50324

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8cc29ccb564ae0672697d623dbd9e929491d69bd https://github.com/pharo-project/pharo-core/commit/8cc29ccb564ae0672697d623… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-15 (Tue, 15 Sep 2015) Changed paths: M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version1212_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version313Moose51_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version321_.st M GT-Spotter.package/GTSpotter.class/instance/accessing/pagerModel.st M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/accessing/stepModel_.st M GT-Spotter.package/GTSpotterContentsBrick.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterDropDownMorph.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterHeaderBrick.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterItemActionbarBrick.class/instance/accessing/stepModel_.st M GT-Spotter.package/GTSpotterItemBrick.class/instance/accessing/stepModel_.st M GT-Spotter.package/GTSpotterMorph.class/instance/accessing/breadcrumbBrick_.st M GT-Spotter.package/GTSpotterMorph.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterPreviewArrowBrick.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterPreviewArrowBrick.class/instance/event handling/onStepAdded.st M GT-Spotter.package/GTSpotterPreviewBrick.class/instance/accessing/spotterModel_.st M GT-Spotter.package/GTSpotterResultsBrick.class/instance/accessing/stepModel_.st M GT-Spotter.package/GTSpotterResultsBrick.class/instance/initialization/initialize.st M GT-Spotter.package/GTSpotterStepsBreadcrumb.class/instance/accessing/spotterModel_.st M Glamour-Morphic-Brick.package/GLMEditableLabelBrick.class/instance/label-brick-accessing/editBrick_.st M Glamour-Morphic-Pager.package/GLMPagerBarBrick.class/instance/bar-accessing/pagerModel_.st M Glamour-Morphic-Pager.package/GLMPagerBrick.class/instance/pager-accessing/pagerModel_.st M Glamour-Morphic-Pager.package/GLMPagerButtonsPaneBrick.class/instance/buttons-accessing/pagerModel_.st M Glamour-Morphic-Pager.package/GLMPagerButtonsPaneBrick.class/instance/buttons-adding/addButton_.st M Glamour-Morphic-Pager.package/GLMPagerScrollSlidingBrick.class/instance/slider-accessing/pagerModel_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50323.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50324.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50323.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50324.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50324 16561 Remove senders of subscribe:send:to: in GToolkit https://pharo.fogbugz.com/f/cases/16561 16501 Remove senders of subscribe:send:to: in Glamour https://pharo.fogbugz.com/f/cases/16501 http://files.pharo.org/image/50/50324.zip

Sept. 15, 2015

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

by Nicolai Hess

2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Thanks Nicolai, that's great! I'll merge in your changes. Which files do > I need to look at? > I changed (removed my code, added Marcels) platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c platforms/win32/vm/sqWin32.h platforms/win32/vm/sqWin32Directory.c I added (should be the same as in squeak vm repository) platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c But my changes only about that code that already is in squeaks repository. If we want to merge some of the pharo-vm code into squeaks branch, we first need to wrap that code with some #ifdefs (For the win32 file/directory stuff, this would be code in platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c platforms/win32/vm/sqWin32.h platforms/win32/vm/sqWin32Directory.c and platforms/Cross/plugins/FilePlugin/FilePlugin.h) Maybe Estaban should look at this, and tell which path he would follow to merge those changes. > > On Sat, Sep 12, 2015 at 8:00 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> >> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)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. >>> 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). >> >> github branch: >> https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin >> I'll create a push request. >> >> >> nicolai >> >> >> >>> >>> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> For those who had problems with pharo on windows and github based >>>> repositories, >>>> I built a windows vm with support for long paths: >>>> >>>> >>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>>> >>>> >>>> For browsing directories with large paths (FileList or Inspect), >>>> you may need one additional change in the image (But I am not really >>>> sure about that) : >>>> >>>> DiskStore>>initialize >>>> super initialize. >>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 >>>> ]. >>>> >>>> >>>> please test and give feedback. >>>> >>>> This wasn't as easy as I thought, and I had to make some more changes >>>> for the file permissions (the stat-functions don't work for files with >>>> long paths). >>>> Please test other file/folder operations. >>>> >>>> >>>> nicolai >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > >

Sept. 15, 2015

Nautilus package search "broken"

by Nicolai Hess

Needs review : https://pharo.fogbugz.com/f/cases/16523 I just provided a possible solution, but I don't really use the package search. Some feedback is needed. nicolai

Sept. 15, 2015

Re: [Pharo-dev] Array literal changes of a compiled method

by Eliot Miranda

Hi Juraj, On Mon, Sep 14, 2015 at 4:56 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi, > > I have a test case like that: > -=-=- > testIncrementBy > prefix := MyObject new numbers: #(1 10); yourself. > prefix incrementBy: 10. > self assert: prefix numbers equals: #(1 20). > -=-=- > > and the byte code starts like that: > -=-=- > 57 <40> pushLit: MyObject > 58 <CC> send: new > 59 <88> dup > 60 <21> pushConstant: #(1 10) > -=-=- > > If I run the test case, it is green, but the byte code changes into: > -=-=- > 57 <40> pushLit: MyObject > 58 <CC> send: new > 59 <88> dup > 60 <21> pushConstant: #(1 *20*) > -=-=- > > The #incrementBy: method looks like: > -=-=- > incrementBy: aNumber > numbers at: 2 put: (numbers at: 2) + aNumber > -=-=- > > Is it correct that it also changes the method byte code? > No, ut this does happen. hat I suspect you're seeing is the fact that in the Pharo and Squeak implementations, literals are not immutable. So if you were to assign to a literal Array in a method's literals that assignment would not cause an error, and worse, would not be visible because the mehtods source code would be unchanged. We shall have a proper fix for this in a future release where we will support fully immutable literals. For now the correct respponse shoudl be to find out where in your code the literal is assigned to and to not do that. Of course adding a copy is also fine. > I can put "#(1 10) copyâ into the test case. > I am just curious if it is a feature or bug. > It's a bug, but an ancient one. Some Smalltalks, such as VisualAge and VisualWorks have fixed this by introducing support for immutable objects, but the {haro/Squeak Vms have yet to provide this. I expect to implement it in Spur some time next year. > > Tested in Pharo4.0, Latest update: #40613. > > Cheers, > Juraj > -- _,,,^..^,,,_ best, Eliot

Sept. 15, 2015

Array literal changes of a compiled method

by Juraj Kubelka

Hi, I have a test case like that: -=-=- testIncrementBy prefix := MyObject new numbers: #(1 10); yourself. prefix incrementBy: 10. self assert: prefix numbers equals: #(1 20). -=-=- and the byte code starts like that: -=-=- 57 <40> pushLit: MyObject 58 <CC> send: new 59 <88> dup 60 <21> pushConstant: #(1 10) -=-=- If I run the test case, it is green, but the byte code changes into: -=-=- 57 <40> pushLit: MyObject 58 <CC> send: new 59 <88> dup 60 <21> pushConstant: #(1 20) -=-=- The #incrementBy: method looks like: -=-=- incrementBy: aNumber numbers at: 2 put: (numbers at: 2) + aNumber -=-=- Is it correct that it also changes the method byte code? I can put "#(1 10) copyâ into the test case. I am just curious if it is a feature or bug. Tested in Pharo4.0, Latest update: #40613. Cheers, Juraj

Sept. 14, 2015

Re: [Pharo-dev] Metacello load script won't update the configuration

by Yuriy Tymchuk

Yes, that is exactly what I need! Thank you! > On 14 Sep 2015, at 23:10, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Uko, > > The `get` command is used to load a fresh copy of the ConfigurationOf or BaselineOf so the following should do the trick: > > Metacello new > smalltalkhubUser: 'Pharo' > project: 'MetaRepoForPharo40'; > configuration: 'QualityAssistant'; > get; > load > > > I make the loading of the BaselineOf and ConfigurationOf explicit so that the developer can control when and if they want a new copy of the BaselineOf or ConfigurationOf. > > For github urls like github://project/user/project, the `get` command causes the system to invalidate the cache directory so that on the next load, the github cache for the project is freshly downloaded so that you get the latest version of the BaselineOf ... > > Dale > > On 09/14/2015 01:49 PM, Yuriy Tymchuk wrote: >> Hi, >> >> when you use a script like >> >> Metacello new >> smalltalkhubUser: 'Pharo' >> project: 'MetaRepoForPharo40'; >> configuration: 'QualityAssistant'; >> load >> >> and you already have the configuration package loaded, the script is not updating the configuration itself. As the result you cannot update to a newer version. Is there a special expression that has to be used to update the configuration package? If not, maybe it does make sense to update the configuration before loading it? >> >> Cheers! >> Uko >

Sept. 14, 2015

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

by Eliot Miranda

Thanks Nicolai, that's great! I'll merge in your changes. Which files do I need to look at? On Sat, Sep 12, 2015 at 8:00 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)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. >> 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). > > github branch: > https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin > I'll create a push request. > > > nicolai > > > >> >> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> For those who had problems with pharo on windows and github based >>> repositories, >>> I built a windows vm with support for long paths: >>> >>> >>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>> >>> >>> For browsing directories with large paths (FileList or Inspect), >>> you may need one additional change in the image (But I am not really >>> sure about that) : >>> >>> DiskStore>>initialize >>> super initialize. >>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. >>> >>> >>> please test and give feedback. >>> >>> This wasn't as easy as I thought, and I had to make some more changes >>> for the file permissions (the stat-functions don't work for files with >>> long paths). >>> Please test other file/folder operations. >>> >>> >>> nicolai >>> >>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> > > -- _,,,^..^,,,_ best, Eliot

Sept. 14, 2015

Re: [Pharo-dev] Metacello load script won't update the configuration

by Dale Henrichs

Uko, The `get` command is used to load a fresh copy of the ConfigurationOf or BaselineOf so the following should do the trick: Metacello new smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo40'; configuration: 'QualityAssistant'; get; load I make the loading of the BaselineOf and ConfigurationOf explicit so that the developer can control when and if they want a new copy of the BaselineOf or ConfigurationOf. For github urls like github://project/user/project, the `get` command causes the system to invalidate the cache directory so that on the next load, the github cache for the project is freshly downloaded so that you get the latest version of the BaselineOf ... Dale On 09/14/2015 01:49 PM, Yuriy Tymchuk wrote: > Hi, > > when you use a script like > > Metacello new > smalltalkhubUser: 'Pharo' > project: 'MetaRepoForPharo40'; > configuration: 'QualityAssistant'; > load > > and you already have the configuration package loaded, the script is > not updating the configuration itself. As the result you cannot update > to a newer version. Is there a special expression that has to be used > to update the configuration package? If not, maybe it does make sense > to update the configuration before loading it? > > Cheers! > Uko

Sept. 14, 2015

Metacello load script won't update the configuration

by Yuriy Tymchuk

Hi, when you use a script like Metacello new smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo40'; configuration: 'QualityAssistant'; load and you already have the configuration package loaded, the script is not updating the configuration itself. As the result you cannot update to a newer version. Is there a special expression that has to be used to update the configuration package? If not, maybe it does make sense to update the configuration before loading it? Cheers! Uko

Sept. 14, 2015