Revise the map search pages so that they are updated and match the rest of the site

Map search pages all currently here

@rlskoeser @thatbudakguy Here are the designs for when there is a map view on the Member search page.

Nick and I had agreed that:

Even though there is pagination on the "list view" it won't work for the "map view" and there won't be any on the "map view", so it will be an infinite scroll.
On desktop and tablet, in order for the user to interact with the map they will need to select a pin on the map, which would highlight and bring to the top of the list (on the left side of the page) the information of the member/the owner of that pin.
On desktop and tablet selecting a "member container" on the left side of the page, on the list will take the user to that member's biography page.
On mobile, by default the user will only see the map and no member information. In order for the user to interact with the map they will need to select a pin on the map, which would bring to the bottom of the pin the information of the member (slides up on the map, so it's viewed easily rather than it appearing at the bottom where the user won't notice).
On mobile, when a pin is selected the map becomes dark to further highlight the pin so that it is more visible on this small screen.
On mobile, selecting a "member container" that has appeared at the bottom of the pin will take the user to that member's biography page.
There won't be a way for the user to select more than one pin at a time. When a second pin is selected the previous pin is deselected.
On all devices the default view of the map would be as zoomed out as possible with the library pin in view (preferably in the center), and no pins selected.
On all devices in the map view the list of the members won't are not numbered like they are on the list view.

Note: As you see I have two versions for the mobile screens: one is what Nick and I had agreed on, and the other one is my proposal to show the full list by default (infinite scroll), just like how it is for desktop and tablet, where a member container would be highlighted and appear at the bottom of the pin when a pin is selected. I don't feel strongly about it, just thought it would be good to raise this right now as we are coming back to it.
Some unfortunate UX desires :D
Initially I was hoping:

There would be a way to select a member container on the left that would highlight the pin associated with it on the map. But I can't think of a way to do it without complicating it (meaning without adding any additional controls on top that would help)  – Because selecting a container would need to take us to the biography page.

There would be a way to select more than one pin at a time so you can see more than one member's info appear at the same time stacked on top of each other to make it easier to compare information. But again, I can't think of a way to do it without complicating it (meaning without adding any additional controls on top that would help) .

There would be a way that by default all pins show the most information above them. (the member's name? or membership dates?) – This would actually be nice so that there is a bit more information provided to the user before they decide to select any pin.

I feel strongly about my number 3 above. It would really help and add a lot if there is a way!

Thanks for working on this @gissoo.
I don't understand what you mean for 8 — "map would be as zoomed out as possible"; we want to have it focused on Paris with the store visible even though we have locations outside of Paris, right? I wonder if there is some way with leaflet to indicate the number of locations available that are not visible (or if not the number, at least that there are more).
On the UX desires:

I get what you mean — most people's reference for this is probably going to be Google Maps, and that is more how it operates. Maybe we could override the link behavior for the card in the map, but we'd still need some way to get to the member detail page.
Not sure how/if that would work, think we should not worry about this one (for now at least)
I'm not sure I understand this - you want to show text on the map? How do we do that without it getting cluttered?

One thing that jumped out at me when I looked at the designs — can we come up with better labels than "list view" and "map view" ?

Thanks for working on this @gissoo.
I don't understand what you mean for 8 — "map would be as zoomed out as possible"; we want to have it focused on Paris with the store visible even though we have locations outside of Paris, right? I wonder if there is some way with leaflet to indicate the number of locations available that are not visible (or if not the number, at least that there are more).

I agree! That would be great.
So it won't be possible to show all of the addresses (meaning having the map zoomed out to show all the pins) but still have the library pin visible in the middle? I was trying to find on the database to see which other cities/addresses there are other than the ones in Paris, but can't see without easily without paging through the data.

On the UX desires:
1. I get what you mean — most people's reference for this is probably going to be Google Maps, and that is more how it operates. Maybe we could override the link behavior for the card in the map, but we'd still need some way to get to the member detail page.

I agree.

2. Not sure how/if that would work, think we should not worry about this one (for now at least)

I agree

3. I'm not sure I understand this - you want to show text on the map? How do we do that without it getting cluttered?

Correct, it's okay if it gets cluttered by default, I'm imagining once zoomed in it won't be cluttered. (I'm thinking of it being something short, maybe one piece of information that is most helpful in this context to be seen first, it can be laid out to not be wide, rather tall) – might be more challenging with membership dates.

A few things that occurred to me when I looked at the designs:
1. Can we come up with better labels than "list view" and "map view" ?

Sure! Thanks for thinking of this. I can think about it.

2. I'm not sure how important the card icon indicator is in this view (most members with addresses will probably have cards since that's where the addresses came from until we started adding more from the address book); what do you think about dropping it so we have more space for the text on the member cards?

I think it's useful to have it, how many do you think won't have a card here? Out of how many? I might be fine with dropping it – so if we drop it, in this view the card filter won't work? Or will work but not show the card icon?

3. How important is it to include arrondissement on the cards? Is that the best way to display it?

I think it's useful to have it there, it's very relevant to have it in sight there. How else can we display it? I would like it more if there was a way that when you look at an address on the list it would mean something on the map – if the map had some numbering on it so it would be easier to understand and relate it to the address on the list.

4. "Membership Dates" is now years, and could be longer than what you have on the mockup.

Thanks, just updated them, I was updating them the other way around by mistake :D I think it's ok if they are longer – can show variations with dates – the width won't become a problem, it might make increase the height of the container and I can define max width for the text inside the container.

5. The maps on the individual member pages show the actual address when you click on the pin; is it problematic or inconsistent to not have that detail available here?

Thanks for reminding me of this!! I think it would be nice to show it on the list! Not sure if it's useful on the map here, but it might be nice on the list!

@gissoo is the intent that we should discuss all aspects of the design of #201 here? just want to make sure that things don't get lost.
i have a thought that simplifies some things, but is a fairly radical departure from the design, so wanted to throw it out now in case it gets anyone else thinking.
consider a map view that operates very similarly to google maps, where:

the side pane (or bottom pane on mobile) shows only one member at a time, and thus displays as much detail as is desired (perhaps we can call this the "detail pane").
the detail pane includes a link to view the detail page for the selected member, as well as a button to hide/collapse itself and show only the map again.
clicking any pin on the map shows the detail pane, as well as displaying a popup next to the pin that shows the address information (just like on the member detail page map).
entering a query or using filters changes the pins that are displayed on the map, but has no other effect.

in this version, there is no sorting, pagination, or scrolling - just a detail pane that shows the equivalent of a single member's result. we assume that if the user has switched to this interface, their primary way of "browsing" is via the map itself, because they are interested first and foremost in where people live.

@thatbudakguy Yes, that is the intent (and to bring RSK to the loop since I know many of the discussions we had on this last year was between you and I – so just wrote above on what you and I had agreed on for RSK and also as a refresher and confirmation for the both of us too)
I like the way you're thinking about it! – It's very similar to what I have shown and what we agreed to for the mobile version – except it will be that way for all devices, I think it makes sense. It will put the focus entirely on the map this way, it's better than showing everyone with infinite scroll and not really letting the user get from the member to the map (no clicking on the member to get a response on the map) – it makes sense – I will look into the designs further and share with you in case there are any concerns for design and usability.

@thatbudakguy I also proposed that we show a piece information on the pin that will be relevant, because it will give more clues to the user before they select a pin, not sure if the address would help us achieve this goal – RSK, in a comment above asked what if it clutters the map – where I responded "Correct, it's okay if it gets cluttered by default, I'm imagining once zoomed in it won't be cluttered. (I'm thinking of it being something short, maybe one piece of information that is most helpful in this context to be seen first, it can be laid out to not be wide, rather tall) – might be more challenging with membership dates."

