Broken pipe pyhs2

Query not correctly finish and shows broken pipe, how could it be fixed, is there any way to time out the queries ? And how to fix the broken pipe ?

The author have said the project isn't supported anyway. You can try the alternatives

I switched to pyhive thanks.
Get Outlook for Androidhttps://aka.ms/ghei36
On Fri, Apr 7, 2017 at 3:08 AM -0400, "Jiacai Liu" <notifications<EMAIL_ADDRESS>wrote:
The author have said the project isn't supported anyway. You can try the alternatives
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/BradRuderman/pyhs2/issues/69#issuecomment-292459307, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF8yeFZRyCpl7BbbQGitwECMEsQN6oErks5rteD8gaJpZM4M2ZVa.


Added functionality to only parse a set amount of links

Allows parsing of partial playlist

Coverage decreased (-0.2%) to 76.126% when pulling dd242a4cccac772d0a560c3650eb22ca374f3670 on Choromanski:master into 67e436eaabdbf9a10cc649610801c9b4bbd52838 on nficano:master.

Issue seems to be fixed already -- please re-open if this isn't the case :)


Census data: establish how to hit the API

Summary
The census.gov API is vast and we only need a handful of fields and records, so will need to dig into it.
Documentation (ours)
Explain in README (and/or wiki??) how to:

Obtain an API key
Add REACT_APP_CENSUS_API_KEY to .env

Decisions
WHICH DATASET TO USE?
Which dataset on the Available APIs to use? I believe it will be the 5-year.
WHICH ENDPOINT?
Doesn't look like it applies to all the APIs but some like the 1-year have additional endpoints like Subject Tables, Data Profiles, Comparison Profile, etc.
WHICH FIELDS?

Tract-level: I think I can follow the columns in the tileset Maya uploaded to MB. You can see each of the available fields (they're calling them "variables") by clicking "html" under each endpoint. Example for Detailed Tables:

PUMA-level: TBD

WHICH GEOGRAPHY?
Not sure if this applies but if you click "Examples and Supported Geography" you'll see the options.
Links and resources
The API

PUMS Microdata search maybe?
Maya's ArcGIS Census Language Data Map
SVI (Social Vulnerability Index) Documentation (not sure if SVI will make it into this round of updates as it is a lower-priority "time-permitting" SOW item and, if it does, if SVI data is even available via Census API).

Consuming the API

https://uscensusbureau.github.io/citysdk/examples/mapbox-choropleth/
https://uscensusbureau.github.io/citysdk/docs/

@rperlin-ela or @fiddleHeads, when you have a chance could one of you sign up for a Census API key and email it to me please? It's a really short signup form: https://api.census.gov/data/key_signup.html

**UPDATE: ** got an API key from Ross, added it to Netlify and GH Secrets with REACT_APP_CENSUS_API_KEY as env var name.

@rperlin-ela and/or @fiddleHeads let's keep the ball rolling on this issue. Step by step probably best. Let's start with the "WHICH DATASET TO USE?" above. If you can confirm that it's just the 5-year, we can move on to the next question (first one is easiest, enjoy 😃 )

Yes, it’s the most recent (i.e. 2018) 5-year data on language spoken at home, let me know if you need us to find the code. (Apparently the 2019 5-year will be released in December.) Matt, who’s spent a good amount more time with the census data than we have, is also ready to jump in and help.

On Oct 21, 2020, at 9:25 PM, Jason Lampel<EMAIL_ADDRESS>wrote:
@rperlin-ela https://github.com/rperlin-ela and/or @fiddleHeads https://github.com/fiddleHeads let's keep the ball rolling on this issue. Step by step probably best. Let's start with the "WHICH DATASET TO USE?" above. If you can confirm that it's just the 5-year, we can move on to the next question (first one is easiest, enjoy 😃 )
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/113#issuecomment-714138692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5CFDZAF5WCO52SC4XDSL6C2BANCNFSM4SQ6CPYQ.

Awesome, glad to have someone familiar with that data labyrinth!
The 2019 might end up w/the same schema and it's just a matter of swapping out the endpoint URL rather than a bunch of fields, but for now I'll have to use 2018.
I think we can move on to the "WHICH ENDPOINT?" question. I'm not sure what's needed out of those 4 (hopefully just one of them, and I think we may have established via Zoom that "Comparison Profile" is not needed) but here they are:
https://www.census.gov/data/developers/data-sets/acs-5year.html
In that link try clicking some of the things I highlighted here to get an idea of what's what:

let me know if you need us to find the code

oh and yes to this please.

Does it make sense that the code we're looking for would be S1601_C01_001E, which is the Subject Table for "Language Spoken at Home"?

On Oct 21, 2020, at 11:44 PM, Jason Lampel<EMAIL_ADDRESS>wrote:

let me know if you need us to find the code
oh and yes to this please.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

sorry haven't replied to this yet, will look into it once i start getting into this.

Did some digging into this and #114 today, here are some updates...

Does it make sense that the code we're looking for would be S1601_C01_001E, which is the Subject Table for "Language Spoken at Home"?

Nope, it looks like just about every value in the Census API is a number, so I think there's going to be a field/code (evidently they are referred to as "variables" by the API authors) per language.
After digging into the API docs again today, I'm wondering if it's really worth it to hit the API for something that doesn't change more than annually? It's hard to explain but here are the steps involved if we go that route:

#114 which is similar process to what I did for counties/neighborhoods MB Boundaries, except not as straightforward as I was learning the hierarchy of Census levels and relationship to MB Boundaries (or lack thereof in some cases, depending on the level).
Every time the census layer is turned on, it has to cross-reference the lookup tables (the things MB Dropboxed to us). I "slimmed" the one for the nationwide tracts from 60-70,000 down to "just" 2,000 for the 5-county NYC area (Richmond, Kings, Queens, New York, Bronx). This definitely took some Rainmanning to find the patterns between MB lookups and, assuming those are the correct areas, this is essentially a one-off task that I've completed.
...but what's NOT a one-off is hitting the Census API each time the layer is turned on or changed (e.g. show Tagalog instead of Russian). The API query should return a fair amount of rows, so those all must be compared against the 2,000 records from the lookup table (the purpose of those tables is to middleman the connection between MB Boundaries and Other Data).

So, depending on how many fields are needed for non-PUMA (I'm still wrapping my head around how that one will happen on my end, it sounds harder than the tract-level), I'm wondering if we shouldn't just join that data to the lookup tables permanently? If Matt already has all this info, I could provide the whittled lookup table as a CSV and he could join it up with the appropriate columns. The lookups are really slim column-wise, just an id, tract to join against Census, and the extent/bounds of each feature:

...there's just a LOT of them. But if we're only using the Census API to get data for a couple dozen columns then it might be more efficient to just do the perma-join. I'm envisioning the output like:

MbInternalID
TractId
Bounds
NumTagalog
NumRussian
NumOtherLangEtcEtc

3047045353
027301
stuff i use to zoom to feature when it's clicked
4
0
6

If we go the API route
...as opposed to the perma-join, I still don't know which endpoint or columns/variables to use. The endpoints are  Subject Tables, Data Profiles, Comparison Profile, and Detailed Tables. Links and explanations in the issue descrip above. If it were as easy as the Language At Home one then I'd be sure it's Subject Tables.
Since Matt already knows how to get the data, maybe have him pass on some of the variable codes? I think there was a different tool/site recommended to me but I can't find it in my email and I didn't make note of it since it was only for static downloads, not API.

the census tracts via MB Boundaries were relatively easy to set up. i was able to adapt the existing code i wrote for the other two Boundaries layers:

so now i just need some data to go with them and then we'll be purple-free. :) also will make sure to hide the ones outside the 5 counties (i know they're boroughs, but for all data purposes they are counties).
i think we're also going to need a Ross-controllable config, maybe Sheets again, to keep a list of Languages that i will use as the basis of a dropdown like "show census tracts by number of speakers for:". it's possible we could use the column names from the joined lookup if we go that route, but i'm not holding my breath as that sounds pretty messy.
this is a lot to convey through GH. i'll try to stumble through more of it tomorrow but if i don't make any progress then might need Zoom next week.

Thanks — just want to register that I got these, will try to wrap my head around it, glad to Zoom next week.
I believe the outside tool in question, which Matt finds easier than the census site for just pulling data is called IPUMS. In Tab B of the master spreadsheet https://docs.google.com/spreadsheets/d/13vs7TyQgWF_xpai6m_VoZQfSKNzXLwM3XFagUsSdXKs/edit#gid=892557664 you can see he’s just been grabbing it by borough for our reference here, but perhaps the codes in column B there (e.g. Afrikaans 420) are the “variables” in question? If so, perhaps master spreadsheet Tab G is a useful start for the “Ross-controllable config”? Not finalized but assuming there’s tract-level data for all of these, I could imagine this type of list.
API vs perma-join I’m agnostic— would be good to know which is potentially easier to update, even if it’s just annually. Can revisit variables with Matt or have him work on a join as needed.

On Nov 12, 2020, at 11:52 PM, Jason Lampel<EMAIL_ADDRESS>wrote:
the census tracts via MB Boundaries were relatively easy to set up. i was able to adapt the existing code i wrote for the other two Boundaries layers:
https://user-images.githubusercontent.com/4974087/99029826-be855880-2530-11eb-92e1-a68291467afb.png
so now i just need some data to go with them and then we'll be purple-free. :) also will make sure to hide the ones outside the 5 counties (i know they're boroughs, but for all data purposes they are counties).
i think we're also going to need a Ross-controllable config, maybe Sheets again, to keep a list of Languages that i will use as the basis of a dropdown like "show census tracts by number of speakers for:". it's possible we could use the column names from the joined lookup if we go that route, but i'm not holding my breath as that sounds pretty messy.
this is a lot to convey through GH. i'll try to stumble through more of it tomorrow but if i don't make any progress then might need Zoom next week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/113#issuecomment-726510854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5CT6C3H2AQYPAQADETSPS3R7ANCNFSM4SQ6CPYQ.

thanks, i think the codes might be part of the variable but i'm not sure. i haven't found examples for the census "language" endpoint besides 2013 so i might be in the wrong spot.
i think all the hoops to jump through for a perma-join would be messy. but having to hit the API super frequently in addition to the lookup tables, i'm not sure is going to be performant. JS does fine but there are limits in the browser. cross that bridge i guess.
would these be the things we need maybe? https://api.census.gov/data/2019/pdb/tract/variables.html

That link looks promising to me— Maya can confirm but that list of ~10 languages seems about right in terms of what they have on a tract level basis. (When I keep saying there’s a few dozen I think I’m thinking of PUMA-level)

On Nov 13, 2020, at 12:46 AM, Jason Lampel<EMAIL_ADDRESS>wrote:

thanks, i think the codes might be part of the variable but i'm not sure. i haven't found examples for the census "language" endpoint besides 2013 so i might be in the wrong spot.
i think all the hoops to jump through for a perma-join would be messy. but having to hit the API super frequently in addition to the lookup tables, i'm not sure is going to be performant. JS does fine but there are limits in the browser. cross that bridge i guess.
would these be the things we need maybe? https://api.census.gov/data/2019/pdb/tract/variables.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

ok thanks. @fiddleHeads you probably told me where you got your non-PUMA data from (e.g. for the "Arabic Speakers by Census Tract" layer in the argis map) but i forget. where was that again? IPUMS as well?
Re: perma-join, i'm leaning even harder towards NOT that for a few reasons:

