Menu
▾
▴
Re: [Jython-dev] Jython 3: greenhorn questions from an old hand
|
From: Stefan R. <Ste...@gm...> - 2017-05-29 17:35:15
|
(sorry, don't know the answers to your actual questions, actually I have somewhat the same questions) > Maybe my perception is coloured by the work I did last, which was very specific to Python 2, and doesn't belong in 3 I guess my perception is coloured by work on metaclass issues, diamond inheritance issues w.r.t. slots etc. Also unifying PyDict and PyStringMap, adding Py.newJ contructors, and plenty of other examples that I think do apply to Jython 3 as well. Porting them will be significant work, so exploring a somewhat automatic approach would be vital. It would be already a huge win if it could do 40-50% of the work. The remaining work will already be more than enough and involve plenty of cherry picking... > Gesendet: Montag, 29. Mai 2017 um 17:26 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...> > Betreff: Re: [Jython-dev] Jython 3: greenhorn questions from an old hand > > Maybe my perception is coloured by the work I did last, which was very > specific to Python 2, and doesn't belong in 3, but I'd dismissed any > mechanical merge as impossible or inadvisable. I think each change we > made to 2 will need cherry-picking on its merits, but you're right about > doing it systematically. This may actually be what I spend time doing. > > Given the pervasive nature of the (close to 700) changes on the Jython 3 > fork, it seems likely there would be constant conflict. I expect to > spend a lot of time with Kdiff3. > > Quite understand about your GSoC commitment: don't worry, we won't go > far without you. :/ > > Would appreciate answers to my newbie questions. > > Jeff > > Jeff Allen > > On 29/05/2017 15:31, Stefan Richthofer wrote: > > I really recommend that we (at least try to) merge 2.7.1 work into Jython 3 as far as and wherever possible. > > That means, really go back to the spot where 3 was forked from 2.7 and look at every single commit and merge it. > > I suppose this can be done in a semi-automated manner. Maybe it's not possible entirely with github GUI, but > > maybe we can save the changesets somehow. Git certainly has a way to use a changeset file as input for its > > merging algorithm. Ideally we would have a script that applies all changes that are automatically mergable. > > Every changeset that cannot be merged automatically should get a look (from its author ideally). > > Either it can be adjusted with reasonable effort, or it is maybe not applicable to Jython 3 for fundamental reasons. > > > > We should do this before Jython 3 and 2 diverge even more. Chances that automatic approach is vastly applicable will > > decrease more and more. I really doubt I can motivate myself much to work on a Jython 3 codebase that is full of > > issues we already solved. I'd rather much prefer to fix things that might break due to the merge process. > > > > Unfortunately I cannot help much on this process right now, because GSoC is about to launch. > > Will be in for Jython 3 later this year again. > > > > Best > > > > -Stefan > > > > > > > >> Gesendet: Montag, 29. Mai 2017 um 12:07 Uhr > >> Von: "Jeff Allen" <ja...@fa...> > >> An: "Jython Developers" <jyt...@li...> > >> Betreff: [Jython-dev] Jython 3: greenhorn questions from an old hand > >> > >> With 2.7.1 seemingly on its release journey, I have a bit of time to > >> hack on Jython 3. A lot has been done to Jython 3 since it forked from > >> 2, so I have some really newbie questions: > >> > >> * Is https://github.com/jython/jython3 the official reference > >> repository? (Is https://hg.python.org/sandbox/jython3 dead?) > >> * Are we still building with Ant? (It didn't for me on Windows, and I > >> thought I'd fix that first.) BTW, this is a question about now, not > >> what we'd like to do in future. > >> * Versions: Java 8, and Python 3.5? > >> * Although I believe I could commit directly to > >> https://github.com/jython/jython3, or a branch in there, do we agree > >> a better practice is to fork, branch and create a PR for a "feature" > >> (groups of related commits)? Even if I then accept my own PR, it > >> seems to give us a better audit trail, integration test, squash > >> point, etc.. A separate thread/discussion is due about workflow, > >> naming, etc.. > >> * Do we agree that our aim is to run the CPython regression tests with > >> as few skips, exclusions and replacement tests as possible? > >> * Does anyone have code stored up that I risk duplicating? (E.g. > >> Somewhere, Darjus mentioned ANTLR4 migration.) Otherwise I'll just > >> start with things I know about (bytes and strings, buffer interface, > >> io, import perhaps), driven by getting Py3k tests to pass honestly. > >> > >> I will averaging much fewer than 3 commits a day. ;) > >> > >> -- > >> > >> Jeff Allen > >> > >> > >> ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> Jython-dev mailing list > >> Jyt...@li... > >> https://lists.sourceforge.net/lists/listinfo/jython-dev > >> > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > |
