- Pharo-dev - lists.pharo.org

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

by stepharo

> I use both thisContext and stackTop regularly. thisContext maybe once a wee, stackTop probably multiple times a day. > So explain to me how? Stef

Jan. 10, 2016

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

by stepharo

Le 10/1/16 10:26, HernÃ¡n Morales Durand a Ã©crit : > 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. The pharo board decided that it was ok. But I never thought it would be the default one. Now I find this process obscure and I'm not part of the board so I do not care. Stef

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

Hi Stef, > On Jan 10, 2016, at 10:21 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi doru > > you see I make the effort to reply even if I get really frustrated with our tools. Thank you. First, let me say that I was not arguing at all. I was looking for solutions. The way I know to do it is to make explicit the reasonings that we already went through so that others can poke holes at it. I also wanted to say that the choice was not random, but maybe we can find a better choice. > I do not get why you cannot > - have a set of fixed most used queries and this will create a small vocabulary that can be extensible > and it can be mapped to what we do with shortcuts = reduce cognitive load > and then a full search when you do not know what you are searching. > This is not exclusive and it works for the two scenario. I understand the intention, but I do not understand how these fixed queries are any different than we have now. When you are on the top of Spotter, when you query, you get always the same processors being executed. At first you will not know their names, and you will scroll. And if you see them, you might remember them and reproduce afterwards. Itâs a discoverable learning process that you do not have to remember. The only part that is not discoverable is that # introduces a category search. Thinking loud, I just thought that we can make the label start with # like this (I committed this change): We also thought of having completion as soon as someone type #. So, you have a kind of a dropdown for the available categories, but we did not get to implement that one. This should solve the discoverability problem even more. What do you think about that? Regarding the shortcuts, we could associated such shortcuts with a processor, but I would first want to see if we cannot manage to produce a solution with the current set of options. > I was discussing with Luc and he made a fun but sad remark > "Since people do not understand well spotter they most of the time only use it to open a class. > And this is something that he already had before." > I briefly looked at the Youtube video of Chloupis and > So you can have a generic super cool tool, if people do not use it it defeats its purpose. Certainly. > You can be really happy because you go fast with it but you only. That is not really true :). > So making sure that the most used actions are really supported is important. Of course it is. For Senders we did not find a good solution yet that is reasonably fast and useful. Stefan and I are still literally working on this. I think we should be able to have a solution, but we have to see if it is reasonable enough. We will announce it once we have it working. But, really, this tool more than anything allows one to play with possibilities in a couple of lines of code. We want people to play (some did) and to get concrete feedback and possible solutions. I think we should not just say that we need something else before we actually play with it a bit more. > But more important the discoverability is important because there is not even a help. > Right now as a user I can only guess and often I close spotter and use my shortcuts. > As a user I see something that ask me about network (and I do not care) but nothing > that brings me to the next level. This is something we need to work on, but you know, time is limited for us, too. > Most of the time the user forgets the key combination (may be this will be solved with > the cool shortcut reminder we developed and is under review) All actions in spotter have a visible icon. All. And if you hover over it you get the command. And there are literally 5 such actions. What is missing in this regard from your point of view? Doru > Stef > > > > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Yes this is my point > >> On Jan 9, 2016, at 3:29 PM, Christophe Demarey >> <christophe.demarey(a)inria.fr >> <mailto:christophe.demarey@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. >

Jan. 10, 2016

How to get launcher launching Spur images?

by stepharo

Hi I changed the setting to be the following but I cannot get a spur image started on mac. Does anybody succeed? Stef

Jan. 10, 2016

Re: [Pharo-dev] [Vm-dev] Differentiate ProcessList and LinkedList - incomplete

by David T. Lewis

On Sat, Jan 09, 2016 at 05:40:09PM +0800, Ben Coman wrote: > > LinkedList is a generic concept but historically has been intimately > coupled to Process scheduling. While trying to make LinkedList API > more generic, Pharo inadvertently introduced some problems with > Processes, so we decided to copy LinkedList to ProcessList so this can > remain specialised for Process scheduling, allowing LinkedList the > opportunity to be more generic. > > Here is some history at fogbugz.pharo.com: > Background... > Case 5602 "LinkedList at: index putLink: aLink" > Case 10273 "Cleaning Linked List API" > Changes... > Case 15868 "Differentiate ProcessList and LinkedList" > Case 15871 "enable ProcessList" > Case 17277 "newSpecialObjectsArray should return a process list > instead of a linked list at item 41" > > Semaphore rather intimately manipulates the process list, but it seems > to have been missed as it still inherits from LinkedList. Should it > subclass ProcessList instead? Based on the logic I see in #primitiveResume, I would expect that your Semaphore class would need to inherit from ProcessList. You may also need to update something in the special objects array (but that would not affect the VM). > > I guess FreeTypeCacheLinkedList and Stack can remain where they are. > > > So also a question for the Squeak, Cuis & Newspeak communities... > There are various references to LinkedList in the VM [1]. Currently > only in comments but there are hints down the track there could be > more direct use. So I am wondering how these groups would feel about > aligning with Pharo on this change, so the comments in the VM can be > updated accordingly? > > cheers -ben > > [1] https://git.io/vuQQk Eliot may have more to say on this, but it looks to me like you are basically just giving a different name to the linked list class that will be used for process scheduling. I guess we could update some of those comments in the VM classes, but I don't think it's a big issue one way or the other. Dave

Jan. 10, 2016

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

by Eliot Miranda

Hi Nicolai, On Sun, Jan 10, 2016 at 3:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" is > nil > > > is this valid pragma syntax: > > <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> > As others have said this is not a valid pragma. A valid pragma is a message expression (a message with no receiver) that has only literal arguments. There is one exception, to accept a variable name for the error code in a primitive invocation. And as Levente has said it is a goal of the new FFI to get rid of the old syntax you show above. And as Igor Stasenko discovered /any/ C signature can be written as a literal Array, providing we allow underscores in Symbols (which is a preference). So for example, the heapsort declaration from the standard C library: int heapsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *)) could be written as a pragma via e.g. <ffiCCall: #(int heapsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *)))> in which case it is equal to <ffiCCall: #(#int #heapsort #( #void #* #base #, #size_t #nel #, #size_t #width #, #int #( #* #compar ) #( #const #void #*, #const #void #*)))> which, while a massive hack, is pretty neat. The only difficulty in parsing the above s that void *, is #void #*, not #void #* #,. So for me, the natural pragma syntax for the new FFI should be a single keyword starting with ffi that includes the language with which to parse the pragma's argument, followed by a literal Array containing the signature (rather than e.g. a String). I'd also provide a special-purpose pretty-printer for literal arrays that would be used to pretty-print the above, e.g. when decompiling. This would easily allow extensions such as <ffiCcall: #(wchar_t * wcschr(const wchar_t *s, wchar_t c)) arg1is: #UnicodeString arg2is: Character> to guide a marshalling engine in providing automatic checks and conversions. [Slightly OT] Note that I'm already using this syntax in Alien callbacks because one thing it does is to normalize the signature, eliminating the significance of most whitespace (the #*, above being one example where it fails). So a Callback for heapsort above looks like voidstarvoidstarRetint: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *)) abi: #IA32> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5))) or voidstarvoidstarRetintARM32: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *)) abi: #ARM32> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien registerAt: 1)) value: (Alien forPointer: (spAlien registerAt: 2))) Hmmm, if Callback had subclasses for each ABI then the above would become IA32Callback methods for signature voidstarvoidstarRetint: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *))> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5))) ARM32Callback methods for signatures voidstarvoidstarRetint: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *))> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien registerAt: 1)) value: (Alien forPointer: (spAlien registerAt: 2))) Much nicer. I shall make it so. 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 > _,,,^..^,,,_ best, Eliot

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 10, 2016, at 10:51 AM, stepharo <stepharo(a)free.fr> wrote: > > - 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 As Mariano said, there is one already. > - 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. Please, letâs be reasonable. This is a contextual action, and it is not at all unreasonable to have it as a contextual menu. > - I found the icon on the right (the right mo You did not finish this one. > When do you think that the new debugger could be stable. What is needed from your point of view except from the labels on the buttons? > Because we can try to see if we can change the lectures and change the screenshots but first > we should finish the other ones. Thank you for wanting to find a solution. Cheers, Doru > 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: >> >> <Mail Attachment.png> >> >> >> 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> 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 >> www.feenk.com >> >> "It's not how it is, it is how we see it." >> > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 10, 2016, at 11:58 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 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 :) Tell me about risky :). But, I was not arguing. I just said why we chose to add it where it is. However, in Glamour the rule is that we have global actions as buttons, and contextual ones as contextual menus. This is used consistently in the inspector and playground, and it can be used as consistently to the debugger as well :). > 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. I am convinced it is the habits. Just consider this. The contextual menus of the spec debugger have several dozen actions. Also, the previous inspector had no visual actions. You see, if we would have such a strong set of design principles, we would have seen it. One goal with GT is to provide a small set of conventions that you can learn. They are clearly not the best, but once they are adopted in every tool, it should be better than the current state of affairs. And then we can iterate, but my stand is that we first have to reach a uniform enough situation. Anyway, I do not want to have a religious debate. But, I also think that if we impose the condition that new things should be exactly like the old ones we have a high chance of staying the same forever :). Cheers, Doru > > > <Untitled.png> > > > 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." > > -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Mariano Martinez Peck

On Sun, Jan 10, 2016 at 5:51 AM, stepharo <stepharo(a)free.fr> wrote: > - 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 > > There is a setting for this which allows you to disable it. Maybe we should disable it by default (thought I would enable it for myself) > - 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> 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 > www.feenk.com > > "It's not how it is, it is how we see it." > > > -- Mariano http://marianopeck.wordpress.com

Jan. 10, 2016