- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] [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-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)

by David Allouche

First a disclaimer, I do not have a lot of experience with inter-process communication (I have a bit, though), and no direct experience with mmaped files. > On 17 Jan 2016, at 17:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > 1) Do you think this is possible with the current Pharo ? > > 2) Will I be limited by the fact that the VM currently does not multithread or cannot use multithreading libraries ? ( I have no intention of using multithreading but some handling of process access to the data may be necessary to make sure data is safe from concurent modification) Communication through mmaped files, or shared memory in general, is inherently asynchronous, so lack of multiple OS threads should not be a blocker if the protocol is well designed. > 3) Is there anything else I should be aware of as common pitfalls for such implementation ? I expect you would need some sort of out-of-band signalling so polling is not necessary. Pipes or sockets could be used for that, slower for data transfer (more copying), but they are compatible with select() and other OS polling features. You could build synchronisation primitives on top of sockets, too. But building things like mutexes would be inefficient. I guess you could use pipes for all the message sending and memory management, and shared memory for bulk data transfer. Large number of messages could be handled in batch this way: allocate a message area (socket round trip) fill the message area signal to process a block of messages (socket one way) optimistically check for incoming messages in shared memory wait for socket input Not very efficient for messages that depend on one another. But I am not sure you could do better without things like interprocess semaphores or a FFI. > 4) Can the current FFI help in this task or would I need to implement this as a C DLL and load it from Pharo > > PS: I have no intention of messing with the Pharo VM and I also want to avoid the use of plugins as I want this to work with standard Pharo distributions.

Jan. 17, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Tudor Girba

Hi, > On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 16-01-16 13:50, Dimitris Chloupis wrote: >>> Seems that creating forms and morph from pngs is super slow >> >> Put the forms in one fuel file and materialize that >> >> Stephan > > That is exactly what I showed him in https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-sl… That is actually a very cool idea. Thank you both :) Doru > The speedup was massive and it was so easy to do. > > But the fact remains that the PNG parser itself, being written in pure Pharo, could use a Plugin counterpart, like in the JPG case. > > Sven -- www.tudorgirba.com www.feenk.com "Sometimes the best solution is not the best solution."

Jan. 17, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Sven Van Caekenberghe

> On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 16-01-16 13:50, Dimitris Chloupis wrote: >> Seems that creating forms and morph from pngs is super slow > > Put the forms in one fuel file and materialize that > > Stephan That is exactly what I showed him in https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-sl… The speedup was massive and it was so easy to do. But the fact remains that the PNG parser itself, being written in pure Pharo, could use a Plugin counterpart, like in the JPG case. Sven

Jan. 17, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Stephan Eggermont

On 16-01-16 13:50, Dimitris Chloupis wrote: > Seems that creating forms and morph from pngs is super slow Put the forms in one fuel file and materialize that Stephan

Jan. 17, 2016

Re: [Pharo-users] [Pharo-dev] [Moose-dev] [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-users] Creation form from PNG file very slow on Pharo 4 and 5

by Stephan Eggermont

On 16-01-16 15:40, Dimitris Chloupis wrote: > I report a sever limitation and I have been told > c) that its a hardware limitation when the hardware is able to perform > light years ahead of what pharo is currently doing That is because disks can not do much more than that. If you need more speed you need to make sure the files are not on different tracks, or cached. Stephan

Jan. 17, 2016

Re: [Pharo-users] Updated Pharo by Example

by stepharo

Yes this is why I started to hate this slack interface today :) Le 17/1/16 18:44, Dimitris Chloupis a Ã©crit : > looks great I see you added the link for slack invitation that I could > not find, awesome > > On Sun, Jan 17, 2016 at 7:35 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Here is the reviewed Preface of UpdatePharoByExample. > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample > for typos... > > stef >

Jan. 17, 2016

Re: [Pharo-users] Pharo Sound does not work on Pharo 4

by Dimitris Chloupis

"Ok add it. I do not remember things (doing too many things I guess)" nah that ok I am joking of course "Ok this is good to know for 50. Did you check the " baseSoundSystem " No I did not, and I will but please note that the exact same code works fine on Pharo 5. But most likely I will migrate back to 5 at some point and will end up closing this bug report so its not a big deal for me. I dont like leaving bug reports open ;) On Sun, Jan 17, 2016 at 7:42 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 17/1/16 17:17, Dimitris Chloupis a Ã©crit : > > hehe you forget who translated this chapter from French to English, though > I cannot take most of the credit that belongs to Google translate :D > > > Ok add it. > I do not remember things (doing too many things I guess) > > > > On Sun, Jan 17, 2016 at 5:18 PM stepharo <stepharo(a)free.fr> wrote: > >> Can you check the attached pdf? >> >> >> >> >> Le 16/1/16 13:27, Dimitris Chloupis a Ã©crit : >> > even though it works fine for me in Pharo 5 (with the exception I have >> > to restart the sound player because the primitive fails at times) in >> > Pharo 4 I have no sound and no errors. Just Silence of the Lamps. >> > >> > opened bug report >> > >> > >> https://pharo.fogbugz.com/f/cases/17402/Pharo-Sound-does-not-work-on-Pharo-4 >> > >> >> >

Jan. 17, 2016

Re: [Pharo-users] Updated Pharo by Example

by Dimitris Chloupis

looks great I see you added the link for slack invitation that I could not find, awesome On Sun, Jan 17, 2016 at 7:35 PM stepharo <stepharo(a)free.fr> wrote: > Here is the reviewed Preface of UpdatePharoByExample. > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample > for typos... > > stef >

Jan. 17, 2016