- Pharo-dev - lists.pharo.org

valid pragma syntax

by Nicolai Hess

pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" is nil is this valid pragma syntax: <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> our (pharo) parser can not parse this (does not recognizes the "selector parts" (apicall:module:) right) Any recommendations how to fix this - fix RBParser or - change this pragma, for example, like this <apicall: #(bool SetCursorPos (long long)) module: 'user32.dll'> nicolai

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-10 6:26 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Thanks for the detailed feedback. See my comments inline. > > > On Jan 10, 2016, at 12:12 AM, Ferlicot D. Cyril < > cyril.ferlicot(a)gmail.com> wrote: > > > > Le 09/01/2016 10:32, Tudor Girba a Ã©crit : > >> Hi, > >> > >> Could you be specific? What exactly do you find less intuitive? To be > able to react, it is useful to get concrete points. > >> > >> Cheers, > >> Doru > >> > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Value is always contextual." > >> > > > > This was my impression but I will try to list these things. > > > > First I find the improvements of Esteban good. > > > > - For the icons it is true that the text help a lot. As someone mention, > > just a setting to get or not the text is possible, but a least be able > > to get the text is important IMO. > > I use Intellij for java debugging and sometime I get a little lost when > > I see the icons because for a same icon there is two different actions > > between Pharo and Intellij. So I lose always some time waiting the > > popup. And I think that a lot of students that do Java will have the > > same problem. > > Interesting point, but I would not guide myself > > > > - I like that the stack is fully loaded in the Spec debugger. In general > > that doesn't add this much time to show all the stack and it's one more > > line to show useful information. > > It is now fully loaded in a FastTable in the GTDebugger as well. > > > > - On thing that I really don't like is to get 4 lines with the code of a > > block in the stack. This is too much space I think. And because of this > > we have a large horizontal scroll bar that we could avoid with a limite > > in character. I miss the fact that we had the name of the class on the > > line of a block in the Spec debugger. > > This is no longer the case in the latest implementation. Could you check? > > > > For example I will join a screen with a block. > > > > I would prefer something like: > > > > In GLMMorphicTabulatorRenderer: [ :index :each | each hasId ifTrue:â¦ ] > > And if you use FTTable you will not even get the horizontal scrollbar, > > so it's useless to get 4 long lines of the block if we cannot see half > > of it. > > > Indeed. Printing is a problem of the Context printing, and will be > changed, but in the meantime we have FastTable. Is this good enough for now? > > > > - There is no way to close the inspector if we miss click > > Indeed, this is a problem. We did not want to have an extra tab line and > that is why we do not have a way to close inspector panes, but you can > still scroll back. Also, in the meantime, we made the Evaluator the default > second pane, so you can use it by default just like in the classic debugger. > How about making the first pane sticky? I ofte miss click, or if I want to open the context menu on a instance variable, or array item, for opening another inspector window, the contenxt inspect pane slides away and this is really annoying. > > > > - I liked the separation between attributes and parameter/temp. I think > > that it was more readable. Before I could had a global overview of both > > easily. Now I have to scroll down to see the attributes. But for this > > one maybe I prefer the old one by habits. > > I think this is indeed a habit issue. > > > > - The context menu of the spec debugger have more useful options > > (Suggestions, Code searchâ¦) > > These can be added. Could you say more concretely which of those you > actually used? > > > > These are the things that come in my mind. But maybe I missed some since > > the fact that I found the old debugger more intuitive was a feeling. > > It's hard to define why we have a feeling. > > Thanks for taking the time. I know itâs hard to dig underneath an > impression like that, but it is very valuable once you do it because it can > push us further. > > Cheers, > Doru > > > > -- > > Cyril Ferlicot > > > > http://www.synectique.eu > > > > 165 Avenue Bretagne > > Lille 59000 France > > <screen14.png> > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > >

Jan. 10, 2016

Re: [Pharo-dev] Just that you know that we are not happy

by Max Leske

