- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Le 9/1/16 11:02, Esteban Lorenzano a Ã©crit : > you have to confess that with text and icons looks a lot better than > the old one :P you mean both old ones GT and Spec. I hated the the GT icons because I was forced to wait for the fly by help I hate this interfaces that looks nice but are not efficient. > >> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> 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 >>> <mailto:estebanlm@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 >>>> <mailto:stepharo@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"? >>>>> >>>> >>>> >>> >> >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by Dimitris Chloupis

why it has to check for version conflicts ? once I tell pharo to install a package thats what I want it to do. Is this practice really necessary ? On Sat, Jan 9, 2016 at 2:58 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > it is a combination of 2 things: the repo must 1st be defined and used by > a package, then there is this odd behaviour of checking all repos for > version conflicts. > > so it depends on what you have loaded. > > > On 09 Jan 2016, at 12:34, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > eeeehhh that was happening forever at least the last 2 years I am > around. How come you guys just noticed ? > > > > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I saw that too, I choked in my coffee ;-) > > > > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > > > > > may be I'm dreaming this morning but when I saved code in the inbox I > saw a query to www.squeaksource.com? > > > > > > Stef > > > > > > > > > >

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Le 9/1/16 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): And text. I asked that during two years in GT but I was told it was not possible. Like that I do not have to learn these icons What is the Where is? > > > > would that be aceptable for you? > > cheers! > Esteban > >> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@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 >>> <mailto:stepharo@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"? >>>> >>> >>> >> >

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Why do we need an ugly Stack pane with all the buttons on the right? Le 9/1/16 09:43, Esteban Lorenzano a Ã©crit : > (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: > > > (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 >> <mailto:stepharo@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"? >>> >> >> >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by stepharo

may be because we are slow :) Le 9/1/16 12:34, Dimitris Chloupis a Ã©crit : > eeeehhh that was happening forever at least the last 2 years I am > around. How come you guys just noticed ? > > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > I saw that too, I choked in my coffee ;-) > > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > may be I'm dreaming this morning but when I saved code in the > inbox I saw a query to www.squeaksource.com > <http://www.squeaksource.com>? > > > > Stef > > > >

Jan. 9, 2016

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by stepharo

Le 9/1/16 11:15, Tudor Girba a Ã©crit : > Hi, > > This issue is still pending: > https://pharo.fogbugz.com/f/cases/7077/LayoutFrame-refactoring > > Let us fix the Glamour issues and then we can deprecate it. Yes please. I should said that I was discouraged when I saw Glamour code but this is easy to fix. There is one spec left and we can be done. I fixed the paginated I do not what. > > Cheers, > Doru > > >> On Jan 9, 2016, at 11:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Stef, >> >> could you deprecate the use of fractions:offsets: ? It's a nice way of shooting oneself in the foot. >> >> Create a LayoutFrame taking all space: >> >> LayoutFrame fractions: (0@0 corner: 1@1) >> >> right? >> >> Create a layout frame taking all space with an inset of three, so an offset of +3 left and above, and -3 right and bottom: >> >> LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) >> >> Fail! >> >> See what I mean? You have to forbid the use of a rectangle for offsets! >> >> (Note: I think the easiest API is the one used by Spec and Morphic: Rectangle asLayoutFrame topOffset: / bottomOffset ...) >> >> Thierry >> >> Le 09/01/2016 09:56, stepharo a Ã©crit : >>> Here is the new class comments I'm trying to write. >>> I hope that it will help people to understand the circumstances under >>> which they should use fractions:offset: creation API. >>> >>> >>> >>> I define a transformation frame relative to some rectangle. I'm basic >>> data structure used for graphics. >>> I represent two groups of distances: >>> - The fractional distance (between 0 and 1) to place the morph in its >>> owner's bounds >>> - Fixed pixel offset to apply after fractional positioning (e.g., "10 >>> pixel right of the center of the owner") >>> >>> !! API usage >>> It is important to understand that it is better to use the fine grained >>> API using elementary distances (bottomFraction:, bottomOffset:, >>> leftFraction: ....) than the ones (historical) using points and >>> rectangles (fractions:offsets:) >>> >>> The reason is that the old API (fractions:offsets:) is only interesting >>> if you already have a rectangle and points at hand. If you need to >>> create new ones, then they are created for nothing because they will be >>> destructured to extract their information to be feed into the layoutFrame. >>> So please do not blindly copy and paste code! >>> >>> Example: >>> Favor >>> >>> (LayoutFrame identity >>> leftFraction: 0; >>> yourself); >>> >>> (LayoutFrame identity >>> leftFraction: 0.5; >>> rightFraction: 0.95; >>> >>> (LayoutFrame identity >>> topOffset: topHeight; >>> bottomFraction: 0; >>> bottomOffset: self buttonsBarHeight; >>> leftOffset: -1; >>> rightOffset: 1) >>> over >>> >>> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >>> >>> because you are creating for nothing a new rectangle and some points. >>> >>> >>> >>> !! Implementation >>> >>> Instance variables: >>> The fractional distance (between 0 and 1) to place the morph in its >>> owner's bounds is represented by the following instance variables: >>> leftFraction >>> topFraction >>> rightFraction >>> bottomFraction <Float> >>> >>> >>> Fixed pixel offset to apply after fractional positioning (e.g., "10 >>> pixel right of the center of the owner") is represented by the >>> following instance variables: >>> leftOffset >>> topOffset >>> rightOffset >>> bottomOffset <Integer> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > >

Jan. 9, 2016

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by stepharo

Hi thierry > Stef, > > could you deprecate the use of fractions:offsets: ? It's a nice way of > shooting oneself in the foot. Yes we should in fact. Today I was thinking that there may be cases where this api makes sense but your remark in the bug tracker made me think and you are right. > Create a LayoutFrame taking all space: > > LayoutFrame fractions: (0@0 corner: 1@1) > > right? better LayoutFrame identity :) > > Create a layout frame taking all space with an inset of three, so an > offset of +3 left and above, and -3 right and bottom: > > LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) > > Fail! > > See what I mean? You have to forbid the use of a rectangle for offsets! oh yes pretty well :) > > (Note: I think the easiest API is the one used by Spec and Morphic: > Rectangle asLayoutFrame topOffset: / bottomOffset ...) > > Thierry > > Le 09/01/2016 09:56, stepharo a Ã©crit : >> Here is the new class comments I'm trying to write. >> I hope that it will help people to understand the circumstances under >> which they should use fractions:offset: creation API. >> >> >> >> I define a transformation frame relative to some rectangle. I'm basic >> data structure used for graphics. >> I represent two groups of distances: >> - The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds >> - Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") >> >> !! API usage >> It is important to understand that it is better to use the fine grained >> API using elementary distances (bottomFraction:, bottomOffset:, >> leftFraction: ....) than the ones (historical) using points and >> rectangles (fractions:offsets:) >> >> The reason is that the old API (fractions:offsets:) is only interesting >> if you already have a rectangle and points at hand. If you need to >> create new ones, then they are created for nothing because they will be >> destructured to extract their information to be feed into the >> layoutFrame. >> So please do not blindly copy and paste code! >> >> Example: >> Favor >> >> (LayoutFrame identity >> leftFraction: 0; >> yourself); >> >> (LayoutFrame identity >> leftFraction: 0.5; >> rightFraction: 0.95; >> >> (LayoutFrame identity >> topOffset: topHeight; >> bottomFraction: 0; >> bottomOffset: self buttonsBarHeight; >> leftOffset: -1; >> rightOffset: 1) >> over >> >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >> >> because you are creating for nothing a new rectangle and some points. >> >> >> >> !! Implementation >> >> Instance variables: >> The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds is represented by the following instance variables: >> leftFraction >> topFraction >> rightFraction >> bottomFraction <Float> >> >> >> Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") is represented by the >> following instance variables: >> leftOffset >> topOffset >> rightOffset >> bottomOffset <Integer> >> >> > > >

Jan. 9, 2016

Re: [Pharo-dev] need help improving layoutFrame =

by stepharo

thanks stefan. I should have done it with igor some years ago. Le 9/1/16 10:37, Stephan Eggermont a Ã©crit : > On 09-01-16 10:06, stepharo wrote: >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) = LayoutFrame identity >> should be true and it is not. >> I do not have the time to fix it now. >> >> Stef >> >> > Name: > SLICE-Issue-17363-LayoutFrame-fractions-0--0-corner-1--1--LayoutFrame-identity-should-be-true-and-it-is-not-StephanEggermont.1 > Author: StephanEggermont > Time: 9 January 2016, 10:36:18.036246 am > UUID: 0a7119da-7ed6-4bf2-8581-7c02351dd2de > Ancestors: > Dependencies: Morphic-Base-StephanEggermont.525, > Morphic-Tests-StephanEggermont.7 > > = & hash to avoid comparing with == > > >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by Sven Van Caekenberghe

it is a combination of 2 things: the repo must 1st be defined and used by a package, then there is this odd behaviour of checking all repos for version conflicts. so it depends on what you have loaded. > On 09 Jan 2016, at 12:34, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > eeeehhh that was happening forever at least the last 2 years I am around. How come you guys just noticed ? > > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I saw that too, I choked in my coffee ;-) > > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > > > may be I'm dreaming this morning but when I saved code in the inbox I saw a query to www.squeaksource.com? > > > > Stef > > > >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by stepharo

thanks esteban. I was surprised. Le 9/1/16 10:11, Esteban Lorenzano a Ã©crit : > no, is true :( > the configurations for FFI and Alien are pointing to a place there, and since Monticello isâ¦ wellâ¦ not so goodâ¦ it scans all available repositories to get a version number. > Obviously, not good.. > And I think we changed that last year, but obviously is back. > > in the mean time, I have in my todo to make a mirror for FFI and Alien in sthub and do a configuration who will take packages from there. That will minimise the problem, but it will still be there :( > > Esteban > >> On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: >> >> may be I'm dreaming this morning but when I saved code in the inbox I saw a query to www.squeaksource.com? >> >> Stef >> >

Jan. 9, 2016