- Pharo-dev - lists.pharo.org

Cypress - cross platform Pharo & Visualworks

by Ben Coman

Is anyone using cross-platform Pharo / VisualWorks development with Cypress? https://github.com/CampSmalltalk/Cypress cheers -ben

April 30, 2015

Re: [Pharo-dev] [ANN] Screencast on Versionner (Part 2)

by stepharo

esteban can you provide the link to the second videos? Stef Le 30/4/15 15:31, Esteban Lorenzano a Ã©crit : > Hi again, > > Now I made a small video on how to use Versionner to help you manage > your releases and commits. > > https://youtu.be/cFRJDuWL-Q0 > > This is new stuff, so you will need latest Pharo 5 to use it, > alternatively you can install latest Versionner into Pharo 4 (I donât > know how it will work on Pharo 3, youâll probably need to load Glamour > as well others). > In Pharo 4, you can install it executing: > > Gofer it > smalltalkhubUser: 'PharoExtras' project: 'Versionner'; > configuration; > loadVersion: '2.12.2'. > > cheers, > Esteban > >

April 30, 2015

Re: [Pharo-dev] Is there a way to understand why rubric (playground) does not highlight code?

by Yuriy Tymchuk

Would be nice. Otherwise Iâve attached the new version. As far as I can tell by using it myself I donât see any issues. > On 30 Apr 2015, at 16:16, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Maybe Alain (in CC) can share some light on this :) > > Cheers, > Andrei > > On Thu, Apr 30, 2015 at 4:08 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Iâd like to remove that, but I also want to communicate about what was the original intent. Because now before the styling takes place the text color is stored and set to transparent, and after the styling takes place the previous color is set. But if the styling is delayed because other processes are running - you end up with transparent text in your playground/inspector. > > Uko > > > > >> On 30 Apr 2015, at 16:04, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> No idea it that's a feature or not :) >> Feel free to remove it. >> >> >> On Thu, Apr 30, 2015 at 4:01 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> Ok, found the cause. By default the color of text is correctly set by themer. But RubParagraphDecorator>>#next: sets the color to transparent before the styling takes place. Does this make any sense? Because itâs like: âyou cannot see anything while Iâm stylingâ. >> >> Uko >> >>> On 30 Apr 2015, at 15:07, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Oh, and one more snippet that blocks syntax highlight and puts you in transparent text madness: >>> >>> GLMAsyncTask new >>> doInBackground: [ [ true ] whileTrue: [ ] ]; >>> execute >>> >>> Uko >>> >>>> On 30 Apr 2015, at 15:02, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>> >>>> Ok, Iâve manually tried to set the color to black for a certain EditingArea and it works. Can anyone suggest me now can I put a breakpoint that work on insVar access? Do I have to do something with slots? >>>> >>>> Uko >>>> >>>> P.S. I really donât get why everyone is so ignorantâ¦ whole our team suffers from not seeing text in rubricâ¦ >>>> >>>>> On 28 Apr 2015, at 22:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>> >>>>> Look, the point is that if code styling is not happening, because higher priority process is running, you canât see what you are typing. There is a cause for that. Also, is there a way disable styling? Just to see what happens then? >>>>> >>>>> Uko >>>>> >>>>> >>>>>> On 28 Apr 2015, at 22:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>>>>> >>>>>> RubEditingArea allInstances collect: #textColor "{Color transparent. Color transparent. Color transparent. Color transparent. Color black. Color black. Color lightGray}" >>>>>> >>>>>> But I haven't seen any place that would be missing color. Maybe the "EditingArea" color is not used in favor of selection/section color (or whatever the name of it in rubric is)? >>>>>> >>>>>> Peter >>>>>> >>>>>> On Tue, Apr 28, 2015 at 10:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>>> Guys, run please âRubEditingArea allInstances collect: #textColorâ. Almost all rubric text areas have transparent text color. Is it something strange happening in my image, or you have the same? >>>>>> >>>>>> Uko >>>>>> >>>>>> >>>>>> >>>>>>> On 20 Apr 2015, at 14:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>>>>>> >>>>>>> This also happened to me several times when executing (do it and go) some Roassal example with error (=it opened debugger). However the occurrence is very inconsistent so I don't know what was the trigger. >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>>>> This was just an example. The question is how do I identify what is blocking the highlighting. >>>>>>> >>>>>>> Uko >>>>>>> >>>>>>> >>>>>>>> On 20 Apr 2015, at 12:19, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Maybe highlighting is running in process with lesser priority than default priority of #fork method. >>>>>>>> >>>>>>>> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes with lesser priority >>>>>>>> >>>>>>>> >>>>>>>> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>>>>>>> Open a new pharo image (Iâve used latest 5, but on 4 it should work as well). Open playground and execute: >>>>>>>> >>>>>>>> [ [ true ] whileTrue: [ ] ] fork >>>>>>>> >>>>>>>> now open a new playground and start typing. Characters are invisible. >>>>>>>> Uko >>>>>>>> >>>>>>>>> On 20 Apr 2015, at 11:14, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I did not see this before. Could you reproduce the issue? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>>>>>> Hi. >>>>>>>>> >>>>>>>>> Sometimes it happens that playground does not do the syntax highlighting. This is especially frustrating when you open a new window and text is either white or transparent i.e. you cannot see what you are typing. >>>>>>>>> >>>>>>>>> I guess this is because some process is blocked by another one. Is there a way to check it? Because I want to understand whether it is because of me, or not. >>>>>>>>> >>>>>>>>> Cheers! >>>>>>>>> Uko >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com <http://www.tudorgirba.com/> >>>>>>>>> >>>>>>>>> "Every thing has its own flow" >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > >

April 30, 2015

Re: [Pharo-dev] Collecting user data

by Yuriy Tymchuk

Cool. > On 30 Apr 2015, at 16:18, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Of course :) > Just right now we are too busy with releasing moose 5.1 and moving development to Pharo 5. > After it's done we can sync more on this. > > Cheers, > Andrei > > On Thu, Apr 30, 2015 at 4:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Ok, then an important question: is any author of a reporting tool ready to help other 2 authors to migrate to his tool? > > Uko > > > >> On 30 Apr 2015, at 16:10, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> >> One is also easier to improve/maintain. >> Stef >> >> >> Le 28/4/15 14:31, Andrei Chis a Ã©crit : >>> Yes, some level of unification would be nice, especially for the part about users agreeing to send usage data and persisting that setting. >>> Also at least two general levels of details about what data is being send that tools should follow would help (full anonymous vs. include class names/method names ?). >>> Last but not least, a single entry point for sending that data over the network would help. >>> >>> How data is collected/stored will differ from tool to tool, but agreeing on the previous aspects would make it much easier to collect data. >>> >>> Cheers, >>> Andrei >>> >>> On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> > >>> > Hi guys, >>> > >>> > from time to time we have to collect a usage data in order to improve our tools. For example Iâd like to collect data in future about how do you treat code critics: do they occur, do you outfox them, do you mark them as false positives? If we had answers to these questions, we could really make good and helpful critics. >>> > >>> > For now I know that there are 3 projects which collect data: >>> > - GTSpotter >>> > - Shoreline >>> > - DFlow (not in image by default). >>> > >>> > Should I make 4th data collection for QualityAssistant? Or maybe we can do some unification? >>> > >>> >>> I would love unification! >>> >>> Itâs not only good for the researchers, but even for the user: I do not want to decide 5 times to give data to research, >>> but I want to decide it onceâ¦ >>> >>> Marcus >>> >>> >>> >> > >

April 30, 2015

Re: [Pharo-dev] Collecting user data

by Andrei Chis

