- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] valid pragma syntax

by Nicolai Hess

2016-01-10 13:14 GMT+01:00 Levente Uzonyi <leves(a)caesar.elte.hu>: > > On Sun, 10 Jan 2016, Nicolai Hess wrote: > > pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" is >> nil >> >> >> is this valid pragma syntax: >> >> <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> >> > > This is not a pragma, but the special syntax used by FFI. AFAIK it > predates pragmas. > Ah, ok. > > >> 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'> >> > > There's nothing to fix here. Either you change your parser, compiler and > decompiler to support this syntax, but knowing how things work in Pharo, > this is not an option Why is this not an option? > , or change the methods with these callouts, introducing another > incompatibility between Pharo and the rest, to use pragmas and create a > custom parser, compiler and decompiler to be able to compile FFI callouts > into methods when such pragmas are present. > As we now included this FFI-Examples, where this is used, I would like to find a way that works in both, pharo and squeak. @esteban is this already supported by "our" FFI and just not by the parser used for syntax highlighting or wasn't this package supposed to be in Pharo ? > > Levente > > >> >> nicolai >> >> > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Andrei Chis

On Sun, Jan 10, 2016 at 12:54 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 10-01-16 06:26, Tudor Girba wrote: > >> - 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. >> > > I would add a context menu on the > GLMPagerScrollButtonBrick with close last and > close all invisible and on each pane too > > I tried adding right click handling by adding the event to the > GLMPagerButtonAnnouncement, setting it in GLMPagerScrollButtonBrick>>click > and doing > GLMPagerButtonsPaneBrick>>onButtonClicked: ann > |event| > event := ann event. > event yellowButtonPressed ifTrue: [ > self pagerModel popPane: true ] > ifFalse: [ > self pagerModel switchPaneTo: ann buttonModel index] > > but the right click doesn't arrive, possibly because the > GLMPagerScrollSlidingBrick is intercepting it? Independent of your question now I added the close action in the toolbar of the presentation. Also to save space the navigation scrollbar only appears if you have more than three objects. Cheers, Andrei > > > Stephan > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Stephan Eggermont

On 10-01-16 06:26, Tudor Girba wrote: >> - 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. I would add a context menu on the GLMPagerScrollButtonBrick with close last and close all invisible and on each pane too I tried adding right click handling by adding the event to the GLMPagerButtonAnnouncement, setting it in GLMPagerScrollButtonBrick>>click and doing GLMPagerButtonsPaneBrick>>onButtonClicked: ann |event| event := ann event. event yellowButtonPressed ifTrue: [ self pagerModel popPane: true ] ifFalse: [ self pagerModel switchPaneTo: ann buttonModel index] but the right click doesn't arrive, possibly because the GLMPagerScrollSlidingBrick is intercepting it? Stephan

Jan. 10, 2016

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