- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Tudor Girba

Thanks. What do you think of the new solution? Is it sufficient? Doru > On Jan 8, 2016, at 8:05 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > I second Torstenâs comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > >> On Jan 8, 2016, at 14:28, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi, >> >> with a moldable debugger we should (in the future) be able to support >> debugging also different/other programming languages/DSLs in Pharo :) >> - although usually one does necessary have such a use case. So I guess >> GTInspector or other will be adopted to own needs more than GTDebugger. >> >> However: >> The only objection so far is that I dislike the order/size of the panes. >> The placement of the panes in GTDebugger (as for instance found in Moose) >> requires often to use the scrollbars of the pane showing the stack because >> of the text length. >> >> In GTDebugger the stack is at the top left, the source at the top right with >> a common splitter beneath the two panes: therefore the height (depth) of the >> stack pane is always the height of the code pane. >> When you have a long method to debug on the right much space is wasted for >> a deep stack on the left although you might only be interested in a few top frames. >> >> Contrary when you have are interested in a deep/full stack and you increase the >> height of the stack pane on the left you directly increase the height of the code >> pane and for short methods you waste a lot of space in the source pane as well. >> >> This is much better solved with the positioning in the traditinal Debugger: >> - Stack >> - Source >> - other >> >> So in my opinion We should preserve: >> >> - TOP: the stack at the top (using the full width of the window, so only vertical scrolling >> has to be done to "roll" on the stack, no need for horizontal scrolling as the area >> is wide enough) >> - MIDDLE: the source code pane in the middle (also using the full width of the window and there >> fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) >> - BOTTON: one or more panel for inspection at the bottom >> >> It would be OK for me if others like the new layout better - but at least there should be an >> option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) >> >> Also the debugger window in Moose wastes a lot of space/has unused space within the >> windows client are itself. For instance the splitters are very thick which might be an issue of >> the moose theme. >> >> Thanks >> T. >> >> Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr >> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 >> >> 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). >> >> >> >> Here is 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[http://www.feenk.com] >> >> "Beauty is where we see it." > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Thank you, indeed. Doru > On Jan 9, 2016, at 1:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Thanks for this wonderfully positive message !! That is the spirit. > >> On 09 Jan 2016, at 10:49, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> Since I am the mainn maintainer of UPBE and pretty much alone, I will have to disagree, I have expressed my dislike for GT tools in the past, I was quite vocal about my dislike about GTPlayground and especially the pages interface of GTInspector. >> >> Yet even though I am the one that usually ends up keep pushing UPBE forward the most, I never said dont include this GT tool because I will have to document it. >> >> As a matter of fact GT people are the rare breed of pharoers , close to extinction level, that bothers documenting its own tools making my job super easy and a matter of porting their blog posts to Pillar. >> >> Also its important to note here that our dear beloved debugger is decades old, maybe just maybe its time to try something new even if we dont like it. >> >> Afterall GT people were quick to adress my problems of Playground like the lack of copy paste in right click menu, the lack of tabs etc. We objected and criticised, they improved . End of story. None complains about the Playground anymore. >> >> Its also important to note that they constantly pushing pharo forward. >> >> On the matters of documentation I will accept zero excuses from this community. If one spent 10 minutes per week, I repeat 10 minutes per week, on contributing to UPBE we would have the following >> >> 1) a person even a slow typer, types at least 40 words per minute >> 2) in 10 minutes one can type 400 words >> 3) That is one page of UPBE (pdf version) in 10 minutes >> 4) thats 50 pages per year per person >> 5) if people who are experienced are at least 10, I think we can find 10 people who understand pharo deeply , thats 500 pages per year >> >> we end up with the conclusion that the UPBE with extremely limited effort and extremely low amount of people would have by now the last 7 years that Pharo is around , 3500 pages of documentation. >> >> But since 10 people is too few and there a lot more judging from the mailing list , I will say 100 people is more realistic which means 35.000 pages or to put it more in perspective , thats the total of 10 UPBE books >> >> I repeat 10 UPBE BOOKS !!!!! >> >> >> So no no no and NO dont exclude the new debugger because of the effort to document, I respect Stef he and Damien are the ones responsible for the existenve of UPBE and PBE in the first place, they also helped me alot with Dimitri to port many chapters to pharo 4. Plus I love Pillar for documentation its awesome even with its flaws. >> >> >> But I say that GT people earned my trust, my trust that the have desire and visions to push Pharo forward and I say let them put the Debugger in who is going to hurt , it can be disabled and bring back the old one. Same story with Playground but seriously who bring back the old workspace ? >> >> Let them take the criticism and improve the new debugger, its a new thing of course it will have its flaws. But I dont want a Pharo that works well, I want a Pharo that keeps going forward. >> >> I have not the opportunity to download a new image because of my lack my connection is down and I use my mobile connection to do the minimum because it costs too much. >> >> But even if I heavily dislike the debugger like I did the the Playground I know that GT people will listen and will improve it, for that I have zero doubts because I admire their efforts even when I disagree with them. >> >> >> >> On Sat, Jan 9, 2016 at 4:19 AM Ben Coman <btc(a)openinworld.com> wrote: >> On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> wrote: >>> I'm sorry but this debugger should not be the default one. >>> MONDAY we are filming our mooc and we have to explain the debugger and >>> personally I do not see the gain: >>> - It looks a lot more complex to me and I do not want to have to redo >>> all the screenshots >>> of our lecture. >>> - Just that I have to learn the meaning of small icons. >>> - Why do we need a special pane for the evaluator >>> - Why there is a type column. >>> - Sorry but I'm not convinced about the moldable aspect behind the story >>> (no need to argue I know it) >> >> This also applies to UPBE. It would be good to get that out the door >> matching Pharo 5 without too much rework. >> >> cheers -ben >> >> >>> I would like to avoid to be forced to use not the latest version of Pharo >>> for the mooc. >>> >>> Such changes are arriving far too late in the release. We do not change the >>> debugger itself the day of code freeze. >>> >>> We decided that the GTDebugger can be included but to me it never meant that >>> it should be the default one. >>> I think that experts can choose the debugger they want. The newbies don't. >>> >>> Stef >>> >>> >> > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Thanks for this. Part of it is now in the repo. We need to work to find a reasonable solution to add text to Glamour. Cheers, Doru > On Jan 9, 2016, at 12:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > <Screen Shot 2016-01-09 at 10.59.20.png> > > would that be aceptable for you? > > cheers! > Esteban > >> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> (re-send because I exceeded limit.) >> >> Hi, >> >> letâs think positive. >> the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. >> For instance, I took me 2â to tweak the debugger presentation and to get this: >> >> <Screen Shot 2016-01-09 at 09.29.59.png> >> >> (I changed all availableâ¦ is a trivial task) >> >> and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. >> Reasons to suggest this approach: >> >> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) >> - it preserves âthe importantâ (the code) as central. >> - it gives space for adding columns (like the bytecode). >> >> Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ >> >> Soâ¦ can we have an agreement? >> >> Esteban >> >> ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too >> >>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: >>> >>> Thanks for your testimony. >>> >>> I'm not against GTDebugger per se. I believe that we should have better tools >>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >>> >>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >>> >>> Stef >>> >>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>> I'm sorry but this debugger should not be the default one. >>>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>>> personally I do not see the gain: >>>>> - It looks a lot more complex to me and I do not want to have to >>>>> redo all the screenshots >>>>> of our lecture. >>>>> - Just that I have to learn the meaning of small icons. >>>>> - Why do we need a special pane for the evaluator >>>>> - Why there is a type column. >>>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>>> story (no need to argue I know it) >>>>> >>>>> I would like to avoid to be forced to use not the latest version of >>>>> Pharo for the mooc. >>>>> >>>>> Such changes are arriving far too late in the release. We do not change >>>>> the debugger itself the day of code freeze. >>>>> >>>>> We decided that the GTDebugger can be included but to me it never meant >>>>> that it should be the default one. >>>>> I think that experts can choose the debugger they want. The newbies don't. >>>>> >>>>> Stef >>>>> >>>>> >>>> IMO the old debugger is way more intuitive. >>>> When I used the debugger of Eclipse for java I was lost. When I used >>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>>> the feeling with GTDebugger. And the debugger is one of the main source >>>> of interest for newbies. >>>> >>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>>> >>> >>> >> > -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 9, 2016, at 9:52 PM, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com> wrote: > > Hi, > > i would like to have the GTDebugger in the near future. Great job and thanks! > > I like the Esteban built instead of the original one and i agree with stef on removing _stack and _thisContext from top and the bytecode view. Aim to simplicity must be a top priority and if anybody needs something more specific can change it easily (its moldable!) :) Doru > Cheers > Francisco > > > > On Sat, Jan 9, 2016 at 12:07 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > http://ws.stfx.eu/3KXXDAJ4EUF6 > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Saturday, January 9, 2016 3:36 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 > > On 09-01-16 12:39, Dimitris Chloupis wrote: > > there has been around a script to automate the screenshots, but > > personally I never bother using it because taking a screenshot and > > inserting in pillar is the easiest thing. > > AFAIK the hard part is keeping things up to date. That's where automation helps. > > Stephan > > > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 9, 2016, at 10:23 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-09 20:52 GMT+01:00 Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com>: > Hi, > > i would like to have the GTDebugger in the near future. Great job and thanks! > > I like the Esteban built instead of the original one and i agree with stef on removing _stack and _thisContext from top and the bytecode view. Aim to simplicity must be a top priority and if anybody needs something more specific can change it easily (its moldable!) > > I often use thisContext and stackTop for inspecting the current context (I use this a lot when debugging compiler errors) and > the stackTop when stepping through cascaded message send, I want to see the intermediate return value. Indeed, I use them too, but not too often. That is why Andrei and I think maybe they should be in the menu of hte stack and have them appear in the inspector below. What do you think? Cheers, Doru > > > Cheers > Francisco > > > > On Sat, Jan 9, 2016 at 12:07 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > http://ws.stfx.eu/3KXXDAJ4EUF6 > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Saturday, January 9, 2016 3:36 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 > > On 09-01-16 12:39, Dimitris Chloupis wrote: > > there has been around a script to automate the screenshots, but > > personally I never bother using it because taking a screenshot and > > inserting in pillar is the easiest thing. > > AFAIK the hard part is keeping things up to date. That's where automation helps. > > Stephan > > > > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Jan. 9, 2016

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) Yes. This would work quite well if the language would project on the AST of Pharo, like Helvetia does. > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. The debugger can be specialized for specific libraries or frameworks, not necessarily only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements. I expect that every framework would benefit from a specialized debugger. This would not be an odd behavior at all. > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Thanks. We took this into account. > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. Thanks. We reduced the splitter size in Glamour. Doru > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch <mailto:moose-dev@iam.unibe.ch>>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > 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). > > > > Here is an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ <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/>[http://www.tudorgirba.com <http://www.tudorgirba.com/>] > www.feenk.com <http://www.feenk.com/>[http://www.feenk.com <http://www.feenk.com/>] > > "Beauty is where we see it." -- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/> "Presenting is storytelling."

Jan. 9, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

You can find documentation with examples about GTSpotter on the humane-assessment.com blog: https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… Specifically about finding Pragma usages, I just added a blog post: http://www.humane-assessment.com/blog/spotting-pragmas-with-gtspotter Cheers, Doru > On Jan 9, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > Is there a help a student or idiot like me can read about how to find information with Spotter? > For example > We with luc wanted to find all the senders of variableSubclass: we tried # #senders and more... but gave up. > Yesterday I wanted to find all the user of <menu> > > May be I missed an obvious help that will enlighten me? > I hope. > > Now without such help how can we expect students or users to discover the way we should > use the tools? > > We were planning to do a video to explain Spotter but I'm slowly thinking to discard this video > because we do not know. > > Stef > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hello everyone, As expected, there was some feedback. Here is a summary: 1. The layout should mirror the classic debugger - The previous layout was chosen to show more of the stack and to make use of the screen real estate. - But, as that is not an essential component of GTDebugger, the current implementation of the generic stack debugger looks like this now: 2. it would be interesting if the buttons would have text - This is something we need to work on 3. Why is there bytecode shown? - There is none by default :). This only appears when the developer explicitly chooses the Bytecode debugger 4. why is there a _thisContext _stackTop? - Because this is what the SpecDebugger offers as well :). - But, we removed them for now from the list. - There would be a possibility to add them to the context menu of the stack or to add them to bottom of the list 5. why is there a Type column in the inspector - Because we want to know what kind of variable we are dealing with (parameter, instvar, temp). This is not explicit in other debuggers. - Furthermore, you can filter the variables by clicking on the type tag. This can be particularly useful when we deal with large states. Please let me know if I missed anything. Of these only point 2 requires work. Cheers, Doru > On Jan 8, 2016, at 1:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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: > > <bytecode.png> > > 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 > www.feenk.com > > "What is more important: To be happy, or to make happy?" > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Jan. 9, 2016

Re: [Pharo-dev] Little challenge

by stepharo

We tried (Object allSubclasses select: #isVariable) reject: [ :each | each instVarNames isEmpty ] and we discovered that we have no class in the system with named instance variables and indexed ones. May be we are wrong. We are interested if you find one. Now we created one Object variableSubclass: #PPpoint instanceVariableNames: 'x y' classVariableNames: '' package: 'Web' and this is strange because inspecting PPoint new: 3 looks wrong since the variable zone arrives before the named one as displayed.

Jan. 9, 2016

Re: [Pharo-dev] Idea to improve GTInspector

by Tudor Girba

Thanks. Try this. Class>>gtInspectorDefinitionIn: composite <gtInspectorPresentationOrder: 15> composite pharoScript title: 'Definition'; display: [ self definition ] I committed it in the latest GTInspector. It took 2 minutes. Doru > On Jan 9, 2016, at 11:14 PM, stepharo <stepharo(a)free.fr> wrote: > > We cannot see the class definition when browsing a collection of classes. > > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Jan. 9, 2016