March 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub March 26, 2016

March 26, 2016

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

1 0

[pharo-project/pharo-core]
by GitHub March 26, 2016

March 26, 2016

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

1 0

[pharo-project/pharo-core] e6b9ee: 50661
by GitHub March 26, 2016

March 26, 2016

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e6b9ee071d8bd1eccac563b8ab0fce718f728d3c https://github.com/pharo-project/pharo-core/commit/e6b9ee071d8bd1eccac563b8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-03-26 (Sat, 26 Mar 2016) Changed paths: R Keymapping-Tests.package/KMDispatcherTestCase.class/class/as yet unclassified/keymapEventBuilderClass.st R Keymapping-Tests.package/KMKeymapTest.class/class/as yet unclassified/keymapEventBuilderClass.st R Keymapping-Tests.package/KeymapBuilderTest.class/class/as yet unclassified/keymapEventBuilderClass.st M Nautilus.package/NautilusUI.class/instance/source code area/compileAMethodFromCategory_withSource_notifying_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50660.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50661.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50660.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50661.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Base.package/AbstractTool.class/instance/class/addClassIn_.st M Tool-Base.package/AbstractTool.class/instance/class/addTraitIn_.st R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examples.st R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examplesConcurrent.st R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examplesForegroundUpdate.st Log Message: ----------- 50661 17891 creating of a new method in "no messages" category does not update methods list in Nautilus https://pharo.fogbugz.com/f/cases/17891 16309 ThreadSafeTranscript>>examples doesnt work anymore https://pharo.fogbugz.com/f/cases/16309 16922 Nautilus: Using class pane menu entry "Add class" can cause problems https://pharo.fogbugz.com/f/cases/16922 17878 KM calls to unimplemented methods https://pharo.fogbugz.com/f/cases/17878 http://files.pharo.org/image/50/50661.zip

1 0

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue
by Eliot Miranda March 26, 2016

March 26, 2016

Hi Levente, the first thing to report is that this isn't a Cog-specific bug. It also reproduces using the trunk VM sources (4.15.3) and a freshly built linux VM with a 4.6 image. On Thu, Mar 24, 2016 at 2:16 AM, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > The snippet below, evaluated from a workspace, triggered the issue in less > than a minute for me, three times in a row. > Both processes will halt if #sloppyWaitForDataIfClosed: doesn't return > within a second. If you send #dataAvailable to the socket, you'll find that > it has data ready to be read, but its readSemaphore has no signal. > > Levente > > > Socket compile: 'sloppyWaitForDataIfClosed: closedBlock > > [(socketHandle ~~ nil > and: [self primSocketReceiveDataAvailable: socketHandle]) ifTrue: > [^self]. > self isConnected ifFalse: > [^closedBlock value]. > self readSemaphore wait] repeat' > classified: 'waiting'. > > [ > listenerSocket := Socket newTCP. > listenerSocket listenOn: 0 backlogSize: 4 interface: #[127 0 0 1]. > clientSocket := Socket newTCP. > clientSocket connectTo: #[127 0 0 1] port: listenerSocket > localPort. > clientSocket waitForConnectionFor: 1. > self assert: clientSocket isConnected. > serverSocket := listenerSocket waitForAcceptFor: 1. > self assert: serverSocket isConnected ] > ensure: [ listenerSocket destroy ]. > > serverProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > [ serverSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := serverSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PING'. > serverSocket sendData: 'PONG' ] repeat ] newProcess. > clientProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > clientSocket sendData: 'PING'. > [ clientSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := clientSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PONG' ] repeat ] > newProcess. > clientProcess priority: 39; resume. > serverProcess priority: 39; resume. > > "Evaluate these after debugging: > clientSocket destroy. > serverSocket destroy." > > > > On Wed, 23 Mar 2016, Eliot Miranda wrote: > > Hi Levente, >> On Wed, Mar 23, 2016 at 11:31 AM, Levente Uzonyi <leves(a)caesar.elte.hu> >> wrote: >> Hi Eliot, >> >> What sort of reproducibility are you looking for? Is it enough if >> it happens once every few hours or do you need something that you can >> trigger on demand? >> >> >> I'll take every few hours, but I'd prefer "in under 30 minutes". Getting >> warm and fuzzy feelings when trying to prove a negative with something that >> takes hours to run is very difficult. Let's say you have >> a case which reproduces in 8 hours 50% of the time. To reach 99% >> confidence level in a fix I'd have to run it for 8 * (50 log: 2) hours >> without seeing it reproduce, right? That's nearly 2 days; it could >> take weeks to fix :-( >> >> Levente >> >> >> >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- _,,,^..^,,,_ best, Eliot

