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]>> 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
<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
------------------------------------------------------------------------
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
