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/documenta...les/index.html

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster