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

[Pharo-project] MNU spec

by phil＠highoctane.be

It was Pharo #20567

Feb. 24, 2013

[Pharo-project] Refactor: rename class give Spec bug.

by phil＠highoctane.be

I was trying to get the Manuia Memory Monitor to work in Pharo 2.0 Got it working, nothing special: just say Smalltalk vm parameterAt: xxx instead of the SmalltalkImage current vmParameterAt: xxx Some Cmd-. needed but worked. Then, I wanted to have a look at how it worked. I noticed a class named: MMMemoryUsageIndicadorMorph and wanted to rename it to MMMemoryUsageIndicatorMorph. But I got a MNU: receiver of "model:widget:" is nil. Quite annoying. Screenshot in attach. Phil

Feb. 24, 2013

[Pharo-project] [JOB][Research] Postdoc position: IDEs

by Marcus Denker

Infrastructure for new generation IDEs ===================================== About Inria and the job ----------------------- Inria, with its academic, institutional and industrial partners, is commited to major research and innovation projects in the field of computational sciences. The institute disseminates across France thanks to its eight research centres. The Inria Lille - Nord Europe research centre, inaugurated in 2008, employs 357 people, including 250 scientists, in its seventeen research teams. Recognised for its significant contribution to the social and economic development of the Nord - Pas-de-Calais region, the Inria Lille - Nord Europe research centre promotes a policy of close cooperation with major businesses and small enterprises. By encouraging synergies between researchers and industrial partners, Inria contributes to the transfer of skills and expertise in computational technologies and provides access to top-level European and international research in order to support innovation and businesses, particularly in the region of Lille. Whether designing innovative software for business or logistics, modelling living cells or fusion plasma, or developing medical simulators or interfaces to facilitate human-computer interaction, our research opens up new possibilities that can revolutionise common practice and contribute to a better understanding of the natural phenomena which surround us. The goal of the RMoD research team at Inria Lille is to support re-modularization of object-oriented applications. This objective is tackled from two complementary perspectives: reengineering and modularity constructs for programming languages. For more information on RMOD, see http://rmod.lille.inria.fr Mission ------- The objectives will be to reconsider and develop a new infrastructure to build new and modern IDEs. The goal of this postdoc is to help the RMOD team rethinking the infrastructure of Pharo from the point of view of its user interface and interaction foundation as well as code navigation. The following topics will be analysed and rethought : - Alternate models of event handling - Decomposing responsibilities of event handler and dispatchers. - Alternative ways to navigate code - Queries to access code elements - Smart handling of coding contexts - Management of window plague - Support for contextual refactorings and automated code transformation. Skills and profile ------------------ - English - Pharo: http://www.pharo.org - User interface design, Vector graphics - IDE design and user interactions Benefits --------- - Possibility of French courses - Help for housing - Participation for transportation - Scientific Resident card and help for husband/wife visa Additional information ----------------------- - Duration : 16 months - Salary: 2 620,84 â¬ gross/month - Monthly salary after taxes : around 2 138 â¬ (medical insurance included) - For the first selections, please apply before March 2013, 22nd. - Before applying, please contact the scientist advisor: stephane.ducasse(a)inria.fr - More information: http://rmod.lille.inria.fr/web/pier/blog/2013-02-22 Security and defense procedure ------------------------------ In the interests of protecting its scientific and technological assets, Inria is a restricted-access establishment. Consequently, it follows special regulations for welcoming any person who wishes to work with the institute. The final acceptance of each candidate thus depends on applying this security and defense procedure.

Feb. 24, 2013

Re: [Pharo-project] TextModel review and discussion

by Denis Kudriashov

Hello. Sorry for long silence. I was at vacation without internet. So I found this mail only now. 2013/2/6 Igor Stasenko <siguctua(a)gmail.com> > Hi, today, me, Tristan and Camillo took some overview on existing > code and discussed further steps. > > TxAttributes > 'contents' should be private (no getter/setter) > > because if you can directly manipulate the underlying collection, then > what is the point of having separate class? > I need accessors for tests and "manual debugging". You can look at TxAttributesTests to see my point. It includes separate tests for adding new attributes and for getting it by concrete attribute class. Without #contents method I can't write such tests. Adding and getting attributes are different behaviour. If you want independant unit tests for your objects you need accessors for all instance variables. By "manual debugging" I mean ability to script object state in inspectors and workspaces. I really hate situations when I can't see state of object in debugger by simple "printIt" operation on "object someState". It always force me to open another tool like inspector or browser which slow down my workflow of exploring some system behaviour. That's why I really like idea about auto accessors for any instance variables: you add new instance variable and system automatically add accessors. You know Self, Newspeak and javascript has this by language design (not sure about newspeak). If you talk about incapsulation as system design property It has no relation to accessors existence. It has relation to accessors usage. And I'm sure we all agree that code inside span class like "attributes contents at: TxFontAttribute" is very bad idea. But unit tests need this. > > Text Attributes in general: > > - we discussed and decided that it would be better that model will > keep abstract attributes for text , like > - bold > - italic > - font family name > > the view then can compute the real font to use, but model don't have > to deal with real font(s). > > This will imply having more complex attribute(s): you will be forced > to visit them all to determine all of the font properties > of a final font to use. > I have no idea why this is better than real font. Can you explain? Because you said "This will imply having more complex attribute(s)". So why more complex attributes is better? What give us separation font to primitive properties? In any case I'm not fimiliar with font system. So I'm not know what bold, italic properties mean inside font instance. Can this properties be extracted from font instance? > The attributes in span should behave like a set (you cannot apply same > attribute once), > and hence implement #= and #hash properly. > Attributes accessing api guarantee it. If you add different font attributes twice only last font stay. Contents of TxAttributes is dictionary with "Attribute class->attribute" structure. > > Also, i think, since neither bold, nor italic attributes don't need to > be represented by multiple instances of same class, > we could use convenience methods (by introducing them) in TxAttribute > class to get a singletons for those ones, e.g.: > > selection applyAttribute: TxAttribute bold > Interesting thing about first class attributes is how they can be used for text drawing. Current morphic implementation: TxCharactersSpan>>drawOn: aCanvas at: aPoint aCanvas drawString: characters at: aPoint font: (self getAttribute: TxFontAttribute) color: (self getAttribute: TxForeColorAttribute) But with athens it can be: TxCharactersSpan>>drawOnAthens: aCanvas attributes applyOn: aCanvas. aCanvas drawString: characters. And each attribute can change athens canvas state for drawing like: TxFontAttribute>>applyOn: aCanvas aCanvas font: value Is it possible with separated primitive font properties? Layout: > - right now, when you do layout it will split spans of txmodel. Which > should not happen. It is not happen. > > We discussed about it and agreed that layouts(views) should not modify > anything in text model. > Layout just creates new splitted spans without source span modification. Text model not changed. > Instead the information about where line has to be split (like when > you need to wrap a text) should be kept > separately by a view. > > We thought that it would be nicer to implement a new span type > (layoutspan), which will hold > an text-interval (pos1, pos2) and probably any additional information > (like caching the width/height) > to not recalculate this stuff if nothing changed in model. > I think about it too. But first I want readonly text morph which works with different layout strategies. So I just reuse existed spans. I gather introduce special object (layoutspan) to implement editing stuff. And I think this layoutspan can make very simple implementation of text selection drawing. LayoutSpan can have own attributes which will override underlyng span attributes during drawing. And visual text selection will apply special font/color attributes to selected layout spans. What you think about it? Best regards, Denis > > > We did some cosmetic changes to configuration.. to merge Tristan's > code into it and load most recent packages: > > Gofer it > smalltalkhubUser: 'sig' project: 'TxText'; > package: 'ConfigurationOfTxText'; > load. > > (ConfigurationOfTxText project version: '0.3') load: 'Tests' > > -- > Best regards, > Igor Stasenko. > >

Feb. 24, 2013

Re: [Pharo-project] webdoc is back online

by Camillo Bruni

On 2013-02-24, at 12:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 Feb 2013, at 23:35, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I just figured out that it runs on a 1.2 image :D >> time to upgrade ;) > > Yes, great, but *very* old ;-) > > You should see how you can work together with Torsten. Yeah definitely, since I don't need any seaside specific features (except for the html generator) I could easily write it the way Torsten did it. I make it work first under 1.4 and then see how far I get this weekend ;)

Feb. 24, 2013

Re: [Pharo-project] [ANN] Pharo Online Help 1.1. for Pharo 2.0 (now with Markdown support and tutorials)

by Sean P. DeNigris

EstebanLM wrote > yep... system call is complicated because it uses some weird jumps inside > (at least, that's what Igor says... that's way over my understanding :) Ha ha, over mine too. Issue 7583: [ENH]: NB system example https://code.google.com/p/pharo/issues/detail?id=7583 -- View this message in context: http://forum.world.st/ANN-Pharo-Online-Help-1-1-for-Pharo-2-0-now-with-Mark… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2013

Re: [Pharo-project] webdoc is back online

by Camillo Bruni

I'm preparing it for multiple pharo versions: http://pharo.gforge.inria.fr/doc On 2013-02-24, at 12:37, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I've got a 404 page not found error. > > Noury > On 24 fÃ©vr. 2013, at 11:52, stephane ducasse wrote: > >> sweet! >> >> Thanks a lot. >> >> >> On Feb 23, 2013, at 10:22 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I made a little effort to get webdoc up and running again. I think with the forthcoming >>> stable release of pharo it makes sense to put an documentation of the whole system online. >>> >>> I took the seaside image and statically exported (almost) all content and uploaded it to >>> the gforge: >>> >>> http://pharo.gforge.inria.fr/doc/webdoc.html >>> >>> I will spend some more time this weekend to fix the missing contents (mostly the popups) >> >> > > Noury Bouraqadi > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > >

Feb. 24, 2013

Re: [Pharo-project] [ANN] Pharo Online Help 1.1. for Pharo 2.0 (now with Markdown support and tutorials)

by Esteban Lorenzano

yep... system call is complicated because it uses some weird jumps inside (at least, that's what Igor says... that's way over my understanding :) On Feb 24, 2013, at 12:38 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > EstebanLM wrote >> in mac, you need to do it in cocoa. > > In NB for Mac OS X, we could do 'system("open http://whatever")', but I > couldn't get simple system calls to work in > http://forum.world.st/NB-crash-boom-td4669980.html > > > > -- > View this message in context: http://forum.world.st/ANN-Pharo-Online-Help-1-1-for-Pharo-2-0-now-with-Mark… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 24, 2013

Re: [Pharo-project] [ANN] Pharo Online Help 1.1. for Pharo 2.0 (now with Markdown support and tutorials)

by Sean P. DeNigris

EstebanLM wrote > in mac, you need to do it in cocoa. In NB for Mac OS X, we could do 'system("open http://whatever")', but I couldn't get simple system calls to work in http://forum.world.st/NB-crash-boom-td4669980.html -- View this message in context: http://forum.world.st/ANN-Pharo-Online-Help-1-1-for-Pharo-2-0-now-with-Mark… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2013

Re: [Pharo-project] webdoc is back online

by Noury Bouraqadi

I've got a 404 page not found error. Noury On 24 fÃ©vr. 2013, at 11:52, stephane ducasse wrote: > sweet! > > Thanks a lot. > > > On Feb 23, 2013, at 10:22 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I made a little effort to get webdoc up and running again. I think with the forthcoming >> stable release of pharo it makes sense to put an documentation of the whole system online. >> >> I took the seaside image and statically exported (almost) all content and uploaded it to >> the gforge: >> >> http://pharo.gforge.inria.fr/doc/webdoc.html >> >> I will spend some more time this weekend to fix the missing contents (mostly the popups) > > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

Feb. 24, 2013