- Esug-list - lists.esug.org

Call for Participation Smalltalk Directions

by Stéphane Ducasse

Hi guys I encourage you to send article to Smalltalk Directions Stef 19th–21st March 2012, Biloxi, Mississippi Smalltalk Directions is a refereed symposium that will be co-located with the Smalltalk Industry Conference (STIC) in March 2012. The Smalltalk Directions Symposium will run in parallel with STIC, offering a parallel track of presentations of refereed academic work that will be open to all attendees of STIC. We solicit research papers concerned with the future of the Smalltalk language, forward-looking applications of Smalltalk and Smalltalk-inspired languages, and the core technologies supporting such languages, including but not limited to: 1. Libraries & Frameworks 2. Language extensions and contractions 3. Implementation technologies, such as Virtual machines, compilers, instruction sets, garbage collection 4. Object persistence 5. Distributed objects 6. Program development tools and environments 7. Using Smalltalk to educate future object-oriented programmers 8. Design Patterns in and for Smalltalk 9. Modelling 10. Meta-programming 11. Domain-specific languages implemented in Smalltalk 12. Smalltalk on the web Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful information on how to write effective submissions. We are working to have accepted papers appear in the ACM Digital library. A special issue of the Journal of Object Technology will be published in conjunction with the symposium. The authors of selected papers will be invited to submit an extended version of their Smalltalk Directions submission to this special issue, which will then conduct its own reviewing precess. Papers must be submitted electronically using EasyChair (https://www.easychair.org/conferences/?conf=smalltalkdirections2) Important Dates Paper submission deadline 6th January 2012 Author notification 4th February 2012 Final version deadline 24th February 2012 Symposium 19th– 21st March 2012 Organizing Committee Andrew P Black Portland State University, USA black(a)cs.pdx.edu Ralph Johnson University of Illinois, Urbana-Champaign, USA rjohnson(a)illinois.edu Roger Whitney San Diego State University whitney(a)cs.sdsu.edu David West New Mexico Highlands University dmwest(a)nmhu.edu

Dec. 5, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by stephane ducasse

tx :) On Dec 3, 2011, at 11:23 AM, Johan Brichau wrote: > Hi all, > > A little late, but I still wanted to react to these questions. > > Besides the obvious question on 'what functionality does the change fix/add/remove?', I often find myself navigating and browsing code to answer the following questions: > > - Does the change remain confined to a module (this can be a package, class, …) or is it crosscutting ? > - What parts of the system are directly using the changed behavior? Is it a central part of the system with many dependents? > - Who was the owner of the code that was changed? Should another developer review these changes (i.e. the original author whose code was adapted) ? > - If the change is a refactoring, were all appropriate parts refactored and no inappropriate ones included? Are there other packages that would need to change as well to incorporate this change? > - Does the code (partially) reinvent the wheel? In essence: does it introduce code duplication or does it implement parts that are reimplementations of existing parts in the code base or existing libraries? > - How about the unit tests? Was there a new test? Were they adapted? Is the code in this change covered adequately ? > > I assume the verification of coding conventions, unit testing, etc… as a step of the integration process as well. > > I should also note that, in our case, every developer needs to integrate his work in the trunk himself. A first check is therefore done by the developer who is merging his changes in the trunk. This change in the trunk is afterwards verified with the questions above. This means that, at that time, problems related to parallel changes are practically non-existant (i.e. the developer who integrates needs to deal with those directly). Daily coordination amongst developers also reduces the possibility on conflicting parallel changes. Such a single branch development is feasible for us because we work with a single software version and excluding changes from the trunk is a very uncommon decision (bad changes need to be corrected appropriately instead of simply left out). > > best regards, > Johan > > On 27 Nov 2011, at 20:45, Tudor Girba wrote: > >> Hi, >> >> Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example: >> - I would like to be able to group them by author, or >> - I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time). >> >> Cheers, >> Doru >> >> >> On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote: >> >>> Hi guys >>> >>> We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) >>> What are the questions that you ask yourselves when you are/want to merge some code in your project? >>> We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. >>> >>> Here are some typical questions we asked ourselves. >>> - What other changes did this change require? >>> - Can I integrate this change right now? >>> - How large it is? >>> - Who made it? >>> - Is it still valid (when I'm working on an old change)? >>> - Is this change impacted by a change that happened in another branch of my software? >>> >>> Stef D., Andy K. and Veronica U. >>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Dec. 4, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Johan Brichau

Hi all, A little late, but I still wanted to react to these questions. Besides the obvious question on 'what functionality does the change fix/add/remove?', I often find myself navigating and browsing code to answer the following questions: - Does the change remain confined to a module (this can be a package, class, …) or is it crosscutting ? - What parts of the system are directly using the changed behavior? Is it a central part of the system with many dependents? - Who was the owner of the code that was changed? Should another developer review these changes (i.e. the original author whose code was adapted) ? - If the change is a refactoring, were all appropriate parts refactored and no inappropriate ones included? Are there other packages that would need to change as well to incorporate this change? - Does the code (partially) reinvent the wheel? In essence: does it introduce code duplication or does it implement parts that are reimplementations of existing parts in the code base or existing libraries? - How about the unit tests? Was there a new test? Were they adapted? Is the code in this change covered adequately ? I assume the verification of coding conventions, unit testing, etc… as a step of the integration process as well. I should also note that, in our case, every developer needs to integrate his work in the trunk himself. A first check is therefore done by the developer who is merging his changes in the trunk. This change in the trunk is afterwards verified with the questions above. This means that, at that time, problems related to parallel changes are practically non-existant (i.e. the developer who integrates needs to deal with those directly). Daily coordination amongst developers also reduces the possibility on conflicting parallel changes. Such a single branch development is feasible for us because we work with a single software version and excluding changes from the trunk is a very uncommon decision (bad changes need to be corrected appropriately instead of simply left out). best regards, Johan On 27 Nov 2011, at 20:45, Tudor Girba wrote: > Hi, > > Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example: > - I would like to be able to group them by author, or > - I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time). > > Cheers, > Doru > > > On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote: > >> Hi guys >> >> We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) >> What are the questions that you ask yourselves when you are/want to merge some code in your project? >> We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. >> >> Here are some typical questions we asked ourselves. >> - What other changes did this change require? >> - Can I integrate this change right now? >> - How large it is? >> - Who made it? >> - Is it still valid (when I'm working on an old change)? >> - Is this change impacted by a change that happened in another branch of my software? >> >> Stef D., Andy K. and Veronica U. >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Dec. 3, 2011

Re: [Esug-list] ESUG Video upload continuing...

by Sean P. DeNigris

Marcus Denker-4 wrote > > I will add them to all the conference pages. > Thanks :) -- View this message in context: http://forum.world.st/ESUG-Video-upload-continuing-tp3877544p4128506.html Sent from the ESUG mailing list archive at Nabble.com.