1 0

Green builds on Github
by Max Leske March 25, 2016

March 25, 2016

Hi, Just wanted to let you know that the Github builds are now all green (since now the DateAndTime issue in Squeak has been fixed), i.e. Pharo-alpha, Pharo 5.0, Pharo 4.0, Squeak-trunk, Squeak-4.6, Squeak-4.5 on both OS X and Linux. See for yourself here: https://github.com/theseion/Fuel. Note that the sources are still being hosted on Smalltalkhub. Iâm triggering the builds through the TravisCI API when I run a build on the INRIA CI. Iâd like to thank Tobias Pape and Fabio Niephaus for their help in setting this up and for creating the SmalltalkCI infrastructure for TravisCI. Cheers, Max

2 1

fullscreen on MacOS (possible VM bug)
by J.F. Rick March 25, 2016

March 25, 2016

Hi, I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn". On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop (MacMini, 4k display, OS 10.11.3), the screen goes to black for several seconds and the VM crashes. I am attaching the crash.dmp file. Note that this is a new Pharo4.0 I just downloaded from pharo.org. If I maximize the screen using the green button on the Pharo window, it does not crash. But, it does mean that anytime I move my cursor towards the top the Apple menus appear. That's not ideal for this purpose but could be acceptable. When I quit and restart Pharo, it doesn't come back in full screen mode. Is there Pharo code I can run to have it be in this kind of fullscreen mode without user action? Cheers, Jeff

2 3

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue
by Eliot Miranda March 25, 2016

March 25, 2016

Hi Levente, On Thu, Mar 24, 2016 at 2:16 AM, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > The snippet below, evaluated from a workspace, triggered the issue in less > than a minute for me, three times in a row. > Both processes will halt if #sloppyWaitForDataIfClosed: doesn't return > within a second. If you send #dataAvailable to the socket, you'll find that > it has data ready to be read, but its readSemaphore has no signal. > > Levente > > > Socket compile: 'sloppyWaitForDataIfClosed: closedBlock > > [(socketHandle ~~ nil > and: [self primSocketReceiveDataAvailable: socketHandle]) ifTrue: > [^self]. > self isConnected ifFalse: > [^closedBlock value]. > self readSemaphore wait] repeat' > classified: 'waiting'. > > [ > listenerSocket := Socket newTCP. > listenerSocket listenOn: 0 backlogSize: 4 interface: #[127 0 0 1]. > clientSocket := Socket newTCP. > clientSocket connectTo: #[127 0 0 1] port: listenerSocket > localPort. > clientSocket waitForConnectionFor: 1. > self assert: clientSocket isConnected. > serverSocket := listenerSocket waitForAcceptFor: 1. > self assert: serverSocket isConnected ] > ensure: [ listenerSocket destroy ]. > > serverProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > [ serverSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := serverSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PING'. > serverSocket sendData: 'PONG' ] repeat ] newProcess. > clientProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > clientSocket sendData: 'PING'. > [ clientSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := clientSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PONG' ] repeat ] > newProcess. > clientProcess priority: 39; resume. > serverProcess priority: 39; resume. > > "Evaluate these after debugging: > clientSocket destroy. > serverSocket destroy." Fabulous, thank you! replace the self halts with e.g. self assert: (clientSocket dataAvailable = (clientSocket readSemaphore excessSignals > 0)), and we even have a test. I have work to do tomorrow but hope I should be able to debug this soon. I'll add kqueue and epoll support when I fix it. (Stephan, interesting suggestion to throw hardware at the problem, thank you). On Wed, 23 Mar 2016, Eliot Miranda wrote: > > Hi Levente, >> On Wed, Mar 23, 2016 at 11:31 AM, Levente Uzonyi <leves(a)caesar.elte.hu> >> wrote: >> Hi Eliot, >> >> What sort of reproducibility are you looking for? Is it enough if >> it happens once every few hours or do you need something that you can >> trigger on demand? >> >> >> I'll take every few hours, but I'd prefer "in under 30 minutes". Getting >> warm and fuzzy feelings when trying to prove a negative with something that >> takes hours to run is very difficult. Let's say you have >> a case which reproduces in 8 hours 50% of the time. To reach 99% >> confidence level in a fix I'd have to run it for 8 * (50 log: 2) hours >> without seeing it reproduce, right? That's nearly 2 days; it could >> take weeks to fix :-( >> >> Levente >> >> >> >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- _,,,^..^,,,_ best, Eliot

