December 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Some Object methods that could be removed ?

by Sven Van Caekenberghe

Hi Guys, Here are 4 Object methods that could maybe be removed, right ? Object>>#xxxClass no real senders except MethodFinder Object>>#identityHashPrintString 1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either Object>>#mouseUpBalk a does nothing hook, no other implementors only two senders, looks like being related to debugging Object>>#windowReqNewLabel: a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model The last two could be changed to a conditional perform if we want to keep the hooks. If there are no objections, I could produce a slice (or slices). Sven BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Henrik Sperre Johansen

On 04.12.2012 12:49, StÃ©phane Ducasse wrote: > Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right > I will explain you why. > > Even writing comment in test is cool. > > Stef I would go so far as to say comments in tests are *especially* important. It's sometimes hard to tell whether a failure is due to a faulty test, or an actual bug, when you have no idea (even when looking at the code) what case the test was actually written to cover. With a comment of what the test was intended to do, you have a better feel for how to handle it. TL;DR: Intent, while obvious to whoever is writing the test, may not be so clear to whoever is around when it starts failing. Cheers, Henry

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sebastian Nozzi

2012/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Comments are ***REEEAALLLLY*** important because they help a guy > reading the code to say "yes, you are smart and you got it right" +1 Never thought about it that way... documentation as a confirmation of what is intuitive...

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sebastian Nozzi

I am fully for automating whatever can be automated. In this sense tests are a good combination of: * automated quality-control * sample-code Often there is no good way, for somebody new to a codebase, to distinguish between these two kinds of tests. There are tests that can be looked at like "runnable specifications" or "sample usage code". And there are tests that more about the nuts and bolts of a framework. Relevant to developers/maintainers of a package, but not for a potential user (yet). Solutions for this? Maybe categorizing tests accordingly... ? Either through packages/method-categories, or pragmas? I am also glad whenever I find an "example" method-category for a core class in a package. My 2 cents. 2012/12/4 Sven Van Caekenberghe <sven(a)stfx.eu>: > What makes me value tests a bit above documentation (but not so much > that I am saying that documentation is not important), are two things: > > - tests are machine enforceable/controllable > - you can find them exactly using senders or references

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Sven Van Caekenberghe

But I think we do agree ;-) What makes me value tests a bit above documentation (but not so much that I am saying that documentation is not important), are two things: - tests are machine enforceable/controllable - you can find them exactly using senders or references On 04 Dec 2012, at 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right > I will explain you why. > > Even writing comment in test is cool. > > Stef > >> Well written: >> >> http://kennethreitz.org/open-source-and-constraints.html >> >> I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >

Dec. 4, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by StÃ©phane Ducasse

Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right I will explain you why. Even writing comment in test is cool. Stef > Well written: > > http://kennethreitz.org/open-source-and-constraints.html > > I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Dec. 4, 2012

[Pharo-project] Gforge downtime 11 Dec

by Marcus Denker

Due to sheduled maintenance on network appliances, the INRIA Forge will be unavailable from 2 pm to 4 pm on Tuesday, December 11th 2012. Marcus

Dec. 4, 2012

[Pharo-project] [update 2.0] #20427

by Marcus Denker

20427 ----- Issue 7093: DynamicVariable>>#value:during: should return the value of evaluating its second block argument http://code.google.com/p/pharo/issues/detail?id=7093 Issue 7092: MultiByteFileStream>>#readInto:startingAt:count: currently bypasses decoding http://code.google.com/p/pharo/issues/detail?id=7092 Diff information: http://ss3.gemstone.com/ss/Pharo20/Multilingual-Tests-MarcusDenker.23.diff http://ss3.gemstone.com/ss/Pharo20/KernelTests-MarcusDenker.456.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1261.diff http://ss3.gemstone.com/ss/Pharo20/Files-MarcusDenker.ducasse.285.diff

Dec. 4, 2012

[Pharo-project] ECOOP'13/ECMFA'13/ECSA'13: Call for workshop proposals

by Damien Cassou

Call for Workshops ================== In 2013, the European Conference on Object-Oriented Programming (ECOOP), European Conference on Modelling Foundations and Applications (ECMFA) and the European Conference on Software Architecture (ECSA) will be collocated in Montpellier, France. The 3 conferences will host an exciting array of workshops that address a variety of topics in object-oriented technology, Model-Driven Engineering and software architecture. A workshop is a forum for exchanging ideas and theories that are still in an evolutionary stage. Typically, a workshop will either address a focused topic in depth or explore connections between one of the three conferences' domains and other areas of interest. ECOOP 2013, ECMFA 2013 and ECSA 2013 thus invite proposals for workshops lasting half a day, one day or two days. The workshops will be held Monday and Tuesday 1-2 July 2013. Proposals ========= A workshop proposal must be submitted as one PDF file. It must include the following information, in this order: * Name of the workshop (first page) * Table of contents for the proposal (with page numbers) * Duration of the workshop (half-day, full day, 2 days) * Abstract: 150-200 words describing the workshop, suitable for the conferences Web site * Keywords and addressed domains. * References to previous editions of the workshop (if any), including name of host conference and number of participants to the workshop each year * Summary of the workshop format: e.g., refereed papers, and/or short papers, and/or invited talks, and/or problem solving, and/or brainstorming sessions. How will papers or other submissions be reviewed? * Description of how the workshop papers and results will be published or otherwise disseminated (see the "Dissemination of Workshop Results" section below) * Preliminary Call For Workshop Papers describing the workshop's focus, its main topics and its deadlines * A (draft) list of the workshop PC members * A list of the workshop organizers * For each organizer of the workshop: - name, - affiliation - contact information - a brief biography (up to 200 words), focusing on the organizer's expertise in the field and (if applicable) experience as a workshop organizer * Primary contact: identify one organizer as the primary contact * Any special requirements that the workshop may have Workshop Schedule Constraints ============================= Each workshop will have to pay attention to the following timing constraints : * the program must be made public before the early registration deadline of the conferences; we thus expect you to make it available around mid-may; * the workshop must be able to consider submissions of papers rejected by the conferences, and have these enter its reviewing process; we thus expect you to make your submission deadline around mid-april; * the workshop must send its Call For Papers at least one month before submission deadline; we thus expect you to send your CFP around mid-march; Proposal Submission and Review ============================== Workshop proposals should be submitted by email to the workshop chairs, at ws-chairs-ec-montpellier-2013(a)inria.fr Proposals will be reviewed by the workshop chairs. Proposals will be selected based on their relevance to the conferences aims, beneficiaries, and timely advances in their respective topics. In particular, proposals will be evaluated according to the following criteria: - The potential to advance the state of research and practice - The organizers' commitment to stimulate discussion at the workshop - The organizersâ commitment to arrange for sensible digital and permanent post-meeting proceedings - The organizers' experience and ability to lead a successful workshop - Timeliness and expected interest in the workshop topics - The balance and synergy between the proposed workshops. - The continuity of previous years workshops *Workshop proposal deadline: January 10th* *Workshop proposal notification: January 16th* Workshop proposals may still be submitted after January 10th, till February 15th, and will be evaluated with the same criteria. But in addition these "late" proposals may only be accepted if their themes do not interfere with those of already accepted workshops. We thus strongly advise you to submit your workshop proposal as soon as possible, and *before* January 10th. Dissemination of Workshop Results ================================= A proposal should clearly state how the results of the workshop, that is the papers and other outcomes, will be made available to participants and others, both before and after the workshop event. ACM DL publications are encouraged. Contact ======= For additional information about this Call for Workshops, please contact the workshop chairs at ws-chairs-ec-montpellier-2013(a)inria.fr. An up-to-date version of this call for workshops may be found at: http://info-web.lirmm.fr/ec-montpellier-2013/index.php/satelliteevents?id=1… Workshop Chairs =============== Olivier Zendra, INRIA Nancy - France Reda Bendraou, UniversitÃ© Pierre et Marie Curie - France Damien Cassou, UniversitÃ© Lille 1 - France StÃ©phane Ducasse, INRIA Lille - France

Dec. 4, 2012

Re: [Pharo-project] [[ false ] whileFalse: [ ]] in workspace

by Marcus Denker

can you just put in in the issue tracker? I have no time right nowâ¦ but mails are such bad TODO trackersâ¦ On Dec 2, 2012, at 10:42 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > I've hacked a fix, but I don't know if it is correct... can somebody check it so I make a Slice? > > Guille > > On Sun, Dec 2, 2012 at 8:56 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, I've found the cause :). > > From update 20043: > > Issue 5744: Clean up Temp Embedding 2): DoIts > http://code.google.com/p/pharo/issues/detail?id=5744 > > > - Doits are now compiled with source embedded > - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added) > > CompiledMethod: > > - remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode > - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource > - remove #holdsTempNames. Temp name embedding not needed > - add isDoit > - schematicTempNamesString always returns the schematic string representation of all temps > - tempNames forwards to methodNode > - remove tempNamesString. Concatenate yourself if you need that. > > Debugger>>selectedMessage asks the selectedContext directly for the source. No need for the methodMap. > > DebuggerMethodMap > > - no special handling of methods that encode temps. Just as for methodNode always. > > MethodNode > > - generateWithSource. embedd pretty printed code in case of doit > - remove generateWithTempNames > > In general: rewrite code to use #generateWithSource > > > On Sat, Dec 1, 2012 at 6:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Sebastian > > I can tell you that what you did is **useful** because we are all working like mad > and such kind of help is really welcome. > > Stef > > On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote: > > > It's the #7076. > > > > 2012/11/29 Camillo Bruni <camillobruni(a)gmail.com>: > >> perfect! can you open a bug report with this information? :) > > > > > > > <MessageNode.GuillermoPolito.cs>

Dec. 4, 2012