Re: [Pharo-users] Distribution of test method name length
Nice graph, Ben! The larger test names (selector size > 100) look more like sentences than names ;-). On 21/06/19 6:50 AM, Ben Coman wrote: classes := Object allSubclasses select: [ :cc | cc isKindOf: TestCase class ]. methods := c flatCollect: [ :c | c allMethods ]. Did you mean classes flatCollect: here? tests := methods select: [ :m | m selector beginsWith: 'test' ]. lengths := tests collect: [ :m | m selector size ]. select:thenCollect: can also be used here. lengths asBag keysAndValuesDo: [ :len :count | Transcript crShow: len; show: ','; show: count ] I find the in: selector very handy for quick commands without having to use undefined temps. e.g. (Object allSubclasses select: [ :cc | cc isKindOf: TestCase class ]) in: [ :classes | (classes flatCollect: [ :c | c allMethods ]) in: [ :methods | (methods select: [ :m | m selector beginsWith: 'test' ] thenCollect: [ :m | m selector size ]) in: [:lengths | lengths asBag keysAndValuesDo: [ :len :count | Transcript crShow: len; show: ','; show: count Regards .. Subbu
[Pharo-users] Distribution of test method name length
Working on the Exercism project to shorten generated test method names, for comparison I reviewed the length of test method names in Pharo 7. So just for curiousity value, here is that graph (done in Excel)... [image: image.png] Data generated by... classes := Object allSubclasses select: [ :cc | cc isKindOf: TestCase class ]. methods := c flatCollect: [ :c | c allMethods ]. tests := methods select: [ :m | m selector beginsWith: 'test' ]. lengths := tests collect: [ :m | m selector size ]. lengths asBag keysAndValuesDo: [ :len :count | Transcript crShow: len; show: ','; show: count ] cheers -ben
Re: [Pharo-users] Information on Spec development
--- Begin Message --- Thanks for sharing this. You guys are doing an amazing job. I do not mind having a couple of warning times to time. Cheers, Alexandre > On Jun 20, 2019, at 11:29 AM, Cyril Ferlicot wrote: > > Hello everyone! > > This is an important update about the development of Spec. > > As you might have heard, we are working on Spec to release a new > version in Pharo 8. One goal is to unify all Pharo interfaces behind > one GUI framework and a second goal is to allow multiple back-ends > (Morphic but also GTK, Bloc, ...). To reach those goals we have been > updating the current version of Spec. We see now, however, that > updating Spec directly creates troubles with migration. For example, > we currently have a lot of deprecation warnings in Iceberg, because we > can't update it without breaking Pharo 7 compatibility. > > After some discussions between the engineers working on Spec, here is > our plan to improve the situation: We will copy all classes of Spec > and rename them with the "Sp" prefix. (We will also ensure that every > class of Spec started with the same prefix for consistency). For > extensions methods, we will rename them to have a version different > from Spec 1 (The spec from Pharo 7). Once done we will integrate this > new version in Pharo 8. From there we will wait some weeks to let > users who started to use the updated Spec change their projects to use > this new Spec2. Finally, we will revert all changes that happened on > Spec 1 and deprecate the packages. We hope this will make things > easier for everyone. > > Have a nice day! > > -- > Cyril Ferlicot > https://ferlicot.fr > --- End Message ---
[Pharo-users] Information on Spec development
Hello everyone! This is an important update about the development of Spec. As you might have heard, we are working on Spec to release a new version in Pharo 8. One goal is to unify all Pharo interfaces behind one GUI framework and a second goal is to allow multiple back-ends (Morphic but also GTK, Bloc, ...). To reach those goals we have been updating the current version of Spec. We see now, however, that updating Spec directly creates troubles with migration. For example, we currently have a lot of deprecation warnings in Iceberg, because we can't update it without breaking Pharo 7 compatibility. After some discussions between the engineers working on Spec, here is our plan to improve the situation: We will copy all classes of Spec and rename them with the "Sp" prefix. (We will also ensure that every class of Spec started with the same prefix for consistency). For extensions methods, we will rename them to have a version different from Spec 1 (The spec from Pharo 7). Once done we will integrate this new version in Pharo 8. From there we will wait some weeks to let users who started to use the updated Spec change their projects to use this new Spec2. Finally, we will revert all changes that happened on Spec 1 and deprecate the packages. We hope this will make things easier for everyone. Have a nice day! -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-users] Question: anyone using NOCompletion setting?
--- Begin Message --- Marcus, this is an excellent idea! Alexandre > On Jun 19, 2019, at 4:15 AM, Marcus Denker wrote: > > > >> On 18 Jun 2019, at 19:34, Sean P. DeNigris wrote: >> >> I use it sometimes. IIRC there was a paper that it was objectively better at >> finding the "right" thing. Are you thinking of removing it? >> >> > > I would like to re-implement sorting of results in a more pluggable way… so > that e.g. > people can add more sorting ideas. > > But doing that in one step seems hard… it would be much easier if we could > simplify the system > first. > > Removing the Ocompletion (for a while) would make it much easier… > > Marcus > > --- End Message ---
