- Pharo-dev - lists.pharo.org

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

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