I started a comment the other day and then lost track of it in a tab somewhere...
One of my concerns was that the discussions Gissoo and I were having were making it more complicated, and that we need to keep it as simple as we can while providing the appropriate functionality. Nick, glad to hear you thinking about this too!
Showing only one member at a time and making the different screens more consistent sounds like a good approach. I wonder if this losing something towards allowing users to easily compare multiple members locations, but even if that's the case it might still be worth the trade-off.
@thatbudakguy this suggests to me that the panel can be generated from a portion of the member detail page we already have (with some adjustments, hopefully minor).
@gissoo I think this map should be consistent with the individual member map as much as possible; I suggest we show addresses when a pin is clicked, not by default. It seems like it is likely to be cluttered if we're showing them all when the results aren't filtered. (Maybe it will be easier to tell when we have started working on it?)
@gissoo I have a suggestion for the tab labels based on a question that occurred to me. I was wondering what the "total results" count for the map view refers to, members or addresses (the way I'm thinking of implementing is indexing and searching/filtering on addresses in tandem with the associated members). Could "members" and "addresses" work for the tab labels? Or is that confusing/redundant since the page title is "members"?
I commented on slack that switching to the map implicitly applies a filter to members with addresses, and that it would be good to make this explicit. I'm wondering – if we make a hidden form input (has address), will the selected filters logic do almost the right thing without much more work? Clearing the input would need to switch back to the member list, but otherwise it seems pretty close to current logic.

@gissoo the card icon question might be different now if we're only displaying member details for one member and it is based on the existing member details page (my proposal). However, some numbers to follow up on our earlier conversation:

1495 members with an associated address
894 members with address but no card

That number is higher than I thought it would be; must be due to all the data work Ian has been doing with the address book.
The card filter should still work whether or not we display a card indicator on the member detail tile.

@gissoo @thatbudakguy one thought/question: is there a way to highlight other addresses associated with the same member, for members who have more than one? Asking both about interaction and implementation here, as I'm not sure about either.

@rlskoeser What if it's "All Members" "Members with Address" – I think it's still about members and even though there is a title up there "MEMBERS" it's odd to just have "addresses", it can be confusing. I know the way we are thinking about it now makes it to be logically about the "Addresses" however I think "Members with Address" would make it more inclusive in the sense that there is a way to find a "member" eventually.
I still think it makes sense to have the card icon there, especially since the card filter is working here.

Let's keep thinking about the labels, I'm hoping we can come up with something shorter than this. All members seems confusing, because as soon as you search or filter it isn't all. I think list/map might be preferable.
I agree, card icon is more important than I thought, since there are a lot of members who have addresses but no card.

Based on our meeting we agreed:

Map is focused on Paris and the library by default on all devices.
Upon selecting a pin one member's info will be shown on the left on a side bar that extends to the bottom of the map on desktop and tablet.
Upon selecting a pin one member's info will be shown on the bottom of the map on mobile
Erase the address from the member's container.
The address will be on the map on click/select (in the same format as it is on the biography page).
The height of the map on mobile is not full height – and the container appears at the bottom of the map in a way that is visible to the user.
Upon selecting a part of the map that has no pins the side bar is deselected and therefore disappears.
There are no sorting and no pagination options.
The search bar and search results text to indicate that the results are focused on "addresses"
Determine a visual indicator for selected arrondissements – include what it would look like if they need to be visually shown by default.
The pins show members' names on them by default – show what that looks like.

@rlskoeser @thatbudakguy @jkotin Please take a look at the design variations here and let me know what you think:
Disclaimer: You will definitely find the correct names don't match with the correct addresses as well as membership/birth/death years & the position of addresses and pins on the map are not correct – please ignore these as the purpose of these designs is not to communicate correct data – rather to communicate the variations of responses and interactions users can have with the map search
Member List view – This is just to show you what will change in the current member search (the addition of the "list view" and the "map view")
Member Map View with & without neighborhoods – There are two variations here: One where the default map shows the arrondissement + one without it.
Pin Selected – One member associated with 1 address – Desktop
Pin Selected – One member associated with 1 address – Tablet
Pin Selected – One member associated with 1 address – Mobile
Pin Selected – One member associated with >1 address in view – Desktop
Pin Selected – One member associated with >1 address in view – Tablet
Pin Selected – One member associated with >1 address in view – Mobile
Pin Selected – One address associated with >1 member – Desktop
Pin Selected – One address associated with >1 member – Tablet
Pin Selected – One address associated with >1 member – Mobile
Active Arrondissement filter – Members Map Search – Desktop – what it would look like on the map when arrondissement filter is active (I imagine the user can select the arrondissement on the map directly as well – obviously this maybe out of scope/not viable, but design-wise it will make sense just FYI)
Notes:

Map is supposed to be focused on Paris and the library by default on all devices.

Pins show the members' names by default (can show two names at the same time on one pin, have an indicator of "more or "..." if there are more names, maybe?) and each pin shows a number like: 1/4 (meaning this is pin 1 of 4 of member x, meaning they have 4 total addresses and this is their first address – happy to reformat this to a clearer/more accurate/possible format) – (it's better if we can do these, but also if it's not viable it's fine – I know RSK thought it would be helpful to have the names at least) – if not, then pins would not show any info by default

Upon selecting a pin the address will replace the member's name (again, this is only true if 2 (above) is implemented – if not, then I imagine the white containers on the map would show the address when selected (just like the biography page)

Upon selecting a pin one member's info will be shown on the left on a side bar that extends to the bottom of the map on desktop and tablet. (the info in the side bar will have the same visual layout across all devices to simplify things – the visual layout is the same as the mobile members results page – (information consists of member's name, birth/death, card, membership years)

Upon selecting a pin one member's info will be shown on the bottom of the map on mobile

The height of the map on mobile is not full height – and the container appears at the bottom of the map in a way that is visible to the user. I did some research and chose a safe height for this.

