Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #77031 > unrolled thread

Re: Python vs C++

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python vs C++ Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-08-26 10:12 +0200
    Re: Python vs C++ alex23 <wuwei23@gmail.com> - 2014-08-27 15:43 +1000
      Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-27 00:23 -0600
      Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-27 00:33 -0600
      Re: What is acceptable as 'open-source'?  [was Python vs C++] "Frank Millman" <frank@chagford.com> - 2014-08-27 09:50 +0200
        Re: What is acceptable as 'open-source'? Paul Rubin <no.email@nospam.invalid> - 2014-08-27 09:38 -0700
          Re: What is acceptable as 'open-source'? Marko Rauhamaa <marko@pacujo.net> - 2014-08-27 20:14 +0300
            Re: What is acceptable as 'open-source'? Rustom Mody <rustompmody@gmail.com> - 2014-08-27 10:41 -0700
            Re: What is acceptable as 'open-source'? Chris Angelico <rosuav@gmail.com> - 2014-08-28 08:46 +1000
              Re: What is acceptable as 'open-source'? Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 08:31 +0300
                Re: What is acceptable as 'open-source'? Chris Angelico <rosuav@gmail.com> - 2014-08-28 15:44 +1000
        Re: What is acceptable as 'open-source'?  [was Python vs C++] Christian Gollwitzer <auriocus@gmx.de> - 2014-08-27 21:41 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] Chris Angelico <rosuav@gmail.com> - 2014-08-27 18:03 +1000
      Re: What is acceptable as 'open-source'?  [was Python vs C++] Ned Batchelder <ned@nedbatchelder.com> - 2014-08-27 07:54 -0400
        Re: What is acceptable as 'open-source'?  [was Python vs C++] Rustom Mody <rustompmody@gmail.com> - 2014-08-27 10:29 -0700
          hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Ethan Furman <ethan@stoneleaf.us> - 2014-08-27 11:26 -0700
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Skip Montanaro <skip@pobox.com> - 2014-08-27 13:51 -0500
            Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 08:58 +0300
              Re: hg, git, fossil, ... Tim Chase <python.list@tim.thechases.com> - 2014-08-28 09:56 -0500
              Re: hg, git, fossil, ... Ned Batchelder <ned@nedbatchelder.com> - 2014-08-28 11:39 -0400
                Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 19:17 +0300
                  Re: hg, git, fossil, ... Tim Chase <python.list@tim.thechases.com> - 2014-08-28 11:32 -0500
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 02:38 +1000
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 22:37 +0300
                      Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 09:08 +1000
                      Re: hg, git, fossil, ... Lele Gaifax <lele@metapensiero.it> - 2014-08-29 09:43 +0200
                        Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:54 +0300
                  Re: hg, git, fossil, ... Terry Reedy <tjreedy@udel.edu> - 2014-08-28 13:40 -0400
                  Re: hg, git, fossil, ... Tim Delaney <timothy.c.delaney@gmail.com> - 2014-08-29 07:25 +1000
                  Re: hg, git, fossil, ... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-28 22:41 +0100
                  Re: hg, git, fossil, ... Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-28 20:20 -0600
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 08:59 +0300
                      Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 17:20 +1000
                        Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:48 +0300
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 12:24 +1000
                    Re: hg, git, fossil, ... Rustom Mody <rustompmody@gmail.com> - 2014-08-28 19:53 -0700
              Re: hg, git, fossil, ... Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-28 19:56 -0600
                Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 08:50 +0300
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 17:19 +1000
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:43 +0300
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Ethan Furman <ethan@stoneleaf.us> - 2014-08-27 11:58 -0700
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Chris Angelico <rosuav@gmail.com> - 2014-08-28 09:07 +1000
      Re: Python vs C++ Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-08-27 15:15 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] "Frank Millman" <frank@chagford.com> - 2014-08-28 15:44 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] Chris Angelico <rosuav@gmail.com> - 2014-08-28 23:58 +1000

Page 1 of 3  [1] 2 3  Next page →

#77031 — Re: Python vs C++

[Multipart message — attachments visible in raw view] — view raw

