Quantcast

huge files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

huge files

andrea crotti-2
It looks like it's a common "problem" in the Elisp world, but I was
wondering is it normal to have huge source files.

python-mode.el is > 10k lines now, which for me causes two problems:
- it's hard to even know the various functionalities
- it's hard to manage the file

I see various things that could be very easily splitted
- virtualenv
- ipython
- pdbtrack (maybe)
- defcustom-defvar (or maybe better by topic taking the variables together)

and probably more.
Since it doesn't do any difference in terms of performance and it's
much less intimidating to try to grasp, is there a reason to keep all in
one big file?
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Andreas Röhler-2
Am 14.02.2012 22:31, schrieb Andrea Crotti:

> It looks like it's a common "problem" in the Elisp world, but I was
> wondering is it normal to have huge source files.
>
> python-mode.el is > 10k lines now, which for me causes two problems:
> - it's hard to even know the various functionalities
> - it's hard to manage the file
>
> I see various things that could be very easily splitted
> - virtualenv
> - ipython
> - pdbtrack (maybe)
> - defcustom-defvar (or maybe better by topic taking the variables together)
>
> and probably more.
> Since it doesn't do any difference in terms of performance and it's
> much less intimidating to try to grasp, is there a reason to keep all in
> one big file?

think it's basically historical.

People interested in developing/understanding might check out and use
the components branch

https://code.launchpad.net/~a-roehler/python-mode/components-python-mode

I'm doing all my developing and Python editing there.
It's sometimes ahead several days, if new features are introduced. But
the same tests are run before commits, so a possible loss in stability
is mince.

BTW in future we could create a declared stable branch of components and
make two tarballs for release.

CC to Barry for this question.

Andreas
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

andrea crotti-2
On 02/15/2012 08:34 AM, Andreas Röhler wrote:

>
> think it's basically historical.
>
> People interested in developing/understanding might check out and use
> the components branch
>
> https://code.launchpad.net/~a-roehler/python-mode/components-python-mode
>
> I'm doing all my developing and Python editing there.
> It's sometimes ahead several days, if new features are introduced. But
> the same tests are run before commits, so a possible loss in stability
> is mince.
>
> BTW in future we could create a declared stable branch of components
> and make two tarballs for release.
>
> CC to Barry for this question.
>
> Andreas

Ah i see interesting, so you did already this split..
Well I think that only one file might be easier to deploy, but the
average Emacs user should not really have problems in
untarring a tar and change the load path, right?

And the thing is that if I checkout the bzr repo I would expect that I
see the same structure that the devs are actually
seeing, otherwise it's also harder to apply patches directly reported
from others for example.

So a big +1 in a declared stable branch of components :)
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Barry Warsaw
In reply to this post by Andreas Röhler-2
On Feb 15, 2012, at 09:34 AM, Andreas Röhler wrote:

>think it's basically historical.
>
>People interested in developing/understanding might check out and use the components branch
>
>https://code.launchpad.net/~a-roehler/python-mode/components-python-mode
>
>I'm doing all my developing and Python editing there.
>It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince.
>
>BTW in future we could create a declared stable branch of components and make two tarballs for release.
I've always thought that because python-mode.el is a separate download, it's
better to have one big file.  This makes it easier for users to add it to
their Emacsen, even though it makes it more difficult to maintain, as rightly
observed.

But maybe we're at the tipping point where that trade-off should go the other
way.  Good, discoverable, installation documentation would go a long way
toward alleviating those concerns.  I run python-mode out of the bzr trunk, so
I'm probably not a good use case.

In a very real sense, this is Andreas's decision now.  "He who does the work,
decides" and Andreas has for quite a while now assumed primary ownership on
the code, by virtue of his great work on the mode.  I have no place to stand
in the way of his decision on this.

Cheers,
-Barry

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Jeff Bauer
On Wed, Feb 15, 2012 at 07:57:46AM -0500, Barry Warsaw wrote:

> On Feb 15, 2012, at 09:34 AM, Andreas Röhler wrote:
>
> >think it's basically historical.
> >
> >People interested in developing/understanding might check out
> >and use the components branch
> >
> >https://code.launchpad.net/~a-roehler/python-mode/components-python-mode
> >
> >I'm doing all my developing and Python editing there.  It's
> >sometimes ahead several days, if new features are
> >introduced. But the same tests are run before commits, so a
> >possible loss in stability is mince.
> >
> >BTW in future we could create a declared stable branch of
> >components and make two tarballs for release.
>
> I've always thought that because python-mode.el is a separate
> download, it's better to have one big file.  This makes it
> easier for users to add it to their Emacsen, even though it
> makes it more difficult to maintain, as rightly observed.
>
> But maybe we're at the tipping point where that trade-off should
> go the other way.  Good, discoverable, installation
> documentation would go a long way toward alleviating those
> concerns.  I run python-mode out of the bzr trunk, so I'm
> probably not a good use case.
>
> In a very real sense, this is Andreas's decision now.  "He who
> does the work, decides" and Andreas has for quite a while now
> assumed primary ownership on the code, by virtue of his great
> work on the mode.  I have no place to stand in the way of his
> decision on this.

Extending what Barry said ...

python-mode.el already has a hurdle to overcome, as it's not
distributed with emacs.  I think a single file makes it easier for
non-experts (I'm in this category) to drop in .emacs.d and run.

  http://marmalade-repo.org/about

However, as the Marmalade server (hopefully) becomes a standard
method for distributing 3rd party emacs packages, then multi-file
python-mode will be a non-issue.  Perhaps we might see some
convergence in this direction?

Agreed that the decision is Andreas's, and I thank him for his
efforts.

Jeff Bauer
Rubicon, Inc.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

François Pinard
In reply to this post by Andreas Röhler-2
Andreas Röhler <[hidden email]> writes:

> Am 14.02.2012 22:31, schrieb Andrea Crotti:

>> python-mode.el is > 10k lines now, which for me causes two problems:
>> - it's hard to even know the various functionalities
>> - it's hard to manage the file

As I'm favoring a single file, I feel like arguing a bit, not much :-).
In any case, as Barry and Jeff said already, this is Andreas' now.

The first point is a documentation and organization issue.  The
documentation is severely lacking, and it should exist either in some
more substantial README, or a manual.  The size of the Emacs Lisp source
does not much have to do with it.  It could it either be split to stress
the structure, or merely organized into pages, which would have almost
the same effect.

The second point, I do not get.  How is it hard to manage a single file?
It seems to be that many files are harder to manage than one.  On the
other hand, python-mode already holds a few extraneous Emacs Lisp files
taken from elsewhere, so the simplicity is being lost already.
Splitting python-mode in many files might blur the distinction between
what is python-mode proper from what is borrowed stuff; such blurring
have both advantages and disadvantages, but this is another problem.

>> Since it doesn't do any difference in terms of performance and it's
>> much less intimidating to try to grasp, is there a reason to keep all in
>> one big file?

It's easier to share and install.  A bit, not by much, nowadays.
Splitting might be a trigger towards a more formal installation
procedure.  But it would not alleviate the need for some good, or at
least reasonable documentation.  Splitting could also give to some the
feeling that it "replaces" documentation.  So I fear a bit that energies
might be dispersed away from the real thing to do.

François
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Andreas Röhler-2
In reply to this post by Barry Warsaw
Am 15.02.2012 13:57, schrieb Barry Warsaw:

> On Feb 15, 2012, at 09:34 AM, Andreas Röhler wrote:
>
>> think it's basically historical.
>>
>> People interested in developing/understanding might check out and use the components branch
>>
>> https://code.launchpad.net/~a-roehler/python-mode/components-python-mode
>>
>> I'm doing all my developing and Python editing there.
>> It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince.
>>
>> BTW in future we could create a declared stable branch of components and make two tarballs for release.
>
> I've always thought that because python-mode.el is a separate download, it's
> better to have one big file.  This makes it easier for users to add it to
> their Emacsen, even though it makes it more difficult to maintain, as rightly
> observed.
>
> But maybe we're at the tipping point where that trade-off should go the other
> way.  Good, discoverable, installation documentation would go a long way
> toward alleviating those concerns.  I run python-mode out of the bzr trunk, so
> I'm probably not a good use case.
>
> In a very real sense, this is Andreas's decision now.  "He who does the work,
> decides" and Andreas has for quite a while now assumed primary ownership on
> the code, by virtue of his great work on the mode.  I have no place to stand
> in the way of his decision on this.
>
> Cheers,
> -Barry

thanks looking with patience at my endeavors :)

