Re: Jython 3: greenhorn questions from an old hand

(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" <[email protected]>
> An: "Stefan Richthofer" <[email protected]>, "Jython Developers" <[email protected]>
> 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" <[email protected]>
> >> An: "Jython Developers" <[email protected]>
> >> 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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