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

[update 3.0] #30140

by Marcus Denker

May 17, 2013

Re: [Pharo-dev] TxTextLayout

by stephane ducasse

> But, what is the impediment of adding Athens now to the image? We are just waiting that igor is here and we were focusing on the new compiler. Stef > Cheers, > Doru > > > On Fri, May 17, 2013 at 8:47 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Denis > > I think that alain will start to look at TextModel too because we do not want to have rubric competing with it and > WE WANT ATHENS IN PHARO BEFORE the end of June. > Igor when you are back from holidays we will push athens into Pharo and start hakcing like mad :) > > Stef > > > On May 16, 2013, at 10:32 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> >> On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hello. >> > >> > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> > >> >> I have a question concerning the new TxText layout. >> >> How hard is it support inline non-text nodes (aka inline morphs) in a text >> >> layout? >> >> >> > >> > Do you mean supporting "TxMorphSpan" objects from text model at text layout >> > level? >> > I think it is is not hard. Main issue here is supporting such kind of spans >> > at text model level. But I think it is not difficult too, >> > I should look at code to answer in detail (can't do it now). >> > >> > >> >> >> >> My dream is still to be able to drag and drop an "instance" from an >> >> inspector to a workspace and do some operations on it using standard >> >> smalltalk. >> > >> > >> > +1 >> > And I want drag and drop objects between inspectors and between workspaces. >> > >> > >> >> The only difference here would be instead of using a variable or >> >> expression to get an instance of something I would have a textual/visual >> >> node directly representing an instance! >> >> >> > >> > I'm not understand it. >> > By dropping some object to workspace It can create named variable and then >> > you can use it for scripting inside workspace. >> > But what you suggest here? Can you explan deeply? >> >> >> Indeed I am not very clear (as usual :). >> a) I want to have a morph representing an object >> b) I want to embed these morphs into text >> c) I want to interact with these morphs and the text >> >> Let's say [Set] is the morph representing a set and I have the following >> source code with this morph inside: >> >> [Set] includes: #a >> >> Then this would be equivalent to the following: >> >> Smalltalk at: #MySetInstance put Set new. >> >> MySetInstance includes: #a >> >> However [Set] is not just text but a real morph I can drag around, right click >> and get a decent, instance specific menu on... and so forth :) >> >> is that more clear? >> >> Ok. Now I understand what you want. >> >> I look at code. >> As I sad before. TxMorphSpan requires some changes in text model code and layout code. >> Now TxLayout is collection of TxLayoutLine's where TxLayoutLine is collection of TxLayoutSpan's. And now TxLayoutSpan is interval of TxCharacterSpan. So TxLayoutSpan know that it is layout of characters. It has font. >> One of the options to support TxMorphSpan layout is to introduce TxLayoutMorphSpan and implement all required protocol. To hook up this object during layout building you should implement something like: >> >> TxMorphSpan>>layoutContentsBy: aLayoutBuilder >> aLayoutBuilder currentSpan: (TxLayoutMorphSpan on: self) >> aLayoutBuilder completeSpan >> >> You see it is quite simple. >> >> Now I almost finich edit decorators stuff. (I have TxNoneEditDecorator, TxMaskEditDecorator, TxInsertModeEditDecorator, TxSmartCharsEditDecorator). And next my task will validation/filtering of input. I think it will require text model changes, so I will think about morph span too. >> And of couse if you again join to TxText development it will be perfect! You and Igor started this project. >> >> Best regards, >> Denis >> . >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

May 17, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by stephane ducasse

