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