- Pharo-dev - lists.pharo.org

[Pharo-project] impossible to integrate -> squeaksource is down and restart and get down again.

by stephane ducasse

does anybody have an idea? Stef

May 2, 2010

Re: [Pharo-project] gettext package

by StÃ©phane Ducasse

Ok I understand now. Stef On May 2, 2010, at 6:13 PM, Michael Rueger wrote: > >> can you give a sketch example so that I the it? >> >> instaed of 'lkjhlk' translated >> NaturalLanguageTranslator translated: 'lkjhlk' > > No, you keep the 'lkjhlk' translated :-) > > Apologies, the current implementation does already what I meant > > String>>translated > ^ NaturalLanguageTranslator current translate: self > > All you would need to do is to exchange the implementation of NaturalLanguageTranslator depending on whether you want to use the current implementation or gettext. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 2, 2010

Re: [Pharo-project] gettext package

by Michael Rueger

> can you give a sketch example so that I the it? > > instaed of 'lkjhlk' translated > NaturalLanguageTranslator translated: 'lkjhlk' No, you keep the 'lkjhlk' translated :-) Apologies, the current implementation does already what I meant String>>translated ^ NaturalLanguageTranslator current translate: self All you would need to do is to exchange the implementation of NaturalLanguageTranslator depending on whether you want to use the current implementation or gettext. Michael

May 2, 2010

Re: [Pharo-project] gettext package

by StÃ©phane Ducasse

On May 2, 2010, at 5:52 PM, Michael Rueger wrote: > On 5/1/10 2:05 PM, Hilaire Fernandes wrote: >> StÃ©phane Ducasse a Ã©crit : >> >>>> - If we want the gettext package to be loadable, the method >>>> String>>translated in core could be changed to return self, then the >>>> gettext packaged provided the translated version to effectively >>>> handle the translation. >>> >>> but this would be an override. >> >> Yes, is it a problem? > > Yes, overrides in a core class are always a problem. > > Another way to solve this would be to dispatch translated through NaturalLanguageTranslator which I guess would be completely replaced by the gettext package? can you give a sketch example so that I the it? instaed of 'lkjhlk' translated NaturalLanguageTranslator translated: 'lkjhlk' ? > > Maybe we should turn the translation related classes all into stubs that then can be replaced by either the current version (made loadable as a package) or the gettext one. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 2, 2010

Re: [Pharo-project] gettext package

by Michael Rueger

On 5/1/10 2:05 PM, Hilaire Fernandes wrote: > StÃ©phane Ducasse a Ã©crit : > >>> - If we want the gettext package to be loadable, the method >>> String>>translated in core could be changed to return self, then the >>> gettext packaged provided the translated version to effectively >>> handle the translation. >> >> but this would be an override. > > Yes, is it a problem? Yes, overrides in a core class are always a problem. Another way to solve this would be to dispatch translated through NaturalLanguageTranslator which I guess would be completely replaced by the gettext package? Maybe we should turn the translation related classes all into stubs that then can be replaced by either the current version (made loadable as a package) or the gettext one. Michael

May 2, 2010

[Pharo-project] CFP DSLRob'10

by Serge Stinckwich

