- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Alexandre Bergel

I see the motivation, but things should go incrementally. If code should be highly documented, with a high test coverage, friendly to API migration then well.. not much happensâ¦ Cheers, Alexandre > On Jan 10, 2016, at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I think that we should not integrate new classes if they don't have a >> class comment that follow the template. > > +100 > > I can understand that when prototype, hacking, being generally productive inside Pharo, you don't write comments at first. But once you go public, after some iterations, and especially if you want to be integrated into Pharo itself, there is no excuse. We need proper class comments, and comments for the main non-trivial public methods. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 10, 2016

Re: [Pharo-dev] Better class comment version2

by Thierry Goubier

Hi David, this is the bug with LayoutFrame>>#fractions:offsets: we were talking about relative to that class comment. In Pharo, Rectangles are constrained to have the smallest vertical value as the top, smallest horizontal value as the left, largest vertical value as bottom and largest horizontal value as right. So, your rectangle 'offsets' was in fact: -3 @ -3 corner: 3 @ 3 which is exactly the reverse of what you intended ;) Using the elementary distance accessors is the correct approach. Regards, Thierry Le 10/01/2016 23:05, David Allouche a Ã©crit : > I guess that is a class comment for LayoutFrame. I think this is > great improvement. > > By I the way, I noticed something really strange when I was using it > in my learning project of a TicTacToe game. I started initializing a > LayoutFrame using #fractions:offsets:, but I had strange incorrect > results. I have fixed them by using the elementary distance > accessors. > > Here is the relevant method in my code. > > drawCircleOn: aCanvas "Draw a circle cell" | layout oval | "That > should worlk, but does not!" "offsets := (1@1 corner: (-1)@(-1)) > scaleBy: lineWidth*3." "layout := LayoutFrame fractions: (0@0 corner: > 1@1) offsets: offsets." layout := (0@0 corner: 1@1) asLayoutFrame. > layout topOffset: lineWidth*3; leftOffset: lineWidth*3; bottomOffset: > lineWidth*(-3); rightOffset: lineWidth*(-3). oval := layout > transform: self bounds. aCanvas frameOval: oval width: lineWidth > color: color. > > I could not find an online syntax highlighter that supports > Smalltalk, so here it comes unstyled. > > Should I write a test case for that, or did I try to do something > obviously incorrect? > >> On 9 Jan 2016, at 10:22, stepharo <stepharo(a)free.fr> wrote: >> >> I define a transformation frame relative to some rectangle. I'm >> basic data structure used for graphics. I represent two groups of >> distances: - The fractional distance (between 0 and 1) to place the >> morph in its owner's bounds - Fixed pixel offset to apply after >> fractional positioning (e.g., "10 pixel right of the center of the >> owner") >> >> !! API usage It is important to understand that it is better to use >> the fine grained API using elementary distances (bottomFraction:, >> bottomOffset:, leftFraction: ....) than the ones (historical) using >> points and rectangles (fractions:offsets:) >> >> The reason is that the old API (fractions:offsets:) is only >> interesting if you already have a rectangle and point at hand. If >> you need to create new ones, then they are created for nothing >> because they will be destructured to extract their information to >> be feed into the layoutFrame. So please do not blindly copy and >> paste code! >> >> Example: Favor >> >> (LayoutFrame identity leftFraction: 0; yourself); >> >> (LayoutFrame identity leftFraction: 0.5; rightFraction: 0.95; >> >> (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; >> bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: >> 1) over >> >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >> >> For this one in particular it is better to use LayoutFrame >> identity >> >> It is faster and more readable >> >> because you are creating for nothing a new rectangle and some >> points. >> >> !! Final point: Do not use Rectangles for specifying layoutFrames >> >> If you happen to need to create a rectangle and use the >> fractions:offsets: class methods, refrain from creating a >> rectangle. The reason is that a rectangle is not 4 numbers, it >> represents a space area and when you use a rectangle to represent >> random numbers you end up creating rectangles with negative extents >> and this is not good. In this case use Margin, Margin is a nice >> class holding either one number (the same "margin" on the four >> sides of a rectangle), or two number (top/bottom, left/right >> margins) or 4 numbers. >> >> !! Implementation >> >> Instance variables: The fractional distance (between 0 and 1) to >> place the morph in its owner's bounds is represented by the >> following instance variables: leftFraction topFraction >> rightFraction bottomFraction <Float> >> >> >> Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") is represented by the >> following instance variables: leftOffset topOffset rightOffset >> bottomOffset <Integer> >> > > >

