On 10 May 2013 09:41, Herbert Duerr <[email protected]> wrote: > Sorry for the late answer, we had a public holiday yesterday: > > [...] >>> I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit >>> JRE >>> -> 64bit UNO -> XCode4 -> clang -> allows C++11 -> no-stlport4 and >>> XCode4 >>> -> newer SDK) it wasn't easy to come up with a name that covered the >>> different aspects. "Platform refresh 2013" and "rejuvenate" were the only >>> ones that came to my little mind. Maybe I should have asked around more >>> for >>> better ideas. In my defense I mentioned the name "pr2013" as a suggestion >>> for the branch in my 2013/04/09 mail on the XCode4 topic and nobody >>> complained or had a better idea then. >>> >> >> You are right with that lot of changes "rejuvenate" is quite precise (now >> I just start wondering what rejuvenate02 is going to contain) >> > > With the two-digit extension we'll have enough room to rejuvenate our > Office many more times ;-) > > As to a concrete rejuvenate02 branch there are no concrete plans, only > some general ideas: > - Maybe now that the branch rejuvenate01 replaced stlport4 by a standard > compliant STL from a binary perspective a new branch rejuvenate02 could be > the followup for the related cleanup in the main codebase? Since this can > mostly be automated I'll probably do it r01 though. > - A rejuvenate03 branch could use all the C++11 features that are already > now commonly available on our platform's compilers to clean up our codebase > - A rejuvenate04 branch could go to full C++11 and improve speed using > rvalue semantics and auto-types could help to make some areas much cleaner > > But what's in a name anyway. I just want to keep us the options open, but > I don't like to concretely plan such stuff years ahead. Such concrete > long-term plans would only limit the flexibility and close options that > could benefit the project. >
you caught me out here...I was actually trying to make a joke, I highly respect the work you are doing, it is an example to all of us. having said that it is still nice to see you have visions for the future...and building systems seems to be on another track :-) > > I have one technical question, how come you can change so easily to STL, >> when it took LO many volunteers to do it, or did I misunderstand >> something ? >> > > Because of the license incompatibility I have no idea what they did and so > I don't know why it took so much effort. Maybe they also converted some > other ancient OOo data structures to STL? > I dont know either, I just read soo much about how much they invested. > > Or maybe they did the changes needed individually? I prefer to isolate the > individual transition concerns (using my STL-wrappers and their > STLPORT4-emulation), do the main transition (e.g. from hash_map to > unordered_map) automatically and then drop the STL-wrappers altogether. If > we have volunteers who like to boost their committer statistics we could to > the main transition manually and per source file though ;-) > Yours seems to be the smarter way....if we work smart we can do more than a bunch on "just programmers" !! thx. for the explanation. I will try to configure the branch saturday for ubuntu 12.04...do you want me to commit changes directly or do you prefer patch files ? rgds jan I. > > Herbert > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