Smalltalkers are welcome ;-) ====================================================================================== CALL FOR PAPERS 1st International Workshop on Domain-Specific Languages and models for ROBotic systems (DSLRobâ10) October 2010, Tapei, Taiwan Web site : http://www.doesnotunderstand.org/wikka.php?wakka=DSLRob10 ====================================================================================== This workshop will take place in October 2010 in Taipei (å°å) Taiwan, during the 2010 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS'10) : http://www.iros2010.org.tw/ Description A domain-specific language (DSL) is a programming language dedicated to a particular problem domain that offers specific notations and abstractions that increase programmer productivity within that domain. Models offer a high-level way for domain users to specify the functionality of their system at the right level of abstraction. DSLs and models have historically been used for programming complex systems. However recently they have garnered interest as a separate field of study. Robotic systems blend hardware and software in a holistic way that intrinsically raises many crosscutting concerns (concurrency, uncertainty, time constraints, ...), for which reason, traditional general-purpose languages often lead to a poor fit between the language features and the implementation requirements. DSLs and models offer a powerful, systematic way to overcome this problem, enabling the programmer to quickly and precisely implement novel software solutions to complex problems within the robotics domain. The main objective of this workshop is a cross-pollination of ideas between robotics researchers in DSLs and models from different domains. DSLs and models are key elements in many robotic systems presented at leading conferences such as IROS and ICRA, but the domain-centric structure of the typical robotics conference does not offer a natural venue for exchange of ideas regarding DSLs and models. This workshop will bring together robotics researchers from different parts of the robotics community, thus forming a base for future collaboration. This workshop will focus on the use of Domain-Specific Languages and Models for Robotic Systems. Topics that are of special interest include: - domain-specific languages to express reactive behaviors, variability in robotic systems, - domain-specific languages to express uncertainty, modelling of physical system, real-time constraints, - domain-specific languages to describe cooperative robotics and modular robotics systems, - languages to teach robotics, visual languages for robotics, - tools support and frameworks for describing and manipulating DSLs for robotic systems, - model-driven engineering approaches for robotic systems, - code generation and code transformation for robotics systems, - frameworks to combine DSLs in an uniform manner, - benchmarks to compare use of DSL vs general-purpose programming, - programming languages in the context of robotic systems. Type of workshop: half-day The intended audience is those robotics researchers throughout the entire robotics community who use DSLs and models as a key component of their robotics software infrastructure. In addition, robotics researchers with an interest in modern approaches to solving complex software-related issues will find the workshop inspirational. Important dates - Due date for full workshop papers submission: July 1st, 2010 - Final acceptance: July 23rd, 2010 - Camera-ready paper due: August 6th, 2010 - Workshop date: October, 2010 (half day workshop) during IROS'10 Submission guidelines All submitted papers will be reviewed on the basis of technical quality, relevance, significance, and clarity. At least two reviews for each paper will be conducted. All workshop papers should be submitted electronically in PDF format through the Easychair website and should use the IEEE US letter format. We are looking for submission of full research papers and experiences reports (up to 6 pages) and work in progress submissions (up to 4 pages). Please create your account on Easychair website as soon as possible if you intend to submit a paper: http://www.easychair.org/conferences/?conf=dslrob10 Organizers - Ulrik P. Schultz, University of Southern Denmark, Denmark - Serge Stinckwich, UMI UMMISCO IRD/UPMC/MSI-IFI, Vietnam - Mikal Ziane, LIP6, France Program committee - Jean-Christophe Baillie, GOSTAI - Alexandre Bergel, University of Chile, Chile - Mirko Bordignon, University of Southern Denmark, Denmark - SÃ©bastien Gerard, CEA LIST, France - Henrik Nilsson, University of Nottingham, UK - Ulrik P. Schultz, University of Southern Denmark, Denmark - Serge Stinckwich, UMMISCO (IRD/UPMC/MSI), Vietnam - Mikal Ziane, LIP6, France - Tewfik Ziadi, LIP6, France -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 2, 2010

Re: [Pharo-project] Issue 2372: HelpSystem for 1.1

by Michael Roberts

it's much more important to enable documentation to be easily written. Thanks for putting it in mike On Saturday, May 1, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Hi, >> >> The help core package and the according tests package are ready for >> integration in the pharo inbox. After talking today with Stephane I also >> removed the squeak specific stuff, so it is ready for inclusion in >> Pharo 1.1. core image. >> >> The idea is to have the basic help support (help core) in the Pharo >> core image and provide additional docu/help books in the dev-image. > > for now this is more important to add documentation and > since help is easy to unload. I would put helpcore into core + help into dev > > In the future we may move it outside mini. > thanks torsten. > > Let see what the other think. > >> >> But this should depend on a community decision, so any comments >> would be appreciated. >> >> A second option would be to to keep it out of the core image >> and just provide the help support and documentation in the >> Pharo-dev image. >> >> Bye >> T. >> >> >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 2, 2010

Re: [Pharo-project] Fwd: DropPlugin issue?

by StÃ©phane Ducasse

