Re: [Bioc-devel] Replacement for CytoscapeWindowClass from devel RCy3

[Robert M. Flight]

Thanks again Alex!

Copying bioc-devel list in case anyone else has similar issues.

On Fri, Mar 30, 2018, 8:15 PM Alex Pico 
wrote:

> I think that’s correct.  A few tips based on looking at your particular
> usage…
>
> 1) cw <- CytoscapeWindow(graphName, graph=ccGraph, …)
>
> ...becomes
>
> net.suid <- createNetworkFromGraph(graph=ccGraph,title=graphName, ...)
>
> 2) You don’t need `displayGraph(cw)` anymore
>
> 3) You can simply delete `cw` from all subsequent functions. Optionally,
> you can replace it with `network=net.suid`
>
> 4) You don’t need `redraw(cw)` anymore
>
> 5) Your “Rule” functions become...
>
> setNodeTooltipMapping(nodeAtts[toolTipLoc[1]])
>
> setNodeColorMapping(‘fillcolor’, tmpCols, tmpCols, ‘d’, default.color='
> #FF’)
> # or, if you have a column of hex colors already, try this:
> setNodeColorMapping(‘fillcolor’, tmpCols, mapping.type= ‘p’,
> default.color='#FF’)
>
> setNodeShapeMapping(‘shape’, nodeShapes, nodeShapes, ‘d’, default.shape='
> ellipse' )
> # again, if you have a column of hex colors already, try this:
> setNodeShapeMapping(‘shape’, nodeShapes, mapping.type= ‘p’, default.shape=
> 'ellipse')
>
>
> Ok. Hope that helps!
>  - Alex
>
> On Mar 30, 2018, at 4:54 PM, Robert M. Flight  wrote:
>
> OK, I'll have to try out some of the examples and see if it works. In most
> of my methods it would just mean removing that part of the signature, I
> think.
>
> Robert
>
> On Fri, Mar 30, 2018, 7:44 PM Alex Pico 
> wrote:
>
>> Correct. This simplification comes at the cost of Object types. The
>> advantages, however, include avoiding a false sense of state when CyREST is
>> stateless. There was an whole class of errors and user issues based on
>> breaks between the R Object and the Cytoscape network. Now, you can even
>> restart R and pick right up in the middle of script (as far as RCy3 is
>> concerned).
>>
>> Also, since in most cases you are working with one network at a time, you
>> can actually ignore the SUID and let the default behavior (of working with
>> the “current” network) take over and greatly simplify your scripts.
>>
>>  - Alex
>>
>> On Mar 30, 2018, at 4:05 PM, Robert M. Flight 
>> wrote:
>>
>> Alex,
>>
>> That makes sense. Appreciate the info on SUID. Again this is only a
>> simple numeric though, right?? No class attribrute or formal class with it??
>>
>> I like the fact that currently my methods know they are operating on a
>> cytoscape network object, this breaks that paradigm.
>>
>> Will have to think about the best way to handle this.
>>
>> Robert
>>
>> On Fri, Mar 30, 2018, 6:50 PM Alex Pico 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Indeed, lots of changes being made in this major version bump to RCy3.
>>> The goals are to align better with the rapid development of Cytoscape’s
>>> REST API. A description of how to “upgrade” existing scripts is provided
>>> here:
>>> https://github.com/cytoscape/RCy3/wiki/Upgrading-Existing-Scripts
>>>
>>>
>>> In the case you pointed to the upgrade is not too bad (see attached):
>>>  * Replace all instances/references to CyWindow Objects with a simple
>>> numeric, the network SUID.
>>> *Note: that even this reference is now optional for all functions, i.e.,
>>> you can leave it out completely if you know that you are operating on the
>>> “current” network in Cytoscape. If you’re not sure, then this is how you
>>> specify networks now.*
>>>  * Replaced getAllEdgeAttributes with getTableColumns(‘edge’)
>>>
>>> That’s it!  If you have any more questions, please ask.
>>>
>>>  - Alex
>>>
>>> On Mar 30, 2018, at 9:13 AM, Robert M. Flight 
>>> wrote:
>>>
>>> My package, categoryCompare, is failing in Bioc devel.
>>>
>>> The reason appears to be exports in previous versions of RCy3 no longer
>>> being exported, namely the "CytoscapeWindowClass".
>>>
>>> I had some methods where behavior was defined based on being passed an
>>> object of "CytoscapeWindowClass" (see
>>> https://github.com/rmflight/categoryCompare/blob/7305185a65f80b108d50971b350c165a4e0cbe47/R/outCytoscape.r#L37
>>>  for
>>> an example).
>>>
>>> It appears this class no longer exists in the devel version of RCy3, and
>>> what is noted as a replacement for the deprecated function that created it
>>> (example being createNetworkFromGraph), has no specific class outside of
>>> returning a "function".
>>>
>>> I could use some advice on how I should modify my method signature to
>>> handle this for the next version of RCy3, or if the object returned will
>>> indeed have a "class" attached to them that can be checked via method
>>> signatures.
>>>
>>> Thanks,
>>>
>>> -Robert
>>>
>>> Robert M Flight, PhD
>>> Bioinformatics Research Associate
>>> Puller of Rabbits from Hats
>>> Research Parasite
>>> Resource Center for Stable Isotope Resolved Metabolomics
>>> Manager, Systems Biology and Omics Integration Journal Club
>>> 

Re: [Bioc-devel] Replacement for CytoscapeWindowClass from devel RCy3

[Alex Pico]

Hi Robert,

Indeed, lots of changes being made in this major version bump to RCy3. The 
goals are to align better with the rapid development of Cytoscape’s REST API. A 
description of how to “upgrade” existing scripts is provided here:
https://github.com/cytoscape/RCy3/wiki/Upgrading-Existing-Scripts 



In the case you pointed to the upgrade is not too bad (see attached):
 * Replace all instances/references to CyWindow Objects with a simple numeric, 
the network SUID. 
Note: that even this reference is now optional for all functions, i.e., 
you can leave it out completely if you know that you are operating on the 
“current” network in Cytoscape. If you’re not sure, then this is how you 
specify networks now.
 * Replaced getAllEdgeAttributes with getTableColumns(‘edge’)

That’s it!  If you have any more questions, please ask.
 - Alex

> On Mar 30, 2018, at 9:13 AM, Robert M. Flight  wrote:
> 
> My package, categoryCompare, is failing in Bioc devel.
> 
> The reason appears to be exports in previous versions of RCy3 no longer being 
> exported, namely the "CytoscapeWindowClass".
> 
> I had some methods where behavior was defined based on being passed an object 
> of "CytoscapeWindowClass" (see 
> https://github.com/rmflight/categoryCompare/blob/7305185a65f80b108d50971b350c165a4e0cbe47/R/outCytoscape.r#L37
>  
> 
>  for an example).
> 
> It appears this class no longer exists in the devel version of RCy3, and what 
> is noted as a replacement for the deprecated function that created it 
> (example being createNetworkFromGraph), has no specific class outside of 
> returning a "function".
> 
> I could use some advice on how I should modify my method signature to handle 
> this for the next version of RCy3, or if the object returned will indeed have 
> a "class" attached to them that can be checked via method signatures.
> 
> Thanks,
> 
> -Robert
> 
> Robert M Flight, PhD
> Bioinformatics Research Associate
> Puller of Rabbits from Hats
> Research Parasite
> Resource Center for Stable Isotope Resolved Metabolomics
> Manager, Systems Biology and Omics Integration Journal Club
> Markey Cancer Center
> CC434 Roach Building
> University of Kentucky
> Lexington, KY
> 
> Twitter: @rmflight
> Web: rmflight.github.io 
> ORCID: http://orcid.org/-0001-8141-7788 
> 
> EM rfligh...@gmail.com 
> PH 502-509-1827 
> 
> To call in the statistician after the experiment is done may be no more than 
> asking him to perform a post-mortem examination: he may be able to say what 
> the experiment died of. - Ronald Fisher

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

[Bioc-devel] Workflows are now in git (and other Important workflow-related changes)

[Hervé Pagès]

To the authors/maintainers of the workflows:


Following the svn-to-git migration of the software and data experiment
packages last summer, we've completed the migration of the workflow
packages.

The canonical location for the workflow source code now is
git.bioconductor.org

Please use your git client to access/maintain your workflow the same
way you would do it for a software or data-experiment package.

We've also migrated the workflows to our in-house build system.
Starting with Bioc 3.7, the build report for the devel versions of
the workflows can be found here:

  https://bioconductor.org/checkResults/devel/workflows-LATEST/

We run these builds every other day (Mondays, Wednesdays, Fridays).
Because of limited build resources, we now run the data-experiment
builds on Sundays, Tuesdays, and Thursdays only (instead of daily).

The links to the package landing pages are not working yet. This
will be addressed in the next few days.

Please address any error you see on the report for the workflow
you maintain.

Note that, from now on, we're also following the same version scheme
for these packages as for the software and data-experiment packages.
That is, we're using an even y (in x.y.z) in release and an odd y in
devel. We'll take care of bumping y at release time (like we do for
software and data-experiment packages).

After the next Bioconductor release (scheduled for May 1), we'll start
building the release versions of the workflows in addition to the
devel versions. The build report for the release versions will be here:

  https://bioconductor.org/checkResults/release/workflows-LATEST/

Finally, please note that with the latest version of BiocInstaller
(1.29.5), workflow packages can be installed with biocLite(), like
any other Bioconductor package. We'll deprecate the old mechanism
(workflowInstall()) at some point in the future.

Thanks to Andrzej, Lori, Nitesh, and Valerie for working on this
migration.

Let us know if you have any question about this.

H.


--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] appveyor CI failing with biocparam

[Marcel Ramos]

Hi Vivek,

Make sure you are using the appropriate version of R.

Your appveyor code says you're using 3.4.4.

https://ci.appveyor.com/project/vivekbhr/icetea#L22

Add a chunk like:

```
environment:
  global: ...
  matrix:
    - R_VERSION: devel

```

after your "global:" tag under the "environment:" field.

Regards,

Marcel



On 03/29/2018 02:39 PM, Vivek Bhardwaj wrote:
> Hi Martin
>
> Thanks for the quick reply. I think that would have been the real issue 
> most probably. I fixed it, though the build still failed, but this time 
> it might be due to build cache or other issues with appveyor? A unit 
> test that was fixed earlier also keeps failing on appveyor.
>
> My travis build .
> My appveyor build .
>
> I am developing on R-3.5 and Bioc3.7 on my local linux system (travis is 
> also using that for linux/mac), but our sysadmin didn't install the 
> devel version on the windows therefore I have to use the older one there 
> for testing.
>
> Thanks for the comment on biocparallel. I would try this.
>
> Best,
> Vivek
>
>
>
>
> On 03/29/2018 03:23 PM, Martin Morgan wrote:
>> Hi Vivek...
>>
>> On 03/29/2018 08:39 AM, Vivek Bhardwaj wrote:
>>> Dear All
>>>
>>> I have travis and appveyor CI running for my upcoming package in
>>> development. I find that the appveyor CI fails for the function
>>> `GenomicAlignments::summarizeOverlaps`, which is called by one of the
>>> functions in my package. It doesn't recognize the BPPARAM argument
>>> (appveyor build is here
>>> ). The same function
>>> passes on my local windows system.
>>>
>> I would guess that the underlying reason is a difference in package 
>> versions.
>>
>> I'd also guess that the problem is at 
>> https://github.com/vivekbhr/icetea/blob/master/R/detect_diffTSS.R#L125 
>> , where summarizeOverlaps hands off the BPPARAM to ResizeReads via 
>> ..., which is then passed to GenomicRanges::resize where the function 
>> is not expecting an argument named BPPARAM. Probably simply replace l 
>> 131 with
>>
>>   GenomicRanges::resize(reads, width = width, fix=fix)
>>
>> Remember that your new package will be added to the 'devel' version of 
>> Bioconductor, so you should be building and testing on R-3.5 /  Bioc 3.7.
>>
>> There seem to be several calls to bplapply in your code; it might pay 
>> to start the parallel back-end at the top of your function, as 
>> mentioned in https://support.bioconductor.org/p/107303/#107322
>>
>> Martin
>>
>>> *appveyor windows build : *
>>>
>>> R version 3.4.4 Patched (2018-03-19 r74453)
>>> Platform: i386-w64-mingw32/i386 (32-bit)
>>> Running under: Windows Server 2012 R2 x64 (build 9600)
>>>
>>> *my local windows info : *
>>>
>>> R version 3.4.3 (2017-11-30)
>>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>> Running under: Windows 7 x64 (build 7601) Service Pack 1
>>>
>>> Has anyone encountered this issue? The call to bplapply works in other
>>> functions of the package so I am not sure if this is coming directly
>>> from biocparallel.
>>>
>>>
>>> Best Wishes
>>> Vivek
>>>
>>> 
>>>
>>> *Vivek Bhardwaj*
>>> PhD Candidate | International Max Planck Research School
>>> Max Planck Institute of Immunobiology and Epigenetics
>>> Stübeweg 51, Freiburg
>>> E-mail: bhard...@ie-freiburg.mpg.de
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> This email message may contain legally privileged and/or confidential 
>> information.  If you are not the intended recipient(s), or the 
>> employee or agent responsible for the delivery of this message to the 
>> intended recipient(s), you are hereby notified that any disclosure, 
>> copying, distribution, or use of this email message is prohibited.  If 
>> you have received this message in error, please notify the sender 
>> immediately by e-mail and delete this email message from your 
>> computer. Thank you.
>



This email message may contain legally privileged and/or...{{dropped:4}}

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

Re: [Bioc-devel] Update data in data package, pcxnData

[Shepherd, Lori]

I believe this should clear up in a few days.  Because of the circular 
dependencies, it will require a few passes through the build system.


For example:


First pass:

The pcxnData package has a force install, so it will get installed even if it 
fails the build and check. The pcxn package will also fail its first pass 
through.


Second pass:

the pcxn package will find the newly installed version of the pcxnData package 
and pass.  The pcxnData package will still fail


Third pass:

pcxnData will find the newly built software package and pass as will the linux 
version of the software package.


Forth pass:

May be needed for the mac and windows versions to find the new data package.



The last update to the software package was on March 27 - which probably missed 
being pulled for the March 28th report so probably included for the March 29th 
build report

March 29th  - both fail (but there was a force install behind the scenes)

March 30th -  data package fails, but the linux version of the software package 
built and propagated

http://bioconductor.org/checkResults/3.6/bioc-LATEST/pcxn/malbec1-buildsrc.html


My guess is that by Sunday's or Monday's build reports everything will be okay.

I will keep an eye on this to make sure its the case and please let us know if 
you still are seeing issues next week.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Sokratis Kariotis 
Sent: Thursday, March 29, 2018 6:49:47 AM
To: Turaga, Nitesh
Cc: Shepherd, Lori; bioc-devel
Subject: Re: [Bioc-devel] Update data in data package, pcxnData

Hey all,

The packages' changes went through to the 3_6 branch, but since pcxn and 
pcxnData depend on each other, there are errors when they get built as they see 
the old version of the other package. In the current example: 
https://www.bioconductor.org/checkResults/3.6/bioc-LATEST/pcxn/malbec1-buildsrc.html
 , the pathCor_pathprint_v1.2.3_unadjusted_frame file is now located in the new 
pcxnData package but during build the old pcxnData is being used and the error 
occurs since the file is not there. I have checked both packages locally and 
they work when both are in their updated form. How can we bypass this? Thanks.

Cheers,
Sokratis

On 27 March 2018 at 14:02, Sokratis Kariotis 
> wrote:
Hey all,

Thanks for the advice. I managed to fix the problem of no permissions! My 
windows machine, after an update, changed the paths to my github keys and had 
to reposition them.  I have now succesfully pushed in both master and 
RELEASE_3_6 branches.

Cheers,
Sokratis

On 26 March 2018 at 15:47, Turaga, Nitesh 
> wrote:
Hi Sokratis,

Your key(s) on file is

ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCmaqfMSKr3AtAPpMz5m4pITFaq6AVp+v8ABp7FfTvcirdZz834ECUsnlsvkLZL2uWtelNo7TFgaIo0Jfi21IDSZ3R0Oyl49vsYXqHAB9CtH3yItiaddq+nLG4s+jnlAftWyQOFa/02LyYwBvEnuacLxxZimveZ6VywBF9Q7pz3v+pGXZb9LDmK9khr6RvO+mRcD7dJyFt1CySEbxVZj/TKHwn4Vs9lQIISxeeKo9ypxFzW8YDzmACLga7u2BVX622/UjrrXanZhmNWcEEgxw3B8rgzDZi2YcwbBG3RqXncE29a6gEvsjqJbUh5jIyk9cLunUjQpVwqrnlHXcRGjkLB

ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC9G4NrGqxmHJj26MBW4A2EJLCD8z+QV5fRehTPiNzwHztQiJzj8Kakesk8FcfZt1Y3cPZRhwzyuwxiZQRrB1qidg6nFfLwjHBi24xLo9RWQBxTfgCDWyUKb5WLFZn6wQWhWp10ooRz0oGX9Syh6rw+rCiHiFwE+CxTWjELwlASiuDUa/599MBe7Q2mMVmtP4QXFyaOGsq46I16k80Ta0YzM1bbIZlY+YFbmw8GhDrZ//z+2FJ241AR4nuTx8QJ6fXLMnfo8IgZtDxJYw3G24ZduP93Q47ptl4u5IElZzEceXN53VD1WQkphk4+SDr24Fm4qkYkQ2s5VaPk6Yh3oXYd

ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC7QB8rwK1n7/cD5rfDoZe/uSVGVqkBCHOEbfReiEt8dQCx1KqrjPFRv2geTDkhmQpSmVSWxKbrmbgMmogGQZykKmT2CybrGQZavOgwsFNzvkJYW8InfQ6eO09ovHKxW8u/kPBxuR8tUQAqWLaMVDp0UZseC79zqMAZRVOxvy4Esa5E/gIPDPrrhAVraTTqZjLGKOvii2WnInYZP4oR2KsBck5sIdYUFIdkDU73oHbTlvTl8ic7s5uiW94+VM5Cj8oi5sZtQKptdLK8cQWGerCcYj/ZzlvMpn1wXKbmGYiGVWDZy5qtO42UsW5EIVb1QlGXh//ppBJRnZ9ORSZahFsf

ssh-rsa 
B3NzaC1yc2EDAQABAAACAQDdEiGtAz6nXBAaGbUCLQFMWYE9mKRtKf+20GTGAt83aM7uMpIH9fiHIFpe+5ghm3+68fKVTuprG2PYosiy3Nvk79/WZ02IZuYGfFHXEIhsa1aIVMNsofvOrwBhFezbvoZ3b9oPakFbQFiAtjPkN6h4drr+iQq4to4jc5wvYw07uqIEEG8nZfiB+QWa5s+rplTS3zJZzr7xpEDT/7ZHpKVduZUg34tzaN4+vONgofgOthUMWArO3oO69wPwAdoAUACRmXT02xknrcWZm4UtuhzT98FHLznSowZMLG3jm8vKgsgbH8UGGtz478UZW5xE4qS5LHiKJbcZFBCLFABUjCajuYF3z+bZF0cxbT9d+25kpp/p89lvljsvlE7vbxdqFmeobGSQ6ftDq5btdEHfD2rc++iWEZgmOGjcHtDxUem3nNGCOYtDkPAIKES5oCCtlD9sBL5gLFHTkl3KyxNdIsH9j0iNFdJmEHySZh2ePdrqG7ZE/FOKf77XTX+acqgydF+Dsep16lTIxk94MXLk7Sz2v8XQqFtETa5q0Gkm70Ok/qht/O80nWUT3QX44sPM4ivPckOHwnZjywpZyBONas26hP0M1pZSEvB5qLCMKyD4YmTJ5aZkeCHh6wsW7CDZvNJl7dWyn2kxrxgin4nhqSrDryEYl3qYZxwOG0XzfHGVfQ==

Are you sure you are using a private key which corresponds to any of these 
public keys? I�d start with that.

Best

Nitesh


> On Mar 23, 2018, at 8:20 AM, Sokratis Kariotis 

Re: [Rd] Base R examples that write to current working directory

[Henrik Bengtsson]

So, the proposal would then be to write to tempdir(), correct?  If so,
I see three alternatives:

1. explicitly use file.path(tempdir(), filename), or tempfile() everywhere.

2. wrap example code in a withTempDir({ ... }) call.

3. Add an 'eval.path' (*) argument to example() and make it default to
eval.path = tempdir(). This would probably be backward compatible and
keep the code example clean.  The downside is when a user runs an
example and can't locate produced files. (*) or 'wd', 'workdir', ...

/Henrik

On Fri, Mar 30, 2018 at 9:25 AM, Uwe Ligges
 wrote:
>
>
> On 30.03.2018 00:08, Duncan Murdoch wrote:
>>
>> On 29/03/2018 5:23 PM, Hadley Wickham wrote:
>>>
>>> Hi all,
>>>
>>> Given the recent CRAN push to prevent examples writing to the working
>>> directory, is there any interest in fixing base R examples that write
>>> to the working directory? A few candidates are the graphics devices,
>>> file.create(), writeBin(), writeChar(), write(), and saveRDS(). I'm
>>> sure there are many more.
>>>
>>> One way to catch these naughty examples would be to search for
>>> unlink() in examples: e.g.,
>>>
>>> https://github.com/wch/r-source/search?utf8=✓=unlink+extension%3ARd=.
>>> Of course, simply cleaning up after yourself is not sufficient because
>>> if those files existed before the examples were run, the examples will
>>> destroy them.
>>>
>>
>> Why not put together a patch that fixes these?  This doesn't seem to be
>> something that needs discussion, fixing the bad examples would be a good
>> idea.
>
>
> Seconded. CRAN would not accept these base packages, hence we should
> urgently give better examples.
>
> Best,
> Uwe
>
>
>
>> Duncan Murdoch
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Base R examples that write to current working directory

[Uwe Ligges]

On 30.03.2018 00:08, Duncan Murdoch wrote:

On 29/03/2018 5:23 PM, Hadley Wickham wrote:

Hi all,

Given the recent CRAN push to prevent examples writing to the working
directory, is there any interest in fixing base R examples that write
to the working directory? A few candidates are the graphics devices,
file.create(), writeBin(), writeChar(), write(), and saveRDS(). I'm
sure there are many more.

One way to catch these naughty examples would be to search for
unlink() in examples: e.g.,
https://github.com/wch/r-source/search?utf8=✓=unlink+extension%3ARd=. 


Of course, simply cleaning up after yourself is not sufficient because
if those files existed before the examples were run, the examples will
destroy them.



Why not put together a patch that fixes these?  This doesn't seem to be 
something that needs discussion, fixing the bad examples would be a good 
idea.


Seconded. CRAN would not accept these base packages, hence we should 
urgently give better examples.


Best,
Uwe



Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Bioc-devel] Replacement for CytoscapeWindowClass from devel RCy3

