From: Updike, C. <Cla...@jh...> - 2005-01-31 16:26:38
|
I'd like to help with the collections support. That said, I have a bit to learn before I can become productive (I've never used cvs, haven't developed anything on sourceforge, etc). Are there any docs that would be a good place to start? It would be helpful to have some steps on how to get a=20 development environment set up for jython--up to and=20 including the running of the unit tests. I realize the PSF grant mentioned producing such docs later, but even just a=20 paragraph or two would be helpful. =20 Out of curiosity, is Eclipse popular amoung the short list=20 of current developers? -Clark > -----Original Message----- > From: jyt...@li...=20 > [mailto:jyt...@li...] On Behalf Of=20 > Brian Zimmer > Sent: Monday, January 31, 2005 11:08 AM > To: jyt...@li... > Subject: [Jython-dev] workings >=20 >=20 >=20 > I'm currently working on a design and prototype for PEP 302. >=20 > Samuele is finishing up new-style classes. >=20 > Oti has published an initial installer implementation. >=20 > There has been some discussion around Collections support but I'm not=20 > sure if anyone is actively working on the development. Is anyone?=20 > Anyone interested in volunteering? >=20 > We still have bugs to either close or fix if someone wants to=20 > work on a=20 > smaller piece of functionality. >=20 > One of the issues in my proposal that I am quite interested in=20 > accomplishing is a larger development and committer community. If=20 > anyone submits a patch for a significant feature or improvement to=20 > Jython (such as the Collections implementations) and it's=20 > accepted, they=20 > would, if interested, be added to the committer list. I=20 > think this will=20 > help ensure more active development and increase the=20 > frequency of releases. >=20 > thanks, >=20 > brian >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20 > Reporting Tool for open source databases. Create drag-&-drop=20 > reports. Save time by over 75%! Publish reports on the web.=20 > Export to DOC, XLS, RTF, etc. Download a FREE copy at=20 http://www.intelliview.com/go/osdn_nl _______________________________________________ Jython-dev mailing list Jyt...@li... https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Updike, C. <Cla...@jh...> - 2005-02-01 15:50:31
|
Thanks for the quick turnaround. It strikes me that this type of content would be well suited for a wiki. If a project admin want's=20 to take a crack at setting MoinMoin up (my personal=20 favorite), directions are here: <http://gaiacrtn.free.fr/articles/MoinMoinWikiOnSourceForge.html> I could port your slides into the wiki if you like if someone could set it up. -Clark > -----Original Message----- > From: Brian Zimmer [mailto:bz...@zi...]=20 > Sent: Monday, January 31, 2005 11:07 PM > To: Updike, Clark > Cc: jyt...@li... > Subject: Re: [Jython-dev] workings >=20 >=20 > Here's the start of a developer's guide. Please help make it=20 > better by=20 > trying it out and providing feedback. >=20 > http://ziclix.com/jython/devguide/ >=20 > I want to move all this to jython.org at some point but I'm having=20 > severe sf.net problems tonight. >=20 > thanks, >=20 > brian >=20 >=20 > On Jan 31, 2005, at 10:26 AM, Updike, Clark wrote: >=20 > > I'd like to help with the collections support. That said, > > I have a bit to learn before I can become productive (I've=20 > never used=20 > > cvs, haven't developed anything on sourceforge, etc). Are=20 > there any=20 > > docs that would be a good place to start? > > > > It would be helpful to have some steps on how to get a development=20 > > environment set up for jython--up to and including the=20 > running of the=20 > > unit tests. I realize the PSF grant mentioned producing such docs=20 > > later, but even just a paragraph or two would be helpful. > > > > Out of curiosity, is Eclipse popular amoung the short list > > of current developers? > > > > -Clark > > > >> -----Original Message----- > >> From: jyt...@li... > >> [mailto:jyt...@li...] On Behalf Of Brian=20 > >> Zimmer > >> Sent: Monday, January 31, 2005 11:08 AM > >> To: jyt...@li... > >> Subject: [Jython-dev] workings > >> > >> > >> > >> I'm currently working on a design and prototype for PEP 302. > >> > >> Samuele is finishing up new-style classes. > >> > >> Oti has published an initial installer implementation. > >> > >> There has been some discussion around Collections support=20 > but I'm not=20 > >> sure if anyone is actively working on the development. Is anyone?=20 > >> Anyone interested in volunteering? > >> > >> We still have bugs to either close or fix if someone wants=20 > to work on=20 > >> a smaller piece of functionality. > >> > >> One of the issues in my proposal that I am quite interested in=20 > >> accomplishing is a larger development and committer community. If=20 > >> anyone submits a patch for a significant feature or improvement to=20 > >> Jython (such as the Collections implementations) and it's=20 > accepted,=20 > >> they would, if interested, be added to the committer list. I > >> think this will > >> help ensure more active development and increase the > >> frequency of releases. > >> > >> thanks, > >> > >> brian > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20 > >> Reporting Tool for open source databases. Create=20 > drag-&-drop reports.=20 > >> Save time by over 75%! Publish reports on the web. Export to DOC,=20 > >> XLS, RTF, etc. Download a FREE copy at > > http://www.intelliview.com/go/osdn_nl > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li...=20 > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20 > > Reporting Tool for open source databases. Create=20 > drag-&-drop reports.=20 > > Save time by over 75%! Publish reports on the web. Export=20 > to DOC, XLS,=20 > > RTF, etc. Download a FREE copy at=20 > > http://www.intelliview.com/go/osdn_nl > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev >=20 >=20 |
From: Frank W. <fwi...@gm...> - 2005-02-01 18:43:04
|
Commiters, What are the chances of some reorganziation of the cvs files, like the source files going under a "src" directory instead of sitting at the root and a "test" directory for the test code? I know that it is a huge PITA to do on cvs... but it would make it easier to maintain the ant script, and some IDEs are happier with this arrangement. I realize this may not be a good time to try such things since there are two branches going. Just a request... Thanks, Frank Wierzbicki |
From: Brian Z. <bz...@zi...> - 2005-02-02 02:54:25
|
I've been wanting to move some files around for awhile. I think this next release has the potential for some backward in-compatible changes to Java source files so this might be a good time to re-organize. A lot of the code is over 4+ year old so I'm not sure how much we'd be consulting history anyways. A new tree would definitely make IDE integration better. When we do the merge from the new-style branch I think it would be a good time to upgrade the directory structure and the build scripts. This would include building the new installer and distribution from ant. Here are some links to current best practices. http://jakarta.apache.org/site/dirlayout.html http://www.onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html Jython ------ build.xml src/ java/ com/ org/ python/ Lib/ Misc/ Tools/ test/ java/ (either support files for python tests or regular JUnit tests) python/ (currently these live in Lib/test; this would deviate from CPython) (should the bugtests module move here?) doc/ bin/ jython.bat jython[.sh] jythonc.bat jythonc[.sh] contribs/ (perhaps the installer could go here?) Building would create --------------------- build/ dist/ A distribution would move the files into the expected places, such as 'test' under 'Lib' which is the CPython way. What do people think about this idea? I like it and if we dropped CVS history then it would be pretty straight forward even with fighting CVS. thanks, brian On Feb 1, 2005, at 12:42 PM, Frank Wierzbicki wrote: > Commiters, > > What are the chances of some reorganziation of the cvs files, like the > source files going under a "src" directory instead of sitting at the > root and a "test" directory for the test code? I know that it is a > huge PITA to do on cvs... but it would make it easier to maintain the > ant script, and some IDEs are happier with this arrangement. I > realize this may not be a good time to try such things since there are > two branches going. Just a request... > > Thanks, > Frank Wierzbicki > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Frank W. <fwi...@gm...> - 2005-02-02 03:47:04
|
This would be perfect for me. Frank Wierzbicki |
From: Samuele P. <ped...@st...> - 2005-02-02 10:44:37
|
Brian Zimmer wrote: > I've been wanting to move some files around for awhile. I think this > next release has the potential for some backward in-compatible changes > to Java source files so this might be a good time to re-organize. A > lot of the code is over 4+ year old so I'm not sure how much we'd be > consulting history anyways. I often consulted history. Without history is very hard to answer questions e.g. like what bugfixes and features have been ported from CPython sre impl to ours and which are still missing. > > A new tree would definitely make IDE integration better. When we do > the merge from the new-style branch I think it would be a good time to > upgrade the directory structure and the build scripts. This would > include building the new installer and distribution from ant. > > Here are some links to current best practices. > > http://jakarta.apache.org/site/dirlayout.html > http://www.onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html > > Jython > ------ > build.xml > src/ > java/ > com/ > org/ > python/ > Lib/ > Misc/ > Tools/ > test/ > java/ > (either support files for python tests or regular JUnit tests) > python/ > (currently these live in Lib/test; this would deviate from > CPython) this will make reusing the CPython test driver harder, depending of where you move some directories with java files it may also require more complicated classpaths to run rests. I personally like to run tests without having to run ant and build a dist before. > (should the bugtests module move here?) > doc/ > bin/ > jython.bat > jython[.sh] > jythonc.bat > jythonc[.sh] > contribs/ > (perhaps the installer could go here?) > > Building would create > --------------------- > build/ > dist/ > > A distribution would move the files into the expected places, such as > 'test' under 'Lib' which is the CPython way. > > What do people think about this idea? I like it and if we dropped CVS > history then it would be pretty straight forward even with fighting CVS. > > thanks, > > brian > > On Feb 1, 2005, at 12:42 PM, Frank Wierzbicki wrote: > >> Commiters, >> >> What are the chances of some reorganziation of the cvs files, like the >> source files going under a "src" directory instead of sitting at the >> root and a "test" directory for the test code? I know that it is a >> huge PITA to do on cvs... but it would make it easier to maintain the >> ant script, and some IDEs are happier with this arrangement. I >> realize this may not be a good time to try such things since there are >> two branches going. Just a request... >> >> Thanks, >> Frank Wierzbicki >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Brian Z. <bz...@zi...> - 2005-02-02 11:43:45
|
On Feb 2, 2005, at 04:44 AM, Samuele Pedroni wrote: > Brian Zimmer wrote: > >> I've been wanting to move some files around for awhile. I think this >> next release has the potential for some backward in-compatible >> changes to Java source files so this might be a good time to >> re-organize. A lot of the code is over 4+ year old so I'm not sure >> how much we'd be consulting history anyways. > > I often consulted history. Without history is very hard to answer > questions e.g. like what bugfixes and features have been ported from > CPython sre impl to ours and which are still > missing. > Losing history is really the biggest loss as far as I'm concerned. In my own projects and at work I have often found that a better laid out directory structure outweighs the usefulness of history. If you have a tag at the time of the restructuring it's always possible to go back and see it. It's too bad CVS is awful at this. I think it's possible to get both though by moving the files on the server rather than through the client. http://computing.ee.ethz.ch/sepp/cvs-1.10-to/cvsbook/ main_117.html#SEC117 http://web.archive.org/web/20011126165057/www.arsdigita.com/bboard/q- and-a-fetch-msg?msg_id=000KBt&topic_id=395 >> >> A new tree would definitely make IDE integration better. When we do >> the merge from the new-style branch I think it would be a good time >> to upgrade the directory structure and the build scripts. This would >> include building the new installer and distribution from ant. >> >> Here are some links to current best practices. >> >> http://jakarta.apache.org/site/dirlayout.html >> http://www.onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html >> >> Jython >> ------ >> build.xml >> src/ >> java/ >> com/ >> org/ >> python/ >> Lib/ >> Misc/ >> Tools/ >> test/ >> java/ >> (either support files for python tests or regular JUnit tests) >> python/ >> (currently these live in Lib/test; this would deviate from >> CPython) > > this will make reusing the CPython test driver harder, depending of > where you move some directories with java files it may also require > more complicated classpaths to run rests. > I personally like to run tests without having to run ant and build a > dist before. > > Not married to this idea. I was throwing it out. I too don't use the dist, I point my python.home to my checkout directory, not the dist directory. I was however thinking of changing this practice. brian |
From: Alan K. <jyt...@xh...> - 2005-02-02 16:00:00
|
[Brian Zimmer] >>> I've been wanting to move some files around for awhile. >>> I think this next release has the potential for some >>> backward in-compatible changes to Java source files so >>> this might be a good time to re-organize. A lot of the >>> code is over 4+ year old so I'm not sure how much we'd >>> be consulting history anyways. [Samuele Pedroni] >> I often consulted history. Without history is very hard >> to answer questions e.g. like what bugfixes and features >> have been ported from CPython sre impl to ours and which >> are still missing. [Brian Zimmer] > Losing history is really the biggest loss as far as I'm > concerned. In my own projects and at work I have often found > that a better laid out directory structure outweighs the > usefulness of history. If you have a tag at the time of > the restructuring it's always possible to go back and see it. > > It's too bad CVS is awful at this. Indeed, I think the jython source base is now suffering from the worst problems of CVS, and I like the idea of a re-organization. However, if there was to be a re-organization, I would *greatly* prefer a migration to subversion, which is a superior versioning system. Among other things, it can version directories, and can move files around without losing history, etc, etc, etc. http://subversion.tigris.org There are tools for migrating CVS to subversion, but I'm not sure how good they are at carrying over history, etc, and don't have the time to research it. But the code re-organisation could then be done *after* a move to subversion, thus preserving history on files as they move around the hierarchy. However, I don't know how practical migrating to subversion is. If we're tied to SourceForge, then I suppose we have no choice but to stick with CVS. But maybe the entire project could move to a different host, e.g. http://jython.tigris.org? Or perhaps someone on the list could volunteer space? I could volunteer this server space myself, i.e. a full subversion/Trac installation dedicated to jython on http://jython.xhaus.com, but wouldn't be able to get around to setting it all up for at least a month or two. As for project management, bug tracking, etc, I also think it would be *fantastic* if we could use something like Trac, which is a great little project management system written in cpython, and gaining a *lot* of traction in the field of software project tracking and management. It has lovely out-of-the-box features, such as a wiki (jython desperately needs a wiki!), a simple and effective bug tracker, milestone management, a lovely integrated wiki markup language that allows linkage to tickets/reports/sourcecode/etc, a pretty and effective source code browser, simply-extended report engine, etc, etc, etc. http://www.edgewall.com/trac/ Using Trac would be fantastic because it is so dynamic and easy to manage and update. I think that jython has a significant marketing/perception problem, i.e. that there is too little activity on the project. But that's just because most people don't bother to check CVS checkins, bug reports, etc, because they don't see it right in front of their noses when they visit the jython web site. Trac would answer most of those perception problems. Lastly, contributing to jython would be much easier for me if we used subversion, because that's what I use for all my projects. I was an early adopter of subversion, because CVS was such a pain. Just my €0,02 Regards, Alan. |
From: Ype K. <yk...@xs...> - 2005-02-02 17:25:42
|
On Wednesday 02 February 2005 17:03, Alan Kennedy wrote: > [Brian Zimmer] > >>> I've been wanting to move some files around for awhile. > >>> I think this next release has the potential for some > >>> backward in-compatible changes to Java source files so > >>> this might be a good time to re-organize. A lot of the > >>> code is over 4+ year old so I'm not sure how much we'd > >>> be consulting history anyways. > > [Samuele Pedroni] > >> I often consulted history. Without history is very hard > >> to answer questions e.g. like what bugfixes and features > >> have been ported from CPython sre impl to ours and which > >> are still missing. > > [Brian Zimmer] > > Losing history is really the biggest loss as far as I'm > > concerned. In my own projects and at work I have often found > > that a better laid out directory structure outweighs the > > usefulness of history. If you have a tag at the time of > > the restructuring it's always possible to go back and see it. > > > > It's too bad CVS is awful at this. > > Indeed, I think the jython source base is now suffering from the worst > problems of CVS, and I like the idea of a re-organization. > > However, if there was to be a re-organization, I would *greatly* prefer > a migration to subversion, which is a superior versioning system. Among > other things, it can version directories, and can move files around > without losing history, etc, etc, etc. > > http://subversion.tigris.org > > There are tools for migrating CVS to subversion, but I'm not sure how > good they are at carrying over history, etc, and don't have the time to > research it. But the code re-organisation could then be done *after* a > move to subversion, thus preserving history on files as they move around > the hierarchy. The history is kept by the standard conversion from cvs to svn. Once in svn, renames and moves are also in the history. Apart from the versioned renames, the local diff is also very handy. > However, I don't know how practical migrating to subversion is. If we're The migration script cvs2svn.py is written in Python, what more could one wish? It even migrated .cvsignore to the corresponding svn property correctly in my case. Some planning ahead is already going on, and the rest is moving files in svn and fixing file references in the code. Kind regards, Ype Kingma |
From: Ilia I. <ii...@ya...> - 2005-02-02 19:01:40
|
In case of migration to svn I think it will be better to migrate the whole project to codehaus. They have svn, jira and lots of donated tools. They want Python, they have Boo which python like language for .NET and groovy. On they side note I think breaking org.python.core.* is as important as bin/build/test/src directory structure. Thanks, Ilia --- Alan Kennedy <jyt...@xh...> wrote: > [Brian Zimmer] > >>> I've been wanting to move some files around for > awhile. > >>> I think this next release has the potential > for some > >>> backward in-compatible changes to Java source > files so > >>> this might be a good time to re-organize. A > lot of the > >>> code is over 4+ year old so I'm not sure how > much we'd > >>> be consulting history anyways. > > [Samuele Pedroni] > >> I often consulted history. Without history is > very hard > >> to answer questions e.g. like what bugfixes and > features > >> have been ported from CPython sre impl to ours > and which > >> are still missing. > > [Brian Zimmer] > > Losing history is really the biggest loss as far > as I'm > > concerned. In my own projects and at work I have > often found > > that a better laid out directory structure > outweighs the > > usefulness of history. If you have a tag at the > time of > > the restructuring it's always possible to go back > and see it. > > > > It's too bad CVS is awful at this. > > Indeed, I think the jython source base is now > suffering from the worst > problems of CVS, and I like the idea of a > re-organization. > > However, if there was to be a re-organization, I > would *greatly* prefer > a migration to subversion, which is a superior > versioning system. Among > other things, it can version directories, and can > move files around > without losing history, etc, etc, etc. > > http://subversion.tigris.org > > There are tools for migrating CVS to subversion, but > I'm not sure how > good they are at carrying over history, etc, and > don't have the time to > research it. But the code re-organisation could then > be done *after* a > move to subversion, thus preserving history on files > as they move around > the hierarchy. > > However, I don't know how practical migrating to > subversion is. If we're > tied to SourceForge, then I suppose we have no > choice but to stick with > CVS. But maybe the entire project could move to a > different host, e.g. > http://jython.tigris.org? > > Or perhaps someone on the list could volunteer > space? I could volunteer > this server space myself, i.e. a full > subversion/Trac installation > dedicated to jython on http://jython.xhaus.com, but > wouldn't be able to > get around to setting it all up for at least a month > or two. > > As for project management, bug tracking, etc, I also > think it would be > *fantastic* if we could use something like Trac, > which is a great little > project management system written in cpython, and > gaining a *lot* of > traction in the field of software project tracking > and management. It > has lovely out-of-the-box features, such as a wiki > (jython desperately > needs a wiki!), a simple and effective bug tracker, > milestone > management, a lovely integrated wiki markup language > that allows linkage > to tickets/reports/sourcecode/etc, a pretty and > effective source code > browser, simply-extended report engine, etc, etc, > etc. > > http://www.edgewall.com/trac/ > > Using Trac would be fantastic because it is so > dynamic and easy to > manage and update. I think that jython has a > significant > marketing/perception problem, i.e. that there is too > little activity on > the project. But that's just because most people > don't bother to check > CVS checkins, bug reports, etc, because they don't > see it right in front > of their noses when they visit the jython web site. > Trac would answer > most of those perception problems. > > Lastly, contributing to jython would be much easier > for me if we used > subversion, because that's what I use for all my > projects. I was an > early adopter of subversion, because CVS was such a > pain. > > Just my 0,02 > > Regards, > > Alan. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- > Interactive Reporting > Tool for open source databases. Create drag-&-drop > reports. Save time > by over 75%! Publish reports on the web. Export to > DOC, XLS, RTF, etc. > Download a FREE copy at > http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: <bi...@de...> - 2005-02-02 23:51:24
|
Alan Kennedy wrote: > [Brian Zimmer] > > Losing history is really the biggest loss as far as I'm > > concerned. In my own projects and at work I have often found > > that a better laid out directory structure outweighs the > > usefulness of history. If you have a tag at the time of > > the restructuring it's always possible to go back and see it. > > > > It's too bad CVS is awful at this. > > Indeed, I think the jython source base is now suffering from the worst > problems of CVS, and I like the idea of a re-organization. Looking at the source layout I'm inclined to agree; CVS can result in inertia when it comes to code organization. > However, if there was to be a re-organization, I would *greatly* prefer > a migration to subversion, which is a superior versioning system. Among > other things, it can version directories, and can move files around > without losing history, etc, etc, etc. > > http://subversion.tigris.org > > There are tools for migrating CVS to subversion, but I'm not sure how > good they are at carrying over history, etc, and don't have the time to > research it. But the code re-organisation could then be done *after* a > move to subversion, thus preserving history on files as they move around > the hierarchy. I've migrated a number of projects big and small to Subversion from CVS; it is usually a straightforward task. I agree it's a better tool than CVS, especially so for Java. IDE support could be better, but there are decent standalone tools available now. Switching vcs should not be done on a whim however - imo it's a much bigger deal than a CVS restructuring. [cvs2svn.py needs to work on the ,v files directly. It the event that this is what people want to do, it can be tested on a sourceforge repository tarball.] cheers Bill |
From: Brian Z. <bz...@zi...> - 2005-02-03 14:14:25
|
Bill de h=D3ra wrote: > Alan Kennedy wrote: >=20 > Looking at the source layout I'm inclined to agree; CVS can result in=20 > inertia when it comes to code organization. >=20 It can, but a lot of work has occurred despite, or because of, CVS. >=20 >> However, if there was to be a re-organization, I would *greatly*=20 >> prefer a migration to subversion, which is a superior versioning=20 >> system. Among other things, it can version directories, and can move=20 >> files around without losing history, etc, etc, etc. >> >> http://subversion.tigris.org >> I don't see this happening before a next release. We need to get a=20 stable, updated version of Jython released and then we can begin=20 investigating a migration if it's worth the effort. I know a number of=20 projects have left sf in favor of subversion on other systems (pyobjc=20 comes to mind). I'm definitely in favor of a such a move but we have to=20 focus on development first in the near term. >> There are tools for migrating CVS to subversion, but I'm not sure how=20 >> good they are at carrying over history, etc, and don't have the time=20 >> to research it. But the code re-organisation could then be done=20 >> *after* a move to subversion, thus preserving history on files as they= =20 >> move around the hierarchy. >=20 >=20 > I've migrated a number of projects big and small to Subversion from CVS= ;=20 > it is usually a straightforward task. I agree it's a better tool than=20 > CVS, especially so for Java. IDE support could be better, but there are= =20 > decent standalone tools available now. >=20 > Switching vcs should not be done on a whim however - imo it's a much=20 > bigger deal than a CVS restructuring. >=20 Absolutely agree. > [cvs2svn.py needs to work on the ,v files directly. It the event that=20 > this is what people want to do, it can be tested on a sourceforge=20 > repository tarball.] >=20 >=20 > cheers > Bill >=20 |
From: <bi...@de...> - 2005-02-03 14:34:32
|
Brian Zimmer wrote: > I don't see this happening before a next release. We need to get a > stable, updated version of Jython released and then we can begin > investigating a migration if it's worth the effort. I know a number of > projects have left sf in favor of subversion on other systems (pyobjc > comes to mind). I'm definitely in favor of a such a move but we have to > focus on development first in the near term. No argument there. If svn comes in the future, I'll volunteer to help with the migration. cheers Bill |
From: <bi...@de...> - 2005-02-02 11:22:11
|
Brian Zimmer wrote: > What do people think about this idea? I like it and if we dropped CVS > history then it would be pretty straight forward even with fighting CVS. I'd been building some notes on the Jython tree and your layout is close to what I had as an ideal (I even have an ant script to generate ant projects laid out like this). It's certainly idiomatic Java. The other things you could consider are: src/ gen/ /if/ you wanted to keep javacc generated code separate from hand rolled code (that would also help make the ant clean task straightforward), and to keep all targets underneath a single build folder: build/ classes/ doc/ dist/ lib/ ... I'm +1 on getting this done, as I think it will help any new Java contributors come to speed; the current layout is a hoop to jump through imvho. Samuele has a point about history; you can't move files around in CVS and keep history unless you move them directly on the server and tell everyone to update (on the subject on modern IDEs, this is why CVS sucks for automated refactoring). The last time I looked, you couldn't do this on Sourceforge - maybe there's a way to persuade their admins to allow access. Perhaps when new style classes are introduced there's an opportunity afterwards to change the layout. It sounds like a big change; maybe the history will be less relevant. As for complicating the cpython test runners; I would certainly help on finding a way to reduce that cost. In the meantime, deprecating and removing the makefiles is certainly an option; perhaps a headcount of who's using make might be in order. cheers Bill |
From: Brian Z. <bz...@zi...> - 2005-02-02 02:36:15
|
I agree, this kind of content is a good match for a wiki. Looking on the sf servers it appears Jython already has a MoinMoin instance installed though I'm not sure if that's what's driving the FAQ. Given the feedback on documentation it appears it's definitely an area a lot of people are eager to see done better. I'm working with Sean McGrath (who is currently handling the updating of the Jython site) on perhaps upgrading it's look and content. There should be more on this in the next couple of days. In the interim, please let me know what changes you want made to the developer documentation so I can start keeping that up to date while we roll out a new wiki or other such framework. thanks, brian On Feb 1, 2005, at 09:50 AM, Updike, Clark wrote: > Thanks for the quick turnaround. > > It strikes me that this type of content would be > well suited for a wiki. If a project admin want's > to take a crack at setting MoinMoin up (my personal > favorite), directions are here: > > <http://gaiacrtn.free.fr/articles/MoinMoinWikiOnSourceForge.html> > > I could port your slides into the wiki if you like > if someone could set it up. > > -Clark > >> -----Original Message----- >> From: Brian Zimmer [mailto:bz...@zi...] >> Sent: Monday, January 31, 2005 11:07 PM >> To: Updike, Clark >> Cc: jyt...@li... >> Subject: Re: [Jython-dev] workings >> >> >> Here's the start of a developer's guide. Please help make it >> better by >> trying it out and providing feedback. >> >> http://ziclix.com/jython/devguide/ >> >> I want to move all this to jython.org at some point but I'm having >> severe sf.net problems tonight. >> >> thanks, >> >> brian >> >> >> On Jan 31, 2005, at 10:26 AM, Updike, Clark wrote: >> >>> I'd like to help with the collections support. That said, >>> I have a bit to learn before I can become productive (I've >> never used >>> cvs, haven't developed anything on sourceforge, etc). Are >> there any >>> docs that would be a good place to start? >>> >>> It would be helpful to have some steps on how to get a development >>> environment set up for jython--up to and including the >> running of the >>> unit tests. I realize the PSF grant mentioned producing such docs >>> later, but even just a paragraph or two would be helpful. >>> >>> Out of curiosity, is Eclipse popular amoung the short list >>> of current developers? >>> >>> -Clark >>> >>>> -----Original Message----- >>>> From: jyt...@li... >>>> [mailto:jyt...@li...] On Behalf Of Brian >>>> Zimmer >>>> Sent: Monday, January 31, 2005 11:08 AM >>>> To: jyt...@li... >>>> Subject: [Jython-dev] workings >>>> >>>> >>>> >>>> I'm currently working on a design and prototype for PEP 302. >>>> >>>> Samuele is finishing up new-style classes. >>>> >>>> Oti has published an initial installer implementation. >>>> >>>> There has been some discussion around Collections support >> but I'm not >>>> sure if anyone is actively working on the development. Is anyone? >>>> Anyone interested in volunteering? >>>> >>>> We still have bugs to either close or fix if someone wants >> to work on >>>> a smaller piece of functionality. >>>> >>>> One of the issues in my proposal that I am quite interested in >>>> accomplishing is a larger development and committer community. If >>>> anyone submits a patch for a significant feature or improvement to >>>> Jython (such as the Collections implementations) and it's >> accepted, >>>> they would, if interested, be added to the committer list. I >>>> think this will >>>> help ensure more active development and increase the >>>> frequency of releases. >>>> >>>> thanks, >>>> >>>> brian >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive >>>> Reporting Tool for open source databases. Create >> drag-&-drop reports. >>>> Save time by over 75%! Publish reports on the web. Export to DOC, >>>> XLS, RTF, etc. Download a FREE copy at >>> http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Jython-dev mailing list >>> Jyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive >>> Reporting Tool for open source databases. Create >> drag-&-drop reports. >>> Save time by over 75%! Publish reports on the web. Export >> to DOC, XLS, >>> RTF, etc. Download a FREE copy at >>> http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Jython-dev mailing list >>> Jyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> > |
From: Brian Z. <bz...@zi...> - 2005-01-31 16:48:25
|
Updike, Clark wrote: > I'd like to help with the collections support. That said, > I have a bit to learn before I can become productive (I've > never used cvs, haven't developed anything on sourceforge, > etc). Are there any docs that would be a good place to > start? I can start on this tonight. > > Out of curiosity, is Eclipse popular amoung the short list > of current developers? > Eclipse does not fit my head for some reason. I use IntelliJ even though it's commercial. It just seems to work better for me. brian |
From: Noel R. <noe...@gm...> - 2005-01-31 17:01:27
|
I'll second the Intellij recommendation -- it also has great CVS support. I find the interface much cleaner than eclipse, myself. Have we settled on a plan for collections? My time is buried in another project at the moment, but I'd still like to lend a hand if I can. Noel On Mon, 31 Jan 2005 10:51:46 -0600, Brian Zimmer <bz...@zi...> wrote: > Updike, Clark wrote: > > I'd like to help with the collections support. That said, > > I have a bit to learn before I can become productive (I've > > never used cvs, haven't developed anything on sourceforge, > > etc). Are there any docs that would be a good place to > > start? > > I can start on this tonight. > > > > > Out of curiosity, is Eclipse popular amoung the short list > > of current developers? > > > > Eclipse does not fit my head for some reason. I use IntelliJ even > though it's commercial. It just seems to work better for me. > > brian -- Noel Rappin noe...@al... |
From: Brian Z. <bz...@zi...> - 2005-02-01 04:06:55
|
Here's the start of a developer's guide. Please help make it better by trying it out and providing feedback. http://ziclix.com/jython/devguide/ I want to move all this to jython.org at some point but I'm having severe sf.net problems tonight. thanks, brian On Jan 31, 2005, at 10:26 AM, Updike, Clark wrote: > I'd like to help with the collections support. That said, > I have a bit to learn before I can become productive (I've > never used cvs, haven't developed anything on sourceforge, > etc). Are there any docs that would be a good place to > start? > > It would be helpful to have some steps on how to get a > development environment set up for jython--up to and > including the running of the unit tests. I realize the PSF > grant mentioned producing such docs later, but even just a > paragraph or two would be helpful. > > Out of curiosity, is Eclipse popular amoung the short list > of current developers? > > -Clark > >> -----Original Message----- >> From: jyt...@li... >> [mailto:jyt...@li...] On Behalf Of >> Brian Zimmer >> Sent: Monday, January 31, 2005 11:08 AM >> To: jyt...@li... >> Subject: [Jython-dev] workings >> >> >> >> I'm currently working on a design and prototype for PEP 302. >> >> Samuele is finishing up new-style classes. >> >> Oti has published an initial installer implementation. >> >> There has been some discussion around Collections support but I'm not >> sure if anyone is actively working on the development. Is anyone? >> Anyone interested in volunteering? >> >> We still have bugs to either close or fix if someone wants to >> work on a >> smaller piece of functionality. >> >> One of the issues in my proposal that I am quite interested in >> accomplishing is a larger development and committer community. If >> anyone submits a patch for a significant feature or improvement to >> Jython (such as the Collections implementations) and it's >> accepted, they >> would, if interested, be added to the committer list. I >> think this will >> help ensure more active development and increase the >> frequency of releases. >> >> thanks, >> >> brian >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive >> Reporting Tool for open source databases. Create drag-&-drop >> reports. Save time by over 75%! Publish reports on the web. >> Export to DOC, XLS, RTF, etc. Download a FREE copy at > http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |