- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50530 Home: https://github.com/pharo-project/pharo-core

Jan. 18, 2016

Re: [Pharo-dev] [Moose-dev] roassal2 seems to work well now

by Johan Fabry

If Esteban says there are problems, there are problems. (And he did say so.) > On Jan 17, 2016, at 22:43, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Johan? > > Does the image still crash? > > Alexandre > > >> On Jan 17, 2016, at 2:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> With the latest development, Roassal2 seems to work well. >> >> For example, the rendering of the logical view of Glamour browsers was broken, and now it works well. This is great news. >> >> <Inspector on a GLMSystemWindow(771559424).png> >> >> Is this just my impression? Do we know if there are still open issues with the FFI in this area? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 18, 2016

Re: [Pharo-dev] [Moose-dev] roassal2 seems to work well now

by Alexandre Bergel

Johan? Does the image still crash? Alexandre > On Jan 17, 2016, at 2:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > With the latest development, Roassal2 seems to work well. > > For example, the rendering of the logical view of Glamour browsers was broken, and now it works well. This is great news. > > <Inspector on a GLMSystemWindow(771559424).png> > > Is this just my impression? Do we know if there are still open issues with the FFI in this area? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 18, 2016

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

by Nicolai Hess

2016-01-17 22:09 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Jan 17, 2016, at 7:56 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > [â¦] > > > > - 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 inspector and instvars : list methods storing into/using > > > > Ok. Thanks. Fixed. > > Thanks Doru, I commented on the bug report. Will this be included in the (left most) inspector pane in the debugger? (this is difficult to use in the "State"-pane, because as soon as you try to bring up the popup-menu, the pane "slides away"). nicolai > -- > www.tudorgirba.com > www.feenk.com > > "To utilize feedback, you first have to acquire it." > > >

Jan. 17, 2016

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

by Tudor Girba

Hi, > On Jan 17, 2016, at 7:56 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > [â¦] > > - 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 inspector and instvars : list methods storing into/using > Ok. Thanks. Fixed. > [â¦] > > (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. We have now moved the accept and cancel to the contextual menu for now. However, the longer term goal is to change this pattern. Here is a longer explanation. We think of the IDE like terms an object-oriented system built using a language. From this point of view, an action is put in the context that provides enough information to trigger it. So, for actions that do not rely on the selection, or on the cursor position, we can safely put them in the toolbar of the presentation. For global actions (like refreshing the whole inspector), we put them all the way in the title bar. For example: - "Do Itâ depends on the selection or cursor, and thus it is added to the context menu - âAccept" is not specific to the current location of the cursor or of the selection and can be made presentation specific (added to the toolbar of the presentation). - Switching the whole debugger to a âBytecodeâ one is global for the whole debugger, and it is added to the top of the visual hierarchy. This choice also documents the scope of an action. For example, imagine having a global toolbar with actions that only do something in a certain pane (out of possible many). How will you know before triggering what is the effect going to be? But, if you always put the action to the scope that it affects, there is a more clear connection because cause and effect. And there is yet another advantage. When you stick with this design, you get potentially reusable components. This does require some getting used to. And this design will not necessarily work for general UIs. But, an IDE is not a general UI. It is made for programmers, and in our case, it is made for object-oriented programmers, and we can use the abilities of such programmers in our designs. Does this explanation make more sense? Cheers, Doru -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."

Jan. 17, 2016

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

by Eliot Miranda

On Sun, Jan 17, 2016 at 12:13 PM, stephane ducasse < stephane.ducasse(a)gmail.com> wrote: > > > On 17 Jan 2016, at 18:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > So this year I hope we will have an excellent high performance FFI. > > > this will be an exciting year. > BTW when ronie will arrive here we will plan some skype session with you. > Yes, if we're to pull this off we have all to be working with a coherent shared plan and to keep in communication. This is exciting. I've been dreaming of this FFI for a while now :-). _,,,^..^,,,_ best, Eliot

Jan. 17, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by David Allouche

> On 17 Jan 2016, at 16:52, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Jan 17, 2016, at 1:18 PM, David Allouche <david(a)allouche.net> wrote: >> >> Cool. While you are there, could provide a way to separate instance variables from local variables (and class shared variables too, maybe)? >> It could be different columns, filtering, tabs, I do not really care. Currently, when debugging classes with lots of instance variables (like morphic stuff) it's quite painful to find the one local variable of interest. > > > The tags to the left of each variable can be used to filter the list of variables. Nice, but: It's not an obvious, standard UI behaviour In a complex class, you still need to hunt through the list to find the first local variable, that's frustrating. You cannot even use incremental search there. That should probably be a wishlist item on the bug tracker. > >> Also, could the scroll position in the variable be preserved while stepping? > > I am not sure what you refer to. The currently selected variable is preserved both when you step, and it is even preserved when you switch back and forth through the stack. > > What am I missing? The selected variable is preserved, but if ones scroll the variable list using the mouse wheel, the scroll position changes but not the selection. Stepping resets the scroll position to show the selected variable, which is "self" by default. I would like the scroll position for the variable list to be remembered by the debugger in each object. Or maybe the right granularity is concrete class, I am not sure. >> Unfortunately, Pharo does not appear to receive ctrl-tab keydown events, so I need to reach for the mouse to move the focus out of any text areaâ¦ > > Indeed, this does not work. I already reported that before on the mailing list, and I have tracked it down to ctrl-tab keydown not even reaching Sensor. The corresponding keyup are correctly detected. So I guess it might be a vm issue. I should probably file a proper bug report.

Jan. 17, 2016

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