- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Ben Coman

On Sat, Jan 9, 2016 at 8:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Ben, allf > > Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in > Linux. And yes, since it's opaque I don't have to map it and just allocating > the correct size is enough. Its probably not 76 bytes in 64-bit though. Can someone on 64-bit report the result of my little C-code sample. Probably its okay initially to waste a few bytes on 32-bit until we have something to calculate these at runtime (btw, what is the current state/plans for such a feature). > I expect this would work in all GNU libc (glibc) based UNIXses. > Esteban, well, I thought the init function would do both, allocate and init, > but in glibc it seems it only init. In OSX it seems it does both. But from > the API point of view it's not explicit that they should allocate the space. > > Anyway, I think we get this working this time. Thanks all for the help. > > Now the problem I am facing (in Linux) is that my none blocking pipes do not > seem to be none blocking or either feof() call is not working as expected. > Ok, I have to deal with this one now. Do you have any code samples? Sounds like an interesting thing to have a look at. cheers -ben > > Thanks!! > > > On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Sat, Jan 9, 2016 at 12:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >> > On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck >> > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >>> >> >>> On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >> >>> <marianopeck(a)gmail.com> wrote: >> >>> > Hi guys, >> >>> > >> >>> > I wonder if someone could give me a hand to find out why a FFI >> >>> > calling I >> >>> > am >> >>> > doing is crashing. In OSX it works correct but I am testing in >> >>> > CentOS >> >>> > and it >> >>> > fails. I wonder if it also crashes in other Linuxes too. >> >>> >> >>> I only had enough time to run it a few time so you know it also >> >>> crashes in Debian Jessie 32-bit. There were no debug logs. I got >> >>> these sorts of messages... >> >>> >> >> >> >> Thanks! >> >> >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size >> >>> (fast): 0x08841a70 *** >> >>> >> >>> pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >> >>> >= (unsigned long) (nb)' failed. >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory >> >>> corruption: 0x0984c1e0 *** >> >>> >> >>> >> >>> Searching github for "posix_spawn_file_actions_init " >> >>> (https://git.io/vuSPL) >> >>> I see a lot a function definitions of the form... >> >>> int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) >> >>> { >> >>> fa->__actions = 0; >> >>> return 0; >> >>> } >> >>> >> >>> ...so it seems you need to first allocate the space for the struct and >> >>> then pass the address of that. >> >> >> >> I thought the same. But I also read in glibc that that the init and >> >> destroy >> >> would free and alloc exactly so that you don't have to do it. >> >> >> >> In fact, the structure is known to be opaque. I cannot rely in what I >> >> see in >> >> internet since each os may have a different. >> >> >> >> And I cant get the size of it from ffi so I cannot allocate accurately. >> >> I >> >> think I am screw. I don't want to go to plugin side grrr .. >> >> >> >> And osx does work. >> >> >> >> I think I will try against glibc rather than libc. >> >> >> >> Another idea? >> >> >> >>> { >> >>> int __allocated; >> >>> int __used; >> >>> struct __spawn_action *__actions; >> >>> int __pad[16]; >> >>> } posix_spawn_file_actions_t; >> >>> // http://linux.die.net/include/spawn.h >> >>> >> >> >> >> But that's opaque right? I cannot rely on that >> > >> > Your ExternalAddress use only allocates 4 bytes for the pointer. You >> > need to also allocate the space for the structure. I guess these may >> > need separate ExternalXXX objects, but just as hack experiment I find >> > below that n:=68 crashes and n:=69 its fine. >> >> Whoops, I missed that the space for the struct seems actually >> allocated by ExternalAddress. Doh! there it is staring at me with the >> #allocate: message. So I guess a separate ExternalXXX object isn't >> required. >> >> > >> > | posixSpawnFileActionsT n | >> > n := 68. "n := 69" >> > posixSpawnFileActionsT := ExternalAddress allocate: n. >> > OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: >> > posixSpawnFileActionsT. >> > posixSpawnFileActionsT free. >> > >> > >> > In trying to understand this I found an interesting article... >> > http://www.catb.org/esr/structure-packing/ >> > What I don't know is for a 32-bit OS on a 64-bit machine, is my >> > pointer 4 or 8 bytes? >> > Assuming 4 I derive the structure size for my 32-bit system is... >> > 4 int __allocated; >> > 4 int __used; >> > 4 struct __spawn_action *__actions; >> > 64 int __pad[16]; >> > 76 posix_spawn_file_actions_t; >> > >> > 76 - 68 = 8 is an interesting round number, but I can't quite reason it >> > out. >> >> btw I confirmed *my* structure size by compiling and running... >> #include <stdio.h> >> #include <spawn.h> >> posix_spawn_file_actions_t tst; >> int main() >> { >> printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); >> } >> >> -->sizeof=76 >> >> cheers -ben >> >> > With FFI how to you allocate some external memory and then get a >> > pointer to it to pass to primitivePosixSpawnFileActionsInit ? >> > >> > cheers -ben >> > >> >>> > I am using latest Pharo 5.0 with Spur. To reproduce: >> >>> > >> >>> > 1) Get latest Pharo 5.0 and Spur via: >> >>> > wget -O- get.pharo.org/alpha+vm | bash >> >>> > >> >>> > 2) Inside Pharo, load my prototype tool: >> >>> > >> >>> > Gofer it >> >>> > package: 'OSSubprocess'; >> >>> > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; >> >>> > load. >> >>> > >> >>> > 3) This is the code I am executing and it's crashing: >> >>> > >> >>> > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress >> >>> > allocate: 4. OSSUnixSubprocess new >> >>> > primitivePosixSpawnFileActionsInit: >> >>> > posixSpawnFileActionsT. posixSpawnFileActionsT free. >> >>> > 4) The primitive is as simple as: >> >>> > >> >>> > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT >> >>> > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* >> >>> > aPosixSpawnFileActionsT) ) module: LibC >> >>> > >> >>> > I have no idea what I am doing wrong. And again, this works on OSX. >> >>> > The >> >>> > function I am calling is: int >> >>> > posix_spawn_file_actions_init(posix_spawn_file_actions_t >> >>> > *file_actions); >> >>> > as >> >>> > you can read in [1] >> >>> > >> >>> > Below is the stacktrace I get the Linux terminal. >> >>> > >> >>> > Any hint is greatly appreciated. >> >>> > >> >>> > Thanks, >> >>> > >> >>> > >> >>> > [1] >> >>> > >> >>> > >> >>> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… >> >>> >> > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Henrik Nergaard

http://ws.stfx.eu/3KXXDAJ4EUF6 -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Saturday, January 9, 2016 3:36 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 On 09-01-16 12:39, Dimitris Chloupis wrote: > there has been around a script to automate the screenshots, but > personally I never bother using it because taking a screenshot and > inserting in pillar is the easiest thing. AFAIK the hard part is keeping things up to date. That's where automation helps. Stephan

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Stephan Eggermont

On 09-01-16 12:39, Dimitris Chloupis wrote: > there has been around a script to automate the screenshots, but > personally I never bother using it because taking a screenshot and > inserting in pillar is the easiest thing. AFAIK the hard part is keeping things up to date. That's where automation helps. Stephan

Jan. 9, 2016

Re: [Pharo-dev] Semaphore and Mutex changes summary

by Denis Kudriashov

2016-01-07 14:05 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > It is also explain why we should deprecate Semaphore>>critical: and use > Mutex>>critical: instead. That's second change. > > So we want to move 4 Semaphore methods to Mutex: > > - critical: mutuallyExcludedBlock > > It will relies on new Semaphore method waitIfInterrupted: which block is > executed when waiting process terminated at point where lock was not > acquired. Slice for this already in inbox. > It was wrong idea. I stop slice for the better solution. I will post about it later

Jan. 9, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:30 GMT+01:00 stepharo <stepharo(a)free.fr>: > Indeed people like to play with better API and sometimes this is not > better. > I prefer on:do: because like that I know that this is about Exception > handling. > But it is too long. ifError: is very intuitive name.

Jan. 9, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:17 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Hi, > > 8. 1. 2016 v 17:11, Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi, > > > > Denis says that right now, to use ifError: you do: > > > > [...] ifError: [:msg :rcv | â¦ ] > > > > and he would like to write this: > > > > [...] ifError: [:error | â¦ ] > > But for this we have on:do: message, right? > Do we need ifError:? > It is nice convenient method for the case when you don't care what exact error happens. It is very useful for scripting. sum := 0. #(1 asd 4534 5423 sdfs) do: [:each | [sum := sum + each] ifError: []] Actually I never use argument version of block. But it definitely should be error instance and not of one of it properties.

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Mariano Martinez Peck

I wanted to say that I also like more the distribution that Esteban built instead of the original one of GT Debugger. So.. +1 for that. And yes, I also like the text besides the buttons since unfortunately the buttons are not extremely intuitive. +1 for that too. Stef, as for the bydecode debugger, if I remember, you had to explicitly switch to a bytecode debugger. In the normal debugger a normal user will use, the bytecode pane was not there. On Sat, Jan 9, 2016 at 11:08 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Dont do it for me , what I did with ChronosManager is only the tip of the > iceberg, I will be redesigning the whole Pharo GUI from scratch. After I > release ChronosManager 0.2 my next victim will be Nautilus, then inspector > and finally debugger. So I will be building my own GUI for the debugger > anyway, in similar style to ChronosManager, completely custom made , static > and icon based. It wont happen tommorow but slowly and steadily I will > make my own Pharo GUI, obviously radically different to what we have now. > > I merely mentioned this to represent a voice of reason over icon based > interfaces that dominate software market anyway. > > On Sat, Jan 9, 2016 at 3:49 PM Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Hi, >> >> It is impossible to satisfy everyone. >> What I would suggest is to have text + icons as default and a preference >> to only have icons. >> >> Christophe >> >> Le 9 janv. 2016 Ã 14:30, Dimitris Chloupis a Ã©crit : >> >> Which brings us to my question, where did tooltips go ? Squeak had them >> and then they were gone in pharo. >> >> Personally I dont see the point of having an icon to have text next to >> it. Seriously how much time it takes you to learn what each icon does ? >> >> and the debugger is not exactly a tool you will be using once per month, >> so the chance of forgeting gets pretty low after the first week. >> >> So my vote goes to get rid of text, it wastes valuable gui space in an >> environment where windows fight for space. And even on my 27'' monitor I >> rather have as compact as possible GUI. >> >> On Sat, Jan 9, 2016 at 3:05 PM stepharo <stepharo(a)free.fr> wrote: >> >> >>> >>> 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? >>> >> >>> >>> >>> <PiÃ¨ce jointe Mail.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"? >>> >>> >>> >>> >>> >>> -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Esteban Lorenzano

thatâs just an example, default debugger does not have it :) I will commit my changes as soon as I can sit and clean itâ¦ the actions need to be changed to make explicit if you want text/icon/both so we can keep all behaviours (and keep compatible). Esteban > On 09 Jan 2016, at 14:08, stepharo <stepharo(a)free.fr> wrote: > > Why do we get bytecodes? > Do you think that normal developpers do not care about bytecodes? > Do you want me to show that to students? Seriously? > > Stef > > >> >> 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: >> >> <Mail Attachment.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 < <mailto:stepharo@free.fr>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] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:11 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Denis says that right now, to use ifError: you do: > > [...] ifError: [:msg :rcv | â¦ ] > > and he would like to write this: > > [...] ifError: [:error | â¦ ] > > I agree with him. The problem is that this might generate a bit of ripple > effects in external code. This is when Stephan came in and said that if we > would have a way to investigate all external repositories that are open we > could do such refactorings more boldly. > > Does it make more sense now? Or did I get it wrong? > Exactly Tudor. My cry was about why man who implement it decides to deincapsulate error state.

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

