- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Vim Keys?

by Sean P. DeNigris

Goubier Thierry wrote > the removal of the global, class-linked maps (it was rejected)... > This is the only step missing for your vim shortcuts to work. Yes!!! That's exactly what was holding me up... From http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022… : Sean P. DeNigris wrote > > Guillermo Polito wrote >> - static shortcuts (per class) >> - dynamic category shortcuts ( you build a category and attach it to an >> instance) > The thing is that these two conflict. If I add a category to a class in > the "static shortcuts" (which I consider to be "default shortcuts" - I > think that's more useful), and then I want to remove that category for an > instance, I can't. > > What I want is: each instance gets its own copy of all its maps. If the > morph instance doesn't have any per-instance customizations, this can > point to the class defaults to save space (but I think this would be > premature optimization). However, as soon as the instance differs at all > from the class defaults, it /must/ have it's own local copy of all the > maps. I don't want to have to override each shortcut of a category > attached to the class. I want to detach the category /for just this > instance/. -- View this message in context: http://forum.world.st/Re-Vim-Keys-tp4657381p4657920.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 3, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 497 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Dec. 3, 2012

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

by Eliot Miranda

On Sun, Dec 2, 2012 at 2:59 PM, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Would it be possible to start native thread inside pharo? This thread would > run (for quite a long time) some event loop (like the libev), and post some > info to the SharedQueue. Smalltalk code would in turn be reading stuff from > this queue. You could say it would be pumping events from libev to > SharedQueue instance for Smalltalk code to consume. > > Is this doable? With NativeBoost or Plugin? > > I have also found some info on threaded VM, but if I understand it > correctly > it seems more oriented to provide a thread to execute FFI call on it. > I wouldn't say that. The threading scheme is David Simmons' architecture, used in his AOS and S# VMs and similar to that used in the python VM, but more efficient. It allows multiple threads to share the VM, but only allows one to run Smalltalk at any one time. It is designed to allow Smalltalk to interact freely with any number of native threads. Cal-backs can come in from any thread. SMalltalk processes can be associated with specific threads, allowing one to control which thread a call-out is made on. ----- > http://www.cloud208.com/ > -- > View this message in context: > http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plu… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

Dec. 3, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Sven Van Caekenberghe

On 03 Dec 2012, at 19:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, the lack of FileStream buffering was (re)-discovered and > corrected when I have experimented with my own SqueaXTream experiments > http://www.squeaksource.com/XTream/ before porting the original > Xtreams to Squeak http://www.squeaksource.com/Xtreams/ > Then Levente soon came up with an excellent patch for buffering Squeak > FIleStream and this was later ported to Pharo. > > What I also re-discovered is that not only buffering the raw file > counts, but also buffering the decoding. > Indded, an uncarefull implementation would read file by chunk but > decode byte after byte... > While a buffered one would decode large chunks of ASCII (if any) in a > single copy primitive. > > This was reported near the end of this post: > http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 > > For Xtreams, I don't remember exactly where I put some experiments, > but pre-allocating a WideString instead of a String can also make a > noticeable difference in presence of WideCharacter... Many people seem to be rediscovering the same problems, not a good sign ;-) I think that in particular MultiByteFileStream>>#peek is not efficient. Yeah, there seems to be a WideString construction issue as well, I haven't looked into it yet. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 3, 2012

Re: [Pharo-project] DynamicVariable>>value:during:

by Sven Van Caekenberghe

http://code.google.com/p/pharo/issues/detail?id=7093 -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 02 Dec 2012, at 22:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I think so too, but maybe there was some reason for not doing it ? > > On 02 Dec 2012, at 20:52, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hey guys, >> >> would not make much much more sense if we return the result of evaluating the block when we use dynamic variables? >> >> Here is the patch I'm using these days: >> >> DynamicVariable>>value: anObject during: aBlock >> >> | p oldValue result | >> p := Processor activeProcess. >> oldValue := (p psValueAt: index) ifNil: [self default]. >> [ >> p psValueAt: index put: anObject. >> result := aBlock value. >> ] ensure: [ >> p psValueAt: index put: oldValue >> ]. >> >> ^ result

Dec. 3, 2012