Regarding the height of the map on desktop and tablet, I think they should be full, however to make it possible to scroll past the map to get to the footer, I think we could leave some space on the left side of the map so it's not full width – I think it should be full on the right, not on the left if that's easier (I don't like the idea of it being centered like it is on the biography page – happy to discuss though).

Upon selecting a part of the map that has no pins the side bar is deselected and therefore disappears.

There are no sorting and no pagination options on the map search view.

The search bar and search results text to indicate that the results are focused on "addresses" – I chose "Search members who have addresses" but it doesn't fit on mobile – happy to go with what you suggest – I think it will help a lot to have something about the "addresses" in the search box text as a hint.

Tested with visually indicating arrondissement and what it would look like when are they are selected/filtered. (would be nice to have – but understand if it's too much and not viable right now)

Revised the default and selected style of pins – really started to hate the default being green on this page specifically – it's not logical, visible enough nor consistent with the logic of the "green" color on the site. (We use green for when things are "active"/selected).

@thatbudakguy  you made a point yesterday about an address with >1 member on the map and if we could hover over to see the individual members and select the one we want – I think it's complicated on tablet and mobile, and it's more preferable if the user can see as many members on a pin as possible so that when they select the pin they can see their info in individual containers on the left/bottom.

@gissoo The maps look amazing!  I'm going to need the weekend to review closely. If you'd like preliminary notes now, I can send them and then follow-up.  Of I can sent notes on Sunday.  Thank you for all this incredible work.

@gissoo -- I was able to make some notes this afternoon, so I send them along now.  I'll return to the maps over the weekend and see if I have anything to add or revise. My notes are in no particular order:

Member names should appear as: first name last name.

Address format should be:

First Name Last Name
Number Street
Paris Arr
For example:
Sylvia Beach
12 rue de l'Odeon
Paris 6e

I would prefer that the arrondissement not be demarcated, or only demarcated when the arrondissement filter is being used. (Apologies if this was in the intention all along!  I think it is.)

When/if an arrondissement is demarcated, its borders shouldn't overlap the address bubbles.

Would the search prompt be better as: "Search members with addresses" or "Search members with known addresses"?

Do we need 1/1 if there's only one member at a specific location?  I don't think so.

7a. I think the name of the member should always be in the address bubble, even if the name is also in the pane on the left.  I worry that disconnecting the name from the address will cause confusion.
7b. I understand that it's probably necessary to disconnect the member name from the address when multiple members have the same address. A hotel, for example.  In such a case, we would include the hotel name, presumably.

Do we have -- or will we need -- a way to shorten long names?

Members with multiple addresses:  I see that we show all the addresses simultaneously -- this is good.  I think we might not need the 1/4, 2/4, etc.  You refer to a member's "first address," but the addresses in the database do not have any real order.  We haven't matched addresses to dates of residency, although most most addresses do happen to correlate to dates of residency, i.e. when a member only has one address or when a member has a short membership.

Number of addresses shown: is it possible to display a map with all the addresses in the database?  Is there a limit to how many addresses can be shown?  If so, what is it, and what addresses are shown if the limit is reached? I suspect some filters will result in 500 addresses or 800.

A potential problem: we know that a member had a given address, but we do not know when that member lived at that address -- that is, we do not know the member's dates of residency. So I can imagine filtering for members from 1936 and displaying addresses that were no longer active in 1936.  I worry that the map will imply that an address is active in the specified year.  Should we disallow filtering by membership year for the map view?  Should we show the member years in the address bubble? Another way of putting this problem: there is an symmetry between the list view and the map view: on the list view, all the members were active in the specified year, but in the map view all the member addresses might not have been active in the specified year.

It might be helpful/useful to see how the maps look when the street names can be read.  (I.e. with zoom.) How do the address bubbles fit with the map in detail?

I realize this is out of scope, but I'll mention it here: it would be FASCINATING to be able to select a member and then show all the other members who borrowed the same books.  It would also be fascinating to be able to select a book and show the addresses of all the members who borrowed it, and to have some kind of "chronological circuit" to connect them: to trace, that is, the geographic circulation of a book.  I'm trying to think about the intellectual stakes of the map. I've always been interested in the relation between proximity and taste.

@gissoo -- I was able to make some notes this afternoon, so I send them along now. I'll return to the maps over the weekend and see if I have anything to add or revise. My notes are in no particular order:
1. Member names should appear as: first name last name.

Design-wise this makes sense to me, however I wanted it to be more consistent with the "list view" where we show the member's name "last name, first name" – I do think "first name, last name" is generally easier to read. There is no sorting here either so I think it should be fine? – Would defer to @rlskoeser in case it creates any issues I'm not aware of.

2. Address format should be:

First Name Last Name
Number Street
Paris Arr
For example:
Sylvia Beach
12 rue de l'Odeon
Paris 6e

@jkotin Our idea is to have it be the same format as it is on the biography page. @rlskoeser @thatbudakguy might have more thoughts on this. I'm flexible with this.

1. I would prefer that the arrondissement not be demarcated, or only demarcated when the arrondissement filter is being used. (Apologies if this was in the intention all along!  I think it is.)

Not having it at all probably makes things much less complicated for now.
However, if we end up having this feature: My initial intention was not for the arrondissement to appear only when the filter is active, however after stepping away from this for a few days this makes a lot more sense and I agree that it should appear only when the filter is active. In this case, it will never be in black/grey, it will either not be visible on the map or it will be green (for when the filter is active).

2. When/if an arrondissement is demarcated, its borders shouldn't overlap the address bubbles.

I'm not sure if this is possible, I'm imagining it would be inevitable when the map is zoomed out. @rlskoeser @thatbudakguy what do you think?

3. Would the search prompt be better as: "Search members with addresses" or "Search members with known addresses"?

Thanks! the "known" makes sense! I think "Search members with known addresses" would make more sense.

4. Do we need 1/1 if there's only one member at a specific location?  I don't think so.

I don't feel strongly in the case since they are all on the map and the user is not looking at one member at a time (because in that case I think 1/1 makes sense to familiarize the user with the concept), however, here I agree and I'm not sure it's needed.

7a. I think the name of the member should always be in the address bubble, even if the name is also in the pane on the left. I worry that disconnecting the name from the address will cause confusion.

I'm not quite convinced, in my opinion it's repetitive information and can become problematic when there are 3+ members associated with 1 address, it makes the bubble longer and/or wider even if there is only 1 member, let alone 2+ members. Also, partly because a pin is about the "address", logically that pin might have been associated with so many people throughout time so I'm not sure having the name with the address makes sense.

7b. I understand that it's probably necessary to disconnect the member name from the address when multiple members have the same address. A hotel, for example. In such a case, we would include the hotel name, presumably.
1. Do we have -- or will we need -- a way to shorten long names?

I think truncating would be better – since the user will see the full name appear in the pane upon selection.

2. Members with multiple addresses:  I see that we show all the addresses simultaneously -- this is good.  I think we might not need the 1/4, 2/4, etc.  You refer to a member's "first address," but the addresses in the database do not have any real order.  We haven't matched addresses to dates of residency, although most most addresses do happen to correlate to dates of residency, i.e. when a member only has one address or when a member has a short membership.

Just to make sure we are on the same page and to clarify, we show all the addresses of one person simultaneously. This is helpful and what I wasn't sure about, I think instead of 1/3, 2/3, 3/3 it can be 1, 2, 3 for those who have multiple addresses. The numbering is helpful and needed because all of the addresses may not be in the view of the user (i.e. they might need to zoom out to see some of that person's addresses (green/active pins)).

3. Number of addresses shown: is it possible to display a map with all the addresses in the database?  Is there a limit to how many addresses can be shown?  If so, what is it, and what addresses are shown if the limit is reached? I suspect some filters will result in 500 addresses or 800.

I am imagining all the addresses of the database are shown on the map by default, I defer to @rlskoeser on this.
(to be more specific: I am imagining all the addresses of the database are shown on the map by default visually through the pins and the members' names, where the address shows up upon selecting the pin.)

4. A potential problem: we know that a member had a given address, but we do not know when that member lived at that address -- that is, we do not know the member's dates of residency. So I can imagine filtering for members from 1936 and displaying addresses that were no longer active in 1936.  I worry that the map will imply that an address is active in the specified year.  Should we disallow filtering by membership year for the map view?  Should we show the member years in the address bubble? Another way of putting this problem: there is an symmetry between the list view and the map view: on the list view, all the members were active in the specified year, but in the map view all the member addresses might not have been active in the specified year.

Thanks for pointing this out. I see what you mean with the confusion.
I don't think the membership year filter is meaningful here – it is not adding anything new that is not already covered on the list view. Showing the membership years on the pane is still helpful. @rlskoeser @thatbudakguy I vote for removing this filter on the map view.

5. It might be helpful/useful to see how the maps look when the street names can be read.  (I.e. with zoom.) How do the address bubbles fit with the map in detail?

I imagine and recommend the size and the address inside the bubble to not change based on zoom variations, the pin would be always on the address. I'm not sure how practical it is for me mock this up since I imagine there may be many logical variables implementation-wise.

6. I realize this is out of scope, but I'll mention it here: it would be FASCINATING to be able to select a member and then show all the other members who borrowed the same books.  It would also be fascinating to be able to select a book and show the addresses of all the members who borrowed it, and to have some kind of "chronological circuit" to connect them: to trace, that is, the geographic circulation of a book.  I'm trying to think about the intellectual stakes of the map. I've always been interested in the relation between proximity and taste.

@jkotin thanks for writing. I agree that it's out of scope. It would be very fascinating! I imagine that will need to be at least one new filter.

a few notes on @jkotin's comments before I take a look at the designs in detail; will try to use same numbering:

We talked about having arrondissement demarcations only appear when the filter is used; I think this is feasible.
It's fairly trivial to ensure that the arrondissement polygons do not overlap markers and popups; this concept of "layering" and depth is well-represented in the map software.
We have an auto-generated "short name" for members that is currently used in the breadcrumbs, but this information isn't indexed for searching (though it could be).
In terms of feasibility, the map should have no problem displaying thousands of markers simultaneously. Only one popup will be visible at a time.
This might be a serious complication; I'm glad @jkotin brought it up. I'm not sure offhand what the most predictable way to handle it is, since if the user already had a date range filter active, we need to decide what to do with that:

make the date filter (and its active filter listing) disappear entirely, or just make them appear inactive/disabled?
"remember" the user's selected date range so it is set when they return to the list view, or clear it out when they switch to the map view?
Some of these possibilities seem like they could introduce a lot more complexity.

You can already see this on member detail page maps - the search map should look more or less the same.

Thanks everyone for all the careful thinking about this map feature! We need to be careful of complications and additional features, or we won't be able to complete it this week.
I still have some questions about how leaflet will handle multiple pins at the same exact location and whether they need to be combined (i.e., can we have multiple pins for multiple different members at the same hotel or does it need to be a single pin?). I'm hoping that a prototype map will answer those questions and help us decide some things. (In terms of functionality, I think it would be really powerful to have one pin for a hotel and be able to click on it to see everyone that we know used that address; but I'm not sure if that's the best approach in terms of implementation.)
I think that some of the functionality of the map that we've discussed should be considered separate features, and we are unlikely to get to all of them. (Some of them are my ideas! Sorry). I propose postponing these (we can write user stories to capture the ideas). Any dealbreakers for anyone if we omit these for now?

showing the lines for selected arrondissements
highlighting other addresses associated with the current member

@gissoo on the design I see you went with '### total addresses' — what do you think of showing both the number of members and the number of addresses included in the result?
@jkotin I understand your concern about the membership dates vs address dates, but we need to keep this feature simple so we can complete it this week. It also seems like filtering the addresses by membership date would be a powerful way to use the map. Could this be addressed with any wording changes (maybe the text that indicates the number of addresses? does "known addresses" help any?) and/or a new FAQ entry?

@rlskoeser I really worry about the membership date issue. An overarching Project policy has been not to introduce new errors into the data.  Consider this scenario: a user delimits to members from 1938 and Hemingway's address in 1925 appears, yet we know that that address is not valid for 1938. This scenario would undermine the Project.
Is there a way to avoid it?  Practically, we will never be able to match addresses to membership dates accurately. We ran into this problem way back when we were working on Jesse's right bank map.

Looking at the designs, I have some more questions about differences between this and the member detail map. In my memory, we were trying to have the two maps align as much as possible, but it seems like there's still a lot of divergence. There are a few minor differences and one major one:

The pins are now black, with a noticeable outline, and appear to be green when selected. This is minor, but we would need to change the member detail map to match.
The popups have rounded corners. Again, minor, but we should pick one style for both the member detail and member search maps.
The popups use our heading font instead of our body text font. This gives us less space to work with inside the popup and (imo) is slightly harder to read.

The most striking difference is that the pins all have popups active simultaneously. I think this  detracts from the readability of the map, since when the map loads there will be a huge number of them overlapping. Also, it's not clear that the user then needs to click the pin (or popup? what part is interactive?) again to get more information, since it appears to already be active.

@jkotin imo no new errors are being introduced. we just need to be clear that the search affects members, not addresses - it is not inaccurate to show hemingway's 1925 address if we limit to members from 1938, because hemingway was a member at that time and we need to show all his addresses. the address may be invalid for that year, but the membership is not, and the filter is called "membership years".

Thank you @thatbudakguy -- I see your point, but this still seems like a significant problem for me. Users will, I think, assume that the map implies contemporaneity — that by delimiting to 1938, they are seeing addresses from 1938.
But this connects to a larger issue that I've been thinking a lot about. How might the map be important and/or useful?  What are the user stories for going to the map?  I actually started to make a list of user stories, but they became too long and unfocused.
Should we discuss this at our meeting tomorrow?

@jkotin would it help if we display the dates for the address if known and explicitly indicate dates are not known otherwise?
Seems like the only other simple solution is to disable the membership years filter — but it seems like that takes away a lot of the power of this page.

Thanks everyone for all the careful thinking about this map feature! We need to be careful of complications and additional features, or we won't be able to complete it this week.
I still have some questions about how leaflet will handle multiple pins at the same exact location and whether they need to be combined (i.e., can we have multiple pins for multiple different members at the same hotel or does it need to be a single pin?). I'm hoping that a prototype map will answer those questions and help us decide some things. (In terms of functionality, I think it would be really powerful to have one pin for a hotel and be able to click on it to see everyone that we know used that address; but I'm not sure if that's the best approach in terms of implementation.)

I'm having a hard time imagining how users would read and navigate multiple pins at the same location.

I think that some of the functionality of the map that we've discussed should be considered separate features, and we are unlikely to get to all of them. (Some of them are my ideas! Sorry). I propose postponing these (we can write user stories to capture the ideas). Any dealbreakers for anyone if we omit these for now?
* showing the lines for selected arrondissements

I agree with this one.

* highlighting other addresses associated with the current member

I don't understand what it would be like without this (just show one address for the member? If yes, how do we pick that one address/based on what logic?)

@gissoo on the design I see you went with '### total addresses' — what do you think of showing both the number of members and the number of addresses included in the result?

So you mean make it like this for instance?:

"1 total address and 2 total members"?
Or
"1 total address
2 total members"?

@rlskoeser @thatbudakguy Even though I understand your logic, I don't think it makes sense for usability. Is there any easy way to make the membership years not usable on this tab? I think it also totally makes sense to not "remember the user's selected date range so it is set when they return to the list view, or clear it out when they switch to the map view" as Nick was asking about earlier.
I just don't know what it really adds here with the map, that aspect of the information can be found and learned on the "list view".
If we do keep it I think we need to be explicit that it's not really just about the "address", right now the language I was going for was "total addresses" .."members with addresses" ...
@rlskoeser regarding your last comment I agree that it will take a lot of the power of this page, in an unnecessary way.

would it help if we display the dates for the address if known and explicitly indicate dates are not known otherwise?

@rlskoeser Would you say more about how this might work? I worry that the datawork/research required would be overwhelming.  I also worry about having uncertaintyicons or the like for addresses, and that causing confusion.

As a general note, Cliff, Jesse, and I really struggled thinking about the value of seeing all the addresses at once, not connected by single date. (When the Project started, we had a fantasy of having a "slider" on the map showing how the S&Co community changed for the its twenty-year existence.) We focused on the Right Bank map because the dates didn't really matter: it was interesting to see that members lived in a part of the city we didn't associate with the lost generation.  Maybe if we came up with user stories for the map, our priorities would come into focus? For a second I thought: what if I worked on dating the addresses of members with multiple addresses?  There must be relatively few. But I'm not sure that we can presume that members with single addresses had those addresses throughout their memberships.
I'm eager for help thinking my way out of this corner.

Looking at the designs, I have some more questions about differences between this and the member detail map. In my memory, we were trying to have the two maps align as much as possible, but it seems like there's still a lot of divergence. There are a few minor differences and one major one:
1. The pins are now black, with a noticeable outline, and appear to be green when selected. This is minor, but we would need to change the member detail map to match.

Thanks for writing @thatbudakguy I had some notes on this above, I think for the purposes of this page it is okay if the pins are different. The pin on the biography page is not interactive, logically to me it is "selected" in the sense that it is showing up on the biography page it belongs to, so it makes sense for it to be green. Style-wise it would be better if it's like the green icon on the map view, but it really doesn't have to be. On the map view, there are many pins and the pin needs to be more visible than it is on the biography page.

2. The popups have rounded corners. Again, minor, but we should pick one style for both the member detail and member search maps.

Sorry I missed this! I agree, they should match the one on the biography page, that is totally fine!

3. The popups use our heading font instead of our body text font. This gives us less space to work with inside the popup and (imo) is slightly harder to read.

I agree, let's just match it with the biography page, I tested 14px first (which is what appears to be on the site) and it appeared too small in Sketch, but it looks better on the site. Also, the font is different, because on this page the members' names always appear in Louize, so it's slightly odd if they are in two different fonts on the same page. I think it's fine if the font on the map here completely matches with the font on the map on the biography page (Univers).
However, I'm not sure if the grey font color is visible enough for this page, I would recommend we change the font color to black for this page.

The most striking difference is that the pins all have popups active simultaneously. I think this detracts from the readability of the map, since when the map loads there will be a huge number of them overlapping. Also, it's not clear that the user then needs to click the pin (or popup? what part is interactive?) again to get more information, since it appears to already be active.

So we had discussed this and I think @rlskoeser and I were both thinking it would be helpful to have member names always shown (it would be the default), I still think it actually helps to see members' names and they would be readable when zoomed in. I don't see much of user engagement if the user has to select 1 pin at a time to see a member's name, it's a lot of effort, making it less engaging and easy to use.
So the idea right now is the pins always show members' names (at least 1 member's name for 1 pin), the pin is black, when the user selects the black pin the address associated with the pin appears on the bubble and the container on the left/bottom about the member(s) appear(s). I think it's clear usability-wise.

Another way I can think about it is that the pins are black and don't show any information from the beginning, which is less ideal usability-wise, and once a pin is selected its associated address shows in a bubble along with the member's info on the container on the left/bottom. But I'm not confident about this scenario at all. I think there is a value in showing member names especially since there is no more list on the left (as a way to give a meaningful big picture).

@jkotin in my mind, the primary use case for the map is investigating geographic communities of readership. being able to narrow down a search to just members who borrowed Ulysses and then immediately see the geographic distribution of where they lived is a powerful tool. controlling the map display by refining a subset of members is what gives it this power.
do we have FAQ content about the addresses? perhaps we could write an FAQ entry and link to it from this page (and potentially the member detail page, on its map).

@thatbudakguy Awesome -- exactly right. I think I was being obtuse: I didn't understand that the current conception of the map would allow users to delimit members who borrowed a specific book. That is indeed powerful.  I still don't follow how member dates are necessary, although I do understand how including member dates would make implementation more straightforward by maintaining the symmetry with member searches.
There isn't an FAQ about addresses yet.  I will write one when I have a better sense of the map.

@jkotin sorry - I should have been clearer. We can't do that yet - I was referring to the book filters on the member search, which are not MVP. We can currently support queries of the form "Where did all the Americans live" or "Where did people born between 1883 and 1900 live" (i.e. the Lost Generation).

@thatbudakguy Are you saying we can do this in the map view? Or that this is how you imagine the map to be most useful? Because there are no filters to allow for it, and the keyword search is just for member names.

@thatbudakguy ahhh thanks :D

Right!  I understand. I agree that the demographic searches are useful, although our data about age and nationality is quite limited.  Still U.S. v. French will be very cool.
I'm still hung up on the membership dates filter. I can't see how it would work without causing confusion, even false beliefs. Yet I agree that it would, in ideal circumstances, be powerful.
The book filter is ultimately what will make the map an amazing tool.

responding to @gissoo's comments:

I think it's fine that they are different. I think it's still worth making the ones on the map view black to start with and green when selected. The number of pins on this page is a lot more and visibility becomes an issue.

I like the increased contrast between the black & green versions (and the outline helps with visibility too). Could we just use that on the member detail map as well, so it's consistent?

So we had discussed this and I think @rlskoeser and I were both thinking it would be helpful to have member names always shown (it would be the default), I still think it actually helps to see members' names and they would be readable when zoomed in. I don't see much of user engagement if the user has to select 1 pin at a time to see a member's name, it's a lot of effort, making it less engaging and easy to use.

I'm willing to at least try this and see if it's legible. There might be some leaflet plugins or options to try to move around the popups so that they don't all overlap so much, or we could explore rendering the names in a different way (non-popup labels of some kind?)

More short-term actions that will be taken regarding this issue:

RSK to query people with multiple addresses
Josh to see how feasible to get dates from these

More context:
From the conversations we had on this feature we agreed to hold off on it because the addresses on the map do not align with the active membership years filter, i.e., if the membership year is set to 1920-1921, all of member x's addresses will be shown beyond the filtered year range, implying as if a user lived in 4 addresses at the same time. Josh expressed "I want to make clear that we’re not showing a contemporary relation but a kaleidoscope relation over time".
This is confusing and problematic mainly for members who have multiple addresses. There are complexities to properly solve this problem that are not immediately feasible at this point, data-wise and implementation-wise. Possible solutions discussed were:

adding a disclaimer text below the membership filter so users will be aware. (Josh didn't find this valuable) – simplest for a tight timeline.
relying on a Source essay to help (Josh doesn’t want to send users to a long essay, but if the filter is greyed out and there’s a question mark that sends them to essay)
making the membership filter inactive and unusable for the map view, while preserving the year range that the user had chosen when in the list view so that when they switch back to the list view their search is "remembered"/preserved. I disagreed with the logic here and don't think it's necessary to preserve the filter here since it's inactive in the map view tab.
removing the membership years filter entirely from the map view.
fixing the data so that only addresses that match the selected membership year filter would be shown.

Some agreements we reached for when we resume with this feature in the future:

Not to display polygons on the map that show the area of the clustered addresses.
Change color of the member address clusters to all be one color, the same color as the default pin (#2e2e2e) with white font displaying the number of the addresses in the cluster – Gissoo will decide on their sizes/any other visual characteristics (like the size mentioned, still unsure and need to assess).
To see members' names when you zoom in/Tool tips to display on a certain zoom level (Gissoo agrees)
On the pin, by default, display member's name and when you click on the pin, displays address
Write “Search members with known addresses” in the search box

Some actions for when we resume with this feature:

highest priority is the member name on the map
Lower threshold so more pins display
Make image of the pin smaller
Show member's name above the pin anytime the pin would be shown instead of cluster
Make member's name as small as possible to still be legible (probably can't be smaller than 14px)
Select the pin for the address to appear in the bubble
Down the line: toggles between member name and address, and member name has membership date


Fine tuning?

Hi,
Thank you for the amazing model!
I was wondering if there is any guidance for how to fine-tuning the model? I would like to finetune the model with my human data in both atac- and rna- sequencing.  and if you have any advices if I have control vs disease data - shall I fine tuning on control and disease separately?
Thank you!

Any updates on fine-tuning code?

We'll submit a methods description to bioRxiv and release code for this shortly. The pull request is here https://github.com/calico/baskerville/pull/40, but we're still cleaning and testing.


Fix issue with multiple content presenters.

TeachingTip's template had multiple content presenters, one for each of Content, BleedingContent and Icon. This was causing issues because ContentPresenter has some magic in it to automatically set its content property (but only when it's content property is null during the loaded event) to its nearest ContentControl ancestor's content property.  This means when they teaching tip had content but no bleeding content or no IconSource the content presenters were attempting to show the content UI in multiple locations, resulting in a crash due to multiply parented UI.  The fix is to replace these content presenters with border elements.

In order to create cleaner PRs in the future, consider rebasing your changes onto master so that the PR only contains the commits that have not yet been merged to master. Not a huge deal, it just makes the PRs easier to read.


refactor!: Move crypto operations into a trait.

This is a reroll of #103, which has become quite inconvenient to merge.
As a practical difference, the functions that used to be moved into a CryptoExt trait now just take a crypto first argument -- not much of an ergonomics setback, but easier to understand code.

There are still quite a few instances of default_crypto() around that eventually should be relegated to tests and example only. The most prominent leftovers are in lib/src/lib.rs that is not generic yet -- but that is probably easier to do once the C API is in the freezer.

Ready from my PoV -- please review. This would then be a sensible base for the big typestating bout.

Just to note, I am having trouble with installing and running [hax] on my computer, to run against this PR. I am on it, but the build takes time (and fails after a lot o fime).  Once I solve that and the fstar generation works, I would be happy to merge this PR.

I was finally able to install and run hax in my mac -- and these changes do not affect hax into fstar.
There are still some errors but they were already present at the previous implementation, i.e., the only complaints are due to the recursive order of some elements in the consts crate. I leave the full output below for reference.
Details

cargo-hax -C -p edhoc-rs -p edhoc-consts --no-default-features --features="crypto-hacspec, ead-none" --release \; into -i '-c_wrapper::** -edhoc_rs::generate_connection_identifier_cbor -edhoc_rs::generate_connection_identifier' fstar

   Compiling edhoc-consts v0.1.0 (/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts)
warning: unused import: `super::structs::*`
   --> consts/src/lib.rs:225:9
    |
225 |     use super::structs::*;
    |         ^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_imports)]` on by default

thread 'rustc' panicked at 'attempted to read from stolen value: rustc_middle::thir::Thir', cli/driver/src/exporter.rs:142:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: The THIR body of item DefId(0:57 ~ edhoc_consts[76f7]::structs::BytesSuites::{constant#0}) was stolen.
       This is not supposed to happen.
       This is a bug in Hax's frontend.
       This is discussed in issue https://github.com/hacspec/hacspec-v2/issues/27.
       Please comment this issue if you see this error message!
  --> consts/src/lib.rs:69:33
   |
69 |     pub type BytesSuites = [u8; SUITES_LEN];
   |                                 ^^^^^^^^^^

thread 'rustc' panicked at 'attempted to read from stolen value: rustc_middle::thir::Thir', cli/driver/src/exporter.rs:142:22
error: The THIR body of item DefId(0:59 ~ edhoc_consts[76f7]::structs::BytesSupportedSuites::{constant#0}) was stolen.
       This is not supposed to happen.
       This is a bug in Hax's frontend.
       This is discussed in issue https://github.com/hacspec/hacspec-v2/issues/27.
       Please comment this issue if you see this error message!
  --> consts/src/lib.rs:70:42
   |
70 |     pub type BytesSupportedSuites = [u8; SUPPORTED_SUITES_LEN];
   |                                          ^^^^^^^^^^^^^^^^^^^^

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.fst"

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.Cbor.fst"

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.Common_edhoc_parsing.fst"

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.Consts.fst"

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.Helpers.fst"

note: Writing file "/Users/geovane/Developer/inria/dev/edhoc-rs-FORK/consts/proofs/fstar/extraction/Edhoc_consts.Structs.fst"

warning: `edhoc-consts` (lib) generated 1 warning
error: could not compile `edhoc-consts` (lib) due to 2 previous errors; 1 warning emitted

@malishav I am ok with merging this. Do you wish to provide any input?


dhcpcd-9.4.0: Fix infinite DHCP INFORM messages

When an address is configured on the interface, do not send a DHCP
INFORM message if the interface is already bound (ack already received)
The second issue is that dhcp_inform resets the lease information, and
may drop the existing server address.
#47

Thanks for this patch. This helps with a mesh setup of APs. I often have "reconnects", which puts me offline for some time - quite annoying. Dunno what it internally does?! Maybe AP transition.. And with this patch, I no longer have these down times.
Just a heads up for usefulness of this patch. :)


Couldn't find Materialize object on window

I've installed angular2-materialize as per the read me, but I'm getting an error regarding the Materialize object.
Couldn't find Materialize object on window. It is created by the materialize-css library. Please import materialize-css before importing angular2-materialize.
Anyone run into this before?

The materialize js file is missing.
In your index.html:
<script type="text/javascript" src="vendor/materialize-css/dist/js/materialize.min.js"></script>

@numerick thanks heaps for picking this one up. I'll close this issue now.
If any of you two think the documentation is lacking I'd love for a PR to fix what's missing. Cheers.

Well, in may case, I close Atom IDE and restart the server (ng serve) again and working to me, I do not know why....

GET http://localhost:4200/node_modules/materialize-css/dist/css/materialize.css
localhost/:12 GET http://localhost:4200/node_modules/jquery/dist/jquery.js
localhost/:13 GET http://localhost:4200/node_modules/hammerjs/hammer.js
localhost/:14 GET http://localhost:4200/node_modules/materialize-css/dist/js/materialize.js
index.js:4 Uncaught Error: Couldn't find Materialize object on window. It is created by the materialize-css library. Please import materialize-css before importing angular2-materialize.
at Object.../../../../angular2-materialize/dist/index.js (index.js:4)
at webpack_require (bootstrap 0890751…:54)
at Object.../../../../../src/app/app.module.ts (app.component.ts:8)
at webpack_require (bootstrap 0890751…:54)
at Object.../../../../../src/main.ts (environment.ts:8)
at webpack_require (bootstrap 0890751…:54)
at Object.2 (main.ts:11)
at webpack_require (bootstrap 0890751…:54)
at webpackJsonpCallback (bootstrap 0890751…:25)
at main.bundle.js:1
any one resolve the issue?

restart the web server

Estoy instalando materialize y me da este error
Uncaught Error: Couldn't find Materialize object on window. It is created by the materialize-css library. Please import materialize-css before importing angular2-materialize.
at eval (webpack-internal:///./node_modules/angular2-materialize/dist/index.js:10)

Este es mi angular cli
"styles": [
"../node_modules/materialize-css/dist/css/materialize.css",
"../node_modules/materialize-css/dist/css/materialize.min.css",
"styles.css"
],
"scripts": [
"../node_modules/jquery/dist/jquery.js",
"../node_modules/hammerjs/hammer.js",
"../node_modules/materialize-css/dist/js/materialize.js",
"../node_modules/materialize-css/dist/js/materialize.min.js"

TRY IT
        "styles": [
          "src/styles.css",
          "./node_modules/materialize-css/dist/css/materialize.css"
        ],
        "scripts": [
          "./node_modules/jquery/dist/jquery.js",
          "./node_modules/hammerjs/hammer.js",
          "./node_modules/materialize-css/dist/js/materialize.js"
        ]

warning for relative route...
and in your angular.json file ... put it in "build" zone...   its possible get a mistake put in "test" zone.

TRY IT
In app.module.css: Remove the MaterializeModule in Imports. Remove import { MaterializeModule } from 'angular2-materialize';

Hello thanks
I fix

i used materialize-css v0.100.2 and worked fine

TRY IT
In app.module.css: Remove the MaterializeModule in Imports. Remove import { MaterializeModule } from 'angular2-materialize';

Wolud you mind to tell why? Because angular2-materialize wizard tells to put it.....


Synvert

(You should enable discussions).
At RubyKaigi 2023 there was this talk: https://rubykaigi.org/2023/presentations/flyerhzm.html#day3
I was really impressed with what he developed.
I wonder if there is some overlap. I often find myself having to rewrite code across a large system or set of systems, and RuboCop is a bit too specific.

(Did not know about discussions, created here)
Will give that a look a bit later tonight.

From a glance it has a lot of the issues I had with NodePattern and Prism in that it introduces its own syntax and tends to be more verbose. I don't think I have a solution for this yet, mind, but there's something there and I'll have to give it more thought.

Once you've enabled discussions, you can move this issue to a discussion.


Data Export Creating Empty File

Summary of problem or feature request
I am using the Datatables Service implementation. When I try to perform an export of the data using either csv, excel, or pdf, the file is created with no data, headers, etc... I is just an empty file. I was originally using the non-service implemenation but ran into issues with data export displaying json to screen so I just switched to this method. I apologize for the lengthy post, I just want to make sure you have everything you might need to be able to assist me in this issue.
The way I am intending this to work is:
User clicks the reports link which loads the index view. From here they have a custom date filter and report selection drop down. Based on their input, the appropriate report is ran and results displayed in the datatable located on the same page. So far, everything except the data export works.
Code snippet of problem
ReportsDataTable.php
public function ajax()
{
    return $this->datatables
                      ->collection($this->query())
                      ->make(true);
}

public function query()
{
    $response = "";

    switch( $this->type )
    {
        case 1:
            $response = $this->sales($this->start, $this->end);
            break;
        case 2:
            $response = $this->commission($this->start, $this->end);
            break;
        case 3:
            $response = $this->cog($this->start, $this->end);
            break;
        case 4:
            $response = $this->shipping($this->start, $this->end);
            break;
    }

    return $response;
}

public function html()
{
     return $this->builder()
                       ->columns($this->getColumnNames())
                       ->ajax('')
                       ->parameters($this->getBuilderParameters());
}

protected function getBuilderParameters()
{
    return [
        'order'   => [[0, 'asc']],
        'buttons' => [
            'csv',
            'excel',
            'pdf',
        ],
    ];
}

protected function getColumnNames()
{
    return $this->columns;
}

private function commission($start, $end)
{
    $dataArray = new Collection;

    $data = 'QUERY';

    $dataArray->push([
        'public_name' => $data->public_name,
        'comm_total' => money_format('%.2n', $data->comm_total)
    ]);

    $this->columns = [ 'public_name', 'comm_total' ];

    return $dataArray;
}

Javascript
$('#reports-table').DataTable({
    dom:            'frtBp',
    paging:         true,
    pagingType:     'simple_numbers',
    lengthMenu: [ [ 15, 30, 50, -1 ], [ 15, 30, 50, "All" ] ],
    processing:     true,
    serverSide:     true,
    destroy:        true,
    buttons:
    [
        'excel',
        'csv',
        'pdf',
    ],
    ajax: {
        url: '{!! route( 'reports::getreport' ) !!}',
        data: function(d) {
            d.fromDate = start;
            d.toDate = end;
            d.report_type = 2;
        }
    },
    columns: [
        { data: 'public_name', name: 'public_name', title: 'Name', sortable: true },
        { data: 'comm_total', name: 'comm_total', title: 'Commission', sortable: true },
     ],
});

ReportsController.php
public function index()
{
    return view('reports.index');
}

public function getReport(ReportsDataTable $dataTable)
{
    $report_type = Input::get('report_type');
    $start = Carbon::now()->subMonth();
    $end = Carbon::today();

    return $dataTable->setSelection($report_type, $start, $end)->render('reports.index');
}

Routes
Route::group( [ 'as' => 'reports::', 'prefix' => 'reports', 'namespace' => 'Reports' ], function() {
    Route::get( 'index', [ 'as' => 'index', 'uses' => 'ReportsController@index' ] );
    Route::get( 'getreport', [ 'as' => 'getreport', 'uses' => 'ReportsController@getReport' ] );
});

System details

Operating System: Windows 10 Professional (Workstation) / Ubuntu Server 14.04 (Server)
PHP Version: 5.5.9-1
Laravel Version: 5.2
Laravel-Datatables Version: 6.10.1

Does your table renders correctly? Exporting process is almost the same with rendering the default ajax response. So basically, ff the table in service renders properly, exporting should work as expected.

My table renders as expected. All the data is present, but for some reason when I attempt to export I get nothing. I'm not getting table headers or data, just an empty excel or csv.

I was able to get it working with the csv option. I will test the other options now. What I had to do to get it to work was to add columns array to my setSelection() and pass the columns for the desired query. Then set $this->columns in setSelection instead of my query function.


Create Transform operation

Create a new Filter operation that takes an iterable of elements and an ElementTransform. The handler should just apply the transformations to the elements.

Would it be wise to potentially combine this with #1291 ? The functionality will be quite similar, insomuch that it's applying a predicate and returning a filtered iterable of elements.
I can of course simply make the Stream implementations in #1291 more general, and just have the operation & handler interact with these.

Merged into develop.

Please note, this operation will note be available be default until this bug is fixed: https://github.com/gchq/Gaffer/issues/1341


remove vendor dir

https://github.com/open-cluster-management/backlog/issues/16033

/test images

/lgtm


Release 2.17.1 to pypi

Forgot to approve the release pipeline, the release will be available as soon as this run is completed.


Revert "tests: disable nfs-ganesha testing"

This reverts commit 7348e9a253518904724b05565c97fa1f35c47006.
Since the nfs-ganesha rpm build for CentOS 8 has been fixed.
Signed-off-by: Dimitri Savineau<EMAIL_ADDRESS>

jenkins test centos-non_container-all_daemons

jenkins test centos-non_container-all_daemons

Need to rebuild the ceph container image since the latest shaman build fixes the nfs-ganesha segfault and then enable back nfs testing for container scenario too

jenkins test centos-non_container-all_daemons

jenkins test centos-container-all_daemons


feat: Add and edit github connection

Notion: https://www.notion.so/rilldata/RD-RC-1-3-Project-Status-Page-updates-dd5daf216f5a4c05886b98bc20d4f8f5

Some initial UXQA –

Editing the GitHub repo is buggy. The GitHub repo rendered in ProjectGitHubConnection.svelte never updates. And the listed resources appear to be linked to the previous (t-1) GitHub repo, not the current (t) GitHub repo. I'll send a Jam via Slack.
The dropdown should be initialized with the current GitHub repository (in this case, rill-examples)

@ericokuma, it looks like we need to add a field to configure the subpath. FWIW, here's how Vercel handles selecting a "root directory":

Writing down what we discussed live:

The motivation behind the GitHubConnection classes is to track the state of the connect-to-GitHub flow (which happens in a new tab). We want to be smart about when we refetch GetGitHubUserStatus and ListGitHubUserRepos, each of which can take a couple seconds. The refetches should happen after the connect-to-GitHub flow on page re-focus. However, these GitHubConnection classes are hard to read.
We should know why updating the GitHub repo leads to a page flash. We figured out it's the result of a GetProject request that omits cookies & returns a 401 error. But why does the request not include cookies?

Approving from backend POV

FYI, @jkhwu updated the designs to remove a couple cases of indentation. E.g., see these new mocks:

UXQA –

After the "Choose another repo" flow, I see this page that references the CLI (cc @ericokuma):

I created a blank repo, then I hit a 404 when I selected it and clicked "continue" in the UI:


⚠ Bofrost.fr has degraded performance

In d9716e4, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1058 ms

Resolved: Bofrost.fr performance has improved in 859728e after 7 minutes.


Publisher: In create mode hide selection of Subsets

Is your feature request related to a problem? Please describe.
When on the Create Page you still see the active selection in Subsets to publish on the right

However, that makes it somewhat feel like that right hand side has something to do with the values I'm seeing to the left of it. But they aren't. I almost think that right hand side subsets to publish should be deactivated completely and just be visual reference of what you already have.
(The same goes for the + button on the right hand side underneath those Subset to Publish - it doesn't do anything in the Create page)

Also, selecting no asset/task on the left hand side still allows you to create an instance - which seems to be a bit confusing too.
Describe the solution you'd like
The create page to me still confuses me most of the time. So anything that tries to avoid clutter and confusion on the page will help.
Describe alternatives you've considered
It might be even worth deciding to NOT show the subset to publish at all. It's nice seeing what's already there currently but I feel like in the current state it's more confusing and clutter than what it adds to the end user.
[cuID:OP-4745]

Accidentally marked as resolved in PR that fixed different issue

Here are my perspective on this. I agree with @BigRoy that there are some confusing point. For me it is:

The Create >> button as it is almost hidden and very small and it doesn't feel like next step to something. Also it would be good to make the button in deactivated mode in case something is missing in the family requirements.
Create tab doesn't need to have publishing comment and oher buttons, since those are more publishing related feaures. But Reload button is ofcourse related to Create so it could stay there.
List of instances at Create, I understand why it is selectable - as user can multi/single select them and remove.
Yes the plus sign at instance list at right side, is not realy any particular importance at Create tab. I would remove it completely. To make transition button similar as to go from Create to Publish with > right button we could create the same at left in Publish tab for going back to Creator with < button.
There is the burger menu button which is not actually menu but display mode switch. It could be confusing for lot users. I would rather want to see diplay mode button on top of the list and action buttons at bottom - so for me Bin icon on bottom only.
List of instances Options in Create tab, seems to be shown unnecessarily.


Intersection of Two Arrays

Given two arrays, return their intersection (i.e., the elements that appear in both arrays).

Hello, could you assign this to me?

Hello, could you assign this to me?

@byhlel Sure, it's already assigned to you. Please go ahead!


fix: voiceover issues for UiMultipleChoices component

Related issue
Closes #218
Scope of work

Fixes only issue on chromium-based browsers. Still, there is an issue with firefox.

Recording
https://github.com/infermedica/component-library/assets/17556031/8b132453-fc5a-454a-a193-4b37c0d7f36b

@pspaczek I found a possible way to fix it on Firefox too.
We would have to move input outside the label in UiRadio.
From:
<input type="radio> ...

To:

<input type="radio> ...

WDYT?

Without changes from this PR? Because now you change ul to div but li still be li ;)

@pspaczek I found a possible way to fix it on Firefox too. We would have to move input outside the label in UiRadio.
From:
<input type="radio> ...

To:

<input type="radio> ...

WDYT?

It should be changed in UiCheckbox and UiRadio, I think :)

@pspaczek I only changed role from tag. I'd leave it as it is, changing the markup of radios and checkboxes is a bit more risky in terms of plans for the triage release.


Example app fails with 1,000,000 items

It may be borderline abuse, but I tried the example at http://developerdizzle.github.io/react-virtual-list/ with a million items, and it fails to render when I drag the scrollbar to the bottom. Know what would cause the failure?
We have a requirement to virtually scroll millions of items, so I could potentially help to write an improvement.
Latest Chrome on OSX.

On Safari it also freaks out..

Could it be that the empty container is simply too large? Would it help if the height were capped, and the vertical scrolling were to map logarithmically to the index position?

Hmm, great question.  It may have to do with browsers' maximum height limitation.  I'll run some tests when I get a chance, but I suspect there will be a point where the page is just too high.  Logarithmic mapping is an interesting proposal though.

Running a few tests, it's very much a limitation of either the height or the padding. Most likely, something getting converted into a floating point or simply capping out.  I'll be experimenting with a maximum height and linear scaled scrolling for now.

I don't have much to say on this as I never render more than 50 rows on a page right now in my application. I use this library because the individual rows are quite expensive to render (50 DOM elements per row with 4-6 responsive images, some @2x res), but I've never tested it academically with a massive amount of rows.

I'm convinced this is a result of each browsers' maximum height limitation.  Closing this, but feel free to re-open if anyone believes otherwise.


Replace Enyo by vue.js

Sugarizer relies on the Enyo JS framework but does not use anything from Enyo that makes it mandatory.
Replacing Enyo by vue.js would clarify and modernize the code base, while attracting more developers.

@llaske I am interested to work on this. Could you please provide me some pointers on where to get started with?

@llaske I would like to work on this as a part of my gsoc proposal. Before replacing enyo with vue in the core platform, Porting some activities first which use enyo would be a starting point I think.
The activities which currently use enyo framework are -

Tank Operation
Foodchain
Abecedarium
Tam Tam Micro
Video Viewer
Last One Loses

I would like a start working on porting a few of these. Which one among these would be a priority?
Requesting suggestions.

@ksraj123 Thanks for this proposal.
BTW I don't see any good reason to migrate these activities:

No benefit for users: the activity will not work better
No benefit for developers: there is no maintenance issue today and dependency to Enyo framework didn't not prevent recent improvements on these activities

So a best way to prepare migration is to invest in Vue.js for new activities. Not to rewrite old activities.
Conversely to Gtk2/Python2 issue in Sugar, using a deprecated Enyo version has no impact on Sugarizer deployment.

Well said.  We're not porting to Python 3 because we want to, but because we have no other way to benefit the users.

@llaske I agree with you. It sounds reasonable. As Enyo is a comparatively old framework there are not as many resources for us (student developers) to learn more about it or refer to if something does not work, as there are for vue. I made some contributions to some of the enyo activities I mentioned recently and faced these problems myself, seeing an open issue on this I thought maybe others are facing this issue as well. But I agree with you on porting will not make the old activities work better and I guess changes to the core platform are not that often to justify porting. So I agree with you on investing in vue for future activities. Thanks.

For information, it's a WIP here https://github.com/llaske/sugarizer/tree/feature/v2


Move event assertions from tests to library

Then they can be used in user application tests

Useful change, thanks.


dbadashconfig.exe closes silently if .net 6 not installed

i was told it would detect .net framework missing and prompt me to install it.  It closes silently when I tried.  v 2.13.3
windows event viewer
Description: A .NET application failed.
Application: DBADashConfig.exe
Path: C:\Users\administrator.MK\Downloads\DBADash_2.13.3\DBADashConfig.exe
Message: It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '6.0.0' was not found.

The following frameworks were found:
2.2.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
3.1.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:

https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x64&rid=win10-x64

The prompt to install the .NET framework is generated from Microsoft code.  It's possible this has some dependencies of its own and might not be able to run in some situations.  What version of Windows are you running?
There might be some things I could consider like packaging the application with an installer to improve the user experience.

Microsoft Windows Server 2016 Standard Evaluation
On Sun, Mar 20, 2022 at 1:51 PM David Wiseman @.***>
wrote:

The prompt to install the .NET framework is generated from Microsoft code.
It's possible this has some dependencies of its own and might not be able
to run in some situations. What version of Windows are you running?
There might be some things I could consider like packaging the application
with an installer to improve the user experience.
—
Reply to this email directly, view it on GitHub
https://github.com/trimble-oss/dba-dash/issues/89#issuecomment-1073346233,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIP4L4RVQBVZYDSKVAVQK6LVA6FVVANCNFSM5RFTJW4A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

I think i was using the wrong exe though.  Note the word service is missing from the filename here.  I tried to open the first exe in the file list with Config in the name.
Later i found dbadashserviceconfig.exe worked ok.  I might have installed .net 6 by that point tho.


[WIP] niworkflows update

Fixes #266

I've tested this on all subjects listed in https://github.com/poldracklab/fmriprep/issues/266#issuecomment-269181677 - most of them show very good results. The only exception is ds109 sub 48 which has very unusual anatomy (almost non-existent ventricles and one-third of the corpus callosum missing).


public membership is needed to update the details of the software

The user should be a public member of the organization in order to change the details of the listed software. That should be mentioned somewhere.

https://github.com/research-software-directory/auth-github/commit/d29d7ae8e3185fef4ec9f484c9c7daf15ec0a2f0

https://help.github.com/articles/publicizing-or-hiding-organization-membership/


pool:Too many objects

I use PooledClient and the value passed to max_pool_size is 16.
33 threads use the same PooledClient object and encountered this problem.
What should I do?

File "/usr/local/lib/python3.6/dist-packages/pymemcache/pool.py", line 71, in get
self.max_size))
RuntimeError: Too many objects, 16 >= 16

https://pymemcache.readthedocs.io/en/latest/apidoc/pymemcache.client.base.html#pymemcache.client.base.PooledClient
Your pool is too small for the amount of concurrency that you have


design CLDR distribution mechanism

I mentioned this in #9. We don't have to create something novel here; other projects have blazed this trail before. Perhaps take a look at jquery globalize and python babel. They are linked on the References wiki page.
I mentioned cargo's [features] sections to allow users to specify which data they need as part of the rust-locale distribution. Maybe they'll specify language tags? That seems like an obvious choice, but maybe there's something nicer, easier, or more specific?
Or maybe we can provide "bite-sized" chunks of CLDR data, and deliver data for multiple locales under one cargo [feature]. Like "europe" would deliver all locales for the European cultures, "america" for north and south america and the Carribean, etc. I actually don't like this idea now that I've mentioned it.
Would we need to have a CLDR crate? How else would we deliver appropriate data?

For $work, what I do is that I create special "messages" like "digits|01234567890", "plus_sign|+", "locale_name|English (USA)" etc. (| is actually "\036"-or-whatever-gettext-uses-as-context-separator), add them in the .pot, translate them from CLDR using a python script and compile them in the .mo. And simply get everything from the messages.
So I think we should eventually have two methods:

bundled, where everything would live in one big, compiled-in, static hash.
in translation, with the tool extracting translatable strings able to add them to the .po files and inject the CLDR translations (the tool itself can be built bundled, so it will have the values handy). For limited devices where the user does not want to bundle it.

That's an interesting approach.

bundled, where everything would live in one big, compiled-in, static hash.

By "everything" do you mean all of CLDR data in one data structure?
python-babel appears to pickle/serialize CLDR data into lots of files. One file for en-US currency names, one for es-MX currencies, same for datetimes, language names, and all the rest. Is this what you meant by your first bullet point? If not, we should add this method to the list.
The script that python-babel uses is called at distribution (installation?) time. It downloads a given CLDR distro, parses the data and pickles it to disk. BTW, their issue tracker has a nice issue about the design and its (lack of) extensibility: python-babel/babel#344

By bundled I meant the way ICU does it. All data, for all supported locales, go in the shared library.

Hm, interesting.
Basically by bundled I mean similar approach to ICU. They just pack everything into one big binary file and potentially link it into the shared library itself.
I have rejected it for $work because the pack is really huge (~29MiB)¹. However, for desktop it shouldn't be a problem and we don't want to include everything they do (especially not the charset conversion tables that take up third of the bundle).

¹ By the way, my /usr/lib/locale/locale-archive with all locales has 114MiB! I am not sure how efficiently packed it is though; probably not much.

Yeah, avoiding a full CLDR install would be helpful.
I think we can leverage cargo's [features] like the examples below, but I'm not super familiar with it, so it might not be suitable. If you can think of a better mechanism for letting users select specific locale data, we should list it here (or the wiki).
cargo install rust-locale --features "en_US vi_VN zh_CN"
or
cargo install rust-locale --features "full-cldr"
etc.
I think that's really sexy (if perhaps tedious if they need lots of individual locales). It's so easy from the user's perspective.
We'd have to deal with cfg attributes to handle the features. That actually doesn't sound fun, since the list of "official" language tags can vary over time. And I don't think we "parameterize" #[cfg(feature = foo)] where foo is whatever was passed on the command line through rustc --cfg feature=.... Yeah I'm pretty sure that's not a thing.

cargo install rust-locale --features "en_US vi_VN zh_CN"

That would be insane; there is well over hundred of those.
I would just have a bundled CLDR (a couple of MiB, in a shared library no problem for desktop or newer mobile) and the keys that the application would inject in its .mo files using provided utility for those applications that are intended to run in severely restricted environments.
Also,

cargo install

Remember, locale is a library. It is installed implicitly by cargo as part of installing some application. User won't get to select the features.

That would be insane;

Well, yeah. :smiley: But imagine I'm a dev at Foo, Inc. and our main product, FooForYou, only supports American English, Vietnamese, and Mandarin. Then selecting "features" like that would be reasonable since those three are all I care about. As FooForYou supports more and more locales, adding each individual tag becomes unreasonable, and you'd want to just say "give me everything CLDR supports" or something more convenient.

Remember, locale is a library.

You're right, the CLI command is wrong. I should have written the example below. The consumers of rust-locale would select the "features" in their Cargo.toml:
[dependencies.rust-locale]
version = "1.0.0"
default-features = false # do not include the default features, and optionally
                         # cherry-pick individual features
features = ["en_US", "vi_VN"]

Anyway, yes, writing every language tag is silly. More thought here is required. I'm not married to this method of data delivery. I like it as a starting point for discussion, though.

But imagine I'm a dev at Foo, Inc. and our main product, FooForYou, only supports American English, Vietnamese, and Mandarin.

That's what the .mo approach is for. You just request features = [] and ask the rxgettext tool to add the CLDR data to your translation catalogs.

OK, for the full-CLDR-install case, I understand it to be something like this:

User installs rust-locale, indicating (somehow) they want all CLDR data.
CLDR data files are installed so rust-locale can use them.
User constructs a Locale object, foo, and rust-locale does The Right Thing (opening files? mmap-ing files?) so the CLDR data files/data are accessible for locale sensitive services like date formatting.
User constructs message formatter for locale foo to load the user's appropriate message catalogs. rust-locale does The Right Thing to load the catalogs so the user can format localized messages. If user wanted to print a localized message which also includes a date, they'd use a date formatter and the message formatter.

Is that at least approximately right?
To be honest my experience of localized message catalogs is restricted to unsophisticated usage of java properties files. So I'm not even sure about 4, above.
I haven't fully understood the .mo approach you brought up (partly because I'm not familiar with gettext). Can you outline it in a bit more detail? (Did you mean xgettext instead of rxgettext, or is rxgettext the Ruby or hypothetical rust version of xgettext?)

The .mo is very similar to the Java properties. It is simply an external hash.
The specific thing with .mo files is, that the keys are strictly either the original string, or a pair of context and original string. This has two advantages:

it automatically falls back to the primary language (usually English), which makes missing translation bugs less severe and
it makes it easy to track changes as if the original changes, it will simply come up as new key missing translation.

The context is for distinguishing short labels, e.g. "file action" "Open" from "port state" "Open"; the former is a verb and the later is a noun and in most languages that will be different words.
The translation will be done by message translator. Message formatter will be a layer on top of the rest that will tie everything together.
And yes, by rxgettext I mean a rust-specific version of xgettext, the tool to extract the strings that need translation.

Regarding storing the locale data in .mo files, remember, that in GNU LibC, all the locale data are read (even internally) via nl_langinfo, which returns a string (the bytes and byte arrays can be encoded in strings easily and the wide variants are just alternates we don't need). So instead of nl_langinfo we just do a cgettext.
E.g. numeric formatting needs digits, + and - sign, decimal separator, group separator and group sizes. So we get them as
cgettext("numeric/digits", "0123456789")
cgettext("numeric/plus", "+")
cgettext("numeric/minus", "-")
cgettext("numeric/group-separator", ",")
cgettext("numeric/decimal-separator", ".")
cgettext("numeric/grouping", "33")

it is actually rather inefficient, because each .mo file must contain the keys including the contexts. However if you just need some attributes (e.g. no need to store monetary formats if the application does not use them) for only few supported languages, it is much smaller than bundling everything.

Ok, we should start somewhere. For start we need two things:

Something that will take a LanguageTag and finds most suitable definition from a set. I've already defined accessors for the subtags in https://github.com/rust-locale/rust-locale/commit/9bb840770f83a35d4bf12a6f64c765a25478fb29. I also wrapped them in locale in https://github.com/rust-locale/rust-locale/commit/c16fd7de32fdf4552822de4158f8b64139ed0df2, but if the CLDR library is going to be separate, it should only depend on the locale_core, because the locale crate will depend on it and we can't have circular dependencies.
Something that will go through the CLDR definition for each language and from specified nodes will generate simple key-value pairs. Strings should do for start.

The first (and simplest) elements we are going to process are the /numbers/symbols/decimal, /numbers/symbols/group, /numbers/decimalFormats/decimalFormatLength/decimalFormat/pattern[not(@type)] and such. I think XSLT would work. There does not seem to be any in Rust yet, but this is offline and does not have to be in Rust.
Since I don't think cargo has much in a way of support for installing resource files, I think it would be best to generate Rust code with all the tables that we would just include in the upload to crates.io. The phf crate seems like a decent option to me.
@mrhota, would you look at it and perhaps start prototyping some generator? Simple and limited for start; we should have something working first and polish it later.

I'll write a python script to begin with. I will want to move to a pure rust generator later so we don't have extraneous, implicit dependencies on other systems.
Python should be fine for a start.

Great.
I think python would do even forever, since it is just a development dependency. And in this case even for development of locale itself and not the crates that use it, though we will, at least at first, certainly have development python dependencies for them too—I don't intend to rewrite translate toolkit any time soon.

my computer has been out of commission for a while, but it's back now. I have adapted the CLDR fetch+parse scripts from the Python Babel project. They use the Python pickle serialization format, which I'm not happy with. It seems like the serde-pickle plugin is immature at this point.
I'll push soon

Thank you.

Python pickle serialization format, which I'm not happy with.

I am not happy with it either.

The nested maps structure is mostly fine in dynamically typed language like python, but in Rust it would require a recursive type with variants. A flat map would be simpler.

The final format should be possible to include_bytes! or memmap and access it without (much) additional allocation.

I was considering cdb format, but the cdb crate uses the unmaintained mmap crate, which does not work on Windows, and the tinycdb crate requires a C library. Another option would be to use the phf crate, with the disadvantage that it has to be linked in and can't be read from file (it could be read from shared library, but that would still be platform-dependent).
Also we actually don't need one flat layer, but two — first by language tag and second by item. And disadvantage of the cdb format (or mo format, for that matter; they are actually quite similar) is that the keys would have to be repeated for each language.
And maybe we will need more layers in the end anyway. In some places we will need to enumerate available items. E.g. available skeletons for date+time.
Either way we are going to have to shave some yaks. But we can start with something less efficient and switch to something more efficient later.

It seems like the serde-pickle plugin is immature at this point.

And I don't think serde-pickle is going to read the Babel serialized locale data anyway. It would have to read into something like:
enum Node {
    Value(String),
    Dict(Box<HashMap<String, Node>>),
}

and I am not sure it would know, or can be explained, how.

Looking at serde, a good format for use at the moment might be msgpack. It has python implementation and it has rust implementation (the original seems unmaintained) including serde support.

msgpack looks good to me

btw, I'm not dead! I'm experimenting with some different delivery methods. msgpack no longer seems like the right choice. Dumb JSON + (gzip|bzip2|xz) would give us everything we need (right now) for data retrieval flexibility, plus it will produce smaller files.
I should have a PR later this week.

Ok.
If compression gives better results — and it makes sense, the strings are still strings in msgpack — go ahead. Just don't spend too much time perfecting it. We should have some prototype first and can perfect it later.

see here for an "alpha" version: https://github.com/mrhota/cldr-rs
I published as a crate, too: https://crates.io/crates/cldr
The build script clones all CLDR repos, compresses the JSON files using bzip2, and puts them in the output dir, available for the CLDR lib to read. I haven't really started the lib part of the crate.

@mrhota , how is that supposed to be used? As it is it can't be used as a a dependency of locale because:

CLDR schema is evolving too. Does the json extract provide sufficient stability guarantee that we can blindly fetch the latest version when, for whatever reason, rebuilding old version of locale?
The build script currently requires nightly compiler. locale is supposed to work with stable.
Distribution folks are gonna hate us if we insist on downloading anything as part of build. This can be fixed by first checking whether suitable local copy was already made and downloading only if not.

And then, the whole thing is huge. It has 21 MiB apparent size and 41 MiB disk usage. In contrast, ICU has, on my system 25 MiB, but that includes 9.1 MiB of charset conversion data we don't have. And even then, we are going to use far from all of it.
Last but not least, cargo still lacks mechanism for installing data files. So the only thing that would actually work for crates wanting to be installed via cargo install is if we embed the data in the binary (though we clearly eventually want that to be optional).

@jan-hudec it isn't supposed to be used yet, which I hoped would be clear from the README in the repo.

we can blindly fetch the latest version

Notice that the version of my CLDR crate is 29.0.0-alpha. The build script checks out the tag matching the CLDR crate's version; not master.

The build script currently requires nightly compiler. locale is supposed to work with stable.

I don't remember ever discussing this constraint. Anyway, we don't have much of a locale library to speak of yet. I can easily change to stable before releasing a non-alpha version. I want to lay down broad strokes here and get something going even if it requires nightly.

checking whether suitable local copy was already made

I'm going to move forward with fleshing out structs around CLDR data so this becomes a real library. You can make a PR (or file an issue) to help make the build script more polite and intelligent. Saving 10 - 20 MiB of space is of secondary importance at this early stage.

the only thing that would actually work

I don't think this is a problem. You wouldn't cargo install cldr because it doesn't have bin targets. Meanwhile, depending on cldr in a Cargo.toml file will allow the data to be written into OUT_DIR where the cldr lib has access to them without them being embedded in the libs. I did some cursory checks and it seemed to work fine. Did I understand you correctly?

leave further comments about CLDR crate on that project's issue tracker

Ok. Here is muuuuch simpler solution. There already is a library that bundles CLDR data and provides interfaces to them. It is also developed with lockstep with them. The ICU.
So the primary CLDR distribution mechanism will be simply using ICU as a backend. For everything. I don't like how some bits of it are done, but it's best to get things working first and pretty later.
:white_check_mark: designed.