- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] new debugger shortcuts

by David Allouche

> On 17 Jan 2016, at 17:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > The existing debugger shortcuts are conflicting with code editing shortcuts. > > Now, I defined the following shortcuts: > resume - cmd + r > restart - cmd + shift + a > over - cmd + shift + o > through - cmd + shift + t > into - cmd + e > > There is also a test in GT that checks for double meanings. Please let me know if you see problems with these, and comment on the issue here: > https://pharo.fogbugz.com/f/cases/17408/The-generic-stack-debugger-defines-… > > We want to integrate this as soon as possible, so please react as soon as you can :) I posted a comment on the bug. Summary: nice, simple Fn key bindings would be even better.

Jan. 17, 2016

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

by Nicolai Hess

2016-01-15 13:39 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Thanks indeed for the feedback. I think not quite all are bugs, but see > more details inside. > > > > On Jan 14, 2016, at 12:59 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > Hi Nicolai, > > > > Thanks for reporting these issues. They are indeed bugs and we are > working on fixing them. > > > > Cheers, > > Andrei > > > > On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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. > > > > Accept and Cancel buttons shouldn't be there > > or should not act on if the codepane hasn't changed. > > (every press on "accept" writes a new method version, although the > contents didn't changed - tested on > > Latest update: #50524 ) > > Good catch. This will happen even if the button would not be present. > > > > Most (all?) other tools don't have Accept/Cancel buttons. > > The logic is that these are actions that do not depend on the selection, > so in Glamour we map these on actions that are applicable to the entire > presentation. A similar approach is present in the inspector, although > probably it does not appear so prominently because there is no text. We > could try to add them in a dropdown menu. Would that help? > > > > - I really miss the "List Methods using 'varname'/List Methods storing > into âvarname' > > Please open an issue for this. > This issue is one year old: 14583 <https://pharo.fogbugz.com/f/cases/14583/inspector-and-instvars-list-methods…> inspector and instvars : list methods storing into/using > > > > - is "stackTop" now gone ? I thought you wanted to add it to the stack ? > > - thisContext is gone as well ? > > These were removed due to emergency mail exchange that happened during the > last weekend. > > > > - the Bytecode/GT button is badly placed, it looks like the "downarrow" > window menu icon > > is a dropdown menu with label âBytecode" > > We could try to fix by adding more space to the left of the menu bar in > the theme. Could you open an issue? > > > > (since when do we put buttons in the title pane? > > Since Glamour makes it easy to have them there :). The GTPlayground and > GTInspector have them, too. > still I don't think this is a good idea. What is the difference between action buttons in the title pane and the other one. > > > > - the evaluator pane is shown as "dirty", as it does not make a > difference if we > > accept the text in this pane, there shouldn't be a dirty indicator. > > This is a problem that seems to exist with basically every pharoScript in > Glamour. You commented on an issue for this: > > https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-al… Yes this is working nwo in 3.8. > > > > > > - you can not use the inspector pane to change inst var values > > This is a problem but it is not specific to the debugger. > > > > - there is no way to refresh the inspector pane > > Indeed. Would it be enough if we added a refresh for the whole debugger? > I don't know if there is an easy solution. But it was nice in the old debugger resp. inspector pane to have auto-updates for this values. > > Cheers, > Doru > > > > I don't open bugtracker entries now, I 'll wait maybe this issues aren't > bugs but > > features. > > > > > > nicolai > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > >

Jan. 17, 2016

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

by Thierry Goubier

Le 17/01/2016 15:47, Eliot Miranda a Ã©crit : > Hi Thierry, > >> On Jan 17, 2016, at 6:10 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Hi Eliot, >> >> I still don't understand why this platform-specific data (external >> datatypes sizes, constants values) has to be written as a json >> file and not as Smalltalk code ? > > It can be any notation that is easy to parse. One could use pure > Smalltalk, json, ston, xml. I thought ston /was/ a form of Smalltalk > aimed at representing key/value pairs, in which case it seems ideal. > > What are the objectives for this notation? My take (feel free to > suggest a better set) is: > > a) be quick to parse since these files are parsed on start-up when > the platform is different from that the image was snapshot red on > > b) be human readable. The flexibility of being able to version, edit, > search and diff these files seems useful > > c) be reasonably straight-forward to generate from C. But hey, it's > only code :-) Agreed to all points, of course :) I do think b and a; c is ok. >> If I write an interface to an external lib, I'd like to benefit >> from nice access to Smalltalk code to, say, test versions of the >> external libraries, set external types based on system information, >> etc, etc... instead of having to deal with all those various json >> files outside my normal workflow. >> >> Okay, I can write smalltalk code which runs those C tests programs, >> extract their output, model them in smalltalk and generate the >> jsons from there... but, then, I really don't understand why I have >> to write those jsons then every user loads those jsons instead of >> just running that setup code I have in my external library >> smalltalk support package ? > > You /don't/ have to write them ever. They are written for you by the > FFI shared pool. Yes, that was understood. > So you're suggesting the C program output a Smalltalk method that > looks like:e.g. > > initializeMYSQLMac32 MYSQL_ENABLE_CLEARTEXT_PLUGIN := 123. > MYSQL_INIT_COMMAND := 234. MYSQL_OPT_BIND := 345 > > So the trade off you're discussing is whether it is valuable to keep > these in the image or not. For me these initialize toon methods are > overhead. They get parsed as infrequently as possible. So personally > I prefer to use several external files that are parsed infrequently > instead of the overhead of several initialization methods that are > run infrequently. > > For example, if I were deploying on some embedded arm device, the > initialization method would be something I'd have to strip from the > image. Seems easier to just parse an external file to me. Well, for me, on a pure technical basis, no. - It adds one failure point: reading one more file at startup. - It adds management issues: slight version differences in an external libs may force me to add context-dependent json file loading. > I like the use of Smalltalk for eg user interface opening code where > - we want a UI construction tool to edit an e excitable > representation of the interface - there is only one version of the UI > method > > But with these interface descriptions we could easily end up with a > 32-bit and a 64-bit version for every UNIX variant plus Mac OS and > Windows. You could easily have ten long methods with overheads in > the tens of kilobytes. Seems a waste to me. No really. You have the same complexity, either in a json or in an init file; and the same level of customization or even more flexibility (you can decide to set those initialisation methods in different packages, and have the flexibility to slice / share the way you like... 64bits / 32bits, 64bits ARM + MIPS are the same except one constant, etc...). It's a bit like dealing with those configure scripts: in C, if you really want multiplatform support, you write #ifdef macros and shell scripts to query the build platform for you... I just prefer to do it in Smalltalk if I have to. But I guess that I could still do it by hacking the FFI layer anyway :) And I'd be happy to see a system modeling layer in Smalltalk (one which knows how to query hardware/software capabilities at startup) since it opens up yet unforeseen possibilities (switching on an OpenCL acceleration layer on supported platforms with the right driver version?). Thierry

Jan. 17, 2016

Re: [Pharo-dev] Seeing class method template when there is no protocol

by Nicolai Hess

2016-01-17 12:42 GMT+01:00 stepharo <stepharo(a)free.fr>: > HI > > yesterday during my exercise session a student was puzzled because > he could not see the method template on the class side when there is not > protocol. > I had to create first a protocol. > But you can always select the "no messages" protocol entry to show up the method template. I think it was always like that. > > I do not have the solution because I understand why it is like that. > Because Nautilus displays > the class definition first and when we click on protocol the template. > But I would be interested to see if there is an alternative. > > Stef > >

Jan. 17, 2016

Re: [Pharo-dev] Seeing class method template when there is no protocol

by Sven Van Caekenberghe

> On 17 Jan 2016, at 18:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > well, I disagree :) > >> On 17 Jan 2016, at 17:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 17 Jan 2016, at 17:13, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> Le 17/1/16 16:09, Sven Van Caekenberghe a Ã©crit : >>>>> On 17 Jan 2016, at 15:52, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>>> >>>>> Maybe add a "New Method" button somewhere that changes the class definition with a method template ? >>>> But only when it is needed. >>>> >>>> The overall Nautilus interface is becoming way too busy and distracting. >>> >>> Where? >>> Because we removed features so I'm surprised and we wanted to remove more >>> but people use them. >> >> Let see (this is my personal opinion, not necessarily the most beginner friendly view): >> >> <Screen Shot 2016-01-17 at 17.39.34.png> >> >> - I never use the history navigator, not the drop down, nor the arrows >> - The previous location of variables was better (small icon) >> - I never use the weird search/filter field with the pattern >> - I never use scoped browsing >> - I never use format as you read >> - I never want line numbers >> - I never want to know where the cursor is >> - I only want critics when I say so, not all the time > > - I never use history navigator neither > - I like variables where they are now :) > - I use âweirdâ search/filter all the time > - I use very often scoped browsing (I do a lot of refactors) > - I do not use format as you read neither, but I like to have it thereâ¦ can be useful. > - line numbers I do not care, but that space will be useful for breakpoints/etc. > - I need to know where cursor is, or at least I feel myself more confident when I know. > - I not only want critics *always*: I also want critics always for everybody: I spotted many bugs I could made just for having them thereâ¦ and in particular newbies can find them useful :) > >> >> Again, this is my POV. And I definitively still want to have these features around, I just don't want to *see* them all the time. > > And these are mineâ¦ :P > Thatâs why we should not take *our* convenience as a model (we can, after all modify a lot of that just with settings or ignoring them :P) > > In my own feedback, Nautilus (and the IDE in general) has become a lot more attractive to newcomers now, and the visual contamination (again, as far as Iâve been told by newbies and students, etc.) is not that. Quite the contrary they feel it as âreassuringâ (because it resembles a bit more what they know from other IDEs). > > My idea is that newbies will welcome to see them all the time, and we (power users) can disable what we do not want in settings (and we can have a preference with our ownâ¦ preferences :P. > Is the same I do about Dark Theme for example: I activate it always by default. > Or with the Growl notifications: I hate them in bottom-left corner, I would prefer it in top-rightâ¦ or bottom rightâ¦ then I just change it :) > > So +1 enhance configurability of the system, -100 to remove/hide features that are important specially for newbies. Like I said, it is my POV, I don't want to convince anybody else, that is why I did not say anything earlier. But, not all the things that I want are preferences now, ... Pharo should not only cater to beginners, or try to mimic other bloated IDE's like Eclipse or IntelliJ. Pharo is yours also means it should fit proficient users. > cheers, > Esteban > >> >> Spotter gets me to classes & methods, the rest is command-click and short cuts. >> >>> Stef >>> >>>> >>>>> On Sun, Jan 17, 2016 at 8:42 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> HI >>>>> >>>>> yesterday during my exercise session a student was puzzled because >>>>> he could not see the method template on the class side when there is not protocol. >>>>> I had to create first a protocol. >>>>> >>>>> I do not have the solution because I understand why it is like that. Because Nautilus displays >>>>> the class definition first and when we click on protocol the template. >>>>> But I would be interested to see if there is an alternative. >>>>> >>>>> Stef

