From Harald.Siegmund at isotravel.com Thu Sep 5 09:11:39 2024 From: Harald.Siegmund at isotravel.com (Siegmund, Harald) Date: Mon Sep 9 03:23:45 2024 Subject: [odb-users] =?windows-1252?q?gcc_13=2E2=3A_vector=2Eixx=3A_warni?= =?windows-1252?q?ng=3A_=91i=92_may_be_used_uninitialized?= Message-ID: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> gcc 13.2 seems to be more sensitive when recognizing potentially uninitialized variables and prints a warning when inserting elements into an odb::vector. /usr/local/include/odb/vector.ixx:246:20: warning: ?i? may be used uninitialized [-Wmaybe-uninitialized] 246 | impl_.insert (i, v_.size () - n); | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ /usr/local/include/odb/vector.ixx: In static member function [?] /usr/local/include/odb/vector.ixx:236:15: note: ?i? was declared here 236 | size_type i, n; | ^ The code from vector.ixx: template template inline void vector:: insert (iterator p, I f, I l) { size_type i, n; if (_tracking ()) { i = static_cast (p.base () - v_.begin ()); n = v_.size (); } v_.insert (p.base (), f, l); if (_tracking ()) impl_.insert (i, v_.size () - n); } I can see the compiler's point: Function _tracking() could hypothetically return different results in each invocation, so IMHO the warning message is appropriate. It would be nice if you could change that piece of code to get rid of the warning. $ gcc --version gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0 $ odb --version ODB object-relational mapping (ORM) compiler for C++ 2.5.0-b.27 From boris at codesynthesis.com Mon Sep 9 07:10:36 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 9 07:09:58 2024 Subject: [odb-users] gcc 13.2: =?utf-8?Q?vector?= =?utf-8?B?Lml4eDogd2FybmluZzog4oCYaeKAmQ==?= may be used uninitialized In-Reply-To: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> Message-ID: Siegmund, Harald writes: > insert (iterator p, I f, I l) > { > size_type i, n; > if (_tracking ()) > { > i = static_cast (p.base () - v_.begin ()); > n = v_.size (); > } > > v_.insert (p.base (), f, l); > > if (_tracking ()) > impl_.insert (i, v_.size () - n); > } > > I can see the compiler's point: Function _tracking() could hypothetically > return different results in each invocation, so IMHO the warning message > is appropriate. The _tracking() function is inline so the compiler should be able to see through it. What probably causes this is a non-inline call between the two of them, which could potentially change the value _tracking() is based on. In any case, should be fixed now, thanks for the report: https://git.codesynthesis.com/cgit/odb/odb/commit/?id=54389be6199234c644b26bfdfb7333f82603bbd6 From Harald.Siegmund at isotravel.com Tue Sep 10 03:16:20 2024 From: Harald.Siegmund at isotravel.com (Siegmund, Harald) Date: Tue Sep 10 04:22:33 2024 Subject: =?Windows-1252?Q?AW:_[odb-users]_gcc_13.2:_vector.ixx:_warning:_=91i=92_m?= =?Windows-1252?Q?ay_be_used_uninitialized?= In-Reply-To: References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> Message-ID: <89b46807591f40689dfbc8d36e76bae4@isotravel.com> Thanks for the effort. The compiler is quiet now with -O0 but still complains with -O3. This is clearly a gcc issue. -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov Gesendet: Montag, 9. September 2024 13:11 An: Siegmund, Harald Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] gcc 13.2: vector.ixx: warning: ?i? may be used uninitialized EXTERNAL EMAIL: Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Siegmund, Harald writes: > insert (iterator p, I f, I l) > { > size_type i, n; > if (_tracking ()) > { > i = static_cast (p.base () - v_.begin ()); > n = v_.size (); > } > > v_.insert (p.base (), f, l); > > if (_tracking ()) > impl_.insert (i, v_.size () - n); > } > > I can see the compiler's point: Function _tracking() could > hypothetically return different results in each invocation, so IMHO > the warning message is appropriate. The _tracking() function is inline so the compiler should be able to see through it. What probably causes this is a non-inline call between the two of them, which could potentially change the value _tracking() is based on. In any case, should be fixed now, thanks for the report: https://protection.retarus.com/v1?u=https%3A%2F%2Fgit.codesynthesis.com%2Fcgit%2Fodb%2Fodb%2Fcommit%2F%3Fid%3D54389be6199234c644b26bfdfb7333f82603bbd6&c=3s0vctN&r=4OKduUWa8cgFw1PGWDBE1h&k=7s1&s=YcftIkrI6CtzzERhffgGFjcSJ9EQWtrzQEbxAFbeZ6y From boris at codesynthesis.com Tue Sep 10 04:26:06 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 10 04:25:29 2024 Subject: [odb-users] gcc 13.2: =?utf-8?Q?vector?= =?utf-8?B?Lml4eDogd2FybmluZzog4oCYaeKAmQ==?= may be used uninitialized In-Reply-To: <89b46807591f40689dfbc8d36e76bae4@isotravel.com> References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> <89b46807591f40689dfbc8d36e76bae4@isotravel.com> Message-ID: Siegmund, Harald writes: > The compiler is quiet now with -O0 but still complains with -O3. This > is clearly a gcc issue. Hm, interesting. Maybe it thinks the non-inline call may change the local variable? Can you change the first line to read: const bool t (_tracking ()); And see if that helps? From Harald.Siegmund at isotravel.com Tue Sep 10 12:33:01 2024 From: Harald.Siegmund at isotravel.com (Siegmund, Harald) Date: Wed Sep 11 04:33:02 2024 Subject: =?Windows-1252?Q?AW:_[odb-users]_gcc_13.2:_vector.ixx:_warning:_=91i=92_m?= =?Windows-1252?Q?ay_be_used_uninitialized?= In-Reply-To: References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> <89b46807591f40689dfbc8d36e76bae4@isotravel.com> Message-ID: Unfortunately the const doesn't make the warning go away. I set up a small reproducer with Compiler Explorer for playing with this issue: https://godbolt.org/z/7rhxTfqMf It seems that several things have to come together to trigger the false warning. See the comments in the code. This strongly looks like a gcc bug. Clang stays silent. -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov Gesendet: Dienstag, 10. September 2024 10:26 An: Siegmund, Harald Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] gcc 13.2: vector.ixx: warning: ?i? may be used uninitialized EXTERNAL EMAIL: Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Siegmund, Harald writes: > The compiler is quiet now with -O0 but still complains with -O3. This > is clearly a gcc issue. Hm, interesting. Maybe it thinks the non-inline call may change the local variable? Can you change the first line to read: const bool t (_tracking ()); And see if that helps? From boris at codesynthesis.com Wed Sep 18 05:43:06 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 18 05:42:27 2024 Subject: [odb-users] Postgres Bulk Operations on Windows? In-Reply-To: References: Message-ID: Raphael Palefsky-Smith writes: > I gave pipeline mode another shot and it was actually quite simple. I am > getting a *50x* speedup, even more on slower connections. So a huge thank > you for pipeline mode, it really does make a big difference. To get it > working, I changed [...] Thanks for trying this and reporting back the results. Based on this we've now enabled pipeline support on Windows. Note, however, that we had to make a few more tweaks around error handling compared to your changes: https://git.codesynthesis.com/cgit/odb/odb/commit/?id=70d0251d7b802d92d74fe81eea1c35274e193fd6 From boris at codesynthesis.com Wed Sep 18 06:06:32 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 18 06:05:52 2024 Subject: [odb-users] gcc 13.2: =?utf-8?Q?vector?= =?utf-8?B?Lml4eDogd2FybmluZzog4oCYaeKAmQ==?= may be used uninitialized In-Reply-To: References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> <89b46807591f40689dfbc8d36e76bae4@isotravel.com> Message-ID: Siegmund, Harald writes: > Unfortunately the const doesn't make the warning go away. Ok, thanks for testing. I've now suppressed it by making sure the variables in question are always initialized: https://git.codesynthesis.com/cgit/odb/odb/commit/?id=fc3962b053a80e2a6744c3b28e59d4d4c113c166 From Harald.Siegmund at isotravel.com Thu Sep 19 02:19:00 2024 From: Harald.Siegmund at isotravel.com (Siegmund, Harald) Date: Thu Sep 19 03:51:07 2024 Subject: =?Windows-1252?Q?AW:_[odb-users]_gcc_13.2:_vector.ixx:_warning:_=91i=92_m?= =?Windows-1252?Q?ay_be_used_uninitialized?= In-Reply-To: References: <97ba6d6122ae4abdb7522d04061d685e@isotravel.com> <89b46807591f40689dfbc8d36e76bae4@isotravel.com> Message-ID: <4ea5b1724c1e4c7f94ade7d01e17b224@isotravel.com> Thank you, after the last patch the warning message has disappeared. -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov Gesendet: Mittwoch, 18. September 2024 12:07 An: Siegmund, Harald Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] gcc 13.2: vector.ixx: warning: ?i? may be used uninitialized EXTERNAL EMAIL: Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Siegmund, Harald writes: > Unfortunately the const doesn't make the warning go away. Ok, thanks for testing. I've now suppressed it by making sure the variables in question are always initialized: https://protection.retarus.com/v1?u=https%3A%2F%2Fgit.codesynthesis.com%2Fcgit%2Fodb%2Fodb%2Fcommit%2F%3Fid%3Dfc3962b053a80e2a6744c3b28e59d4d4c113c166&c=3s0vctN&r=QzRygBoy4jPfl51t6joTf&k=7s1&s=rBzmWwnktVmr3gKVqJLjPNgVe5SWd0la1GFOOxXRhMq From sunny.sun at ringcentral.com Tue Sep 24 02:19:18 2024 From: sunny.sun at ringcentral.com (Sunny Sun) Date: Tue Sep 24 04:53:54 2024 Subject: [odb-users] Mutex may not be released Re: It was blocked by odb::sqlite::connection_pool_factory::create() In-Reply-To: References: <3AEBBBF8-8875-45F9-83B8-7A909E000708@ringcentral.com> Message-ID: Hi, Boris: After upgrading to odb2.5.0, this issue has been resolved. Thanks! Here I have a new question. How to build arm64 target odb static lib in x64 platform with msvc? I tried the following script, but it failed. bpkg create -d libodb-msvc-release cc^ config.cxx=cl^ "config.cc.coptions=/std:c++20 /O2 /MD /Zi /arch:armv8.0"^ "config.cc.loptions=/MACHINE:ARM64"^ "config.bin.lib=static"^ config.install.root="%CurrentFolder%output\Release" Could you help? Thank you in advance. Sunny Sun ________________________________ From: Boris Kolpackov Sent: Monday, July 29, 2024 9:21 PM To: Sunny Sun Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Mutex may not be released Re: It was blocked by odb::sqlite::connection_pool_factory::create() [EXTERNAL] Sunny Sun writes: > I downloaded the source code here: https://urldefense.com/v3/__https://git.codesynthesis.com/cgit/odb/odb/__;!!J-1DKIBqn-Pi!C-lhggN4IwnFJyVtJZuZ0UK0grancufwYh-RHcDdDKkMqFePtzEKba328-nKS5fq8jrNWAmToX3ViFB2DMKWDw$ and tried to understand? > > > In 2.5.0 we have switched to C++11 threading API so maybe that will help. > > But from the code I didn?t find out the exact change. What apis/interfaces > does odb switched? The Win32-based support is still in 2.5.0 and is unchanged (it will be dropped in 2.6.0 once we drop support for C++98/03). But by default in 2.5.0 we don't use it, instead using the C++11 threading support. This is controlled with the ODB_THREADS_* macros, for example: https://urldefense.com/v3/__https://git.codesynthesis.com/cgit/odb/libodb/tree/odb/details/mutex.hxx__;!!J-1DKIBqn-Pi!C-lhggN4IwnFJyVtJZuZ0UK0grancufwYh-RHcDdDKkMqFePtzEKba328-nKS5fq8jrNWAmToX3ViFAkFqpIxg$ > Could you help analyze it? I will again suggest that you try 2.5.0 and see if that makes a difference. From boris at codesynthesis.com Tue Sep 24 05:00:59 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 24 05:00:17 2024 Subject: [odb-users] Cross-compiling from x86 to ARM on Windows Message-ID: Sunny Sun writes: > After upgrading to odb2.5.0, this issue has been resolved. Thanks! > > Here I have a new question. Do not send a new question by replying to an existing message. It will end up with an unrelated subject and this makes email clients with support for threading as well as the mailing list archives less usable. Instead, create a new email with a new subject. This is guideline #2 in the posting guidelines: https://codesynthesis.com/support/posting-guidelines.xhtml > How to build arm64 target odb static lib in x64 platform with msvc? > I tried the following script, but it failed. > > bpkg create -d libodb-msvc-release cc^ > config.cxx=cl^ > "config.cc.coptions=/std:c++20 /O2 /MD /Zi /arch:armv8.0"^ > "config.cc.loptions=/MACHINE:ARM64"^ > "config.bin.lib=static"^ > config.install.root="%CurrentFolder%output\Release" > > Could you help? What is the diagnostics that you get when you try this? From finjulhich at gmail.com Wed Sep 25 13:40:46 2024 From: finjulhich at gmail.com (MM) Date: Wed Sep 25 13:41:16 2024 Subject: [odb-users] odb libpq connection debugging Message-ID: Hi, Case 1: Process entirely C++. We create a ssh tunnel with the help of libssh2 and obtain a dynamic local port that the tunnel listens on. ODB postgres database class creation is pointed to this in-process tunnel (localhost, localport) and the class is created ,and the db.begin() call inside a transation succeeds and queries work and everything works. Case 2: Process mixes python and C++. We exposed the creation of odb::database via boost::python. From python we instantiate the odb::database instance that we get back as a opaque pointer. We use sshtunnel python module to create the tunnel case 2.1 : python process1 runs the sshtunnel module python process2 instantiate the ODB database class (via boost::python) and runs queries to this sshtunnel process1 successfully all the way to the database and queries work. case 2.2: we tried in the *same* python process to do use the sshtunnel module and instantiate the ODB database class and start the odb::transaction. As connection to postgresql is laze, the odb::transaction is what hangs. we have a pg connection_timeout of 10second, and it times out. We see however the odb/libpq local socket connected successfully to the in-process sshtunnel listening port , ESTABLISHED successfully, so what must be failing further comm through the tunnel to reach all the way to the remote postgreql server. We see the postgresql server side TCP connection never established. Is there any way to tell odb to tell libpq to debug more? Can the global python interpreter GIL lock impact this? Rds, MM From sunny.sun at ringcentral.com Thu Sep 26 02:02:55 2024 From: sunny.sun at ringcentral.com (Sunny Sun) Date: Thu Sep 26 07:30:47 2024 Subject: [odb-users] Re: Cross-compiling from x86 to ARM on Windows In-Reply-To: References: Message-ID: It got error: unable to translate target triplet CPU aarch64 to /MACHINE Even if I delete the option " config.cc.loptions=/MACHINE:ARM64", it still returns the same error. ________________________________ From: Boris Kolpackov Sent: Tuesday, September 24, 2024 5:00 PM To: Sunny Sun Cc: odb-users@codesynthesis.com Subject: Cross-compiling from x86 to ARM on Windows [EXTERNAL] Sunny Sun writes: > After upgrading to odb2.5.0, this issue has been resolved. Thanks! > > Here I have a new question. Do not send a new question by replying to an existing message. It will end up with an unrelated subject and this makes email clients with support for threading as well as the mailing list archives less usable. Instead, create a new email with a new subject. This is guideline #2 in the posting guidelines: https://urldefense.com/v3/__https://codesynthesis.com/support/posting-guidelines.xhtml__;!!J-1DKIBqn-Pi!ASlAHQxIBLvkaCY273X2ECiakJPKyZG1pEms5tMblQiYnQ4IM_SucXC-MvbUCSkkyguk90TTXvMTqGyj-p3_Lw$ > How to build arm64 target odb static lib in x64 platform with msvc? > I tried the following script, but it failed. > > bpkg create -d libodb-msvc-release cc^ > config.cxx=cl^ > "config.cc.coptions=/std:c++20 /O2 /MD /Zi /arch:armv8.0"^ > "config.cc.loptions=/MACHINE:ARM64"^ > "config.bin.lib=static"^ > config.install.root="%CurrentFolder%output\Release" > > Could you help? What is the diagnostics that you get when you try this? From boris at codesynthesis.com Fri Sep 27 03:29:13 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Sep 27 03:28:30 2024 Subject: [odb-users] odb libpq connection debugging In-Reply-To: References: Message-ID: MM writes: > Is there any way to tell odb to tell libpq to debug more? You can create odb::pgsql::connection by manually creating and passing underlying PGconn*: https://git.codesynthesis.com/cgit/odb/odb/tree/libodb-pgsql/odb/pgsql/connection.hxx#n44 This way you can tell libpq whatever it is you need to tell it, yourself. From finjulhich at gmail.com Fri Sep 27 18:12:06 2024 From: finjulhich at gmail.com (MM) Date: Fri Sep 27 18:12:37 2024 Subject: [odb-users] Containers of containers Message-ID: Hellom Trying to compile and understand the experimental facility of vectors of vectors, I can't odb compile the example here https://cppget.org/odb/2.5.0-b.23?f=full#description around odb/nested-container.hxx first it complains about no id. and then after I place no_id on the object, 1.hpp:16:29: error: unable to map C++ type '::package::licenses_type' used in data member 'license_alternatives' to a PostgreSQL database type 1.hpp:16:29: info: use '#pragma db value_type' to specify the database type What's involved to get the example to work? Rds,