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
Cool. I'm assigning you to the blueprint for my_malloc/my_free cleanup. As a warning, there are three larger/uglier things in the mysys freedom you'll hit (we just did this last week and are re-doing it now in smaller pieces) MEM_ROOT MYSQL_CHARSET client_error[] Welcome to the fun! > Cheers, > Toru > > On Thu, Jul 24, 2008 at 7:03 AM, Monty Taylor <[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> > >>>>>>>>> (cd .libs && rm -f libdrizzle.la <http://libdrizzle.la> && > ln -s ../libdrizzle.la <http://libdrizzle.la> > >>>>>>>>> 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 > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