Of course :) Just right now we are too busy with releasing moose 5.1 and moving development to Pharo 5. After it's done we can sync more on this. Cheers, Andrei On Thu, Apr 30, 2015 at 4:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Ok, then an important question: is any author of a reporting tool ready to > help other 2 authors to migrate to his tool? > > Uko > > > > On 30 Apr 2015, at 16:10, stepharo <stepharo(a)free.fr> wrote: > > > One is also easier to improve/maintain. > Stef > > > Le 28/4/15 14:31, Andrei Chis a Ã©crit : > > Yes, some level of unification would be nice, especially for the part > about users agreeing to send usage data and persisting that setting. > Also at least two general levels of details about what data is being send > that tools should follow would help (full anonymous vs. include class > names/method names ?). > Last but not least, a single entry point for sending that data over the > network would help. > > How data is collected/stored will differ from tool to tool, but agreeing > on the previous aspects would make it much easier to collect data. > > Cheers, > Andrei > > On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> > Hi guys, >> > >> > from time to time we have to collect a usage data in order to improve >> our tools. For example Iâd like to collect data in future about how do you >> treat code critics: do they occur, do you outfox them, do you mark them as >> false positives? If we had answers to these questions, we could really make >> good and helpful critics. >> > >> > For now I know that there are 3 projects which collect data: >> > - GTSpotter >> > - Shoreline >> > - DFlow (not in image by default). >> > >> > Should I make 4th data collection for QualityAssistant? Or maybe we can >> do some unification? >> > >> >> I would love unification! >> >> Itâs not only good for the researchers, but even for the user: I do not >> want to decide 5 times to give data to research, >> but I want to decide it onceâ¦ >> >> Marcus >> >> >> > > >

April 30, 2015

Re: [Pharo-dev] Is there a way to understand why rubric (playground) does not highlight code?

by Andrei Chis

Maybe Alain (in CC) can share some light on this :) Cheers, Andrei On Thu, Apr 30, 2015 at 4:08 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Iâd like to remove that, but I also want to communicate about what was the > original intent. Because now before the styling takes place the text color > is stored and set to transparent, and after the styling takes place the > previous color is set. But if the styling is delayed because other > processes are running - you end up with transparent text in your > playground/inspector. > > Uko > > > > > On 30 Apr 2015, at 16:04, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > No idea it that's a feature or not :) > Feel free to remove it. > > > On Thu, Apr 30, 2015 at 4:01 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Ok, found the cause. By default the color of text is correctly set by >> themer. But RubParagraphDecorator>>#next: sets the color to transparent >> before the styling takes place. Does this make any sense? Because itâs >> like: âyou cannot see anything while Iâm stylingâ. >> >> Uko >> >> On 30 Apr 2015, at 15:07, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Oh, and one more snippet that blocks syntax highlight and puts you in >> transparent text madness: >> >> GLMAsyncTask new >> doInBackground: [ [ true ] whileTrue: [ ] ]; >> execute >> >> Uko >> >> On 30 Apr 2015, at 15:02, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Ok, Iâve manually tried to set the color to black for a >> certain EditingArea and it works. Can anyone suggest me now can I put a >> breakpoint that work on insVar access? Do I have to do something with slots? >> >> Uko >> >> P.S. I really donât get why everyone is so ignorantâ¦ whole our team >> suffers from not seeing text in rubricâ¦ >> >> On 28 Apr 2015, at 22:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Look, the point is that if code styling is not happening, because higher >> priority process is running, you canât see what you are typing. There is a >> cause for that. Also, is there a way disable styling? Just to see what >> happens then? >> >> Uko >> >> >> On 28 Apr 2015, at 22:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> RubEditingArea allInstances collect: #textColor "{Color transparent. >> Color transparent. Color transparent. Color transparent. Color black. Color >> black. Color lightGray}" >> >> But I haven't seen any place that would be missing color. Maybe the >> "EditingArea" color is not used in favor of selection/section color (or >> whatever the name of it in rubric is)? >> >> Peter >> >> On Tue, Apr 28, 2015 at 10:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>> Guys, run please âRubEditingArea allInstances collect: #textColorâ. >>> Almost all rubric text areas have transparent text color. Is it something >>> strange happening in my image, or you have the same? >>> >>> Uko >>> >>> >>> >>> On 20 Apr 2015, at 14:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> This also happened to me several times when executing (do it and go) >>> some Roassal example with error (=it opened debugger). However the >>> occurrence is very inconsistent so I don't know what was the trigger. >>> >>> Peter >>> >>> On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >>>> This was just an example. The question is how do I identify what is >>>> blocking the highlighting. >>>> >>>> Uko >>>> >>>> >>>> On 20 Apr 2015, at 12:19, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>> >>>> Hi >>>> >>>> Maybe highlighting is running in process with lesser priority than >>>> default priority of #fork method. >>>> >>>> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes >>>> with lesser priority >>>> >>>> >>>> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >>>> >>>>> Open a new pharo image (Iâve used latest 5, but on 4 it should work as >>>>> well). Open playground and execute: >>>>> >>>>> [ [ true ] whileTrue: [ ] ] fork >>>>> >>>>> now open a new playground and start typing. Characters are invisible. >>>>> Uko >>>>> >>>>> On 20 Apr 2015, at 11:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I did not see this before. Could you reproduce the issue? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>>>> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> Sometimes it happens that playground does not do the syntax >>>>>> highlighting. This is especially frustrating when you open a new window and >>>>>> text is either white or transparent i.e. you cannot see what you are typing. >>>>>> >>>>>> I guess this is because some process is blocked by another one. Is >>>>>> there a way to check it? Because I want to understand whether it is because >>>>>> of me, or not. >>>>>> >>>>>> Cheers! >>>>>> Uko >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> >> > >

