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

[Pharo-project] one-click is dead, now we have platform specific builds
by Esteban Lorenzano March 24, 2013

March 24, 2013

tbh, one-click was just cool for mac users... windows and linux users (specially newcomers) where having bad reaction with the structure that the one-click enforces. The new scripts produces structures that can fit better into the platforms where they will run. You can check them here: http://files.pharo.org/platform/ of course, a lot of improvements are possible, this is just the first step :) Esteban

22 41

[Pharo-project] Contribution CI Semantics
by Ben Coman March 24, 2013

March 24, 2013

Just curious about how the Contribution CI is set up. Is is based off the latest ConfigurationOf or just the latest mcz loaded in the folder? Will you be running a #stable as well as #development jobs for contributions? Or will that decision be configured somehow by the contribution developers, who may want to choose one of four quadrants from... x-axis 1. Pharo 2.x 2. Pharo 3.x y-axis A. Contribution #stable B. Contribution #development 1A. Presumed this should _always_ be green. Perhaps automatically copied to the ConfigurationBrowser repository. Gives Pharo developers early opportunity to see the impact of bug fix leading up to a minor release. 1B. Mostly green jobs and usually only temporarily red. It would be interesting if the CI/Smalltalkhub integration being developed could help moving a green 1B job to 1A with a minimum of steps - perhaps a single click. 2A. Red contribution jobs expected and maybe last a long time, but useful for giving contribution developers early opportunity to track which infrastructure changes caused the red job. 2B. For the fastest feedback cycle for those contribution developers working on the bleeding edge in parallel with Pharo developers. Of course that increases the CI resource requirements and additional effort to set up, but just something to consider... cheers -ben

4 4

[Pharo-project] Please help! Weird error!
by Steven R. Baker March 24, 2013

March 24, 2013

Heya folks, I've got a failing test here, screenshot attached. When I inspect events, it contains the mock I'm looking for. For some reason, the self assert: (events includes: mockEvent1) fails. But when I inspect, events is an OrderedCollection with one item, and it appears to be the mock. Please help! Thanks in advance! -Steven

3 2

[Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip
by Andrei Vasile Chis March 23, 2013

March 23, 2013

Hi, Lately I started to get ConnectionClosed errors when loading packages from Smalltalkhub by using Monticello. It's very likely to just be a problem with my environment, as I'm connecting through a university server, but I got stuck debugging it. Just to see if I can download packages normally I tried two things: ZnClient new systemPolicy; url: ' http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… '; beOneShot; get. ZnClient new systemPolicy; url: ' http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… '; setAcceptEncodingGzip; beOneShot; get. In the first case it works perfectly. However when I add 'setAcceptEncodingGzip' every time I get: [ConnectionClosed signal: 'Connection closed while waiting for data.'] in Socket>>waitForDataFor: but if I proceed from this error I get the right content. Monticello uses "setAcceptEncodingGzip" so I get the above error. If I remove it, it works ok. I've tried this with the Pharo2.0-one-click image on Mac OS (all the compression tests pass). Doing a request using curl with "Accept-Encoding: gzip,deflate" to the same url works ok. Am I missing something obvious? Cheers, Andrei

5 19

[Pharo-project] [update 3.0] #30010
by Marcus Denker March 23, 2013

March 23, 2013

30010 ----- 10076 Cleaning code formatting of criticbrowser https://pharo.fogbugz.com/f/cases/10076/ 10101 Object: remove #class https://pharo.fogbugz.com/f/cases/10101 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Manifest-Tests-MarcusDenker.… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Manifest-CriticBrowser-Marcu… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Manifest-Core-MarcusDenker.1… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1345

1 0

[Pharo-project] Updated the download page
by Marcus Denker March 23, 2013

March 23, 2013

http://www.pharo-project.org/pharo-download Instead of 1.4 and 2.0 it now lists 2.0 and 3.0

4 7

[Pharo-project] [update 3.0] #30009
by Marcus Denker March 23, 2013

March 23, 2013

30009 ----- 10005 floatPrecision: setter is missing from UpdatingStringMorph https://pharo.fogbugz.com/f/cases/10005/ 10100 TaskListMorph: remove unused classVar UseHistoricalShortcuts https://pharo.fogbugz.com/f/cases/10100 10099 Improve CommandLineArgument API optionAt:ifPresent: https://pharo.fogbugz.com/f/cases/10099/ 10095 HandMorph>>userPicture[:aPicture] unused. Can be removed. https://pharo.fogbugz.com/f/cases/10095 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/System-CommandLine-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Polymorph-Widgets-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1380

1 0

[Pharo-project] SocketStream>>#next:
by Sven Van Caekenberghe March 23, 2013

March 23, 2013

Hi, Related to a hard to find Zinc bug that I just discovered, I require some feedback as to the semantics of SocketStream>>#next: IMHO, the current implementation is semantically wrong. I would expect the semantics to be: try to read count elements and return a new species collection containing them. If less elements are available, return a smaller collection. ( It then becomes effectively a limited #upToEnd). I always implemented #next: by delegating to #next:into:, to #next:into:startingAt: and finally #readInto:startingAt:count: (see for example ZdcAbstractSocketStream, ZnLimitedReadStream or ZnChunkedReadStream). When you look at the implementations of #next:into:, #next:into:startingAt: and #readInto:startingAt:count: on SocketStream, the fact that ConnectionClosed is not signalled is clearly stated. Yet SocketStream>>#next: is different, it does signal ConnectionClosed, which makes it impossible (unless you proceed the exception) to read up to end. And this is what InflateStream>>#getFirstBuffer expects. And which fails when less than 65536 bytes are available. Note that InflateStream reads its subsequent buffers using #next:into:startingAt: (see #moveSourceToFront) so that it properly reads up to end without signalling ConnectionClosed for larger payloads. I can easily program around it, but I think SocketStream>>#next: is wrong and should be changed. Any opinions ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

5 7

March 22, 2013

We are really happy to announce that High Octane is a new member of the consortium. Thanks a lot for your trust, Philippe! http://www.highoctane.be/sections/vision.html Stef for the Pharo community!

4 4

[Pharo-project] Fwd: 18 months Post-Doc Position on Software Engineering for Mobile Robotics
by Noury Bouraqadi March 22, 2013

March 22, 2013

Begin forwarded message: > Date: 22 mars 2013 21:35:28 HNEC > Subject: 18 months Post-Doc Position on Software Engineering for Mobile Robotics > Source: CAR: Components, Agents, and Robots > Author: noury > > The CAR team (http://car.mines-douai.fr) carries research at the frontier of Software Engineering and Robotics. We study software architectures, languages and tools for controlling individual robots. We have developed an expertise in reflective and dynamic languages, as well as component models, for a modular robotic software architectures. Besides, our research also addresses coordination and cooperation inâ¦ Continue reading â > Read moreâ¦ > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

1 0