Index repr changes to make them consistent

With this PR, makes repr of all Index types consistent.
closes #6482
closes #6295
replaces #9897
Previous Behavior
In [1]: pd.get_option('max_seq_items')
Out[1]: 100

In [2]: pd.Index(range(4),name='foo')
Out[2]: Int64Index([0, 1, 2, 3], dtype='int64')

In [3]: pd.Index(range(104),name='foo')
Out[3]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, ...], dtype='int64')

In [4]: pd.date_range('20130101',periods=4,name='foo',tz='US/Eastern')
Out[4]:
<class 'pandas.tseries.index.DatetimeIndex'>
[2013-01-01 00:00:00-05:00, ..., 2013-01-04 00:00:00-05:00]
Length: 4, Freq: D, Timezone: US/Eastern

In [5]: pd.date_range('20130101',periods=104,name='foo',tz='US/Eastern')
Out[5]:
<class 'pandas.tseries.index.DatetimeIndex'>
[2013-01-01 00:00:00-05:00, ..., 2013-04-14 00:00:00-04:00]
Length: 104, Freq: D, Timezone: US/Eastern

New Behavior
In [1]:  pd.get_option('max_seq_items')
Out[1]: 10

In [9]: pd.Index(range(4),name='foo')
Out[9]: Int64Index([0, 1, 2, 3], dtype='int64', name=u'foo')

In [10]: pd.Index(range(104),name='foo')
Out[10]: Int64Index([0, 1, ..., 102, 103], dtype='int64', name=u'foo', length=104)

In [11]: pd.date_range('20130101',periods=4,name='foo',tz='US/Eastern')
Out[11]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00', '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [12]: pd.date_range('20130101',periods=104,name='foo',tz='US/Eastern')
Out[12]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00', ..., '2013-04-13 00:00:00-04:00', '2013-04-14 00:00:00-04:00'], dtype='datetime64[ns]', name=u'foo', length=104, freq='D', tz='US/Eastern')

Note that MultiIndex and CategoricalIndex are multi-line repr and do no truncate sequences (of e.g. labels), this is consistent with previous versions. (easy to change this though)
In [1]: MultiIndex.from_product([list('abcdefg'),range(10)],names=['first','second'])
Out[1]:
MultiIndex(levels=[[u'a', u'b', u'c', u'd', u'e', u'f', u'g'], [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]],
           labels=[[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6], [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]],
           names=[u'first', u'second'])

In [4]: pd.CategoricalIndex(np.random.randint(0,5,size=100),name='foo')
Out[4]:
CategoricalIndex([3, 0, 0, 3, 1, 3, 0, 4, 2, 3, 0, 4, 0, 1, 2, 0, 4, 1, 4, 2, 3, 1, 0, 4, 4, 3, 0, 3, 0, 1, 2, 3, 3, 1, 1, 0, 0, 4, 4, 1, 1, 3, 1, 1, 4, 4, 3, 0, 0, 0, 4, 4, 0, 1, 3, 1, 2, 0, 3, 1, 2, 2, 2, 1, 1, 4, 1, 0, 4, 3, 3, 0, 0, 0, 4, 4, 1, 4, 2, 2, 1, 4, 0, 0, 0, 4, 3, 0, 4, 0, 0, 0, 3, 3, 1, 2, 2, 3, 4, 1],
                 categories=[0, 1, 2, 3, 4],
                 ordered=False,
                 name=u'foo',
                 dtype='category')

@jorisvandenbossche
@shoyer
cc @hsperr

Looks like a great idea to me! Would be nice to squeeze name into repr for datetimeindex, too.

I think adding the name is certainly OK!
However, I don't know if I like the stacking and indenting under each other. For short indices, this makes your output in the console a lot longer.
If we change the Index repr in such a way, I would do at once a more thourough clean-up, and also look if we can/want to make the DatetimeIndex more consistent (and I would then do this for 0.17 and not in a minor release)

Ah, I see that you updated the initial message :-) (my response was based on the mail I got)
So you also reformatted the datetime-like indices. I think that is a good idea, but to repeat above: maybe we should leave this for 0.17? And I would also ping the mailing list.
And maybe we should also think about if we want a difference between repr and str.
Small remark on the actual output: for DatetimeIndex, the dates should also be quoted I think to have this evalable (like it is for TimedeltaIndex and objext Index)

I do agree with @jorisvandenbossche that it's nice to have the output on one line than spread over many.
As for larger unification of index repr, this is also a great idea! Given that this is unlikely to break any existing code, I think it would probably be OK in an point release (especially given how loosely pandas does semantic versioning already -- people already expect new features and changes in point releases).
My vote would be to include more than the first and last items in string output for all indexes. Perhaps the first 30 and last 30 items, like Series? I'd be happy even with just 5/5. This is actually a bit of a pet-peeve of mine with the old DatetimeIndex repr -- I would often end up converting the index to a series just to see more than 2 values.

ok, this was pretty trivial (and now the short format works for everything).
max_seq_items is for this purpose, but I think need to make much smaller (its a default of 100 now), or maybe adjust a bit, e.g. for integers its ok, but for datetimes its way too big.
so will print short format if its a small sequence, and long format otherwise (trivial to be either one)
In [1]: pd.set_option('max_seq_items',8)

In [2]: pd.date_range('20130101',freq='s',periods=2,tz='US/Eastern',name='foo')
Out[2]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-01 00:00:01-05:00'], name=u'foo', dtype='datetime64[ns]', length=2, freq='S', tz='US/Eastern')

In [3]: pd.date_range('20130101',freq='s',periods=4,tz='US/Eastern',name='foo')
Out[3]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-01 00:00:01-05:00', '2013-01-01 00:00:02-05:00', '2013-01-01 00:00:03-05:00'], name=u'foo', dtype='datetime64[ns]', length=4, freq='S', tz='US/Eastern')

In [4]: pd.date_range('20130101',freq='s',periods=6,tz='US/Eastern',name='foo')
Out[4]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-01 00:00:01-05:00', '2013-01-01 00:00:02-05:00', '2013-01-01 00:00:03-05:00', '2013-01-01 00:00:04-05:00', '2013-01-01 00:00:05-05:00'], name=u'foo', dtype='datetime64[ns]', length=6, freq='S', tz='US/Eastern')

In [5]: pd.date_range('20130101',freq='s',periods=8,tz='US/Eastern',name='foo')
Out[5]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-01 00:00:01-05:00', '2013-01-01 00:00:02-05:00', '2013-01-01 00:00:03-05:00', '2013-01-01 00:00:04-05:00', '2013-01-01 00:00:05-05:00', '2013-01-01 00:00:06-05:00', '2013-01-01 00:00:07-05:00'], name=u'foo', dtype='datetime64[ns]', length=8, freq='S', tz='US/Eastern')

In [6]: pd.date_range('20130101',freq='s',periods=10,tz='US/Eastern',name='foo')
Out[6]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-01 00:00:01-05:00', ..., '2013-01-01 00:00:08-05:00', '2013-01-01 00:00:09-05:00'],
              name=u'foo',
              dtype='datetime64[ns]',
              length=10,
              freq='S',
              tz='US/Eastern')

This is not really much of a change per-se as a) you normally don't print indexes themselves that often. and its just a display fix (and really a bug fix at that).

starting to like these (I changed it to always print on the same line). MultiIndex (and CategoricalIndex) are  the odd one out here, but they have quite a bit more info to communicate
In [2]: pd.set_option('max_seq_items',8)

In [3]: pd.date_range('20130101',periods=80)
Out[3]: DatetimeIndex(['2013-01-01', '2013-01-02', ..., '2013-03-20', '2013-03-21'], dtype='datetime64[ns]', length=80, freq='D', tz=None)

In [4]: Index(range(8))
Out[4]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7], dtype='int64')

In [5]: Index(range(10))
Out[5]: Int64Index([0, 1, ..., 8, 9], dtype='int64')

In [6]: Index(range(10),name='foo')
Out[6]: Int64Index([0, 1, ..., 8, 9], name=u'foo', dtype='int64')

ok, updated the top of the PR with new/previous behavior.
This unifies all Index repr (including MultiIndex, though that is unchanged and multi-line). I switched back to a single line, with the display.max_seq_items controlling if it does a short or long-format.
The number to display in the short-repr is 2 on the head and 2 on the tail and is hard coded, but I suppose could be 'computed', e.g. in theory you could show say more integers that you can datetimes, but will leave that for later.

OK, I would probably default to showing 3 items rather than 2, but this is a step in the right direction.
As long as we're changing this, let's make sure that all index types can be run through eval, at least if they aren't truncated for length. So I think that means the length field needs to go.

I would vote for on a single line. The terminal wraps it anyways, and otherwise you can get strange effects like:
In [3]: pd.Index(range(21))
Out[3]:
Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19
, 20],
           dtype='int64')

But should check how this in a notebook.
Some other feedback:

not sure that the 'name' should go before dtype. It seems more logical to put optional ones as last.
agree about the length field. I know it is there in the current repr, but this is inconsistent with the others, and also not a real correct kwarg.
it feels strange to me that if you approach max_seq_items you can have a very long output, and then at once if you reach it, only a very short output. It seems more logical that the output is truncated at  max_seq_items (eg if max_seq_items is set at 30, show the first 15 and last 15). But that can be an argument to change the default of max_seq_items to a much lower one (or to make this a new option specific for index)

By the way, as this directly touches the output users see (and that can be delicate), I would certainly also bring this to the mailing list. Plus, just having more eyes looking at this as the three of us would be good. I can do it tomorrow, if it is not yet done by then.

we could have an argument say max_seq_visible to control the head/tail ones. But honestly I would do that later, see if its really needed.
I just put name/dtype (and length only shows up if you are truncating) first. but could easily change that order (you want dtype then name, ok)
If you want to put on the mailing list ok by me. I don't really think this is that big of a deal. The basic formats are pretty much unchanged and its just cleaning up things. (the current PR is for 1 line btw).

top-section is updated

I updated the top of the PR to show the repr of MultiIndex/CategoricalIndex (unchanged for MultiIndex from previous versions)

Wouldn't we keep the new CategoricalIndex consistent with the other Index types instead of to MultiIndex?

@jorisvandenbossche you mean 1 line?
I think things get lost, e.g. ordered/name. As you have both codes/categories. Now codes themselves are not really necessary (and simliarly for MultiIndex), e.g. in my example a MultiIndex is really just
In [7]: MultiIndex.from_product([list('abcdefg'),range(10)],names=['first','second']).levels[0]
Out[7]: Index([u'a', u'b', u'c', u'd', u'e', u'f', u'g'], dtype='object', name=u'first')

In [8]: MultiIndex.from_product([list('abcdefg'),range(10)],names=['first','second']).levels[1]
Out[8]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype='int64', name=u'second')

Which IMHO is more informative, but it would be by-definition multi-line repr
and CategoricalIndex is closer to MultiIndex I think.

In [12]: pd.date_range('20130101',periods=104,name='foo',tz='US/Eastern')
Out[12]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00', ...,
               '2013-04-13 00:00:00-04:00', '2013-04-14 00:00:00-04:00'],
              dtype='datetime64[ns]', name=u'foo', length=104, freq='D', tz='US/Eastern')

@jorisvandenbossche your proposal looks like adding a line feed after the 'data' portion, then putting all the rest on the next line, yes?

Can you show what you think for th example above? (the short and long-format)

@shoyer @jorisvandenbossche
any remaining issues on this?
I think promotes consistency. Can always tweak the format in future versions as its pretty easy to change.

Sorry, I will look at it this evening!

I agree these are good changes -- the old repr was not very consistent.

To understand correclty, everything is now on 1 line? (so it lets the terminal wrap it as needed)
Yes, I think this is OK for now (the other proposal of splitting the values ourselves over multiple lines so they can be nicely aligned as numpy arrays do (proposal from the mailing list) can maybe be added later. Only three things:

I am still not really fond on the length keyword-like (as this is the only one that is not a real keyword). But OK for me if others like this.
I would personally keep the max_seq_items to the same default of 100 for now. 10 is really not much (for dataframes we use 60)
I would make the CategoricalIndex follow the other Index types (so on one line)

Furthermore, the CategoricalIndex is not following the max_seq_items as the other indices?
With the PR:
In [34]: pd.CategoricalIndex(np.random.randint(0,5,size=100),name='foo')
Out[34]:
CategoricalIndex([3, 3, 4, 2, 2, 0, 3, 4, 0, 1, 1, 3, 2, 4, 2, 2, 2, 0, 4, 3, 4,
 1, 0, 4, 0, 0, 3, 3, 4, 1, 2, 4, 3, 1, 0, 1, 0, 2, 0, 2, 0, 3, 0, 1, 3, 1, 3, 0
, 2, 4, 3, 1, 1, 0, 0, 3, 0, 3, 2, 3, 1, 4, 1, 3, 2, 2, 0, 0, 1, 1, 1, 1, 0, 4,
3, 1, 3, 0, 3, 1, 4, 4, 4, 4, 3, 3, 1, 2, 4, 3, 1, 3, 0, 2, 2, 2, 0, 4, 1, 1],
                 categories=[0, 1, 2, 3, 4],
                 ordered=False,
                 name=u'foo',
                 dtype='category')

Categorical follows exactly the format of MultiIndex
no wrapping of values at all
putting this on 1 line is imho very confusing

why would you make max_seq_items so big? the point is to provide a concise view - how about 20 as a compromise

for the categorical: the difference with MultiIndex is that there you don't have 3 extra small lines at the end. It would also be possible to put only these on one line.
For eg DatetimeIndex, you also have a lot of extra info (freq, tz, dtype, name), and there we put everything on one line

max_seq_items: for other Index types apart from the datetime-like, it is like that at this moment (showing up to 100 items). And I don't think we got complaints about that?
For me personally, one of the annoying things with DatetimeIndex was that it showed only 2 values. With this PR it goes from 2 to 4, which is already better of course! :-), but personally I would like the see more.
The fact that with Index of length 10 -> you see 10 items, index of length 11 -> you see 4 items, is also a bit strange. I would also have this 10 / first 5 last 5 (or 20 and first 10 / last 10)

The "what is the point of looking at df.index" is indeed the good question.
Is it to provide a concise view vs to have a detailed look at the values? Probably people will use it for different purposes.
But regarding to a quick look of what kind of index / what is inside, having a more aligned output will also help (following the numpy array approach a bit).
For example, the current output of a DatetimeIndex (with this PR):
In [42]: pd.date_range('20130101',periods=10,name='foo',tz='US/Eastern')
Out[42]: DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00'
, '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00', '2013-01-05 00:00:00
-05:00', '2013-01-06 00:00:00-05:00', '2013-01-07 00:00:00-05:00', '2013-01-08 0
0:00:00-05:00', '2013-01-09 00:00:00-05:00', '2013-01-10 00:00:00-05:00'], dtype
='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

could be something like:
In [42]: pd.date_range('20130101',periods=10,name='foo',tz='US/Eastern')
Out[42]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00', '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00', '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00', '2013-01-10 00:00:00-05:00'],
              dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

@jreback my doubt about the max_seq_len is maybe more about the 2x2 values that are shown (instead of 2x5), than the value of 10 itself. You can always do  .values if you want to see all values

ok I changes max_seq_items to 20, and now use +-5 for the head/tail. and CategoricalIndex is now on 1-line.
In [3]: pd.date_range('20130101',periods=50,freq='s',name='foo')
Out[3]: DatetimeIndex(['2013-01-01 00:00:00', '2013-01-01 00:00:01', '2013-01-01 00:00:02', '2013-01-01 00:00:03', '2013-01-01 00:00:04', ..., '2013-01-01 00:00:45', '2013-01-01 00:00:46', '2013-01-01 00:00:47', '2013-01-01 00:00:48', '2013-01-01 00:00:49'], dtype='datetime64[ns]', name=u'foo', length=50, freq='S', tz=None)