2014-08-26 6:02 GMT+02:00 Ian Kelly <ian.g.kelly@gmail.com>:

> On Mon, Aug 25, 2014 at 4:52 AM, Amirouche Boubekki <
> amirouche.boubekki@gmail.com> wrote:
> >  - I am a big fan of Final Fantasy games, it seems to be an easy game
> experience to code
>
> Maybe not so easy, if the horrifying number of bugs in the early games of
> the series are any indication.
>

I started with FF VII, I don't remember any bugs.


>
> I'm not sure what makes this a C++ project in any case.
>

True.


> It would be just as easy or easier in Python, or one could save a lot more
> effort by just using RPG Maker like every other indie RPG developer seems
> to do.
>

I don't think there is FLOSS equivalent.

Anyway, I have other ideas:

- An "after effect" equivalent
- This might be the same thing as the above, a live processing of vidéos. I
tried using python bindings of gstreamer six months ago, I failed. Part of
the failure is that g-software suite doesn't care much about this usecase.
- port torus trooper to C++ (
http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html)
- Contribute to cling, cern's C++ interpreter based on llvm
<http://root.cern.ch/drupal/content/cling>. I think PyPy people are
interested to use it too.

[toc] | [next] | [standalone]

#77103

On 26/08/2014 6:12 PM, Amirouche Boubekki wrote:
> 2014-08-26 6:02 GMT+02:00 Ian Kelly <ian.g.kelly@gmail.com
> <mailto:ian.g.kelly@gmail.com>>:
>     It would be just as easy or easier in Python, or one could save a
>     lot more effort by just using RPG Maker like every other indie RPG
>     developer seems to do.
>
> I don't think there is FLOSS equivalent.

There is indeed:

http://openrpgmaker.sourceforge.net/

[toc] | [prev] | [next] | [standalone]

#77106

On Tue, Aug 26, 2014 at 11:43 PM, alex23 <wuwei23@gmail.com> wrote:
> On 26/08/2014 6:12 PM, Amirouche Boubekki wrote:
>>
>> 2014-08-26 6:02 GMT+02:00 Ian Kelly <ian.g.kelly@gmail.com
>> <mailto:ian.g.kelly@gmail.com>>:
>>
>>     It would be just as easy or easier in Python, or one could save a
>>     lot more effort by just using RPG Maker like every other indie RPG
>>     developer seems to do.
>>
>> I don't think there is FLOSS equivalent.
>
>
> There is indeed:
>
> http://openrpgmaker.sourceforge.net/

Ugh. There seems to be no public repository, and the only source to be
found is from release-versioned tarballs, so there's apparently no
collaboration other than some forums for reporting bugs and requesting
features. All the work is done by one developer in his spare time, and
he is currently on hiatus since April. Meanwhile the most recent
release is February, so it's not like somebody could just pick it up
and start hacking and expect to merge.

That's only open-source under the most literal of definitions.

[toc] | [prev] | [next] | [standalone]

#77107

On Wed, Aug 27, 2014 at 12:23 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 11:43 PM, alex23 <wuwei23@gmail.com> wrote:
>> On 26/08/2014 6:12 PM, Amirouche Boubekki wrote:
>>>
>>> 2014-08-26 6:02 GMT+02:00 Ian Kelly <ian.g.kelly@gmail.com
>>> <mailto:ian.g.kelly@gmail.com>>:
>>>
>>>     It would be just as easy or easier in Python, or one could save a
>>>     lot more effort by just using RPG Maker like every other indie RPG
>>>     developer seems to do.
>>>
>>> I don't think there is FLOSS equivalent.
>>
>>
>> There is indeed:
>>
>> http://openrpgmaker.sourceforge.net/
>
> Ugh. There seems to be no public repository, and the only source to be
> found is from release-versioned tarballs, so there's apparently no
> collaboration other than some forums for reporting bugs and requesting
> features. All the work is done by one developer in his spare time, and
> he is currently on hiatus since April. Meanwhile the most recent
> release is February, so it's not like somebody could just pick it up
> and start hacking and expect to merge.
>
> That's only open-source under the most literal of definitions.

And the license is GPL, which I think is an unfortunate choice for a
game maker, since it probably means that any games developed using it
must themselves be distributed libre and open-source.

[toc] | [prev] | [next] | [standalone]

#77116 — Re: What is acceptable as 'open-source'? [was Python vs C++]

"Ian Kelly" <ian.g.kelly@gmail.com> wrote in message 
news:CALwzidkRO_hrYamwXBk0go-w1OJ6Ty6mYB_c5vHXB6okGOLg6g@mail.gmail.com...
>
> Ugh. There seems to be no public repository, and the only source to be
> found is from release-versioned tarballs, so there's apparently no
> collaboration other than some forums for reporting bugs and requesting
> features. All the work is done by one developer in his spare time, and
> he is currently on hiatus since April. Meanwhile the most recent
> release is February, so it's not like somebody could just pick it up
> and start hacking and expect to merge.
>
> That's only open-source under the most literal of definitions.

This is quite a timely message for me. I am inching closer to releasing a 
version of my accounting software, and a lot of the above comments apply to 
me as well. At present I am the only developer, and my project is not hosted 
anywhere, so I have to decide how to make it available, and I am open to 
suggestions.

I have had two attempts at running an hg repository locally, and I am afraid 
that I am not keeping it up to date. I do have a master copy, but I have 
made so many changes in my clone that a merge will not make any sense, so I 
will have to start afresh. I think that making it public will be the only 
way that I can force myself to update it regularly.

I could stick to hg (or git) but I have recently come across fossil, and it 
seems ideal for my needs. Has anyone used it? It seems to have everything it 
needs (a wiki and a ticketing system) for self-hosting, and I have my own 
domain that I have not activated yet, so maybe I should just use fossil and 
host it myself. Any comments?

There is no test suite (shock, horror). I have not got my head around that 
yet. The things that I could write tests for are so trivial that they don't 
seem worth the effort, and the things that cause me problems are so complex, 
because they depend on exactly what features have been activated, that the 
permutations are endless and I don't know where to start. However, once it 
is public, if someone is prepared to do a bit of mentoring, I will start to 
fill the gap.

Documentation is a mess. I did start using Sphinx a while ago, so there is a 
sprinkling of rest-format docstrings, but they have not been kept 
up-to-date, and in some cases are out of date. There are plenty of other 
comments in the code, mostly reminders to myself about various issues. I 
don't know open-source etiquette. Should I spend the time to sort this out 
before going public, or is it acceptable to leave it as is for now?

Any other comments?

Frank Millman

[toc] | [prev] | [next] | [standalone]

#77145 — Re: What is acceptable as 'open-source'?

"Frank Millman" <frank@chagford.com> writes:
> I could stick to hg (or git) but I have recently come across fossil,
> and it seems ideal for my needs. Has anyone used it? 

I've played with it.  It's incredibly impressive for such a
comparatively small program.  But, it's kind of niche, and even hg has
become niche, everyone is using git now.  Self-hosting git repositories
can be pretty simple, nearly trivial with git-daemon, or slightly
fancier with gitweb.  There are also full-on fancy solutions like gitlab
or gitstar: I'm not up on the latest of these things.

> There is no test suite (shock, horror). I have not got my head around
> that yet. The things that I could write tests for are so trivial

In my experience, writing tests for existing code is a big pain in the
neck and doesn't really get good coverage.  The best way to write tests
is with a development style where you write the tests at the same time
that you write the code.  This will have implications for the way the
code is organized, so it's much harder to retrofit tests after the fact.
But at least, you can write some integration tests.  I'm old-fashioned
and use dejagnu for that.  I think there's newer and trendier stuff now
though.

[toc] | [prev] | [next] | [standalone]

#77146 — Re: What is acceptable as 'open-source'?

Paul Rubin <no.email@nospam.invalid>:

> "Frank Millman" <frank@chagford.com> writes:
>> I could stick to hg (or git) but I have recently come across fossil,
>> and it seems ideal for my needs. Has anyone used it?
>
> I've played with it. It's incredibly impressive for such a
> comparatively small program.