Jan. 17, 2016

Re: [Pharo-dev] Why there is no setting to disable QA?

by Dimitris Chloupis

you are the boss... go for it and anywhere I can help I am here. I want Pharo to succeed :) On Sun, Jan 17, 2016 at 7:48 PM stepharo <stepharo(a)free.fr> wrote: > > > Seriously though its not that necessary to baby sit begineers, the > important thing for a beginner is to love coding. I remember when I started > I would have begged to have an IDE like Pharo and a language like pharo, > instead all I had was Locomotive Basic, command line and a really badly > written and even worse translated book. I would have begged for code > critics . > > Not for the first class :) > > > An IDE that tells me what I do wrong ? Are you serious ? It would have > been sci fiction in 1988. > > :) but now there is eclipse. > > Did I hate coding ? No > > Seriously who expectes coding to be easy at start.... only lazy and naive > people. Neither make good coders anyway. I think with your passion about > coding and the great design of Pharo as an IDE it will be hard not to fall > in love with coding. All begineer hand is friendly hand to point them > towards the right direction, just some reassurance that they do things > right and that their mind is on the right path. > > A side note, I am a bit sceptical for your decision to go down the Pharo 5 > route, are we sure Pharo 5 will be stable enough for a begineer to use in > the time of the MOOC ? > > WE MUST MAKE IT STABLE BY THEN! > We should release often and stable. > And Pharo 50 should be. Because after we have Pharo 6.0 and I want Xtreams > and Bloc > > > > Esteban already fixed most of my problems with pharo 5, I am actually > closing my bug reports now, but still it seems to me a bit risky and maybe > it puts unnecessary pressure on Esteban and the Moose people. > > I any case I wish you success with MOOC :) > > On Sun, Jan 17, 2016 at 7:27 PM stepharo <stepharo(a)free.fr> wrote: > >> Ok I'm wrong and stupid. >> Thanks for the reminder. >> I disabled QA in the Mooc images. >> >> > Thatâs the point. Someone finds this disruptive, someone instructing. >> But itâs always a true information. So here we are not dealing with the >> faults of algorithm but with a way we are communicating a data with a user. >> > >> > Thatâs why I kindly ask not to call this things âfalse positivesâ :). >> > I thinks that it makes sense to be bale to disable some critics by >> their severity. >> > >> > Also I think that itâs a good thing to teach beginners to write class >> comments. You donât need special skills for that and making it a habit from >> the beginning will payoff in the future. >> > >> > Cheers. >> > Uko >> > >> > >> > >> > >> >> On 17 Jan 2016, at 16:11, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> >> wrote: >> >> >> >> Le 17/01/2016 16:04, stepharo a Ã©crit : >> >>> We have also >> >>> instance variables not written or read >> >>> class comment is empty >> >>> >> >>> And I find that disruptive for a student starting with Pharo. >> >>> >> >> I find that instructing. >> >> When I create a class and I see those messages it's like "objectives". >> I >> >> need to correct that and it help me not to avoid the documentation. >> >> >> >> -- >> >> Cyril Ferlicot >> >> >> >> http://www.synectique.eu >> >> >> >> 165 Avenue Bretagne >> >> Lille 59000 France >> >> >> > >> > >> >> >> >

