January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

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

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Christophe Demarey

Not yet tested but looks good. I just noticed it misses the "run to here" action. 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"? >>>> >>> >>> >> >

Jan. 9, 2016

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

by Dimitris Chloupis

Slow is definetly not what your are, neither stupid because pharo will not be in a state that it is and neither slow to implement things because pharo would not be so rapidly moving forward as it is. But then by using smalltalk you basically cheat , but thats our common secret ,no need to get out of this community ;) On Sat, Jan 9, 2016 at 3:04 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > 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

Can you remove this useless _stack top and _thisContext? Who needs that? And also the bytecode and also the Step glamour that freezes by image and the Step petitParser So you see what I mean? Something that normal people can use...

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

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: > > > (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

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