Dont do it for me , what I did with ChronosManager is only the tip of the iceberg, I will be redesigning the whole Pharo GUI from scratch. After I release ChronosManager 0.2 my next victim will be Nautilus, then inspector and finally debugger. So I will be building my own GUI for the debugger anyway, in similar style to ChronosManager, completely custom made , static and icon based. It wont happen tommorow but slowly and steadily I will make my own Pharo GUI, obviously radically different to what we have now. I merely mentioned this to represent a voice of reason over icon based interfaces that dominate software market anyway. On Sat, Jan 9, 2016 at 3:49 PM Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi, > > It is impossible to satisfy everyone. > What I would suggest is to have text + icons as default and a preference > to only have icons. > > Christophe > > Le 9 janv. 2016 Ã 14:30, Dimitris Chloupis a Ã©crit : > > Which brings us to my question, where did tooltips go ? Squeak had them > and then they were gone in pharo. > > Personally I dont see the point of having an icon to have text next to it. > Seriously how much time it takes you to learn what each icon does ? > > and the debugger is not exactly a tool you will be using once per month, > so the chance of forgeting gets pretty low after the first week. > > So my vote goes to get rid of text, it wastes valuable gui space in an > environment where windows fight for space. And even on my 27'' monitor I > rather have as compact as possible GUI. > > On Sat, Jan 9, 2016 at 3:05 PM stepharo <stepharo(a)free.fr> wrote: > > >> >> 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? >> > >> >> >> <PiÃ¨ce jointe Mail.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"? >> >> >> >> >> >>

Jan. 9, 2016