> On 10 Jan 2016, at 08:37, stepharo <stepharo(a)free.fr> wrote: > > Hi > > if GTdebugger becomes the default debugger it means that our mooc will be already obsolete before getting finished. > It means that we will be forced to > have separate installers > different web pages explaining not to use Pharo 50 but a strange version > it means that people will report bugs on a different system > And we will have to spent time on that instead of the rest. > > And we will really thank the Pharo community for its great vision and care about our effort. > This is more than 6 months that we are working on it and we have problably yet another month of work. > Now just writing this makes me sick. > > So if the only respect about the work of other people is like that then I will just think a lot about my > engagement. If this happens I can tell you that you will have a hard time to ask me to put energy into > pharo in the future. > > Now if this makes you feel easy you can think that I'm tired. This poor stephane is working too much and > is overacting. Think that if this helps you to feel good. Really. > > Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 students > This year I was teaching to > Prague > Annecy > Lviv > Lome > Dakar > Saint louis > Yaounde > > and when I say that the student are afraid by the default debugger, they are afraid also by > a more complex one. Who among the people deciding to not put this debugger by default > can show me that he did one lecture on newbies over the last two years? For real? > > So be right and go ahead: because you know what is good for the end programmer. > I asked five times to understand who need _thisContext and _stakc top and so far I got zero answer. > It will help me to take a break from Pharo. I use both thisContext and stackTop regularly. thisContext maybe once a wee, stackTop probably multiple times a day. > > Stef > > PS: I 'm not in the Pharo board anymore because I have to do something else > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-09 23:10 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > On Jan 9, 2016, at 3:29 PM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > > Not yet tested but looks good. > > > Thanks. > > I just noticed it misses the "run to here" action. > > > It does not miss it. It is in the context menu of the code (this is where > it logically belongs). > Argh, trying to change a "well known user interface" (SpecDebugger) and arguing about why the new interface (GTDebugger) is " more logical" is always risky :) Even so we (smalltalkers) have the best software environment (Pharo) we are bound to our owns habits. And it is a question of "discoverability". If you only see 5 debugger action icons, you may not know that there is another one (hidden) inthe context menu. > > > > Doru > > > > > Le 9 janv. 2016 Ã 11:01, Esteban Lorenzano a Ã©crit : > > 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 > > "Quality cannot be an afterthought." > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-09 22:51 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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? > I don't know. At the moment I would say, keep it. It is a valuable information about the current state of the execution. But if you implement it as you described, I will test and give feedback. I would not change the name of thisContext to _thisContext. The name "thisContext" is a valid and evaluatable variable name. It is confusing if we show it as "_thisContext" just to tell it appart from "normal" variable names. There is a "type" column, this could be used to name this kind of variable ("pseudo Var" for example). > > 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. 10, 2016

Re: [Pharo-dev] Just that you know that we are not happy

by HernÃ¡n Morales Durand

Hi Stef, Just to tell you that I don't understand the process (if any) where it is decided a new tool to be the new default, how it is evaluated and by whom. But I would love to. HernÃ¡n 2016-01-10 6:06 GMT-03:00 stepharo <stepharo(a)free.fr>: > Since the debugger is improving we will see if we can avoid to produce an > obsolete lecture that people will > use for 5 years. I should discuss with damien and luc. > But it means that it should be stable by monday or at maximum tuesday > because we will have to redo > the slides. Now luckily we postponed redoing 15 videos we should (re)do to > show how to code in Pharo > (for the record doing such videos of 5 min takes 3 hours minimum to do, > cut and process). > > Now I would like that we consider that I gave feedback on the icons two > years ago and the net result > was that during two years nothing changed. So I'm happy to see feedback > getting listened because > I often got the impression in the past that I should learn how to use > tools instead of having tools > that work for me (remember the discussion about playground and where we > have to explain why the result of > a printString should not only be in a popup!) > Sometimes I hate that people teachs me how I should work because I often > go faster my way. > > Stef > > Le 10/1/16 08:37, stepharo a Ã©crit : > > Hi >> >> if GTdebugger becomes the default debugger it means that our mooc will be >> already obsolete before getting finished. >> It means that we will be forced to >> have separate installers >> different web pages explaining not to use Pharo 50 but a strange >> version >> it means that people will report bugs on a different system >> And we will have to spent time on that instead of the rest. >> >> And we will really thank the Pharo community for its great vision and >> care about our effort. >> This is more than 6 months that we are working on it and we have >> problably yet another month of work. >> Now just writing this makes me sick. >> >> So if the only respect about the work of other people is like that then I >> will just think a lot about my >> engagement. If this happens I can tell you that you will have a hard time >> to ask me to put energy into >> pharo in the future. >> >> Now if this makes you feel easy you can think that I'm tired. This poor >> stephane is working too much and >> is overacting. Think that if this helps you to feel good. Really. >> >> Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 >> students >> This year I was teaching to >> Prague >> Annecy >> Lviv >> Lome >> Dakar >> Saint louis >> Yaounde >> >> and when I say that the student are afraid by the default debugger, they >> are afraid also by >> a more complex one. Who among the people deciding to not put this >> debugger by default >> can show me that he did one lecture on newbies over the last two years? >> For real? >> >> So be right and go ahead: because you know what is good for the end >> programmer. >> I asked five times to understand who need _thisContext and _stakc top and >> so far I got zero answer. >> It will help me to take a break from Pharo. >> >> Stef >> >> PS: I 'm not in the Pharo board anymore because I have to do something >> else >> >> >> >> >> > >

