Re: [R-pkg-devel] flang doesn't support derived types
Hello Simon, I must be misunderstanding something, am I expected to CC the mailing list when replying to CRAN? I was just trying to follow the instructions in the email which states > If you are fairly certain the rejection is a false positive, please reply-all to this message and explain. The email address I replied-all to was cran-submissi...@r-project.org. My package is called trngl, the source can be found on GitHub (https://github.com/oelhammouchi/trngl). In my reply, I explained that flang lacks some very basic features of the Fortran 2003 standard (because the compiler is still in development), and that I have added a check to abort the installation if the user's compiler doesn't support these features. This seemed to me to be coherent with the approach taken by packages such as av that require system libraries before they can be installed. I am happy to provide any further detail you want. Yours, Othman El Hammmouchi On 03/06/2024 22:44, Simon Urbanek wrote: > Othman, > > I'm not sure why you would expect a response from CRAN. The ball is in your > court - you have to either fix your code (ideally) or provide a justification > why you think it is safe. I have not seen any email from you to > c...@r-project.org and you have not mentioned the name of the package in this > thread (you should really post the link to the sources if you are at all > serious about this) so it's hard to follow up on - thus I wouldn't expect > anything more on this thread until you make the move. > > Cheers, > Simon > > >> On 4/06/2024, at 7:09 AM, Othman El Hammouchi >> wrote: >> >> Hello once again, >> >> >> Unfortunately, I didn't receive a reply to the mail I sent CRAN nor the >> follow-up/reminder I sent on 2024-05-09. It's been nearly a month now. I >> understand they're busy of course, but it's a bit disheartening not to >> know what one can do to remedy the situation after putting in so much >> work to try to get it published. Would you (or anyone else) have some >> pointers as to how I can receive a reply from CRAN? >> >> >> Yours, >> >> >> Othman El Hammouchi >> >> On 10/05/2024 08:04, Othman El Hammouchi wrote: >>> Dear Ivan, >>> >>> >>> Thanks again for the help, you've given me some great pointers to >>> pursue. I will keep you posted on what CRAN responds and whether I >>> find a workaround. >>> I do wish that flang-new would be a better compiler or at least a better documented one, but instead of a list of features on their website, I can only see "Getting Involved [3] for tips on how to get in touch <...> and to learn more about the current status". There is only so many projects one can get involved in. >>> The problem is not the quality of the compiler so much as the fact >>> that it's not finished. They don't make a big secret of the fact that >>> it's still under development. It may be the standard in industry as >>> you say, but it would greatly surprise me if it was the default for >>> most ordinary users. Most distros and platforms seem to ship the (much >>> more complete) gfortran. >>> >>> >>> Yours, >>> >>> >>> Othman El Hammouchi >>> >>> On 09/05/2024 18:34, Ivan Krylov wrote: В Thu, 09 May 2024 15:31:25 + Othman El Hammouchi пишет: > Do I understand it correctly that there is no way to specify a > Fortran standard in the SystemRequirements? It's possible (and even recommended) to describe the Fortran version requirement in SystemRequirements [1], but this field is for now mostly informational. I think I remember efforts to standardise it, but they are far from complete. > I had resubmitted my package in the mean time with a configure script > that aborts the install if the compiler does not support > polymorphism, but I understand that this is a fruitless avenue for > CRAN? Signs point to yes, at least judging by a previous time we had flang-related problems [2]. On the other hand, there were relatively easy workarounds that time, and here I'm not seeing anything as simple. > I should point out my local flang install is version 16, but I cannot > install 18 on my system since it's in unstable (this again > underscores the problem of developing under these constraints). Would you consider containers for this purpose? I was able to reproduce the problem relatively quickly by starting podman run --rm -it debian:sid and installing flang-18 in there. (Unlike Docker a few years ago, podman can be installed straight from the repository, at least on Debian, and doesn't require adding users to special groups in order to work. Maybe Docker has also improved.) I don't like containers as a basis for software distribution, but I can't deny that they are being great at letting me quickly reproduce problems without installing 10 different GNU/Linux distros. > What would you advise? And don't you think these
Re: [R-pkg-devel] flang doesn't support derived types
Othman, I'm not sure why you would expect a response from CRAN. The ball is in your court - you have to either fix your code (ideally) or provide a justification why you think it is safe. I have not seen any email from you to c...@r-project.org and you have not mentioned the name of the package in this thread (you should really post the link to the sources if you are at all serious about this) so it's hard to follow up on - thus I wouldn't expect anything more on this thread until you make the move. Cheers, Simon > On 4/06/2024, at 7:09 AM, Othman El Hammouchi > wrote: > > Hello once again, > > > Unfortunately, I didn't receive a reply to the mail I sent CRAN nor the > follow-up/reminder I sent on 2024-05-09. It's been nearly a month now. I > understand they're busy of course, but it's a bit disheartening not to > know what one can do to remedy the situation after putting in so much > work to try to get it published. Would you (or anyone else) have some > pointers as to how I can receive a reply from CRAN? > > > Yours, > > > Othman El Hammouchi > > On 10/05/2024 08:04, Othman El Hammouchi wrote: >> Dear Ivan, >> >> >> Thanks again for the help, you've given me some great pointers to >> pursue. I will keep you posted on what CRAN responds and whether I >> find a workaround. >> >>> I do wish that flang-new would be a better compiler or at least a >>> better documented one, but instead of a list of features on their >>> website, I can only see "Getting Involved [3] for tips on how to get in >>> touch <...> and to learn more about the current status". There is only >>> so many projects one can get involved in. >> >> The problem is not the quality of the compiler so much as the fact >> that it's not finished. They don't make a big secret of the fact that >> it's still under development. It may be the standard in industry as >> you say, but it would greatly surprise me if it was the default for >> most ordinary users. Most distros and platforms seem to ship the (much >> more complete) gfortran. >> >> >> Yours, >> >> >> Othman El Hammouchi >> >> On 09/05/2024 18:34, Ivan Krylov wrote: >>> В Thu, 09 May 2024 15:31:25 + >>> Othman El Hammouchi пишет: >>> Do I understand it correctly that there is no way to specify a Fortran standard in the SystemRequirements? >>> It's possible (and even recommended) to describe the Fortran version >>> requirement in SystemRequirements [1], but this field is for now mostly >>> informational. I think I remember efforts to standardise it, but they >>> are far from complete. >>> I had resubmitted my package in the mean time with a configure script that aborts the install if the compiler does not support polymorphism, but I understand that this is a fruitless avenue for CRAN? >>> Signs point to yes, at least judging by a previous time we had >>> flang-related problems [2]. On the other hand, there were relatively >>> easy workarounds that time, and here I'm not seeing anything as simple. >>> I should point out my local flang install is version 16, but I cannot install 18 on my system since it's in unstable (this again underscores the problem of developing under these constraints). >>> Would you consider containers for this purpose? I was able to reproduce >>> the problem relatively quickly by starting podman run --rm -it >>> debian:sid and installing flang-18 in there. (Unlike Docker a few years >>> ago, podman can be installed straight from the repository, at least on >>> Debian, and doesn't require adding users to special groups in order to >>> work. Maybe Docker has also improved.) I don't like containers as a >>> basis for software distribution, but I can't deny that they are being >>> great at letting me quickly reproduce problems without installing 10 >>> different GNU/Linux distros. >>> What would you advise? And don't you think these Fortran constraints should be better documenten. >>> I'm afraid I don't have any more specific advice besides testing your >>> workarounds with Debian Sid in a container or a virtual machine or a >>> chroot. I can try to take a look at more concrete problems. I hope you >>> will be able to find a relatively painless workaround. >>> >>> I do wish that flang-new would be a better compiler or at least a >>> better documented one, but instead of a list of features on their >>> website, I can only see "Getting Involved [3] for tips on how to get in >>> touch <...> and to learn more about the current status". There is only >>> so many projects one can get involved in. >>> >>> -- >>> Best regards, >>> Ivan >>> >>> [1] >>> https://cran.r-project.org/doc/manuals/R-exts.html#Using-modern-Fortran-code >>> >>> >>> >>> [2] >>> https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010065.html >>> >>> [3] >>> https://flang.llvm.org/docs/GettingInvolved.html > > __ > R-package-devel@r-project.org mailing
Re: [R-pkg-devel] flang doesn't support derived types
Hello once again, Unfortunately, I didn't receive a reply to the mail I sent CRAN nor the follow-up/reminder I sent on 2024-05-09. It's been nearly a month now. I understand they're busy of course, but it's a bit disheartening not to know what one can do to remedy the situation after putting in so much work to try to get it published. Would you (or anyone else) have some pointers as to how I can receive a reply from CRAN? Yours, Othman El Hammouchi On 10/05/2024 08:04, Othman El Hammouchi wrote: > Dear Ivan, > > > Thanks again for the help, you've given me some great pointers to > pursue. I will keep you posted on what CRAN responds and whether I > find a workaround. > > > I do wish that flang-new would be a better compiler or at least a > > better documented one, but instead of a list of features on their > > website, I can only see "Getting Involved [3] for tips on how to get in > > touch <...> and to learn more about the current status". There is only > > so many projects one can get involved in. > > The problem is not the quality of the compiler so much as the fact > that it's not finished. They don't make a big secret of the fact that > it's still under development. It may be the standard in industry as > you say, but it would greatly surprise me if it was the default for > most ordinary users. Most distros and platforms seem to ship the (much > more complete) gfortran. > > > Yours, > > > Othman El Hammouchi > > On 09/05/2024 18:34, Ivan Krylov wrote: >> В Thu, 09 May 2024 15:31:25 + >> Othman El Hammouchi пишет: >> >>> Do I understand it correctly that there is no way to specify a >>> Fortran standard in the SystemRequirements? >> It's possible (and even recommended) to describe the Fortran version >> requirement in SystemRequirements [1], but this field is for now mostly >> informational. I think I remember efforts to standardise it, but they >> are far from complete. >> >>> I had resubmitted my package in the mean time with a configure script >>> that aborts the install if the compiler does not support >>> polymorphism, but I understand that this is a fruitless avenue for >>> CRAN? >> Signs point to yes, at least judging by a previous time we had >> flang-related problems [2]. On the other hand, there were relatively >> easy workarounds that time, and here I'm not seeing anything as simple. >> >>> I should point out my local flang install is version 16, but I cannot >>> install 18 on my system since it's in unstable (this again >>> underscores the problem of developing under these constraints). >> Would you consider containers for this purpose? I was able to reproduce >> the problem relatively quickly by starting podman run --rm -it >> debian:sid and installing flang-18 in there. (Unlike Docker a few years >> ago, podman can be installed straight from the repository, at least on >> Debian, and doesn't require adding users to special groups in order to >> work. Maybe Docker has also improved.) I don't like containers as a >> basis for software distribution, but I can't deny that they are being >> great at letting me quickly reproduce problems without installing 10 >> different GNU/Linux distros. >> >>> What would you advise? And don't you think these Fortran constraints >>> should be better documenten. >> I'm afraid I don't have any more specific advice besides testing your >> workarounds with Debian Sid in a container or a virtual machine or a >> chroot. I can try to take a look at more concrete problems. I hope you >> will be able to find a relatively painless workaround. >> >> I do wish that flang-new would be a better compiler or at least a >> better documented one, but instead of a list of features on their >> website, I can only see "Getting Involved [3] for tips on how to get in >> touch <...> and to learn more about the current status". There is only >> so many projects one can get involved in. >> >> -- >> Best regards, >> Ivan >> >> [1] >> https://cran.r-project.org/doc/manuals/R-exts.html#Using-modern-Fortran-code >> >> >> [2] >> https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010065.html >> >> [3] >> https://flang.llvm.org/docs/GettingInvolved.html __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Including "Rmath.h" in C code for an R package
Thank you for the suggestion! It looks like that caused problems with other parts of the code, so I just added these couple of lines after the import to avoid the beta remaps: #ifdef beta #undef beta #endif On Mon, Jun 3, 2024 at 5:56 AM Duncan Murdoch wrote: > On 2024-06-02 7:39 p.m., Iris Simmons wrote: > > To avoid the remapping of beta to Rf_beta, you should > > define R_NO_REMAP_RMATH before you include Rmath: > > > > #define R_NO_REMAP_RMATH > > #include > > ... and then remember to include the "Rf_" prefix on the routines that > you do want to use. > > Duncan Murdoch > > > > > On Sun, Jun 2, 2024, 19:33 Gregory Raskind wrote: > > > >> Hi, > >> > >> I'm extending an R package that uses the R C API directly. I'd like to > use > >> some distribution functions, so I included the "Rmath.h" header. The > issue > >> is that this introduces macros that have unintended consequences for the > >> code. For example, I have a local variable named "beta", which is > expanded > >> to "Rf_beta". > >> > >> Is there a way of including the "Rmath.h" header without applying the > >> macros to my code? E.g. if I want to use the beta function, I would use > it > >> with "Rf_beta(a,b)", but "beta" would remain my local variable. > >> > >> Thanks for your time! > >> > >> Best, > >> Greg > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-package-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >> > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Including "Rmath.h" in C code for an R package
On 2024-06-02 7:39 p.m., Iris Simmons wrote: To avoid the remapping of beta to Rf_beta, you should define R_NO_REMAP_RMATH before you include Rmath: #define R_NO_REMAP_RMATH #include ... and then remember to include the "Rf_" prefix on the routines that you do want to use. Duncan Murdoch On Sun, Jun 2, 2024, 19:33 Gregory Raskind wrote: Hi, I'm extending an R package that uses the R C API directly. I'd like to use some distribution functions, so I included the "Rmath.h" header. The issue is that this introduces macros that have unintended consequences for the code. For example, I have a local variable named "beta", which is expanded to "Rf_beta". Is there a way of including the "Rmath.h" header without applying the macros to my code? E.g. if I want to use the beta function, I would use it with "Rf_beta(a,b)", but "beta" would remain my local variable. Thanks for your time! Best, Greg [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