I agree with you. Methods should be commented!!!! On May 17, 2013, at 1:27 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I really enjoy smalltalk, every small thing that I discover every day. > > But there is one thing that really annoys me. The bold claim that small functions do not need comments. > There is of course a level of truth that when a function/methods is well formated and follows the common logic > rules of readable code a comment should not be needed for what it takes 10 lines or less of code to explain. > > But then that is also an illusion. > > The problem is that the code never explains the why. And why can be very important in understanding the code. > Also a big issue I have with smalltalk in general. All this spaggeti mess I see unfold before my eyes in every library I see. > One method calling another method which calls (excuse me, I should have said "sends a message") another and before > you know you forget where you started and where is the end. Its the definition of Code Labyrinth. All this hectic browsing > around could have been avoided so easily with a single comment. > > Its those moments you beg for a comment or some documentation. > > So my message to this list is to express my discomfort on this and ask > > Is it me or is this a really bad code practice afterall ? > > I am new to smalltalk so maybe I miss something or maybe things get easier in the future with more experience. > But something it tells me inside that I will never get used to this , maybe I will learn to tolerate it , but its so far away from > my way of thinking I dont think it has much chance into integrating in my brain. > > The thing is that I am quite the opposite , I am a comment and documentation freak. You may think I do it just to be > awared the oscar of amazing readable coding but nothing can be further from the truth. I may be coding for 25 years now > but it was never something serious , I am no pro and certainly not a serious coder. I just like to mess around with code, thats all. > > For me its a matter of survivability , if I dont comment or document I will quickly forget why I code these things anyway. > Its so easy for me to forget and be confused and I find in this case smalltalk code is not as forging to coders like me. > > So I would like to hear you thoughts on this as much more experience smalltalk coders than me. > > I would like to note here that I am also a big fan of small methods and that my question is not related to whether methods > should be kept small and readable but whether comments are really needed for those methods.

May 17, 2013

Small Methods dont need comments , true or myth ?

by dimitris chloupis

I really enjoy smalltalk, every small thing that I discover every day. But there is one thing that really annoys me. The bold claim that small functions do not need comments. There is of course a level of truth that when a function/methods is well formated and follows the common logic rules of readable code a comment should not be needed for what it takes 10 lines or less of code to explain. But then that is also an illusion. The problem is that the code never explains the why. And why can be very important in understanding the code. Also a big issue I have with smalltalk in general. All this spaggeti mess I see unfold before my eyes in every library I see. One method calling another method which calls (excuse me, I should have said "sends a message") another and before you know you forget where you started and where is the end. Its the definition of Code Labyrinth. All this hectic browsing around could have been avoided so easily with a single comment. Its those moments you beg for a comment or some documentation. So my message to this list is to express my discomfort on this and ask Is it me or is this a really bad code practice afterall ? I am new to smalltalk so maybe I miss something or maybe things get easier in the future with more experience. But something it tells me inside that I will never get used to this , maybe I will learn to tolerate it , but its so far away from my way of thinking I dont think it has much chance into integrating in my brain. The thing is that I am quite the opposite , I am a comment and documentation freak. You may think I do it just to be awared the oscar of amazing readable coding but nothing can be further from the truth. I may be coding for 25 years now but it was never something serious , I am no pro and certainly not a serious coder. I just like to mess around with code, thats all. For me its a matter of survivability , if I dont comment or document I will quickly forget why I code these things anyway. Its so easy for me to forget and be confused and I find in this case smalltalk code is not as forging to coders like me. So I would like to hear you thoughts on this as much more experience smalltalk coders than me.Â I would like to note here that I am also a big fan of small methods and that my questionis not related to whether methods should be kept small and readable but whether comments are really needed for those methods.

May 17, 2013

[update 3.0] #30139

by Marcus Denker

30139 ----- 10656 add Compiler>>#parseLiterals: https://pharo.fogbugz.com/f/cases/10656 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.462.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDen…

May 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=mac… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=win… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 17, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Camillo Bruni

