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.
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]> 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]>> 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>
>> <https://launchpad.net/%7Edrizzle-discuss>
>> Post to : [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]
>> 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