April 30, 2015

Re: [Pharo-dev] Collecting user data

by Yuriy Tymchuk

Ok, then an important question: is any author of a reporting tool ready to help other 2 authors to migrate to his tool? Uko > On 30 Apr 2015, at 16:10, stepharo <stepharo(a)free.fr> wrote: > > > One is also easier to improve/maintain. > Stef > > > Le 28/4/15 14:31, Andrei Chis a Ã©crit : >> Yes, some level of unification would be nice, especially for the part about users agreeing to send usage data and persisting that setting. >> Also at least two general levels of details about what data is being send that tools should follow would help (full anonymous vs. include class names/method names ?). >> Last but not least, a single entry point for sending that data over the network would help. >> >> How data is collected/stored will differ from tool to tool, but agreeing on the previous aspects would make it much easier to collect data. >> >> Cheers, >> Andrei >> >> On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> > >> > Hi guys, >> > >> > from time to time we have to collect a usage data in order to improve our tools. For example Iâd like to collect data in future about how do you treat code critics: do they occur, do you outfox them, do you mark them as false positives? If we had answers to these questions, we could really make good and helpful critics. >> > >> > For now I know that there are 3 projects which collect data: >> > - GTSpotter >> > - Shoreline >> > - DFlow (not in image by default). >> > >> > Should I make 4th data collection for QualityAssistant? Or maybe we can do some unification? >> > >> >> I would love unification! >> >> Itâs not only good for the researchers, but even for the user: I do not want to decide 5 times to give data to research, >> but I want to decide it onceâ¦ >> >> Marcus >> >> >> >

April 30, 2015

Re: [Pharo-dev] Differences between TextConverters and ZnEncoders

by stepharo