Update the jenkins job to be multi-platform (though only loading #last): https://ci.inria.fr/pharo-contribution/job/NBOpenGL On 2013-05-17, at 09:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 15 May 2013 09:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> How did you loaded NBOpenGL? >>>> For 2.0/3.0 pharo image use >>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>> It would be a lot better to make >>> >>> ConfigurationOfNBOpenGL load. >>> >> >> unless you put a lot of complex logic behind that "load", >> it will never work. > > Why? > load should be > > ConfigurationOfNBOpenGL class>>#load > ^ self project stableVersion load. > > and nothing else > >> That's why i prefer to giving a version numbers. This version of >> config works with 2.0 image, >> and no pain, no surprises. >> Now, when people get used to do "ConfigurationOfNBOpenGL load" >> it is less pain, but just for the next major update of whatever >> infrastructural parts in Pharo. > > again... why? > Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :( > >> >> And second, for me, as developer , it is much more helpful to deal >> with problem reports like: >> "this version doesn't loads/works with this version of image" >> instead of "i tried and it doesn't works" :) > > he, I'm sorry, I disagree... > If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. > And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) > As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... > > cheers, > Esteban > >> >>> work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. >>> >>> Esteban >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

May 17, 2013

Re: [Pharo-dev] TxTextLayout

by Tudor Girba

But, what is the impediment of adding Athens now to the image? Cheers, Doru On Fri, May 17, 2013 at 8:47 AM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Denis > > I think that alain will start to look at TextModel too because we do not > want to have rubric competing with it and > WE WANT ATHENS IN PHARO BEFORE the end of June. > Igor when you are back from holidays we will push athens into Pharo and > start hakcing like mad :) > > Stef > > > On May 16, 2013, at 10:32 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> > >> >> On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hello. >> > >> > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> > >> >> I have a question concerning the new TxText layout. >> >> How hard is it support inline non-text nodes (aka inline morphs) in a >> text >> >> layout? >> >> >> > >> > Do you mean supporting "TxMorphSpan" objects from text model at text >> layout >> > level? >> > I think it is is not hard. Main issue here is supporting such kind of >> spans >> > at text model level. But I think it is not difficult too, >> > I should look at code to answer in detail (can't do it now). >> > >> > >> >> >> >> My dream is still to be able to drag and drop an "instance" from an >> >> inspector to a workspace and do some operations on it using standard >> >> smalltalk. >> > >> > >> > +1 >> > And I want drag and drop objects between inspectors and between >> workspaces. >> > >> > >> >> The only difference here would be instead of using a variable or >> >> expression to get an instance of something I would have a >> textual/visual >> >> node directly representing an instance! >> >> >> > >> > I'm not understand it. >> > By dropping some object to workspace It can create named variable and >> then >> > you can use it for scripting inside workspace. >> > But what you suggest here? Can you explan deeply? >> >> >> Indeed I am not very clear (as usual :). >> a) I want to have a morph representing an object >> b) I want to embed these morphs into text >> c) I want to interact with these morphs and the text >> >> Let's say [Set] is the morph representing a set and I have the following >> source code with this morph inside: >> >> [Set] includes: #a >> >> Then this would be equivalent to the following: >> >> Smalltalk at: #MySetInstance put Set new. >> >> MySetInstance includes: #a >> >> However [Set] is not just text but a real morph I can drag around, right >> click >> and get a decent, instance specific menu on... and so forth :) >> >> is that more clear? >> > > Ok. Now I understand what you want. > > I look at code. > As I sad before. TxMorphSpan requires some changes in text model code and > layout code. > Now TxLayout is collection of TxLayoutLine's where TxLayoutLine is > collection of TxLayoutSpan's. And now TxLayoutSpan is interval of > TxCharacterSpan. So TxLayoutSpan know that it is layout of characters. It > has font. > One of the options to support TxMorphSpan layout is to introduce > TxLayoutMorphSpan and implement all required protocol. To hook up this > object during layout building you should implement something like: > > TxMorphSpan>>layoutContentsBy: aLayoutBuilder > aLayoutBuilder currentSpan: (TxLayoutMorphSpan on: self) > aLayoutBuilder completeSpan > > You see it is quite simple. > > Now I almost finich edit decorators stuff. (I have TxNoneEditDecorator, > TxMaskEditDecorator, TxInsertModeEditDecorator, TxSmartCharsEditDecorator). > And next my task will validation/filtering of input. I think it will > require text model changes, so I will think about morph span too. > And of couse if you again join to TxText development it will be perfect! > You and Igor started this project. > > Best regards, > Denis > . > > > -- www.tudorgirba.com "Every thing has its own flow"

May 17, 2013