Toru Maesaka wrote: > Hi Patrick, > > Theres no plans on changing function names but those with my_bool as the > return type will be changed to bool... so we might come across conflicts ;-) > > Saying that, when is your work going to be merged to the trunk? I could > either merge your tree now and keep working on that, or if its going to > be merged to the trunk soon then I can wait for that and face possible > merge conflicts then.
It's ready to be merged now... > I don't think we'll face anything nasty though :) > > Cheers, > Toru > > I won't be changing the > > On Thu, Jul 24, 2008 at 9:41 PM, Patrick Galbraith <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Toru, Monty, > > I've converted drizzle.h, now working on client.c/libdrizzle, then > client programs - just renames so far. Hopefully everything you do > will merge with my changes ;) </anticipation> You aren't changing > any names, correct? Just making sure. > > --Patrick > > Toru Maesaka wrote: > > Hi guys, > > Letting you all know that I've begun working on freeing > libdrizzle from mysys. So far I've replaced my_malloc/my_free > with malloc(3)/free(3) and I'm about to get rid of my_bools. > Hopefully libdrizzle will be freed from mysys in no time :) > > Btw, the branch I'm working with is > lp:~dev-torum/drizzle/libdrizzle-cleanup > > Cheers, > Toru > > On Thu, Jul 24, 2008 at 7:03 AM, Monty Taylor > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > > Jay Pipes wrote: > > OK, Patrick and MontyT, I have set up all the tasks and > subtasks on > > Launchpad as blueprints, and added dependencies between them. > Some have > > already been assigned to each of you. > > > > Like I mentioned to Monty on IRC, here is what I propose for > development > > process of these interrelated tasks: > > > > The easiest way to work on this stuff is bzr branch from trunk > into a > > local branch named the same as the blueprint task (takes > care of > > uniqueness there!) and then push to > ~mordred/drizzle/blueprint-name. I > > will then take care of merges into the depending branches > locally, > > resolve conflicts, and push a branch to the > > ~drizzle-developers/drizzle/medium-blueprint-name > > > > Work for everyone? > > Yes ... except I think that in some cases we might be able to > merge > directly back to trunk, depending on the blueprint and the > state of > other work, etc... but that's what communication is all about! > > > -jay > > > > Monty Taylor wrote: > >> Jay Pipes wrote: > >>> Monty Taylor wrote: > >>>> Yes. That should be DRIZZLE *... > >>>> Ok. I think I have officially drug this branch down the > rathole. I'm > >>>> terribly sorry for wrecking work and delaying > DBD::drizzle... > >>> Don't apologize, there is no need to. :) > >> Thanks guys. > >> > >>>> Jay just sent me an email about his work in the tree today, > which came > >>>> to the sensible conclusion that the changes I was committing > were too > >>>> interwoven to be able to backtrack through them > successfully... and he's > >>>> totally right. > >>>> > >>>> Jay is going to look at starting from scratch from trunk and > starting to > >>>> apply the patches one bit at a time. (I think I know > where it > broke, but > >>>> it's all too much atm) > >>>> > >>>> I think we should/can divvy this up a bit, so we don't (and > by we, this > >>>> week I seem to mean me) break each other's work. > >>>> > >>>> SO, I propose these related but unrelated tasks. > >>> Yes, small, bitesize tasks, each attached to a blueprint > which > can be > >>> made dependent on each other. Create a branch for each small > task, > >>> attached to the blueprint. Merge proposals will go from > small > task > >>> branch -> medium task branch -> large task branch ->trunk. I > am happy > >>> to manage the blueprint dependencies and simply assign > them to > you and > >>> Patrick as you want them...I am also working on putting > together a > >>> buildbot master soon so we can start automating builds > and tests. > >> I mostly agree, but I'm not 100% sure each of the bullet > points > needs to > >> be a full blueprint/branch on its own, since some of the > bullet > points > >> weren't split by task as much as just to try to remember each > bit... but > >> I'm good either way. > >> > >>>> TASK ONE: Rename mysql to drizzle OR to something more > generic where it > >>>> will touch storage engines. This includes: > >>> The above is a medium task, composed of the below small > tasks... > >>> > >>>> - Replacing use of the MYSQL_TYPE_* constants to FIELD_* > >>>> - Renaming MYSQL_* types in drizzle.h to DRIZZLE_* > >>>> - Renaming MYSQL* defines to DRIZZLE* > >>>> - Changing mysql_init() to drizzle_create() > >> Forgot to add: > >> > >> - Rename mysql_* functions to drizzle_* > >> > >> doh. > >> > >>> Cool. :) > >>> > >>>> - Moving my_thread_init(), my_net_init(), etc. into > drizzle_create() > >>> Excellent. > >>> > >>>> - Rename mysql_real_* to just drizzle_* > >>> Or killing them off completely. If it smells like a hack, it > probably is.... > >> Yes... most of the *_real_* methods are stupid wrappers around > old calls > >> in an attempt to ease ABI transitions. But I don't care about > that... > >> > >> Also, might want to add: > >> > >> - Rename functions starting with cli_* > >> > >> that might be short for "client" (which is overused word > anyway) but it > >> makes me think "Command Line Interface", so I hate it. > >> > >>>> (I think I can re-do the first four bullets above pretty > quickly now > >>>> that I know where it's all hanging together. I'd like > someone > else to > >>>> look at bullet 5 - I think it needs a different set of > eyes.) > >>> Happy to. > >>> > >>>> TASK TWO: Remove the mysys/mystrings depends from > libdrizzle. > The main > >>>> depends are charsets, my_malloc/my_free, some lame string > manipulation > >>>> functions (and one nice one), bad header file organization > and errors. > >>>> (Could conceivably be done in parallel... but probably > should > wait for > >>>> the above to be done and merged) > >>> Again, this is a medium task with the following smaller > tasks. > What > >>> should be decided is whether indeed this can be done in > parallel or this > >>> is dependent on the above tasks being completed. I suspect > that they > >>> can be done in parallel but in separate, smaller trees. > >> Yes, you are probably right here. > >> > >>>> - Replacing my_malloc/my_free with normal malloc/free > >>> Sure, but some places should not be a blanket replacement. I > noticed a > >>> couple places in your tree where my_multi_malloc() was > replaced with > >>> many small malloc calls, which is not efficient...perhaps for > now tackle > >>> single malloc calls. IMHO, For this tree, it is essential > that valgrind > >>> be run cleanly before any merge into another tree... > >> Agree. What do you think we should do with my_multi_malloc? > Also, some > >> of the my_free calls when replaced need to be prefixed with a > >> if (bla!=NULL) protection. > >> > >>>> - Removing use of non-standard string functions > >>>> - Removing charset references from libdrizzle (make > the lib > send the > >>>> bytes the programmer sends) > >>> Heh, these two might have to wait a bit... > >> Non-standard string functions in libdrizzle turned out to be > surpisingly > >> easy to eradicate. > >> > >> The charset references actually also aren't _too_ > terrible... but I > >> agree, there is a larger conversation here... but it's got to > go if we > >> want libsys out of libdrizzle - or we've got to figure out > a way to > >> sensibly pull in only the bits we absolutely have to have > >> > >>>> - Moving some stuff around in headers (I think I did this > mostly > >>>> right, so most of this can be copied verbatim) > >>>> - Removing use of MEM_ROOT in libdrizzle. This most > affects > >>>> MYSQL_FIELD and MYSQL_ROWS. While we're at it, we > curse the > >>>> MYSQL_ROWS implementation. (BTW Stewart - the first > time I did > >>>> this, I was yearning for talloc...) > >>> This is a medium task in itself in my opinion, even if > only for > >>> libdrizzle. Messing with MEM_ROOT is a serious undertaking. > I would > >>> recommend moving this to a separate medium task and branch. > >> Agree. There are a couple of places where it especially > sucks. But > >> definitely only talking about libdrizzle. > >> > >>>> TASK THREE: Figuring out what to do with the ER() macros and > >>>> client_errors[] (NOT RELATED TO THE ABOVE... CAN BE > PARALLEL) > >>>> (I didn't do this right the first time at all) > >>>> This whole thing is a mess, as there are global static > arrays that are > >>>> shared between client and server, and we generate these > things with > >>>> comp_err. I'd say it's a later design issue to be solved, > but it's > >>>> keeping libdrizzle tied to mysys... and it's a spiderweb > anyway. > >>> This task should be dependent on both medium task 1 and 2 > (b/c of > >>> changes to the same files in #1 and movement of header files > in #2) > >> Agree. > >> > >> I should also mention that there are a couple of places where > the IMPL > >> code of libdrizzle references mysqld errors (ER_*) as a > protocol > >> library, this is insane... either the error codes are ones > defined by > >> the protocol (in which case they should be defined by the lib) > or they > >> are internal mysqld errors, in which case the client should > never see them. > >> > >>>> Once all of that is done and all still compiles and is > merged, _then_ we > >>>> can tackle (instead of doing it all in one fell swoop): > >>>> > >>>> - Removing references to deprecated things in client/ > >>>> > >>>> - Password support functions > >>>> - Unix Domain Sockets > >>>> - Shared Memory > >>>> - Embedded Server > >>>> (but keeping the command line options as null-ops for now) > >>> Yep, medium task with subtasks all dependent on #1,2,3. > >> Agree. > >> > >>>> - Removing mysys/mystrings from client/ > >>> This is going to be a larger debate. ;) > >> Tell me about it. :) > >> > >>>> - moving mysqlbinlog to a binlog dir, which will eventually > also house > >>>> binlong related files from server/ for a libbinlog ... but > that's a > >>>> whole other thing. > >>> Sure. > >>> > >>>> Hopefully if we do it right, dormando and krow can continue > working on > >>>> the blocking/non-blocking IO issue, and possibly krow's > interest in > >>>> removing vio... > >>> Sure. > >>> > >>>> At this point, libdrizzle can become a source package > with no > external > >>>> depends. and we can: > >>>> > >>>> - Rearrange/split up header files and code for libdrizzle - > sort of like > >>>> how libmemcached is - file for DRIZZLE_ROW, file for > DRIZZLE_FIELD, etc. > >>> Yep, this is the last major task... > >>> > >>>> Thoughts/comments? Bricks to the head? If this sounds > good to > you guys, > >>>> I'll transfer it to the blueprint... > >>> Happy to help. Shall we get going? :) > >> Hell yes. > >> > >>> -jay > >>> > >>>> Monty > >>>> > >>>> Patrick Galbraith wrote: > >>>>> Monty, > >>>>> > >>>>> Now I get this error: > >>>>> > >>>>> o -MD -MP -MF ".deps/linktest.Tpo" -c -o linktest.o > linktest.c; \ > >>>>> then mv -f ".deps/linktest.Tpo" ".deps/linktest.Po"; > else rm -f > >>>>> ".deps/linktest.Tpo"; exit 1; fi > >>>>> linktest.c:2:25: error: mysql/mysql.h: No such file or > directory > >>>>> linktest.c: In function 'main': > >>>>> linktest.c:13: error: 'MYSQL' undeclared (first use in this > function) > >>>>> linktest.c:13: error: (Each undeclared identifier is > reported only once > >>>>> linktest.c:13: error: for each function it appears in.) > >>>>> linktest.c:13: error: expected ';' before 'my' > >>>>> linktest.c:15: error: 'my' undeclared (first use in this > function) > >>>>> make[1]: *** [linktest.o] Error 1 > >>>>> > >>>>> So, linktest.c has: > >>>>> > >>>>> nt main(int argc, char** argv) { > >>>>> > >>>>> (void)argc; > >>>>> (void)argv; > >>>>> > >>>>> MYSQL my; > >>>>> > >>>>> ... > >>>>> > >>>>> Shouldn't it be DRIZZLE my ? > >>>>> > >>>>> Monty Taylor wrote: > >>>>>> Patrick Galbraith wrote: > >>>>>> > >>>>>>> Monty Taylor wrote: > >>>>>>> > >>>>>>>> I stuck a file called "linktest.c" into the libdrizzle > dir to test for > >>>>>>>> missing symbols in libdrizzle while we were removing > depends. Sounds > >>>>>>>> like it got removed. > >>>>>>>> > >>>>>>>> Patrick Galbraith wrote: > >>>>>>>> > >>>>>>>>> I have all the client calls renamed to drizzle_xxx > and when > >>>>>>>>> compiling, get this error that doesn't tell me much: > >>>>>>>>> > >>>>>>>>> creating libdrizzle.la <http://libdrizzle.la> > <http://libdrizzle.la> > >>>>>>>>> (cd .libs && rm -f libdrizzle.la > <http://libdrizzle.la> <http://libdrizzle.la> > && ln -s ../libdrizzle.la <http://libdrizzle.la> > <http://libdrizzle.la> > >>>>>>>>> libdrizzle.la <http://libdrizzle.la> > <http://libdrizzle.la>) > > >>>>>>>>> make[1]: *** No rule to make target `linktest.o', > needed by > >>>>>>>>> `linktest'. Stop. > >>>>>>>>> > >>>>>>>>> That's the only error, everything else seems to go > fine. Any > >>>>>>>>> thoughts? I could push this to a special tree if anyone > wants to look > >>>>>>>>> at it. > >>>>>>>>> > >>>>>>>>> --Patrick > >>>>>>>>> > >>>>>>>>> > >>>>>>> Monty, > >>>>>>> > >>>>>>> Could you please re-commit/push ? ;) > >>>>>>> > >>>>>> Yes! Committing-pushing right now! > >>>>>> > >>>>>> Monty > >>>>>> > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > <https://launchpad.net/%7Edrizzle-discuss> > <https://launchpad.net/%7Edrizzle-discuss> > > Post to : [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > Unsubscribe : https://launchpad.net/~drizzle-discuss > <https://launchpad.net/%7Edrizzle-discuss> > <https://launchpad.net/%7Edrizzle-discuss> > > More help : https://help.launchpad.net/ListHelp > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > <https://launchpad.net/%7Edrizzle-discuss> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~drizzle-discuss > <https://launchpad.net/%7Edrizzle-discuss> > More help : https://help.launchpad.net/ListHelp > > > > > -- > > Satyam Eva Jayate - Truth Alone Triumphs > Mundaka Upanishad > > > > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
