Dirk Reiners wrote: > Hi All, > > Gerrit Voss wrote: >>>>>> I agree with this statement and it scares me quite a bit. The 1.x and >>>>>> 2.0 code branches are diverging and I don't see an end to it in sight. >>>>>> IMHO we have to find a way to end the 1.x series otherwise the 2.0 >>>>>> series will never really get going. >>> Diverging may be an understatement. >> It is not as bad as it sounds. > > That's the optimist's way of looking at it. ;) I somewhat agree with it, > though, > the changes in 1 are mostly minor. > >> Which in particular ??, we do not merge on a regular basis but usually >> all these minor fixes get pulled over once we merge (as far as they >> apply). Also some things inside 1.x need to be redesigned before they >> end up in 2.x as the current 1.x implementation is more than ugly ;-). > > Anything in particular? > >>>> Note: I don't speak for the OpenSG team. I may commit code once in a >>>> while, but I am not a core developer. I proposed August as a time for >>>> an alpha 2.0 because we are already using it and it seems at least alpha >>>> quality to me. ;) >> Kind of agree, but there is a roadblock ;-(, the pieces that are there >> are close to alpha, there should be some cleanup but August could be a >> reasonable time frame for an alpha iff we finally manage decide on the >> pointer stuff ASAP. >> >> Both implementations are there and running. Dirk wanted to work on it a >> while back but I don't have any feedback on the status right now.
It sounds like we need to get this done. IMHO, if we are going to keep OpenSG 2.0 moving forward, we need to set a date for this work to be completed to the point we can start testing it. Since one of the key people is going to be gone all of July, I propose we set a date of June 30th to have a first pass at the cptr implementation complete. With that said, is that date reasonable and what can the rest of us in the community do to help make it happen? > > Haven't gotten around to it. :( I want to do it, but other things seemt o get > into the way big time. :( :( Please let us know how we can help. > >> We both are in favor of using plain C pointers (IIRC) the only thing we >> could not really agree on was the use of RefPointer. I'm more cautious >> when using them internally and Dirk is more in favor of using them >> internally. But actually I'm ok with both as long as the performance >> does not decrease and I don't have to implement them ;-). > > :) AFAIR you were primarily worried about overhead when passing them around, > and > when using them in growing vectors. There was some discussion on boost about > moving vs. copying constructors a bit back, so I think the general problem is > understood. I think we can solve it by having an auto_ptr equivalent to pass > stuff around without refcount impact. > > The benefits I am hoping to get is simplified code, especially when it comes > to > parents and remembering where to increase/decrease refs. For the parents I > would > add a new FieldType that handles the parent linking/unlinking, and use that > instead of the normal MFFCPtr. > >> So if we agree on C pointer I could go ahead and remove the fcptr >> pointer code along with the mixin cleanup I did a while back. Once we >> have this part out of the way we can go ahead and look into the ref >> pointer problem. > > One of my goals with CPtr was to seriously simplify the code, which is why I > wanted to do it myself. If you could turn your head/hat inside out and look > at > it with the KISS view instead of the elegance view I would be very happy if > you > could move on that one a little bit. Having looked through GV's code I can say that it would be dramatically simplified by just having one ptr type. Yes, it would still need more documentation but a vast amount of the confusing indirection caused by the template metafunctions would just disappear. I find myself amazed that GV was even able to find a way to implement the stuff that is there. > >> s***, I am a core developer ;-). > > Ouch! How did that happen? Does it hurt? ;) > >> But 99% of my time I'm concerned about >> 2.x so I basically don't do any 1.x development anymore and >> intentionally left the 1.x release to Dirk and Andreas (sorry ;-)). > > That's ok, it was not your problem. > >> So for me 1.x is already dead and buried and I did not follow the >> discussion why 1.8 was not released yet, so I have no idea why it >> is delayed. > > I didn't push it hard enough, plain and simple. I did a few attempts to get > it > out, but I didn't push it hard enough. > > Thanks to the DB making an actual release is not that big a deal, it's > essentially just changing the rev number and waiting a day for everything to > be > built. It would be nice to have a MacOS db, so that we could have a MacOS > dist, > too... > > The main problem for me is that we need people to test everything to make > sure > all the installers/dists actually work as expected. I tried to launch people > to > test them two or three times, but I never got a single response from anybody. > Given that I'm not optimistic enough to believe that everything is just > working > that meant nobody tried it, and that's not good enough to release. > > So here's a new idea: we officially go into feature freeze on 1.8 now. I'll > set > up a page on the Wiki with a list of things that need to be tested and I'll > ask > users and core to pick one to try, and once it works, to strike it out on the > page. Once everything is done we release. I might need some help in setting > up > the list of things to test before I push it out. > > Comments? I like the idea. I think it would be good to float the idea on the user list after you create the wiki page and ask people there to contribute to the page of things that need fixed and tested. I for one will be *very* happy when 1.8 is out the door. As GV said, 1.8 is pretty much "dead and buried" for me as well. -Allen > > Dirk > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Opensg-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
