Re: [Pharo-dev] Github and Fogbugz integration

[Dimitris Chloupis]

Not Tiobe Index, Tiobe is based more on google search with the name of the
language followed with the word "programming". Which is one of the reason
its critics say its not reliable. As if there is a reliable way to measure
popularity.

The only popularity index I am familiar with that was using mainly github
was poplang, but it is no longer maintained and I do not think it was based
on the github issues.

Of course using Github as a measure for a language popularity is a really a
bad idea because Github is mainly for open source projects which means its
biased towards languages that have more active open source community.
Because by very far web dev has the most active open source community
Javascript comes No1. Of course in reality Javascript is nowhere near the
most popular language if you take into the consideration that Java
dominates business and Android software and especially mobile software is
extremely active. Obviously more closed source source orientated languages
like C# and C++ take a huge hit even though they dominate the Windows
platform while desktop still takes at least one third of the market. In the
gaming world which is still a very profitable and active part of the
software industry web based language are pretty much non existent and its
pretty much monopolised by C/C++/C# with Java trailing way way behind, even
though Java dominates on Android ultility software neither Unity or Unreal
use it, both game engines are the bread and butter of game devs.

In sort the language popularity field is a huge pile of mess because its
widely fluctuates depending on the area and subject matter and the criteria

Poplang used to be an excellent example of this

http://65.39.133.14/

But is abandoned now.

On Sun, Aug 20, 2017 at 3:41 AM Tim Mackinnon  wrote:

> I also wonder when they measure the popularity of a language/community
> whether GitHub issues is a measure (I suspect it is), so it may be
> advantageous to show activity particularly for a smaller community.
>
> Like others, I'm not a big fan of fogbugz (never understood why Joel is
> considered a god), but it's ok, and it's served its purpose. I'd seriously
> switching.
>
> I Tim
>
> Sent from my iPhone
>
> On 19 Aug 2017, at 21:40, Dimitris Chloupis  wrote:
>
>
> On Sat, Aug 19, 2017 at 10:32 PM Sean P. DeNigris 
> wrote:
>
>> > I see little reason not to allow both ways of reporting bugs.
>> It seems that the need to create an account in FB to even view/search
>> issues has been a big barrier to new(er) would-be contributors. I expect
>> this difficulty would be multiplied since, in the process of reporting a
>> bug on GH, they would not be able to easily determine if it had already
>> been opened on FB
>
>
> Tons of issues are reported in GH that are closed minutes as the issue
> they report does not even exist. Closing an issue is just a matter of
> pressing a button and you can always redirect the user to the issue in FB.
>
> Frankly I am no fan of FB, I find Github interface less powerful but far
> simpler and better designed. What annoyed me is that fogbuz did not even
> subscribed me to my own issues (issues I created) . I did not go back
> because I thought people ignored me , then one day I decided to create a
> new bug report and found out that people have replied almost immediately to
> my old ones. Then I realised that Fogbuz did not alert me through email ,
> then I dig up its settings and found the way enable email alerts. Suffice
> to say I was not very happy with this.
>
> I prefer GH also because I have already been using it with Python way
> before I was introduced into Pharo, so its not just newcomer who will
> prefer GH , I think the vast majority of people coming from other languages
> will do too. GH is almost a monopoly at this point.
>
> Pretty much every one says moving to git and github will be costly , like
> Stef just did. Blender made the move I think a year ago, so much noise in
> the mailing list whether its really worth it moving from svn to git more
> than 1 million line of code and more than a decade of commits. Later
> admitted it was far easier than they expected.
>
> Point is that people are lazy, we are just are, and we like to keep doing
> things we are familiar with because learning is hard. Problem is not
> learning is far more costly.
>
> I have been a defender of git and github in the pharo mailing lists for
> years now even though many resisted me and tried to convince me how Pharo
> and git will never properly work and here we are, not regretting a second
> of it and I am sure that other people who were supportive too dont either.
>
> But I never forced my opinion on anyone and I wont now. I am just saying ,
> if I have the choice between github and fogbuz, for me its github all the
> way. Likewise if its iceberger vs gitup , gitup all the way.
>
> On the other hand , its great to live in a time having so many choices ;)
>
>

