Thread: Debugger integration
Hi all, At Hiroshi's request I've just been testing the pl/pgsql debugger that he's been working on under OS X (For those that don't know, EnterpriseDB donated their wxWidgets based prototype debugger to us under our normal licence). So far, the code has been modified mainly to get rid of it's use of MDI windows, and to use wxAUI instead, and to integrate it into the pgAdmin build system. Having tried it on OS X, I find we have a problem. On that platform, executables are distributed inside 'appbundles' [1] which include resources without which applications cannot be used (they start, but cannot gain focus). What I didn't realise though, was that there doesn't seem to be a way to include the resources for two executables in the same appbundle. One workaround is to embed the resources into the debugger executable - this can be done with: `wx-config --rescomp` debugger However, whilst this works, the application menu still takes on the name of the appbundle (pgAdmin3), so you end up with the strange case where choosing the 'Exit pgAdmin3' menu option only exits the debugger. Another option is to build a second appbundle for the debugger, however we would want this to be included within the pgAdmin appbundle, not externally. I cannot see from the docs if this is actually possible. Anyone know? The final option (which I am currently favouring) would be to move the debugger code into pgAdmin itself, rather than keeping it as a separate application. This has the disadvantage that the architecture if the debugger is quite different from pgAdmin, so whilst it could work, it will always seem a little odd unless largely rewritten. Thoughts? Regards, Dave. [1] http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html
Dave Page wrote: > Hi all, > > So far, the code has been modified mainly to get rid of it's use of MDI > windows, and to use wxAUI instead, and to integrate it into the pgAdmin > build system. Cool. > Having tried it on OS X, I find we have a problem. On that platform, > executables are distributed inside 'appbundles' [1] which include > resources without which applications cannot be used (they start, but > cannot gain focus). What I didn't realise though, was that there doesn't > seem to be a way to include the resources for two executables in the > same appbundle. > Another option is to build a second appbundle for the debugger, however > we would want this to be included within the pgAdmin appbundle, not > externally. I cannot see from the docs if this is actually possible. > Anyone know? I believe that this is possible - I'll have to check, but I can vaguely remember that I already saw applications in the wild that did exactly this. Actually, it might be as easy as just putting a normal appbundle into the Ressources folder. > The final option (which I am currently favouring) would be to move the > debugger code into pgAdmin itself, rather than keeping it as a separate > application. This has the disadvantage that the architecture if the > debugger is quite different from pgAdmin, so whilst it could work, it > will always seem a little odd unless largely rewritten. Sounds like the most elegant option - do you think this will happen before 1.8, or should we pursue the appbundle-inside-appbundle idea for 1.8 greetings, Florian Pflug
Florian G. Pflug wrote: >> The final option (which I am currently favouring) would be to move the >> debugger code into pgAdmin itself, rather than keeping it as a separate >> application. This has the disadvantage that the architecture if the >> debugger is quite different from pgAdmin, so whilst it could work, it >> will always seem a little odd unless largely rewritten. > Sounds like the most elegant option - do you think this will happen > before 1.8, or should we pursue the appbundle-inside-appbundle idea > for 1.8 Whatever we do it needs to be for 1.8 - and I wantt get it done sooner rather than later (there are huge changes in the Windows build environments for PostgreSQL and pgInstaller that need my attention). I'd be happy to go with the embedded bundle option - what puts me off is that I'm still not overly confident with make etc. The merged code option is nicest in theory, but I'd be concerned that it would always seem like bolted on code without an almost complete rewrite (which seems pointless - Korry's code is perfectly good, just architected very differently from the rest of pgAdmin). If you can track down any info on embedded bundles, that would be a big help. I suspect this is the method that would be the most sensible overall. Regards, Dave.
From: "Florian G. Pflug" <fgp@phlo.org> > Dave Page wrote: >> Hi all, >> >> So far, the code has been modified mainly to get rid of it's use of MDI >> windows, and to use wxAUI instead, and to integrate it into the pgAdmin >> build system. > Cool. :-) > >> Having tried it on OS X, I find we have a problem. On that platform, >> executables are distributed inside 'appbundles' [1] which include >> resources without which applications cannot be used (they start, but >> cannot gain focus). What I didn't realise though, was that there doesn't >> seem to be a way to include the resources for two executables in the >> same appbundle. > >> Another option is to build a second appbundle for the debugger, however >> we would want this to be included within the pgAdmin appbundle, not >> externally. I cannot see from the docs if this is actually possible. >> Anyone know? > I believe that this is possible - I'll have to check, but I can vaguely > remember that I already saw applications in the wild that did exactly > this. Actually, it might be as easy as just putting a normal appbundle > into the Ressources folder. Oh, Sound good to me! > >> The final option (which I am currently favouring) would be to move the >> debugger code into pgAdmin itself, rather than keeping it as a separate >> application. This has the disadvantage that the architecture if the >> debugger is quite different from pgAdmin, so whilst it could work, it >> will always seem a little odd unless largely rewritten. > Sounds like the most elegant option - do you think this will happen > before 1.8, or should we pursue the appbundle-inside-appbundle idea > for 1.8 Umm, There may also be structure which debugger is connected with PostgreSQL by itself and waits for a response, and it may not be desirable on a constitution. The call from pgAdmin3 uses one stream of them. Probably, it may be hard to understand an operation of a users. Regards, Hiroshi Saito
Hiroshi Saito wrote: > Umm, There may also be structure which debugger is connected with > PostgreSQL by itself and waits for a response, and it may not be > desirable on a constitution. Yeah, that's a good point. In case that doesn't retranslate to German well, what Hiroshi is saying is that users can currently attach the debugger standalone from the command line, so integration might not be the best idea. Regards, Dave
Dave Page wrote: > Hiroshi Saito wrote: >> Umm, There may also be structure which debugger is connected with >> PostgreSQL by itself and waits for a response, and it may not be >> desirable on a constitution. > > Yeah, that's a good point. In case that doesn't retranslate to German > well, what Hiroshi is saying is that users can currently attach the > debugger standalone from the command line, so integration might not be > the best idea. OK, so what about a completely different idea. We just build two completly independent appbundles, distribute both together, and just add code to pgadmin to find the debugger application? I think OSX has support for this - after all, the finder finds the correct application to open a certain file with, even if you move the application around on your harddisk. That only works if mixing different versions of the debugger and of pgadmin3 doesn't cause trouble, of course. Alternatively, we could do both - include the debugger app in the pgadmin3 bundle, but also provide it separately. greetings, Florian Pflug
Hi Florian-san. debugger operates very wonderful by EnterpriseDB now. However, some functions for the operation still run short by the OSS-PostgreSQL version. Then, Korry-san will realize it soon. And the specification is very great. The specification of debugger contains the minimum for already using them by various functions now. The best offer is desired. I don't want to delete the present function... Therefore, I welcome your suggestion.:-) Thanks! Regards, Hiroshi Saito From: "Florian G. Pflug" <fgp@phlo.org> > Dave Page wrote: >> Hiroshi Saito wrote: >>> Umm, There may also be structure which debugger is connected with >>> PostgreSQL by itself and waits for a response, and it may not be >>> desirable on a constitution. >> >> Yeah, that's a good point. In case that doesn't retranslate to German >> well, what Hiroshi is saying is that users can currently attach the >> debugger standalone from the command line, so integration might not be >> the best idea. > > OK, so what about a completely different idea. We just build two > completly independent appbundles, distribute both together, and > just add code to pgadmin to find the debugger application? > > I think OSX has support for this - after all, the finder finds > the correct application to open a certain file with, even if > you move the application around on your harddisk. > > That only works if mixing different versions of the debugger and > of pgadmin3 doesn't cause trouble, of course. > > Alternatively, we could do both - include the debugger app in the > pgadmin3 bundle, but also provide it separately. > > greetings, Florian Pflug
Florian G. Pflug wrote: > Dave Page wrote: >> Hiroshi Saito wrote: >>> Umm, There may also be structure which debugger is connected with >>> PostgreSQL by itself and waits for a response, and it may not be >>> desirable on a constitution. >> >> Yeah, that's a good point. In case that doesn't retranslate to German >> well, what Hiroshi is saying is that users can currently attach the >> debugger standalone from the command line, so integration might not be >> the best idea. > > OK, so what about a completely different idea. We just build two > completly independent appbundles, distribute both together, and > just add code to pgadmin to find the debugger application? Running the debugger standalone only makes sense if started from the command line - it doesn't have the UI to let you attach it to anything. I realise that weakens Hiroshi's argument. Still, if it is it's own bundle inside the pgadmin bundle, then it wouldn't be hard to move it outside in the the future should someone write a UI... /D
Dave Page wrote: > I'd be happy to go with the embedded bundle option - what puts me off is > that I'm still not overly confident with make etc. The merged code > option is nicest in theory, but I'd be concerned that it would always > seem like bolted on code without an almost complete rewrite (which seems > pointless - Korry's code is perfectly good, just architected very > differently from the rest of pgAdmin). > > If you can track down any info on embedded bundles, that would be a big > help. I suspect this is the method that would be the most sensible overall. For info, I'm just about to commit changes that do exactly this - build a Debugger.app within the pgAdmin3.app resources directory - it seems to work fine, with one caveat: The existing complete-bundle.sh code works fine, and rewrites the paths to the wx libraries as expected, however the debugger crashes when run. As best I can figure, this is because although the debugger has the correct relative paths to the libraries, some of those (wx) libraries are interdependent, and when run by the debugger executable, the relative paths between them are incorrect. To resolve this until a better solution is found, I've modified the build system such that static linking is forced when building an app bundle. This also has the advantage of reducing the bundle size a little :-) Regards, Dave.
Dave Page wrote: > The existing complete-bundle.sh code works fine, and rewrites the paths > to the wx libraries as expected, however the debugger crashes when run. > As best I can figure, this is because although the debugger has the > correct relative paths to the libraries, some of those (wx) libraries > are interdependent, and when run by the debugger executable, the > relative paths between them are incorrect. I'll look into this. One solution might be to symlink the wx libs into the Debugger bundle, but I hope that there is a cleaner solution. > To resolve this until a better solution is found, I've modified the > build system such that static linking is forced when building an app > bundle. This also has the advantage of reducing the bundle size a little :-) The only downside of this that I can see is that the pgadmin3 binary gets _really_ huge (about 200M or so) when statically linked against wx. My old powerbook G4 takes a few minutes to even open that with gdb.. BTW, I've been working on an i386 binary of pgadmin3 that is statically linked. If've managed to compile static version of libxml, libxslt, wxwidgets and libpq, but configure fails for pgadmin3 because it doesn't know that it has to pass "-lssl" when linking against that static libpq. AFAIK, libtool ususally takes care of that, and provides dependency information for static libs. Neither wxwidgest nor postgres seem to create *.la files for my static libs - Does anyone know if they should - or how to deal with static linking without libtool? greetings, Florian Pflug
Florian G. Pflug wrote: > Dave Page wrote: >> The existing complete-bundle.sh code works fine, and rewrites the paths >> to the wx libraries as expected, however the debugger crashes when run. >> As best I can figure, this is because although the debugger has the >> correct relative paths to the libraries, some of those (wx) libraries >> are interdependent, and when run by the debugger executable, the >> relative paths between them are incorrect. > I'll look into this. One solution might be to symlink the wx libs > into the Debugger bundle, but I hope that there is a cleaner solution. > >> To resolve this until a better solution is found, I've modified the >> build system such that static linking is forced when building an app >> bundle. This also has the advantage of reducing the bundle size a >> little :-) > The only downside of this that I can see is that the pgadmin3 binary gets > _really_ huge (about 200M or so) when statically linked against wx. My old > powerbook G4 takes a few minutes to even open that with gdb.. So don't use --enable-appbundle with --enable-debug. The debug bundle should still work in that instance shouldn't it? > BTW, I've been working on an i386 binary of pgadmin3 that is statically > linked. > If've managed to compile static version of libxml, libxslt, wxwidgets and > libpq, but configure fails for pgadmin3 because it doesn't know that it has > to pass "-lssl" when linking against that static libpq. AFAIK, libtool > ususally > takes care of that, and provides dependency information for static libs. > > Neither wxwidgest nor postgres seem to create *.la files for my static > libs - > Does anyone know if they should - or how to deal with static linking > without > libtool? I'm missing something I guess - whilst it only links statically with wx and pg, we already have --enable-static which works fine on intel and ppc macs. That's the option I now force on when building an appbundle. Regards, Dave.
Dave Page wrote: > Florian G. Pflug wrote: >> BTW, I've been working on an i386 binary of pgadmin3 that is statically >> linked. >> If've managed to compile static version of libxml, libxslt, wxwidgets and >> libpq, but configure fails for pgadmin3 because it doesn't know that it has >> to pass "-lssl" when linking against that static libpq. AFAIK, libtool >> ususally >> takes care of that, and provides dependency information for static libs. >> >> Neither wxwidgest nor postgres seem to create *.la files for my static >> libs - >> Does anyone know if they should - or how to deal with static linking >> without >> libtool? > > I'm missing something I guess - whilst it only links statically with wx > and pg, we already have --enable-static which works fine on intel and > ppc macs. That's the option I now force on when building an appbundle. acinclude.m4 seems to special-case static linking on osx, and adds -lssl if it thinks that is needed. (I think it was me who added that code, but I seem to have forgotten about it.. ;-) ). I'm currently thinking that unconditionally adding the output of pg_config --libs to LIBS if linking statically might be a better approach - thoughts? greetings, Florian Pflug
Florian G. Pflug wrote: > Dave Page wrote: >> Florian G. Pflug wrote: >>> BTW, I've been working on an i386 binary of pgadmin3 that is statically >>> linked. >>> If've managed to compile static version of libxml, libxslt, wxwidgets >>> and >>> libpq, but configure fails for pgadmin3 because it doesn't know that >>> it has >>> to pass "-lssl" when linking against that static libpq. AFAIK, libtool >>> ususally >>> takes care of that, and provides dependency information for static libs. >>> >>> Neither wxwidgest nor postgres seem to create *.la files for my static >>> libs - >>> Does anyone know if they should - or how to deal with static linking >>> without >>> libtool? >> >> I'm missing something I guess - whilst it only links statically with wx >> and pg, we already have --enable-static which works fine on intel and >> ppc macs. That's the option I now force on when building an appbundle. > > acinclude.m4 seems to special-case static linking on osx, and > adds -lssl if it thinks that is needed. (I think it was me > who added that code, but I seem to have forgotten about it.. ;-) ). > > I'm currently thinking that unconditionally adding the output > of pg_config --libs to LIBS if linking statically might > be a better approach - thoughts? That whole section of the file seems a bit kooky to me - it does some weird stuff on Solaris as well. pg_config --libs does output more than we need for libpq though, so I'm a little loathe to use it - what about just conditionally adding the -lssl, if you can grep it form the pg_config output? Regards, Dave
Dave Page wrote: > Florian G. Pflug wrote: >> I'm currently thinking that unconditionally adding the output >> of pg_config --libs to LIBS if linking statically might >> be a better approach - thoughts? > > That whole section of the file seems a bit kooky to me - it does some > weird stuff on Solaris as well. > > pg_config --libs does output more than we need for libpq though, so I'm > a little loathe to use it - what about just conditionally adding the > -lssl, if you can grep it form the pg_config output? Yeah - realized that too, seconds after I mailed.. The problem with grepping for -lssl is that AFAIK some plattforms need more than -lssl (Like -lcrypto). So if we're going that way, we won't get rid of all that plattform-specific uglyness in that section. Maybe removing those libs from the output of pg_config that we surely don't need or want (like -lpgport) is workable alternative? greetings, Florian Pflug
Florian G. Pflug wrote: > Dave Page wrote: >> Florian G. Pflug wrote: >>> I'm currently thinking that unconditionally adding the output >>> of pg_config --libs to LIBS if linking statically might >>> be a better approach - thoughts? >> >> That whole section of the file seems a bit kooky to me - it does some >> weird stuff on Solaris as well. >> >> pg_config --libs does output more than we need for libpq though, so I'm >> a little loathe to use it - what about just conditionally adding the >> -lssl, if you can grep it form the pg_config output? > > Yeah - realized that too, seconds after I mailed.. > The problem with grepping for -lssl is that AFAIK some > plattforms need more than -lssl (Like -lcrypto). So > if we're going that way, we won't get rid of all that > plattform-specific uglyness in that section. > > Maybe removing those libs from the output of pg_config that > we surely don't need or want (like -lpgport) is workable > alternative? Yeah, that sounds reasonable. Regards, Dave
Dave Page wrote: > Florian G. Pflug wrote: >> Dave Page wrote: >>> Florian G. Pflug wrote: >>>> I'm currently thinking that unconditionally adding the output >>>> of pg_config --libs to LIBS if linking statically might >>>> be a better approach - thoughts? >>> That whole section of the file seems a bit kooky to me - it does some >>> weird stuff on Solaris as well. >>> >>> pg_config --libs does output more than we need for libpq though, so I'm >>> a little loathe to use it - what about just conditionally adding the >>> -lssl, if you can grep it form the pg_config output? >> Yeah - realized that too, seconds after I mailed.. >> The problem with grepping for -lssl is that AFAIK some >> plattforms need more than -lssl (Like -lcrypto). So >> if we're going that way, we won't get rid of all that >> plattform-specific uglyness in that section. >> >> Maybe removing those libs from the output of pg_config that >> we surely don't need or want (like -lpgport) is workable >> alternative? > > Yeah, that sounds reasonable. I'll try to do that, and try to cleanup that part of acinclude.m4. greetings, Florian Pflug
Florian G. Pflug wrote: >>> Maybe removing those libs from the output of pg_config that >>> we surely don't need or want (like -lpgport) is workable >>> alternative? >> >> Yeah, that sounds reasonable. > > I'll try to do that, and try to cleanup that part of acinclude.m4. Thanks :-) Regards, Dave