2 2

SessionManager (aka new startup / shutdown list manager) needs testers
by Christophe Demarey March 25, 2016

March 25, 2016

Hi, Guillermo, Pablo and I started to work on a new implementation for the image startup / shutdown list. The old implementation misses domain objects, polluted the SmalltalkImage class and introduced crazy dependencies to other packages. So, what is Session Manager? a replacement of the Session class (is now WorkingSession) a rewrite of startup / shutdown list with domain objects SessionManager: can create new sessions and manage categories. Also provide a facade to register new session handlers. Session manager provide sthe list of handlers by order of priority (categories order and categories priority) either for the startup or the shutdown, WorkingSession: unique object for the current smalltalk session (I.e. between a startup and a shutdown). On each image startup the current session is invalidated and a new session is created. Define how errors should be handled. Run the startup / shutdown process. SessionCategory: we defined some well known categories for startup / shutdown: system, network, GUI, tools and there is room to add user specific categories, It help to run the handler at the right time without caring about the whole order. and SessionHandlers: handleSession for a specific class or any other object. the shutdown list is now simply the startup list reversed we also refactored error handling at startup by using the UIManager and StartupUIManager. It allowed to remove ugly checks like #isInteractive, isHeadless in error handling methods and centralize that in UIManager. You can find an image with the new SessionManager in action here: https://ci.inria.fr/pharo-contribution/job/SessionManager/ As it is a critical piece of code, could you play / test it a bit before we integrate this new mechanism in the Pharo image? Regards, Christophe ps: Pharo tests pass ps2: There is still some code to clean / remove from the old startup management system.

6 13

[ann] pharo consortium membership matching campaign
by Tudor Girba March 25, 2016

March 25, 2016

Hi, The Pharo Board is proud to announce a special campaign for attracting new Pharo Consortium members during 2016: http://consortium.pharo.org/web/Membership A new fund has been created from which the Consortium will receive the equivalent of one yearly membership fee for every new member, and the increment in yearly fees for every upgrading member. For example, if a new company joins the Consortium as a Silver member (2000 EUR / year), the fund will contribute a one-time amount of 2000 EUR to the Consortium. Similarly, if a company upgrades from Bronze (1000 EUR / year) to Gold (4000 EUR / year), the fund will contribute a one-time amount of 3000 EUR. This campaign will take place until the end of 2016, or until the fund is depleted. Currently, the fund totals 21000 EUR, a sum which is graciously supported by three companies: - LabWare Inc (http://labware.com) - ObjectProfile (http://objectprofile.com) - feenk gmbh (http://feenk.com) This is an exciting development that paves the way to attract more industrial interest around Pharo. Please help us by spreading the word about this campaign. Cheers, The Pharo Board

1 0

[ANN] Simple FogBugz Search tool in Pharo
by Torsten Bergmann March 25, 2016

March 25, 2016

Hi, played with the JSON API of Pharo FogBugz issue tracker with the outcome of another little Pharo tool that lets you: - login to FogBugz from Pharo - enter a string and search for according issues - open a browser on a selected issue in the result list (works on Linux and Win so far) The project repo is at: http://www.smalltalkhub.com/#!/~TorstenBergmann/FogBugz One can use the client also directly: |client| client := FogBugzClient loginUser: 'abc(a)def.com' password: 'secret'. (client query: 'UFFI') inspect. client logout You can download the tool in latest Pharo 5 (50660 or later) from catalog or by opening the Spotter and entering "FogBugz", wait and hitting ENTER. Attached is a screenshot. Enjoy T.

1 0