Jan. 10, 2016

Re: [Pharo-dev] Just that you know that we are not happy

by stepharo

Since the debugger is improving we will see if we can avoid to produce an obsolete lecture that people will use for 5 years. I should discuss with damien and luc. But it means that it should be stable by monday or at maximum tuesday because we will have to redo the slides. Now luckily we postponed redoing 15 videos we should (re)do to show how to code in Pharo (for the record doing such videos of 5 min takes 3 hours minimum to do, cut and process). Now I would like that we consider that I gave feedback on the icons two years ago and the net result was that during two years nothing changed. So I'm happy to see feedback getting listened because I often got the impression in the past that I should learn how to use tools instead of having tools that work for me (remember the discussion about playground and where we have to explain why the result of a printString should not only be in a popup!) Sometimes I hate that people teachs me how I should work because I often go faster my way. Stef Le 10/1/16 08:37, stepharo a Ã©crit : > Hi > > if GTdebugger becomes the default debugger it means that our mooc will > be already obsolete before getting finished. > It means that we will be forced to > have separate installers > different web pages explaining not to use Pharo 50 but a strange > version > it means that people will report bugs on a different system > And we will have to spent time on that instead of the rest. > > And we will really thank the Pharo community for its great vision and > care about our effort. > This is more than 6 months that we are working on it and we have > problably yet another month of work. > Now just writing this makes me sick. > > So if the only respect about the work of other people is like that > then I will just think a lot about my > engagement. If this happens I can tell you that you will have a hard > time to ask me to put energy into > pharo in the future. > > Now if this makes you feel easy you can think that I'm tired. This > poor stephane is working too much and > is overacting. Think that if this helps you to feel good. Really. > > Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and > M1 students > This year I was teaching to > Prague > Annecy > Lviv > Lome > Dakar > Saint louis > Yaounde > > and when I say that the student are afraid by the default debugger, > they are afraid also by > a more complex one. Who among the people deciding to not put this > debugger by default > can show me that he did one lecture on newbies over the last two > years? For real? > > So be right and go ahead: because you know what is good for the end > programmer. > I asked five times to understand who need _thisContext and _stakc top > and so far I got zero answer. > It will help me to take a break from Pharo. > > Stef > > PS: I 'm not in the Pharo board anymore because I have to do something > else > > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

- Can we have a setting to remove all the colors from the stack because sometimes the hilighting is more confusing than helping and especially for newbies - the argument about run to here not being a button is not about logical placement is it about making things easy to use and discover. - I found the icon on the right (the right mo When do you think that the new debugger could be stable. Because we can try to see if we can change the lectures and change the screenshots but first we should finish the other ones. Stef Le 9/1/16 22:35, Tudor Girba a Ã©crit : > 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 >> <mailto:tudor@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 <http://www.tudorgirba.com> > www.feenk.com > > "It's not how it is, it is how we see it." >

Jan. 10, 2016

Re: [Pharo-dev] Little challenge

by stepharo

Le 10/1/16 01:56, Eliot Miranda a Ã©crit : > BlockClosure and Context. Back in the day OrderedCollection was one (when become was cheap there was no need for the array inst car). Yes I remember in VW. > You want to say > > Smalltalk allClasses select: [:c| c isVariable and: [c instSize > 0]] > > _,,,^..^,,,_ (phone) > >> On Jan 9, 2016, at 1:24 PM, stepharo <stepharo(a)free.fr> wrote: >> >> 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. >> >> >> <hhbahgba.> >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

> I've never used the bytecodes view, but when I see them listed in the > inspector on a method I still often think "Wow! You can do that?!" > Its cool a hook to let novices peek under the hood and build a sense > of mastery. Though I haven't used the GTDebugger for a long time, so > I'm not sure whether my sentiment is applicable. We are not facing the same novices then. Mine are 3 years into programming at max. Stef

Jan. 10, 2016