[Gretl-devel] Re: Windows build 2020a/b
On Wed, 25 Mar 2020, Sven Schreiber wrote: Am 20.03.2020 um 10:31 schrieb Sven Schreiber: Hi everybody and especially Allin of course, I just remembered that I had tried again to build gretl (2020a) on Windows last week but still got some errors. I will see if I can re-run that thing and post the details. OK here's what I did. I already have MSYS/MinGW installed (64bit). I deleted the old /opt/gretl and ~/src/build. In ~/src/gretl-git I did git pull. I deleted ~/pkglist.sh, ~/add-repo.sh, and ~/setup.sh. I ran pacman -Syu (which produced quite a bit of updates). I re-downloaded setup.sh as per the wget command in the guide and ran: bash setup.sh. Clearly this did not fully work. You're missing (at least part) of the content of the the gretl-x86_64-deps package from the pacman repository at sourceforge. That package includes the R and mpi headers that your build is missing. See section 3.5 of "Building gretl on MS Windows". (Mingw's openblas and curl conflict with the gretl deps package and have to be removed along the way. This is a bit of a problem -but not major- when you also do other stuff with this MSYS instance, you always have to flip back and forth. But that's not the point right now.) Perhaps I should offer a split of the gretl-x86_64-deps package, leaving out openblas and curl so people could just use the mingw64 versions. The reasons I've not done that to date are: * Openblas should really be multi-threaded via OpenMP for use with gretl, but the mingw64 package uses raw pthreads. * The mingw64 curl package is fine, but it's full-featured and drags in as dependencies a lot of DLLs that gretl has no use for. The curl in my package is slimmed down to what gretl actually needs. This has more relevance if you're building gretl for distribution rather than just for your own use. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: Windows build 2020a/b
Am 25.03.2020 um 21:42 schrieb Allin Cottrell: On Wed, 25 Mar 2020, Sven Schreiber wrote: I re-downloaded setup.sh as per the wget command in the guide and ran: bash setup.sh. Clearly this did not fully work. You're missing (at least part) of the content of the the gretl-x86_64-deps package from the pacman repository at sourceforge. That package includes the R and mpi headers that your build is missing. See section 3.5 of "Building gretl on MS Windows". I'm pretty sure that the deps package was installed again since it asked me whether it was OK to remove the openblas and curl packages because of that. I will re-visit that part tomorrow. thanks sven ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: Windows build 2020a/b
Am 20.03.2020 um 10:31 schrieb Sven Schreiber: Hi everybody and especially Allin of course, I just remembered that I had tried again to build gretl (2020a) on Windows last week but still got some errors. I will see if I can re-run that thing and post the details. OK here's what I did. I already have MSYS/MinGW installed (64bit). I deleted the old /opt/gretl and ~/src/build. In ~/src/gretl-git I did git pull. I deleted ~/pkglist.sh, ~/add-repo.sh, and ~/setup.sh. I ran pacman -Syu (which produced quite a bit of updates). I did not delete the texinst shell script in the hope that this time-consuming step could be avoided. I re-downloaded setup.sh as per the wget command in the guide and ran: bash setup.sh. (Mingw's openblas and curl conflict with the gretl deps package and have to be removed along the way. This is a bit of a problem -but not major- when you also do other stuff with this MSYS instance, you always have to flip back and forth. But that's not the point right now.) Then ran make inside ~/src/build. (But this is with the default GTK2. The aim is to build with GTK3 afterwards.) This gives the following error: ../../gretl-git/lib/src/gretl_foreign.c:39:11: fatal error: Rinternals.h: No such file or directory 39 | # include /* for SEXP and friends */ | ^~ compilation terminated. Then I ran 'make clean' inside ~/src/build and added to conf.sh the additional switch --with-libR=no. I got some warning about being unable to build docs because XSLT or pdflatex not found. I ran make again nonetheless. Then I get this error: ../../gretl-git/lib/src/gretl_mpi.c:23:10: fatal error: mpi.h: No such file or directory 23 | #include | ^~~ compilation terminated. OK, so again 'make clean' and added --with-mpi=no to conf.sh. The build then finished without errors! (Didn't try installing etc.) Now back to the GTK3 issue: Ran make clean again and deleted the --enable-gtk2 line from conf.sh. The make stage is still running (building on MSYS seems quite a bit slower than on Linux). Will report back thanks sven ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: Problem with ODBC query
> On Mon, 23 Mar 2020, atecon(a)posteo.de wrote: > > > I see what you mean (I think!). Getting this right involves some > brain-bending mapping between 1-based SQL columns, 0-based C arrays, > and 1-based dataset series. But I believe this should now work > better in current git. > > Allin Hi Allin, sorry for another post on this. While the working of SQL_DATE works nicely, I still get wrongly fetched data if the first selected column is of type SQL_DATE, the second is of type SQL_VARCHAR -- the format of the remaining ones does not matter. QUERY 1: WORKS col 1 (DATUM): data_type SQL_DATE, size 10, digits 0, nullable 2 (?) col 2 (KLIMA): data_type SQL_DECIMAL, size 4, digits 1, nullable 2 (?) binding col 2 to xt[0] col 3 (SEKTOR): data_type SQL_VARCHAR, size 20, digits 0, nullable 2 (?) binding col 3 to strvals[1] (len = 20) <> nulldata NOBS -p setobs 7 2018-01-01 --time-series string Q = "SELECT DATUM, KLIMA, SEKTOR FROM ABC.DEF" data klima sektor obs-format="%s" query=Q --odbc --verbose print dataset -o indexklima sektor 2018-01-011104.8 gesamt 2018-01-022104.8 gesamt 2018-01-033104.8 gesamt 2018-01-044104.8 gesamt 2018-01-055104.8 gesamt QUERY 2: FAILS <> nulldata NOBS -p setobs 7 2018-01-01 --time-series string Q = "SELECT DATUM, SEKTOR, KLIMA FROM ABC.DEF" data sektor klima obs-format="%s" query=Q --odbc print dataset -o As you can see, "sektor" has no string-values any more and for "klima" are values are missing. index sektorklima 2018-01-0111 2018-01-0221 2018-01-0331 2018-01-0441 2018-01-0551 Thank you, Artur ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: Windows build 2020a/b
Am 25.03.2020 um 09:54 schrieb Sven Schreiber: Am 20.03.2020 um 10:31 schrieb Sven Schreiber: Now back to the GTK3 issue: Ran make clean again and deleted the --enable-gtk2 line from conf.sh. The make stage is still running (building on MSYS seems quite a bit slower than on Linux). So this also seemed to work (remember: GTK3, but no R, no MPI, no pdfdocs, no addons). Running 'make install' did not produce any further error, either. So much for now, waiting for advice about the earlier failures. thanks sven ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: Problem with ODBC query
On Wed, 25 Mar 2020, ate...@posteo.de wrote: On Mon, 23 Mar 2020, atecon(a)posteo.de wrote: I see what you mean (I think!). Getting this right involves some brain-bending mapping between 1-based SQL columns, 0-based C arrays, and 1-based dataset series. But I believe this should now work better in current git. Allin Hi Allin, sorry for another post on this. While the working of SQL_DATE works nicely, I still get wrongly fetched data if the first selected column is of type SQL_DATE, the second is of type SQL_VARCHAR -- the format of the remaining ones does not matter. QUERY 1: WORKS col 1 (DATUM): data_type SQL_DATE, size 10, digits 0, nullable 2 (?) col 2 (KLIMA): data_type SQL_DECIMAL, size 4, digits 1, nullable 2 (?) binding col 2 to xt[0] col 3 (SEKTOR): data_type SQL_VARCHAR, size 20, digits 0, nullable 2 (?) binding col 3 to strvals[1] (len = 20) <> nulldata NOBS -p setobs 7 2018-01-01 --time-series string Q = "SELECT DATUM, KLIMA, SEKTOR FROM ABC.DEF" data klima sektor obs-format="%s" query=Q --odbc --verbose print dataset -o indexklima sektor 2018-01-011104.8 gesamt 2018-01-022104.8 gesamt 2018-01-033104.8 gesamt 2018-01-044104.8 gesamt 2018-01-055104.8 gesamt QUERY 2: FAILS <> nulldata NOBS -p setobs 7 2018-01-01 --time-series string Q = "SELECT DATUM, SEKTOR, KLIMA FROM ABC.DEF" data sektor klima obs-format="%s" query=Q --odbc print dataset -o As you can see, "sektor" has no string-values any more and for "klima" are values are missing. index sektorklima 2018-01-0111 2018-01-0221 2018-01-0331 2018-01-0441 2018-01-0551 Thanks for your patience with this, Artur. I now see what was going wrong in this case, and it should be fixed in git. (The actual ODBC import was fine, but the transcription into the gretl dataset was messed up.) Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