Re: [Pharo-dev] Launcher Opening Tiny Windows

[Tim Mackinnon]

It's a known problem for any image that was saved in headless mode (not just 
launcher) - we should find a way to resolve this.

Tim

Sent from my iPhone

> On 20 Aug 2017, at 00:35, Sean P. DeNigris  wrote:
> 
> Check out this screenshot.
>  
> 
> The red arrow points to an open "window" of a newly created Pharo 6.0 based
> image, minimized to the point of barely being visible. Clicking on it makes
> a title bar somewhat more visible, the edges of which can then be dragged as
> any other window.
> 
> Anyone else seeing this?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Launcher-Opening-Tiny-Windows-tp4962615.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] Github and Fogbugz integration

[Tim Mackinnon]

I also wonder when they measure the popularity of a language/community whether 
GitHub issues is a measure (I suspect it is), so it may be advantageous to show 
activity particularly for a smaller community.

Like others, I'm not a big fan of fogbugz (never understood why Joel is 
considered a god), but it's ok, and it's served its purpose. I'd seriously 
switching.

I Tim

Sent from my iPhone

> On 19 Aug 2017, at 21:40, Dimitris Chloupis  wrote:
> 
> 
>> On Sat, Aug 19, 2017 at 10:32 PM Sean P. DeNigris  
>> wrote:
>> > I see little reason not to allow both ways of reporting bugs. 
>> It seems that the need to create an account in FB to even view/search issues 
>> has been a big barrier to new(er) would-be contributors. I expect this 
>> difficulty would be multiplied since, in the process of reporting a bug on 
>> GH, they would not be able to easily determine if it had already been opened 
>> on FB 
> 
> Tons of issues are reported in GH that are closed minutes as the issue they 
> report does not even exist. Closing an issue is just a matter of pressing a 
> button and you can always redirect the user to the issue in FB. 
> 
> Frankly I am no fan of FB, I find Github interface less powerful but far 
> simpler and better designed. What annoyed me is that fogbuz did not even 
> subscribed me to my own issues (issues I created) . I did not go back because 
> I thought people ignored me , then one day I decided to create a new bug 
> report and found out that people have replied almost immediately to my old 
> ones. Then I realised that Fogbuz did not alert me through email , then I dig 
> up its settings and found the way enable email alerts. Suffice to say I was 
> not very happy with this.  
> 
> I prefer GH also because I have already been using it with Python way before 
> I was introduced into Pharo, so its not just newcomer who will prefer GH , I 
> think the vast majority of people coming from other languages will do too. GH 
> is almost a monopoly at this point. 
> 
> Pretty much every one says moving to git and github will be costly , like 
> Stef just did. Blender made the move I think a year ago, so much noise in the 
> mailing list whether its really worth it moving from svn to git more than 1 
> million line of code and more than a decade of commits. Later admitted it was 
> far easier than they expected. 
> 
> Point is that people are lazy, we are just are, and we like to keep doing 
> things we are familiar with because learning is hard. Problem is not learning 
> is far more costly. 
> 
> I have been a defender of git and github in the pharo mailing lists for years 
> now even though many resisted me and tried to convince me how Pharo and git 
> will never properly work and here we are, not regretting a second of it and I 
> am sure that other people who were supportive too dont either. 
> 
> But I never forced my opinion on anyone and I wont now. I am just saying , if 
> I have the choice between github and fogbuz, for me its github all the way. 
> Likewise if its iceberger vs gitup , gitup all the way. 
> 
> On the other hand , its great to live in a time having so many choices ;)  

[Pharo-dev] Launcher Opening Tiny Windows

[Sean P. DeNigris]

Check out this screenshot.
 