too many hoops/steps and assoc. documentation to make it team-friendly. whereas API is all up to me (except for a Ross-config list perhaps, but that's needed regardless of approach).
assuming the 2019 data has all the same data, it could be a one-character adjustment in the code to make the switch.
we don't know if there are performance implications to the MB Boundaries > lookup table > census api call approach yet, so i might have jumped the gun on the perf argument against the api approach.

for point 2 above, isn't this already 2019?

this is the description of the "PDB" endpoint btw:

The PDB is a database of U.S. housing, demographic, socioeconomic and operational statistics based on select 2010 Decennial Census and select  5-year American Community Survey (ACS) estimates. Data are provided at the census block group level of geography. These data can be used for many purposes, including survey field operations planning.

i'm guessing maybe PUMA data will be the relevant piece of what gets updated in Dec then? either way, i still need to know which data to use and how to get it. somebody somewhere has to provide a firm answer to this so i don't start down the wrong path.
i think i have enough to play with for today, hopefully a proof of concept before weekend, but let's get the where/how data question answered asap.

Hi both, I can respond more in full later, but the data I manipulated in the ArcGIS Online map comes from this layer in The Living Atlas: https://www.arcgis.com/home/item.html?id=77f87dfda3c547efab483e9a07d8a3eb. And this comes from the American Community Survey showing the predominant language spoken at home by the US population aged 5+by Census tracts. This looks to be the same as what you're hitting with the api link Ross sent above.

but first is there any reason to think, in terms of the variables you need, that you haven’t more or less hit paydirt with https://api.census.gov/data/2019/pdb/tract/variables.html?

it's 100% your call so just give me the green light so i know what data to use. ran into issues w/this though, see below.

I don’t know what MOE is

ha, had to google that one myself. "margin of error" i think. govt and their acronyms!

Let me know if this is something plausible and simple to test

here's the first part of the result i'm getting for querying by NY State + the 5-county area with the fields you mentioned:

(Line 3 corresponds with Line 18, and Line 12 with 27, etc.)
i did some spot-checking though and there have been some discrepancies. for example tract 137 on the SW edge of Central Park shows 32 for Arabic:

whereas the API returns 16 and 0 for the MOE and non-MOE, respectively, for Arabic:

sometimes it's correct, like

with

but then others like this one, using same api call with different county parameter, do not match Maya's map:

Oh yeah check out https://api.census.gov/data/2020/pdb/tract/variables.html

This only goes down to the County level unfortunately, whereas 2019 is all the way to block or tract: https://www.census.gov/data/developers/data-sets/planning-database.2019.html
Next steps
i don't think sifting through the census api trying to find what you what and going through the back and forth on github is my responsibility or a very efficient use of anyone's time, and since i've put a good couple of days into this trying to understand what's required, i would appreciate some guidance on next steps.

So, I'll leave the api question to Ross and Matt, although for what it's worth, the 2019 api makes sense to use to me (https://api.census.gov/data/2019/pdb/tract/variables.html). The data I'm using in the map is not authoritative, so we shouldn't get caught up on whether it uses a different tract number than the api. As long as the api and MB census tracts are in alignment, I think that's all that matters.
I've finally gotten around to symbolizing two sample layers in the AGOL map (https://arcg.is/1rvuuO) in order for Jason to copy the classification method and color scheme. I've classified the two layers in two different ways. I'm also using an expression in order to display the percentage of such-and-such speakers by census tract. The expression is: (($feature.Chinese / $feature.Total) * 100).
First Option:
Classification method: Equal Interval
of classes: 6
Color scheme: shades of green
The equal interval classification method  works fairly well with percentages and requires the least amount of input from the cartographer. In other words, if we're going to use the same number and range of classes for each layer, I think this is probably the best option, though I can certainly be persuaded otherwise. This is not really my area of expertise. As you'll see in the map, using this classification method is not as satisfying as using the Natural Breaks classification method. I chose the green to match with the underlying color scheme of the rest of the app. Open to changing this.
Second Option:
Classification method: Natural Breaks
of classes: 5
Color scheme: shades of green
Natural Breaks groups data according to natural groupings in the data values and works well with clustered datasets, but there's some risk with using it across all these different languages because ideally I'd be looking at a histogram of the data to determine the class breaks according to the natural curve of the dataset.
Perhaps Matt can weigh in on classification methods...?

So, I'll leave the api question to Ross and Matt, although for what it's worth, the 2019 api makes sense to use to me (https://api.census.gov/data/2019/pdb/tract/variables.html). The data I'm using in the map is not authoritative, so we shouldn't get caught up on whether it uses a different tract number than the api. As long as the api and MB census tracts are in alignment, I think that's all that matters.
I've finally gotten around to symbolizing two sample layers in the AGOL map (https://arcg.is/1rvuuO) in order for Jason to copy the classification method and color scheme. I've classified the two layers in two different ways. I'm also using an expression in order to display the percentage of such-and-such speakers by census tract. The expression is: (($feature.Chinese / $feature.Total) * 100).
First Option:
Classification method: Equal Interval
of classes: 6
Color scheme: shades of green
The equal interval classification method  works fairly well with percentages and requires the least amount of input from the cartographer. In other words, if we're going to use the same number and range of classes for each layer, I think this is probably the best option, though I can certainly be persuaded otherwise. This is not really my area of expertise. As you'll see in the map, using this classification method is not as satisfying as using the Natural Breaks classification method. I chose the green to match with the underlying color scheme of the rest of the app. Open to changing this.
Second Option:
Classification method: Natural Breaks
of classes: 5
Color scheme: shades of green
Natural Breaks groups data according to natural groupings in the data values and works well with clustered datasets, but there's some risk with using it across all these different languages because ideally I'd be looking at a histogram of the data to determine the class breaks according to the natural curve of the dataset.
Perhaps Matt can weigh in on classification methods...?

thanks Maya. my replies:

So, I'll leave the api question to Ross and Matt, although for what it's worth, the 2019 api makes sense to use to me (https://api.census.gov/data/2019/pdb/tract/variables.html). The data I'm using in the map is not authoritative, so we shouldn't get caught up on whether it uses a different tract number than the api. As long as the api and MB census tracts are in alignment, I think that's all that matters.

sounds good. as soon as i get the consensus green light i'll take that as the gospel.

I've finally gotten around to symbolizing two sample layers in the AGOL map (https://arcg.is/1rvuuO) in order for Jason to copy the classification method and color scheme. I've classified the two layers in two different ways. I'm also using an expression in order to display the percentage of such-and-such speakers by census tract. The expression is: (($feature.Chinese / $feature.Total) * 100).

Nice, thanks for making that happen, although I wasn't able to view anything besides the basemap in your https://arcg.is/1rvuuO link:

but it sounds like 6-class equal interval might be the best catch-all. I do have some capabilities on my end if I install another plugin, and MB can do some interpolation as well, but i'm getting reluctant to do that for performance reasons:
the good news
i've successfully hit the census api, "joined" to my whittled MB Boundaries lookup table, and rendered the result. just Arabic so far, and hardcoded "classes" at that (classifying with non-hardcoded classes dynamically will be a different animal):

and, even with the ballparked hardcode i'm definitely seeing some legit patterns using your original map as comparison:

the bad
we might need a disclaimer saying "we're not responsible if your device disintegrates while viewing the tracts layer". even with the magic that is vector tiles, coupled with a decent laptop with 16GB of RAM and an SSD, i'm definitely feeling the map groan now. there is a LOT going on- the vector tiles are already dynamic, as is the fetch to get the lookup table, and hit the census api, then marry the two up and assign the paint options to the layer.
i've been consistently impressed by how well the map performs despite how much we're throwing at it, but this might be straw + camel's back now. granted i just figured out the initial setup tonight and have not approached large performance efforts yet but, simply given all that is happening inside the browser, i could see it crashing easily. even if it doesn't crash, the choppy lag i'm noticing now is unacceptable and feels like using MapQuest in 2004.
perma-join
i realize this is not the best option for long-term maintenance, but we may not have a choice. if if the MB lookup table already had the 10-language census data in it, that would reduce the in-browser processing considerably, not to mention skip the api call entirely, and also require far less coding.
performance was my concern from the beginning for the always-dynamic api-only approach and it seems like the concerns are legit, so let's have that convo about the perma-join. since the data only changes one every year or less, it doesn't seem fair to the user to make them wait for something that could've been ready before they even got to the site. the API is awesome, don't get me wrong, but with such a fixed set of column requirements it seems kind of overkill to keep hitting it. i've hit it dozens or more likely hundreds of times today just during development, so the time-suck is felt on the dev side too.

i forgot to mention PUMA, which might be a separate API call and complexity. assuming that could be incorporated directly into the MB lookup tables, that would save some more code and only add a bit of Kb's to the data size. i've already slimmed down what MB gave us, nickel-and-diming things like renaming feature_id column to id, but i would not be opposed to an additional byte weight loss program.
thinking even further ahead, another benefit of a pre-joined static table is that we'd have control, for better or worse, over the column names. for example, instead of maintaining a config that says Age5p_Arabic_ACS_13_17 is synonymous with certain Arabic languages in Ross's data, perhaps we could just call the column Arabic in the lookup table and then just say if "Language value in data includes 'Arabic', the corresponding Explore page for that Language (e.g. /Explore/Language/Arabic (Moroccan) would contain a button or link to set the census tracts to Arabic".
(as i'm typing that i feel like we're going to need config if we take it to that UI level!)
not the end of the world to have more config, i was anticipating that anyway, but as they say: mo' moving parts, mo' problems.

Hey Jason. I'm on the run and can come back to this later, but for now, use this link: https://arcg.is/fXHC9. Sorry about that other one. I'm not sure what happened there. More later, Maya

Thanks Maya. I got the perma join set up using the non-PUMA data from the API (the languages in Ross's list, minus English) and set a placeholder for color classes using your green scheme.
I did not include a total speakers surveyed or total population field in the result, so we wouldn't be able to do a percentage that way. I'm not much of a stats master but instead could we maybe just make the classes dynamic but relative to the given language? In other words if Tract A had 5 Vietnamese speakers, Tract B had 32, and C had 124, just make the classes based on that (124 is darkest) rather than incorporating division? I'm not sure if the goal here is to recreate your map or just follow the general classes and color scheme.
If all we need is non-PUMA and one of Chroma's class options (or another lib's), then I might have everything I need?
https://gka.github.io/chroma.js/#chroma-limits

I don't think the goal is to recreate my map, and if Ross thinks a relative classification like you describe would work, that's okay with me. I think I was trying to avoid any danger with not normalizing the data. The other option is, especially if you're not planning on hitting the API (I remain a little confused about this), is that I could create another field and calculate the percentage there.

Totally open to and agnostic about different classifications on this end— whatever we think will be most legible to users

On Nov 16, 2020, at 1:51 AM, fiddleHeads<EMAIL_ADDRESS>wrote:

I don't think the goal is to recreate my map, and if Ross thinks a relative classification like you describe would work, that's okay with me. I think I was trying to avoid any danger with not normalizing the data. The other option is, especially if you're not planning on hitting the API (I remain a little confused about this), is that I could create another field and calculate the percentage there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

whatever we think will be most legible to users

what is it, in one sentence or phrase, that needs to be legible? aka what are we trying to communicate to them? is it how many speakers there are for each language relative to itself, to the number of speakers surveyed in each tract/PUMA, to the total population in each tract/PUMA, or something else? that really has to be answered before sincerely moving forward with data, UI, or anything else census-related.
if you don't mind, resist the bad example i've established in this unfocused issue and keep any API stuff here and color scheme/symb in #115 . dear Future Jason: less shotgun, more laser.

good call— my priority would be “how many speakers there for each language relative to itself", since we’re only doing this for sizeable languages, and I don’t see much danger of making it look like there are significant absolute concentrations when there aren’t.

On Nov 16, 2020, at 10:23 PM, Jason Lampel<EMAIL_ADDRESS>wrote:
whatever we think will be most legible to users
what is it, in one sentence or phrase, that needs to be legible? aka what are we trying to communicate to them? is it how many speakers there are for each language relative to itself, to the number of speakers surveyed in each tract/PUMA, to the total population in each tract/PUMA, or something else? that really has to be answered before sincerely moving forward with data, UI, or anything else census-related.
if you don't mind, resist the bad example i've established in this unfocused issue and keep any API stuff here and color scheme/symb in #115 https://github.com/Language-Mapping/language-map/issues/115 . dear Future Jason: less shotgun, more laser.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/113#issuecomment-728661733, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5HITUT2PPC62F3BBZTSQHUDPANCNFSM4SQ6CPYQ.


Merge main into v3.0.0

Description
Just getting the v3.0.0 branch current before tackling the items listed in https://www.notion.so/workos/Features-for-the-Next-Major-SDK-Release-4a425188c6b94d46a728e42abc509a62#c2e47b7921e14cc4adf649158c287f56.
Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
[ ] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

Just getting the v3.0.0 branch current

Is the "v3.0.0 branch" main in this case?
The PR title is a little confusing, since we're merging this PR into main.

The PR title is a little confusing, since we're merging this PR into main.

Ohh, it should have been v3.0.0 (I was hoping gh would use my tracking branch as the branch to merge into, but it needed an edit).

The PR title is a little confusing, since we're merging this PR into main.

Ohh, it should have been v3.0.0 (I was hoping gh would use my tracking branch as the branch to merge into, but it needed an edit).

Seems like we should just use main for the next major version release (v3) instead of creating a new branch to track it.
And then we just keep the v2.x around if we need to release new v2.x.x versions in the meantime.

Seems like we should just use main for the next major version release (v3) instead of creating a new branch to track it.

And then we just keep the v2.x around if we need to release new v2.x.x versions in the meantime.

I like that idea better :+1:.


Log to the console when the browser is ready to be navigated to

The output for npm run test-browser should be:
[18:24:17] Using gulpfile ~/WebDev/temp/generator-tests/gulpfile.babel.js
[18:24:17] Starting 'test-browser'...
[18:24:17] Starting 'lint-src'...
[18:24:19] Starting 'lint-test'...
[18:24:19] Finished 'test-browser' after 2.11 s
[18:24:20] Finished 'lint-src' after 2.45 s
[18:24:20] Finished 'lint-test' after 598 ms
[18:24:24] /Users/jmeas/WebDev/temp/generator-tests/tmp/__spec-build.js reloaded.
[18:24:28] Starting 'lint-src'...
[18:24:28] Starting 'lint-test'...
[18:24:28] Finished 'lint-src' after 136 ms
[18:24:28] Finished 'lint-test' after 251 ms
+ [18:24:28] You can now load the "test/runner.html" file in your browser to view the tests.

& if there's anything I can do to make that stand out (bold, bright color), then I should!

Finished


refactor ledger handling codes in main thread

This PR is for https://github.com/thorchain/asgardex-electron/issues/676

Since this PR is about structuring and to be more in common with structures at other places, I would suggest the following:
├── ledger
│   ├── address.ts # address stuff (e.g. `getLedgerAddress`)
│   ├── binance.ts  # BNB stuff
│   ├── bitcoin.ts # BTC stuff
│   ├── transaction.ts # tx stuff (e.g. `signTxInLedger`)
│   └── index.ts # just an entry file to export everything

Also, please remove any prefix / suffix of Ledger from function names (e.g. getLedgerAddress -> getAddress, signTxInLedger -> signTx)


[WIP] Introduce FileBasedRelation trait to decouple relation types from source provider.

What is the context for this pull request?

TBD
What changes were proposed in this pull request?

TBD
Does this PR introduce any user-facing change?

No
How was this patch tested?

API refactoring. Existing tests should be enough.

@imback82 Just some early feedback...
I've seen you added the FileBasedRelation trait. The DataSourceV2Relation is not necessarily a file base relation. I would suggest to have this trait defined as a more generic relation, not only file based ones. As you suggest on my #321 PR SourceRelation fits better.

We need to have files-related APIs such as allFiles at FileBasedRelation (I thought about having SupportsFiles trait, but didn't want to complicate APIs at this stage). Until we have a good use case/example of supporting non-filed relations, making it explicit seems reasonable (similar to we store FileBasedSourceProviderManager in the hyperpsace context).
Similar to SourceProvider, I can have a top level trait SourceRelation, but will still use FileBasedRelation in FileBasedSourceProviderManager.getRelation.

First, regarding Iceberg and DataSourceV2...
The Iceberg source does not use and index (like the InMemoryFileIndex) and the files attached to an Iceberg table are not attached to a relation. To retrieve the files of an Iceberg table you need to use the table file scan api.
See https://github.com/microsoft/hyperspace/pull/320/files#diff-01b72d2de6f62e2696e47b850eb7e40039fa85120d40ef392df1cf7b44aff9f8R246-R259
Second, it does NOT look right to have the DataSourceV2Relation hard linked to the FileBasedRelation and I don't know if this refactor make the code clearer in the case of DataSourceV2 sources like Iceberg.
In the end, if you still consider that this will bring clarity, please complete this PR ASAP and merge it, so that I could modify my PRs to fit these changes.
Thank you.

Second, it does NOT look right to have the DataSourceV2Relation hard linked to the FileBasedRelation and I don't know if this refactor make the code clearer in the case of DataSourceV2 sources like Iceberg.

Why not? I see that you are implementing allFiles? Your provider for iceberg can just check if the given datasourcev2relation is applicable.
I will get this ready for review by eod today as promised.

@andrei-ionescu @sezruby @apoorvedave1 This is ready for review now (I will update the PR description soon, but I believe you already know the context. 😄 ). Basically, I removed the direct dependency on LogicalRelation from actions/rules code.
@andrei-ionescu Now, you can just implement IcebergProvider and IcebergRelation without modifying anywhere else hopefully, 🤞🏼

@andrei-ionescu I also add you as a co-author in this commit https://github.com/microsoft/hyperspace/pull/355/commits/50ed5cd30bc4727b73dc9c0e46345d8c16aa5864, so when this PR is merged, you will get the co-authorship. Thanks!

@imback82 Thanks for co-authoring!

The approach looks great. Thanks :)


Mongoid uses _id instead of id

Hi there, I am using MongoDB with Mongoid, where Mongoid uses the field _id instead of id.
So if I did the example provided in the readme of rails-backbone in the index.html.erb
$(function() {
window.controller = new Blog.Controllers.PostsController({posts: <%= @posts.to_json.html_safe -%>});
Backbone.history.start();
});
I'd get "id is not defined" in the Chrome console
if I changed the above to
$(function() {
window.controller = new Kiosk.Controllers.PostsController({posts: <%= @posts.to_json.gsub('_id','id').html_safe -%>});
Backbone.history.start();
});
the difference is the gsub(), it'll display okay, and works as it should until some part of the app re-request the model directly from server where no gsub('_id', 'id') was manually done, e.g., creating a new record.
I know this can be argued that it's a mongoid thing or mongodb thing in general and not this gem's business, but is there any chance that you can allow for a customizable key what is traditionally the "id".

But backbone also sets the id attribute when saving which breaks on the rails side.  So it doesn't look like it is really using the _id except for when fetching.

I haven't touched Backbone + Mongoid (but it is on the map, and not a maybe item) for a few weeks now. -- Thanks for adding your finding to this issue. - If I were to give it a shot, I would put an ApplicationController-wise before_filter if you use Mongoid and Backbone which looks for params[:id].present? && params[:_id].blank? and set params[:_id] to params[:id] manually when this simple condition is met. Think it will work?

An alternative option is to change it serverside by overidding either the as_json method or the serializable_hash method,  as described in the two links below:
http://blog.joshdzielak.com/blog/2011/12/24/tame-the-mongoid-id-field-in-your-rails-and-backbone-js-app/
module Mongoid
module Document
def as_json(options={})
attrs = super(options)
attrs["id"] = self.persisted? ? self._id : nil
attrs
end
end
end
https://github.com/mongoid/mongoid/issues/1262
module Mongoid
module BackboneSerialization
extend ActiveSupport::Concern
module InstanceMethods
def serializable_hash(options = nil)
persisted? ? super.merge('id' => _id) : super
end
end
end
end


There is no way for the connectWith option to be false

In some case you do not want a connectWith selector to be set (eg. preventing of dragging and dropping of items between levels in a nested list). However, there does not currently seem to be a way to specify connectWith as its default value of false.
If no connectClass is specified on the plugin then it defaults to .ko_container
I have hacked the code around so that:
connectWith: connectClass ? "." + connectClass : false
and the default connectClass value is null:
connectClass: null,
This works for my situation but a more generic method is probably needed.

Just want to make sure that I understand your situation to consider the right change.  Can you describe specifically what you want to accomplish?
The 'allowDrop' option lets you control if a section is a target for drops and if it is observable or a function, then it will update dynamically.
The 'connectClass' could be set to something unique, if you don't want to participate with the other sections.

I have a deeply nested hierachy: ABCD etc.... and I only want the user to be able to drag and drop items on the same branch in the hierachy.
I would have to either put a unique connectClass on each level to ensure that the user can't drag and drop between levels in the hierachy (http://jsfiddle.net/unklefolk/LbeRE/1/) (I guess I would have to dynamically generate this). It does not seem to be enough just to supply a connectClass that isn't actually applied to any elements (http://jsfiddle.net/unklefolk/sypLG/  - you can still drag and drop between the groups).
Or I would have to run a beforeMove test which I have tried (eg. arg.targetParent() === arg.sourceParent()) but this didn't seem very reliable - maybe due to the flickery nature of jquery sorting when on the boundary between two elements.
If I had a simple way to inicate that connectWith should be false this would remove these issues and avoid extra processing.

Thanks for the clarification.  Makes sense.  Easy enough to provide this ability.  You can now set it to null/false globally (ko.bindingHandlers.connectClass = false) or in the binding.   e0d1bf3b071b1eef1b75a7a975de5d97653ffc55.  Please reopen, if this does not meet your needs.

I just realized that you could actually just set allowDrop = false and nobody would be able to drop onto that list (but you can still sort within it).
So, an option would have been just to set ko.bindingHandlers.sortable.allowDrop = false like: http://jsfiddle.net/rniemeyer/sypLG/1/
There is still a subtle difference in that you would be able to drop from this list onto another list that accepted drops, so overall I think that having the option to set connectClass to null/false is good to have.

Thanks, Ryan. I've got your fix and it work great.


haskellPackages.diohsc: unbreak

Description of changes
diohsc is marked as broken because it fails to build with tls 1.8. It builds successfully with tls 2.0.6.
Things done
Override scope of diohsc and mark it as non broken.

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.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.

Add a :+1: reaction to pull requests you find important.

Thank you!

Please retarget this PR at the haskell-updates branch. (Be sure to mark as draft during the branch switch because that sometimes creates mass pings.)
Optional: run maintainers/scripts/haskell/regenerate-hackage-packages.nix in your commit, so that all changes go together.
Optional: Elaborate the comment a bit. E.g. when this override was added or when the override can be removed. (But I guess with a bit of thinking the current comment is okay.)

Ex-cell-ent


Release 2.5.4

2.5.4

Added optional commitModalBypass feature config. When the <CommitButton /> component is used inside of a widget with a matching src prop, the CommitModal will be bypassed and onCommit() will be called instantly when the button is clicked. If for some reason the requested transaction is invalid, the CommitModal will still appear to show an error message to the user. View example below to see configuration options.
Added optional enableWidgetSrcWithCodeOverride boolean feature flag. This is helpful to enable when developing in a local environment when using a redirectMap in combination with the new commitModalBypass feature. With this enabled, any widget that is overridden via redirectMap can still reference its src prop to respect your commitModalBypass config.

initNear({
  features: {
    commitModalBypass: {
      authorIds: ["mob.near", "root.near"], // Bypass for all widgets published by these accounts
      sources: [
        "cool.near/widget/CoolComponent",
        "awesome.near/widget/AwesomeComponent",
      ], // Bypass for specific components
    },
    enableWidgetSrcWithCodeOverride: isLocalEnvironment,
  },
});

Merged the hotfix. Please pull latest change from dev

Thanks @evgenykuzyakov! I synced my PR with the latest from dev. Will go ahead and merge now.


Require GL_EXT_nonuniform_qualifier for unbounded arrays

While the GL_EXT_nonuniform_qualifier extension has the primary function of adding the nonuniformEXT qualifier with semantics similar to HLSL NonUniformResourceIndex, it also has a critical function in changing the GLSL spec behavior around arrays with an unspecified size.
Without the extension, an array with unspecified size is an "implicitly sized array," which only supports indexing with integral constant expressions (with the largest such constant determining the array size).
With the extension, an array of an object type (e.g., texture, sampler, or buffer) with unspecified size is a "runtime sized array" which supports non-constant indices.
Slang should emit this extension as required whenever a GLSL shader being emitted has an unbounded-size array of resources among its parameters.

As a workaround, users can explicitly use NonUniformResourceIndex when indexing into such arrays, which has the side effect of forcing the GL_EXT_nonuniform_qualifier extension to be enabled.


bigquery and sqllab  - table dropdown generates an error

Make sure these boxes are checked before submitting your issue - thank you!

[x ] I have checked the superset logs for python stacktraces and included it here as text if any
[ x] I have reproduced the issue with at least the latest released version of superset
[ x] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
very latest including the updated
lib/python2.7/site-packages/superset/db_engine_specs.py
Expected results
List of tables ..
Actual results
After selecting the "schema" it tries to query the tables and the gui comes back and shows
Error while fetching table list.
The log shows:
2018-02-10 19:09:21,610:INFO:root:Database.get_sqla_engine(). Masked URL: bigquery://production-bigdata/
2018-02-10 19:09:21,620:DEBUG:urllib3.util.retry:Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=None, status=None)
2018-02-10 19:09:21,622:DEBUG:google.auth.transport.requests:Making request: POST https://accounts.google.com/o/oauth2/token
2018-02-10 19:09:21,627:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): accounts.google.com
2018-02-10 19:09:21,696:DEBUG:urllib3.connectionpool:https://accounts.google.com:443 "POST /o/oauth2/token HTTP/1.1" 200 None
2018-02-10 19:09:21,700:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): www.googleapis.com
2018-02-10 19:09:21,804:DEBUG:urllib3.connectionpool:https://www.googleapis.com:443 "GET /bigquery/v2/projects/production-bigdata/datasets HTTP/1.1" 200 None
2018-02-10 19:09:21,805:ERROR:root:dataset must be a Dataset or a DatasetReference
Traceback (most recent call last):
  File "/home/derwin/venv/local/lib/python2.7/site-packages/superset/views/base.py", line 62, in wraps
    return f(self, *args, **kwargs)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/flask_appbuilder/security/decorators.py", line 52, in wraps
    return f(self, *args, **kwargs)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/superset/views/core.py", line 1335, in tables
    database, database.all_table_names(schema), schema)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/superset/models/core.py", line 724, in all_table_names
    self.db_engine_spec.get_table_names(schema, self.inspector))
  File "/home/derwin/venv/local/lib/python2.7/site-packages/superset/db_engine_specs.py", line 225, in get_table_names

  File "/home/derwin/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/reflection.py", line 201, in get_table_names
    self.bind, schema, info_cache=self.info_cache)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/pybigquery/sqlalchemy_bigquery.py", line 192, in get_table_names
    tables = connection.connection._client.list_dataset_tables(d)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/google/cloud/bigquery/client.py", line 459, in list_dataset_tables
    return self.list_tables(*args, **kwargs)
  File "/home/derwin/venv/local/lib/python2.7/site-packages/google/cloud/bigquery/client.py", line 438, in list_tables
    raise TypeError('dataset must be a Dataset or a DatasetReference')
