Hi, > 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
well for me it is not dead yet ;-) I will try to update the visual studio project files on monday that's the last open point on my side. Andreas ------------------------------------------------------------------------- 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
