Re: [R-pkg-devel] Fortune candidate Re: Issue with R Package on CRAN - OpenMP and clang17

2023-10-31 Thread Greg Hunt
If i remember rightly one of the early Algol compilers for the IBM mainframe couldnt be compiled on an IBM mainframe because it was too memory hungry (it had to be cross compiled). The numbers change, but the problems don’t, except that i haven’t run a compile lately that ran out of memory like

Re: [R-pkg-devel] Too many cores used in examples (not caused by data.table)

2023-10-24 Thread Greg Hunt
In my case recently, after an hour or so’s messing about I disabled some tests and example executions to get rid of the offending times. I doubt that i am the only one to do that. On Tue, 24 Oct 2023 at 9:38 pm, Helske, Jouni wrote: > Thanks for the help, I now tried resubmitting with >

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

2023-08-26 Thread Greg Hunt
that data.table could not do better with it’s > heuristics (e.g. respecting CGroups settings as raised by Henrik in > https://github.com/Rdatatable/data.table/issues/5620) but the current > defaults (50%) seem reasonable for, dare I say, most users. > > Tim > > On 26 Aug 2023, at

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

2023-08-25 Thread Greg Hunt
The question should be, in how many cases is the current behaviour a problem? In a shared environment, sure, you have to be more careful. I'd say don't let the teenagers in there. The CRAN build server does need to do something to protect itself and I don't greatly mind the 2 thread limit, I

Re: [R-pkg-devel] "pdflatex: not found" in GitHub Action

2022-04-23 Thread Greg Hunt
to the wisdom of using it in a package vignette. Greg On Sat, 23 Apr 2022 at 22:34, Spencer Graves < spencer.gra...@effectivedefense.org> wrote: > Hello, All: > > > Greg Hunt asked this list 4 hours ago, > "Is the > use of pdfpages a viable a

Re: [R-pkg-devel] URL checks

2022-06-30 Thread Greg Hunt
make the URL checks better for everyone. I probably sound > defeatist in my e-mails; sorry about that. > > On Thu, 30 Jun 2022 17:49:49 +1000 > Greg Hunt wrote: > > > Do you have evidence that even without the use of HEAD that > > CloudFlare is rejecting the CRAN check

Re: [R-pkg-devel] Searching examples in source code

2022-05-08 Thread Greg Hunt
Indeed, and since this is a database client, the question is not just the elapsed time of the client code, but the optimisation opportunities need to be viewed as a proportion of the overall request time: client time, network time, typical and minimum database server time. On Mon, 9 May 2022 at

Re: [R-pkg-devel] Non-ASCII and CRAN Checks

2022-09-20 Thread Greg Hunt
Leaving data in the wrong encoding is leaving a bug around waiting to surface. Is the data correctly encoded as Latin1 (codepage 8859-1), Windows 8 bit (codepage 1252, also sometimes referred to as Latin1) or some Unicode encoding (likely UTF-8)? Character mapping is not such an issue for

Re: [R-pkg-devel] Undocumented requirement for CRAN

2022-09-12 Thread Greg Hunt
These aren't requirements of the language, they are issues of code and documentation quality. Other languages have exactly the same issues and no code audit tool I've ever seen provides 100% coverage of potential issues. There is always a level of human intelligence applied to effective code

Re: [R-pkg-devel] corrupted NAMESPACE file

2023-01-20 Thread Greg Hunt
xFEFF isn't a BOM in a UTF-8 file, its not anything. The UTF-8 BOM is a different sequence of bits. If tools treat it as a BOM, that is arguably a problem. On Sat, 21 Jan 2023 at 05:09, Bill Dunlap wrote: > Setting the locale to "C" (or perhaps some other non-UTF-8 locale) will > show the

Re: [R-pkg-devel] CRAN submission struggle

2023-12-29 Thread Greg Hunt
Christaan, The elapsed time note is because CRAN expects that examples will be configured to run single threaded and some package that you use, or a package used by a package that you use is multi-threading by default and using more CPU time than clock time. If you cannot figure out how to

Re: [R-pkg-devel] Order of repo access from options("repos")

2024-03-31 Thread Greg Hunt
Dirk, Sadly I can't use localhost for all of those. 172.17.0.1 is an internal Docker IP, not the localhost address (127.0.0.1), they are there to handle two different scenarios and different ones will fail to resolve in different scenarios. Are you saying that the DNS lookup adds a timing issue

[R-pkg-devel] Order of repo access from options("repos")

2024-03-31 Thread Greg Hunt
When I set multiple repositories in options(repos=...) the order of access is providing me with some surprises as I work through some CICD issues: Given: options( repos = c( CRAN = "http://localhost:3001/proxy;, C = "http://172.17.0.1:3002;, B = "http://172.17.0.1:3001/proxy;,

Re: [R-pkg-devel] Order of repo access from options("repos")

2024-03-31 Thread Greg Hunt
er the > repositories are visited? > > > > Martin Morgan > > > > *From: *R-package-devel on behalf > of Greg Hunt > *Date: *Sunday, March 31, 2024 at 7:35 AM > *To: *Dirk Eddelbuettel > *Cc: *List r-package-devel > *Subject: *Re: [R-pkg-devel] Ord

[R-pkg-devel] Package vulnerabilities

2024-04-03 Thread Greg Hunt
Uwe, Whether it takes a lot of effort to get malicious code into a company depends on the pay-off, which can be large relative to the effort. The example of the hack before was largely interesting because the priorities of the package users were fundamentally insecure (higher version number wins,

Re: [R-pkg-devel] Order of repo access from options("repos")

2024-04-02 Thread Greg Hunt
opycats/) > > > > Jan > > > > On 01-04-2024 02:07, Greg Hunt wrote: > > Martin, Dirk, Kevin, > > Thanks for your help. To summarise: the order of access is undefined, > and > > every repo URL is accessed. I'm working in an environment > >