Thanks for the tip. I've been looking for the magic bullet since I had
to abandon Sun's TeamWare years back. Unfortunately, fossil seems to
suffer from the same problem as git and hg: they all consider the whole
repository to be the version-controlled "file". There are no independent
changes; parallel changes always result in a conflict that requires
merging.

Darcs apparently tries to be the scientific choice that combines the
best of CVS and git. However, I'm not at all sure that scientific
precision is truly needed.

What I'd like is a hg/git that treated each file independently. That is,
in hg/git terms, consider each file a separate repository.


Marko

[toc] | [prev] | [next] | [standalone]

#77150 — Re: What is acceptable as 'open-source'?

On Wednesday, August 27, 2014 10:44:37 PM UTC+5:30, Marko Rauhamaa wrote:
> Paul Rubin :

> > "Frank Millman" writes:
> >> I could stick to hg (or git) but I have recently come across fossil,
> >> and it seems ideal for my needs. Has anyone used it?
> > I've played with it. It's incredibly impressive for such a
> > comparatively small program.

> Thanks for the tip. I've been looking for the magic bullet since I had
> to abandon Sun's TeamWare years back. Unfortunately, fossil seems to
> suffer from the same problem as git and hg: they all consider the whole
> repository to be the version-controlled "file". There are no independent
> changes; parallel changes always result in a conflict that requires
> merging.

> Darcs apparently tries to be the scientific choice that combines the
> best of CVS and git. However, I'm not at all sure that scientific
> precision is truly needed.

> What I'd like is a hg/git that treated each file independently. That is,
> in hg/git terms, consider each file a separate repository.

See vcsh

vcsh allows you to maintain several Git repositories in one single
directory. They all maintain their working trees without clobbering
each other or interfering otherwise. By default, all Git repositories
maintained via vcsh store the actual files in $HOME but you can
override this setting if you want to.

of course theres also the classic rcs

[toc] | [prev] | [next] | [standalone]

#77171 — Re: What is acceptable as 'open-source'?

On Thu, Aug 28, 2014 at 3:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Thanks for the tip. I've been looking for the magic bullet since I had
> to abandon Sun's TeamWare years back. Unfortunately, fossil seems to
> suffer from the same problem as git and hg: they all consider the whole
> repository to be the version-controlled "file". There are no independent
> changes; parallel changes always result in a conflict that requires
> merging.

This is a feature, not a problem. As far as most version control
systems are concerned, files aren't independent. However, the merge
should be trivially easy if it's different files that have changed.

If what you're concerned about is the number of merge commits, the
easiest solution is to perform rebase pulls (or to rebase a change
onto the latest tree, depending on your point of view). That's not as
easy with github's fork/merge philosophy as it is with your own
commits, but I find it's extremely easy with a pull/push model, and
not too hard with other models.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77182 — Re: What is acceptable as 'open-source'?

Chris Angelico <rosuav@gmail.com>:

> On Thu, Aug 28, 2014 at 3:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> parallel changes always result in a conflict that requires merging.
>
> This is a feature, not a problem. As far as most version control
> systems are concerned, files aren't independent. However, the merge
> should be trivially easy if it's different files that have changed.

I'd venture to say files are quite independent most of the time. That's
why such merges have been facilitated to the point that negates the
"feature" you mentioned. Nobody cares to take the trouble of analyzing
the validity of automatic merges.

I have a hunch that the "feature" has more to do with conceptual
simplification and performance optimization than some theoretical
principle. As a theoretical principle, it is far too blunt (unlike in
Darcs). In practice, parallel, independent changes are the norm, not the
exception, but git and hg just don't support them.

Oh, well. The damage is insignificant if your repositories are small
(~ 20 files).

> If what you're concerned about is the number of merge commits, the
> easiest solution is to perform rebase pulls (or to rebase a change
> onto the latest tree, depending on your point of view). That's not as
> easy with github's fork/merge philosophy as it is with your own
> commits, but I find it's extremely easy with a pull/push model, and
> not too hard with other models.

I'm glad to have seen the perfect world. I can only assume that
bitkeeper (whose author was among the TeamWare developers) would follow
the same principles, although I haven't ever tried it.


