issue_comments

Table actions

9 rows where user = 2444231 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: issue_url, reactions, created_at (date), updated_at (date)

user 1

  • pgierz · 9 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1109755369 https://github.com/pydata/xarray/pull/3417#issuecomment-1109755369 https://api.github.com/repos/pydata/xarray/issues/3417 IC_kwDOAMm_X85CJYXp pgierz 2444231 2022-04-26T12:49:13Z 2022-04-26T12:49:13Z NONE

Any progress on this one? I would like to use this functionality. I have a workaround for right now, but it would be nice to do it "correctly"

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   fix #3141 add cumsum to DatasetGroupBy 509421390
598569859 https://github.com/pydata/xarray/pull/3858#issuecomment-598569859 https://api.github.com/repos/pydata/xarray/issues/3858 MDEyOklzc3VlQ29tbWVudDU5ODU2OTg1OQ== pgierz 2444231 2020-03-13T06:21:35Z 2020-03-13T06:25:43Z NONE

Yes, I agree. Having a library only depend on the environment is less than optimal to say the least. The main reason behind this was to allow one of the GRB backends to read custom tables. I've already contacted both the cfgrib and PyNIO people to see about changing this to something more flexible.

Regarding writing my own utility: I'm afraid this introduces one more hoop for end users to jump through. If I can tell my colleagues "Hey just use Xarray", that normally works pretty well. If I now need to say "Hey, use my own little thing plus Xarray plus ...." (who knows what else) might introduce more friction.

However, it's an interesting idea: How challenging would it be to write my own Xarray backend (In this case for GRB files) and include that instead? Would Xarray be open to including a further backend? That would separate the logic into it's own project and if anything breaks, then the Xarray team would have less to worry about and can just refer issues to the backend development team (so, I guess me 😉)...

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Backend env 579722569
598035459 https://github.com/pydata/xarray/issues/3853#issuecomment-598035459 https://api.github.com/repos/pydata/xarray/issues/3853 MDEyOklzc3VlQ29tbWVudDU5ODAzNTQ1OQ== pgierz 2444231 2020-03-12T06:57:01Z 2020-03-12T06:57:01Z NONE

Me too! Then we have a good test case :-)

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Custom Table when opening GRIB Files 578427969
598020815 https://github.com/pydata/xarray/issues/3853#issuecomment-598020815 https://api.github.com/repos/pydata/xarray/issues/3853 MDEyOklzc3VlQ29tbWVudDU5ODAyMDgxNQ== pgierz 2444231 2020-03-12T05:59:51Z 2020-03-12T05:59:51Z NONE

I can have a look at implementing this. Might be a nice opportunity to actually contribute to some of the packages I use every day ;-)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Custom Table when opening GRIB Files 578427969
597491042 https://github.com/pydata/xarray/issues/3853#issuecomment-597491042 https://api.github.com/repos/pydata/xarray/issues/3853 MDEyOklzc3VlQ29tbWVudDU5NzQ5MTA0Mg== pgierz 2444231 2020-03-11T07:50:43Z 2020-03-11T07:50:43Z NONE

Apparently this is possible by setting an environmental variable: http://www.pyngl.ucar.edu/NioFormats.shtml#GRIB1-user-defined-parameter-tables

So, if I have my codetable at /path/to/codetab; I can set NIO_GRIB_PTABLE_PATH=/path/to/codetab. I'm honestly not too happy with this solution. Would it be possible to add something like backend_env to open_dataset; where I can specify environmental variables that are active during opening, and then restore the environment afterwards?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Custom Table when opening GRIB Files 578427969
483705762 https://github.com/pydata/xarray/issues/422#issuecomment-483705762 https://api.github.com/repos/pydata/xarray/issues/422 MDEyOklzc3VlQ29tbWVudDQ4MzcwNTc2Mg== pgierz 2444231 2019-04-16T15:16:23Z 2019-04-16T15:16:23Z NONE

Maybe a bad question, but is there a good jumping off point to gain some familiarity with the code base? It’s admittedly my first time looking at xarray from the inside...

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add average function 84127296
413104436 https://github.com/pydata/xarray/issues/422#issuecomment-413104436 https://api.github.com/repos/pydata/xarray/issues/422 MDEyOklzc3VlQ29tbWVudDQxMzEwNDQzNg== pgierz 2444231 2018-08-15T06:17:12Z 2018-08-15T06:17:12Z NONE

Hi,

my research group recently discussed weighted averaging with x-array, and I was wondering if there had been any progress with implementing this? I'd be happy to get involved if help is needed.

Thanks!

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   add average function 84127296
382430172 https://github.com/pydata/xarray/issues/2066#issuecomment-382430172 https://api.github.com/repos/pydata/xarray/issues/2066 MDEyOklzc3VlQ29tbWVudDM4MjQzMDE3Mg== pgierz 2444231 2018-04-18T15:35:15Z 2018-04-18T15:35:15Z NONE

I’d be happy taking a shot at contributing an error catch for that. I assume that wouldn’t be too difficult, right?

On 18. Apr 2018, 15:21 +0200, Ryan Abernathey notifications@github.com, wrote:

I don’t think we should change the default, at it may have unintended consequences.

I DO think we should catch this specific error and recommend to the user to try autoclose=True in the error message.

On Apr 18, 2018, at 5:47 AM, Paul Gierz notifications@github.com wrote:

That seemed to do the trick. Would it be worthwhile to consider putting the default value of autoclose=True in the method definition, or would that induce other problems?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   open_mfdataset can't handle many files 315381649
382330380 https://github.com/pydata/xarray/issues/2066#issuecomment-382330380 https://api.github.com/repos/pydata/xarray/issues/2066 MDEyOklzc3VlQ29tbWVudDM4MjMzMDM4MA== pgierz 2444231 2018-04-18T09:47:49Z 2018-04-18T09:47:49Z NONE

That seemed to do the trick. Would it be worthwhile to consider putting the default value of autoclose=True in the method definition, or would that induce other problems?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   open_mfdataset can't handle many files 315381649

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);