It was a stupid idea of mine. Stef On May 2, 2010, at 12:14 PM, Johannes Rasche wrote: > it didn't, StÃ©phane, > > the result of that method is the same as without: > > MultiByteFileStream: '/private/var/folders/Yg/YgHKWBxBEfilHeP6wELlh++++TI/TemporaryItems/' > > instead of expected ( as from Safari ) : > > MultiByteFileStream: '/private/var/folders/Yg/YgHKWBxBEfilHeP6wELlh++++TI/TemporaryItems/soulkitchen_03.jpg' > > BTW reading the code for the recommended fix, I cannot see how the code should change the instance variable " result". > result is expected to be a ReadStream with an extension, a drophandler is able to handle > > ( > I replaced in method dropFiles in PasteUpMorph > FileStream requestDropStream: i. > by > MultiByteFileStream new requestDropStream: i > ) > > Assume we misunderstood each other some how > > Johannes > > Am 01.05.2010 um 16:29 schrieb StÃ©phane Ducasse: > >> johannes >> >> did the following fix it? >> >> http://code.google.com/p/pharo/issues/detail?id=2301 >> >> Stef >> On May 1, 2010, at 4:04 PM, StÃ©phane Ducasse wrote: >> >>> >>> >>> Begin forwarded message: >>> >>>> From: Johannes Rasche <johannesrasche(a)mac.com> >>>> Date: May 1, 2010 3:54:48 PM GMT+02:00 >>>> To: pharo-project-owner(a)lists.gforge.inria.fr >>>> Subject: DropPlugin issue? >>>> >>>> Hi Folks, >>>> >>>> just had a strange encounter, as I was dragging a picture from Firefox to Pharo ( on Mac OS X) >>>> - up to now I used only Safari - >>>> >>>> ExternalDropHandler is receiving >>>> â¢ not a filestream having an extension expressing to the image format >>>> â¢ but a local temp folder containing that picture >>>> >>>> as a work around I can take the most recent ... :) :( >>>> >>>> other programs than Squeak are receiving that image properly >>>> >>>> is it a DropPlugin deficiency ? or what ? >>>> >>>> any advice is welcome >>>> >>>> Johannes >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

May 2, 2010

Re: [Pharo-project] Fwd: DropPlugin issue?

by Johannes Rasche

it didn't, StÃ©phane, the result of that method is the same as without: MultiByteFileStream: '/private/var/folders/Yg/YgHKWBxBEfilHeP6wELlh++++TI/TemporaryItems/' instead of expected ( as from Safari ) : MultiByteFileStream: '/private/var/folders/Yg/YgHKWBxBEfilHeP6wELlh++++TI/TemporaryItems/soulkitchen_03.jpg' BTW reading the code for the recommended fix, I cannot see how the code should change the instance variable " result". result is expected to be a ReadStream with an extension, a drophandler is able to handle ( I replaced in method dropFiles in PasteUpMorph FileStream requestDropStream: i. by MultiByteFileStream new requestDropStream: i ) Assume we misunderstood each other some how Johannes Am 01.05.2010 um 16:29 schrieb StÃ©phane Ducasse: > johannes > > did the following fix it? > > http://code.google.com/p/pharo/issues/detail?id=2301 > > Stef > On May 1, 2010, at 4:04 PM, StÃ©phane Ducasse wrote: > >> >> >> Begin forwarded message: >> >>> From: Johannes Rasche <johannesrasche(a)mac.com> >>> Date: May 1, 2010 3:54:48 PM GMT+02:00 >>> To: pharo-project-owner(a)lists.gforge.inria.fr >>> Subject: DropPlugin issue? >>> >>> Hi Folks, >>> >>> just had a strange encounter, as I was dragging a picture from Firefox to Pharo ( on Mac OS X) >>> - up to now I used only Safari - >>> >>> ExternalDropHandler is receiving >>> â¢ not a filestream having an extension expressing to the image format >>> â¢ but a local temp folder containing that picture >>> >>> as a work around I can take the most recent ... :) :( >>> >>> other programs than Squeak are receiving that image properly >>> >>> is it a DropPlugin deficiency ? or what ? >>> >>> any advice is welcome >>> >>> Johannes >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 2, 2010

Re: [Pharo-project] removing some dust in Morph

by StÃ©phane Ducasse

On May 1, 2010, at 10:33 PM, Igor Stasenko wrote: > On 1 May 2010 22:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Morph removeSelector: #affiliatedSelector! >> Morph removeSelector: #completeModificationHash! >> Morph removeSelector: #constructorString! >> Morph removeSelector: #duplicateMorphImage:! >> Morph removeSelector: #haloDelayTime! >> Morph removeSelector: #modificationHash! >> Morph removeSelector: #preserveTrash! > > so, no more trash preservation? > i am really disappointed! ;) Ok we can provide a cs just for you with a pink animation http://s.myniceprofile.com/myspacepic/461/46143.gif :) > >> Morph removeSelector: #readoutForField:! >> Morph removeSelector: #rememberedColor! >> Morph removeSelector: #rememberedColor:! >> Morph removeSelector: #showHiders! >> Morph removeSelector: #shuffleSubmorphs! >> Morph removeSelector: #subclassMorph! >> Morph removeSelector: #uncollapseSketch! >> Morph removeSelector: #wantsSimpleSketchMorphHandles! >> >> ? >> > > >> the cs will the full changes is available at: >> http://code.google.com/p/pharo/issues/detail?id=2382 >> >> Stef >> >> But probably rewriting everything would be better >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 1, 2010