So could not we spot the "cr" conversion and isolate the users/providers? Stef Le 30/4/15 12:40, Sven Van Caekenberghe a Ã©crit : >> On 30 Apr 2015, at 11:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> I'd like to summarize some things >> >> + 1 to all that sven said. >> >> Taking a look at users of old text converters, there are only 77 of them: >> >> (TextConverter withAllSubclasses gather: [ :each | >> SystemNavigation new allReferencesTo: each binding ]) size >> " => 77" >> >> That is maybe a good starting point. And it will step by step remove the leading char magic. >> >> The only point where I see a problem is in the feature "convert magically cr's to some line ending convention" that is managed by a mixture between the text converter and the file stream. I would not like to push this "feature" to the zinc encoders. Actually I don't believe it belongs to the file reading neither. > That are the things I am talking about, the old code mixed things up way too much. > > The main API problem is a key one: the old converters work String <-> String, the new ones String <-> ByteArray (or streams of course). > > Also does anyone dare to touch MultiByteFileStream or MultiByteBinaryOrTextStream (the names alone ;-) ? > >> Guille >> >> El jue., 30 de abr. de 2015 a la(s) 11:46 a. m., Norbert Hartl <norbert(a)hartl.name> escribiÃ³: >> If yours is better there shouldn't be much of a reason to keep the bad one, right? I'd just suggest that pharo does not depend on zinc classes but the encoder moves to pharo with a different name. >> >> Norbert >> >>> Am 30.04.2015 um 11:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>>> On 30 Apr 2015, at 11:13, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> Hi! >>>> >>>> I'm struggling with the TextConverter's API in Pharo :). >>>> >>>> I wanted to test the converters in Pharo, and I found the method #convertFromSystemString: that should (from its name) convert a Pharo String into an encoded version of it. >>>> >>>> (UTF8TextConverter default convertFromSystemString: 'Ã¡'). >>>> >>>> Funny thing, it does not do that. It does the opposite: it tries to convert an encoded string to a pharo string. And so it fails. Of course, its symmetrical version does what I want and behaves as the ZnUTF8Encoder :) >>>> >>>> (UTF8TextConverter default convertToSystemString: 'Ã¡') asByteArray >>>> "#[195 161]" >>>> >>>> ZnUTF8Encoder new encodeString: 'Ã¡' "#[195 161]" >>>> >>>> Question: >>>> - does the convertTo/From methods makes sense to you or It's just me that sees them inverted? >>>> - does it make sense to have the two versions of converters? Zn and the TextConverters do the same in my opinion (or maybe I'm confused :) ) >>>> >>>> Guille >>> I am biased, but the Zn converters are better. Why ? Because they work between String <-> Bytes as a text encoder/decoder should. They also have a number of extra features (counting the number of encoded bytes, being able to move backwards on input, being able to be very strict), are faster and have a clearer implementation. Furthermore, they are more correct and implement more encodings. >>> >>> There is also good documentation http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ >>> >>> ZnCharacter[Read|Write]Stream are also very instructive, compare them to MultiByteStream. >>> >>> Should we throw the other one out ? Probably. But it is the same problems as with Xtreams: the API is different and adding a compatibility layer would defeat the purpose. So I don't know. >>> >>> Sven >>> >>> >>> >> > >

April 30, 2015

Re: [Pharo-dev] Collecting user data

by stepharo

One is also easier to improve/maintain. Stef Le 28/4/15 14:31, Andrei Chis a Ã©crit : > Yes, some level of unification would be nice, especially for the part > about users agreeing to send usage data and persisting that setting. > Also at least two general levels of details about what data is being > send that tools should follow would help (full anonymous vs. include > class names/method names ?). > Last but not least, a single entry point for sending that data over > the network would help. > > How data is collected/stored will differ from tool to tool, but > agreeing on the previous aspects would make it much easier to collect > data. > > Cheers, > Andrei > > On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>> wrote: > > > > Hi guys, > > > > from time to time we have to collect a usage data in order to > improve our tools. For example Iâd like to collect data in future > about how do you treat code critics: do they occur, do you outfox > them, do you mark them as false positives? If we had answers to > these questions, we could really make good and helpful critics. > > > > For now I know that there are 3 projects which collect data: > > - GTSpotter > > - Shoreline > > - DFlow (not in image by default). > > > > Should I make 4th data collection for QualityAssistant? Or maybe > we can do some unification? > > > > I would love unification! > > Itâs not only good for the researchers, but even for the user: I > do not want to decide 5 times to give data to research, > but I want to decide it onceâ¦ > > Marcus > > >

April 30, 2015

Re: [Pharo-dev] [Review] Issue 14080: Nuke remaining subStringXyz's

by stepharo

Le 29/4/15 13:46, Sean P. DeNigris a Ã©crit : > Luc Fabresse wrote >> Congrats Sean for this one! >> It impacts on a lot of external packages... > Thanks, Luc! The whole time I was working on this, I was thinking "there is > not enough value in a simple rename to be worth all this work". No there is :) > But now, I'm > really glad I finished it for one reason - now I know it can be done! What I > mean is that IIRC it would have been way more complicated and scary to do > that change a few years ago without Jenkins, Penelope, slices, a group of > immediately available reviewers/integrators, etc. I clearly experienced the > compounded value of all of the infrastructure we have built. Now that I know > we have the structures necessary to support broad changes to the system, I > am dreaming about what to do next... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Review-Issue-14080-Nuke-remaining-subStringXyz-s-tp48… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 30, 2015