TypeError: dataset must be a Dataset or a DatasetReference

Steps to reproduce
Select SQLLab
Select BigQuery for Database
Select one of the Schemas it finds (datasets).
Then the error..

That looks like an issue in pybigquery

Yes .. now that I look into the error it appears to be the interface. I will close this here and post a note if I am able to resolve it.

Proposed fix noted over on pybigquery github.
#        tables = connection.connection._client.list_tables(d)
          tables = connection.connection._client.list_tables(connection.connection._client.dataset(d.dataset_id))

@darylerwin if this turns out fine mind to create a PR for adding a big query entry here please? https://github.com/apache/incubator-superset/blob/master/docs/installation.rst#database-dependencies


PYP Q4

Source
PYP Q4 (Semester 1: AY2021/2022)
Description
Hi, could anyone explain the code in q4 to me? I don't really understand it nd hence do not know how to approach the question. Thank you!
Screenshots (if any):

for a) MyStream.generate returns a new MyStream with the updated abstract method with a random number supplier. So the question is asking us to create a foreach method that is similar to that of the stream class. So some properties of foreach would be that it returns void and takes in a consumer.

for a) MyStream.generate returns a new MyStream with the updated abstract method with a random number supplier. So the question is asking us to create a foreach method that is similar to that of the stream class. So some properties of foreach would be that it returns void and takes in a consumer.

