date:20221010

Re: [Bioc-devel] Version number trouble

2022-10-10 Thread Brüggemann , Mirko

Hi Vincent,

thanks for the clarification. I can now see where I went wrong. I’ve dumped the 
version number from 1.3.0 to 1.3.1 now.

Thanks a lot
Mirko



Von: Vincent Carey 
Datum: Montag, 10. Oktober 2022 um 18:26
An: "Brüggemann, Mirko" 
Cc: "bioc-devel@r-project.org" 
Betreff: Re: [Bioc-devel] Version number trouble

Hi Mirko -- the devel branch has an odd y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES$ cd BindingSiteFinder
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.3.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git fetch --all
Fetching origin

The current release branch has an even y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git checkout 
RELEASE_3_15
Branch 'RELEASE_3_15' set up to track remote branch 'RELEASE_3_15' from 
'origin'.
Switched to a new branch 'RELEASE_3_15'
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.2.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git remote -v
origin g...@git.bioconductor.org:packages/BindingSiteFinder (fetch)
origin g...@git.bioconductor.org:packages/BindingSiteFinder (push)

By managing the current checkout you can make changes in a selected branch,
incrementing z in x.y.z in the associated DESCRIPTION file as necessary

Full details at https://contributions.bioconductor.org/git-version-control.html

On Mon, Oct 10, 2022 at 12:19 PM Brüggemann, Mirko 
mailto:mirko.brueggem...@bmls.de>> wrote:
Hello,

I’m having some troubles updating my package(BindingSiteFinder) on the devel 
branch.

I’ve made some changes to the code and as always incremented the z part of the 
version number. Then I realized that the y part of the version number was 
already changed by the Bioconductor team (to 1.3.0). I guess in preparation for 
the new release. So, I left the version number like this, to not mess things up.

Now my package does compile without errors or warnings, but my changes do not 
show on the devel landing page. Also, I still want to push some more changes 
prior to the upcoming release.

My question is how do I properly set the version numbers here? Do I keep it 
with the y part set to the new release and then increment the z part (so 1.3.0 
to 1.3.1?), or do I go back to the lates version number? Since I did not push 
any changes in the last cycle it would then be 1.2.1. And if I do will the 
package still build in the new release?

Maybe someone knows what to do here?

Thanks a lot in advance
Mirko

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Issue with a package dependent on rJava

2022-10-10 Thread Hervé Pagès


Thanks Anestis for your analysis and detailed feedback.

@J. Aravind: I hope this is helpful. You should be able to reproduce the 
problem with a recent version of Java. Generally speaking you want to 
make sure that your package is compatible with reasonably recent 
versions of Java. FWIW here are the versions of Java installed on the 
Bioconductor build machines:


-- Devel builds --

  nebbiolo2:

    biocbuild@nebbiolo2:~$ java --version
    openjdk 11.0.16 2022-07-19
    OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu120.04)
    OpenJDK 64-Bit Server VM (build 
11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, sharing)


  palomino4:

    PS C:\Users\hpages> java --version
    java 17.0.1 2021-10-19 LTS
    Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39)
    Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed 
mode, sharing)


  lconway:

    lconway:~ biocbuild$ java --version
    openjdk 18 2022-03-22
    OpenJDK Runtime Environment (build 18+36-2087)
    OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)

-- Release builds --

  nebbiolo1:

    biocbuild@nebbiolo1:~$ java --version
    openjdk 11.0.16 2022-07-19
    OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu120.04)
    OpenJDK 64-Bit Server VM (build 
11.0.16+8-post-Ubuntu-0ubuntu120.04, mixed mode, sharing)


  palomino3:

    PS C:\Users\hpages> java --version
    java 17.0.1 2021-10-19 LTS
    Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39)
    Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed 
mode, sharing)


  merida1

    merida1:~ biocbuild$ java --version
    openjdk 14.0.1 2020-04-14
    OpenJDK Runtime Environment (build 14.0.1+7)
    OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