The red arrow points to an open "window" of a newly created Pharo 6.0 based
image, minimized to the point of barely being visible. Clicking on it makes
a title bar somewhat more visible, the edges of which can then be dragged as
any other window.

Anyone else seeing this?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Launcher-Opening-Tiny-Windows-tp4962615.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

[Sean P. DeNigris]

Eliot Miranda-2 wrote
> While basenameWithoutExtension is an intension revealing selector it is
> soon ln :-)  For file manipulation code that's a problem.   I
> wonder if something like bodyName is better because it's shorter.

While I too feel a bit of pain from the long selector, I have reservations
with #bodyName because I already know I will not remember what that means
and will have to constantly look it up. IIRC we already have #base and
#basename, which seem to be made up labels for subtle distinctions and I can
never remember the difference. I think the domain here is nuanced enough to
defy simple labels. I remember when we first integrated FS there was
confusion/unworkability around "extension" vs. "extensions" for e.g.
/myfile.tar.zip vs. /mypackage.1.mcz



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/19609-FileReference-base-should-be-before-last-separator-tp4961729p4962586.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Lowering the pain of newbies

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> any idea is welcome

From
http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-td4859734.html
:
Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System
   
https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst-Var-name-Allowed-But-Breaks-System



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Lowering-the-pain-of-newbies-tp4961937p4962584.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Github and Fogbugz integration

[Dimitris Chloupis]

On Sat, Aug 19, 2017 at 10:32 PM Sean P. DeNigris 
wrote:

> > I see little reason not to allow both ways of reporting bugs.
> It seems that the need to create an account in FB to even view/search
> issues has been a big barrier to new(er) would-be contributors. I expect
> this difficulty would be multiplied since, in the process of reporting a
> bug on GH, they would not be able to easily determine if it had already
> been opened on FB


Tons of issues are reported in GH that are closed minutes as the issue they
report does not even exist. Closing an issue is just a matter of pressing a
button and you can always redirect the user to the issue in FB.

Frankly I am no fan of FB, I find Github interface less powerful but far
simpler and better designed. What annoyed me is that fogbuz did not even
subscribed me to my own issues (issues I created) . I did not go back
because I thought people ignored me , then one day I decided to create a
new bug report and found out that people have replied almost immediately to
my old ones. Then I realised that Fogbuz did not alert me through email ,
then I dig up its settings and found the way enable email alerts. Suffice
to say I was not very happy with this.

I prefer GH also because I have already been using it with Python way
before I was introduced into Pharo, so its not just newcomer who will
prefer GH , I think the vast majority of people coming from other languages
will do too. GH is almost a monopoly at this point.

Pretty much every one says moving to git and github will be costly , like
Stef just did. Blender made the move I think a year ago, so much noise in
the mailing list whether its really worth it moving from svn to git more
than 1 million line of code and more than a decade of commits. Later
admitted it was far easier than they expected.

Point is that people are lazy, we are just are, and we like to keep doing
things we are familiar with because learning is hard. Problem is not
learning is far more costly.

I have been a defender of git and github in the pharo mailing lists for
years now even though many resisted me and tried to convince me how Pharo
and git will never properly work and here we are, not regretting a second
of it and I am sure that other people who were supportive too dont either.

But I never forced my opinion on anyone and I wont now. I am just saying ,
if I have the choice between github and fogbuz, for me its github all the
way. Likewise if its iceberger vs gitup , gitup all the way.

On the other hand , its great to live in a time having so many choices ;)

Re: [Pharo-dev] Github and Fogbugz integration

[Sean P. DeNigris]

> I see little reason not to allow both ways of reporting bugs. 
It seems that the need to create an account in FB to even view/search issues 
has been a big barrier to new(er) would-be contributors. I expect this 
difficulty would be multiplied since, in the process of reporting a bug on GH, 
they would not be able to easily determine if it had already been opened on FB




-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Github-and-Fogbugz-integration-tp4960676p4962547.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Github and Fogbugz integration

[Cyril Ferlicot]

