Discussion:
[Gmod-gbrowse] Subroutine for bgcolor
Vaneet Lotay
2017-03-28 18:26:50 UTC
Permalink
Hello,

I can't get the subroutine to work for dynamically calculating bgcolor. At first I thought I was not correctly accessing the right attributes of the 'feature' but those same attribute calls (ex: $feature->type) seem to work fine if I use them in a subroutine for 'balloon click'. Here's my code for the bgcolor part of my stanza:

..
bgcolor = sub {
my $f = shift;
my $type = $f->type;
if($type =~ /Enhancer/){
return "green";
} elsif($type =~ /Suppressor/){
return "red";
} else{
return = "black";
}
}

I even tried just having a single line in my subroutine that just returns a color but it still doesn't work which leads me to believe that subroutines are just not accepted anymore for the bgcolor attribute?

Looking at an old post for this issue, someone suggesting trying a perl module reference call like this:

bgcolor = \&Colors::bgcolor;

I tried that and wrote code within 'Colors.pm' but still nothing, it always seems to default to cyan color no matter what code I write in.

All I want to do is have the ability to change colors of different segment types (column 3) in a GFF3 file or according to any other attribute of GFF3 file if need be, please let me know if there's a better way to do this.

Thanks,

Vaneet


Vaneet Lotay

Xenbase Bioinformatician

403-220-6652

724 ICT Building - University of Calgary

2500 University Drive NW

Calgary AB T2N 1N4

CANADA
Scott Cain
2017-03-29 15:28:58 UTC
Permalink
Hi Vaneet,

The tricky thing about bgcolor callbacks (if I'm remembering this
correctly) is that it is the subpart's type that get's passed in, so if
your enhancers and suppressors have subparts, you need to put those in the
regex for assigning color. That's one reason one you'd get one result when
using the same callback in a balloon versus bgcolor.