Marko

[toc] | [prev] | [next] | [standalone]

#77184 — Re: What is acceptable as 'open-source'?

On Thu, Aug 28, 2014 at 3:31 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> I'd venture to say files are quite independent most of the time. That's
> why such merges have been facilitated to the point that negates the
> "feature" you mentioned. Nobody cares to take the trouble of analyzing
> the validity of automatic merges.

Okay. Imagine a big C program (hundreds of .c files) and the latest
build segfaults on certain input. You know that 60 commits ago it
wasn't segfaulting. Now, you have two options:

1) Work with the repo as an entire whole, and bisect those 60 commits
in about six steps, to find when the segfault began.
2) Look through which files have been changed, which might be a couple
dozen, and treat each file's changes separately.

I know which I'd rather do. The project is one thing, regardless of
how many files it is, and a successful build might not even be
possible if you get mismatched versions. I call it a feature.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77157 — Re: What is acceptable as 'open-source'? [was Python vs C++]

Am 27.08.14 09:50, schrieb Frank Millman:
> This is quite a timely message for me. I am inching closer to releasing a
> version of my accounting software, and a lot of the above comments apply to
> me as well. At present I am the only developer, and my project is not hosted
> anywhere, so I have to decide how to make it available, and I am open to
> suggestions.
 >
> [...]
 >
> I could stick to hg (or git) but I have recently come across fossil, and it
> seems ideal for my needs. Has anyone used it? It seems to have everything it
> needs (a wiki and a ticketing system) for self-hosting, and I have my own
> domain that I have not activated yet, so maybe I should just use fossil and
> host it myself. Any comments?

Fossil is indeed an impressive piece. It comes from Richard Hipp, the 
guy behind SQLite, and it's currently in use to manage the Tcl/Tk 
sources. If you want to do the hosting yourself, it can be a good choice.

I myself decided not to use it, but instead use git with github. The 
reasons:

- github offers much more than plain git; you can host a website in the 
repo, included is a (rudimentary) templating engine, which allows to 
write your docs in simple markdown [*]

- the github frontpage makes it easier to download a tarball of the 
project. In the fossil website it's quite hard to find

- github gives the server storage for free to open source projects

- there is a "social network" - anybody who wants to contribute, can 
send you pull requests via github

- For large projects, git is much faster than fossil to update the repo.

The good news: you can migrate from fossil to git; e.g. the tcl/tk repos 
are mirrored to github. For fossil, there is also public storage space 
e.g. on chiselapp.com as an alternative

	Christian

[*] in case you are curious, this is the website of my repo:
http://auriocus.github.io/VecTcl/
The content is all done in markdown, including math and syntax 
highlighting, and the template was adopted from one of the designs 
offered from github

[toc] | [prev] | [next] | [standalone]

#77117 — Re: What is acceptable as 'open-source'? [was Python vs C++]

On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman <frank@chagford.com> wrote:
>
> This is quite a timely message for me. I am inching closer to releasing a
> version of my accounting software, and a lot of the above comments apply to
> me as well. At present I am the only developer, and my project is not hosted
> anywhere, so I have to decide how to make it available, and I am open to
> suggestions.
>
> I have had two attempts at running an hg repository locally, and I am afraid
> that I am not keeping it up to date. I do have a master copy, but I have
> made so many changes in my clone that a merge will not make any sense, so I
> will have to start afresh. I think that making it public will be the only
> way that I can force myself to update it regularly.

Then you need to develop a new style of working, which plays more
nicely with source control. Instead of hacking on whatever you feel
like doing and then committing to source control later, make each
change and immediately commit it. Get into the habit of putting useful
commit messages onto your changes. As you say, making it public will
help you force yourself to keep that up-to-date.

> I could stick to hg (or git) but I have recently come across fossil, and it
> seems ideal for my needs. Has anyone used it? It seems to have everything it
> needs (a wiki and a ticketing system) for self-hosting, and I have my own
> domain that I have not activated yet, so maybe I should just use fossil and
> host it myself. Any comments?