Jan. 10, 2016

Re: [Pharo-dev] Better class comment version2

by David Allouche

I guess that is a class comment for LayoutFrame. I think this is great improvement. By I the way, I noticed something really strange when I was using it in my learning project of a TicTacToe game. I started initializing a LayoutFrame using #fractions:offsets:, but I had strange incorrect results. I have fixed them by using the elementary distance accessors. Here is the relevant method in my code. drawCircleOn: aCanvas "Draw a circle cell" | layout oval | "That should worlk, but does not!" "offsets := (1@1 corner: (-1)@(-1)) scaleBy: lineWidth*3." "layout := LayoutFrame fractions: (0@0 corner: 1@1) offsets: offsets." layout := (0@0 corner: 1@1) asLayoutFrame. layout topOffset: lineWidth*3; leftOffset: lineWidth*3; bottomOffset: lineWidth*(-3); rightOffset: lineWidth*(-3). oval := layout transform: self bounds. aCanvas frameOval: oval width: lineWidth color: color. I could not find an online syntax highlighter that supports Smalltalk, so here it comes unstyled. Should I write a test case for that, or did I try to do something obviously incorrect? > On 9 Jan 2016, at 10:22, stepharo <stepharo(a)free.fr> wrote: > > I define a transformation frame relative to some rectangle. I'm basic data structure used for graphics. > I represent two groups of distances: > - The fractional distance (between 0 and 1) to place the morph in its owner's bounds > - Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") > > !! API usage > It is important to understand that it is better to use the fine grained API using elementary distances (bottomFraction:, bottomOffset:, leftFraction: ....) than the ones (historical) using points and rectangles (fractions:offsets:) > > The reason is that the old API (fractions:offsets:) is only interesting if you already have a rectangle and point at hand. If you need to create new ones, then they are created for nothing because they will be destructured to extract their information to be feed into the layoutFrame. > So please do not blindly copy and paste code! > > Example: > Favor > > (LayoutFrame identity > leftFraction: 0; > yourself); > > (LayoutFrame identity > leftFraction: 0.5; > rightFraction: 0.95; > > (LayoutFrame identity > topOffset: topHeight; > bottomFraction: 0; > bottomOffset: self buttonsBarHeight; > leftOffset: -1; > rightOffset: 1) > over > > (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) > > For this one in particular it is better to use > LayoutFrame identity > > It is faster and more readable > > because you are creating for nothing a new rectangle and some points. > > !! Final point: Do not use Rectangles for specifying layoutFrames > > If you happen to need to create a rectangle and use the fractions:offsets: class methods, refrain from creating a rectangle. > The reason is that a rectangle is not 4 numbers, it represents a space area and when you use a rectangle to represent random numbers you end up creating rectangles with negative extents and this is not good. > In this case use Margin, Margin is a nice class holding either one number (the same "margin" on the four sides of a rectangle), or two number (top/bottom, left/right margins) or 4 numbers. > > !! Implementation > > Instance variables: > The fractional distance (between 0 and 1) to place the morph in its owner's bounds is represented by the following instance variables: > leftFraction > topFraction > rightFraction > bottomFraction <Float> > > > Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") is represented by the following instance variables: > leftOffset > topOffset > rightOffset > bottomOffset <Integer> >

Jan. 10, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by Serge Stinckwich

