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

[update 3.0] #30263
by Marcus Denker July 10, 2013

July 10, 2013

30263 ----- 11142 For 3.0: 11102 FileSystemError https://pharo.fogbugz.com/f/cases/1114 10466 Better interruption https://pharo.fogbugz.com/f/cases/10466 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.42.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1514.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Disk-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.…

1 1

[regression reporter]regression occurred
by no-reply＠ci.inria.fr July 10, 2013

July 10, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 2 regressions found. Tests.Polymorph.Widgets.FileDialogWindowTest.testIssue6406 Tests.Release.ReleaseTest.testObsoleteClasses

1 0

[update 2.0] #20612
by Marcus Denker July 10, 2013

July 10, 2013

20612 ----- 10569 Backport 2.0: Better Interrruptionche https://pharo.fogbugz.com/f/cases/10569 10940 Backport 2.0: 10925 Use caching in Gofer https://pharo.fogbugz.com/f/cases/10940 Diff information: http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.782.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1350.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.194.diff

2 1

thisContext usecases
by ClÃ©ment Bera July 10, 2013

July 10, 2013

Hello pharoers, Recently I have been looking at the Pharo thisContext capabilities, in order to perhaps one day in the far future edit its implementation with the Pharo dev team. Nothing is planned or confirmed, it is just to discuss. A context has instances variables (method closureOrNil receiver stackp sender pc) and holds the arguments and temporaries. Now I'd like to know what context's state do we modify, and what states are just internal representations ? For example, it seems that you can do 'thisContext receiver: #foo', but you cannot with Cog. SomeClass>>foo thisContext receiver: #foo. ^ self In workspace, evaluating: 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] Transcript result (with Cog): foo foo a SomeClass a SomeClass a SomeClass Transcript result (with Stack or Vanilla): foo foo foo foo foo Now as no one has ever complained, I guess this feature is not used. As far as I know, the real use cases of the context seems to be: - setting and gettings temporaries - setting and getting the sender of a context - setting and getting the pc - getting method, closureOrNil, receiver, stackp, arguments but NOT setting them Now setting the sender of a context seems to be used only in two cases: - continuations (as seaside continuations) - exception implementation So imagine that in the future you would have a context that can be accessed in read-only, where you could only: - set the temporaries (but not arguments) - set the pc (or something equivalent, as set the currently executed ast node) - use continuations (exceptions can be implemented on top of continuations) I would like to know if there are things that you do now and that you would not be able to do with a context like that. For non meta developer (like enterprise app developer) I guess it will not change anything, but I want to know if you implemented a framework as seaside, does it requires other things from the context and why ? Thanks for answering,

4 8

should:raise:description:
by Camillo Bruni July 10, 2013

July 10, 2013

I continue my rant with should:raise:description: a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. b) self should: [ 1 + 2 ] raise: Halt description: 'message'. In the first case you do not get the 'message' but 'error message'. In the second case you get the 'message'. Does the description make sense in this case? 1. if you signal Halt everything is fine 2. Every other case is a failure 3. In case a) an internal failure happens so the test fails anyway, fine, but no description 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. Can anybody give me a convincing case for 4? Sorry, after this I will stop :D

4 5

[regression reporter]regression occurred
by no-reply＠ci.inria.fr July 10, 2013

July 10, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

1 0

Jenkins build became unstable: Pharo-2.0-Tests Â» run 1,vm,win #258
by no-reply＠ci.inria.fr July 10, 2013

July 10, 2013

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=win/2…>

1 1

More manpower needed for reviewing fixes...
by Marcus Denker July 10, 2013

July 10, 2013

Hi, We mananged to nearly review (and often integrate) almost all pending fixes and enhancements. There are 4 issues left: https://pharo.fogbugz.com/f/filters/36/Review It would be nice if more people would be involved. If *you* don't comment, it might be we will do the wrong thing? Marcus

1 0

sunit failures vs errors
by Torsten Bergmann July 10, 2013

July 10, 2013

Camillo wrote: >Does anybody here distinguish failures and errors for real when doing TDD? Yes, it has a special meaning AND is very helpfull - ESPECIALLY when you start with tests first (XPStyle): Usually one writes the tests and then you try to get them from red over yellow to green: red: there is a real error, for instance a message is not yet implemented (maybe only the test was written and one uses the debugger and the "Create" functionality to create the calls) yellow: the basic calls are there/messages implemented and working (no DNU) but an expectation is not yet met since an assertion fails green: everything is OK Or to quote Kent Beck: http://www.xprogramming.com/testfram.htm <quote> "Failures and Errors The framework distinguishes between failures and errors. A failure is an anticipated problem. When you write tests, you check for expected results. If you get a different answer, that is a failure. An error is more catastrophic, a error condition you didn't check for." </quote> Please keep it separated, it is very usefull. >Besides the complexity added to the testing framework it is a burden for newcomers. Learning about Pragmas, Methods, Classes, Debugger, marking expected failures, ... is also a burden for newcomers. Will we throw them out? No! SUnit is still really simple and a pleasure to work with! Thx Torsten

2 1

OSDC.fr: 5th Open Source Developers Conference in France
by Damien Cassou July 9, 2013

July 9, 2013

Call for Papers 5th Open Source Developers Conference in France Montrouge Beffroi cultural centre, Paris, October 4 & 5, 2013 OSDC.fr objective is to gather French speaking developers from different communities around innovative technologies. After two editions on our own, we are since 2011 associated to Open World Forum and its numerous partners in order to provide the best experience to our attenddees. For the 5th edition of this conference, we invite you to gather the communities dedicated to programming based on free/libre languages such as Perl, Python, Ruby, PHP, Smalltalk & much more. The aim is to learn by exploring the universe of all languages, for many concepts and techniques aren't tied to a specific environment, and therefore allow cross-pollinations. So we invite you to join us by taking part in OSDC.fr, either by submitting a talk proposal <http://act.osdc.fr/osdc2013fr/newtalk> (preferably in French, but English is acceptable), or simply by joining us on October 4 & 5, 2013, at at Montrouge Beffroi cultural centre. Entrance is free and everyone is welcome. Talks can last 25 or 45 minutes. We'll also have a lightning talks session, where talks are limited to 5 minutes max. Here is a non-exhaustive list of possible subjects: - Themes related to programming languages such as Perl, PHP, Python, Ruby, Erlang, JavaScript, node.js, Lua, Scala, Clojure, Groovy, Haskell, C, C++, Smalltalk, Java, etc. - Dynamic compilation - Interpreters and virtual machines (LLVM, JVM, CLR, Parrot, etc) - Development tools - Development best practices - Programming experience feedback - Libraries - Making of innovative languages and their implementation - Software maintenance - Integration of different languages - Teaching techniques - Modern techniques of system administration, industrialization, distributed infrastructure (*cloud*) - Big Data, OpenData Key dates: - Deadline for submitting a talk : September 6th, 2013 - Final schedule : September, 2013 - OSDC.fr conference : October 4 & 5, 2013

1 0