On sam. 19 août 2017 at 21:14, Dimitris Chloupis 
wrote:

> Useless piece of info , I think I am the first person to actually create a
> github issue for Pharo. It was not for pharo code it was for pharo
> documentation
>
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/1
>
> Since then not only UPBE but also other pharo doc github repos have been
> using github issues , so we already doing that and none has blamed me
>
> so far
>
> :D
>


I think this thread is about Pharo in itself. The github project
"pharo-project/pharo". Not about the documentation or the independent
projects as Pillar, Voyage & co.

> --
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-dev] Github and Fogbugz integration

[Dimitris Chloupis]

Useless piece of info , I think I am the first person to actually create a
github issue for Pharo. It was not for pharo code it was for pharo
documentation

https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/1

Since then not only UPBE but also other pharo doc github repos have been
using github issues , so we already doing that and none has blamed me

so far

:D

On Sat, Aug 19, 2017 at 10:00 PM Stephane Ducasse 
wrote:

> Hi sean
>
> I prefer to continue to use fogbugz. Changing is really costly.
>
> Stef
>
> On Sat, Aug 19, 2017 at 6:48 PM, Sean P. DeNigris 
> wrote:
> > Guillermo Polito wrote
> >> Sadly, this just works for the integration of commits into the main
> >> branches, not pull requests. For pull request integration we will
> probably
> >> need a home made solution.
> >
> > Now that we are moving development to GH, has there been any discussion
> of
> > moving issue tracking there as well?
> >
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > View this message in context:
> http://forum.world.st/Github-and-Fogbugz-integration-tp4960676p4962533.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
> >
>
>

Re: [Pharo-dev] Latest Debian, Ubuntu and CentOS packages of the pharo-vm

[Stephane Ducasse]

Tx Holger
Really tx.


On Fri, Aug 18, 2017 at 11:54 AM, Holger Freyther  wrote:
> Hi,
>
> when running Pharo in production you might want to install the image and a VM 
> from distribution packages. So far there were no current public packages and 
> during the last months I have modernized the debian packaging and recently 
> added CentOS rpm packaging as well. The process of generating new source 
> packages is integrated into the pharo-vm travis-ci build as well.
>
> Every time that master of pharo-vm.git is updated a new source package will 
> be uploaded to the Open(SUSE) Build Service and new packages will be built 
> and are available in a "latest" package feed. The generated (and used) 
> sourcecode is inside the source package and will be archived by the OBS 
> platform (one can even nicely diff versions). The "stable" VM is not built 
> from pharo-vm.git (yet?) so it doesn't show on OBS yet.
>
> Below are some semi-tested installation notes in case you want to try it out. 
> The binary names are picked to allow to install the 32bit and 64bit VM in 
> parallel. The names currently are:
>
> - pharo6-32 (32bit version)
> - pharo6-64 (64bit version)
> - pharo6-32-ui  (32bit version with X11 dependencies)
> - pharo6-64-ui  (64bit version with X11 dependencies)
>
>
> CentOS 6.8:
>
> # Add the repo
> $ yum-config-manager --add-repo 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo
>
> # Install 32bit packages (with X11 dependency for *-ui or not)
>
> $ yum install pharo6-32-ui.i686 or pharo6-32.i386
>
> # Install 64bit packages
>
> $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
>
>
>
> CentOS 7 (only 64bit):
>
>
> $ yum-config-manager --add-repo 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_7/devel:languages:pharo:latest.repo
> $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
>
>
> Debian 8:
>
> # Add signing key
> $ wget -O - 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/Debian_8.0/Release.key
>  | apt-key add -
>
> # Update and install
> $ apt update
> $ apt install pharo6-32-ui pharo6-64-ui(or pharo6-32 or pharo6-64)
>
> Ubuntu 14.04 LTS
>
> # Add signing key
> $ wget -O - 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/xUbuntu_14.04/Release.key
>  | apt-key add -
>
> # Update and install
> $ apt update
> $ apt install pharo6-32-ui pharo6-64-ui
>
> Ubuntu 16.04
>
> # Add signing key
> $ wget -O - 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/xUbuntu_16.04/Release.key
>  | apt-key add -
>
> # Update and install
> $ apt update
> $ apt install pharo6-32-ui pharo6-64-ui
>
>
>