I haven't used fossil personally, but I'm not really a fan of
all-in-one systems; they're somewhat inflexible. If you don't like the
wiki, you're stuck with it. I'd rather work with all the parts
separately - change one and it doesn't affect anything else.

But if all fossil's parts suit you, then by all means, use it!

> Documentation is a mess. I did start using Sphinx a while ago, so there is a
> sprinkling of rest-format docstrings, but they have not been kept
> up-to-date, and in some cases are out of date. There are plenty of other
> comments in the code, mostly reminders to myself about various issues. I
> don't know open-source etiquette. Should I spend the time to sort this out
> before going public, or is it acceptable to leave it as is for now?

Go public first, and watch what people get confused at - then document
those parts. If you try to document everything first, you'll spend
heaps of time and effort on it, and maybe won't even be happy with the
result.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77125 — Re: What is acceptable as 'open-source'? [was Python vs C++]

On 8/27/14 3:50 AM, Frank Millman wrote:
>
> "Ian Kelly" <ian.g.kelly@gmail.com> wrote in message
> news:CALwzidkRO_hrYamwXBk0go-w1OJ6Ty6mYB_c5vHXB6okGOLg6g@mail.gmail.com...
>>
>> Ugh. There seems to be no public repository, and the only source to be
>> found is from release-versioned tarballs, so there's apparently no
>> collaboration other than some forums for reporting bugs and requesting
>> features. All the work is done by one developer in his spare time, and
>> he is currently on hiatus since April. Meanwhile the most recent
>> release is February, so it's not like somebody could just pick it up
>> and start hacking and expect to merge.
>>
>> That's only open-source under the most literal of definitions.
>
> This is quite a timely message for me. I am inching closer to releasing a
> version of my accounting software, and a lot of the above comments apply to
> me as well. At present I am the only developer, and my project is not hosted
> anywhere, so I have to decide how to make it available, and I am open to
> suggestions.
>
> I have had two attempts at running an hg repository locally, and I am afraid
> that I am not keeping it up to date. I do have a master copy, but I have
> made so many changes in my clone that a merge will not make any sense, so I
> will have to start afresh. I think that making it public will be the only
> way that I can force myself to update it regularly.

You don't need a "local hg repo", you just need a working tree.  I 
recommend choosing either hg or git, and then using BitBucket or Github, 
and being done with it.

>
> I could stick to hg (or git) but I have recently come across fossil, and it
> seems ideal for my needs. Has anyone used it? It seems to have everything it
> needs (a wiki and a ticketing system) for self-hosting, and I have my own
> domain that I have not activated yet, so maybe I should just use fossil and
> host it myself. Any comments?

Fossil is one of those technologies that is very attractive in and of 
itself, but is so under-adopted that it will itself be a barrier to 
collaboration.  (Frankly, hg is getting to that category also.)

>
> There is no test suite (shock, horror). I have not got my head around that
> yet. The things that I could write tests for are so trivial that they don't
> seem worth the effort, and the things that cause me problems are so complex,
> because they depend on exactly what features have been activated, that the
> permutations are endless and I don't know where to start. However, once it
> is public, if someone is prepared to do a bit of mentoring, I will start to
> fill the gap.
>
> Documentation is a mess. I did start using Sphinx a while ago, so there is a
> sprinkling of rest-format docstrings, but they have not been kept
> up-to-date, and in some cases are out of date. There are plenty of other
> comments in the code, mostly reminders to myself about various issues. I
> don't know open-source etiquette. Should I spend the time to sort this out
> before going public, or is it acceptable to leave it as is for now?

Go public first.  People might look at your repo and say, "ugh, this is 
a mess, I'm not going to help here," but the alternative is them saying, 
"there is no public repo, and therefore no project, ..."

>
> Any other comments?
>
> Frank Millman
>
>
>


-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#77148 — Re: What is acceptable as 'open-source'? [was Python vs C++]