@danyelys may i ask what did u "loop" through? for instance, in Imlist the forEach method loops through the this.list and applys the Consumer on each element.
But i cant seem to figure out what to "loop through" in MyStream

The use of forEach could be defined differently for every context.
For the ImList, you are going through each element in the stored collection.
For this case of MyStream, notice that there is a get method that retrieves something from the Supplier, seed.
As such, your forEach should be attempting to get() something from the seed, for the number of times specified in the forEach arguments.

i got it, thank u sm!!


Request: Support for Powkiddy RK2023

Probably a longshot, but is there any chance of support for RK2023 being added? Mine was able to boot the RG353V/VS image, but the display seems to be vertically offset downwards a bit. A big row at the top is empty while the bottom is cut off. The battery reader also understandably isn't working here and just reads 0% no matter the charge.

Alternatively, if there is a way I could adjust the vertical offset with the current image that would be a huge help.

I've requested a couple of development units from Powkiddy and they're supposed to be sending me some.  We'll see.

Just heard JelOS may add official support for this unit as well.  Will depend on if they can get some units which they're working on.
In the meantime, can someone post the contents of the boot folder in a zip file here.  Mostly looking for the .dtb file(s).  Thanks in advance

The JELOS partition had a .dtb file, is this maybe what you wanted?

https://www.mediafire.com/file/4ec67kym04enpha/JELOS.zip/file EDIT: Also here is the full image if you want that https://mega.nz/file/HcgH3AZA#8SWbKfeW4rxPglmdMYUgqZFapHboFBoiTTHnwpDs3Mg
I found a boot folder under the root partition, but this Linux Reader program I'm using to view it on Windows is telling me nothing is in there.

That dtb is what I was looking for.  Thanks for providing that jelos.zip.  Attached is a zip file that contains an updated rk3566-OC.dtb file.  Try replacing the one in the boot partition on the ArkOS card with this one and see if that changes anything.  Let us know your results.
rk3566-OC.zip

Awesome! That did the trick! Thank you Christian!

Nice!.  Enjoy!

Hopefully all the buttons works correctly.

Yeah I figured it would be easier for you to work on stuff like battery when you actually have a device. All the buttons are working perfectly.

Yeah I figured it would be easier for you to work on stuff like battery when you actually have a device. All the buttons are working perfectly.

Is this with or without using the new dtb file.. Just curious

This is with using the new dtb file.

Hi, can someone load this updated rk3566-OC.dtb file on to this unit and see if battery reading works now and report the results.  Thank you.
rk3566-OC.dtb.zip

I gave it a shot on mine and the battery reading was showing 0% again. It still works just fine otherwise though!

Updated kernel and dtb that fixes the battery reading and analog stick for this device.  Thanks to @fewtarius for the guidance on the battery fix and TSS_Killer for confirming the analog and battery fixes for this device.
RK2023-AnalogandBatteryFix.zip

An image is now available for the RK2023 from the wiki here.  Closing this request as this device now officially supported by ArkOS.


Chiragbaligci patch 1

Fixes #
Changes proposed in this pull request:

Link to live demo: http://pr-XXX-evalai.surge.sh

Codecov Report

Merging #225 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #225   +/-   ##
=======================================
  Coverage   51.74%   51.74%
=======================================
  Files          66       66
  Lines        3643     3643
  Branches      412      412
=======================================
  Hits         1885     1885
  Misses       1663     1663
  Partials       95       95

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 59b23c8...f9b6cb1. Read the comment docs.

@chiragbaligci please change your PR description to appropriate title of your task


[feature request] Add option to JPEG decode with GPU acceleration

This is a suggestion.
Is your feature request related to a problem? Please describe.

Currentry, The Azure Kinect Sensor SDK uses TurboJPEG to decode JPEG (Motion-JPEG) retrieved from color camera.
TurboJPEG is highly optimized and provide high performance on CPU. I like TurboJPEG. :) However, it consumes a lot of CPU resources in return.
Also,  I feel a bit underpowered to CPU (that spread through the market at now) for decode very beautiful and high-resolution image of Azure Kinect. I feel the same thing, even when decoding footage from multiple color cameras because Azure Kinect supports multiple connections on a PC.
Describe the solution you'd like

I think CPU resources available to the user application are limited when decoding JPEG on CPU.
So, I suggest to add GPU acceleration option for JPEG decoding to Azure Kinect Sensor SDK. (For example, there is the NVIDIA Video Codec SDK that runs on NVIDIA GPUs.)
NOTE: This is optional and does not impose any hardware constraints on users who want to run on the CPU alone.

What do you think?
Please consider this.
Thanks,

The challenge is the Huffman decoding. Before anything can be done in parallel or on the GPU, the MJPEG must first be Huffmann decoded. This process is serial and single-threaded...the math can't be changed.
As an example, the Nvidia APIs do this first step on the CPU and later steps on the GPU. Unfortunately, since the Huffmann decoding is a serial math process, it will always be computationally expensive and high latency. There is no opportunity with a single JPEG frame for multithreading/gpu. :-(
However, there is a rare feature of JPEG called "restart markers". Originally, it was designed for error correction. To allow a restart of the image processing so if an error occurred, then it would be isolated to a small section and the other parts of the images would be ok.
These markers can be used in another way. They can be used to separate the compressed data into chunks. Then each chunk can be decompressed/processed by separate threads or a GPU compute unit.
The Kinect Azure camera needs to insert many restart markers into their JPEG frames. After this is done, then existing technology/decoders on the CPU or GPU can be used to decompress these in parallel.
Caution: Azure Kinect camera creates 4:2:2 JPEG frames. 😕 Some GPU decoders (like nvidia's nvenc) do not support that subsampling. They only support 4:2:0 JPEG frames. However, some others decoders (like nvidia's nvJPEG) do support 4:2:2.
Question
Does the Kinect Azure already insert many restart markers into the JPEG frames?
I would check myself, but I have yet to find a tool that will allow me to inspect for them.
Holistically
Putting restart markers in the JPEG data stream is the first step.
After that, I'm not so excited about the SDK adding such an decompress api in isolation. Instead, it is more interesting if the decompressed image is in GPU memory. Then to be able to manipulate that images using tools like OpenCV's cv::UMat or cv::gpu. And after all manipulation, pulling it down to the CPU.

This functionality has to happen for the Azure Kinect to be viable in the IOT space, many applications require higher resolution to be viable(and therefore an even greater CPU bottle neck) and GPU/Cuda acceleration is already available in environments such as the Nvidia Jetson family(which has nvJPEG available). Is there any progress on this?


Not working in Nuxt v2.14.5 ?

I have spent a while trying to get this to work with the latest version of Nuxt, but it does not seem possible. I keep getting
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file for Fetcher. The examples for SSR in this repo are using 2.11. Is there something in more recent versions that break this?
Edit: This may be an issue on my end I am not sure. I am getting odd results. Can you confirm with works with latest version of Nuxt?
Edit 2: It seems like it may have been from using the latest version of @vue/composition-api.

@saturnonearth I have updated the axios-typescript-nuxt example in the examples dir of this repo. The app starts up (yarn dev) and works as expected. Can you provide a repo or codesandbox that reproduces your error?

Hi there,
It appears it was something to do with with the most recent version of the vue composition API, I believe it was requiring Vue 3.


No reading

Anyone experienced no reading since the ESPHome updates recently?
My Glow does not read anything now and shows just a ZERO for usage.  i've tried resetting etc but nothing is working.

Which version are you using and is your sensor still on the correct GPIO pin?

I too have noticed recently, that once in a while its stopping metering. Was thinking it had something to do with my wifi network.

I updated the position of a wifi repeater that is now used by the ESP and had to recalibrate the sensor.
Not sure but maybe it has to do with some kind of change in the amount of power going through the module?

I updated the position of a wifi repeater that is now used by the ESP and had to recalibrate the sensor.
Not sure but maybe it has to do with some kind of change in the amount of power going through the module?
This might relate to the ESPHome updates causing some optimisations to mess with the power levels and thus causing the sensor to become less reliable.

I've changed nothing, other than the software update.  How do you recalibrate the sensor?

I updated the position of a wifi repeater that is now used by the ESP and had to recalibrate the sensor.
Not sure but maybe it has to do with some kind of change in the amount of power going through the module?
This might relate to the ESPHome updates causing some optimisations to mess with the power levels and thus causing the sensor to become less reliable.

I've changed nothing, other than the software update. How do you recalibrate the sensor?

The sensor has a blue potentiometer that, when turned, changes the sensitivity of the sensor.

I get sporadic readings now, a few minutes ago it was over 11,000,000W, not sure that's correct!

Yes, if you look at the log then this happens because the sensitivity is such that it reports the same red flash as multiple flashes.
There are two ways to correct this:

Turn the potentiometer so that it only provides only one red flash
Use the internal filter inside YAML by uncommenting it. #internal_filter: 100ms

Hi guys. In ESPHome 2023.8.0, there was a pulse_meter refactoring. The default mode is now EDGE instead of PULSE as before.
To use the PULSE mode, you need to add the internal_filter_mode option to the pulse_meter configuration, like this:
  - platform: pulse_meter
    name: '${friendly_name} - Power Consumption'
    id: sensor_energy_pulse_meter
    internal_filter_mode: PULSE
    unit_of_measurement: 'W'
    state_class: measurement
    ...

I use the EDGE mode with an internal_filter of 100ms, with a pulse rate of 1000 and have not noticed any difference 🤔

Do you have any strangers values?

Nope, it is always spot on with measuring

hm, In EDGE mode, an internal_filter of 100ms and a pulse rate of 10000 i have right values too 🤔

Mine is still dead. Reports a 0w all day every day.  I've tried to fix it but with no luck

A pulse rate of 10000 is actually too high to make correct measurements. But if I understand correctly, you get good measurements when you set the interval_filter_mode to PULSE?

Perhaps it would be better to set the internal_filter with 100ms default and not the mode back to PULSE as in your PR.

I did close it


Create Contributors.md

Create proper rules that a contributor should follow for contributing to this project.

I will add it.


updated WebApiContrib.Core.Formatter.Protobuf to latest protobuf-net …

…and created a netcoreapp3.1 target
fixes #209

Will do some manuel testing and create a package, hopefully at the weekend.

Hello, hoping to see a package for this soon.

@devindran sorry forgot about this, will do this tomorrow.
Greetings Damien

Released
https://www.nuget.org/packages/WebApiContrib.Core.Formatter.Protobuf/3.0.0/
Thankd for the PR!


Add auth0 user import command

Description
This PR adds support for importing users via the auth0 users import command. If a template is not mentioned, it provides a dropdown that allows a user to select from 4 default user import examples. If the "Empty" template is selected, it will open a text editor to allow a person to add the users they want to import.

References

https://auth0.com/docs/manage-users/user-migration/bulk-user-imports
https://auth0.com/docs/manage-users/user-migration/bulk-user-import-database-schema-and-examples
https://github.com/go-auth0/auth0/blob/master/management/job.go

Checklist

[x] Pass all automated checks
[x] Add support to allow a user to open an empty user import template in an editor before importing.

@sergiughf I actually had this working the way you described, but I decided to change it since I thought the only time you would want to import your own would be on the "Empty" state, but I can see why others would want to edit the other examples before importing. The new commit always opens in editor now. I also added a "Do you want to import these users?" prompt after saving/closing the editor as an extra check.


Special Handling for Cargo deps with paths?

Hello, not sure if this is an issue with Dune or with the rule this template repo uses to grab the compiled rust files.
I've been playing around with template and I wanted to add a Rust dependency to my cargo file which is only local, not published on crates.io.
The change to the cargo.toml dependency looks like this arwen_synth = {version = "0.1.0", path = "../../Github/Arwen_Synth"}.
I think the "../.." causes an issue because the error I get looks like:
File "src/dune", line 1, characters 0-464:
 1 | (rule
 2 |  (targets libmy_project.a dllmy_project.so)
 3 |  (deps
....
13 |     mv
14 |     %{project_root}/../../target/release/libmy_project.a
15 |     libmy_project.a))))
error: failed to get `arwen_synth` as a dependency of package `my_project v0.1.0 (~/Desktop/tmp/ocaml-rust-starter/_build/default)`

Caused by:
  failed to load source for dependency `arwen_synth`

Caused by:
  Unable to update ~/Desktop/tmp/ocaml-rust-starter/Github/Arwen_Synth

Caused by:
  failed to read `~/Desktop/tmp/ocaml-rust-starter/Github/Arwen_Synth/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

Note, I would expect it to try to read from ~/Desktop/Github/Arwen_Synth/Cargo.toml which is what Cargo does.
Do you have any suggestions?

I have just opened this PR: https://github.com/zshipko/ocaml-rust-starter/pull/8 - does it fix the issue for you?
In general getting these builds right takes some trial and error since cargo and dune both have specfic file structures that don't exactly play well together.

As commented on that pr, this fix worked for me. Having only lightly used dune before this, I have found its style pretty different to cargo's making things seem a bit fragile.


Update README.md

Hi.
I updated a simle mistake on README.md.
Anyway, thank you for the awosome plugin!

Awesome, thanks for noting!


Data Binding

I've been using data binding with the Settings Plugin.  Would I use a similar setup or is there a better way?
https://jamesmontemagno.github.io/SettingsPlugin/DataBindingToSettings.html#approach-2-more-magical-way

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a7a399b1-a8a2-9cbd-c479-1bd98af46988
Version Independent ID: 91a6ae06-508b-b668-52aa-cbdeabb2b46a
Content: Xamarin.Essentials: Preferences - Xamarin
Content Source: docs/essentials/preferences.md
Product: xamarin
GitHub Login: @jamesmontemagno
Microsoft Alias: jamont

Yup! The same code basically would work for you here.

@jamesmontemagno I submitted a PR to add a simple snippet to clarify  https://github.com/MicrosoftDocs/xamarin-docs/pull/824

Based on feedback from #824 I have created a Wiki entry for this: https://github.com/xamarin/Essentials/wiki/FAQ-|-Preferences as it is outside of the docs scope to document use of the core API.


Dresden collection

Hi all,
this adds a Dresden collection.
Let me know what you think!
Best,
Robert

Fantastic!! Thanks @haesleinhuepf :D


fix: harmonize HTTP gateway response object when encoding fails

Closes #1845.
@bbenligiray you say in #1845:

As a note, unlike Solution 1, this keeps the rawValue name, which is misleading. This is not the raw response of the API, but rather the response that is post-processed by the Airnode.

And I agree

So if Solution 2 will be implemented, this field should be renamed to something more accurate, such as postProcessedResponse/postProcessedBody/postProcessedValue.

For consistency, wouldn't we want the field renamed in the case both of encoding success and failure? I assume yes, in which case this would be a breaking change for anyone using / expecting the HTTP gateway rawValue field. Now, we could argue that the HTTP gateway is experimental and its fields shouldn't be relied upon, but having this change in v0.12.0 --> v0.12.1 (as currently slated) feels a bit much. We could also say this is v0.13 instead of v0.12.1, but there is more process (e.g. docs release) for that.
What I've done for the moment is harmonize it so that rawValue is returned upon encoding failure like success, which is consistent if slightly inaccurate in name, but happy to make the changes throughout the codebase and docs (e.g. here, here, here, etc.) if you want it renamed.
I've tested rawValue is present and contains the expected API response from coingecko by using the CI-built client docker image and a wrong _path e.g. market_data.current_price.usd234 instead of market_data.current_price.usd.

For consistency, wouldn't we want the field renamed in the case both of encoding success and failure?

Yes

in which case this would be a breaking change for anyone using / expecting the HTTP gateway rawValue field

Yes

Now, we could argue that the HTTP gateway is experimental and its fields shouldn't be relied upon, but having this change in v0.12.0 --> v0.12.1 (as currently slated) feels a bit much.

Fair enough

We could also say this is v0.13 instead of v0.12.1, but there is more process (e.g. docs release) for that.

Indeed

What I've done for the moment is harmonize it so that rawValue is returned upon encoding failure like success, which is consistent if slightly inaccurate in name

Isn't this as breaking as the renaming of the field (even if at a smaller scope)? I don't see why we would update the schema while holding back renaming a field.

Isn't this as breaking as the renaming of the field (even if at a smaller scope)?

The change here (returning the response within rawValue instead of directly) only affects new v0.12 behavior and therefore likely affects very few people (data weren't returned before when encoding failed), whereas renaming rawValue breaks additional versions e.g. v0.11, v0.10, etc.

Okay, I'm convinced

@andreogle does this work for you? If so, would you mind giving it an approval?


New package: LazyFym v0.1.1

Registering package: LazyFym
Repository: https://github.com/JinraeKim/LazyFym.jl
Created by: @JinraeKim
Version: v0.1.1
Commit: 733ff88024dd77c366ed6ed206f21a287e5c8d2e
Reviewed by: @JinraeKim
Reference: https://github.com/JinraeKim/LazyFym.jl/commit/733ff88024dd77c366ed6ed206f21a287e5c8d2e#commitcomment-47378670

Superseded by #30544


Importing DistributionNotFound in a python 3.9 script causes AttributeError

Environment

pip version: 21.0.1
Python version: 3.9.1
OS: Darwin Kernel Version 20.2.0

Description

from pkg_resources import DistributionNotFound in a script causes and AttributeError, but works fine in an interpreter, (I assume it just doesn't hit this code path where it tries to find the module name) in both cases using the same python v3.9.1.
For context, pikepdf does this on import, so neither it nor anything which imports it (e.g. ocrmypdf) can be imported in a script or module.
Expected behavior
No error, imports.
How to Reproduce
Create a file:
#!/usr/bin/env python3.9
from pkg_resources import DistributionNotFound

and execute it.
Output
    from pkg_resources import DistributionNotFound
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3243, in <module>
    def _initialize_master_working_set():
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3268, in _initialize_master_working_set
    tuple(
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 3269, in <genexpr>
    dist.activate(replace=False)
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2783, in activate
    declare_namespace(pkg)
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2282, in declare_namespace
    _handle_ns(packageName, path_item)
  File "/usr/local/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2199, in _handle_ns
    loader = importer.find_module(packageName)
  File "<frozen importlib._bootstrap_external>", line 493, in _find_module_shim
  File "<frozen importlib._bootstrap_external>", line 1428, in find_loader
  File "<frozen importlib._bootstrap_external>", line 1473, in find_spec
  File "<frozen importlib._bootstrap_external>", line 64, in _path_join
  File "<frozen importlib._bootstrap_external>", line 64, in <listcomp>
AttributeError: 'PosixPath' object has no attribute 'rstrip'

I'm unable to elicit the behavior you describe with the repro. What other factors are present in your environment that might be contributing to the failure:
~ $ cd draft
cd: no such file or directory: draft
~ $ mkdir draft
~ $ cd draft
draft $ cat > script
#!/usr/bin/env python3.9
from pkg_resources import DistributionNotFound
draft $ chmod u+x script
draft $ ./script
Traceback (most recent call last):
  File "/Users/jaraco/draft/./script", line 2, in <module>
    from pkg_resources import DistributionNotFound
ModuleNotFoundError: No module named 'pkg_resources'
draft $ pip install setuptools
Collecting setuptools
  Using cached setuptools-52.0.0-py3-none-any.whl (784 kB)
Installing collected packages: setuptools
Successfully installed setuptools-52.0.0
draft $ ./script
draft $

Interesting, I can no longer reproduce it either; including now running again the code where I first discovered it, which imports ocrmypdf.
Happy to close, but I'd be curious if you have any idea what it could have been - what could possibly have happened (and unknowingly changed since yesterday!) to my envionment to cause that?

Ah! Apologies, it was my fault - I put a Path in sys.path. (Which for the purposes just of importing, works, but the docs  do say only that it should be strings, so mea culpa.)
Cheers.

@OJFord  Hello, I face the same issue here, how do you fix it?
    def _zipinfo_name(self, fspath):
        # Convert a virtual filename (full path to file) into a zipfile subpath
        # usable with the zipimport directory cache for our target archive
        while fspath.endswith(os.sep):
            fspath = fspath[:-1]
        #fspath = os.fspath(path) #fspath = fspath.rstrip(os.sep)
        if fspath == self.loader.archive:
            return ''
        if fspath.startswith(self.zip_pre):
            return fspath[len(self.zip_pre):]
        raise AssertionError(
            "%s is not a subpath of %s" % (fspath, self.zip_pre)
        )

Thanks in advance!


Support for ARM architecture

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hey, @grizzlyhackle I've just set up cello on m1 chip running under rosetta.
You could simply hardcode these values in Makefile
ARCH   := x86_64
DOCKER_BASE_x86_64=x86_64/python:3.6


upgrade A-Frame version

https://aframe.io/releases/0.7.1/aframe.min.js

Archived project. Unassigning.


Queue

Browsing the code I've seen a custom implementation of Queue. Since there is a queue on the Standard Library, why not use it?  it may be useful when doing threading? and there is less code to maintain.
If this is not the direction you want to take feel free to close this PR. I just did it because it seems like reinventing the wheel a bit.

Codecov Report

Merging #239 into master will increase coverage by 0.20%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #239      +/-   ##
==========================================
+ Coverage   98.44%   98.64%   +0.20%
==========================================
  Files           7        7
  Lines         385      369      -16
  Branches       39       39
==========================================
- Hits          379      364      -15
+ Misses          3        2       -1
  Partials        3        3

Impacted Files
Coverage Δ

bayes_opt/bayesian_optimization.py
100.00% <100.00%> (+0.98%)
:arrow_up:

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 cb28df8...198d6e2. Read the comment docs.

Of course there is 🤦 .
When implementing it I didn't even think about it, but I agree, not re-inventing the wheel is definitely the way to go. If you don't mind fixing the conflict and squashing the commits into 1, max 2, commits, I would love to get this merged =)

Ok, first time squashing and it seems I have squashed more that what I should. I will have to check how to fix it, my bad.

Actually, the Files Changed section of the PR seems about right, but if I check the use queue from the standard library commit, it seems to be including some documentation and some other commits. I haven't been able to "fix" it, so maybe it is already ok (?).
Please let me know what you think. :-)

Codecov Report

Merging #239 into master will increase coverage by 0.20%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #239      +/-   ##
==========================================
+ Coverage   98.44%   98.64%   +0.20%
==========================================
  Files           7        7
  Lines         385      369      -16
  Branches       39       39
==========================================
- Hits          379      364      -15
+ Misses          3        2       -1
  Partials        3        3

Impacted Files
Coverage Δ

bayes_opt/bayesian_optimization.py
100.00% <100.00%> (+0.98%)
:arrow_up:

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 ab8ca64...847b4ee. Read the comment docs.

Fixed!

Hey @alonfnt, sorry about the slow response. Could I ask you to make any commit to this branch, which will trigger the (recently working again CI) to run?

@bwheelz36 done :)

thank you!


0.3.4 Doesn't work on Ubuntu 14.04

./DriveShare: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

It seems that amd64 version is actually i386. file DriveShare says
DriveShare: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.26,
BuildID[sha1]=826095c3c9010be4e2be9179937bc92535855c4d, stripped

32 bit non-static binary: not a good choice, imho; especially if you didn't set the correct dependencies in the package.
Unlike windows, linux installs have all been 64 bit for many years now, no sense in making a 32 bit binary.

I confirm this bug

Yes, same here: DriveShare: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=826095c3c9010be4e2be9179937bc92535855c4d, stripped

I generated a 32 bit ubuntu executable through a VM, and I'm not sure I can get a 64 bit version up and running. I'll try when I have some time, but any help in this matter would be very appreciated.

@phideas @rkfg @pallas1 @winsvega @guyjames There as been a major release. See if 0.4+ fixes your issues. For Linux I would just highly recommend pulling from master and following the instructions. Only 3 simple commands.

Latest DEB package still doesn't run on Ubuntu 14.04.
Leaving here the errors so you can iron out some bugs.
Next I'll try to install manually.
[6666:1210/001839:ERROR:browser_main_loop.cc(189)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot find module 'fs-jetpack'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (/opt/DriveShare/resources/app.asar/lib/electron_boilerplate/window_state.js:8:15)
at Module._compile (module.js:430:26)
at Object.Module._extensions..js (module.js:448:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)

Thanks, looks as simple as a missing dependency during release bundling. Will resolve.

Installing manually failed for me as well.

I got it to work on ubuntu 14.04 by doing:

Install NVM:
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.29.0/install.sh | bash Download source: git clone https://github.com/Storj/driveshare-gui.git && cd driveshare-gui
Install Node
nvm install node Compile code: npm install
Start program:
`npm start

