Re: [pgadmin-hackers] Mac Port
Hi most probably you did not link the resources to the project, did you adapt the makefiles ? you can have a look at the minimal makefile that gets generated by configure in your mac builddir. Best, Stefan > -Original Message- > From: Adam H. Pendleton [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 30. September 2003 23:44 > To: [EMAIL PROTECTED] > Cc: Stefan Csomor > Subject: Mac Port > > Well, after fixing the xrc detection problem, and the library > naming problem, I've gotten pgAdmin3 to run on my Mac. The > language selection screen appears, but then I cannot select > anything, nor can I even give the window focus. I remember > this problem existing when I was originally working on the > Mac port. I am CCing Stefan on this post; follow the link > below for a screen shot: > > http://www.fmonkey.net/pgastartup.jpg > > I don't remember now how I fixed this before, so I'll have to > do some research. Stefan, maybe you have a quick answer (if > there is such a thing)? :-) > > ahp > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
At 11:31 30/09/2003 +0200, Jean-Michel POURE wrote: Seems like we have to choose between --with-mac and --with-cocoa. I would say (without really knowing) that --with-mac is the compatibility layer of MacOsX to old Macintosh applications, whereas --with-cocoa is the native MacOsX interface. But this may well be the converse. Julian, could you tell us more about these issues? Hi, wxCocoa is very much a work in progress and no-one is seriously using it yet as far as I know. The chap to ask is: David Elliott <[EMAIL PROTECTED]> wxCocoa is a wrapper around Cocoa, and wxMac is a wrapper around Carbon and (to be deprecated) the Classic API. Carbon apps should work under both OSX and Mac Classic, whereas Cocoa apps would only work on OSX. For information about wxMac, the relevant contact is: Stefan Csomor <[EMAIL PROTECTED]> Regards, Julian = Julian Smart mailto:[EMAIL PROTECTED] 3 Water Street, Stamford, www.anthemion.co.uk Lincs, U.K., PE9 2NJ +44 (0)1780 765976 StoryLines: story structuring www.storylinescentral.com HelpBlocks: HTML help authoring www.helpblocks.com DialogBlocks: cross-platform dialogs www.anthemion.co.uk/dialogblocks = ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
> -Original Message-
> From: Adam H.Pendleton [mailto:[EMAIL PROTECTED]
> Sent: 30 September 2003 22:20
> To: Adam Witney
> Cc: [EMAIL PROTECTED]; Julian Smart; pgadmin-hackers
> Subject: Re: [pgadmin-hackers] pgAdmin III under wxCocoa
>
>
> On Tuesday, Sep 30, 2003, at 05:40 US/Eastern, Adam Witney wrote:
>
> > And the relevant part of config.log says
> >
> > configure:4634: gcc -o conftest -Wall -g -O0 -DSSL
> > -I/usr/local/pgsql/include -L/usr/local/pgsql/lib conftest.c -lpq
> > /usr/local/pgsql/l ib/libpq.a -lcrypt -lssl -lcrypto >&5
> > ld: can't locate file for: -lcrypt
> > configure:4637: $? = 1
> > configure: failed program was:
> > | #line 4610 "configure"
> >
>
> Hmmm. I just downloaded and './configure'd pgAdmin3 on my
> system, and
> it doesn't even link against libcrypt. This is because only
> the static
> version of pgAdmin3 links against libcrypt. IIRC, this
> dependency was
> added to the build system to support Slackware. Dave, could
> you change
> line 114 from:
>
> LIBS="${LIBPQ_HOME}/lib/libpq.a -lcrypt $LIBS -lssl -lcrypto"
Dynamic build works, static does not. Incidently, --disable-static
doesn't work, despite prompts indicating that it should. I also note
that snake is linking with libwx_gtk2ud-2.5.a no matter what build type
is performed - I assume this is because that's what wx-config tells it
to do?
Regards, Dave.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [pgadmin-hackers] acinclude.m4.patch
> -Original Message- > From: Adam H.Pendleton [mailto:[EMAIL PROTECTED] > Sent: 30 September 2003 22:29 > To: [EMAIL PROTECTED] > Subject: [pgadmin-hackers] acinclude.m4.patch > > > This is a small patch that changes the file we check for to > validate a > wxWindows xrc installation (this file is not installed on > Mac). Before > applying, could someone verify that this file is installed on all > autoconf platforms? Looks OK here. Patch applied. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Hi
I think (I'm not fluent on the console ;-) it's --disable-shared for getting
static libs
Best,
Stefan
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> Sent: Mittwoch, 1. Oktober 2003 08:40
> To: Adam H.Pendleton; Adam Witney
> Cc: [EMAIL PROTECTED]; Julian Smart; pgadmin-hackers
> Subject: Re: [pgadmin-hackers] pgAdmin III under wxCocoa
>
>
>
> > -Original Message-
> > From: Adam H.Pendleton [mailto:[EMAIL PROTECTED]
> > Sent: 30 September 2003 22:20
> > To: Adam Witney
> > Cc: [EMAIL PROTECTED]; Julian Smart; pgadmin-hackers
> > Subject: Re: [pgadmin-hackers] pgAdmin III under wxCocoa
> >
> >
> > On Tuesday, Sep 30, 2003, at 05:40 US/Eastern, Adam Witney wrote:
> >
> > > And the relevant part of config.log says
> > >
> > > configure:4634: gcc -o conftest -Wall -g -O0 -DSSL
> > > -I/usr/local/pgsql/include -L/usr/local/pgsql/lib
> conftest.c -lpq
> > > /usr/local/pgsql/l ib/libpq.a -lcrypt -lssl -lcrypto >&5
> > > ld: can't locate file for: -lcrypt
> > > configure:4637: $? = 1
> > > configure: failed program was:
> > > | #line 4610 "configure"
> > >
> >
> > Hmmm. I just downloaded and './configure'd pgAdmin3 on my
> system, and
> > it doesn't even link against libcrypt. This is because only the
> > static version of pgAdmin3 links against libcrypt. IIRC, this
> > dependency was added to the build system to support
> Slackware. Dave,
> > could you change line 114 from:
> >
> > LIBS="${LIBPQ_HOME}/lib/libpq.a -lcrypt $LIBS -lssl -lcrypto"
>
> Dynamic build works, static does not. Incidently,
> --disable-static doesn't work, despite prompts indicating
> that it should. I also note that snake is linking with
> libwx_gtk2ud-2.5.a no matter what build type is performed - I
> assume this is because that's what wx-config tells it to do?
>
> Regards, Dave.
>
> ---(end of
> broadcast)---
> TIP 9: the planner will ignore your desire to choose an index
> scan if your
> joining column's datatypes do not match
>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
> -Original Message- > From: Stefan Csomor [mailto:[EMAIL PROTECTED] > Sent: 01 October 2003 09:09 > To: Dave Page; 'Adam H.Pendleton'; 'Adam Witney' > Cc: [EMAIL PROTECTED]; 'Julian Smart'; 'pgadmin-hackers' > Subject: RE: [pgadmin-hackers] pgAdmin III under wxCocoa > > > Hi > > I think (I'm not fluent on the console ;-) it's > --disable-shared for getting static libs Hi Stefan, We used --enable-static rather than --disable-shared (can't remember why). From acinclude.m4: # Static build of pgAdmin3 # AC_DEFUN([ENABLE_STATIC], [AC_ARG_ENABLE(static, [ --enable-static build a static version of pgAdmin3], [pg_static_build=yes], [pg_static_build=no]) ]) Looking at that of course, it looks like --disable-static is not defined anyway which would explain why it doesn't work. Regards, Dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Mac Port
Le Mercredi 1 Octobre 2003 00:43, Adam H.Pendleton a écrit : > http://www.fmonkey.net/pgastartup.jpg > > I don't remember now how I fixed this before, so I'll have to do some > research. Stefan, maybe you have a quick answer (if there is such a > thing)? :-) Dear Adam H. Pendleton, Nice Macintosh. Is this a new platform? How wide is your screen? Sorry for the late reply because of the jet lag :) The language list is displayed in UTF-8 because our translations are stored in Unicode. wxMac does not support Unicode and hence fails to display some languages. If you compile pgAdmin3 without Unicode, you should be able to view pgAdmin3 English interface. Most European languages should display (with accent problems). Because Unicode is based on ASCII characters, it should not break pgAdmin logic. Could Andreas confirm? Dear Stefan, is there a way to use the iconv library as a wrapper to recode strings on the fly from Unicode to Apple format. Do you think iconv is a working solution to display Unicode strings in MacOs10.2 until MacOsX 10.3 is out? By the way, Adam, I did not apply the patches. Could you contact me on my ICQ to explain more deeply what needs to be done. I would like to set up a MacOsX section on the development page and display the recommanded configuration settings. Below is a list of known encodings supported by inconv. Cheers, Jean-Michel # iconv --list La liste suivante contient tous les jeux des codes de caractères connus. Ceci ne signifie pas nécessairement que toutes les combinaisons de ces noms peuvent être utilisées dans les paramètres « FROM » et « TO » des commandes. Un jeu de codes de caractères peut être affiché avec différents noms (aliases). 437, 500, 500V1, 850, 851, 852, 855, 856, 857, 860, 861, 862, 863, 864, 865, 866, 866NAV, 869, 874, 904, 1026, 1046, 1047, 8859_1, 8859_2, 8859_3, 8859_4, 8859_5, 8859_6, 8859_7, 8859_8, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ANSI_X3.4-1968, ANSI_X3.4-1986, ANSI_X3.4, ANSI_X3.110-1983, ANSI_X3.110, ARABIC, ARABIC7, ARMSCII-8, ASCII, ASMO-708, ASMO_449, BALTIC, BIG-5, BIG-FIVE, BIG5-HKSCS, BIG5, BIG5HKSCS, BIGFIVE, BS_4730, CA, CN-BIG5, CN-GB, CN, CP-AR, CP-GR, CP-HU, CP037, CP038, CP273, CP274, CP275, CP278, CP280, CP281, CP282, CP284, CP285, CP290, CP297, CP367, CP420, CP423, CP424, CP437, CP500, CP737, CP775, CP813, CP819, CP850, CP851, CP852, CP855, CP856, CP857, CP860, CP861, CP862, CP863, CP864, CP865, CP866, CP866NAV, CP868, CP869, CP870, CP871, CP874, CP875, CP880, CP891, CP903, CP904, CP905, CP912, CP915, CP916, CP918, CP920, CP922, CP930, CP932, CP933, CP935, CP936, CP937, CP939, CP949, CP950, CP1004, CP1026, CP1046, CP1047, CP1070, CP1079, CP1081, CP1084, CP1089, CP1124, CP1125, CP1129, CP1132, CP1133, CP1160, CP1161, CP1162, CP1163, CP1164, CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, CP1256, CP1257, CP1258, CP1361, CP10007, CPIBM861, CSA7-1, CSA7-2, CSASCII, CSA_T500-1983, CSA_T500, CSA_Z243.4-1985-1, CSA_Z243.4-1985-2, CSA_Z243.419851, CSA_Z243.419852, CSDECMCS, CSEBCDICATDE, CSEBCDICATDEA, CSEBCDICCAFR, CSEBCDICDKNO, CSEBCDICDKNOA, CSEBCDICES, CSEBCDICESA, CSEBCDICESS, CSEBCDICFISE, CSEBCDICFISEA, CSEBCDICFR, CSEBCDICIT, CSEBCDICPT, CSEBCDICUK, CSEBCDICUS, CSEUCKR, CSEUCPKDFMTJAPANESE, CSGB2312, CSHPROMAN8, CSIBM037, CSIBM038, CSIBM273, CSIBM274, CSIBM275, CSIBM277, CSIBM278, CSIBM280, CSIBM281, CSIBM284, CSIBM285, CSIBM290, CSIBM297, CSIBM420, CSIBM423, CSIBM424, CSIBM500, CSIBM851, CSIBM855, CSIBM856, CSIBM857, CSIBM860, CSIBM863, CSIBM864, CSIBM865, CSIBM866, CSIBM868, CSIBM869, CSIBM870, CSIBM871, CSIBM880, CSIBM891, CSIBM903, CSIBM904, CSIBM905, CSIBM918, CSIBM922, CSIBM930, CSIBM932, CSIBM933, CSIBM935, CSIBM937, CSIBM939, CSIBM943, CSIBM1026, CSIBM1124, CSIBM1129, CSIBM1132, CSIBM1133, CSIBM1160, CSIBM1161, CSIBM1163, CSIBM1164, CSIBM11621162, CSISO4UNITEDKINGDOM, CSISO10SWEDISH, CSISO11SWEDISHFORNAMES, CSISO14JISC6220RO, CSISO15ITALIAN, CSISO16PORTUGESE, CSISO17SPANISH, CSISO18GREEK7OLD, CSISO19LATINGREEK, CSISO21GERMAN, CSISO25FRENCH, CSISO27LATINGREEK1, CSISO49INIS, CSISO50INIS8, CSISO51INISCYRILLIC, CSISO58GB1988, CSISO60DANISHNORWEGIAN, CSISO60NORWEGIAN1, CSISO61NORWEGIAN2, CSISO69FRENCH, CSISO84PORTUGUESE2, CSISO85SPANISH2, CSISO86HUNGARIAN, CSISO88GREEK7, CSISO89ASMO449, CSISO90, CSISO92JISC62991984B, CSISO99NAPLPS, CSISO103T618BIT, CSISO111ECMACYRILLIC, CSISO121CANADIAN1, CSISO122CANADIAN2, CSISO139CSN369103, CSISO141JUSIB1002, CSISO143IECP271, CSISO150, CSISO150GREEKCCITT, CSISO151CUBA, CSISO153GOST1976874, CSISO646DANISH, CSISO2022CN, CSISO2022JP, CSISO2022JP2, CSISO2022KR, CSISO2033, CSISO5427CYRILLIC, CSISO5427CYRILLIC1981, CSISO5428GREEK, CSISO10367BOX, CSISOLATIN1, CSISOLATIN2, CSISOLATIN3, CSISOLATIN4, CSISOLATIN5, CSISOLATIN6, CSISOLATINARABIC, CSISOLATINCYRILLIC, CSISOLATINGREEK, CSISOLATINHEBREW, CSKOI
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
On 30/9/03 7:45 pm, "Adam H. Pendleton" <[EMAIL PROTECTED]> wrote: > On Tuesday, Sep 30, 2003, at 08:58 US/Eastern, Adam Witney wrote: > >> >> Actually latest CVS wxWindows, configure'd --with-cocoa fails with this >> problem >> >> ../src/cocoa/font.cpp:88: type specifier omitted for parameter ` >>wxNativeEncodingInfo' >> ../src/cocoa/font.cpp:88: parse error before `*' token >> make: *** [corelib_font.o] Error 1 >> > > For now, I think we should probably just stick with the wxMac stuff. > From what I understand, the wxCocoa code isn't as mature as the wxMac > code. Let's tackle on problem at a time. :-) Ok, it also fails with ../configure --with-mac --disable-shared --enable-debug ../src/mac/checkbox.cpp: In member function `bool wxCheckBox::Create(wxWindow*, int, const wxString&, const wxPoint&, const wxSize&, long int, const wxValidator&, const wxString&)': ../src/mac/checkbox.cpp:45: `wxCH_3STATE' undeclared (first use this function) ../src/mac/checkbox.cpp:45: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [corelib_checkbox.o] Error 1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-hackers]
Le Mardi 30 Septembre 2003 17:23, Ângelo Marcos Rigo a écrit : > A Portuguese-Brazilian PgAdmin user describe me a > problem with acentt code, the data on the database > wich have acentt is not displayed properly in PgAdmin > III but do appear properly in PgAdmin II. Hi Ângelo, Could you: - click on the database and show properties. What is the encoding of your database: SQL_ASCII or Unicode or anything else? - send me privately an attached file including the definition of the table with one row of data. You can use pg_dump --table=TABLE to dump a table. I will test display here. Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS are you running? Cheers, Jean-Michel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] [HACKERS] GPL code issue?
"Dave Page" <[EMAIL PROTECTED]> writes: > In src/backend/parser/parse.h there is a copyright that reads as below. > Note the bottom section that says that the GPL is only excepted for > files generated by Bison *from* this file. This implies to me that this > file is GPL'd, No. The text in question is copied verbatim from some Bison component file that supplies a lot of fixed boilerplate for Bison output files. It's not very well phrased, perhaps, but their intent is clearly to exempt Bison output files from the GPL, and this *is* a Bison output file. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[pgadmin-hackers] make install icons and desktop files
Dear Adam H.,
In the RPM spec, after make install, we install the icon and desktop file
manually using:
cp ./src/include/images/elephant48.xpm
%{buildroot}/%{_datadir}/%{name}/%{name}.xpm
cp ./pkg/%{name}.desktop
%{buildroot}/%{_datadir}/%{name}/%{name}.desktop
Could it be part of make install itself?
Cheers, Jean-Michel
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] PgAdmin III on OSX (was Re: [ANNOUNCE] pgAdmin
Adam Witney wrote: For the time being, I could live with 1), but I couldn't get it to configure on my OSX laptop... It couldn't find my pgsql installation... Even though it was looking in the right place! does pgsql have to be compiled with ssl for pgadmin to work? No, not necessarily. If SSL is not defined, you can go unencrypted. If you compile for SSL, but SSL isn't present in libpq, a single unresolved reference PQgetssl should show up. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] wxWindows lib name changes
Adam H.Pendleton wrote: I just grabbed the CVS tree for wxWindows, and I noticed that the library naming convention seems to have changed. Where it used to be -lwx_macd-2.5 it is now -lwx_macd_core-2.5, etc. This causes the autoconf code to fail, since it is looking for "wx_macd-" not "wx_macd_". Can anyone else confirm that this change takes place on other platforms (I realize we don't use the CVS tree for our builds, but it may be necessary for Mac support). There's a new --enable-monolithic switch for wx to compile the lib the old way. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] Mac Port
Jean-Michel POURE wrote: Le Mercredi 1 Octobre 2003 00:43, Adam H.Pendleton a écrit : http://www.fmonkey.net/pgastartup.jpg I don't remember now how I fixed this before, so I'll have to do some research. Stefan, maybe you have a quick answer (if there is such a thing)? :-) I think the hotfix was putting the line "Language=0" into ~/.pgadmin3 to skip the language selection dialog. Dear Adam H. Pendleton, Nice Macintosh. Is this a new platform? How wide is your screen? Sorry for the late reply because of the jet lag :) The language list is displayed in UTF-8 because our translations are stored in Unicode. wxMac does not support Unicode and hence fails to display some languages. If you compile pgAdmin3 without Unicode, you should be able to view pgAdmin3 English interface. Most European languages should display (with accent problems). Because Unicode is based on ASCII characters, it should not break pgAdmin logic. Could Andreas confirm? Yes, Latin1 should display ok, and other chars shouldn't break pgAdmin3 either. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Czech translation of pgAdmin III
Le Lundi 29 Septembre 2003 15:04, Jean-Michel POURE a écrit : > > I am sending you Czech translation (cs_CZ) of pgAdmin III. All strings > > are translated, but need some work on terminology and "hot keys". While waiting for Jan answer, the maintenance of the Czech translation was handed to Daniel. Cheers, Jean-Michel ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[pgadmin-hackers] Build error under SuSE 8.2
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include -I../src/agent/include -I -DSSL -I/usr/include/pgsql -I/usr/lib/wx/include/gtk2ud-2.5 -D__WXDEBUG__ -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/include -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include -I../src/agent/include -I -Wall -g -O0 -MT pgaStep.o -MD -MP -MF ".deps/pgaStep.Tpo" \ -c -o pgaStep.o `test -f 'agent/pgaStep.cpp' || echo './'`agent/pgaStep.cpp; \ then mv ".deps/pgaStep.Tpo" ".deps/pgaStep.Po"; \ else rm -f ".deps/pgaStep.Tpo"; exit 1; \ fi agent/pgaStep.cpp: In static member function `static pgObject* pgaStep::ReadObjects(pgaJob*, wxTreeCtrl*, const wxString&)': agent/pgaStep.cpp:100: error: ISO C++ says that `wxChar wxString::operator[](int) const' and `wxChar& wxString::operator[](unsigned int)' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter agent/pgaStep.cpp:110: error: ISO C++ says that `wxChar wxString::operator[](int) const' and `wxChar& wxString::operator[](unsigned int)' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter make[2]: *** [pgaStep.o] Error 1 make[2]: Leaving directory `/usr/src/packages/BUILD/pgadmin3-1.0.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/pgadmin3-1.0.1' make: *** [all] Error 2 Cheers, Jean-Michel ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[pgadmin-hackers] MacOsX port with Unicode
Dear friends, Herafter is the answer of Stefan Csomor to the iconv question: "The problem is not the conversion, since that is already existing on mac os, it is rather the wide char functions and headers which have to be emulated, or rewritten using MacOS Unicode functions. It should not be too difficult, but it would take some time..." Best regards, Jean-Michel ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Hi Adam please cvs update src/mac/checkbox.cpp, I've committed the typo fix yesterday evening Thanks, Stefan > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Witney > Sent: Mittwoch, 1. Oktober 2003 10:05 > To: Adam H. Pendleton > Cc: [EMAIL PROTECTED]; pgadmin-hackers > Subject: Re: [pgadmin-hackers] pgAdmin III under wxCocoa > > On 30/9/03 7:45 pm, "Adam H. Pendleton" <[EMAIL PROTECTED]> wrote: > > > On Tuesday, Sep 30, 2003, at 08:58 US/Eastern, Adam Witney wrote: > > > >> > >> Actually latest CVS wxWindows, configure'd --with-cocoa fails with > >> this problem > >> > >> ../src/cocoa/font.cpp:88: type specifier omitted for parameter ` > >>wxNativeEncodingInfo' > >> ../src/cocoa/font.cpp:88: parse error before `*' token > >> make: *** [corelib_font.o] Error 1 > >> > > > > For now, I think we should probably just stick with the wxMac stuff. > > From what I understand, the wxCocoa code isn't as mature as > the wxMac > > code. Let's tackle on problem at a time. :-) > > Ok, it also fails with ../configure --with-mac > --disable-shared --enable-debug > > ../src/mac/checkbox.cpp: In member function `bool > wxCheckBox::Create(wxWindow*, >int, const wxString&, const wxPoint&, const wxSize&, long > int, const >wxValidator&, const wxString&)': > ../src/mac/checkbox.cpp:45: `wxCH_3STATE' undeclared (first use this > function) > ../src/mac/checkbox.cpp:45: (Each undeclared identifier is > reported only once >for each function it appears in.) > make: *** [corelib_checkbox.o] Error 1 > > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > > ---(end of > broadcast)--- > TIP 8: explain analyze is your friend > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] Build error under SuSE 8.2
> -Original Message- > From: Jean-Michel POURE [mailto:[EMAIL PROTECTED] > Sent: 01 October 2003 13:07 > To: [EMAIL PROTECTED] > Subject: [pgadmin-hackers] Build error under SuSE 8.2 > > > if g++ -DHAVE_CONFIG_H -I. -I. -I.. > -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall > -g -I../src/include -I../src/agent/include -I -DSSL > -I/usr/include/pgsql > -I/usr/lib/wx/include/gtk2ud-2.5 -D__WXDEBUG__ -D__WXGTK__ > -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/include > -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include > -I../src/agent/include -I -Wall -g -O0 -MT pgaStep.o -MD -MP -MF > ".deps/pgaStep.Tpo" \ > -c -o pgaStep.o `test -f 'agent/pgaStep.cpp' || echo > './'`agent/pgaStep.cpp; > \ > then mv ".deps/pgaStep.Tpo" ".deps/pgaStep.Po"; \ > else rm -f ".deps/pgaStep.Tpo"; exit 1; \ > fi > agent/pgaStep.cpp: In static member function `static pgObject* >pgaStep::ReadObjects(pgaJob*, wxTreeCtrl*, const wxString&)': > agent/pgaStep.cpp:100: error: ISO C++ says that `wxChar >wxString::operator[](int) const' and `wxChar& > wxString::operator[](unsigned >int)' are ambiguous even though the worst conversion for > the former is >better than the worst conversion for the latter > agent/pgaStep.cpp:110: error: ISO C++ says that `wxChar >wxString::operator[](int) const' and `wxChar& > wxString::operator[](unsigned >int)' are ambiguous even though the worst conversion for > the former is >better than the worst conversion for the latter > make[2]: *** [pgaStep.o] Error 1 > make[2]: Leaving directory > `/usr/src/packages/BUILD/pgadmin3-1.0.1/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/src/packages/BUILD/pgadmin3-1.0.1' > make: *** [all] Error 2 Something wrong with your CVS repository? Those files (agent/*) are not in the 1.0.1 branch which you seem to be compiling. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[pgadmin-hackers] utffile.cpp & expatd.lib
Hi Andreas, I've just found myself unable to compile CVS because of problems with utffile.h/cpp and expatd.cpp. Having temporarily removed them I can carry on, but have you upgraded wx and added expat for some reason? Regards, Dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[pgadmin-hackers] Translation updates
Dear all, Where should we commit translation updates? REL-1_0_0_PATCHES or the main branch? To simplify, I would prefer the main branch only. Same as for translation status. What do you prefer? Cheers, Jean-Michel ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
Dave Page wrote: Hi Andreas, I've just found myself unable to compile CVS because of problems with utffile.h/cpp and expatd.cpp. Having temporarily removed them I can carry on, but have you upgraded wx and added expat for some reason? utffile is in our cvs, while expatd.cpp isn't in my wx cvs snapshot either; it compiles anyway. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 01 October 2003 14:52
> To: Dave Page
> Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] utffile.cpp & expatd.lib
>
>
> Dave Page wrote:
>
> >Hi Andreas,
> >
> >I've just found myself unable to compile CVS because of
> problems with
> >utffile.h/cpp and expatd.cpp. Having temporarily removed them I can
> >carry on, but have you upgraded wx and added expat for some reason?
> >
>
> utffile is in our cvs,
Yes I know, but it won't compile (see below)
> while expatd.cpp isn't in my wx cvs snapshot
> either; it compiles anyway.
It's trying to link with expatd.lib which I do not have on Windows.
iirc, xrc uses a cut down version of expat, or must add a full version
to the list of prereqs?
Regards, Dave
Compiling...
utffile.cpp
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(21) : error C2629:
unexpected 'class wxUtfFile ('
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(21) : error C2238:
unexpected token(s) preceding ';'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(22) : error C2629:
unexpected 'class wxUtfFile ('
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(22) : error C2238:
unexpected token(s) preceding ';'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(24) : error C2061: syntax
error : identifier 'wxFontEncoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(25) : error C2061: syntax
error : identifier 'wxFontEncoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(26) : error C2061: syntax
error : identifier 'wxFontEncoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(39) : error C2061: syntax
error : identifier 'wxFontEncoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(40) : error C2061: syntax
error : identifier 'wxFontEncoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(43) : error C2146: syntax
error : missing ';' before identifier 'm_encoding'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(43) : error C2501:
'wxFontEncoding' : missing storage-class or type specifiers
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\include\utffile.h(43) : error C2501:
'm_encoding' : missing storage-class or type specifiers
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\utils\utffile.cpp(13) : error C2146: syntax
error : missing ';' before identifier 'wxConvUTF16BE'
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\utils\utffile.cpp(13) : error C2501:
'wxMBConvUTF16BE' : missing storage-class or type specifiers
c:\documents and settings\dpage\my
documents\cvs\pgadmin3\src\utils\utffile.cpp(13) : fatal error C1004:
unexpected end of file found
Error executing cl.exe.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgadmin-hackers] Translation updates
> -Original Message- > From: Jean-Michel POURE [mailto:[EMAIL PROTECTED] > Sent: 01 October 2003 14:50 > To: pgadmin-hackers > Subject: [pgadmin-hackers] Translation updates > > > Dear all, > > Where should we commit translation updates? REL-1_0_0_PATCHES > or the main > branch? To simplify, I would prefer the main branch only. Same as for > translation status. Definately main branch for the status pages etc - they can just stay as they are. Ongoing translations will begin to change though as we add & rewrite code, so unless they are translations against the old po files, then they should go on the main branch. Of course, that's a bit fruitless this early in the dev cycle, so the translators should probably enjoy some downtime for a while (or translate the website in cases of extreme boredom)! Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Hi Stefan, Thanks. This now compiles and installs fine with wxWindows current CVS (on MacOSX 10.2.6) cd build ../configure --with-mac --disable-shared --enable-debug make make install Do I need the STC and XRC bits as well? These do not compile as described on the website instructions cd contrib/src/stc make make: *** No targets specified and no makefile found. Stop. Thanks again adam > Hi Adam > > please cvs update src/mac/checkbox.cpp, I've committed the typo fix > yesterday evening > > Thanks, > > Stefan >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Adam Witney >> Sent: Mittwoch, 1. Oktober 2003 10:05 >> To: Adam H. Pendleton >> Cc: [EMAIL PROTECTED]; pgadmin-hackers >> Subject: Re: [pgadmin-hackers] pgAdmin III under wxCocoa >> >> On 30/9/03 7:45 pm, "Adam H. Pendleton" <[EMAIL PROTECTED]> wrote: >> >>> On Tuesday, Sep 30, 2003, at 08:58 US/Eastern, Adam Witney wrote: >>> Actually latest CVS wxWindows, configure'd --with-cocoa fails with this problem ../src/cocoa/font.cpp:88: type specifier omitted for parameter ` wxNativeEncodingInfo' ../src/cocoa/font.cpp:88: parse error before `*' token make: *** [corelib_font.o] Error 1 >>> >>> For now, I think we should probably just stick with the wxMac stuff. >>> From what I understand, the wxCocoa code isn't as mature as >> the wxMac >>> code. Let's tackle on problem at a time. :-) >> >> Ok, it also fails with ../configure --with-mac >> --disable-shared --enable-debug >> >> ../src/mac/checkbox.cpp: In member function `bool >> wxCheckBox::Create(wxWindow*, >>int, const wxString&, const wxPoint&, const wxSize&, long >> int, const >>wxValidator&, const wxString&)': >> ../src/mac/checkbox.cpp:45: `wxCH_3STATE' undeclared (first use this >> function) >> ../src/mac/checkbox.cpp:45: (Each undeclared identifier is >> reported only once >>for each function it appears in.) >> make: *** [corelib_checkbox.o] Error 1 >> >> >> -- >> This message has been scanned for viruses and dangerous >> content by MailScanner, and is believed to be clean. >> >> >> ---(end of >> broadcast)--- >> TIP 8: explain analyze is your friend >> > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] Mac Port
Stefan Csomor wrote: Hi most probably you did not link the resources to the project, did you adapt the makefiles ? you can have a look at the minimal makefile that gets generated by configure in your mac builddir. That's what the problem is. I'd forgotten about that. Thanks! ahp ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Dave Page wrote: Dynamic build works, static does not. Incidently, --disable-static doesn't work, despite prompts indicating that it should. I also note that snake is linking with libwx_gtk2ud-2.5.a no matter what build type is performed - I assume this is because that's what wx-config tells it to do? Most likely. The output from 'wx-config --libs' and 'wx-config --libs --static' seem the same, and seems to be dependent on the wxWindows build. ahp ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] Mac Port
Jean-Michel POURE wrote: Nice Macintosh. Is this a new platform? How wide is your screen? Sorry for the late reply because of the jet lag :) It's a PowerBook G4 15" running Mac OS X 10.2.6. The language list is displayed in UTF-8 because our translations are stored in Unicode. wxMac does not support Unicode and hence fails to display some languages. If you compile pgAdmin3 without Unicode, you should be able to view pgAdmin3 English interface. Most European languages should display (with accent problems). Because Unicode is based on ASCII characters, it should not break pgAdmin logic. Could Andreas confirm? The problem isn't the language display, per se, but rather that I can't click on the dialog, there is no dock icon, etc. It's because I forgot to link against the Mac resource files. I will work on it some more tonight. ahp ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Adam Witney wrote: On 30/9/03 7:45 pm, "Adam H. Pendleton" <[EMAIL PROTECTED]> wrote: On Tuesday, Sep 30, 2003, at 08:58 US/Eastern, Adam Witney wrote: Actually latest CVS wxWindows, configure'd --with-cocoa fails with this problem ../src/cocoa/font.cpp:88: type specifier omitted for parameter ` wxNativeEncodingInfo' ../src/cocoa/font.cpp:88: parse error before `*' token make: *** [corelib_font.o] Error 1 For now, I think we should probably just stick with the wxMac stuff. From what I understand, the wxCocoa code isn't as mature as the wxMac code. Let's tackle on problem at a time. :-) Ok, it also fails with ../configure --with-mac --disable-shared --enable-debug ../src/mac/checkbox.cpp: In member function `bool wxCheckBox::Create(wxWindow*, int, const wxString&, const wxPoint&, const wxSize&, long int, const wxValidator&, const wxString&)': ../src/mac/checkbox.cpp:45: `wxCH_3STATE' undeclared (first use this function) ../src/mac/checkbox.cpp:45: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [corelib_checkbox.o] Error 1 Are you sure you're working with the latest CVS tree? It compiled fine for me. ahp ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers] make install icons and desktop files
Jean-Michel POURE wrote:
Dear Adam H.,
In the RPM spec, after make install, we install the icon and desktop file
manually using:
cp ./src/include/images/elephant48.xpm
%{buildroot}/%{_datadir}/%{name}/%{name}.xpm
cp ./pkg/%{name}.desktop
%{buildroot}/%{_datadir}/%{name}/%{name}.desktop
Could it be part of make install itself?
Yes. I've have to get back to you on specifically how, though. :-)
ahp
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
Dave Page wrote: while expatd.cpp isn't in my wx cvs snapshot either; it compiles anyway. It's trying to link with expatd.lib which I do not have on Windows. iirc, xrc uses a cut down version of expat, or must add a full version to the list of prereqs? Ah I see, I'm preparing for the next wx snapshot, and that includes expat as an additional partial project (moved from xrc to main). While I'll be posting many fixes to wx in the next time, mainly for font inheritance from dialog to control, the latest snapshot wx is workable under win32 and gtk. When I'm done, I'll announce this together with a patch file. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
> -Original Message- > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > Sent: 01 October 2003 16:20 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] utffile.cpp & expatd.lib > > > > I'm preparing for the next wx snapshot, and that includes expat as an > additional partial project (moved from xrc to main). > While I'll be posting many fixes to wx in the next time, > mainly for font > inheritance from dialog to control, the latest snapshot wx is > workable > under win32 and gtk. When I'm done, I'll announce this > together with a > patch file. OK. Can we keep CVS in a working state though please - I'm currently on a 2 week break from Uni and am/was spending my normal homework/assignment time fixing up the Query Builder and trying to do a bunch of other stuff. Unfortunately I'm now having to hack around a number of these changes just to get a working compile again. :-( BTW, it looks like I will have a 6-7 week break from Uni over Christmas this year (due to a new timetable that delays the start of one of my modules), so should finally be able to put in a good stint of coding again! Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[pgadmin-hackers] client encoding SQL_ASCII for server SQL_ASCII
Should that be back patched for 1.0.1? Seems like a bug to me. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers] client encoding SQL_ASCII for server SQL_ASCII
Dave Page wrote: Should that be back patched for 1.0.1? Seems like a bug to me. The bug is the non-ascii data... Yes, we should back-patch that. Just plain pgConn.cpp and pgConn.hpp. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 01 October 2003 16:20 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] utffile.cpp & expatd.lib I'm preparing for the next wx snapshot, and that includes expat as an additional partial project (moved from xrc to main). While I'll be posting many fixes to wx in the next time, mainly for font inheritance from dialog to control, the latest snapshot wx is workable under win32 and gtk. When I'm done, I'll announce this together with a patch file. OK. Can we keep CVS in a working state though please - I'm currently on a 2 week break from Uni and am/was spending my normal homework/assignment time fixing up the Query Builder and trying to do a bunch of other stuff. Unfortunately I'm now having to hack around a number of these changes just to get a working compile again. :-( Sorry for that, taking this huge wx step was expected to stirr things up. Use the current wx snapshot (maybe pinned to 2003-10-01), it should work smoothly. Seems that most of our devteam members are already using wx cvs head anyway (at least for non-win32 development). Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
> -Original Message- > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > Sent: 01 October 2003 16:39 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] utffile.cpp & expatd.lib > > > > Sorry for that, taking this huge wx step was expected to > stirr things up. Use the current wx snapshot (maybe pinned to > 2003-10-01), it should work > smoothly. Seems that most of our devteam members are already using wx > cvs head anyway (at least for non-win32 development). OK, I'll download it. Of course, makes it a pain to do (and test) 1.0.1 Would appreciate a heads-up before any more major changes though please :-) Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers]
Hi, I think I have a similar issue... A pgAdmin III user contacted me with the question why they can't see the data in Russian and how to to solve the problem. I queried them for more information. I think their data must be encoded in some other encoding (e.g. KOI8-R) and when it gets to the client side, it's not converted. Any other hints aside from below what to try? -s On Wed, 1 Oct 2003, Jean-Michel POURE wrote: > Le Mardi 30 Septembre 2003 17:23, Ãngelo Marcos Rigo a écrit : > > A Portuguese-Brazilian PgAdmin user describe me a > > problem with acentt code, the data on the database > > wich have acentt is not displayed properly in PgAdmin > > III but do appear properly in PgAdmin II. > > Hi Ãngelo, > > Could you: > - click on the database and show properties. What is the encoding of your > database: SQL_ASCII or Unicode or anything else? > > - send me privately an attached file including the definition of the table > with one row of data. You can use pg_dump --table=TABLE to dump a table. I > will test display here. > > Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS > are you running? > > Cheers, Jean-Michel -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! "I swear, education is the only industry, where the consumer is happier when they get less for their money" -- Julia Timofeev ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] client encoding SQL_ASCII for server SQL_ASCII
Hmm.. From: "Andreas Pflug" <[EMAIL PROTECTED]> > Dave Page wrote: > > >Should that be back patched for 1.0.1? Seems like a bug to me. > > > > > > > > The bug is the non-ascii data... > Yes, we should back-patch that. Just plain pgConn.cpp and pgConn.hpp. > > Regards, > Andreas Please wait a little. Is this taken into consideration? saito=# \l List of databases Name| Owner | Encoding +---+--- pgdata | saito | UNICODE regression | saito | EUC_JP saito | saito | EUC_JP template0 | saito | EUC_JP template1 | saito | EUC_JP with | saito | SQL_ASCII (6 rows) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers]
Dear Serguei. It is strange. Server has encoding as follows. -- UNICODE --> KOI8R CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_koi8_r FOR 'UNICODE' TO 'KOI8R' FR OM utf8_to_koi8r; -- KOI8R --> UNICODE CREATE DEFAULT CONVERSION pg_catalog.koi8_r_to_utf_8 FOR 'KOI8R' TO 'UNICODE' FR OM koi8r_to_utf8; Please Try psql command. \l <-- list all databases regards Hiroshi Saito - Original Message - From: "Serguei A. Mokhov" <[EMAIL PROTECTED]> > Hi, > > I think I have a similar issue... A pgAdmin III user contacted me with the > question why they can't see the data in Russian and how to to solve the > problem. I queried them for more information. I think their data must be > encoded in some other encoding (e.g. KOI8-R) and when it gets to the > client side, it's not converted. > > Any other hints aside from below what to try? > > -s > > On Wed, 1 Oct 2003, Jean-Michel POURE wrote: > > > Le Mardi 30 Septembre 2003 17:23, Ã,ngelo Marcos Rigo a écrit : > > > A Portuguese-Brazilian PgAdmin user describe me a > > > problem with acentt code, the data on the database > > > wich have acentt is not displayed properly in PgAdmin > > > III but do appear properly in PgAdmin II. > > > > Hi Ã,ngelo, > > > > Could you: > > - click on the database and show properties. What is the encoding of your > > database: SQL_ASCII or Unicode or anything else? > > > > - send me privately an attached file including the definition of the table > > with one row of data. You can use pg_dump --table=TABLE to dump a table. I > > will test display here. > > > > Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS > > are you running? > > > > Cheers, Jean-Michel > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers]
Serguei A. Mokhov wrote: Hi, I think I have a similar issue... A pgAdmin III user contacted me with the question why they can't see the data in Russian and how to to solve the problem. I queried them for more information. I think their data must be encoded in some other encoding (e.g. KOI8-R) and when it gets to the client side, it's not converted. This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded database will not be shown because the server doesn't know how to encode it in Unicode. This is fixed for HEAD and BRANCH. Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers]
From: "Andreas Pflug" <[EMAIL PROTECTED]> > Serguei A. Mokhov wrote: > > >Hi, > > > >I think I have a similar issue... A pgAdmin III user contacted me with the > >question why they can't see the data in Russian and how to to solve the > >problem. I queried them for more information. I think their data must be > >encoded in some other encoding (e.g. KOI8-R) and when it gets to the > >client side, it's not converted. > > > > > This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded > database will not be shown because the server doesn't know how to encode > it in Unicode. > > This is fixed for HEAD and BRANCH. No. Server encoding as below. -- SQL_ASCII --> UNICODE CREATE DEFAULT CONVERSION pg_catalog.ascii_to_utf_8 FOR 'SQL_ASCII' TO 'UNICODE' FROM ascii_to_utf8; -- UNICODE --> SQL_ASCII CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_ascii FOR 'UNICODE' TO 'SQL_ASCII' FROM utf8_to_ascii; regards, Hiroshi Saito ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers]
On Thu, 2 Oct 2003, Hiroshi Saito wrote: > From: "Andreas Pflug" <[EMAIL PROTECTED]> > > > Serguei A. Mokhov wrote: > > > > >Hi, > > > > > >I think I have a similar issue... A pgAdmin III user contacted me > > >with the question why they can't see the data in Russian and how to > > >to solve the problem. I queried them for more information. I think > > >their data must be encoded in some other encoding (e.g. KOI8-R) and > > >when it gets to the client side, it's not converted. > > > > > > > > This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded > > database will not be shown because the server doesn't know how to > > encode it in Unicode. > > > > This is fixed for HEAD and BRANCH. > > No. > Server encoding as below. > -- SQL_ASCII --> UNICODE > CREATE DEFAULT CONVERSION pg_catalog.ascii_to_utf_8 FOR 'SQL_ASCII' TO 'UNICODE' > FROM ascii_to_utf8; > -- UNICODE --> SQL_ASCII > CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_ascii FOR 'UNICODE' TO 'SQL_ASCII' > FROM utf8_to_ascii; Yes, I know about existance of this conversion (as well as about the KOI8-R one). It's been there for ages... I'll report back once the user gets back to me on that. I'm not sure though whether they'd be willing to pull the stuff from the CVS and compile it -- even you guys recommend to use the binaries... ;) > regards, > Hiroshi Saito -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! "I swear, education is the only industry, where the consumer is happier when they get less for their money" -- Julia Timofeev ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] client encoding SQL_ASCII for server SQL_ASCII
There is no error in every place. But, there is one place of the problem. It is a quote problem by the renewal of data view. regards, Hiroshi Saito - Original Message - From: "Hiroshi Saito" <[EMAIL PROTECTED]> > Hmm.. > > From: "Andreas Pflug" <[EMAIL PROTECTED]> > > > > Dave Page wrote: > > > > >Should that be back patched for 1.0.1? Seems like a bug to me. > > > > > > > > > > > > > The bug is the non-ascii data... > > Yes, we should back-patch that. Just plain pgConn.cpp and pgConn.hpp. > > > > Regards, > > Andreas > > Please wait a little. > Is this taken into consideration? > > saito=# \l >List of databases > Name| Owner | Encoding > +---+--- > pgdata | saito | UNICODE > regression | saito | EUC_JP > saito | saito | EUC_JP > template0 | saito | EUC_JP > template1 | saito | EUC_JP > with | saito | SQL_ASCII > (6 rows) > > Regards, > Hiroshi Saito ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] client encoding SQL_ASCII for server SQL_ASCII
It is this problem. any comment? regards, Hiroshi Saito - Original Message - From: "Hiroshi Saito" <[EMAIL PROTECTED]> > > There is no error in every place. > But, there is one place of the problem. > It is a quote problem by the renewal of data view. > > regards, > Hiroshi Saito frmEditGrid_patch Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[pgadmin-hackers] MacOSX compilation steps
Dear Friends, I added information about wxWindows compilation under MacOsX on http://www.pgadmin.org/pgadmin3/download.php#source. It will take some time to replicate from snake development server. Dear Adam H.: could you describe the needed steps for pgAdmin3 compilation? Is it the same as under GNU/Linux? Cheers, Jean-Michel ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers]
Hiroshi Saito wrote: From: "Andreas Pflug" <[EMAIL PROTECTED]> Serguei A. Mokhov wrote: Hi, I think I have a similar issue... A pgAdmin III user contacted me with the question why they can't see the data in Russian and how to to solve the problem. I queried them for more information. I think their data must be encoded in some other encoding (e.g. KOI8-R) and when it gets to the client side, it's not converted. This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded database will not be shown because the server doesn't know how to encode it in Unicode. This is fixed for HEAD and BRANCH. No. Server encoding as below. This is not suitable for non-ascii chars, because the upper bit will be chopped off (ascii->utf8), effectively destroying the string, or converted to a bogus char (xx), effectively destroying the string. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers]
From: "Andreas Pflug" <[EMAIL PROTECTED]> (snip) > >>This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded > >>database will not be shown because the server doesn't know how to encode > >>it in Unicode. > >> > >>This is fixed for HEAD and BRANCH. > > > >No. > >Server encoding as below. > > > > This is not suitable for non-ascii chars, because the upper bit will be > chopped off (ascii->utf8), effectively destroying the string, or > converted to a bogus char (xx), effectively destroying the string. Hmm.. Is it a specific code or all code? However, Will you absorb all the bugs of PostgreSQL? regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers]
Hiroshi Saito wrote: Hmm.. Is it a specific code or all code? However, Will you absorb all the bugs of PostgreSQL? This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database *should* contain only 7bit ascii characters. If you use 8-bit characters, conversion is unpredictable (well, it *is* predictable, but probably not what you'd like to see) Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers]
Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit : > This is not a bug of PostgreSQL, nor of pgAdmin. > SQL_ASCII database *should* contain only 7bit ascii characters. If you > use 8-bit characters, conversion is unpredictable (well, it *is* > predictable, but probably not what you'd like to see) IMHO, SQL_ASCII database contain more than 7bit characters. I used it several times to store Frenc accentuated text and it worked like a charm. The name "ASCII" may not be well chosen. It contains more than ASCII presently. Cheers, Jean-Michel ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Adam Witney wrote: With ./configure --enable-debug I get checking for wxWindows... yes configure: error: you need to install the xrc package from wxWindows/contrib/src/xrc Which is strange as xrc seemed to install fine before What does config.log report? If I use pgadmin3 CVS I have to edit configure.ac to change AC_CONFIG_HEADER([config.h]) to AM_CONFIG_HEADER([config.h]) Otherwise the bootstrap script will fail. What version of autoconf and automake are you using? Sounds like you need to upgrade. And then ./configure --enable-debug works but compilation fails with utils/utffile.cpp: In member function `off_t wxUtfFile::Read(wxString&, long long int)': utils/utffile.cpp:85: no matching function for call to `wxMBConv::MB2WC( wxStringBuffer, char*&, long unsigned int)' /usr/local/include/wx/strconv.h:46: candidates are: virtual size_t wxMBConv::MB2WC(wchar_t*, const char*, long unsigned int) const make[2]: *** [utffile.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 This looks like a separate issue. ahp
Re: [pgadmin-hackers] MacOSX compilation steps
Jean-Michel POURE wrote: Dear Friends, I added information about wxWindows compilation under MacOsX on http://www.pgadmin.org/pgadmin3/download.php#source. It will take some time to replicate from snake development server. Dear Adam H.: could you describe the needed steps for pgAdmin3 compilation? Is it the same as under GNU/Linux? Cheers, Jean-Michel I will post my steps for compiling wxWindows and pgAdmin3 to the list tonight. It is very similar to Linux, but not quite the same. There is, at a minumum, one additional step required. ahp ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
> Hmmm. I just downloaded and './configure'd pgAdmin3 on my system, and
> it doesn't even link against libcrypt. This is because only the static
> version of pgAdmin3 links against libcrypt. IIRC, this dependency was
> added to the build system to support Slackware. Dave, could you change
> line 114 from:
>
> LIBS="${LIBPQ_HOME}/lib/libpq.a -lcrypt $LIBS -lssl -lcrypto"
>
> to:
>
> LIBS="${LIBPQ_HOME}/lib/libpq.a $LIBS -lssl -lcrypto"
>
> and let me know what happens. Could you test this as well Jean-Michel?
> Make sure you configure with --disable-shared. Adam W., go ahead and
> compile pgAdmin3 without the --disable-shared flag for now, and let me
> know what happens.
With ./configure --enable-debug I get
checking for wxWindows... yes
configure: error: you need to install the xrc package from
wxWindows/contrib/src/xrc
Which is strange as xrc seemed to install fine before
Incidently this is from pgadmin3-1.0.0
If I use pgadmin3 CVS I have to edit configure.ac to change
AC_CONFIG_HEADER([config.h])
to
AM_CONFIG_HEADER([config.h])
Otherwise the bootstrap script will fail. And then ./configure
--enable-debug works but compilation fails with
utils/utffile.cpp: In member function `off_t wxUtfFile::Read(wxString&, long
long int)':
utils/utffile.cpp:85: no matching function for call to `wxMBConv::MB2WC(
wxStringBuffer, char*&, long unsigned int)'
/usr/local/include/wx/strconv.h:46: candidates are: virtual size_t
wxMBConv::MB2WC(wchar_t*, const char*, long unsigned int) const
make[2]: *** [utffile.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Thanks
adam
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [pgadmin-hackers]
Jean-Michel POURE wrote: Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit : This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database *should* contain only 7bit ascii characters. If you use 8-bit characters, conversion is unpredictable (well, it *is* predictable, but probably not what you'd like to see) IMHO, SQL_ASCII database contain more than 7bit characters. I used it several times to store Frenc accentuated text and it worked like a charm. The name "ASCII" may not be well chosen. It contains more than ASCII presently. It's no problem storing non-UTF characters in an UNICODE database either, you will never notice until you try to convert. Misusing the database is not a good idea on the long run. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers]
From: "Andreas Pflug" <[EMAIL PROTECTED]> > Hiroshi Saito wrote: > > >Hmm.. > >Is it a specific code or all code? > >However, > >Will you absorb all the bugs of PostgreSQL? > > > > > > This is not a bug of PostgreSQL, nor of pgAdmin. > SQL_ASCII database *should* contain only 7bit ascii characters. If you > use 8-bit characters, conversion is unpredictable (well, it *is* > predictable, but probably not what you'd like to see) It isn't understood. Shouldn't put it in SQL_ASCII. Database comes to return the result which made a mistake. Or, do you use 256(2^8=256) ASCII? regards, Hiroshi Saito ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers]
On Wed, 1 Oct 2003, Jean-Michel POURE wrote: > Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit : > > This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database > > *should* contain only 7bit ascii characters. If you use 8-bit > > characters, conversion is unpredictable (well, it *is* predictable, > > but probably not what you'd like to see) > > IMHO, SQL_ASCII database contain more than 7bit characters. I used it > several times to store Frenc accentuated text and it worked like a > charm. The name "ASCII" may not be well chosen. It contains more than > ASCII presently. Indeed, no one has forbidden extended-ASCII chars :) Though these would be interpreted differntly. My 256 char ASCII table is different from yours presentation-wise. But you can't control it uniformly unless you explicitly tell how to enterpret. I wanna see my Cyrillic chars and not the diacritics of Latin chars, for example. An Indian friedn of mind would like to see their Hindi chars there instead, so... You are lucky because your accented chars are the deault representation. There could potentially be a need to tell the UI which ASCII it is, not sure how it is. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! "I swear, education is the only industry, where the consumer is happier when they get less for their money" -- Julia Timofeev ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Adam H. Pendleton wrote: Adam Witney wrote: With ./configure --enable-debug I get checking for wxWindows... yes configure: error: you need to install the xrc package from wxWindows/contrib/src/xrc Which is strange as xrc seemed to install fine before What does config.log report? If I use pgadmin3 CVS I have to edit configure.ac to change AC_CONFIG_HEADER([config.h]) to AM_CONFIG_HEADER([config.h]) Otherwise the bootstrap script will fail. What version of autoconf and automake are you using? Sounds like you need to upgrade. And then ./configure --enable-debug works but compilation fails with utils/utffile.cpp: In member function `off_t wxUtfFile::Read(wxString&, long long int)': utils/utffile.cpp:85: no matching function for call to `wxMBConv::MB2WC( wxStringBuffer, char*&, long unsigned int)' /usr/local/include/wx/strconv.h:46: candidates are: virtual size_t wxMBConv::MB2WC(wchar_t*, const char*, long unsigned int) const Strange behaviour, try casting m_conversion->MB2WC((wxChar*)wxStringBuffer(str, len), buffer, nLen+1); ^ Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers]
Le Mercredi 1 Octobre 2003 20:21, Andreas Pflug a écrit : > It's no problem storing non-UTF characters in an UNICODE database > either, you will never notice until you try to convert. > Misusing the database is not a good idea on the long run. Agreed, trash my last e-mail. Cheers, Jean-Michel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers]
Hiroshi Saito wrote: From: "Andreas Pflug" <[EMAIL PROTECTED]> Hiroshi Saito wrote: Hmm.. Is it a specific code or all code? However, Will you absorb all the bugs of PostgreSQL? This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database *should* contain only 7bit ascii characters. If you use 8-bit characters, conversion is unpredictable (well, it *is* predictable, but probably not what you'd like to see) It isn't understood. Shouldn't put it in SQL_ASCII. Database comes to return the result which made a mistake. Or, do you use 256(2^8=256) ASCII? The DB will store 8 bit per character, regardless of the db encoding. When it comes to conversion, only 7 bits are valid, if you tell the backend "this is ASCII data". Your fault, if it actually isn't. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers]
Serguei A. Mokhov wrote: Indeed, no one has forbidden extended-ASCII chars :) Though these would be interpreted differntly. My 256 char ASCII table is different from yours presentation-wise. But you can't control it uniformly unless you explicitly tell how to enterpret. I wanna see my Cyrillic chars and not the diacritics of Latin chars, for example. An Indian friedn of mind would like to see their Hindi chars there instead, so... You are lucky because your accented chars are the deault representation. :-) There could potentially be a need to tell the UI which ASCII it is, not sure how it is. *NO*, we discussed this. Data encoding is unknown if SQL_ASCII is selected, so we have to leave it up to the gui to display whatever it means. Hopefully it is what the user expected (it probably will, if using the same language settings as he used when inserting the data). For other encodings, all 256 chars are well-known, so the server knows how to recode to UNICODE, and we know how to display. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] utffile.cpp & expatd.lib
Dave Page wrote: -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 01 October 2003 16:39 To: Dave Page Cc: pgadmin-hackers Subject: Re: [pgadmin-hackers] utffile.cpp & expatd.lib Sorry for that, taking this huge wx step was expected to stirr things up. Use the current wx snapshot (maybe pinned to 2003-10-01), it should work smoothly. Seems that most of our devteam members are already using wx cvs head anyway (at least for non-win32 development). OK, I'll download it. Of course, makes it a pain to do (and test) 1.0.1 If necessary, some wxCHECK_VERSION(2,5,1) could be introduced. Would appreciate a heads-up before any more major changes though please :-) OK, I should have announced a bit more clearly. I thought it was clear that a new wx snapshot is on the way. I posted several patches to wxWindows, lets see whether they are accepted in a reasonable time. If not, they will add to our patch list... :-( Regards, Andreas Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers]
From: "Andreas Pflug" <[EMAIL PROTECTED]> > Hiroshi Saito wrote: (snip) > >It isn't understood. > >Shouldn't put it in SQL_ASCII. > >Database comes to return the result which made a mistake. > >Or, do you use 256(2^8=256) ASCII? > > > > The DB will store 8 bit per character, regardless of the db encoding. > When it comes to conversion, only 7 bits are valid, if you tell the > backend "this is ASCII data". Your fault, if it actually isn't. However, WHERE of SELECT will go to look for it with 7bit for ENCODING if to be SQL_ASCII. Then, it fails. And, order by, too. Therefore, it is the case which you must not use. regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers]
Ah. Sorry. It is not multi-byte... I go for the bed.:-) regards, Hiroshi Saito From: "Hiroshi Saito" <[EMAIL PROTECTED]> > From: "Andreas Pflug" <[EMAIL PROTECTED]> > > > Hiroshi Saito wrote: > (snip) > > >It isn't understood. > > >Shouldn't put it in SQL_ASCII. > > >Database comes to return the result which made a mistake. > > >Or, do you use 256(2^8=256) ASCII? > > > > > > > The DB will store 8 bit per character, regardless of the db encoding. > > When it comes to conversion, only 7 bits are valid, if you tell the > > backend "this is ASCII data". Your fault, if it actually isn't. > > However, > WHERE of SELECT will go to look for it with 7bit for ENCODING if to be SQL_ASCII. > Then, it fails. > And, order by, too. > Therefore, it is the case which you must not use. > > regards, > Hiroshi Saito > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] pgAdmin III under wxCocoa
Actually latest CVS wxWindows, configure'd --with-cocoa fails with this problem ../src/cocoa/font.cpp:88: type specifier omitted for parameter ` wxNativeEncodingInfo' ../src/cocoa/font.cpp:88: parse error before `*' token make: *** [corelib_font.o] Error 1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] GPL code issue?
Dave Page wrote: /* A Bison parser, made by GNU Bison 1.875. */ Given that this file appears to be produced *by* Bison, and given this exception: /* As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction. This special exception was added by the Free Software Foundation in version 1.24 of Bison. */ it would appear that the file can be used without restriction. Any output from bison or flex is non-GPL, AIUI. Any input *into* bison, which is GPL'd before processing, *is* restricted. Given that bison doesn't take .h files as input, doesn't it make sense that this was produced *by* bison, and thus unrestricted? ahp ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
