January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Compiling chapter of "Pharo for the Enterprise"

by Damien Cassou

Hi Natalia, On Fri, Dec 27, 2013 at 11:20 PM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: > I write a chapter to "Pharo for the Enterprise". And I want to compile it, > but when I executing ./compile.sh DSL/DSL.pier, like it is writen here: > https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english/bl… > , I get No yet implemented. > I just start this chapter and it isn't ready to be added to the PFTE.tex. > Should I add it to PFTE.tex or there are another way? What can you recomend > me? Yes, I need to re-implement this feature. For now, please just include a reference to your file in pillar-conf.ston and commit it. If you want to compile fast, you can remove the other input files in the same file (but don't commit). And don't worry if your chapter "isn't ready to be added to the PFTE.tex". No chapter is ready, the whole book is a work in progress. So don't be shy :-). Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by StÃ©phane Ducasse

I liked this distinction between printString and displayString. It was removed probably because it was a mess :) Stef > In my experience with Pharo and other Smalltalks as well: > > #printString is used for debugging, that's why the default > implementation shows the class name. It's implemented using #printOn: > > #displayString (deprecated in Pharo*) is used to display the object in > the UI. It is implemented by means of #displayOn: (Dolphin used this > pattern) > > #asString is the toString() equivalent of other languages. In some > cases `anObject asString asObject` should give the same object back > (e.g. in Date, Numbers, etc.). Most of the times it is the same string > as #printString, but it is not consistent. > > > Ej: > If you have aPerson: > aPerson printString -> "aPerson ('John Doe')" > aPerson displayString -> 'John Doe' > > Regards, > > > (*) Why #displayString was deprecated? > Esteban A. Maringolo > > > 2014/1/3 Frank Shearar <frank.shearar(a)gmail.com>: >> On 3 January 2014 11:44, Otto Behrens <otto(a)finworks.biz> wrote: >>>> 'Conversion' implies using the resulting String in some further >>>> computation. 'Printing' usually implies displaying something to the >>>> user (and nothing more), or serialising to a file/network. >>> >>> What kinds of computation are you thinking of regarding a string? I >>> think I understand what you're saying, I'm just trying to make it a >>> bit more concrete in my mind. >> >> I just mean that sometimes you want to work with a string >> representation of a thing, and #asString is how you get it. For >> instance, a Symbol might printString as '#foo' while in its converted >> form it returns 'foo'. >> >>> The requirements of displaying something to the user and serialising >>> to a file/network are quite different, or not? >> >> You're right. I'm wrong in saying that #printString should be used to >> serialise anything. Actually, you'd probably use #storeString for >> serialising, if you weren't using Fuel. >> >> frank >> >

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Tudor Girba

Hmm, strange. It was available in 30666, but it is not available anymore in 30669. Was it reverted because it was not good, or was it because of another issue? Doru On Fri, Jan 3, 2014 at 2:14 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Doru wrote: > >I do not get that. As far as I can tell, the fix is already integrated :). > > No, it needs to be resolved to Fix to be included. > > Stephan > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Stephan Eggermont

Doru wrote: >I do not get that. As far as I can tell, the fix is already integrated :). No, it needs to be resolved to Fix to be included. Stephan

Jan. 3, 2014

stroke width in Athens

by Alexandre Bergel

Hi! Apparently, the width (in pixels) of a stroke in athens seems to vary with the size of the path. Am I right? For example, I have the following rendering: There is just one code to draw a box, which is: athensCanvas pathTransform restoreAfter: [ athensCanvas pathTransform translateBy: rectangle center; scaleBy: rectangle extent / 2. athensCanvas setPaint: color; drawShape: self path. strokePaint ifNotNil: [ (athensCanvas setStrokePaint: strokePaint) width: 0.1. athensCanvas drawShape: path ] ] Having a width of 1 makes a very large border. Do I miss something? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2014

Re: [Pharo-dev] Thank you for Pharo

by Volkert Barr

On 02.01.2014, at 14:07, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 02 Jan 2014, at 11:49, Volkert Barr <volkert(a)nivoba.de> wrote: > >> >> On 01.01.2014, at 19:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>>> I understand that community support is needed, and yes i am willing to help. As a first step i can offer my help to test pharo features, help to write test cases, write some example code snippets, open bug reports. But i am not sure what Pharo features or libraries i should put my focus on. Any suggestions where to dig in? >>> >>> Excellent! >>> Thanks. I suggest that you focus on what you like or what you want to learn and do it step by step. >>> Stef >>> >> I would like to understand ui and graphics programming in Pharo. I have found different ui related libraries, but not really understand how >> they all relate to each other, what their purposes and what will be "part of" future Pharo Versions and what not. >> > This is not that easy. For example, some of these things are not libraries but just âSystemCategories full of random stuffâ. > >> Spec > > Specifying UIs, layer on top of Morphic (but the goal is to be in depended) > >> Glamour > > From Moose > >> UIManager > Random package, not nice. Needs love. > >> Polymorph > Partly new widgets, partly a builder (programmatically) for UIs, partly lots of overrides for morhic > > â> needs to be moved to Morphic base, Morphic Widgets, overrides need to be move to the other packages > We need to see if the builder parts are needed considering Spec. > >> FreeType > Fonts > >> Keymapping > Keyboard shorcut support > >> Multilingual > > Lots of random stuff for I18N support. > >> Morphic > > a big mess... > >> Graphics > > Random classes related to Graphics. The Canvas is strangely in Morphic, though. > needs cleanup and thought. What is basic Graphics? What is Morhic? What is backward > compatibility? What can be removed? > >> Balloon > Old 2D stuff, incomplete. There is a backend for Athens that uses it, which is handy for > debugging. In the long run â> remove > >> Athens > New 2D Vector API, with backend for Cairo (and Ballon for debugging) right now. > This is the future. > >> NBOpenGL > > OpenGL bindings. We want in the long run to render Athens directly with thisâ¦ (very long run). :-) Thank you Marcus for your clarification. I first try to dig into Spec, Polymorph and Morphic. BW, Volkert

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Tudor Girba

I do not get that. As far as I can tell, the fix is already integrated :). Doru On Fri, Jan 3, 2014 at 1:29 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > If anyone wants the solution for > > https://pharo.fogbugz.com/f/cases/10551/All-Monticello-Repositories-are-add… > before Jan 26, please remember Camillo is working on his PhD till then. > (needs reviewing) > > Stephan > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Carlo

To me #asString is meant to be used when you need an object with the String protocol. As mentioned it looks like the seaside #asString and #greaseString are meant for displaying which causes the confusion but Iâm not sure why #displayString was removed apart from the obvious reasons of trying to cater for common denominator across Smalltalk dialects. In my codebases I also tend to use #asString for displaying but have tried to move to a #displayString and #displayOn: protocol for these purposes. Regards Carlo On 03 Jan 2014, at 1:24 PM, Otto Behrens <otto(a)finworks.biz> wrote: > #printString and #printOn: protocol should be used for printing and #asString for conversion. This implies that #asString should not depend on #print protocol. Ah, I used it the other way around: printOn depends on asString. I saw 'conversion' as the lower level. Why do you distinguish here between conversion and 'printing'? Especially if displayString is being replaced with asString - to me that sounds against your thinking in principle. > If we are going to use #asString to mimic #displayString (instead of as a conversion method) then to me #asString should be viewed at a higher level abstraction than #printOn:. If not then we can run into these issues when calling the higher-level abstraction from a lower level in the same objectt, as you mentioned. Calling #printString from #asString from an API perspective should not cause issues (as displaying something is very different from converting something) so Iâd say this is an API design problem. Yes, I think the API could be clearer. So this becomes the essence of the question here: What is the meaning of these methods from an API perspective? Thanks for the response

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Sebastian Sastre

If that's the case the UI curators should decide what are those 3 priority issues We can "jump" to these: 7. Don't panic by overwhelming issues. Discuss with colleagues or publish in a private wiki for the team or something 8. Decide what are the 3 most blocking entry barriers and show that to the team. We need to discuss the discovered issues so, together, we do something about them If is not, then experiments is what we needed On Jan 3, 2014, at 10:21 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Sebastian wrote >> Cheap idea for us: > > Good idea for a bit later, and for the new parts. > > We already have a number of well-known problems for new users. > If we donât eliminate them first, weâre not going to find much new > issues. They will be hidden behind: > - no discoverable way of creating classes & methods; > - buttons in the system browser without a visible relationship > to the pane they operate on; > - context menus that donât operate on the selected item but > on a whole group; > - menu size > - modal editing > - keyboard navigation of the ui > There are quite some Pharoâers teaching introductions to smalltalk. > I think they are aware of these issues. A few of them are on my slides, > at least. And a few I always have to explain. > > Stephan

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Stephan Eggermont

If anyone wants the solution for https://pharo.fogbugz.com/f/cases/10551/All-Monticello-Repositories-are-add… before Jan 26, please remember Camillo is working on his PhD till then. (needs reviewing) Stephan

Jan. 3, 2014