I'm not sure that this is part of the problem though, since failure to
match should return black, but you've indicated that you're getting cyan
features instead. Double check that you don't have another bgcolor entry
in the same stanza that might be overriding your callback (you laugh, but
I've done that very thing more than once!).

Good luck,
Scott
Post by Vaneet Lotay
Hello,
I can’t get the subroutine to work for dynamically calculating bgcolor.
At first I thought I was not correctly accessing the right attributes of
the ‘feature’ but those same attribute calls (ex: $feature->type) seem to
work fine if I use them in a subroutine for ‘balloon click’. Here’s my code
..
bgcolor = sub {
my $f = shift;
my $type = $f->type;
if($type =~ /Enhancer/){
return “green”;
} elsif($type =~ /Suppressor/){
return “red”;
} else{
return = “black”;
}
}
I even tried just having a single line in my subroutine that just returns
a color but it still doesn’t work which leads me to believe that
subroutines are just not accepted anymore for the bgcolor attribute?
Looking at an old post for this issue, someone suggesting trying a perl
bgcolor = \&Colors::bgcolor;
I tried that and wrote code within ‘Colors.pm’ but still nothing, it
always seems to default to cyan color no matter what code I write in.
All I want to do is have the ability to change colors of different segment
types (column 3) in a GFF3 file or according to any other attribute of GFF3
file if need be, please let me know if there’s a better way to do this.
Thanks,
Vaneet
*Vaneet Lotay*
*Xenbase Bioinformatician*
*403-220-6652 <(403)%20220-6652>*
*724 ICT Building - University of Calgary*
*2500 University Drive NW*
*Calgary AB T2N 1N4*
*CANADA*
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gmod-gbrowse mailing list
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
--
------------------------------------------------------------------------
Scott Cain, Ph. D. scott at scottcain dot
net
GMOD Coordinator (http://gmod.org/) 216-392-3087
Ontario Institute for Cancer Research
Barris, Wes
2017-03-29 17:24:27 UTC
Permalink
Hi Vaneet,

I used perl callbacks to set the bgcolor attribute. In my case I use feature->name and feature->ref. One thing I noticed in your callback is a syntax error on this line:

return = “black”;

Should be:

return “black”;
--
Wes Barris

From: Scott Cain [mailto:***@scottcain.net]
Sent: Wednesday, March 29, 2017 10:29 AM
To: Vaneet Lotay <***@ucalgary.ca>
Cc: gmod-***@lists.sourceforge.net
Subject: Re: [Gmod-gbrowse] Subroutine for bgcolor

Hi Vaneet,

The tricky thing about bgcolor callbacks (if I'm remembering this correctly) is that it is the subpart's type that get's passed in, so if your enhancers and suppressors have subparts, you need to put those in the regex for assigning color. That's one reason one you'd get one result when using the same callback in a balloon versus bgcolor.

I'm not sure that this is part of the problem though, since failure to match should return black, but you've indicated that you're getting cyan features instead. Double check that you don't have another bgcolor entry in the same stanza that might be overriding your callback (you laugh, but I've done that very thing more than once!).

Good luck,
Scott


On Tue, Mar 28, 2017 at 2:26 PM, Vaneet Lotay <***@ucalgary.ca<mailto:***@ucalgary.ca>> wrote:
Hello,

I can’t get the subroutine to work for dynamically calculating bgcolor. At first I thought I was not correctly accessing the right attributes of the ‘feature’ but those same attribute calls (ex: $feature->type) seem to work fine if I use them in a subroutine for ‘balloon click’. Here’s my code for the bgcolor part of my stanza:

..
bgcolor = sub {
my $f = shift;
my $type = $f->type;
if($type =~ /Enhancer/){
return “green”;
} elsif($type =~ /Suppressor/){
return “red”;
} else{
return = “black”;
}
}

I even tried just having a single line in my subroutine that just returns a color but it still doesn’t work which leads me to believe that subroutines are just not accepted anymore for the bgcolor attribute?

Looking at an old post for this issue, someone suggesting trying a perl module reference call like this:

bgcolor = \&Colors::bgcolor;

I tried that and wrote code within ‘Colors.pm’ but still nothing, it always seems to default to cyan color no matter what code I write in.

All I want to do is have the ability to change colors of different segment types (column 3) in a GFF3 file or according to any other attribute of GFF3 file if need be, please let me know if there’s a better way to do this.

Thanks,

Vaneet


Vaneet Lotay

Xenbase Bioinformatician

403-220-6652<tel:(403)%20220-6652>

724 ICT Building - University of Calgary

2500 University Drive NW

Calgary AB T2N 1N4

CANADA


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=gtiDJ8ywfSDe1jUVU6_S2WXFMuC7hU3l46YRCTTLZ7g&e=>
_______________________________________________
Gmod-gbrowse mailing list
Gmod-***@lists.sourceforge.net<mailto:Gmod-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_gmod-2Dgbrowse&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=cfFkJzXkID4H6w42yKtUU4zOyhbQWf2SjNceqNLAHD4&e=>
--
------------------------------------------------------------------------
Scott Cain, Ph. D. scott at scottcain dot net
GMOD Coordinator (http://gmod.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__gmod.org_&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=j3YfOx-CN2oERoWamnjR9D37hUjqOJlXlI-k4N158V4&e=>) 216-392-3087
Ontario Institute for Cancer Research

This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Cobb-Vantress, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Barris, Wes
2017-03-29 18:01:31 UTC
Permalink
Hi Vaneet,

I too have bgcolor set to a default color in the [TRACK DEFAULTS] section. That does not prevent me from setting the bgcolor in a stanza below using a perl callback. Here is one of my callbacks:

bgcolor = sub {
my $feature = shift;
my $name = $feature->name;
my $ref = $feature->ref;
my $start = $feature->start;
my @notes = $feature->attributes('Note');
my $color = 'blue';
if ($notes[1] ne $ref) {
$color = 'red';
}
elsif ($name =~ /\.\d$/) {
$color = 'orange';
}
return $color;
}

I would start simple and use a callback like this:

bgcolor = sub {
return ‘red’;
}

Once you have that working add to it. I use a different method from you for referring to callbacks inside of an init_code module. Before using a separate module, get something simple working.
--
Wes Barris

From: Vaneet Lotay [mailto:***@ucalgary.ca]
Sent: Wednesday, March 29, 2017 12:50 PM
To: Barris, Wes <***@cobb-vantress.com>; 'Scott Cain' <***@scottcain.net>
Cc: 'gmod-***@lists.sourceforge.net' <gmod-***@lists.sourceforge.net>
Subject: RE: [Gmod-gbrowse] Subroutine for bgcolor

Hi Scott, Wes and others

Scott, there are no subparts to the ‘Enhancers’ and ‘Suppressors’, I’m basically using this as a test to see if I can identify different elements with different colors. The relevant part of my GFF3 is this:

scaffold_1 XB2 Motif_Instance 126648 140661 42.764411 + . Name=Motif_Instance_1
scaffold_1 XB2 Enhancer 153650 173663 42.071263 + . Name=Motif_Instance_2
scaffold_1 XB2 Motif_Instance 205528 215541 42.807583 - . Name=Motif_Instance_5
scaffold_1 XB2 Suppressor 225950 245963 44.599342 - . Name=Motif_Instance_6
scaffold_1 XB2 Motif_Instance 253750 253763 42.639247 - . Name=Motif_Instance_7
scaffold_1 XB2 Motif_Instance 254838 254851 43.500730 + . Name=Motif_Instance_8
scaffold_1 XB2 Motif_Instance 303684 319697 44.599342 + . Name=Motif_Instance_9
scaffold_1 XB2 Enhancer 325836 355849 42.764411 + . Name=Motif_Instance_10
scaffold_1 XB2 Motif_Instance 329217 329230 43.863023 - . Name=Motif_Instance_11

This is just a test file I’m using but the real file will be very similar to this I just wanted to test the colors.

Here’s the code I use in my callback Perl module, very simple
.just to see if it could work:

sub bgcolor {
return "blue";
}
1;

No errors in my log, it just doesn’t work. No it’s showing white color instead of cyan before which is weird.

Well I have defaults earlier in the configuration file which set bgcolor to light grey in [TRACK DEFAULTS] but that shouldn’t interfere with me overwriting the bgcolor attribute for each track, nevertheless I tried commenting it out but no change.

Wes I understand the syntax error on my final ‘return’ line, I corrected it but I would assume that would have given me an error in the logs? In fact I purposely put errors in my Perl subroutine for bgcolor and still no errors in the logs, it’s as if the code is not even being read, so I’m confused.

I even tried a callback to code inserted in the ‘General’ section of the configuration file like this:

init_code = sub calc_color{
return “green”;
}

Referenced it like this:

bgcolor = \&calc_color

Still didn’t work. Again if I purposely introduce a syntax error by misspelling the method name, it doesn’t give me an error in the logs. I can still successfully set the bgcolor the traditional way though (ex: bgcolor = red), so it’s not as if I have the wrong configuration file.

Please help if you’ve run into this issue and know how to resolve it.

Thanks,

Vaneet


Vaneet Lotay

Xenbase Bioinformatician

716 ICT Building - University of Calgary

2500 University Drive NW

Calgary AB T2N 1N4

CANADA

From: Barris, Wes [mailto:***@cobb-vantress.com]
Sent: Wednesday, March 29, 2017 11:24 AM
To: Scott Cain <***@scottcain.net<mailto:***@scottcain.net>>; Vaneet Lotay <***@ucalgary.ca<mailto:***@ucalgary.ca>>
Cc: gmod-***@lists.sourceforge.net<mailto:gmod-***@lists.sourceforge.net>
Subject: RE: [Gmod-gbrowse] Subroutine for bgcolor

Hi Vaneet,

I used perl callbacks to set the bgcolor attribute. In my case I use feature->name and feature->ref. One thing I noticed in your callback is a syntax error on this line:

return = “black”;

Should be:

return “black”;
--
Wes Barris

From: Scott Cain [mailto:***@scottcain.net]
Sent: Wednesday, March 29, 2017 10:29 AM
To: Vaneet Lotay <***@ucalgary.ca<mailto:***@ucalgary.ca>>
Cc: gmod-***@lists.sourceforge.net<mailto:gmod-***@lists.sourceforge.net>
Subject: Re: [Gmod-gbrowse] Subroutine for bgcolor

Hi Vaneet,

The tricky thing about bgcolor callbacks (if I'm remembering this correctly) is that it is the subpart's type that get's passed in, so if your enhancers and suppressors have subparts, you need to put those in the regex for assigning color. That's one reason one you'd get one result when using the same callback in a balloon versus bgcolor.

I'm not sure that this is part of the problem though, since failure to match should return black, but you've indicated that you're getting cyan features instead. Double check that you don't have another bgcolor entry in the same stanza that might be overriding your callback (you laugh, but I've done that very thing more than once!).

Good luck,
Scott


On Tue, Mar 28, 2017 at 2:26 PM, Vaneet Lotay <***@ucalgary.ca<mailto:***@ucalgary.ca>> wrote:
Hello,

I can’t get the subroutine to work for dynamically calculating bgcolor. At first I thought I was not correctly accessing the right attributes of the ‘feature’ but those same attribute calls (ex: $feature->type) seem to work fine if I use them in a subroutine for ‘balloon click’. Here’s my code for the bgcolor part of my stanza:

..
bgcolor = sub {
my $f = shift;
my $type = $f->type;
if($type =~ /Enhancer/){
return “green”;
} elsif($type =~ /Suppressor/){
return “red”;
} else{
return = “black”;
}
}

I even tried just having a single line in my subroutine that just returns a color but it still doesn’t work which leads me to believe that subroutines are just not accepted anymore for the bgcolor attribute?

Looking at an old post for this issue, someone suggesting trying a perl module reference call like this:

bgcolor = \&Colors::bgcolor;

I tried that and wrote code within ‘Colors.pm’ but still nothing, it always seems to default to cyan color no matter what code I write in.

All I want to do is have the ability to change colors of different segment types (column 3) in a GFF3 file or according to any other attribute of GFF3 file if need be, please let me know if there’s a better way to do this.

Thanks,

Vaneet


Vaneet Lotay

Xenbase Bioinformatician

403-220-6652<tel:(403)%20220-6652>

724 ICT Building - University of Calgary

2500 University Drive NW

Calgary AB T2N 1N4

CANADA


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=gtiDJ8ywfSDe1jUVU6_S2WXFMuC7hU3l46YRCTTLZ7g&e=>
_______________________________________________
Gmod-gbrowse mailing list
Gmod-***@lists.sourceforge.net<mailto:Gmod-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_gmod-2Dgbrowse&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=cfFkJzXkID4H6w42yKtUU4zOyhbQWf2SjNceqNLAHD4&e=>
--
------------------------------------------------------------------------
Scott Cain, Ph. D. scott at scottcain dot net
GMOD Coordinator (http://gmod.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__gmod.org_&d=DwMFaQ&c=af8u9w0F2npf1WqN58KVCXdfpsUVLkzYpB3wkf95_Lk&r=st-kUDmwmkjs7ZlytYd-NABIraW8mzOJJmfoT0694wI&m=Mxw8ovwnTB8Qba8OM3LhYLv8sT5RQMRdj6iGehIDAFY&s=j3YfOx-CN2oERoWamnjR9D37hUjqOJlXlI-k4N158V4&e=>) 216-392-3087
Ontario Institute for Cancer Research
This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Cobb-Vantress, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.

This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Cobb-Vantress, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Loading...