Re: [Pharo-dev] Github and Fogbugz integration

[Stephane Ducasse]

Hi sean

I prefer to continue to use fogbugz. Changing is really costly.

Stef

On Sat, Aug 19, 2017 at 6:48 PM, Sean P. DeNigris  wrote:
> Guillermo Polito wrote
>> Sadly, this just works for the integration of commits into the main
>> branches, not pull requests. For pull request integration we will probably
>> need a home made solution.
>
> Now that we are moving development to GH, has there been any discussion of
> moving issue tracking there as well?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Github-and-Fogbugz-integration-tp4960676p4962533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Re: [Pharo-dev] Github and Fogbugz integration

[Dimitris Chloupis]

Well technically you cannot stop people from using the github issue tracker
for reporting bugs and by default if you are a contributor to a repo you
will be alerted via email of new issues or replies to existing github
issues.

Both github and forgbuz issue tracker can happily coexist. There will be
also little need create same issues on both githyb and fogbuz because there
will be little benefit , both are quite efficient on what they do , I see
little reason not to allow both ways of reporting bugs.

Github has a bit the edge here because of how it handles pull requests
which it separates from issues and it allows you to start discussions on
top of the code to be merged etc. Again this is a technical detail, the
important thing is to report bugs and to fix them , how you do it is a
lesser concern.

Github has also other advantages that I am not so familiar , especially
with CI. Right now CI for Pharo is separate , this is also can be brought
to gitgub in some way without actually moving the CI and have Github as a
main hub for commits, issue reporting, CI discussions and free wiki and a
static website (maybe as a more permanent version of the wiki).

https://github.com/marketplace/category/continuous-integration

Github is actually extremely flexible. Gitlab is even more so , cause its
full open source and allow you to host it on your own servers and you do
not need to relearn what you learned with Github as it follows a very
similar interface. Gitlab allows to move repos from github and will copy
not just the code but also issues etc. So that is also a good solution for
some people who may way to have Pharo dev on their own server and more
control of it.

A rather new feature for Github is also projects, a way to visualise todo
lists, roadmaps, pull requests etc

https://help.github.com/articles/about-project-boards/

It also offers way to visualise other things like commits, issues etc

and last but not least it can host downloads of releases so there is a
convenient and obvious way to find the latest but also previous versions of
pharo with Github releases

https://help.github.com/articles/creating-releases/



On Sat, Aug 19, 2017 at 7:51 PM Sean P. DeNigris 
wrote:

> Guillermo Polito wrote
> > Sadly, this just works for the integration of commits into the main
> > branches, not pull requests. For pull request integration we will
> probably
> > need a home made solution.
>
> Now that we are moving development to GH, has there been any discussion of
> moving issue tracking there as well?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Github-and-Fogbugz-integration-tp4960676p4962533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Github and Fogbugz integration

[Sean P. DeNigris]

Guillermo Polito wrote
> Sadly, this just works for the integration of commits into the main
> branches, not pull requests. For pull request integration we will probably
> need a home made solution.

Now that we are moving development to GH, has there been any discussion of
moving issue tracking there as well?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Github-and-Fogbugz-integration-tp4960676p4962533.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Ugly smell: really long symbols/selectors

[Sean P. DeNigris]

Denis Kudriashov wrote
> Which is actually shows that tests as methods are not really good idea.
> Tests are supposed to be documentation but with classic SUnit we have only
> two ways (classes and methods) to decompose them which is definitely not
> enough for docs.

He he +100. I remember us talking about this a long time ago. I have a
vision for something like rspec, but with a domain UI and then have the
classes/methods/whatever storage as an implementation detail.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Ugly-smell-really-long-symbols-selectors-tp4961544p4962532.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Latest Debian, Ubuntu and CentOS packages of the pharo-vm