[Robert M. Flight]

My package, categoryCompare, is failing in Bioc devel.

The reason appears to be exports in previous versions of RCy3 no longer
being exported, namely the "CytoscapeWindowClass".

I had some methods where behavior was defined based on being passed an
object of "CytoscapeWindowClass" (see
https://github.com/rmflight/categoryCompare/blob/7305185a65f80b108d50971b350c165a4e0cbe47/R/outCytoscape.r#L37
for
an example).

It appears this class no longer exists in the devel version of RCy3, and
what is noted as a replacement for the deprecated function that created it
(example being createNetworkFromGraph), has no specific class outside of
returning a "function".

I could use some advice on how I should modify my method signature to
handle this for the next version of RCy3, or if the object returned will
indeed have a "class" attached to them that can be checked via method
signatures.

Thanks,

-Robert

Robert M Flight, PhD
Bioinformatics Research Associate
Puller of Rabbits from Hats
Research Parasite
Resource Center for Stable Isotope Resolved Metabolomics
Manager, Systems Biology and Omics Integration Journal Club
Markey Cancer Center
CC434 Roach Building
University of Kentucky
Lexington, KY

Twitter: @rmflight
Web: rmflight.github.io
ORCID: http://orcid.org/-0001-8141-7788
EM rfligh...@gmail.com
PH 502-509-1827 <(502)%20509-1827>

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. - Ronald Fisher

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] vignette problems

[Martin Morgan]

On 03/29/2018 01:07 PM, campos wrote:

Dear bioc-devel team,

I have made some changes in the package STAN and although it seems to 
install correctly, I have problems with timeout and error in windows... 
Could someone help me to improve the time?


https://bioconductor.org/checkResults/3.7/bioc-LATEST/STAN/


it looks like, with your most recent commit (at the top of the page, 
'Snapshot Date', 'Last Commit', 'Last Changed Date'), the package built 
on Windows and Linux.


There is a segfault on Mac, which is likely a programming error in your 
C code. It could be debugged perhaps using valgrind or similar tools, 
but the first step would be to isolate the code to something more easily 
reproduced than the full vignette. It would also help to clean up the C 
code so that it compiles without warnings with the -Wall -pedantic flags


Martin



Best,

Rafael


On 28.03.2018 01:08, Martin Morgan wrote:
When I try and install the version on the master branch of the 
Bioconductor git repository I get


STAN master$ Rdev --vanilla CMD INSTALL .
* installing to library ‘/home/mtmorgan/R/x86_64-pc-linux-gnu-library
...
** testing if installed package can be loaded
Error: package or namespace load failed for 'STAN' in 
namespaceExport(ns, exports):

 undefined exports: viterbi2Gviz


This comes about in a rather interesting way because the body of 
plotViterbi is not defined


plotViterbi <- function(viterbi, regions, gen, chrom, from, to, 
statecols, col)


#'
...

Can you please commit a version of the package that installs?

Martin

On 03/27/2018 06:42 PM, campos wrote:

Dear bioc-devel team,

I am developing the STAN packages and I am running into problems when 
trying to build my package. The problem is the following:


Error in vignette_type(Outfile) :
   Vignette product 'STAN.tex' does not have a known filename 
extension ('NA')

ERROR: installing vignettes failed
* removing '/tmp/Rtmp925Iru/Rinst63471ff1efdc/STAN'
I tried to build the package in old versions (which they used to 
work) and I run in other problems but in this case is:


Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = 
quiet,  :

   Running 'texi2dvi' on 'STAN.tex' failed.
LaTeX errors:
! LaTeX Error: File `beramono.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Could you help me with this problem?

Thank you very much,

Rafael

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



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the 
employee or agent responsible for the delivery of this message to the 
intended recipient(s), you are hereby notified that any disclosure, 
copying, distribution, or use of this email message is prohibited.  If 
you have received this message in error, please notify the sender 
immediately by e-mail and delete this email message from your 
computer. Thank you.





This email message may contain legally privileged and/or...{{dropped:2}}

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