Dec. 1, 2011

Re: [Esug-list] ESUG Video upload continuing...

by Marcus Denker

On Nov 28, 2011, at 5:29 PM, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> We are slowly, but steadily uploading videos to Youtube. >> > > Will someone add a link from the ESUG 2011 page (like the one for 2010). > The Playlists are: ESUG 2008: http://www.youtube.com/playlist?list=PL4A297B9019B3884D ESUG 2009: http://www.youtube.com/playlist?list=PL74E35D8EC7E756AE ESUG 2010: http://www.youtube.com/playlist?list=PL431285A978F581BB ESUG 2011: http://www.youtube.com/playlist?list=PL813665D04A2E4C0A I will add them to all the conference pages. -- Marcus Denker -- http://marcusdenker.de

Dec. 1, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Stan Shepherd

Is this a fix to production? If so, has it also been backfilled to the development branch? ...Stan -- View this message in context: http://forum.world.st/Call-for-your-input-on-questions-you-ask-yourselves-d… Sent from the ESUG mailing list archive at Nabble.com.

Nov. 29, 2011

Re: [Esug-list] ESUG Video upload continuing...

by Sean P. DeNigris

Marcus Denker-4 wrote > > We are slowly, but steadily uploading videos to Youtube. > Will someone add a link from the ESUG 2011 page (like the one for 2010). Thanks. Sean -- View this message in context: http://forum.world.st/ESUG-Video-upload-continuing-tp3877544p4115797.html Sent from the ESUG mailing list archive at Nabble.com.

Nov. 28, 2011

Re: [Esug-list] fosdem smalltalk devroom

by Paolo Bonzini

On 11/28/2011 01:45 PM, Stephan Eggermont wrote: > No, not yet. Do we need a separate one or can we use one of the existing ones? > I'm following a.o. squeak-dev, pharo-dev, seaside FOSDEM gives a mailing list, right? I would like GNU Smalltalk to be represented, since I'll be attending FOSDEM too. Paolo

Nov. 28, 2011

Re: [Esug-list] fosdem smalltalk devroom

by Stephan Eggermont

No, not yet. Do we need a separate one or can we use one of the existing ones? I'm following a.o. squeak-dev, pharo-dev, seaside Stephan On 28 nov 2011, at 12:37, Paolo Bonzini wrote: > Hi all, is there a mailing list or website set up for discussing the program for the devroom? > > Thanks, > > Paolo > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 28, 2011

fosdem smalltalk devroom

by Paolo Bonzini

Hi all, is there a mailing list or website set up for discussing the program for the devroom? Thanks, Paolo

Nov. 28, 2011