Jan. 17, 2016

Re: [Pharo-dev] Why there is no setting to disable QA?

by stepharo

> > Seriously though its not that necessary to baby sit begineers, the > important thing for a beginner is to love coding. I remember when I > started I would have begged to have an IDE like Pharo and a language > like pharo, instead all I had was Locomotive Basic, command line and a > really badly written and even worse translated book. I would have > begged for code critics . Not for the first class :) > An IDE that tells me what I do wrong ? Are you serious ? It would have > been sci fiction in 1988. :) but now there is eclipse. > Did I hate coding ? No > > Seriously who expectes coding to be easy at start.... only lazy and > naive people. Neither make good coders anyway. I think with your > passion about coding and the great design of Pharo as an IDE it will > be hard not to fall in love with coding. All begineer hand is friendly > hand to point them towards the right direction, just some reassurance > that they do things right and that their mind is on the right path. > > A side note, I am a bit sceptical for your decision to go down the > Pharo 5 route, are we sure Pharo 5 will be stable enough for a > begineer to use in the time of the MOOC ? WE MUST MAKE IT STABLE BY THEN! We should release often and stable. And Pharo 50 should be. Because after we have Pharo 6.0 and I want Xtreams and Bloc > Esteban already fixed most of my problems with pharo 5, I am actually > closing my bug reports now, but still it seems to me a bit risky and > maybe it puts unnecessary pressure on Esteban and the Moose people. > > I any case I wish you success with MOOC :) > > On Sun, Jan 17, 2016 at 7:27 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Ok I'm wrong and stupid. > Thanks for the reminder. > I disabled QA in the Mooc images. > > > Thatâs the point. Someone finds this disruptive, someone > instructing. But itâs always a true information. So here we are > not dealing with the faults of algorithm but with a way we are > communicating a data with a user. > > > > Thatâs why I kindly ask not to call this things âfalse > positivesâ :). > > I thinks that it makes sense to be bale to disable some critics > by their severity. > > > > Also I think that itâs a good thing to teach beginners to write > class comments. You donât need special skills for that and making > it a habit from the beginning will payoff in the future. > > > > Cheers. > > Uko > > > > > > > > > >> On 17 Jan 2016, at 16:11, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > >> > >> Le 17/01/2016 16:04, stepharo a Ã©crit : > >>> We have also > >>> instance variables not written or read > >>> class comment is empty > >>> > >>> And I find that disruptive for a student starting with Pharo. > >>> > >> I find that instructing. > >> When I create a class and I see those messages it's like > "objectives". I > >> need to correct that and it help me not to avoid the documentation. > >> > >> -- > >> Cyril Ferlicot > >> > >> http://www.synectique.eu > >> > >> 165 Avenue Bretagne > >> Lille 59000 France > >> > > > > > >

Jan. 17, 2016

Re: [Pharo-dev] Why there is no setting to disable QA?

by stepharo

