> Only shell we could
>
swap in w/o annoying users would be SQL (ducks);
[...]
You would
>
also have to manage expectations: i.e. that the SQL would be extremely
>
basic and that the REPL does not come with an idling 100 node cluster
>
ready to take up any involved queries.
If we ar
I'm also in favor of a rewrite in another language (but it doesn't have to
be now). This is very subjective but I never got the hang of the Ruby
stuff, it's always annoying to use and I end up googling Ruby stuff almost
every time I want to do something that's not covered in the help command.
Scala
On Wed, May 13, 2015 at 1:38 PM, Andrew Purtell wrote:
> > That's only if you assume HBase users actually understand Ruby though,
> no?
>
> Yes, and this is a fair point.
>
> The language REPL in which we're embedding the shell DSL doesn't have to be
> Ruby. JavaScript would work, maybe via Nasho
If you were going to replace Ruby, Python (Jython) and Scala would make more
sense.
Then you could go to play (the Scala GUI) for a GUI to HBase reusing the code.
> On May 13, 2015, at 3:38 PM, Andrew Purtell wrote:
>
>> That's only if you assume HBase users actually understand Ruby though,
> That's only if you assume HBase users actually understand Ruby though, no?
Yes, and this is a fair point.
The language REPL in which we're embedding the shell DSL doesn't have to be
Ruby. JavaScript would work, maybe via Nashorn. Python would work, via
Jython. Or Scala's REPL, even.
On Wed, M
Andrew Purtell wrote:
This is because the Accumulo shell is a custom built shell? If so, we had
one of those once and replaced it with the IRB based one. We didn't settle
on JRuby right away but, at the time, the consensus was we didn't want to
be in the business of maintaining yet another REPL w
Hmmm.
So if we move to a different tech, the modifications / customizations people
have done are going to be useless.
If we upgrade to a new version of JRuby, some scripts may not have issues,
others may have some , and a third group would have major rewrites.
The interesting / downside to J
Having two shells - a simple user shell for tinkering and an advanced one
for real ops and developers - would be fine, as long as one is not
deprecated. Can't trust something deprecated for tooling.
On Wed, May 13, 2015 at 10:52 AM, Esteban Gutierrez
wrote:
> +1 for new JRuby for now and having
This is because the Accumulo shell is a custom built shell? If so, we had
one of those once and replaced it with the IRB based one. We didn't settle
on JRuby right away but, at the time, the consensus was we didn't want to
be in the business of maintaining yet another REPL when specialist open
sour
Agreed on these points, Sean. Having used both, I think both approaches
have their value and their drawbacks.
The ruby shell is _wonderful_ from having a full programming language to
interact with. Accumulo's shell would force you to use your standard
unix-toolbelt if you want to do any extra
+1 for new JRuby for now and having a JIRA to discuss what features should
this shell have would be great.
However, I think that during the last few years many of us have used the
hbase shell for major surgery as Andrew said and it has added some
confusion to users about what the hbase shell is us
Pros:
* It's easier to test and maintain
* it's easier to script with
* its interactive mode "feels" mode focused on the task of interacting with
a cluster to me (maybe this is just acting like a psql or mysql shell)
Cons
* adding custom commands requires knowing java
--
Sean
On May 13, 2015 1
On May 13, 2015 12:06 PM, "Michael Segel" wrote:
>
> So…
> Silly question…
> Do you really need to worry about backward’s compatibility?
>
> How many people have customized HBaseShell ?
>
> What are the common customizations and if you port HBase shell, how much
work would filter through to the cu
Why is the Accumulo shell superior?
Is it scriptable?
On Wed, May 13, 2015 at 10:28 AM, Sean Busbey wrote:
> I would love to rip out the JRuby shell entirely and make something closer
> to the Accumulo shell, but I expect that will
>
> 1) be way more work
>
> 2) be even less compatible for tho
I would love to rip out the JRuby shell entirely and make something closer
to the Accumulo shell, but I expect that will
1) be way more work
2) be even less compatible for those that rely on customizations.
I figured given time we could get a preview "user shell" (rather than
"power shell" via i
I'd be curious to hear proposals for a new shell. Wondering what the
arguments in favor would be and arguments against current.
JRuby has served us well. Recently it personally saved me hassle by
allowing scripted surgery (advanced ops) rather than dev of a one off Java
utility. OTOH, if what we h
sorry to say I don't good at Ruby .
HBase Shell may should upgrade :)
2015-05-14 1:06 GMT+08:00 Michael Segel :
> So…
> Silly question…
> Do you really need to worry about backward’s compatibility?
>
> How many people have customized HBaseShell ?
>
> What are the common customizations and if you
Nice writeup Sean.
Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is
still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+.
But if we are going to do a significant shell refactor for hbase 2.0,
should we consider doing something more radical; e.g. a new shell?
So…
Silly question…
Do you really need to worry about backward’s compatibility?
How many people have customized HBaseShell ?
What are the common customizations and if you port HBase shell, how much work
would filter through to the custom code?
> On May 13, 2015, at 11:22 AM, Sean Busbey
Hi folks!
If you weren't aware, our current shell relies on Ruby, specifically the
REPL program IRB from JRuby. When we launched 1.0 we were on JRuby 1.6 with
defaults, which means we're stuck on Ruby 1.8.
For those that don't already know, Ruby 1.8 is super old and has been
walking off into the
20 matches
Mail list logo