Segue for R

[dtenenba]

Hello,

I see here that as of last year, segue couldn't be used with R > 2.11.
Is that still the case?

I am trying to use it and getting the following results:
> myCluster <- createCluster(numInstances=5)
FAILED - 2012-04-16 16:32:39

> traceback()
No traceback available
> sessionInfo()
R version 2.15.0 (2012-03-30)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics grDevices utils datasets methods
base

other attached packages:
[1] segue_0.02 caTools_1.12 bitops_1.0-4.1
[4] rJava_0.9-3 BiocInstaller_1.5.7

loaded via a namespace (and not attached):
[1] tools_2.15.0

Is there any information I can provide to help narrow this down a bit?
Thanks,
Dan

[James Long]

Dan, if you have not already tried this, try grabbing the latest
source from the Segue site. EMR changed their base version of Debian
and I have to change Segue to cope. I discovered this in the throws of
actually trying to do some work. So I changed Segue without
notification (I'm clearly a crappy source maintainer) and I didn't
even increment the version number.

Let me know if that helps.

-J

[dtenenba]

On Apr 17, 4:42 am, James Long <jdl...@gmail.com> wrote:
> Dan, if you have not already tried this, try grabbing the latest
> source from the Segue site. EMR changed their base version of Debian
> and I have to change Segue to cope. I discovered this in the throws of
> actually trying to do some work. So I changed Segue without
> notification (I'm clearly a crappy source maintainer) and I didn't
> even increment the version number.
>

Thanks for the reply.

I got the same result this time.
I went to the AWS console and got a little more information:

Last State Change Reason: The requested Availability Zone is no longer
supported

Does that help troubleshoot the problem?

Incidentally, after the call to createCluster(), I see a dialog flash
by on my screen very quickly (Mac OS X 10.7.3). I don't know what it
is or if I am expected to interact with it, but FYI.
Thanks,
Dan

[James Long]

oh that's interesting. were you manually selecting a zone or using the default?

-J

[Jack DiMassimo]

On Apr 17, 2012, at 12:57 PM, James Long <jdl...@gmail.com> wrote:

> oh that's interesting. were you manually selecting a zone or using the default?
>
> -J

I've actually seen the same error while using the default availability
zone. Manually changing it resolves the issue.

[James Long]

that's good info. looks like the default zone is borked. I'll change
that in the code.

Thanks for the debugging info.

-j

[dtenenba]

On Apr 17, 11:10 am, James Long <jdl...@gmail.com> wrote:
> that's good info. looks like the default zone is borked. I'll change
> that in the code.
>

Great. Let me know when there is a new version to test. I was just
using the default zone.
Dan

> Thanks for the debugging info.
>
> -j
>
>
>
>
>
>
>
> On Tue, Apr 17, 2012 at 6:08 PM, Jack DiMassimo <jvdi...@gmail.com> wrote:
> > On Apr 17, 2012, at 12:57 PM, James Long <jdl...@gmail.com> wrote:
>
> >> oh that's interesting. were you manually selecting a zone or using the default?
>
> >> -J
>
> > I've actually seen the same error while using the default availability
> > zone. Manually changing it resolves the issue.
>

[James Long]

Well it looks like this is a feature, not a bug:

https://forums.aws.amazon.com/thread.jspa?threadID=67778

I suspect that the "us-east-1a" location is most likely to get loaded
up and have Amazon start throttling new instances. As such, I am going
to change the default location to "us-east-1c." If 1c gets loaded up,
clearly it will throw the same error, but I'm guess this will make it
less common.

-J

[James Long]

I just pushed a change updating the default location to us-east-1c. I
did NOT update the binary, just the source in Google code.

-J