Cheers,

H.

On 09/10/2022 17:02, Anestis Gkanogiannis via Bioc-devel wrote:

Hello,

On line 1289 of melting.R you call the keyset() method of opts_melt (which is a 
HashMap).
This method in Java until 11, return a private AbstractSet (KeySet).
On line 1290 of melting.R you call iterator() method of the KeySet object you 
got on the previous line.

Problem is that this KeySet is private and this call through reflexion isn’t 
valid, hence the exception.

They changed this in java 11 where the returned AbstractSet is public.

So solution is either use java >11
or change your code in melting.R to not call the iterator() method of keyset 
(which is a private AbstractSet).

Best regards,

Anestis Gkanogiannis, PhD
--
https://linkedin.com/in/anestis-gkanogiannis
https://github.com/gkanogiannis
https://www.gkanogiannis.com

-Original Message-
From: Bioc-devel  On Behalf Of DR J Aravind 
via Bioc-devel
Sent: 10 October 2022 00:33
To: bioc-devel@r-project.org
Cc: Aravind J (aravind...@yahoo.com) 
Subject: [Bioc-devel] Issue with a package dependent on rJava

Dear Bioconductor Developers,


My package  `rmelting` is failing to build on release (3.15) and devel (3.16) 
versions for the following systems.

Bioconductor 3.15
- palomino3 (Windows Server 2022 Datacenter / x64)

Bioconductor 3.15
- palomino4 (Windows Server 2022 Datacenter / x64)
- lconway (macOS 12.5.1 Monterey / x86_64)

The error message is as follows.

```
* creating vignettes ... ERROR
--- re-building 'Tutorial.Rmd' using rmarkdown_notangle
.
.
.
.
.

Quitting from lines 195-197 (Tutorial.Rmd)

Error: processing vignette 'Tutorial.Rmd' failed with diagnostics:

java.lang.IllegalAccessException: class RJavaTools cannot access a member of class 
java.util.HashMap$KeySet (in module java.base) with modifiers "public final"

--- failed re-building 'Tutorial.Rmd'



SUMMARY: processing the following file failed:

   'Tutorial.Rmd'
```

I am unable to replicate the same on my end.

It seems to be an issue with java. The package is a low level interface to a 
software written in Java 1.5 using `rJava`. I have tried with different java 
versions upto 1.8.

Any pointers or suggestions to fix the same will be appreciated.


Best Regards,

J. Aravind

Scientist
ICAR-National Bureau of Plant Genetic Resources
New Delhi, India









“SAVE TREE - Please do not print this e-mail unless necessary.”
Disclaimer: The information contained in this electronic message and /or 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain confidential, proprietary or privileged 
information. If you are not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the information contained in this 
e-mail message and/or attachments to it are strictly prohibited. If you have 
received this communication in error, please notify us by reply e-mail or 
telephone and immediately destroy all copies of this message and any 
attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The 
organization accepts no liability for any

Re: [Bioc-devel] Version number trouble

2022-10-10 Thread Vincent Carey

Hi Mirko -- the devel branch has an odd y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES$ cd BindingSiteFinder
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.3.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git fetch --all
Fetching origin

The current release branch has an even y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git checkout
RELEASE_3_15
Branch 'RELEASE_3_15' set up to track remote branch 'RELEASE_3_15' from
'origin'.
Switched to a new branch 'RELEASE_3_15'
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.2.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git remote -v
origin g...@git.bioconductor.org:packages/BindingSiteFinder (fetch)
origin g...@git.bioconductor.org:packages/BindingSiteFinder (push)

By managing the current checkout you can make changes in a selected branch,
incrementing z in x.y.z in the associated DESCRIPTION file as necessary

Full details at
https://contributions.bioconductor.org/git-version-control.html

On Mon, Oct 10, 2022 at 12:19 PM Brüggemann, Mirko <
mirko.brueggem...@bmls.de> wrote:

> Hello,
>
> I’m having some troubles updating my package(BindingSiteFinder) on the
> devel branch.
>
> I’ve made some changes to the code and as always incremented the z part of
> the version number. Then I realized that the y part of the version number
> was already changed by the Bioconductor team (to 1.3.0). I guess in
> preparation for the new release. So, I left the version number like this,
> to not mess things up.
>
> Now my package does compile without errors or warnings, but my changes do
> not show on the devel landing page. Also, I still want to push some more
> changes prior to the upcoming release.
>
> My question is how do I properly set the version numbers here? Do I keep
> it with the y part set to the new release and then increment the z part (so
> 1.3.0 to 1.3.1?), or do I go back to the lates version number? Since I did
> not push any changes in the last cycle it would then be 1.2.1. And if I do
> will the package still build in the new release?
>
> Maybe someone knows what to do here?
>
> Thanks a lot in advance
> Mirko
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Version number trouble

2022-10-10 Thread Brüggemann , Mirko

Hello,

I’m having some troubles updating my package(BindingSiteFinder) on the devel 
branch.

I’ve made some changes to the code and as always incremented the z part of the 
version number. Then I realized that the y part of the version number was 
already changed by the Bioconductor team (to 1.3.0). I guess in preparation for 
the new release. So, I left the version number like this, to not mess things up.

Now my package does compile without errors or warnings, but my changes do not 
show on the devel landing page. Also, I still want to push some more changes 
prior to the upcoming release.

My question is how do I properly set the version numbers here? Do I keep it 
with the y part set to the new release and then increment the z part (so 1.3.0 
to 1.3.1?), or do I go back to the lates version number? Since I did not push 
any changes in the last cycle it would then be 1.2.1. And if I do will the 
package still build in the new release?

Maybe someone knows what to do here?

Thanks a lot in advance
Mirko

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Interpreting BiocCheck output

2022-10-10 Thread Sergio Oller

Hi Giulia, hi all

I often run BiocCheck::BiocCheck() on my packages and end up with errors,
warnings and notes that have not printed specific enough messages, just as
you did.

When that happens, on the same R terminal, I use:

BiocCheck::.BiocCheck$error
BiocCheck::.BiocCheck$warning
BiocCheck::.BiocCheck$note

(please note the leading dot after the double colon)

Those three lists include more specific details. Often even the file names
and line numbers where the error occurred (In my experience I've found line
numbers to not be always perfectly accurate, but it's a good enough
approximation).

There may be a better way to get that information through some BiocCheck
log or other reporting facility, but that's convenient enough for me. I
hope this helps you.

Best
Sergio


El dv., 7 d’oct. 2022, 21:49, Henrik Bengtsson 
va escriure:

> I'm throwing in another 1 cent.
>
> I agree that utils::globalVariables() is risky; since it goes in the
> root of the package code, it applies to *all* functions in the
> package, which is a bit too broad of a stroke for my taste.  The way I
> deal with false globals from non-standard evaluation (NSE), is to
> declare them a as dummy variables local to the function.  In this pl
> case, I would use:
>
> myfcn <- function() {
>   ## To please R CMD check
>   mpg <- cyl <- NULL
>
>   mtcars |> select(mpg, cyl) |> head(3)
> }
>
>
> ADVANCED:
>
> To avoid those dummy assignments from taking place in every call, one
> can also do:
>
> myfcn <- local({
>   ## To please R CMD check
>   mpg <- cyl <- NULL
>
>   function() {
> mtcars |> select(mpg, cyl) |> head(3)
>   }
> })
>
> which is also a bit cleaner, because it keeps the original function body
> as-is.
>
>
> REALLY ADVANCED:
> If you want to be fancy, you can even protect against mistakes by using:
>
> myfcn <- local({
>   ## To please R CMD check
>   mpg <- cyl <- NULL
>
>   ## Prevent developer mistakes
>   lapply(names(environment()), function(name, envir) {
> delayedAssign(
>   name,
>   stop(sprintf("INTERNAL ERROR: %s is not declared",
> sQuote(name)), call. = FALSE),
>   assign.env = envir
> )
>   }, envir = environment())
>
>   function() {
> mtcars |> select(mpg, cyl) |> head(3)
>   }
> })
>
> The latter would throw an error, if you actually end up using 'mpg' or
> 'cyl' in a non-NSE way.
>
> /Henrik
>
> On Fri, Oct 7, 2022 at 12:29 PM Martin Morgan 
> wrote:
> >
> > Just my two cents, but I don’t think using `globalVariables()` is a good
> idea in a package – it’s too easy to say that R should ignore a variable
> that it should not.
> >
> > In the context of dplyr, the alternative is to `importFrom dplyr .data`
> or to use ‘standard’ evaluation, depending on circumstance
> >
> >
> > > mtcars |> as_tibble() |> filter(.data$mpg > 30)  # .data is imported,
> so known…
> > # A tibble: 4 × 11
> > mpg   cyl  disphp  dratwt  qsecvsam  gear  carb
> > 
> > 1  32.4 4  78.766  4.08  2.2   19.5 1 1 4 1
> > 2  30.4 4  75.752  4.93  1.62  18.5 1 1 4 2
> > 3  33.9 4  71.165  4.22  1.84  19.9 1 1 4 1
> > 4  30.4 4  95.1   113  3.77  1.51  16.9 1 1 5 2
> > > mtcars |> select("mpg", "cyl") |> head(3)  # `”mpg”` and `”cyl”` are
> character vectors, not symbols…
> >mpg cyl
> > Mazda RX4 21.0   6
> > Mazda RX4 Wag 21.0   6
> > Datsun 71022.8   4
> >
> > Martin
> >
> > From: Bioc-devel  on behalf of Marcel
> Ramos 
> > Date: Friday, October 7, 2022 at 3:07 PM
> > To: bioc-devel@r-project.org 
> > Subject: Re: [Bioc-devel] Interpreting BiocCheck output
> > Hi Giulia,
> >
> > Thanks for sharing.
> > I took a look at https://github.com/calabrialab/ISAnalytics and I'm glad
> > you resolved the issue.
> >
> > Just a reminder, you can also use `utils::globalVariables('.')` in your
> > package for functions
> > that use `'.'` (and other symbols) as a variable, e.g. in `purrr::pmap`.
> >
> > Best regards,
> >
> > Marcel
> >
> >
> > On 10/6/22 4:34 AM, Giulia Pais wrote:
> > >
> > > Hi, thanks for the reply. I managed to fix the first error as it was a
> > > minor issue in the code, while for the second one I don’t have a
> > > solution since the problem appears only locally and not on Biconductor
> > > after the build.
> > >
> > > Just for reference the package is ISAnalytics and the BiocCheck
> > > version is the latest one.
> > >
> > > Thanks again,
> > >
> > > Giulia
> > >
> > > *From: *Bioc-devel  on behalf of
> > > Marcel Ramos 
> > > *Date: *Wednesday, 2022October5 at 23:48
> > > *To: *bioc-devel@r-project.org 
> > > *Subject: *Re: [Bioc-devel] EXTERNAL: Interpreting BiocCheck output
> > >
> > > Hi Giulia,
> > >
> > > Are you using a recent version of BiocCheck?
> > >
> > > If so, check the bottom of the BiocCheck::BiocCheck():
> > >
> > > ---
> > > See the .BiocCheck folder and run
> > >  browseVignettes(package = 'BiocCheck')
> > > for details.
> > > ---
> >

Re: [Bioc-devel] Version number trouble

Re: [Bioc-devel] Issue with a package dependent on rJava

Re: [Bioc-devel] Version number trouble

[Bioc-devel] Version number trouble

Re: [Bioc-devel] Interpreting BiocCheck output

5 matches

Site Navigation

Mail list logo

Footer information