Changed the intro note at lp, which mentions now a developing branch
beneath the trunk.

Concerning the one-file-solution see the pro at the users side.

BTW as for patches sent, the branch wouldn't be of importance so far.
The only point is the being against a current revision.


Cheers,

Andreas




_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

andrea crotti-2
In reply to this post by François Pinard
On 02/15/2012 03:08 PM, François Pinard wrote:
> It's easier to share and install.  A bit, not by much, nowadays.
> Splitting might be a trigger towards a more formal installation
> procedure.  But it would not alleviate the need for some good, or at
> least reasonable documentation.  Splitting could also give to some the
> feeling that it "replaces" documentation.  So I fear a bit that energies
> might be dispersed away from the real thing to do.
>
>
I don't think that the single file should disappear, what I just would like
is that if I'm downloading from bazaar I see all the components, which is
also how Andreas is actually working.

It's still easy to produce one single file for deployment, if that turns out
to be better.

And really, 10k lines of code is not good, in any language, because it's
impossible
just have a look at the file and understand (even very approximatively)
what is going on.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

François Pinard
Andrea Crotti <[hidden email]> writes:

> And really, 10k lines of code is not good, in any language, because
> it's impossible just have a look at the file and understand (even very
> approximatively) what is going on.

Hi, Andrea.

I really believe that there are ways to organize and document a big file
so it is clear, legible, and manageable.

It all depends on the code.  Gnus or Org could not be bundled as a
single file.  Next to these, Python mode is still a tiny thing.

Splitting a small project in parts might augment the editing hurdle.  If
the original file is disorganised, splitting it might organise it a bit,
but overall, this would only very marginally improve it.

If there is a problem in the area of clarity and legibility, splitting
is really not going to solve it in a significant way.  This would be a
wrong approach for a real problem.

Oh, no doubt that there might be other good reasons to split.  But as
far as the quality of the documentation is meant, it would not buy us
much, and might only induce useless delays.

François



_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Andreas Röhler-2
Am 15.02.2012 20:59, schrieb François Pinard:

> Andrea Crotti<[hidden email]>  writes:
>
>> And really, 10k lines of code is not good, in any language, because
>> it's impossible just have a look at the file and understand (even very
>> approximatively) what is going on.
>
> Hi, Andrea.
>
> I really believe that there are ways to organize and document a big file
> so it is clear, legible, and manageable.
>

updated doc/commands-python-mode.org
which should deliver some overview.



> It all depends on the code.  Gnus or Org could not be bundled as a
> single file.  Next to these, Python mode is still a tiny thing.
>
> Splitting a small project in parts might augment the editing hurdle.  If
> the original file is disorganised, splitting it might organise it a bit,
> but overall, this would only very marginally improve it.
>
> If there is a problem in the area of clarity and legibility, splitting
> is really not going to solve it in a significant way.  This would be a
> wrong approach for a real problem.
>
> Oh, no doubt that there might be other good reasons to split.  But as
> far as the quality of the documentation is meant, it would not buy us
> much, and might only induce useless delays.
>
> François
>
>
>
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: huge files

Andreas Röhler-2
In reply to this post by andrea crotti-2
[ ... ]
> much less intimidating to try to grasp,
[ ... ]



Added a README.DEVEL, indicating some entry point
for people who want to dig into the code.

Cheers,

Andreas

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Loading...