- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

Bad math, the correct is 35.000 word are: *I repeat 100 UPBE BOOKS !!!!! * On Sat, Jan 9, 2016 at 11:49 AM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Since I am the mainn maintainer of UPBE and pretty much alone, I will have > to disagree, I have expressed my dislike for GT tools in the past, I was > quite vocal about my dislike about GTPlayground and especially the pages > interface of GTInspector. > > Yet even though I am the one that usually ends up keep pushing UPBE > forward the most, I never said dont include this GT tool because I will > have to document it. > > As a matter of fact GT people are the rare breed of pharoers , close to > extinction level, that bothers documenting its own tools making my job > super easy and a matter of porting their blog posts to Pillar. > > Also its important to note here that our dear beloved debugger is decades > old, maybe just maybe its time to try something new even if we dont like > it. > > Afterall GT people were quick to adress my problems of Playground like the > lack of copy paste in right click menu, the lack of tabs etc. We objected > and criticised, they improved . End of story. None complains about the > Playground anymore. > > Its also important to note that they constantly pushing pharo forward. > > On the matters of documentation I will accept zero excuses from this > community. If one spent 10 minutes per week, I repeat 10 minutes per week, > on contributing to UPBE we would have the following > > 1) a person even a slow typer, types at least 40 words per minute > 2) in 10 minutes one can type 400 words > 3) That is one page of UPBE (pdf version) in 10 minutes > 4) thats 50 pages per year per person > 5) if people who are experienced are at least 10, I think we can find 10 > people who understand pharo deeply , thats 500 pages per year > > we end up with the conclusion that the UPBE with extremely limited effort > and extremely low amount of people would have by now the last 7 years that > Pharo is around , 3500 pages of documentation. > > But since 10 people is too few and there a lot more judging from the > mailing list , I will say 100 people is more realistic which means 35.000 > pages or to put it more in perspective , thats the total of 10 UPBE books > > > > > *I repeat 10 UPBE BOOKS !!!!! * > So no no no and NO dont exclude the new debugger because of the effort to > document, I respect Stef he and Damien are the ones responsible for the > existenve of UPBE and PBE in the first place, they also helped me alot with > Dimitri to port many chapters to pharo 4. Plus I love Pillar for > documentation its awesome even with its flaws. > > > But I say that GT people earned my trust, my trust that the have desire > and visions to push Pharo forward and I say let them put the Debugger in > who is going to hurt , it can be disabled and bring back the old one. Same > story with Playground but seriously who bring back the old workspace ? > > Let them take the criticism and improve the new debugger, its a new thing > of course it will have its flaws. But I dont want a Pharo that works well, > I want a Pharo that keeps going forward. > > I have not the opportunity to download a new image because of my lack my > connection is down and I use my mobile connection to do the minimum because > it costs too much. > > But even if I heavily dislike the debugger like I did the the Playground I > know that GT people will listen and will improve it, for that I have zero > doubts because I admire their efforts even when I disagree with them. > > > > On Sat, Jan 9, 2016 at 4:19 AM Ben Coman <btc(a)openinworld.com> wrote: > >> On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> wrote: >> > 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) >> >> This also applies to UPBE. It would be good to get that out the door >> matching Pharo 5 without too much rework. >> >> cheers -ben >> >> >> > 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 >> > >> > >> >>

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

Since I am the mainn maintainer of UPBE and pretty much alone, I will have to disagree, I have expressed my dislike for GT tools in the past, I was quite vocal about my dislike about GTPlayground and especially the pages interface of GTInspector. Yet even though I am the one that usually ends up keep pushing UPBE forward the most, I never said dont include this GT tool because I will have to document it. As a matter of fact GT people are the rare breed of pharoers , close to extinction level, that bothers documenting its own tools making my job super easy and a matter of porting their blog posts to Pillar. Also its important to note here that our dear beloved debugger is decades old, maybe just maybe its time to try something new even if we dont like it. Afterall GT people were quick to adress my problems of Playground like the lack of copy paste in right click menu, the lack of tabs etc. We objected and criticised, they improved . End of story. None complains about the Playground anymore. Its also important to note that they constantly pushing pharo forward. On the matters of documentation I will accept zero excuses from this community. If one spent 10 minutes per week, I repeat 10 minutes per week, on contributing to UPBE we would have the following 1) a person even a slow typer, types at least 40 words per minute 2) in 10 minutes one can type 400 words 3) That is one page of UPBE (pdf version) in 10 minutes 4) thats 50 pages per year per person 5) if people who are experienced are at least 10, I think we can find 10 people who understand pharo deeply , thats 500 pages per year we end up with the conclusion that the UPBE with extremely limited effort and extremely low amount of people would have by now the last 7 years that Pharo is around , 3500 pages of documentation. But since 10 people is too few and there a lot more judging from the mailing list , I will say 100 people is more realistic which means 35.000 pages or to put it more in perspective , thats the total of 10 UPBE books *I repeat 10 UPBE BOOKS !!!!! * So no no no and NO dont exclude the new debugger because of the effort to document, I respect Stef he and Damien are the ones responsible for the existenve of UPBE and PBE in the first place, they also helped me alot with Dimitri to port many chapters to pharo 4. Plus I love Pillar for documentation its awesome even with its flaws. But I say that GT people earned my trust, my trust that the have desire and visions to push Pharo forward and I say let them put the Debugger in who is going to hurt , it can be disabled and bring back the old one. Same story with Playground but seriously who bring back the old workspace ? Let them take the criticism and improve the new debugger, its a new thing of course it will have its flaws. But I dont want a Pharo that works well, I want a Pharo that keeps going forward. I have not the opportunity to download a new image because of my lack my connection is down and I use my mobile connection to do the minimum because it costs too much. But even if I heavily dislike the debugger like I did the the Playground I know that GT people will listen and will improve it, for that I have zero doubts because I admire their efforts even when I disagree with them. On Sat, Jan 9, 2016 at 4:19 AM Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> wrote: > > 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) > > This also applies to UPBE. It would be good to get that out the door > matching Pharo 5 without too much rework. > > cheers -ben > > > > 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 > > > > > >

Jan. 9, 2016

Differentiate ProcessList and LinkedList - incomplete

by Ben Coman

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? 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

Jan. 9, 2016

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

by Stephan Eggermont

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] gtdebugger in pharo 5.0

by Tudor Girba

Hi, Could you be specific? What exactly do you find less intuitive? To be able to react, it is useful to get concrete points. Cheers, Doru > On Jan 9, 2016, at 4:23 AM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > 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"? > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Jan. 9, 2016

Fixed Glamour wrong users of LayoutFrame fractions: (0@0 corner: 1@1) fixes

by stepharo

Hi I commited Glamour fixes for LayoutFrame fractions: (0@0 corner: 1@1)) -> LayoutFrame identity It is faster, produces less garbage and easier to read. Now it would be good that Glamourers do the same cleans that I did with Igor on complete Pharo. Check all the uses of fractions: and fractions:offsets: and only use those if you do not create by yourself a rectangle. In addition using rectangles for passing four digits is doomed to create wrong and incorrect rectangles so if you still need to use rectangle better use Margin. A margin is a holder of 1,2 or 4 digits and it is not a rectangle. Tell me if you need more precision. Stef

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 9, 2016, at 10:43 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (re-send because I exceeded limit.) > > Hi, > > letâs think positive. Thanks :) > 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: Exactly :) We should also remember that it uses GTInspector which should decrease the cost of maintenance for those parts. > <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). Yes, we played with this last night and we can adopt it for now. > 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 Yes. I opened an issue for this: https://pharo.fogbugz.com/f/cases/17362/GTDebugger-should-use-FastTable-to-… Cheers, Doru >> 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 "Don't give to get. Just give."

Jan. 9, 2016

Better class comment version2

by stepharo

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 point 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)) For this one in particular it is better to use LayoutFrame identity It is faster and more readable because you are creating for nothing a new rectangle and some points. !! Final point: Do not use Rectangles for specifying layoutFrames If you happen to need to create a rectangle and use the fractions:offsets: class methods, refrain from creating a rectangle. The reason is that a rectangle is not 4 numbers, it represents a space area and when you use a rectangle to represent random numbers you end up creating rectangles with negative extents and this is not good. In this case use Margin, Margin is a nice class holding either one number (the same "margin" on the four sides of a rectangle), or two number (top/bottom, left/right margins) or 4 numbers. !! 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

Fixed Glamour wrong users of LayoutFrame fractions: (0@0 corner: 1@1) fixes

by stepharo

Hi I commited Glamour fixes for LayoutFrame fractions: (0@0 corner: 1@1)) -> LayoutFrame identity It is faster, produces less garbage and easier to read. Now it would be good that Glamourers do the same cleans that I did with Igor on complete Pharo. Check all the uses of fractions: and fractions:offsets: and only use those if you do not create by yourself a rectangle. In addition using rectangles for passing four digits is doomed to create wrong and incorrect rectangles so if you still need to use rectangle better use Margin. A margin is a holder of 1,2 or 4 digits and it is not a rectangle. Tell me if you need more precision. Stef

Jan. 9, 2016

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

by Esteban Lorenzano

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