>>> On Jan 17, 2016, at 9:06 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Thatâs the point. Someone finds this disruptive, someone instructing. But itâs always a true information. So here we are not dealing with the faults of algorithm but with a way we are communicating a data with a user. >>> >>> Thatâs why I kindly ask not to call this things âfalse positivesâ :). >>> I thinks that it makes sense to be bale to disable some critics by their severity. >>> >>> Also I think that itâs a good thing to teach beginners to write class comments. You donât need special skills for that and making it a habit from the beginning will payoff in the future. >> +1000! > +1 me too. > I remember when Stef introduced the mark on uncomment classes I was against: I was finding the exclamation mark too disruptive. Then time proved me wrong: is a nice way to remember people they need to add class comments (and my own production of comments increased considerably). ;D > I think QA will do the same: it might look disruptive, but is educative in fact. Yes but you see when this is really first first first class you write in Pharo.... So I want everybody to have QA on! and to fix them! And I want more rules I want specific rules for everything every frameworks but not on the first class a newbie is writing. People should remember when is the last time they defined a class for the first time. I did Python exercises with my son and it was in plain text editor and it was working. Stef

Jan. 17, 2016

Re: [Pharo-dev] new debugger shortcuts

by Francisco Ortiz PeÃ±aloza

I almost forgot, can we've a "create" shortcut? Regards On Sunday, 17 January 2016, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com> wrote: > +1000! Thank youuuu! > > On Sunday, 17 January 2016, Tudor Girba <tudor(a)tudorgirba.com > <javascript:_e(%7B%7D,'cvml','tudor(a)tudorgirba.com');>> wrote: > >> Hi, >> >> The existing debugger shortcuts are conflicting with code editing >> shortcuts. >> >> Now, I defined the following shortcuts: >> resume - cmd + r >> restart - cmd + shift + a >> over - cmd + shift + o >> through - cmd + shift + t >> into - cmd + e >> >> There is also a test in GT that checks for double meanings. Please let me >> know if you see problems with these, and comment on the issue here: >> >> https://pharo.fogbugz.com/f/cases/17408/The-generic-stack-debugger-defines-… >> >> We want to integrate this as soon as possible, so please react as soon as >> you can :) >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "When people care, great things can happen." >> >> >> >> >> >>

Jan. 17, 2016

Re: [Pharo-dev] Why there is no setting to disable QA?

by Dimitris Chloupis

We all hate you Stef , its not you , its us :D Seriously though its not that necessary to baby sit begineers, the important thing for a beginner is to love coding. I remember when I started I would have begged to have an IDE like Pharo and a language like pharo, instead all I had was Locomotive Basic, command line and a really badly written and even worse translated book. I would have begged for code critics . An IDE that tells me what I do wrong ? Are you serious ? It would have been sci fiction in 1988. Did I hate coding ? No Seriously who expectes coding to be easy at start.... only lazy and naive people. Neither make good coders anyway. I think with your passion about coding and the great design of Pharo as an IDE it will be hard not to fall in love with coding. All begineer hand is friendly hand to point them towards the right direction, just some reassurance that they do things right and that their mind is on the right path. A side note, I am a bit sceptical for your decision to go down the Pharo 5 route, are we sure Pharo 5 will be stable enough for a begineer to use in the time of the MOOC ? Esteban already fixed most of my problems with pharo 5, I am actually closing my bug reports now, but still it seems to me a bit risky and maybe it puts unnecessary pressure on Esteban and the Moose people. I any case I wish you success with MOOC :) On Sun, Jan 17, 2016 at 7:27 PM stepharo <stepharo(a)free.fr> wrote: > Ok I'm wrong and stupid. > Thanks for the reminder. > I disabled QA in the Mooc images. > > > Thatâs the point. Someone finds this disruptive, someone instructing. > But itâs always a true information. So here we are not dealing with the > faults of algorithm but with a way we are communicating a data with a user. > > > > Thatâs why I kindly ask not to call this things âfalse positivesâ :). > > I thinks that it makes sense to be bale to disable some critics by their > severity. > > > > Also I think that itâs a good thing to teach beginners to write class > comments. You donât need special skills for that and making it a habit from > the beginning will payoff in the future. > > > > Cheers. > > Uko > > > > > > > > > >> On 17 Jan 2016, at 16:11, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: > >> > >> Le 17/01/2016 16:04, stepharo a Ã©crit : > >>> We have also > >>> instance variables not written or read > >>> class comment is empty > >>> > >>> And I find that disruptive for a student starting with Pharo. > >>> > >> I find that instructing. > >> When I create a class and I see those messages it's like "objectives". I > >> need to correct that and it help me not to avoid the documentation. > >> > >> -- > >> Cyril Ferlicot > >> > >> http://www.synectique.eu > >> > >> 165 Avenue Bretagne > >> Lille 59000 France > >> > > > > > > >

Jan. 17, 2016