Re: [arts-dev] ARTS/Python interfaces
Hi Stuart, The linker issue is resolved in the latest version. Cheers, Oliver > On 16 Apr 2020, at 14:31, Fox, Stuart wrote: > > Yes, that seems to work - builds successfully and passes all standard tests. > Thanks! > > -Original Message- > From: Oliver Lemke > Sent: 16 April 2020 13:01 > To: Fox, Stuart > Cc: ARTS Development List > Subject: Re: [arts-dev] ARTS/Python interfaces > > > Do you set the CMAKE_BUILD_TYPE to Release when you get this error? If so, > try to compile with CMAKE_BUILD_TYPE=RelWithDebInfo as a temporary > workaround. Does that fix the error for you? > > Cheers, > Oliver > > >> On 16 Apr 2020, at 13:24, Oliver Lemke wrote: >> >>> However, I can’t actually get the most recent dev-version of ARTS to build >>> at all. Linking fails with a bunch of errors along the lines of >>> libartscore.a(m_absorptionlines.cc.o): In function >>> `abs_linesWriteSpeciesSplitXML(my_basic_string const&, >>> Array const&, my_basic_string const&, Verbosity >>> const&)': >>> m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void >>> WriteXML >(my_basic_string const&, >>> Array const&, my_basic_string const&, long const&, >>> my_basic_string const&, my_basic_string const&, >>> my_basic_string const&, Verbosity const&)' >>> >>> Any ideas what’s wrong? >> >> I think I've seen that error when compiling on one of our servers. I'll try >> to reproduce and fix this. >> >> Cheers, >> Oliver > smime.p7s Description: S/MIME cryptographic signature ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] ARTS/Python interfaces
Do you set the CMAKE_BUILD_TYPE to Release when you get this error? If so, try to compile with CMAKE_BUILD_TYPE=RelWithDebInfo as a temporary workaround. Does that fix the error for you? Cheers, Oliver > On 16 Apr 2020, at 13:24, Oliver Lemke wrote: > >> However, I can’t actually get the most recent dev-version of ARTS to build >> at all. Linking fails with a bunch of errors along the lines of >> libartscore.a(m_absorptionlines.cc.o): In function >> `abs_linesWriteSpeciesSplitXML(my_basic_string const&, >> Array const&, my_basic_string const&, Verbosity >> const&)': >> m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void >> WriteXML >(my_basic_string const&, >> Array const&, my_basic_string const&, long const&, >> my_basic_string const&, my_basic_string const&, >> my_basic_string const&, Verbosity const&)' >> >> Any ideas what’s wrong? > > I think I've seen that error when compiling on one of our servers. I'll try > to reproduce and fix this. > > Cheers, > Oliver smime.p7s Description: S/MIME cryptographic signature ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] ARTS/Python interfaces
Hi Stuart, > On 9 Apr 2020, at 15:51, Fox, Stuart wrote: > > Thanks – good news that there hopefully won’t be many modifications to work > with pyarts (although I’m not sure I’m looking forward to having to try and > work out how to get Python stuff that is fully integrated in ARTS working > with our systems here if they need packages that aren’t available in our > default installs). If it's a Linux system, the use of pyarts should be very easy. Thanks to Simon, we now provide a version via PyPi with a precompiled ARTS library for Linux. Getting it should be as easy as doing: pip install --user pyarts No need to even check out the ARTS source code. :-) At least if you don't need anything from controlfiles/general. > However, I can’t actually get the most recent dev-version of ARTS to build at > all. Linking fails with a bunch of errors along the lines of > libartscore.a(m_absorptionlines.cc.o): In function > `abs_linesWriteSpeciesSplitXML(my_basic_string const&, > Array const&, my_basic_string const&, Verbosity > const&)': > m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void > WriteXML >(my_basic_string const&, > Array const&, my_basic_string const&, long const&, > my_basic_string const&, my_basic_string const&, > my_basic_string const&, Verbosity const&)' > > Any ideas what’s wrong? I think I've seen that error when compiling on one of our servers. I'll try to reproduce and fix this. Cheers, Oliver > Stuart > > From: Richard Larsson > Sent: 09 April 2020 14:40 > To: Fox, Stuart > Cc: arts_dev.mi@lists.uni-hamburg.de > Subject: Re: [arts-dev] ARTS/Python interfaces > > Hi Stuart, > > The dev-version of ARTS has full support of the workspace methods of typhon. > In fact, typhon.arts.workspace is simply pyarts.workspace with some small > modifications. So things should work as they have with typhon just making > that replacement in your imports. If you use other things from typhon, like > setting environment data like arts-xml-data paths, I am really not sure how > it they work in the future. I hope we can add that to let pyarts handle it > automatically itself. > > I see no reason why typhon should remove the ARTS interface entirely, but > they will likely want to change so the version of pyarts from ARTS replaces > the "arts" module when things settle down on the ARTS side. Especially if > the two projects start to diverge (e.g., new python features will be added to > the ARTS-version, and not to typhon). > > With hope, > --Richard > > Den tors 9 apr. 2020 kl 14:24 skrev Fox, Stuart : > Hi developers, > > I’ve just been working on interfacing some Python code with ARTS (basically > using ARTS to provide atmospheric radiances for use with the SMRT snow > surface microwave model). So far my implementation uses the > typhon.arts.workspace functions for the interfacing, but I notice from the > recent history on github that there might be some other ARTS/Python work > going on at the moment? Does this mean that the typhon method will be > deprecated soon? Is there any info/update on what is going on with > ARTS/python interfacing? > > Cheers, > > Stuart > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi smime.p7s Description: S/MIME cryptographic signature ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] ARTS/Python interfaces
Thanks – good news that there hopefully won’t be many modifications to work with pyarts (although I’m not sure I’m looking forward to having to try and work out how to get Python stuff that is fully integrated in ARTS working with our systems here if they need packages that aren’t available in our default installs). However, I can’t actually get the most recent dev-version of ARTS to build at all. Linking fails with a bunch of errors along the lines of libartscore.a(m_absorptionlines.cc.o): In function `abs_linesWriteSpeciesSplitXML(my_basic_string const&, Array const&, my_basic_string const&, Verbosity const&)': m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void WriteXML >(my_basic_string const&, Array const&, my_basic_string const&, long const&, my_basic_string const&, my_basic_string const&, my_basic_string const&, Verbosity const&)' Any ideas what’s wrong? Stuart From: Richard Larsson Sent: 09 April 2020 14:40 To: Fox, Stuart Cc: arts_dev.mi@lists.uni-hamburg.de Subject: Re: [arts-dev] ARTS/Python interfaces Hi Stuart, The dev-version of ARTS has full support of the workspace methods of typhon. In fact, typhon.arts.workspace is simply pyarts.workspace with some small modifications. So things should work as they have with typhon just making that replacement in your imports. If you use other things from typhon, like setting environment data like arts-xml-data paths, I am really not sure how it they work in the future. I hope we can add that to let pyarts handle it automatically itself. I see no reason why typhon should remove the ARTS interface entirely, but they will likely want to change so the version of pyarts from ARTS replaces the "arts" module when things settle down on the ARTS side. Especially if the two projects start to diverge (e.g., new python features will be added to the ARTS-version, and not to typhon). With hope, --Richard Den tors 9 apr. 2020 kl 14:24 skrev Fox, Stuart mailto:stuart@metoffice.gov.uk>>: Hi developers, I’ve just been working on interfacing some Python code with ARTS (basically using ARTS to provide atmospheric radiances for use with the SMRT snow surface microwave model). So far my implementation uses the typhon.arts.workspace functions for the interfacing, but I notice from the recent history on github that there might be some other ARTS/Python work going on at the moment? Does this mean that the typhon method will be deprecated soon? Is there any info/update on what is going on with ARTS/python interfacing? Cheers, Stuart ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de<mailto:arts_dev.mi@lists.uni-hamburg.de> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] ARTS/Python interfaces
Hi Stuart, The dev-version of ARTS has full support of the workspace methods of typhon. In fact, typhon.arts.workspace is simply pyarts.workspace with some small modifications. So things should work as they have with typhon just making that replacement in your imports. If you use other things from typhon, like setting environment data like arts-xml-data paths, I am really not sure how it they work in the future. I hope we can add that to let pyarts handle it automatically itself. I see no reason why typhon should remove the ARTS interface entirely, but they will likely want to change so the version of pyarts from ARTS replaces the "arts" module when things settle down on the ARTS side. Especially if the two projects start to diverge (e.g., new python features will be added to the ARTS-version, and not to typhon). With hope, --Richard Den tors 9 apr. 2020 kl 14:24 skrev Fox, Stuart : > Hi developers, > > > > I’ve just been working on interfacing some Python code with ARTS > (basically using ARTS to provide atmospheric radiances for use with the > SMRT snow surface microwave model). So far my implementation uses the > typhon.arts.workspace functions for the interfacing, but I notice from the > recent history on github that there might be some other ARTS/Python work > going on at the moment? Does this mean that the typhon method will be > deprecated soon? Is there any info/update on what is going on with > ARTS/python interfacing? > > > > Cheers, > > > > Stuart > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
[arts-dev] ARTS/Python interfaces
Hi developers, I've just been working on interfacing some Python code with ARTS (basically using ARTS to provide atmospheric radiances for use with the SMRT snow surface microwave model). So far my implementation uses the typhon.arts.workspace functions for the interfacing, but I notice from the recent history on github that there might be some other ARTS/Python work going on at the moment? Does this mean that the typhon method will be deprecated soon? Is there any info/update on what is going on with ARTS/python interfacing? Cheers, Stuart ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