Now it starts up and asks for a password (presumably means create one, but when I put one in and press Enter nothing happens... that's another issue though of course).

@guyjames the password it's asking for is your user password (needed for installing dataserv-client depencies via apt). I'll improve the language there.

I don't think installing from source should use apt: what about the distributions not using that tool?
Dependencies should be listed in the documentation (INSTALL file) so the user knows what to do before compiling.
The compiled package just needs to list the dependencies inside itself.

Well let me be more clear: apt is used to install python and python-pip if they do not exist (which is unlikely on most GNU/Linux distributions). Then pip is used to install dataserv-client.
In any case, I'll include instructions for installing dependencies in the README. The debian package that is created for bundled release should certainly make use of the system's package management instead of the current method, but let's track that issue separately. For this specific issue, I'm only concerned with getting the bundled release working for debian-based systems.

@pallas1 another option that I think I prefer is to not provide a debian package at all, but instead provide a bash script in the repo that GNU/Linux users can curl or wget, and pipe to sh that will handle dependency installation and setup based on the distro.
This would greatly reduce the overhead of maintaining different packages for different distros and remove the need to handle dependency installation from within the application.
What do you think about something similar to that?

I would leave the shell script installation as a last resort. Having a well made deb file will open doors to many distros and could even be included in some repositories, even the official ones when it's the right time. Add rpm and you've covered the most popular distros.
The shell script would need to be maintained and tailored for the various distributions, just like the package files. And it will need to have very careful error checking, or it'll risk to make a mess.
Personally I'm a bit concerned when I'm asked to run a shell script with root privileges, I usually just avoid the installation all together.

Thats a nice wish but at the moment not possible: https://github.com/atom/electron/blob/master/docs/tutorial/supported-platforms.md

Retest with debian 8.2 failed.

@littleskunk what failed? I am running Debian 8 as my primary.

@littleskunk, I am going to have to do this the correct way and abandon the method that was in place when I adopted this project and move all dependency setup to the Debian control file (like I admittedly should have done in the first place).
There are just too many potential problems with trying to install dependencies through the app on first run.
@pallas1 I'll try to have this resolved today.

Retest ok. I used a virtual box image with ubuntu 14.04. I generated a new binary and restored a old savepoint after the ubuntu installation. That way i had no npm or nodejs installed.
Ubuntu software center installed driveshare-gui and i was able to start it, select a folder, see the free space and start farming. Everything fine. Well done :)
Fix will come with driveshare-gui 0.4.2.

@littleskunk awesome, great to hear! If you think it's good to go, can you go ahead and merge #100 into develop?
Side note, I opened an issue on dataserv-client to handle creating a proper debian package for that project, which would allow us to remove the postinst script that does pip install of dataserv-client, making both of these projects package The Debian Way™ and  allow us to publish them both the the Debian archive, letting users install with:
apt-get install driveshare

I am getting the same error on my Win 10 machine now.  Any solution for this?

Ubunto error on a windows 10 machine? Are you sure this is the right issue?

See screenshot.

Looks like you need some more help. If you use driveshare-gui on windows it will download and use dataserv-client binary. No need to upgrade it yourself and no need to install python.
Please join slack: http://slack.storj.io/ channel test_group_b. You will find me there (slack user name skunk). Lets speak about the right installation process for your needs.


MarkdownEditor is not working

By clicking on a Markdown (or TXT) file I am offered to open it with the Markdown Editor.

But only an empty UI appears.

Tested with ocis-latest.owncloud.com

Thank you!


[Settings] Adding a Dashboard Panel

Summary of the Pull Request
Adding a new Dashboard panel to the settings app. It contains the active modules with a brief description, activation shortcut if present, launch button if reasonable and a quick link button to the module's settings page. The new dashboard panel contains a list of all the modules as well, where the user can toggle the modules' enabled/disabled state.

PR Checklist

[ ] Closes: #xxx
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed
Tested locally

amazing
Playing with this, i really like it but think we need to unifi the "shortcut" look / feel.  I think we need the additional

vs

would love to see KBM in it as well

amazing
Playing with this, i really like it but think we need to unifi the "shortcut" look / feel.  I think we need the additional

vs

Yeah, was planning to update the colored ones to the new one in a separate PR. Noted 👍

would love to see KBM in it as well

Do you mean the remapped keys itself? Do we have a gut feeling on what a realistic amount of remappings are (to make sure the card doesn't become huge)

Do you mean the remapped keys itself? Do we have a gut feeling on what a realistic amount of remappings are (to make sure the card doesn't become huge)

My interpretation wss that the buttons should e similar to the buttons on the corresponding settings page. Maybe I am wrong?
I've started to implement it, the current state is:

@donlaci
The issue is #26816. Please reference it in the PR description.

And a screenshot (of the latest result) would be welcome please

The latest state

Idea: if it were me, I would place the togglebuttons inside each settings card. That would eliminate the entire "all apps" column. It feels very fragmented now, to me.

Having that said... The content of this page would be ideal to use as a new fly-out for the tray icon. I've had this idea in my head for a long time. I'll see if I can describe it in one issue of my issues...

Maybe we could use something for "more settings" that looks the same as in Windows 11 Settings.

Idea: if it were me, I would place the togglebuttons inside each settings card. That would eliminate the entire "all modules" column. It feels very fragmented now, to me. (Inactive modules would/should not be hidden then)

Hi @Jay-o-Way
Do you mean an implementation like this?:

It is a possible implementation. The right panel can be dismissed in this case.
One of the goals is to have a brief overview of the enabled PT features and the presence of the disabled modules inhibits the overview.
Another implementation could be to have the togglebuttons on the left like on this example picture, having only the enabled modules without the right panel and also having an "Add modules" button which would open the right panel with all the modules. I'll try to create a small example gif for that implementation.
I am not pushing any of the implementations, just want to give choices, alernatives.

Idea: if it were me, I would place the togglebuttons inside each settings card. That would eliminate the entire "all modules" column. It feels very fragmented now, to me. (Inactive modules would/should not be hidden then)

Hi @Jay-o-Way Do you mean an implementation like this?:
It is a possible implementation. The right panel can be dismissed in this case. One of the goals is to have a brief overview of the enabled PT features and the presence of the disabled modules inhibits the overview. Another implementation could be to have the togglebuttons on the left like on this example picture, having only the enabled modules without the right panel and also having an "Add modules" button which would open the right panel with all the modules. I'll try to create a small example gif for that implementation. I am not pushing any of the implementations, just want to give choices, alernatives.

@jay-o-way Yes, we have explored that option as well. The biggest challenge is to make sure there's a clear overview of what modules are enabled or disabled, that's where the list on the right works well.
But I agree, with the amount of modules this becomes challenging to keep clean and glanceable.
@donlaci I like your "collapsing" state when a module is disabled - maybe we could extend that by removing the list on the right and collapsing cards that are disabled? Additionally, we could grey out the icon/module name when disabled to make the active cards "pop out" a bit more.. Happy to play around with that if you have an active branch - I think it's worthwhile to explore this :)!

Happy to play around with that if you have an active branch - I think it's worthwhile to explore this :)!

Here is an implementation with only the active modules, and an "Add/Done" button which toggles the "All modules" panel presence.
Just another alternative :-)

@donlaci yes, that's what i mean :-)

@donlaci, the mockup lacks a clear indication of updates and new additions of modules since the last installed version. Lazy users like me often find checking the changelog cumbersome, leading to ignorance, as suggested in #21122. It would be convenient to include small icons or indicators alongside updated and new modules, facilitating quick tracking module-by-module checks.
Additionally, as suggested in #21122, a brief walkthrough since the last installed version would be pretty darn amazing! For those who don't need it, adding a quick-simple on/off switch on the homepage would suffice.

@Droyk, #21122 is out of scope for this feature.

I'm not thrilled with the dual toggle.

The toggle is the eye is drawn to the toggle versus the information on the screen
We need to segment the enabled stuff in the dashboard.  The entire point is to help with glanceability and enable the user to do more.  The enabled / disabled have to be segmented which then adds a lot of

I have text extractor enabled but the view isn't helpful.

or randomly 3 enabled.

Do you mean the remapped keys itself? Do we have a gut feeling on what a realistic amount of remappings are (to make sure the card doesn't become huge)

Not showing it defeats the purpose.  I think most people would only have a few but it is a realistic worry for lots of remappings

I think the best is to show only the dashboards for the enabled utilities and have the list of all utilities always visible. (Maybe a search in the "all utilities" is helpful. 🤔) Everything else is imo not really useful to get a fast overview.
Can we order the list of all utilities by enabled state? Does this makes sense?

The current state after implementing the required changes:

@donlaci
The + button is confusing as it say you add remove item from the dashboard. But instead you enable/disable the utilities. We should use a different icon.

@donlaci
The + button is confusing as it say you add remove item from the dashboard. But instead you enable/disable the utilities. We should use a different icon (E700 or E7E8).

Agree with the comment, but i would recommend
E89F	ClosePane
E8A0	OpenPane

@donlaci
What about the update indicator from the screenshot linked in our readme? Is it gone?

@donlaci What about the update indicator from the screenshot linked in our readme? Is it gone?

@htcfreek
The update indicator is visible only if there is an update.

What is you opinion about the "edit" glyph? (e70f)

What is you opinion about the "edit" glyph? (e70f)

@donlaci
Same problem. This looks like edit dashboard and not like manage enabled state of utilities.
 For me this makes no sense.

Current way with always showing the enabled/disabled seems like it's not too useful as a dashboard. This is what it shows on default size of the Settings app:

Tried a release CI build to check if everything's OK. Built well and ran fine :)

It is hard to fulfil every request. Some decisions were made, the current dashboard looks like this:

I've added a commit to make the Dashboard page callable from OOBE General page instead of the Settings General page.

Going to merge this PR soon. I think any further changes can come in following PRs. Thanks everyone for the reviews 😄

Merging it now. @donlaci , can you please address the remaining comments on a follow up PR?


Do you use any tests' set for OPCI?

Hello,
I'm just curious, how do you test your OCPI implementation?
Are you using any test suite? Or did you write something yourself?

Hello @cbelyaev, I have to admit that this library in it's current state lacks tests.
My main way of testing this right now is that I use it in a real implementation of an OCPI service and having that service integrate with other OCPI services in the real world. The library itself does not contain too much logic, right now it is for the most part just a bunch of contracts plus some small functionality like endpoint mapping (for Versions module), which I have tested manually after implementing it. And then again, I am using this in a real implementation myself, and everything seems to work. And I am not planning to change anything logic-wise for some time. So I don't think tests are super important right now.
I am thinking about adding some tests later, but I have more important things to implement first - for example documentation. I think the package lacks documentation more than it lacks unit tests. And I am lacking time to implement everything this package requires 😔

@cbelyaev I am not sure about what you are referring to by 'other services'. Do you mean other OCPI implementations by external parties? Or do you refer to some code in this library?
If you are referring to something in this library, please elaborate what it is in particular.

@cbelyaev
By that I am referring to external OCPI implementations by third parties. For example, you can implement an eMSP using this package and then have it connect with a real external CPO. Or vice versa - implement a CPO and then have it connect with an external eMSP (e.g. Plugshare)
Those external services are all different - and sometimes have minor deviations from OCPI. They are implemented by external parties and we do not control their implementations.
In general I would say that if you use this library then everything should go smoothly when connecting with them. I have reviewed several real external implementations and now am writing this library in a way that it can support slight deviations in connected platforms like those that I have observed.
If you find any serious deviations in external OCPI implementations and have ideas how to update this library so that it supports working with them - feel free to share!

Thanks a lot for your detailed answer!


connect to localhost from emulator with different port number

I have problem geting this to work. I want to connect to localhost:8081 but this code not workin:
AsyncHttpClient client = new AsyncHttpClient(8081);
...
client.post("http://<IP_ADDRESS>:8081/mysite/my_api.php",params, new JsonHttpResponseHandler() {
...

error I get:
java.io.IOException: Unhandled exception: Host name may not be null

thank you very much


Finagle adjuster - Add timestamp and duration if missing

Currently in Finagle Adjuster we apply timestamp and duration to a span only if it contains a binary annotation with the key "finagle.version".
Some legacy instrumentation libraries also use finagle thrift schema and don’t have timestamp and duration fields populated for the Spans. We should add an adjuster that can be used to fill these fields, if they are empty, irrespective of binary annotation availability.

We can add a property zipkin.sparkstreaming.adjuster.finagle.alwaysApplyTimestampAndDuration for this feature.
@adriancole thoughts? I can make the change and send a PR.

You mean instead of only when it is a finagle span? Easier for email review
to know what happens now and what would be different

public abstract class FinagleAdjuster extends Adjuster {

  abstract boolean issue123();
  abstract boolean issue456();

  @Override protected boolean shouldAdjust(Span span) {
    if (issue123() && containsIssue123(span)) return true;
    if (issue456() && containsIssue456(span)) return true;
    return false;
  }

  @Override protected Span adjust(Span span) {

    Span returnSpan = span;

    if (issue123()) {
      returnSpan = patchIssue123(returnSpan);
    }

    if (issue456()) {
      return returnSpan = patchIssue456(returnSpan);
    }

    return returnSpan;
  }
}

And we can have class Issue123 and Issue456 then implements containsIssue123 and patchIssue123

@naoman yep this will work for up to probably 3 adjustments, after which would need to be refactored into a composite I think.

our finagle adjuster currently supports this


search: configure faceting + release

Coverage increased (+0.02%) to 90.387% when pulling 0afed01a4725aa65e5cff5a2323e9a85947f743d on fenekku:279_reenable_faceting_ui into e97570cb52ecde3458f9c7fa3e3f1180a78e83b4 on inveniosoftware:master.