On Wednesday, August 27, 2014 5:24:40 PM UTC+5:30, Ned Batchelder wrote:
> On 8/27/14 3:50 AM, Frank Millman wrote:
> > "Ian Kelly"  wrote in message
> >> Ugh. There seems to be no public repository, and the only source to be
> >> found is from release-versioned tarballs, so there's apparently no
> >> collaboration other than some forums for reporting bugs and requesting
> >> features. All the work is done by one developer in his spare time, and
> >> he is currently on hiatus since April. Meanwhile the most recent
> >> release is February, so it's not like somebody could just pick it up
> >> and start hacking and expect to merge.
> >> That's only open-source under the most literal of definitions.
> > This is quite a timely message for me. I am inching closer to releasing a
> > version of my accounting software, and a lot of the above comments apply to
> > me as well. At present I am the only developer, and my project is not hosted
> > anywhere, so I have to decide how to make it available, and I am open to
> > suggestions.
> > I have had two attempts at running an hg repository locally, and I am afraid
> > that I am not keeping it up to date. I do have a master copy, but I have
> > made so many changes in my clone that a merge will not make any sense, so I
> > will have to start afresh. I think that making it public will be the only
> > way that I can force myself to update it regularly.

> You don't need a "local hg repo", you just need a working tree.  I 
> recommend choosing either hg or git, and then using BitBucket or Github, 
> and being done with it.

> > I could stick to hg (or git) but I have recently come across fossil, and it
> > seems ideal for my needs. Has anyone used it? It seems to have everything it
> > needs (a wiki and a ticketing system) for self-hosting, and I have my own
> > domain that I have not activated yet, so maybe I should just use fossil and
> > host it myself. Any comments?

> Fossil is one of those technologies that is very attractive in and of 
> itself, but is so under-adopted that it will itself be a barrier to 
> collaboration.  (Frankly, hg is getting to that category also.)

Some plainspeak -- Nice!

In modern society we are part users, part masters.  It may be 99% user
1% master if one is super-intelligent versatile etc -- renaissance men.

For us more ordinary folk it is more like 99.99% vs 0.01%
Eg I dont know how to repair the car I drive, build the roads they run on,
a frigging clue about the intenals of the utilities (electricity/water...)
I consume etc.  Heck this is even true of computers -- the SMPS? the Disk?

Likewise versioning systems.
We need to use them. We dont need to master all the details and possibilities.

Git has won the battle -- maybe because of the mystique around the
name 'Torvalds', maybe for sound technical reasons. It doesn't matter.
If you have better things in your life than becoming a phd in versioning,
I'd say flow with the tide and switch to git

[toc] | [prev] | [next] | [standalone]

#77152 — hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

On 08/27/2014 10:29 AM, Rustom Mody wrote:
>
> Git has won the battle

Good thing there's room for more than one technology.

I use hg because 1) python-dev uses hg; and 2) I understand the simple hg commands.  I find git confusing, and my main 
uses are commit, pull, update, an occasional merge, and a rare rollback -- not complicated stuff.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#77154 — Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]

[Multipart message — attachments visible in raw view] — view raw

On Wed, Aug 27, 2014 at 1:26 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

> I use hg because 1) python-dev uses hg; and 2) I understand the simple hg
> commands.  I find git confusing, and my main uses are commit, pull, update,
> an occasional merge, and a rare rollback -- not complicated stuff.


The "simple hg commands" are generally not all that different (in my
limited experience) than the "simple git commands," for some definition of
"simple." Stuff like clone, init, push, pull, commit, the small number of
commands you use day in, day out. When you get beyond that simple core,
both are confusing to me. I think it all boils down to what you use most
often. At work they settled on git awhile ago, so I'm now comfortable with
the basics there, though I recently had a rather unpleasant first
experience with "git rebase." Both hg (almost all of it for me) and git
(the stuff I don't regularly use) are like Perl: I need to consult the
documentation every step of the way. Thank God for StackOverflow. :-)

Skip

[toc] | [prev] | [next] | [standalone]

#77185 — Re: hg, git, fossil, ...

Skip Montanaro <skip@pobox.com>:

> The "simple hg commands" are generally not all that different (in my
> limited experience) than the "simple git commands," for some
> definition of "simple." Stuff like clone, init, push, pull, commit,
> the small number of commands you use day in, day out. When you get
> beyond that simple core, both are confusing to me.

I don't think a working VC system needs to contain much more than that.
Hg stays closer to the simple ideal than git, which really fails at
being a black box. I don't see why git has staging or branches, for
example. Or why can't I revert my changes to a file easily?

The main problem with hg (and git) is the way cherrypicking is done.

See these graphics:

 [1]   Product-Ver1
            |
            | bugfix
            |
            V          feature development
       Product-Ver1' ----------------------> Product-Ver2'

                       feature development
 [2]   Product-Ver1 -----------------------> Product-Ver2
                                                  |
                                                  | bugfix
                                                  |
                           cherry-picking         V
       Product-Ver1' <---------------------- Product-Ver2'


My beef is this: The starting point and end result of [1] and [2] is
identical. The version histories of Product-Ver1' and Product-Ver2'
should usually also be identical. In hg and git, they are not. In CVS,
they are not. In SVN, they are not.

In TeamWare (and bitkeeper?), the version histories are identical.


Marko

[toc] | [prev] | [next] | [standalone]

#77215 — Re: hg, git, fossil, ...

On 2014-08-28 08:58, Marko Rauhamaa wrote:
> The main problem with hg (and git) is the way cherrypicking is done.
> 
> See these graphics:
> 
>  [1]   Product-Ver1
>             |
>             | bugfix
>             |
>             V          feature development
>        Product-Ver1' ----------------------> Product-Ver2'
> 
>                        feature development
>  [2]   Product-Ver1 -----------------------> Product-Ver2
>                                                   |
>                                                   | bugfix
>                                                   |
>                            cherry-picking         V
>        Product-Ver1' <---------------------- Product-Ver2'
> 
> 
> My beef is this: The starting point and end result of [1] and [2] is
> identical. The version histories of Product-Ver1' and Product-Ver2'
> should usually also be identical. In hg and git, they are not. In
> CVS, they are not. In SVN, they are not.
> 
> In TeamWare (and bitkeeper?), the version histories are identical.

I'm not sure how you arrive at the conclusion that git/hg/cvs/svn
are wrong and TeamWare et al. are correct.  If you diff the two,
you'll find that the end result is the same, but the history is
different.  At least git/hg/bzr ensure that the historical tree that
I have and the historical tree that you have are identical.  In your
description, their histories are not.  This ensures that when I speak
about "the ancestor of Product-Ver2", we're both talking about the
same thing.  In #1, that's Product-Ver1' while in #2, that's
Product-Ver2.

-tkc

[toc] | [prev] | [next] | [standalone]

#77217 — Re: hg, git, fossil, ...

On 8/28/14 1:58 AM, Marko Rauhamaa wrote:
>
> The main problem with hg (and git) is the way cherrypicking is done.
>
> See these graphics:
>
>   [1]   Product-Ver1
>              |
>              | bugfix
>              |
>              V          feature development
>         Product-Ver1' ----------------------> Product-Ver2'
>
>                         feature development
>   [2]   Product-Ver1 -----------------------> Product-Ver2
>                                                    |
>                                                    | bugfix
>                                                    |
>                             cherry-picking         V
>         Product-Ver1' <---------------------- Product-Ver2'
>
>
> My beef is this: The starting point and end result of [1] and [2] is
> identical. The version histories of Product-Ver1' and Product-Ver2'
> should usually also be identical. In hg and git, they are not. In CVS,
> they are not. In SVN, they are not.
>
> In TeamWare (and bitkeeper?), the version histories are identical.
>

I feel like I am misunderstanding you.  My summary of what you just said 
is, "I have two scenarios where my code went through different sequences 
of changes to end up with the same content.  I expect both of those 
paths will show the same history."  That sounds nonsensical to me, so I 
must be misunderstanding you.  The path the file followed (that is, the 
sequence of changes that made the file what it is), *is* the history of 
the file.  If two different sequences of changes can result in the same 
history, then one (or both!) of the histories are "wrong" in that they 
don't accurately reflect the sequence of changes that happened.

Maybe you can elaborate?

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web