In [4]: pd.date_range('20130101',periods=10,freq='s',name='foo')
Out[4]: DatetimeIndex(['2013-01-01 00:00:00', '2013-01-01 00:00:01', '2013-01-01 00:00:02', '2013-01-01 00:00:03', '2013-01-01 00:00:04', '2013-01-01 00:00:05', '2013-01-01 00:00:06', '2013-01-01 00:00:07', '2013-01-01 00:00:08', '2013-01-01 00:00:09'], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [5]: pd.CategoricalIndex(list('aabbcdefg')*2,ordered=True,name='foo')
Out[5]: CategoricalIndex([u'a', u'a', u'b', u'b', u'c', u'd', u'e', u'f', u'g', u'a', u'a', u'b', u'b', u'c', u'd', u'e', u'f', u'g'], categories=[u'a', u'b', u'c', u'd', u'e', u'f', u'g'], ordered=True, name=u'foo', dtype='category')

In [6]: pd.CategoricalIndex(list('aabbcdefg')*10,ordered=True,name='foo')
Out[6]: CategoricalIndex([u'a', u'a', u'b', u'b', u'c', ..., u'c', u'd', u'e', u'f', u'g'], categories=[u'a', u'b', u'c', u'd', u'e', u'f', u'g'], ordered=True, name=u'foo', dtype='category')

This was easy actually. Only for the time-base ones (Period/Datetime/Timedelta).
[3] and [4] ok?
In [1]: pd.date_range('20130101',periods=30,freq='s',name='foo')
Out[1]:
DatetimeIndex(['2013-01-01 00:00:00',
               '2013-01-01 00:00:01',
               '2013-01-01 00:00:02',
               '2013-01-01 00:00:03',
               '2013-01-01 00:00:04',
               '2013-01-01 00:00:05'
               ...
               '2013-01-01 00:00:24',
               '2013-01-01 00:00:25',
               '2013-01-01 00:00:26',
               '2013-01-01 00:00:27',
               '2013-01-01 00:00:28',
               '2013-01-01 00:00:29'
              ], dtype='datetime64[ns]', name=u'foo', length=30, freq='S', tz=None)

In [2]: pd.date_range('20130101',periods=10,freq='s',name='foo')
Out[2]:
DatetimeIndex(['2013-01-01 00:00:00',
               '2013-01-01 00:00:01',
               '2013-01-01 00:00:02',
               '2013-01-01 00:00:03',
               '2013-01-01 00:00:04',
               '2013-01-01 00:00:05',
               '2013-01-01 00:00:06',
               '2013-01-01 00:00:07',
               '2013-01-01 00:00:08',
               '2013-01-01 00:00:09'
              ], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [3]: pd.date_range('20130101',periods=2,freq='s',name='foo')
Out[3]: DatetimeIndex(['2013-01-01 00:00:00', '2013-01-01 00:00:01'], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [4]: pd.date_range('20130101',periods=1,freq='s',name='foo')
Out[4]: DatetimeIndex(['2013-01-01'], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

I realized that numpy puts the meta-data on the same line as the last element
what do you think?
In [2]: pd.date_range('20130101',periods=20,tz='US/Eastern',name='foo')
Out[2]:
DatetimeIndex(['2013-01-01 00:00:00-05:00',
               '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00',
               '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00',
               '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00',
               '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00',
               '2013-01-10 00:00:00-05:00',
               '2013-01-11 00:00:00-05:00',
               '2013-01-12 00:00:00-05:00',
               '2013-01-13 00:00:00-05:00',
               '2013-01-14 00:00:00-05:00',
               '2013-01-15 00:00:00-05:00',
               '2013-01-16 00:00:00-05:00',
               '2013-01-17 00:00:00-05:00',
               '2013-01-18 00:00:00-05:00',
               '2013-01-19 00:00:00-05:00',
               '2013-01-20 00:00:00-05:00'
              ], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [3]: pd.date_range('20130101',periods=20,tz='US/Eastern',name='foo').values
Out[3]:
array(['2013-01-01T00:00:00.000000000-0500',
       '2013-01-02T00:00:00.000000000-0500',
       '2013-01-03T00:00:00.000000000-0500',
       '2013-01-04T00:00:00.000000000-0500',
       '2013-01-05T00:00:00.000000000-0500',
       '2013-01-06T00:00:00.000000000-0500',
       '2013-01-07T00:00:00.000000000-0500',
       '2013-01-08T00:00:00.000000000-0500',
       '2013-01-09T00:00:00.000000000-0500',
       '2013-01-10T00:00:00.000000000-0500',
       '2013-01-11T00:00:00.000000000-0500',
       '2013-01-12T00:00:00.000000000-0500',
       '2013-01-13T00:00:00.000000000-0500',
       '2013-01-14T00:00:00.000000000-0500',
       '2013-01-15T00:00:00.000000000-0500',
       '2013-01-16T00:00:00.000000000-0500',
       '2013-01-17T00:00:00.000000000-0500',
       '2013-01-18T00:00:00.000000000-0500',
       '2013-01-19T00:00:00.000000000-0500',
       '2013-01-20T00:00:00.000000000-0500'], dtype='datetime64[ns]')

Revised, much more numpy-like now!
In [1]: pd.date_range('20130101',periods=1,tz='US/Eastern',name='foo')
Out[1]: DatetimeIndex(['2013-01-01 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [2]: pd.date_range('20130101',periods=2,tz='US/Eastern',name='foo')
Out[2]:
DatetimeIndex(['2013-01-01 00:00:00-05:00'
               '2013-01-02 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [3]: pd.date_range('20130101',periods=10,tz='US/Eastern',name='foo')
Out[3]:
DatetimeIndex(['2013-01-01 00:00:00-05:00',
               '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00',
               '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00',
               '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00',
               '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00',
               '2013-01-10 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [4]: pd.date_range('20130101',periods=25,tz='US/Eastern',name='foo')
Out[4]:
DatetimeIndex(['2013-01-01 00:00:00-05:00',
               '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00',
               '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00',
               '2013-01-06 00:00:00-05:00'
               ...
               '2013-01-20 00:00:00-05:00',
               '2013-01-21 00:00:00-05:00',
               '2013-01-22 00:00:00-05:00',
               '2013-01-23 00:00:00-05:00',
               '2013-01-24 00:00:00-05:00',
               '2013-01-25 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', length=25, freq='D', tz='US/Eastern')

one more correction
will display 10 element (or min of 1/2 of the max_seq_len), so 20 displays all, then 21 shows +-10 etc.
In [2]: pd.date_range('20130101',periods=20,tz='US/Eastern',name='foo')
Out[2]:
DatetimeIndex(['2013-01-01 00:00:00-05:00',
               '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00',
               '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00',
               '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00',
               '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00',
               '2013-01-10 00:00:00-05:00',
               '2013-01-11 00:00:00-05:00',
               '2013-01-12 00:00:00-05:00',
               '2013-01-13 00:00:00-05:00',
               '2013-01-14 00:00:00-05:00',
               '2013-01-15 00:00:00-05:00',
               '2013-01-16 00:00:00-05:00',
               '2013-01-17 00:00:00-05:00',
               '2013-01-18 00:00:00-05:00',
               '2013-01-19 00:00:00-05:00',
               '2013-01-20 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [3]: pd.date_range('20130101',periods=21,tz='US/Eastern',name='foo')
Out[3]:
DatetimeIndex(['2013-01-01 00:00:00-05:00',
               '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00',
               '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00',
               '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00',
               '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00',
               '2013-01-10 00:00:00-05:00'
               ...
               '2013-01-12 00:00:00-05:00',
               '2013-01-13 00:00:00-05:00',
               '2013-01-14 00:00:00-05:00',
               '2013-01-15 00:00:00-05:00',
               '2013-01-16 00:00:00-05:00',
               '2013-01-17 00:00:00-05:00',
               '2013-01-18 00:00:00-05:00',
               '2013-01-19 00:00:00-05:00',
               '2013-01-20 00:00:00-05:00',
               '2013-01-21 00:00:00-05:00'], dtype='datetime64[ns]', name=u'foo', length=21, freq='D', tz='US/Eastern')

If we use this formatter for all Index types, rather than just datetimelikes (except MultiIndex)
In [4]: pd.CategoricalIndex(list('aabbcdefg')*10)
Out[4]:
CategoricalIndex([u'a',
                  u'a',
                  u'b',
                  u'b',
                  u'c',
                  u'd',
                  u'e',
                  u'f',
                  u'g',
                  u'a'
                  ...
                  u'g',
                  u'a',
                  u'a',
                  u'b',
                  u'b',
                  u'c',
                  u'd',
                  u'e',
                  u'f',
                  u'g'], categories=[u'a', u'b', u'c', u'd', u'e', u'f', u'g'], ordered=False, dtype='category', length=90)

In [5]: Index(range(20))
Out[5]:
Int64Index([0,
            1,
            2,
            3,
            4,
            5,
            6,
            7,
            8,
            9,
            10,
            11,
            12,
            13,
            14,
            15,
            16,
            17,
            18,
            19], dtype='int64')

@jreback I adjusted your latest version a little bit (see https://github.com/jreback/pandas/pull/14, but, very ugly quick code, to get the idea, only a small work-break :-)), so the number of items on one row depends on the length of the values.
Then you get something like:
In [1]: pd.date_range('20130101',periods=10,name='foo')
Out[1]:
DatetimeIndex([ '2013-01-01', '2013-01-02', '2013-01-03', '2013-01-04',
                '2013-01-05', '2013-01-06', '2013-01-07', '2013-01-08',
                '2013-01-09', '2013-01-10']
               , dtype='datetime64[ns]', name=u'foo', freq='D', tz=None)

In [2]: pd.date_range('20130101 09:00',periods=10,name='foo')
Out[2]:
DatetimeIndex([ '2013-01-01 09:00:00', '2013-01-02 09:00:00',
                '2013-01-03 09:00:00', '2013-01-04 09:00:00',
                '2013-01-05 09:00:00', '2013-01-06 09:00:00',
                '2013-01-07 09:00:00', '2013-01-08 09:00:00',
                '2013-01-09 09:00:00', '2013-01-10 09:00:00']
               , dtype='datetime64[ns]', name=u'foo', freq='D', tz=None)

In [3]: pd.period_range('2013',periods=10, freq='A', name='foo')
Out[3]:
PeriodIndex([ '2013', '2014', '2015', '2016', '2017', '2018', '2019', '2020',
              '2021', '2022']
             , dtype='int64', name=u'foo', freq='A-DEC')

(ignore the few errors in there)
And with this, it would also make more sense with Int64Index
What do you think of this?

@jorisvandenbossche incorporating your changes and some tweaks
In [1]: Index(range(2))
Out[1]: Int64Index([0, 1], dtype='int64')

In [2]: Index(range(5))
Out[2]: Int64Index([ 0, 1, 2, 3, 4], dtype='int64')

In [3]: Index(range(10))
Out[3]: Int64Index([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype='int64')

In [4]: Index(range(20))
Out[4]: Int64Index([  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19], dtype='int64')

In [5]: Index(range(25))
Out[5]:
Int64Index([  0,  1,  2,  3,  4,  5,  6,  7,  8,  9
            ...
             15, 16, 17, 18, 19, 20, 21, 22, 23, 24
           ], dtype='int64', length=25)

In [6]: pd.date_range('20130101',periods=2,freq='s',name='foo')
Out[6]: DatetimeIndex(['2013-01-01 00:00:00', '2013-01-01 00:00:01'], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [7]: pd.date_range('20130101',periods=5,freq='s',name='foo')
Out[7]:
DatetimeIndex([ '2013-01-01 00:00:00', '2013-01-01 00:00:01',
                '2013-01-01 00:00:02', '2013-01-01 00:00:03',
                '2013-01-01 00:00:04'
              ], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [8]: pd.date_range('20130101',periods=20,freq='s',name='foo')
Out[8]:
DatetimeIndex([ '2013-01-01 00:00:00', '2013-01-01 00:00:01',
                '2013-01-01 00:00:02', '2013-01-01 00:00:03',
                '2013-01-01 00:00:04', '2013-01-01 00:00:05',
                '2013-01-01 00:00:06', '2013-01-01 00:00:07',
                '2013-01-01 00:00:08', '2013-01-01 00:00:09',
                '2013-01-01 00:00:10', '2013-01-01 00:00:11',
                '2013-01-01 00:00:12', '2013-01-01 00:00:13',
                '2013-01-01 00:00:14', '2013-01-01 00:00:15',
                '2013-01-01 00:00:16', '2013-01-01 00:00:17',
                '2013-01-01 00:00:18', '2013-01-01 00:00:19'
              ], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [9]: pd.date_range('20130101',periods=25,freq='s',name='foo')
Out[9]:
DatetimeIndex([ '2013-01-01 00:00:00', '2013-01-01 00:00:01',
                '2013-01-01 00:00:02', '2013-01-01 00:00:03',
                '2013-01-01 00:00:04', '2013-01-01 00:00:05',
                '2013-01-01 00:00:06', '2013-01-01 00:00:07',
                '2013-01-01 00:00:08', '2013-01-01 00:00:09'
               ...
                '2013-01-01 00:00:15', '2013-01-01 00:00:16',
                '2013-01-01 00:00:17', '2013-01-01 00:00:18',
                '2013-01-01 00:00:19', '2013-01-01 00:00:20',
                '2013-01-01 00:00:21', '2013-01-01 00:00:22',
                '2013-01-01 00:00:23', '2013-01-01 00:00:24'
              ], dtype='datetime64[ns]', name=u'foo', length=25, freq='S', tz=None)

is there a reason you don't let the Int64Index wrap if it is not truncated?
I would have the ... shifted one space to the right
the number of shown items now does not follow max_seq_len anymore. Was this on purpose?

A fix for the width detection (1 -> 2, for comma and space, otherwise it overflowed in some cases): https://github.com/jorisvandenbossche/pandas/commit/41d90d7d89ff2569cdb3e626b487b95caf284c74

@jorisvandenbossche incorporating your fix
and a couple of tweaks (it doesn't use the full console width but 1/2 of it, with a min)
In [3]: Index(range(5),name='foo')
Out[3]: Int64Index([  0,  1,  2,  3,  4], dtype='int64', name=u'foo')

In [4]: Index(range(95),name='foo')
Out[4]:
Int64Index([   0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  13,  14,  15,  16,  17,  18,  19,  20,  21,  22,  23,  24,  25,  26,  27,  28,  29,  30,  31,  32,  33,
              34,  35,  36,  37,  38,  39,  40,  41,  42,  43,  44,  45,  46,  47,  48,  49,  50,  51,  52,  53,  54,  55,  56,  57,  58,  59,  60,  61,  62,  63,  64,  65,  66,  67,
              68,  69,  70,  71,  72,  73,  74,  75,  76,  77,  78,  79,  80,  81,  82,  83,  84,  85,  86,  87,  88,  89,  90,  91,  92,  93,  94]
           , dtype='int64', name=u'foo')

In [5]: Index(range(105),name='foo')
Out[5]:
Int64Index([    0,    1,    2,    3,    4,    5,    6,    7,    8,    9
             ...
               95,   96,   97,   98,   99,  100,  101,  102,  103,  104]
           , dtype='int64', name=u'foo', length=105)

In [6]: pd.date_range('20130101',freq='s',name='foo',periods=5)
Out[6]: DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',  '2013-01-01 00:00:02',  '2013-01-01 00:00:03',  '2013-01-01 00:00:04'], dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [7]: pd.date_range('20130101',freq='s',name='foo',periods=95)
Out[7]:
DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',  '2013-01-01 00:00:02',  '2013-01-01 00:00:03',  '2013-01-01 00:00:04',
                 '2013-01-01 00:00:05',  '2013-01-01 00:00:06',  '2013-01-01 00:00:07',  '2013-01-01 00:00:08',  '2013-01-01 00:00:09',
                 '2013-01-01 00:00:10',  '2013-01-01 00:00:11',  '2013-01-01 00:00:12',  '2013-01-01 00:00:13',  '2013-01-01 00:00:14',
                 '2013-01-01 00:00:15',  '2013-01-01 00:00:16',  '2013-01-01 00:00:17',  '2013-01-01 00:00:18',  '2013-01-01 00:00:19',
                 '2013-01-01 00:00:20',  '2013-01-01 00:00:21',  '2013-01-01 00:00:22',  '2013-01-01 00:00:23',  '2013-01-01 00:00:24',
                 '2013-01-01 00:00:25',  '2013-01-01 00:00:26',  '2013-01-01 00:00:27',  '2013-01-01 00:00:28',  '2013-01-01 00:00:29',
                 '2013-01-01 00:00:30',  '2013-01-01 00:00:31',  '2013-01-01 00:00:32',  '2013-01-01 00:00:33',  '2013-01-01 00:00:34',
                 '2013-01-01 00:00:35',  '2013-01-01 00:00:36',  '2013-01-01 00:00:37',  '2013-01-01 00:00:38',  '2013-01-01 00:00:39',
                 '2013-01-01 00:00:40',  '2013-01-01 00:00:41',  '2013-01-01 00:00:42',  '2013-01-01 00:00:43',  '2013-01-01 00:00:44',
                 '2013-01-01 00:00:45',  '2013-01-01 00:00:46',  '2013-01-01 00:00:47',  '2013-01-01 00:00:48',  '2013-01-01 00:00:49',
                 '2013-01-01 00:00:50',  '2013-01-01 00:00:51',  '2013-01-01 00:00:52',  '2013-01-01 00:00:53',  '2013-01-01 00:00:54',
                 '2013-01-01 00:00:55',  '2013-01-01 00:00:56',  '2013-01-01 00:00:57',  '2013-01-01 00:00:58',  '2013-01-01 00:00:59',
                 '2013-01-01 00:01:00',  '2013-01-01 00:01:01',  '2013-01-01 00:01:02',  '2013-01-01 00:01:03',  '2013-01-01 00:01:04',
                 '2013-01-01 00:01:05',  '2013-01-01 00:01:06',  '2013-01-01 00:01:07',  '2013-01-01 00:01:08',  '2013-01-01 00:01:09',
                 '2013-01-01 00:01:10',  '2013-01-01 00:01:11',  '2013-01-01 00:01:12',  '2013-01-01 00:01:13',  '2013-01-01 00:01:14',
                 '2013-01-01 00:01:15',  '2013-01-01 00:01:16',  '2013-01-01 00:01:17',  '2013-01-01 00:01:18',  '2013-01-01 00:01:19',
                 '2013-01-01 00:01:20',  '2013-01-01 00:01:21',  '2013-01-01 00:01:22',  '2013-01-01 00:01:23',  '2013-01-01 00:01:24',
                 '2013-01-01 00:01:25',  '2013-01-01 00:01:26',  '2013-01-01 00:01:27',  '2013-01-01 00:01:28',  '2013-01-01 00:01:29',
                 '2013-01-01 00:01:30',  '2013-01-01 00:01:31',  '2013-01-01 00:01:32',  '2013-01-01 00:01:33',  '2013-01-01 00:01:34']
              , dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [8]: pd.date_range('20130101',freq='s',name='foo',periods=105)
Out[8]:
DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',  '2013-01-01 00:00:02',  '2013-01-01 00:00:03',  '2013-01-01 00:00:04',
                 '2013-01-01 00:00:05',  '2013-01-01 00:00:06',  '2013-01-01 00:00:07',  '2013-01-01 00:00:08',  '2013-01-01 00:00:09'
                ...
                 '2013-01-01 00:01:35',  '2013-01-01 00:01:36',  '2013-01-01 00:01:37',  '2013-01-01 00:01:38',  '2013-01-01 00:01:39',
                 '2013-01-01 00:01:40',  '2013-01-01 00:01:41',  '2013-01-01 00:01:42',  '2013-01-01 00:01:43',  '2013-01-01 00:01:44']
              , dtype='datetime64[ns]', name=u'foo', length=105, freq='S', tz=None)

@jreback What do you think of this (https://github.com/jorisvandenbossche/pandas/commit/fa27ce9263ad7fc9b22babb8559b83e5194bb19b):
In [4]: pd.date_range('20130101',periods=80)
Out[4]:
DatetimeIndex(['2013-01-01', '2013-01-02', '2013-01-03', '2013-01-04',
               '2013-01-05', '2013-01-06', '2013-01-07', '2013-01-08',
               '2013-01-09', '2013-01-10'
               ...
               '2013-03-12', '2013-03-13', '2013-03-14', '2013-03-15',
               '2013-03-16', '2013-03-17', '2013-03-18', '2013-03-19',
               '2013-03-20', '2013-03-21'],
              dtype='datetime64[ns]', length=80, freq='D', tz=None)

See the last line, placement of ],

Ah, I see that in the last comment, you also moved the ], I moved both the ] and ,, otherwise you have such a floating ,

yep, fixed up

@jreback with https://github.com/jorisvandenbossche/pandas/commit/77ee027d4f0fcb6e8219101378a37685621c1203, this solves the too much white space (two spaces between the items, and two at beginning of row)

updated to fix the smaller ones (commas were not there)
In [3]: Index(range(1-5),name='foo')
Out[3]: Index([], dtype='object', name=u'foo')

In [4]: Index(range(105),name='foo')
Out[4]:
Int64Index([    0,    1,    2,    3,    4,    5,    6,    7,    8,    9
             ...
               95,   96,   97,   98,   99,  100,  101,  102,  103,  104],
           dtype='int64', name=u'foo', length=105)

In [5]: pd.date_range('20130101',freq='s',periods=5,name='foo')
Out[5]:
DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',
                 '2013-01-01 00:00:02',  '2013-01-01 00:00:03',
                 '2013-01-01 00:00:04'],
              dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [6]: pd.date_range('20130101',freq='s',periods=25,name='foo')
Out[6]:
DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',
                 '2013-01-01 00:00:02',  '2013-01-01 00:00:03',
                 '2013-01-01 00:00:04',  '2013-01-01 00:00:05',
                 '2013-01-01 00:00:06',  '2013-01-01 00:00:07',
                 '2013-01-01 00:00:08',  '2013-01-01 00:00:09',
                 '2013-01-01 00:00:10',  '2013-01-01 00:00:11',
                 '2013-01-01 00:00:12',  '2013-01-01 00:00:13',
                 '2013-01-01 00:00:14',  '2013-01-01 00:00:15',
                 '2013-01-01 00:00:16',  '2013-01-01 00:00:17',
                 '2013-01-01 00:00:18',  '2013-01-01 00:00:19',
                 '2013-01-01 00:00:20',  '2013-01-01 00:00:21',
                 '2013-01-01 00:00:22',  '2013-01-01 00:00:23',
                 '2013-01-01 00:00:24'],
              dtype='datetime64[ns]', name=u'foo', freq='S', tz=None)

In [7]: pd.date_range('20130101',freq='s',periods=105,name='foo')
Out[7]:
DatetimeIndex([  '2013-01-01 00:00:00',  '2013-01-01 00:00:01',
                 '2013-01-01 00:00:02',  '2013-01-01 00:00:03',
                 '2013-01-01 00:00:04',  '2013-01-01 00:00:05',
                 '2013-01-01 00:00:06',  '2013-01-01 00:00:07',
                 '2013-01-01 00:00:08',  '2013-01-01 00:00:09'
                ...
                 '2013-01-01 00:01:35',  '2013-01-01 00:01:36',
                 '2013-01-01 00:01:37',  '2013-01-01 00:01:38',
                 '2013-01-01 00:01:39',  '2013-01-01 00:01:40',
                 '2013-01-01 00:01:41',  '2013-01-01 00:01:42',
                 '2013-01-01 00:01:43',  '2013-01-01 00:01:44'],
              dtype='datetime64[ns]', name=u'foo', length=105, freq='S', tz=None)

There is a comma missing at the and of the last row of the first block of rows (or is this on purpose?)
Did you see my last comment (with fix for spacing)?

ok, updated the top section

@jreback one thing: there are still too much spaces between the elements (see https://github.com/pydata/pandas/pull/9901#issuecomment-99517210 for fix), which causes that the lines gets too long in certain cases. I would say to take 1 space (see fix), or if you want two, then the n_per_row has to be adjusted.
Example:
In [1]: pd.Index(range(24))
Out[1]:
Int64Index([   0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  1
3,  14,  15,  16,
              17,  18,  19,  20,  21,  22,  23],
           dtype='int64')

@jorisvandenbossche ok updated the top-section again.

@jreback awesome!
@sinhrks @mortada @shoyer @TomAugspurger and others. Could you play a bit with this?

going once, going twice........

OK I'll test this out right now...

I'm not a big fan of the way truncating looks with multiple lines right now. For example:
In [29]: pd.Index(['asd', 'zx', 'a'] * 10000)
Out[29]:
Index([u'asd',  u'zx',   u'a', u'asd',  u'zx',   u'a', u'asd',  u'zx',   u'a',
       u'asd',
       ...
         u'a', u'asd',  u'zx',   u'a', u'asd',  u'zx',   u'a', u'asd',  u'zx',
         u'a'],
      dtype='object', length=30000)

In [40]: pd.Index(np.arange(2000) * 100)
Out[40]:
Int64Index([     0,    100,    200,    300,    400,    500,    600,    700,
               800,    900,
            ...
            199000, 199100, 199200, 199300, 199400, 199500, 199600, 199700,
            199800, 199900],
           dtype='int64', length=2000)

My vote would probably be for showing not quite as many elements in the truncated version (3?) and putting everything on line (at least the array elements). Closer to the one of the earlier versions:
In [3]: pd.date_range('20130101',periods=80)
Out[3]: DatetimeIndex(['2013-01-01', '2013-01-02', ..., '2013-03-20', '2013-03-21'], dtype='datetime64[ns]', length=80, freq='D', tz=None)

In [4]: Index(range(8))
Out[4]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7], dtype='int64')

In [5]: Index(range(10))
Out[5]: Int64Index([0, 1, ..., 8, 9], dtype='int64')

In [6]: Index(range(10),name='foo')
Out[6]: Int64Index([0, 1, ..., 8, 9], name=u'foo', dtype='int64')

I know this is arguably less consistent with the logic for displaying series and frames, but I think it looks better.

But to be clear, I would not hold up the release for my objections. Any of these changes are better than what we have now.

the truncating: it looks off in this case beacause the length of the strings used are so that there is just only one element on the second line. I think there are some options:

we could detect that and fill the rest of the line (but, we don't know the length of the following elements in advance, so that may break the aligning
we could also use not a fixed number of values, but just one full row, the dots, a full row with the last elements. So for datetimes it is then maybe the first and last 2 elements, for integers it can be more?
Or we could also decide to return max_seq_len number of items, so  max_seq_len/2 first and last. Then the line in the middle will not be that prominent
or the suggestion of @shoyer (this is also how numpy does it)

Something else I realized: this aligning is not really ideal for column names. Example:

In [10]: pd.Index(['datetime', 'sA', 'sB', 'sC', 'flow', 'error', 'temp', 'ref',
'and_a_longer_one'])
Out[10]:
Index([        u'datetime',               u'sA',               u'sB',
u'sC',             u'flow',            u'error',
u'temp',              u'ref', u'and_a_longer_one'],
dtype='object')

And apparantly, numpy does not align arrays of object dtype (which has some logic, as these have a higher chance of being of different length). Maybe we should follow that?

In [12]: pd.Index(['datetime', 'sA', 'sB', 'sC', 'flow', 'error', 'temp', 'ref',
'and_a_longer_one']*3).values
Out[12]:
array(['datetime', 'sA', 'sB', 'sC', 'flow', 'error', 'temp', 'ref',
'and_a_longer_one', 'datetime', 'sA', 'sB', 'sC', 'flow', 'error',
'temp', 'ref', 'and_a_longer_one', 'datetime', 'sA', 'sB', 'sC',
'flow', 'error', 'temp', 'ref', 'and_a_longer_one'], dtype=object)

@shoyer @jorisvandenbossche
slight modification; I print now 2 head and 2 tail on the truncated display; each line is justified itself (but maxlen are the same). Doesn't affect fixed width types like datetimelikes, but integers look better, mixed width strings are somewhat better I think
In [1]:    pd.get_option('max_seq_items')
Out[1]: 100

In [2]:    pd.Index(range(4),name='foo')
Out[2]: Int64Index([0, 1, 2, 3], dtype='int64', name=u'foo')

In [3]:    pd.Index(range(25),name='foo')
Out[3]:
Int64Index([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
            17, 18, 19, 20, 21, 22, 23, 24],
           dtype='int64', name=u'foo')

In [4]:    pd.Index(range(104),name='foo')
Out[4]:
Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
            10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
            ...
            84, 85, 86, 87, 88, 89, 90, 91, 92, 93,
            94, 95, 96, 97, 98, 99, 100, 101, 102, 103],
           dtype='int64', name=u'foo', length=104)

In [5]:    pd.CategoricalIndex(['a','bb','ccc','dddd'],ordered=True,name='foobar')
Out[5]: CategoricalIndex([u'a', u'bb', u'ccc', u'dddd'], categories=[u'a', u'bb', u'ccc', u'dddd'], ordered=True, name=u'foobar', dtype='category')

In [6]:    pd.CategoricalIndex(['a','bb','ccc','dddd']*10,ordered=True,name='foobar')
Out[6]:
CategoricalIndex([   u'a',   u'bb',  u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',  u'ccc', u'dddd',
                     u'a',   u'bb',  u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',  u'ccc', u'dddd',
                     u'a',   u'bb',  u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',  u'ccc', u'dddd',
                     u'a',   u'bb',  u'ccc', u'dddd'],
                 categories=[u'a', u'bb', u'ccc', u'dddd'], ordered=True, name=u'foobar', dtype='category')

In [7]:    pd.CategoricalIndex(['a','bb','ccc','dddd']*100,ordered=True,name='foobar')
Out[7]:
CategoricalIndex([   u'a',   u'bb',  u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',  u'ccc', u'dddd',
                     u'a',   u'bb',  u'ccc', u'dddd',
                  ...
                     u'a',   u'bb',  u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',
                   u'ccc', u'dddd',    u'a',   u'bb',  u'ccc', u'dddd',
                     u'a',   u'bb',  u'ccc', u'dddd'],
                 categories=[u'a', u'bb', u'ccc', u'dddd'], ordered=True, name=u'foobar', dtype='category', length=400)

In [8]:    pd.date_range('20130101',periods=4,name='foo',tz='US/Eastern')
Out[8]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00'],
              dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [9]:    pd.date_range('20130101',periods=25,name='foo',tz='US/Eastern')
Out[9]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00', '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00', '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00', '2013-01-10 00:00:00-05:00',
               '2013-01-11 00:00:00-05:00', '2013-01-12 00:00:00-05:00',
               '2013-01-13 00:00:00-05:00', '2013-01-14 00:00:00-05:00',
               '2013-01-15 00:00:00-05:00', '2013-01-16 00:00:00-05:00',
               '2013-01-17 00:00:00-05:00', '2013-01-18 00:00:00-05:00',
               '2013-01-19 00:00:00-05:00', '2013-01-20 00:00:00-05:00',
               '2013-01-21 00:00:00-05:00', '2013-01-22 00:00:00-05:00',
               '2013-01-23 00:00:00-05:00', '2013-01-24 00:00:00-05:00',
               '2013-01-25 00:00:00-05:00'],
              dtype='datetime64[ns]', name=u'foo', freq='D', tz='US/Eastern')

In [10]:    pd.date_range('20130101',periods=104,name='foo',tz='US/Eastern')
Out[10]:
DatetimeIndex(['2013-01-01 00:00:00-05:00', '2013-01-02 00:00:00-05:00',
               '2013-01-03 00:00:00-05:00', '2013-01-04 00:00:00-05:00',
               '2013-01-05 00:00:00-05:00', '2013-01-06 00:00:00-05:00',
               '2013-01-07 00:00:00-05:00', '2013-01-08 00:00:00-05:00',
               '2013-01-09 00:00:00-05:00', '2013-01-10 00:00:00-05:00',
               '2013-01-11 00:00:00-05:00', '2013-01-12 00:00:00-05:00',
               '2013-01-13 00:00:00-05:00', '2013-01-14 00:00:00-05:00',
               '2013-01-15 00:00:00-05:00', '2013-01-16 00:00:00-05:00',
               '2013-01-17 00:00:00-05:00', '2013-01-18 00:00:00-05:00',
               '2013-01-19 00:00:00-05:00', '2013-01-20 00:00:00-05:00',
               ...
               '2013-03-26 00:00:00-04:00', '2013-03-27 00:00:00-04:00',
               '2013-03-28 00:00:00-04:00', '2013-03-29 00:00:00-04:00',
               '2013-03-30 00:00:00-04:00', '2013-03-31 00:00:00-04:00',
               '2013-04-01 00:00:00-04:00', '2013-04-02 00:00:00-04:00',
               '2013-04-03 00:00:00-04:00', '2013-04-04 00:00:00-04:00',
               '2013-04-05 00:00:00-04:00', '2013-04-06 00:00:00-04:00',
               '2013-04-07 00:00:00-04:00', '2013-04-08 00:00:00-04:00',
               '2013-04-09 00:00:00-04:00', '2013-04-10 00:00:00-04:00',
               '2013-04-11 00:00:00-04:00', '2013-04-12 00:00:00-04:00',
               '2013-04-13 00:00:00-04:00', '2013-04-14 00:00:00-04:00'],
              dtype='datetime64[ns]', name=u'foo', length=104, freq='D', tz='US/Eastern')

ok, updated on the top of the PR. here are basically the rules:

0, 1, 2 values on a single line, no justification
if we are < max_seq_items, wrap the output to make multi-line; no justification (datetimelikes are 'naturally justfiied though, they just line up)
if we are >= max_seq_items, truncate. Justify non (string,categorical), print head/tail lines, these will wrap (e.g. have more than one line) for things that are datetimelike, but for strings, integers, they will not wrap at all (e.g. only 1 line)

The last point is a slight deviation as it then doesn't justify say integers for a categorical (but make the code a bit simpler, and though it looked a bit better - though my categorical examples of 1000 categories makes it look worse...oh well).

@jreback While on the train I made an alternative implementation to allow an unequal number of elements on one row, based on this branch (https://github.com/jorisvandenbossche/pandas/commit/8ff7998bbca6773a658cb211a701ae14eeaea92e). It is partly based on the array2string function of numpy.
The advantage is that the number of elements on all rows don't have to be equal, it just fills the row up to display width. As a consequence, this (all 3 elements on each row because of one larger string):
In [8]: pd.Index(['datetime', 'sA', 'sB', 'sC', 'flow', 'error', 'temp', 'ref', 'a_bit_a_longer_one']*2)
Index([u'datetime', u'sA', u'sB',
       u'sC', u'flow', u'error',
       u'temp', u'ref', u'and_a_longer_one',
       u'datetime', u'sA', u'sB',
       u'sC', u'flow', u'error',
       u'temp', u'ref', u'and_a_longer_one'],
      dtype='object')

now looks as:
In [5]: pd.Index(['datetime', 'sA', 'sB', 'sC', 'flow', 'error', 'temp', 'ref','a_bit_a_longer_one']*2)
Out[5]:
Index([u'datetime', u'sA', u'sB', u'sC', u'flow', u'error', u'temp', u'ref',
       u'a_bit_a_longer_one', u'datetime', u'sA', u'sB', u'sC', u'flow',
       u'error', u'temp', u'ref', u'a_bit_a_longer_one'],
      dtype='object')

which looks a bit better in my opinion (but you can give more extreme examples where the difference is larger).
For the rest, everything looks exactly the same as before (the latest update of this PR). The only difference is that the justifying or not (depending on string/categorical or not) is now the same for truncated and non-truncated (as I do this with the same code), while in the latest update you made it not justify for non-truncated ones (but I think doing it the same is a bit more consistent).

ok let me incorporate this and I'll update the top section

@jorisvandenbossche @shoyer ok, updated with joris commit. I had to change around slightly the code to avoid justification in certain cases, e.g. here's you don't want to justify otherwise the NaT would have a very long string (basically if its going to be 1 line and its non-truncated, then you don't justify)
In [13]: PeriodIndex(['2011-01-01 09:00', '2012-02-01 10:00', 'NaT'], freq='H')
Out[13]: PeriodIndex(['2011-01-01 09:00', '2012-02-01 10:00', 'NaT'], dtype='int64', freq='H')

Ah, yes, the case of 1 line not needing justification, I forgot, thanks!
There are some more details we could improve, but I think this is looking good for now!
For later (follow-up PR), I was thinking of:

also splitting the attributes part over multiple lines if this is very long

for truncated output: now hard-code at 10 elements, but this could maybe also be 1 line? (and possibly with a minimum number of elements for longer strings) Because now, small integers don't fill the full line with 10 elements, and eg floats there is one element on the second line:

In [7]: pd.Index(np.arange(400.))
Out[7]:
Float64Index([  0.0,   1.0,   2.0,   3.0,   4.0,   5.0,   6.0,   7.0,   8.0,
9.0,
...
390.0, 391.0, 392.0, 393.0, 394.0, 395.0, 396.0, 397.0, 398.0,
399.0],
dtype='float64', length=400)
This could eg easily be restricted to two times one line.

@jorisvandenbossche yes, I was trying to avoid the wrap-around with a small number of elements, in fact thats why the example used 100 for display.width; if its too short you get that kind of effect.
ok, bombs aways. And will add a follow-up issue.


[Bug]: Missing information from Dev Guide and auto cut issues

Describe the bug

With every release, build repo cuts autocut issues in the repo like:
a. https://github.com/opensearch-project/flow-framework/issues/500
b. https://github.com/opensearch-project/skills/issues/178

The issue just mentions to run
Received Error: Error building skills, retry with: ./build.sh manifests/2.12.0/opensearch-2.12.0.yml --component skills.

The above information is incomplete without linking the build.sh file of opensearch-build repo or if present in the repo itself.

To run the build script, OpenSearch should be published to maven local. Otherwise, it would fail with the below:

A problem occurred configuring root project 'opensearch-skills'.
> Could not resolve all files for configuration ':classpath'.
   > Could not find org.opensearch.gradle:build-tools:2.12.0.
     Searched in the following locations:
       - file:/home/ubuntu/.m2/repository/org/opensearch/gradle/build-tools/2.12.0/build-tools-2.12.0.pom
       - https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/gradle/build-tools/2.12.0/build-tools-2.12.0.pom
       - https://plugins.gradle.org/m2/org/opensearch/gradle/build-tools/2.12.0/build-tools-2.12.0.pom
       - https://repo.maven.apache.org/maven2/org/opensearch/gradle/build-tools/2.12.0/build-tools-2.12.0.pom
     Required by:
         project :

* Try:

There's no mention of the same in https://github.com/opensearch-project/opensearch-build/blob/main/DEVELOPER_GUIDE.md or if there's any other documentation where it's mentioned should be linked in the auto cut issues.
To reproduce

Run ./build.sh manifests/2.12.0/opensearch-2.12.0.yml --component <component-name> without publishing OpenSearch to maven local.

Expected behavior

Dev guide should mention the above details

Screenshots
If applicable, add screenshots to help explain your problem.
Host / Environment
No response
Additional context
No response
Relevant log output
No response

[Triage]
By default when executed ./build.sh manifests/2.12.0/opensearch-2.12.0.yml, this will build all components in an order (which are already ordered as per dependencies in manifest), for any component (--component skills) OpenSearch core is the mandatory requirement, hence in this case ./build.sh manifests/2.12.0/opensearch-2.12.0.yml --component OpenSearch skills should work as long as skills just depends only on OpenSearch. Its good to add this line in Build Workflow that shows users to add dependency components with --component flag.


test: keep platform_output as first test

When sorting tests, keeps platform_output as the first test.

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/520/

Why though?  It doesn't bother me that it's no longer first.

Its a matter of taste I guess. It always produces output, I like it more where first you have compilation, then platform output and then only lines starting with ok ..

Landed in https://github.com/libuv/libuv/commit/bdbae7d46b1ce67f6cfb387b9532c1834f977b8c


Scraper hangs if page takes too long to render

Running the latest version of node.js (12), images-scraper, on OS X Mojave.
When running the code, sometimes the page takes too long to render - so when it is instructed to scroll there are no scrollbars and it cannot reach the end of the page. I've "fixed" this by adding a one-second delay:
await page.setUserAgent(self.userAgent);
await page.waitFor(1000); // Add one second delay to ensure scrollbars are present

I'm not all that familiar with puppeteer, so am not sure if this works the way I think it does, and not sure if there is a better way to do this. However, I can no reliably run results w/o it stopping (100 test runs so far).

The other possibility is that ksb._kvc never appears on the page sometimes.

Thanks for finding this issue @ururk
I think it would be better to wait for page load. That can be achieved by doing this right after to goto:
page.waitForNavigation({ waitUntil: 'networkidle0' });

Great! I'm still getting the same issue though - page loads but does not find any results. What I've found, is every time this happens, the meta JSON dos not load on the page (no .rg_meta element) nor are there any .rg_l elements. I see some errors in the web browser console:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'report-sample' 'nonce-5fBQzWdGZVpdbsJiddVttw' 'unsafe-inline'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.

addScriptContent @ VM52 __puppeteer_evaluation_script__:7

No network errors, though, so I'm at a slight loss as to why this is happening. I even tried updating to the latest puppeteer (which includes a newer Chromium) and am still having problems.

Thanks for investigating @ururk . I can't seem to reproduce it
The error you see might be resolved by doing this: https://github.com/puppeteer/puppeteer/blob/master/docs/api.md#pagesetbypasscspenabled
Can you please try? Thanks, I'm reopening this issue.

I managed to reproduce it @ururk . I think this fixes it. I'm pushing it to a new version shortly.

This appears to fix it - I'll run some test searches and let you know how it goes.

I've done about 50 searches - this fixes the problem! I still have random Chromium crashes, but I don't think it's related to this node module's code.


Install boost in gcc container

I have not tested this so no idea if it works. Found it online.

Superseded by #68

Awesome thanks


Reoccurence required for scan?

"if you DONT schedule a recurrence, it will fail" - need to investigate some more

Ideally enforced by form.
Jam in today's date here?  https://github.com/rackerlabs/scantron/blob/master/master/scan_scheduler.py#L77

https://github.com/rackerlabs/scantron/pull/61 should have fixed this.  Allows for setting a single, non-recurring scan to occur the day it is submitted (today).


Add projects

Contradictory to previous flat file structure in types.rs the whole thing is now split over several files/ modules for organisation.
TODO:

[ ] Write Query implementations for Project and Version
[x] Provide getters and setters where needed.
[ ] Provide getting Version bytes for downloading.
[ ] Provide documentation.
[ ] Write relevant tests.
[x] Remove relevant types from types.rs.

closes #2

@pie-flavor can you start reviewing this... i want to make sure that i dont have do major overhaul after this PR is merged


Not able to lock

am trying with "slide to lock".
while tapping & dragging on thumnailImageView am notable to close the lock.
it is coming back again to same position. tried multiple times

If you want to keep the thumbnail in lock position, don't call function resetStateWithAnimation in the delegate.
You can see in my example project
    func mtSlideToOpenDelegateDidFinish(_ sender: MTSlideToOpenView) {
        let alertController = UIAlertController(title: "", message: "Done!", preferredStyle: .alert)
        let doneAction = UIAlertAction(title: "Okay", style: .default) { (action) in
            sender.resetStateWithAnimation(false)
        }
        alertController.addAction(doneAction)
        self.present(alertController, animated: true, completion: nil)

    }

Please comment the line sender.resetStateWithAnimation(false)

i got one more issue here
am using multiple English, Arabic languages in my app
While using english the slidingButton is working fine. And i can swipe
the thumNailImage from left to right.
But, when am using Arabic, the slidingButton is not working. am not able
to swipe the thumNailImage from right to left
Could you help me regarding this issue
--
Thanks & Regards
Bhanuteja


Same API in different tomcat server is not working

Tested API in tomcat server1 working as expected. Same API tested in tomcat sever2.
Getting Error.
Expected outcome
API should work both in tomcat server1 and tomcat server2
Actual outcome
In tomcat server2, getting error - The requested URL can't be reached
Versions
App: 10.0.12
Platform: 5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Steps to reproduce

Same api run in two different tomcat servers.
Run in ARC in both servers

The HTTP message sent from the app is guaranteed to be the same. Variables may change like cookies or other headers but the generated message is always the same. If the app works for one API and it does not for the other one then the API is down, url is different or some other issue. I see that the other request returns 0 status. This status means that conneciton to the resver cannot be setablished. This then means that the API is down.
In any case there's noting to do for me.


Popper.js/Dropdowns - Incorrect Positioning  when body or html have height:100%

Bootstrap v4 Beta
Code Pen:
https://codepen.io/h3christophe/pen/ZJXqJo
Basically if your html or body tag have a height:100%  the dropdowns will be positioned incorrectly
You can see the behavior in the code pen, if you click on a dropdown menu positioned below the view port (meaning you need to scroll down)
http://i.imgur.com/6A4LCHw.jpg
Easy fix is to use min-height:100% instead

Not everyone will have minimum height, some apps I create uses dynamic min-height (changes upon content); this may cause a problem. I raised an issue earlier regarding this https://github.com/twbs/bootstrap/issues/23378#issuecomment-322058629
The custom JS styling offered by popper.js might be needed in most cases.

This is a serious problem for layouts with sidebar: min-height can fix it, but only partially - you can't stretch child flex container properly as child min-height is ignored. Any solution?

@Kopyov you will run into issues with IE later.

@myorangeca Yep you are right, sorry - IE doesn't work well with flex and vh. Removed from my previous comment.

Thank you to report that issue but we cannot fixed it here because it's a positioning issue with Popper.js maybe @FezVrasta know if this is a well known issue

@Johann-S maybe we should keep this opened as popper.js is a BS4 dependency.

There's already an issue with a lot of informations https://github.com/FezVrasta/popper.js/issues/302
If anyone wants to work on it please leave a comment in the issue


perform thermal analysis of walls and heating element

calculate wire temperatures and chamber wall power losses at design temperatures
Outputs:

heating element dT at design temperature
graphs of results
- wall thickness vs power
- wire area vs dT
- furnace power loss vs chamber temperature
- wire [area, power, temperature] assuming a cold chamber (STP) to calculate max wire power

--- Conservative estimate ---
Chamber dimensions: 76mm of brick, 200mm of rock wool
Required power: 112W @ 1100C


python311Packages.netutils: 1.5.0 -> 1.6.0

Diff: https://github.com/networktocode/netutils/compare/refs/tags/v1.5.0...v1.6.0
Changelog: https://github.com/networktocode/netutils/releases/tag/v1.6.0
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 254598 run on x86_64-linux 1

4 packages built:

python310Packages.netutils
python310Packages.netutils.dist
python311Packages.netutils
python311Packages.netutils.dist


Some questions about the dimension

hello, the shape of tensor in vit seem to be (patch_num ** 2 + 1, bs, dim), however, in the released code, B, N, C = x.shape is used. Is it correct or just a mistake?

Hi, I think it is correct in the code.
In timm's implementation, the shape of  input for each transformer layer is (batch_size, token_num, dim). It is (batch_size, 197, 768) in ViT-B/16. See https://github.com/rwightman/pytorch-image-models/blob/master/timm/models/vision_transformer.py#L200


feat: annotation layers CRUD list view

SUMMARY

[x] Convert annotation layers list view to a react page
[x] New view is accessible via the SIP_34_ANNOTATIONS_UI feature flag
[x] Update list view empty state to use new graphic and accept custom empty message + UI (ex. buttons)

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

[x] Add spec file for AnnotationLayersList
[x] Update python tests

ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #11432 into master will decrease coverage by 4.99%.
The diff coverage is 72.72%.

@@            Coverage Diff             @@
##           master   #11432      +/-   ##
==========================================
- Coverage   66.62%   61.63%   -5.00%
==========================================
  Files         860      416     -444
  Lines       40881    25912   -14969
  Branches     3693        0    -3693
==========================================
- Hits        27238    15971   -11267
+ Misses      13545     9941    -3604
+ Partials       98        0      -98

Flag
Coverage Δ

#cypress
?

#javascript
?

#python
61.63% <72.72%> (-0.30%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/annotation_layers/api.py
82.14% <ø> (ø)

superset/views/annotations.py
78.94% <72.72%> (-1.49%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/databases/commands/create.py
82.97% <0.00%> (-8.52%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/utils/celery.py
82.14% <0.00%> (-3.58%)
:arrow_down:

superset/datasets/api.py
89.38% <0.00%> (-3.36%)
:arrow_down:

superset/models/core.py
86.07% <0.00%> (-3.07%)
:arrow_down:

superset/databases/api.py
87.73% <0.00%> (-2.84%)
:arrow_down:

... and 456 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 604a519...e652270. Read the comment docs.


AE2WTLib-1.2.5 incompatibilty with release version of AE2 8.4.0

The latest 1.16 compatible release, 1.2.5, is incompatible with 8.4.0, even though it is compatible with 8.4.0-alpha3, seemingly being limited only by a far-too-strict version check.

looking at ae2's curseforge page, there is no version 8.4.0 for fabric, only 8.4.0-alpha3, which is the latest (and last fabric 1.16 version of ae2).


Fix

Codecov Report

Merging #19 (e0c7c70) into master (ef78681) will increase coverage by 5.74%.
Report is 7 commits behind head on master.
The diff coverage is 91.03%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
+ Coverage   74.08%   79.83%   +5.74%
==========================================
  Files           8        8
  Lines         355      481     +126
==========================================
+ Hits          263      384     +121
- Misses         92       97       +5

Files Changed
Coverage Δ

source/serializer.cpp
0.00% <0.00%> (ø)

source/tokenizer.cpp
62.43% <ø> (ø)

source/tokenizer_test.cpp
100.00% <ø> (ø)

source/parser.cpp
89.74% <92.75%> (+4.02%)
:arrow_up:

source/lexer.cpp
92.30% <100.00%> (+1.39%)
:arrow_up:

source/lexer_test.cpp
100.00% <100.00%> (ø)

source/parser_test.cpp
100.00% <100.00%> (ø)


Execution failed for task ':kernel:cpp:makeCRunLib'

When I run command ./gradlew --no-daemon build I will get error:
:kernel:cpp:makeCRunLib FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':kernel:cpp:makeCRunLib'.
A problem occurred starting process 'command 'clang++'

How to fix: install clang++
To check version: clang++ --version
How to reproduce: remove clang++, remove folder beakerx/kernel/cpp/build, remove autogenerated files (cpp, cpp.bat, CppKernel.h, libCRun.jnilib) on folder beakerx/kernel/cpp/src/main/resources
I propose to add clang++ to Dependencies

dup of https://github.com/twosigma/beakerx/issues/5429


server-set properties should not be required in create method calls

preface: I'm new to working with JMAP so maybe I'm misunderstanding how things work. but assuming I'm not...
the JMAP spec indicates that "server-set" properties of objects should not be submitted by the client when creating these objects:

server-set – Only the server can set the value for this property. The client MUST NOT send this property when creating a new object of this type.

This seems to be contradicted by the current type annotations on this library. For example, Email object properties id blobId threadId and others marked as server-set (per JMAP Mail spec):

id: Id (immutable; server-set) The id of the Email object. Note that this is the JMAP object id, NOT the Message-ID header field value of the message [@!RFC5322].
blobId: Id (immutable; server-set) The id representing the raw octets of the message [@!RFC5322] for this Email. This may be used to download the raw original message or to attach it directly to another Email, etc.
threadId: Id (immutable; server-set) The id of the Thread to which this Email belongs.

However when trying to create an email using this library with the following code (with tsconfig strict enabled):
import Jam from "jmap-jam";

const env = process.env;

const jam = new Jam({
	bearerToken: env.JMAP_TOKEN!,
	sessionUrl: env.JMAP_URL!,
});

const accountId = await jam.getPrimaryAccount();

await jam.api.Email.set({
	accountId,
	create: {
		testDraftId: {
			subject: "hi",
		},
	},
	ifInState: null,
	update: null,
	destroy: null,
        // some other properties omitted for brevity, e.g. `from` `to` `bodyStructure` `bodyValues`
});

we get a type error saying properties id blobId threadId and others are missing:

This seems incorrect, one because it seems to contradict the spec and two because how would I come up with the correct values for these properties when creating an email on the client side?
Also, notice that the email creation example in the JMAP Mail documentation also does not include these fields in the sample request submission.

Thanks for noting this! Likely an oversight on my part when assembling these types. I'll take a closer look!

This was a really good find. I did not appropriately account for server-set fields (likely because I use JMAP for reading emails rather than writing emails).
I'll focus on fixing this in the next release, but it may be some time until I pick it up to work on.

@kwshi I believe v0.8.0 should unblock you, though there is more I'd like to do to improve these types in the future.
Thank you again for raising this issue!


Upgraded Spark to 3.1.0 + fixed tests

Codecov Report

Merging #305 (714c3a3) into develop (d0c77f4) will not change coverage.
The diff coverage is 100.000%.

@@             Coverage Diff             @@
##            develop       #305   +/-   ##
===========================================
  Coverage   100.000%   100.000%
===========================================
  Files            36         36
  Lines          3069       3070    +1
===========================================
+ Hits           3069       3070    +1

Impacted Files
Coverage Δ

src/clojure/zero_one/geni/core/polymorphic.clj
100.000% <100.000%> (ø)

Codecov Report

Merging #305 (714c3a3) into develop (d0c77f4) will not change coverage.
The diff coverage is 100.000%.

@@             Coverage Diff             @@
##            develop       #305   +/-   ##
===========================================
  Coverage   100.000%   100.000%
===========================================
  Files            36         36
  Lines          3069       3070    +1
===========================================
+ Hits           3069       3070    +1

Impacted Files
Coverage Δ

src/clojure/zero_one/geni/core/polymorphic.clj
100.000% <100.000%> (ø)


The download link of .deb package of 1.50.0 version is wrong in learn.microsoft.com

The download link of .deb package of 1.50.0 version is wrong in learn.microsoft.com
The short link is https://go.microsoft.com/fwlink/?linkid=2282287 which refer to 1.49.1 version but it must refer to 1.50.0 version

It seems this issue has been resolved. Can we close it now?
Now, the short link is https://go.microsoft.com/fwlink/?linkid=2298051 which refer to 1.50.0 version


[Suggestion] Preload the next picture to watch

When we're watching a picture, it could be interesting to load in memory/cache, the next picture, or even the 2 next pictures, in order to have a more comfortable watching. (if it is technically possible).

I would love to see this return to Lychee's feature list! When showing pictures outside my home, it can be kind of tiring. Are you planning to find a solution for this?

+1
The image loading behavior really is the biggest sore point for me, it
takes away so much from the otherwise stellar user experience. I really
love the bounce when images are in cache, it makes a positive feeling.
On Mon, Jun 29, 2015 at 1:31 PM, 1337sup3rh4x0r<EMAIL_ADDRESS>wrote:

I would love to see this return to Lychee's feature list! When showing
pictures outside my home, it can be kind of tiring. Are you planning to
find a solution for this?
—
Reply to this email directly or view it on GitHub
https://github.com/electerious/Lychee/issues/185#issuecomment-116622226.

Well the bounce might be nice, but more importantly I would like to be able to minimize blank screen times when showing pictures to others.
The audience's attention is lost too easily ;)

Here's more about the technical problem: https://github.com/electerious/Lychee/issues/361#issuecomment-111722979

I just discovered that the "next" and "previous" buttons contains a preview (thumb) of the corresponding next and previous image.
If, instead of a preview (thumb), Lychee displays the full images then the image will be fetched by the browser and will be cached by the browser for the full display.
Side effects:

The next and previous buttons background images will be slower to load but that should be transparent for most users.
Also the display of the first image would load 3 full size images (main image + background for next and previous buttons) but that is the price to pay to have images preload.

You still have to make sure that the current image will be loaded first.

@kgraefe That is not possible.
The price for preload is that (at most) 3 images are loaded at the same time. This should happen only for the first image of the album. After that, the next (or previous) image is already available in the browser cache so will be displayed immediately.

It still doesn't sound like a clean solution to me and it will make things worse for people that don't care about this issue but loading time (and that nobody figured out how to do it properly yet does not mean that it is not possible. ;-)).
However it's not me to define the priorities of Lychee here.

I think this sounds like the ideal solution! I encourage to take this path :)

I finally found some time to implement my idea. See patch at https://github.com/LudovicRousseau/Lychee/commit/49137c7a415018f5aef74be14e1c8237ec5d3e62
The idea is to use the next image as the background image of the "next image" button. You can see that the background image is not displayed immediately.
I have not changed the "previous image" button. The previous image should already be in the browser cache.
You can try by yourself by cloning my prefetch branch https://github.com/LudovicRousseau/Lychee/tree/prefetch. The files have been regenerated. @kgraefe and all, please test it and comment.

A new updated version of my patch (to match current master) is at https://github.com/LudovicRousseau/Lychee/commit/bdebfb0afad05a8511d3b0f6ab1bbfde98c1c154

prefetching cloud be the perfect solution for this issue.

If we're certain that a specific resource will be required in the future, then we can ask the browser to request that item and store it in the cache for reference later. For example an image or a script, or really anything that's cacheable by the browser […] prefetching can be ignored by the browser. For example, a client might abandon the request of a large font file on a slow network. Firefox will only prefetch resources when "the browser is idle".

Just tested it with Chrome and it also works when adding the prefetch-link via JS.
$('head').append('<link rel="prefetch" href="test.jpg">')

Source: https://css-tricks.com/prefetching-preloading-prebrowsing/

@electerious prefetching looks like the perfect solution. Please implement it.
For users that do not want to prefetch the next image they can disable it, at least in Firefox https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ#Is_there_a_preference_to_disable_link_prefetching.3F

It's also possible to disable it in Chrome, but I think the browser knows best when to prefetch. Will implement it!

\o/
On Sun, Sep 20, 2015 at 1:55 PM, Tobias Reich<EMAIL_ADDRESS>wrote:

It's also possible to disable it in Chrome, but I think the browser knows
best when to prefetch. Will implement it!
—
Reply to this email directly or view it on GitHub
https://github.com/electerious/Lychee/issues/185#issuecomment-141781431.

Prefetch works fine in my tests, but the bounce animation is still missing when opening big photos. It takes a while for the browser to render/scale the cached image.
Another problem:
The size of the next image is unknown and Lychee always preloads the big photo, but sometimes only displays the medium/down-scaled version.
Possible solutions:
a) Load both versions of the next photo
b) Use the size of the current photo to hope that the next one will have the same size

Option b) would work just fine for me. My Lychee albums typically have
pictures all of the same size.
On Sun, Sep 20, 2015 at 9:22 PM, Tobias Reich<EMAIL_ADDRESS>wrote:

Prefetch works fine in my tests, but the bounce animation is still missing
when opening big photos. It takes a while for the browser to render/scale
the cached image.
Another problem:
The size of the next image is unknown and Lychee always preloads the big
photo, but sometimes only displays the medium/down-scaled version.
Possible solutions:
a) Load both versions of the next photo
b) Use the size of the current photo to hope that the next one will have
the same size
—
Reply to this email directly or view it on GitHub
https://github.com/electerious/Lychee/issues/185#issuecomment-141822866.

Will go with b) but need to implement additional checks to ensure that a medium-version is available for the next photo.

I also realized that—even when preloading the images—the bounce animation isn't visible for big photos. It simply takes time for the browser to load, scale and render it.

The patch in https://github.com/electerious/Lychee/commit/6464d6bcc639c39d968f0c31b96fa5559164a648 does not work for me.
I use Firefox 42.0. Using the Development tools I see that the next image is loaded only when I click on the "next image" button or use the keyboard right arrow.
I also do not see the "data-prefetch" in the request header. Something is broken.
Maybe that explains why you do not see the bounce animation.

Thanks Electerious - I don't know if you have implemented the 'b' option yet, but it would definitely be the best solution.  I would have thought that the majority of people would want to share the medium sized photo, so that they load quicker, without the slow network speeds.

@LudovicRousseau Just tested it, again. Works fine for me. Here's how Chrome shows a prefetch.

@palitu 'b' hasn't been implemented, yet. Here's why:
The next version of Lychee uses <img>, instead of background-image. I found a way to center an <img> vertical and horizontal, while maintaining the aspect ratio and ensuring that the image stays within the surrounding box. This allows me to use srcset, so the browser can decide if it should display the medium or big version. They can use different parameters to make a smarter decision.
One downside: Lychee isn't aware of what the browser displays. This means we need to prefetch both versions.

right, i would go for the assumption that if medium is enabled, then
pre-fetch the medium.
just so i get it straight in my head, if medium is enabled, then all
galleries will show the medium picture?  is the edge case where the
original is smaller than the medium size?
either way, keep up the great work!  I love it!
On Fri, Jan 8, 2016 at 9:45 PM, Tobias Reich<EMAIL_ADDRESS>wrote:

@palitu https://github.com/palitu 'b' hasn't been implemented, yet.
Here's why:
The next version of Lychee uses , instead of background-image. I
found a way to center an  vertical and horizontal, while maintaining
the aspect ratio and ensuring that the image stays within the surrounding
box. This allows me to use srcset, so the browser can decide if it should
display the medium or big version. They can use different parameters to
make a smarter decision.
One downside: Lychee isn't aware of what the browser displays. This means
we need to prefetch both versions.
—
Reply to this email directly or view it on GitHub
https://github.com/electerious/Lychee/issues/185#issuecomment-170007637.

@palitu Lychee will generate a medium version when the photo is bigger than 1920x1080. It will only show the medium version when the screen is smaller than 1920x1080 or when the browser decides to do so. The pixel density of your screen will also affect those decision.

@electerious that is quiet strange. For my new test I used Chrome 47.0.2526.106 (64-bit) and the website https://l.electerious.com/ to be sure to run the same code.
I still do not have the prefetch in the headers.
And it is clear the next image is NOT prefetched. it is slow to download and display.

Do you have enabled an option in Chrome to support prefetch?
I also checked with Firefox 43.0.4 and Safari 9.0.2 and no prefetch as well.

Looks like there's a setting for it: https://support.google.com/chrome/answer/1385029?hl=en

On 08.01.2016, at 20:51, Ludovic Rousseau<EMAIL_ADDRESS>wrote:
@electerious that is quiet strange. For my new test I used Chrome 47.0.2526.106 (64-bit) and the website https://l.electerious.com/ to be sure to run the same code.
I still do not have the prefetch in the headers.
And it is clear the next image is NOT prefetched. it is slow to download and display.
Do you have enabled an option in Chrome to support prefetch?
I also checked with Firefox 43.0.4 and Safari 9.0.2 and no prefetch as well.
—
Reply to this email directly or view it on GitHub.

I just discovered that the Firefox module uBlock Origin https://addons.mozilla.org/fr/firefox/addon/ublock-origin/ disables the Firefox network.prefetch-next option https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ
But that does not explain why if does not work either on Chrome and Safari.

An even with Firefox option network.prefetch-next set to true I still do not have prefetch on Firefox :-(

Not sure why. Maybe your browser decides not to prefetch due to your connection/device/environment. Safari does not support prefetching.

is there a cheeky way of getting the photo into cache?  actually include it
in the page, but ensure that it is invisible?
i think you had the thumbnails for prev and next as full size images, just
shrunk to fit.
we would just need to ensure that the load order is enforced if possible.
On Mon, Jan 11, 2016 at 7:34 PM, Tobias Reich<EMAIL_ADDRESS>wrote:

Not sure why. Maybe your browser decides not to prefetch due to your
connection/device/environment. Safari does not support prefetching
http://caniuse.com/#feat=link-rel-prefetch.
—
Reply to this email directly or view it on GitHub
https://github.com/electerious/Lychee/issues/185#issuecomment-170515003.

Yes, there're several ways to get a photo into cache, but prefetch looked like the best solution. Browser know when it's ok to preload images. They know when you're on a mobile device/network and when other resources finished loading. Lets use it for a while and see if we need to try a different approach.

@LudovicRousseau Do you have medium size photo enabled? Because if I understand well, prefetch is enabled only for medium size photo and it seems the example website https://l.electerious.com/ does not have medium size so it cannot be used to test the feature.
tell me if I'm wrong.

@Bramas I wanted to reuse the same site as @electerious used in https://github.com/electerious/Lychee/issues/185#issuecomment-170003380.
It worked for @electerious but not for me. That is strange. The problem may not be on the server side but on the client side with the prefect feature.
I think I will continue maintaining my patch that loads the next image in the "next" button icon. At least that works for me :-)

Ok I did not see that it works for @electerious with the same example.
I understand your problem, however I don't understand how this feature is supposed to work without medium size photo enabled. I thought this had to be enabled.

OK I found something.
First of all, when you said it didn't work for you @LudovicRousseau, you actually didn't selected the right file in the your screenshot of the developper panel:

You selected the current photo and you can see that there is another photo juste after (name start with b1e...) and this one is actually prefetched as @electerious pointed out in its own sreenshot.
This is the how it is supposed to work: the next photo is prefetched.
But there is a bug (but somewhere else):
If you look at the url of the prefetch photo (in the screen shot of @electerious at least, and with my in my own lychee website), the next BIG photo is prefetch instead of the medium one
That's something we have to fix!!

If the next picture is preloaded I assume that will make swiping through pictures smoother on iPhone. The lack of smooth swipe on iPhone is the biggest pain point for me because all of the people who I will be sharing Lychee galleries with use smart phones to view.   Without prefetching Lychee feels so unresponsive and it's making me look for other software even though I like everything else about Lychee.

Status update
Preloading has been implemented for a while now. There're only two related issues left:

https://github.com/electerious/Lychee/issues/361
https://github.com/electerious/Lychee/issues/572

I will close this issue as it's no longer relevant.


Formatter: wrap_multiple_context_managers_in_parens preview style

Implement Black's wrap_multiple_context_managers_in_parens as a preview style. The new style only applies to Py39+.
with \
     make_context_manager1() as cm1, \
     make_context_manager2() as cm2, \
     make_context_manager3() as cm3, \
     make_context_manager4() as cm4 \
:
    pass

Gets formatted as
with (
    make_context_manager1() as cm1,
    make_context_manager2() as cm2,
    make_context_manager3() as cm3,
    make_context_manager4() as cm4,
):
    pass

Black automatically detects the python version used in a file based on the syntax used. E.g. a file using match statements is Py310+. I'm unsure if we should autodetect the python version based on the syntax or rely on requires-python

I'm unsure if we should autodetect the python version based on the syntax or rely on requires-python.

I would prefer to stick to our existing configuration semantics, and not introduce any autodetection.


Attempt to publish all the dataset in one go resulted in 504 error

We got this message from an IPT administrator.
He said that he got the error after 45min or so. He is asking if this could be a memory issue and if this is safe to restart TomCat.
He mentions that the IPT logs seem to suggest the system has hung, as no new progress is added.

We have restarted tomcat, and after that republished al datasets separately. The reason is due to one single large dataset (600000 occurrences and a few million extendedmeasurementorfacts), that can't be published in isolation as well (server hangs and no indication of progress). If i extrapolate the IPT building datasets of 50000 records, it shouldn't take more than 10 minutes, so I think it's a server memory issue. Around a year ago, we published this dataset successfully, it had around 500000 records back then. How much memory is needed for such large datasets?

We have restarted tomcat, and after that republished al datasets separately. The reason is due to one single large dataset (600000 occurrences and a few million extendedmeasurementorfacts), that can't be published in isolation as well (server hangs and no indication of progress). If i extrapolate the IPT building datasets of 50000 records, it shouldn't take more than 10 minutes, so I think it's a server memory issue. Around a year ago, we published this dataset successfully, it had around 500000 records back then. How much memory is needed for such large datasets?

Ok we increased the memory from 2GB toGb and that solved the issue.

Ok we increased the memory from 2GB toGb and that solved the issue.

Thanks for the update, looks like this is resolved.


Update Node to 10.14.2

The latest update of Jest (26.0.1) requires Node >= 10.14.2 (previously >= 8.3).
Jest-action was using 10.14.1 and hence would fail. Updating to use node:10.14.2-alpine seemed to have it working again.

amazing! thank you 🙏

I ran into this issue as well when using the latest tag (1.0.2) until I switched to master in my workflow to get the latest changes:
    steps:
      - uses: actions/checkout@v2
      - name: Run Jest
-        uses<EMAIL_ADDRESS>+        uses: stefanoeb/jest-action@master

This took me a while to track down, so in case someone in the future is referencing this thread the error messages I was getting in the log output looked like this:
Test suite failed to run
ReferenceError: describe is not defined


Desktop app won't connect to Ledger Nano X

Environment

~Browser:~ Desktop app
Safe: any
Wallet: Ledger Nano X
App Version: v2.1.0
Environment:

production (mainnet)

Steps to reproduce

Connect to wallet
Select ledger
Unlock ledger
Select derivation path
Hit "Connect"

Expected result

Ledger conencts

Obtained result

When selecting "Ethereum": "There was a problem accessing your Ledger accounts."
When selecting "Ethereum ledger live": "Cannot write to HID device"
(see screenshots below)

Screenshots
With "Ethereum"

With "Ethereum ledger live":

I think this is an issue when the user first used WalletConnect, right? @matextrem

If it is the case where the user first select WalletConnect, it could be related to that. If don't it could be related to a Blockative Onboardjs problem.
Anyway, I would like to know if you can share me your logs. They are:
on Linux: ~/.config/{app name}/logs/{process type}.log
on macOS: ~/Library/Logs/{app name}/{process type}.log
on Windows: %USERPROFILE%\AppData\Roaming{app name}\logs{process type}.log
app name = 'Safe Multisig'
process type = {main,renderer}

I get the same state when I first select the WallletConnect option and then try to connect with my Ledger Nano X.

So yes, it is a problem related to WalletConnect. I gonna report it to the blocknative team.

I just restarted the app and tried to connected straight the Ledger. Now the error is
Ledger device: Incorrect length (0x6700)

Main.log:
[2020-05-13 17:18:32.750] [info] App starting...
[2020-05-13 17:18:41.888] [info] Checking for update
[2020-05-13 17:18:41.951] [info] Generated new staging user ID: f25f6527-c2b3-5a8d-9bad-58db75d554d2
[2020-05-13 17:18:47.191] [info] Update for version 2.1.0 is not available (latest version: 2.0.0, downgrade is disallowed).
[2020-05-14 10:00:52.451] [info] App starting...
[2020-05-14 10:00:54.324] [info] Checking for update
[2020-05-14 10:00:57.063] [info] Update for version 2.1.0 is not available (latest version: 2.0.0, downgrade is disallowed).

Renderer.log: renderer.log

According to the logs you sent me, it seems that you first clicked wallet connect and the QR code was shown and then you switched to Ledger, didn’t you?

I did that on May 13, yes. However today (May 14) I did not do that, no.

I got it. But it gets cached. We are talking with the Onboardjs to find the root cause of the problem. Thanks for reporting it

Solved issue. Closing it.


WIP Fix #1282

SpongeAPI | SpongeCommon
Fix https://github.com/SpongePowered/SpongeCommon/issues/1282
This was worse than I thought. This PR is currently WIP.

Superseded by https://github.com/SpongePowered/SpongeCommon/commit/802ea1d1d7a81f8cc37322f313f19935ab24ba73
Going to break the API to correctly fix this later.


#15144: Up timeout for mamba to an obscene number because we seem to take longer for some reason that I don't understand

…
Ticket
Link to Github Issue
Problem description
Provide context for the problem.
What's changed
Describe the approach used to solve the problem.
Summarize the changes made and its impact.
Checklist

[ ] Post commit CI passes
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

?!?!

Trying to debug :(


[LDT: USAF-SI] Fix typo

Fix just one minor typo in the USAF-SI reader. For this change, I do not create a test case. However, if you need the test case for verification purposes, please let me know.

Hi @yyoon4, the change compiles and the naming scheme appears to match sample data I see in the LIS data directory. I'll go ahead and merge.

Does this need to be ported back the support/lisf-557ww-7.3 branch?

@emkemp Yes. If you can, please do that.

I will do this.  Thanks.

@jvgeiger Thanks!!