[Sean P. DeNigris]

Holger Freyther wrote
> Every time that master of pharo-vm.git is updated a new source package
> will be uploaded to the Open(SUSE) Build Service and new packages will be
> built and are available in a "latest" package feed.

Awesome!! Esteban and I have wanted this for a long time but were unable to
devote the time to figure out how to get it working. Out of curiosity, where
can I see how it was set up/configured? There is a "Project Config" tab
which seems to be empty...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Latest-Debian-Ubuntu-and-CentOS-packages-of-the-pharo-vm-tp4962000p4962531.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [ Pharo 70 ] Build 44 PR 175 Space-analysis-resurrection

[Stephane Ducasse]

[ Pharo 70 ] Build 44 PR 175 Space-analysis-resurrection
https://pharo.fogbugz.com/f/cases/20230/Space-analysis-resurrection
https://github.com/pharo-project/pharo/pull/175

Re: [Pharo-dev] Little extensions to easily manage file versions

[Stephane Ducasse]

No I will have a look :)
But I also need latestVersion because you need the two: to always load
the latest and save latest + 1
Stef

On Fri, Aug 18, 2017 at 11:38 PM, Denis Kudriashov  wrote:
> Do you know that there is #nextVersion method in FileReference?
>
> 2017-08-18 22:04 GMT+02:00 Stephane Ducasse :
>>
>> Hi
>>
>> I really like (when I save little data files) to have a simple versioning.
>> For example for my game collection I have
>> Games.1.ston
>> Games.2.ston
>> ...
>> and I like that this is managed for me by the system.
>>
>> I harvested this functionality from squeak long time ago.
>> I rewrote it fast and dirty in Pharo. I find this two methods super
>> handy and they provide cheap versioning for little files.
>>
>>
>>
>> lastNameFor: baseFileName extension: extension
>>"Assumes a file name includes a version number encoded as '.'
>> followed by digits
>>preceding the file extension, e.g., games.22.ston
>>Answer the file name with the largest number.
>>If a version number is not found, raises an error"
>>
>>"FileSystem workingDirectory lastNameFor: 'games' extension: 'ston'"
>>
>> | files |
>> files := self childrenMatching: baseFileName , '.*.' , extension.
>> files ifEmpty: [ ^ self error: 'No file with number pattern' ].
>> ^ (files asSortedCollection: [ :a :b | a basename < b basename ]) last
>>
>> nextNameFor: baseFileName extension: extension
>>"Assumes a file name includes a version number encoded as '.'
>> followed by digits
>>preceding the file extension, e.g., games.22.ston
>>Increment the version number (of the largest one) and answer the
>> new file name, e.g., games23.ston
>>If a version number is not found, set the version to 1 and answer a
>> new file name"
>>
>> "FileSystem workingDirectory nextNameFor: 'games' extension: 'ston'"
>>
>> | files splits version |
>> files := self childrenMatching: baseFileName , '.*.' , extension.
>> files ifEmpty: [ ^ baseFileName , '.1.' , extension ].
>> splits := files
>>  collect: [ :filename | filename basename splitOn: $. ]
>>  thenSelect: [ :split | (split at: 1) = baseFileName and: [
>> split size = 3 ] ].
>>  splits := splits asSortedCollection: [ :a :b | (a at: 2) < (b at: 2)
>> ].
>>  version := splits isEmpty
>> ifTrue: [ 1 ]
>> ifFalse: [ (splits last at: 2) asNumber + 1 ].
>>  ^ baseFileName , '.' , version asString , '.' , extension
>>
>> I think that these to methods can be a valuable addition to
>> fileReference (the methods can be better implemented).
>>
>> Let me know what you think.
>>
>> https://pharo.fogbugz.com/f/cases/20324/Handy-file-automatic-numbering
>>
>> Stef
>>
>