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]> 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
> >>>>>>>>> (cd .libs && rm -f libdrizzle.la && ln -s ../libdrizzle.la
> >>>>>>>>> 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]
> 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