This is not SpurPharo.app instead of SpurPharo ? On Sun, Jan 10, 2016 at 6:49 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I changed the setting to be the following but I cannot get a spur image > started on mac. > Does anybody succeed? > > Stef > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

Hi Stef, Thanks for taking the time. I think I did not express myself properly in the previous mail because we are not really in disagreement :). The basic mechanism you talk about exists already in Spotter. Let me explain. When you type: "#e graphs", you will get two examples (and only the example search is being performed). This works because the name of the âExamplesâ category starts with âEâ. Until now we did not have a top level processor that would search for Senders (only inside a method). So, because of this you could not search for them at the top level. In the meantime Stefan just finished implementing it, the name of the category is Senders. So, you will type â#s somethingâ. I now made the category name start with # so that it is closer to the way to query for it. So, when you do not know how, you will just search for âsomethingâ. Then you will discover the #Senders category, and then you can learn that you can search for it. Now, you seem to be saying that instead of â#s somethingâ you want to type â#n somethingâ. For this we would need to find a solution to reconcile the two. My proposal was to maybe introduce something like â&n somethingâ to distinguish between the string match of a category name and a âshortcutâ (I do not know how to call it). I can see how to do this technically, but I still think this is less discoverable then the filtering by the name like described above, and it would be an extra mechanism. We could add this shortcut next to the category name to address this issue. The interesting thing about the shortcut is that we could possibly make it less ambiguous. For example, if you have two categories starting with #S, you will get both when you type â#S somethingâ, which is less ideal for a common case. So, there are pros and cons. Now, what is missing is a top level category for References, and I really think we would have what you wanted (and it is a good goal). The cool thing is that we would be solving this problem with a generic mechanism. So, what I am suggesting is to invest a bit in categories (#Senders can be integrated now) and then we play with it. Is this explanation clearer? Did I misunderstand something? What do you think? Cheers, Doru > On Jan 10, 2016, at 10:23 PM, stepharo <stepharo(a)free.fr> wrote: > > Ok my last attempt :( > > When I look for something there are two cases > > - most of the time I ********************KKKKNNNOOOOOOOWWWWWWW********* > is it clear? I know I know I know what I look for and I WANT THE FASTER WAY TO GET IT > => no three clicks and strange navigation. > > I want the sender of this message (not the implementors the sender) > I want that package > I want the references to this class (not the class and the refs that class) > and I'm ready to learn > #N for reference > #n for senders > #m for implementors > Because they are the same. > #e for example like in the finder > > - looking around and the system can propose me something > and I can navigate and think. > > But this is ok I just use Spotter to open the class browser and all the rest I do it with shortcuts. > I tried to help but I failed. > > I will present Spotter as the great tool to open browser because I cannot use it otherwise and > nobody around me can show me on the spot something more efficient than a shortcut in a workspace. > Or may be I will simply not spend energy doing a videos on Spotter because to me this is not ready > and far less usable than it is supposed to be. > > Now to me Spotter is taking a lot of classes for the gain I get. What esteban did or what is in Squeak > is working perfectly for me because Spotter does not let me express my needs. > So may be you have other needs but I would like to know how people really works and not > how Spotter should be usefull. > > The video of dimitry shows that well: Just browse a class and sometimes you get an implementor > May be you do not like my mail because they look aggressive but when is the last time > you did a real study with users that were not already convinced. Or may be with users > that loves just one tiny feature and not the one you think that they use? > > And BTW it hangs my images two times with 4.0 when I was in africa and this was annoying. > Stef > > >>> I do not get why you cannot >>> - have a set of fixed most used queries and this will create a small vocabulary that can be extensible >>> and it can be mapped to what we do with shortcuts = reduce cognitive load >>> and then a full search when you do not know what you are searching. >>> This is not exclusive and it works for the two scenario. >> >> I understand the intention, but I do not understand how these fixed queries are any different than we have now. When you are on the top of Spotter, when you query, you get always the same processors being executed. At first you will not know their names, and you will scroll. And if you see them, you might remember them and reproduce afterwards. Itâs a discoverable learning process that you do not have to remember. > > Because with these wonderfull queries I do not get what I'm looking for. > Because the system is trying to guess what I have in my mind and this system is not good for that because I'm thinking about > the metallica song I'm listening. > > >> The only part that is not discoverable is that # introduces a category search. Thinking loud, I just thought that we can make the label start with # like this (I committed this change): > > Sorry but I do not get it. > >> >> <Mail Attachment.png> >> >> We also thought of having completion as soon as someone type #. So, you have a kind of a dropdown for the available categories, but we did not get to implement that one. This should solve the discoverability problem even more. What do you think about that? > Why not > but just a ghost with > #n printOn: #m #N .... > would be a huge improvement > > Each time I used Spotter to look for something more than a class I could not find it. > > > >> Regarding the shortcuts, we could associated such shortcuts with a processor, but I would first want to see if we cannot manage to produce a solution with the current set of options. > > I was not saying shortcuts and I was thinking the same vocabulary > > Cmd+N > #N > Cmd+m > #m > Cmd+n > #n >> >> >>> I was discussing with Luc and he made a fun but sad remark >>> "Since people do not understand well spotter they most of the time only use it to open a class. >>> And this is something that he already had before." >>> I briefly looked at the Youtube video of Chloupis and >>> So you can have a generic super cool tool, if people do not use it it defeats its purpose. >> >> Certainly. >> >> >>> You can be really happy because you go fast with it but you only. >> >> That is not really true :). > > See my remark above. >> >>> So making sure that the most used actions are really supported is important. >> >> Of course it is. For Senders we did not find a good solution yet that is reasonably fast and useful. Stefan and I are still literally working on this. I think we should be able to have a solution, but we have to see if it is reasonable enough. We will announce it once we have it working. > > the problem is that you want to solve everything at once. While the divide and conquer is the solution for the first > scenario I mention. I do not need something that crawls the entire system when I have one precise query. > > >> >> But, really, this tool more than anything allows one to play with possibilities in a couple of lines of code. We want people to play (some did) and to get concrete feedback and possible solutions. I think we should not just say that we need something else before we actually play with it a bit more. > I do not get it. > I never worked with me. And so far I did not see anybody succeeding to show me how to find something that I cannot > find faster with a shortcut. > > > >>> But more important the discoverability is important because there is not even a help. >>> Right now as a user I can only guess and often I close spotter and use my shortcuts. >>> As a user I see something that ask me about network (and I do not care) but nothing >>> that brings me to the next level. >> >> This is something we need to work on, but you know, time is limited for us, too. > > Add a button and an help text copied from your blog! > And you will have made a 100% documentation jump. >> >> >>> Most of the time the user forgets the key combination (may be this will be solved with >>> the cool shortcut reminder we developed and is under review) >> >> All actions in spotter have a visible icon. All. And if you hover over it you get the command. And there are literally 5 such actions. What is missing in this regard from your point of view? > > I do not know > They do not cover what I want to do. > I do not care of setting > Most of the time I do not care about seeing all. I saw now that you have an arrow to show more than the top 5 > good but again Cmd-shift > is not easy to type and give pain. > I do not understand why I should dive in most of the time. > > I realised that I could use Spotter when I saw that I can press shift under the return because > before I got immediate pain when trying with the left shift. > To me left shift is a NO WAY. > esc (top left) would work but I did not have the time to hack Spotter. > >> >> Doru >> >> >>> Stef >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> > -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Jan. 10, 2016

Re: [Pharo-dev] Atomic commits

by David Allouche

100% Agreed. > On 8 Jan 2016, at 18:25, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > When one uses a tool in a way that is not suppose to use , the one must expect all sort of new and fascinating problems. > > Some think that putting changes in 2121 files in a single commit is a good idea, github politely disagrees. > > In this case if you want go down the visual route I highly recommend a Git GUI client, I know people are obsessed of doing everything inside pharo, something I may never understand but as I stated in my video tutorial about Git , nothing pharo will create at least the next year will come remotely close to the elegant workflow of some of the best GIT GUIs like SmartGit, SourceTree and lately I am deeply in love with GitUp which unfortunately is only for MacOS because I think is awesome git gui client that makes git super easy. > > Most coders that use git rely on a git client of some sort, if you dont like guis and prefer emacs, there is also magit that i hear is very good. > > No disrespect on people working on git integration in pharo, I am 100% behind them, but frankly I rather use pharo with other tools than pharo alone and try to convince myself that my old methods are going to work with new external tools. > > On Wed, Jan 6, 2016 at 8:14 PM Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > Hi, > I wish the commits were much more atomic than they currently are... > With current practice, reviewing the changes is near to impossible: > - it requires far too much concentration > - it's just impossible through github web interface > > For example, I did wander if the structure fields were correclty aligned in: > https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8… <https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8…> > because I see no code for aligning the offsets... > > But I cannot even navigate in the history... If I do so, > https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405… <https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405…> > the page tells me > "Sorry, we could not display the entire diff because too many files (2,121) changed" > and I couldn't find a way of displaying the portion of interest. > > I thus loose the ability to deposit a comment. > > I can still open a fresh Pharo image and browse and review the whole code snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't. > > While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? > In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. > But in current process i fail to capture such information... > > This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.

Jan. 10, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Dimitris Chloupis

but then I remember once trying to find a tutorial about opengl 3, could not find a thing, then i found one and I wished I never found it. Sometime not documenting thing can be good for your emotional state , ignorance is a bliss :D On Sun, Jan 10, 2016 at 10:33 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I cant understand it not having comments in the first place because i > forget so easily , especially when the code grow larger. But yeah class > comments would be the best feature that pharo can ever have. It would make > coding 1000 times easier. > > On Sun, Jan 10, 2016 at 10:25 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 10 Jan 2016, at 21:14, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> >> wrote: >> > >> > Le 08/01/2016 12:07, Tudor Girba a Ã©crit : >> >> Hi, >> >> >> >> We are about to integrate in Pharo a new member of the Glamorous >> >> Toolkit: the GTDebugger. As this is a significant change that might >> >> affect your workflow, here is some background information to help you >> >> deal with the change. >> >> >> >> First, you should know that the change is not irreversible and it is >> >> easily possible to disabled the new debugger through a setting. >> However, >> >> please do take the time to provide us feedback if something does >> >> not work out for you. We want to know what can be improved and we try >> to >> >> react as fast as we can. >> >> >> >> A practical change comes from the fact that the variables are >> >> manipulated through a GTInspector, which makes it cheaper to maintain >> in >> >> the longer run. >> >> >> >> While the first thing that will capture the attention is the default >> >> generic interface, the real power comes from the moldable nature of the >> >> debugger. Like all other GT tools, GTDebugger is also moldable by >> >> design. This means that we can construct custom debuggers for specific >> >> libraries at small costs (often measured in a couple of hundred lines >> of >> >> code). >> >> >> >> For example, the core configuration includes also the SUnit and the >> >> bytecode debugger. These are around 150 lines of code. Here is how the >> >> bytecode debugger looks like: >> >> >> >> >> >> >> >> You can find more information in an introductory overview blog post >> that >> >> also includes some links for further reading: >> >> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >> >> >> >> Please let us know what you think. >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >> -- >> >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> www.feenk.com >> >> >> >> "What is more important: To be happy, or to make happy?" >> >> >> >> >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev(a)list.inf.unibe.ch >> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> > >> > Hi, >> > >> > An other thing that came in my mind is that, for now, GTDebugger lack >> > documentation. >> > Some classes have no documentation and the class with a comment only >> > have 1 line and don't follow the template. >> > >> > It's good that people takes time to add documentation but if the new >> > classes that Pharo include does not have a proper documentation (class >> > doc + comments in complex methods) we will never be able to have a >> > version of Pharo with a good documentation. >> > >> > I think that we should not integrate new classes if they don't have a >> > class comment that follow the template. >> >> +100 >> >> I can understand that when prototype, hacking, being generally productive >> inside Pharo, you don't write comments at first. But once you go public, >> after some iterations, and especially if you want to be integrated into >> Pharo itself, there is no excuse. We need proper class comments, and >> comments for the main non-trivial public methods. >> >> Sven >> >> > -- >> > Cyril Ferlicot >> > >> > http://www.synectique.eu >> > >> > 165 Avenue Bretagne >> > Lille 59000 France >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)list.inf.unibe.ch >> > https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >

Jan. 10, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Dimitris Chloupis

I cant understand it not having comments in the first place because i forget so easily , especially when the code grow larger. But yeah class comments would be the best feature that pharo can ever have. It would make coding 1000 times easier. On Sun, Jan 10, 2016 at 10:25 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 10 Jan 2016, at 21:14, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> > wrote: > > > > Le 08/01/2016 12:07, Tudor Girba a Ã©crit : > >> Hi, > >> > >> We are about to integrate in Pharo a new member of the Glamorous > >> Toolkit: the GTDebugger. As this is a significant change that might > >> affect your workflow, here is some background information to help you > >> deal with the change. > >> > >> First, you should know that the change is not irreversible and it is > >> easily possible to disabled the new debugger through a setting. However, > >> please do take the time to provide us feedback if something does > >> not work out for you. We want to know what can be improved and we try to > >> react as fast as we can. > >> > >> A practical change comes from the fact that the variables are > >> manipulated through a GTInspector, which makes it cheaper to maintain in > >> the longer run. > >> > >> While the first thing that will capture the attention is the default > >> generic interface, the real power comes from the moldable nature of the > >> debugger. Like all other GT tools, GTDebugger is also moldable by > >> design. This means that we can construct custom debuggers for specific > >> libraries at small costs (often measured in a couple of hundred lines of > >> code). > >> > >> For example, the core configuration includes also the SUnit and the > >> bytecode debugger. These are around 150 lines of code. Here is how the > >> bytecode debugger looks like: > >> > >> > >> > >> You can find more information in an introductory overview blog post that > >> also includes some links for further reading: > >> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > >> > >> Please let us know what you think. > >> > >> Cheers, > >> Doru > >> > >> > >> -- > >> www.tudorgirba.com <http://www.tudorgirba.com> > >> www.feenk.com > >> > >> "What is more important: To be happy, or to make happy?" > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)list.inf.unibe.ch > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > > > > Hi, > > > > An other thing that came in my mind is that, for now, GTDebugger lack > > documentation. > > Some classes have no documentation and the class with a comment only > > have 1 line and don't follow the template. > > > > It's good that people takes time to add documentation but if the new > > classes that Pharo include does not have a proper documentation (class > > doc + comments in complex methods) we will never be able to have a > > version of Pharo with a good documentation. > > > > I think that we should not integrate new classes if they don't have a > > class comment that follow the template. > > +100 > > I can understand that when prototype, hacking, being generally productive > inside Pharo, you don't write comments at first. But once you go public, > after some iterations, and especially if you want to be integrated into > Pharo itself, there is no excuse. We need proper class comments, and > comments for the main non-trivial public methods. > > Sven > > > -- > > Cyril Ferlicot > > > > http://www.synectique.eu > > > > 165 Avenue Bretagne > > Lille 59000 France > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 10, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

> > Especially it is commonly used scenario by senders of > #critical:ifError:. But it is different question. > I propose change ifError: to cull error instance. > > What you think? Can be put it in Pharo 5? Such change can touch some > packages So did you fix it? Stef

Jan. 10, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

> But it is too long. ifError: is very intuitive name. Not to me. Stef

Jan. 10, 2016