Should all the requests be identifiable with a single HEI?

@erasmus-without-paper/all-members
To all developers,
I would like to bring your attention to an important specification detail which you might have missed. @Awerin just started implementing Echo API and, while he admitted it can be done this way, he still was quite surprised with this design decision. I would like for all developers to discuss this detail now, because the more we go into it, the harder it will get to change it.
Current 0..* design
This detail is: In the current architecture specification, each EWP request can be bound with multiple (0..*) requesting HEIs.
Pros:

The requester can perform a query in the name of all covered HEIs in a single request. For example, if Norway and Sweden have centralized systems (with access to all their HEIs), then Norway will be able fetch the data of all Norwegian students studying in Sweden in a single request.

Neither pro nor con:

(The are many other APIs related. E.g. Outgoing Mobilities API, IIA Search API, IIAs API, ToRs API. Each of this APIs may currently respond to requests made by multiple HEIs in a single HTTP request.)

Cons:

It makes the implementation a bit more complex. For example, the Outgoing Mobility Search API requires an additional sending_hei_id parameter (which is a list of HEIs). Server implementers need to remember, that the requester asks for the data in a name of many HEIs.

Alternate 0..1 design (@Awerin's proposal)
An alternative would look like this: Each request would be made in the name of a single HEI (or no HEIs). Many requests would be accompanied with a requesting_hei_id header/parameter (a single HEI who is asking about the data) which would replace parameters like sending_hei_id described above.
Pros:

Makes the implementation of the permissions a bit easier. Every request would be made in the name of either 0 or just 1 HEI. Easier to understand for EWP Partners whose implementations cover singular HEIs.

Cons:

In the examples described above, Norway would not be able to ask for all its students in Sweden in a single request anymore. It would be required to make N requests, where N is the number of HEIs in Norway.

I would vote that we stay with the current design. Perhaps it makes the implementation a bit more complicated, but it also scales better for centralized (multi-HEI) institutions.
Also, I wouldn't be required to rewrite stuff ;)

The problem occurred to me while working on the Java libraries. I had to decide how to represent the entity which is requesting (the actor). Methods will grant access to the data based on that entity. It could be also used to log requests for auditing. It seemed appropriate to see the HEI as such actor and not the list of HEIs (as it isn't an entity on its own).

After a quick summary of the problem presented by @Awerin in Warsaw, most developers seemed to prefer the 0..1 solution. I was a bit surprised by that decision. In Poland, each HEI is covered by its own host anyway, but I tried to design for the solution that seemed to be optimal for other partners too. However, it seems that most partners would still prefer a simpler approach, instead of the "theoretically most efficient" one. So we will have to follow this through. There are some details which need further explanation though.
As indicated in the current structure of the manifest file (4.0.0-rc2), I have designed the architecture to allow communication between computer systems (EWP Hosts), and each of those would represent a group of HEIs (as opposed to just a single HEI):

A1. Each request in the network could have been made from 0..* HEIs to 0..* HEIs.
This means that one computer system was able to query other computer system about any number of HEIs supported by either of those in a single request. E.g. Which of the Mobility objects you are the master of AND I have access to have changed in the last 24 hours?

Monday, we have kind of decided to migrate toward a different approach:

A2. Each request in the network will be made from 0..1 HEI to 0..* HEIs.
This means that one computer system will be able to query another computer system only in a context of a single requesting HEI. However, it will still be able to ask about multiple HEIs covered by the server which has received the request. E.g. Which of the Mobility objects you are the master of AND HEI X has access to have changed in the last 24 hours? (request will need to be accompanied by the requesting_hei_id=X paremeter, and X will need to covered by the requesting EWP Host).

Tuesday, one more approach was proposed:

A3. Should each request in the network be made from 0..1 HEI to 0..1 HEI?
This means that each request will be made in the context of at most a single asking HEI and a single responding HEI. E.g. Which of the Mobility objects which are owned by HEI Y and HEI X has access to have changed in the last 24 hours?

If we really don't want to support A1, then I think that A3 would be more understandable than A2.
Regardless of what we choose, this is a big change in the core architecture and most specifications and APIs will need to be updated.

A2 does seem to cover the main need (most or all use cases), and if a requesting host should need information for more than one of its own HEIs, it can always send multiple requests. We live in 2016, so I'm not worried about a few possible extra HTTP requests and responses. So I'm fine with A2.
I'm not fine with A3 which, as you also say, would be a big change in the core architecture, in addition to making the system more complicated for hosts handling multiple HEIs.

A3 seems like another good step.
@mpuzar, could you give an example of the complications that A3 causes for those hosts which handle multiple HEIs?

Having responsibility for 60 HEIs, we would need to make 60 different connectors (probably virtual, but still) for each and every one of them, 60 certificates, etc. If made virtually, they would need to analyse which HEI it was called. These are the first things that come to my mind.

we would handle somewhat over 100 HEIs on our SAAS hosts
general host to host communication is a bit troublesome
if for example one of our customers is asking one of Oslos HEIs, it would in fact be 100 HEIs asking 60 HEIs for a single piece of data which will most probably generate a lot of overhead
1:* communication seems somewhat feasible but in our case incoming requests would still cause some overhead calculation and again, if only one of our customers is asked, probably 20 of them would answer.
in case of 1:1 communication I am not sure which would be the best solution for identifying the target HEI, probably a normal GET or PATH parameter
in this case I think we also wouldn't go for any batch synchonisations since these could stack up to ten thousands of requests (even in 2016 we brought down a federal database with a similar scenario in austria) and these batch requests should probably not be done during working hours, just saying
but maybe I am missing something, please correct me
i think for usual business 1:1 communication (A3) would be the most feasible solution
the only usecase for 1:* and : communication i can think of are bulk synchronisations and these could probably deserve a separate API or parameter or something to trigger them.

100 HEIs asking 60 HEIs for a single piece of data

In the original architecture (A1), you would need only a single HTTP request for that. Of course, the performance of this single request varies on the implementation of the server endpoint (but A1 allows it to be implemented in a maximum efficient way, with only O(1) HTTP requests, while other proposals might force you to perform even O(n^2) loops).
BTW, in order to understand each other properly we should try use clearly defined terms. EWP Host is a provider of services for a group of HEIs. So, when you're saying that "host to host communication is a bit troublesome", you mean the A1 architecture?

the only usecase for 1:* and *:* communication i can think of are bulk synchronisations and these could probably deserve a separate API or parameter or something to trigger them.

It very important to stress the fact that we are now talking about changing the architecture itself - not individual APIs.
Our original architecture (A1) was designed precisely with this in mind - to allow multi-HEI providers (such as Norway and SOP) to design complex APIs in the most efficient way, and be able to publish such APIs via our Registry. It is a bit more difficult to grasp, that's true... But it allows for "maximum possible performance", regardless of the APIs we may think of in the future. None of the other proposals do (A2, A3).

In other words, if we really intend for our architecture to support such APIs in the future, then I still feel that we should stick with A1, as we have originally proposed. If we select other architecture only because "it seems to be enough for us now", then this may mean that it will need to be extended in a followup project - and - we will still eventually end up with complexities of A1...

yes by host to host i meant EWP host to EWP host or : or A1
i think this is tightly coupled with the HEI parameter
if we are able to identify the calling HEI(s) and the target HEI(s) we are perfectly good, but if we can't we would have to check all possible calling and all possible target HEIs.
In terms of requests it would be perfectly efficient.
but if 99% of the communication is HEI to HEI and we cannot easy decide which HEI is affected we have a significant CPU and database overhead
example would be one single HEI asking one single HEI to list agreements.
if we don't know the exact HEIs involved all 100 would have to answer or the other EWP host would have to answer to all 100

If I understand correctly, your performance issues spawn from the fact, that your SAAS doesn't have a central database. That is, if your API implementation receives a query about multiple HEIs, you will need to - internally - query all of them, and this could take too much time. Is this correct?
If so, won't this link be a better solution for this particular problem? E.g. You would be able to declare in your manifest file, that you are willing to query at most 10 HEIs in one request.

I re-read the related things to this.
correct me if I am wrong.
Even though the communication is EWP host to EWP host we would have parameters indicating which HEI is calling (parameter or certificate) and which HEIs the request is targeting? (didn't find anything on that)
in that case this approach would be perfectly fine for us.
if we don't indicate the target HEI we would have to do the following on each single request (depending which API is called):
check all 100+ HEIs of us if they have agreements with calling HEI(s) or are otherwise supposed to answer
probably check settings for all HEIs if they are configured to answer (our HEIs would most probable be able to opt out of EWP)
iterate over all HEIs which should answer and compose/calculate the results for each HEI
in the case that one HEI requests its 5 agreements from another HEI the answer could at worst contain 100+ agreements of the other HEIs represented by us, which would actually not have been requested in the first place
but again, if we know which HEI(s) is calling which HEI(s) we can perfectly handle these requests efficiently

A1 architecture itself would just give you "a list of the HEIs covered by the requesting EWP Host". However, you may require more information in the particular APIs.
For example, see the this vesion of the Outgoing Mobility Search API. Both sending_hei_id and receiving_hei_id are repeatable and optional, but we could make them required and allow you to make them not-repeatable. Then, if you declare <max-receiving-hei-ids>1</max-receiving-hei-ids> in your manifest file, then you'll only be required to query a single receiving HEI for each your request.

in the case that one HEI requests its 5 agreements from another HEI the answer could at worst contain 100+ agreements of the other HEIs represented by us, which would actually not have been requested in the first place

I think I understand your problem now. And I think you can prevent that with a simple trick. As you know, it is you who will generate the IDs for such agreements. So, you are allowed to include the HEI ID in your generated agreement IDs. Then, whenever you see an ID of an agreement, you will know which HEI you should ask.
So, I'm just saying, that the A1 architecture does not seem to prevent you from doing things efficiently.

And in some rare cases A1 also allows you to do things more efficiently than A2 or A3.
For example, when external institutions will ask you for the list of all agreements (probably via IIA Search API), then you will be allowed to return a cached response (whenever you are quite sure that no new agreement was created in any of your HEIs). Whereas in A3, you would get 100 requests, instead of just 1.

I think I understand your problem now. And I think you can prevent that with a simple trick. As you know, it is you who will generate the IDs for such agreements. So, you are allowed to include the HEI ID in your generated agreement IDs. Then, whenever you see an ID of an agreement, you will know which HEI you should ask.

I don't think we should rely on tricks. For some methods they may not be even possible. They may also be problematic if, for example, a HEI ID changes.
What that example shows is that adding information about caller and receiver to the context of a method may be important. Solution A1 hides that information.

For example, when external institutions will ask you for the list of all agreements (probably via IIA Search API) [...]

What would be the use case for that?
As it was already stated we probably shouldn't be afraid of multiple requests if that only means more headers in the network layer. If it would also mean more database queries than it would be more of an issue.
Even if we decide that it might be an issue to send one request for every HEI we want to ask for, then we should remember that in many cases we won't have other options. For example, in Poland there will be a host for every HEI that is using USOS.

I am not against migrating to A3. I just want existing SAAS providers to understand what they're giving up and make this decision knowingly. They could make use of A1.

What that example shows is that adding information about caller and receiver to the context of a method may be important. Solution A1 hides that information.

It does not include that information on itself, but it still can be included on the API-level.

What would be the use case for that?

Periodical full synchronization. (We cannot trust CNR notifications to always be sent and delivered.)

For example, in Poland there will be a host for every HEI that is using USOS.

There will be now. But who knows how it will look in 10 years time?

if affected HEIs can be clearly identified in each request I think A1 would be the one to go since it would be internally the same as A3 (iteration through entries) but with a single request
without this identification it would probably cause too much overhead during daily business
batch syncs would be carried out during night hours where it doesn't really matter if it takes 5 minutes and 1 request or 5 hours and a million requests
most probably the way to go is A1 with parameters for calling and target HEIs and the possibility to specify in the manifest the limit for calling/target institutions even down to 1, which leads to a degration to A3

most probably the way to go is A1 with parameters for calling and target HEIs and the possibility to specify in the manifest the limit for calling/target institutions

In other words, you would vote to do the following:

Not switch the architecture itself. A single request still would be able to be made in the context of multiple requesting and multiple responding HEIs.
For some APIs, make requesting_hei_id and responding_hei_id parameters required (names may differ, depending on the API), but leave them as repeatable.
Add requesting_hei_id and responding_hei_id parameters to APIs such as Outgoing Mobility API, because you don't want to use any ID-tricks, and you want the caller to know exactly which HEIs should be the masters of which mobilities.

Did I understand you correctly?

yes, sounds like the most feasible approach to me
whats your opinion @mpuzar @mikesteez ?

My opinion is that we should choose a 1:1 mapping for requests and responses.
Arguments:

Ease of implementation - it is much easier to implement a straight model
No premature optimizations - we can't optimize for use cases that does not exist. Communication is made to known parties, not "all HEIs in a country".
The clients to the EWP network should not have to care about either the physical or logical deployment of the hosts.
I also don't think we should implement https://github.com/erasmus-without-paper/general-issues/issues/11 - make links in the response to the next page of results
Less interpretation and logic from information in the Manifest
We can always make things more complex later on - focus on simplicity and adoption right now

Note, that - even in A3 - some requests in the network will not be bound to specific HEIs. So it will be [0..1]:[0..1], not 1..1.
However, we can make all requests bound to "some institutions" (and HEI would be a "subclass" of such). E.g. the Registry Service and the Central IIA Host could be bound to such non-HEI institutions. Then, it would be indeed 1..1.

I also don't think we should implement https://github.com/erasmus-without-paper/general-issues/issues/11 - make links in the response to the next page of results

This seems unrelated. Could you post this comment in the related thread?

I would point the same arguments as @mikesteez.

@georgschermann, would you be against using A3? If I understood your earlier arguments properly, both proposals are okay for you?
@mpuzar, @erasmus-without-paper/wp3, @erasmus-without-paper/all-members? Will all of you be able live with A3? If not, we will stay with A1.
It will be a lot of work to change all the specs. So I will need to have some kind of approval from each of you, even if half-hearted.

A 1:1 mapping, as described by @mikesteez, can be achieved with A1/A2 as well (by specifying the requesting and target HEIs). There is absolutely no reason for a radical change such as A3 to get it working. Please don't do it.

Norway does not agree with the change in solution for the following reasons:
First of all, the intension of this network was to be able to provide a simple as possible way to communicate between two peers without putting too much implementation strain on the single peer. Making each peer handle the whole of the communication means more work for each and the additional hassle of maintaining a certificate.
We do not see how A3 is easier than A1. If we are talking about just a couple of peers communicating, then it really does not matter, but here we are potentially talking about thousands. We feel that it will be much harder to get new partners to join this network if they have to handle the cost of certificate maintenance on top of have to understand and implement the whole communications protocol. I am quite confident that very few universities would have join our EMREX project if we had told them that they had to serve their own certificate and host their own node. Remember that we want to "sell" EWP to more and more and more partners. The lowest possible cost for them, both in money and work, is key.
The solution we have today is flexible in that it allows several HEI's to cooperate on implementation of a host. The host doesn't have to be on the national level, but for some countries it will.
We think @wrygiel has a good solution with the use of requesting_hei_id and responding_hei_id and see no need to change the whole architecture.

A1 with HEI identification and A3 are both perfectly fine for us.
I also don't really see how A1 would be more complex to implement than A3.
I think handling certificates per HEI could be needed and desirable at some point, but not necessary on the "transport layer".

most probably the way to go is A1 with parameters for calling and target HEIs and the possibility to specify in the manifest the limit for calling/target institutions even down to 1, which leads to a degration to A3

this would allow host implementers to force 1:1 communication, if they are not comfortable with implementing :, and allows to force 1:1 for some APIs which probably don't make sense as :

it seems more crucial to be able to always tell which HEI is asking for the data

In A1, you will still be able to tell that, but on the API-level (not the network-level). This way, we are able to introduce both:

simple HEI to HEI APIs, similar to A3,
more efficient APIs, ideal for SAAS providers.

A1 means that a request is handled as if it was composed of multiple requests

In A1, each request can be bound to multiple requesting and multiple responding HEIs. But as requested here - for majority of APIs - it will be bound to a single requesting and a single responding HEI, exactly as you would expect.

@richared I'm afraid I don't understand how it can be simpler to have a very complex *.*network instead of a 1:1? Smaller institutions will have to get into the EWP network through a provider such as SOP. Managing one certificate for each installation seems like the smallest of all problems facing deployment of EWP.  Especially if an institution is to implement the API themselves.

with A1 small institutions would still have the chance to limit all the requests to one caller and one target and implement the APIs as if they were 1:1
But larger hosts would have the possibility to utilize *:* requests if the other host allows it.

Ok, then! We will stick with A1 for now.
Probably nobody would be 100% happy, regardless of what we chose, but we need to pick one way and stick with it, at least for the following months (I have lots of specifications to update, and I will base the changes on A1 and this comment). We can return to this discussion after the model is completely designed and specific APIs start to be implemented.


Add endpoint to serve data folder

Closes #43
Changes made by this Pull Request

Introduces an endpoint that serves the data folder whenever not in production mode

Definition of Done

[ ] Tests are written and run successful
[ ] Code is documented
[ ] User Manual is updated
[ ] All requirements of the user story are met

Codecov Report

Merging #46 (854ed96) into dev (795084c) will decrease coverage by 1.51%.
The diff coverage is 95.45%.

@@             Coverage Diff             @@
##               dev      #46      +/-   ##
===========================================
- Coverage   100.00%   98.48%   -1.52%
===========================================
  Files            2        2
  Lines           45       66      +21
===========================================
+ Hits            45       65      +20
- Misses           0        1       +1

Impacted Files
Coverage Δ

api/mod/src/app.py
98.21% <95.23%> (-1.79%)
:arrow_down:

api/mod/src/settings.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

Look nice, I just have one question:
I'm not sure if we should disable the route in prod, or was that part of the user story? Because I don't see the need in debug mode as one can just look into his file system. And leaving out any security issues, it would be helpful to view the files in prod, right? We could think about implementing some access control for such routes but maybe it's not that crucial without it right now. What do you think? :)

Look nice, I just have one question:
I'm not sure if we should disable the route in prod, or was that part of the user story? Because I don't see the need in debug mode as one can just look into his file system. And leaving out any security issues, it would be helpful to view the files in prod, right? We could think about implementing some access control for such routes but maybe it's not that crucial without it right now. What do you think? :)

Not 100% sure, but I understood it that way: That the route should only be available in dev environments.
Yes, you don't necessarily need it locally. But I actually found it useful when working in the dev docker (with it's not-synced home -dir)
And it's definitely no security concern there, whereas in production...


Slow getLinkPreview

Hi,
I'm not sure if this is expected.
Running this on react-native. I'm able to get a response. But the time it takes is very long.
On an IOS simulator, I see that getting the link preview takes about 2.5s
On an Android device, it's closer to 4s.
I've tried editing the headers user-agent cycling between none, Twitterbot & googlebot to no avail.
I was using 2.1.10 and updated to 3.0.3 but with no luck.
Code snippet bellow. Essentially fetching metadata on the component load and rendering an image when the metadata is returned.
Any help on improving performance would be great!
import { getLinkPreview, getPreviewFromContent } from "link-preview-js";

export const MetaImage = ({url}) => {

const [imageUrl, setImageUrl] = useState("")
    const fetchData = async () => {
        var ts = moment().valueOf()

        let data = await getLinkPreview(url, {
            headers: {
                "user-agent": "Twitterbot"
            }
        })
        console.log(data)
        if(
            data!=undefined &&
            data.images!=undefined &&
            typeof(data.images)=="object"&&
            typeof(data.images[0])=="string"
        ){
            console.log("fetch time: " + (moment().valueOf()-ts))
            setImageUrl(data.images[0])

        }
    }

    useEffect(()=>{
        fetchData()
    },[])

    console.log("imageurl: " + imageUrl)
    if(imageUrl.length==0){
        return (
            <View>
                <View
                    style={{width:50, height:50, backgroundColor:colors.lightGrey}}
                />
                <Text>{url}</Text>
            </View>
        )
    } else {
        return (
            <View>
                <Image
                    source={{
                        uri:imageUrl,
                        cache:'force-cache'
                    }}
                    style={{width:50, height:50, resizeMode:"contain"}}
                />
                <Text>{url}</Text>
            </View>
        )
    }

}

Doubt this has to do with the library, but if you provide a reproducible example I can take a look

No response from author, going to close this, it's pretty much impossible this library is the cause of slow requests. The only case I could think of is that the page trying to be parsed is huge and you are running this on a low-end device, on which case there is nothing I can do.


showNextCoachMark has bad logic causing crash

I am conditionally hiding my first coach mark. When I do hide it, my app crashes because of this line of code. It looks like self.currentIndex is increment before it is checked for 0, so the if statement will run 100% of the time.
private func showNextCoachMark(hidePrevious hidePrevious: Bool = true) {
        self.currentIndex += 1

        // if `currentIndex` is above 0, that means a previous coach mark
        // is displayed. We call the delegate to notify that the current coach
        // mark will disappear, and only then, we hide the coach mark.
        if self.currentIndex > 0 {
            self.delegate?.coachMarksController(self, coachMarkWillDisappear: self.currentCoachMark!, forIndex: self.currentIndex - 1)

            if hidePrevious {
                self.coachMarkDisplayManager.hideCoachMarkView(self.currentCoachMarkView, animationDuration: self.currentCoachMark!.animationDuration) {
                    self.removeTargetFromCurrentCoachView()

                    if self.currentIndex < self.numberOfCoachMarks {
                        self.createAndShowCoachMark()
                    } else {
                        self.stop()
                    }
                }
            } else {
                if self.currentIndex < self.numberOfCoachMarks {
                    self.createAndShowCoachMark()
                } else {
                    self.stop()
                }
            }
        } else {
            self.createAndShowCoachMark()
        }
    }

Hello @hobbesthetige, thanks for reporting the issue.
On which line does the crash occur, exactly?
The idle/default value for self.currentIndex is actually -1, not 0. 😉

Closing due to inactivity.


Zigbee firmware hex for the Sonoff BASICZBR3 with  DS18b20  as Enddevice

Hello,
I test Sonoff ZBR3 with your first release firmare with temperature sensor DS18b20.
I use this relay for control electric heater in water tank.
In HA with mqtt i see temperature from sensor DS18b20.
Generally is working but from time to time i have error 'No network route' and i have to unpair and pair again.
My coordinator is 5m away from ZBR3.
I think there is an issue with two devices (CC2530) struggling to route the signal (they are so weak…). The outcome is that another CC2530 (BlitzWolf BW-SHP13) connects to both of them instead of picking “stronger” routers (that it was connecting before). Finally, it often loses the signal from these Sonoffs  DS18b20 with and does not pick the better routers…
Would it be possible to disable the router feature with your firmware as the second release?
So this BASICZBR3 will work as Enddevice ?
For your information i tested firmare "Zigbee Configurable Firmware v2.5" from "PTVO" with router and without router and this modded firmare can't show temperature from sensor DS18b20.
So please add second release with the source code but as only Enddevice.
waiting for your fedback.
Thx
Wojtek

I do not plan to modify another version of the firmware. you can try building it yourself.
As for the ptvo configurator, DS18b20 sensors should work there. you may not have configured it

Hello ,
thank you for your answer, i don't know how to build it.
But back to PVTO firmare i prepare firmare input/output like on that attached movie https://youtu.be/t8f4HUBQveg, maybe you can take a look and write your opinion?
Board type: CC2530 (without external oscillator, like Sonoff BasicZBR3)
Device type: End device without routing
Power saving mode (PSM): No
Status LED: Yes
Default reporting interval (s): 30
Output pins:
P07: Output 2, GPIO, Pull-up, Remember state
Input pins:
P22: Input 1, DS18B20, External pull-up
P13: Input 2, GPIO, Pull-up, Link to out 2

@rogu22 These settings should work.

Hi now it works
in mqtt i have log?:
Zigbee2MQTT:info  2020-11-13 15:01:46: MQTT publish: topic 'zigbee2mqtt/0x00124b001b78b5df', payload '{"device_l1":"28-1C-3F-50-22-20-01-4F","l1":23,"linkquality":36,"state":"OFF","state_l2":"ON","temperature":35.62,"temperature_l1":23}'
question what i have write in the configuration to present this information from input I1?

platform: "mqtt"
state_topic: "zigbee2mqtt/<0x00124b001b78b5df/get/l1>"
availability_topic: "zigbee2mqtt/bridge/state"
unit_of_measurement: "°C"
device_class: "temperature"
value_template: "{{ value_json.temperature_l1 }}"


bug([Autocomplete]): [Wrong Panel Direction]

Reproduction
https://angular-tpr5kk.stackblitz.io
Steps to reproduce:

Open the page on an iPad and start typing
Click into the autocomplete-component and type "A"

Expected Behavior
The panel containing the results opens upwards because there is not enough space to open it downwards.
Actual Behavior
The panel opens downwards and not all results are visible.
Environment

Angular: 8.2.14
CDK/Material: 8.2.3
Browser(s): Safari (on iPad)
Operating System (e.g. Windows, macOS, Ubuntu): iOS 13.3.1 (on iPad Air 2)

Comment
My suspicion is that it could have something to do with the fact that the software-keyboard is displayed below the page.

The same occurs for Firefox and Chrome on the same iPad, by the way (just tested that).


Preparing Cargo.toml for next release 0.2.4

Description

Fixes pyrsia/pyrsia#
This PR prepares cargo.toml for next release
Screenshots (optional)
PR Checklist

[x] I've read the contributing guidelines.
[x] I've read "What is a Good PR?"
[x] I've included a good title and brief description along with how to review them.
[x] I've linked any associated an issue.

Code Contributions

[x] I've run pre-commit.sh (pre-commit.bat) successfully.
[x] I've run the integrations tests
on the PR branch and all tests passes.

Coverage: 50.509%. Remained the same when pulling fadaf3aed7c696770321af08ebfbdebdb63ae4c2 on dasmanas:prep-version-0.2.4 into 74635526a6f3e4ccf2debb8c59ff11a01255191c on pyrsia:main.

I compared it with the previous version and found that .github/workflows/rust.yml is not updated this time. Is it intentional? https://github.com/pyrsia/pyrsia/pull/1444/files

hardcoding has been resolved by #1495

I compared it with the previous version and found that .github/workflows/rust.yml is not updated this time. Is it intentional? https://github.com/pyrsia/pyrsia/pull/1444/files

all version hardcoding has been resolved by PR #1495

@dasmanas Thank you for the info!


Review claim in sentance

I believe the sentence "Audit logs: The audit logs activity report gives you access to the history of every task that's performed in your tenant." is not accurate. You could be lead to believe that anything within Teams, SharePoint/OneDrive or Exchange would be captured here, but as I understand that's not the case.  For example, creating a transport rule wouldn't get capture here, change a Teams admin setting for communicating with external users wouldn't be captured either.

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

ID: 39bd6875-8c82-02ff-5b74-86bc9ce5b902
Version Independent ID: d9d36752-ac83-89b1-e22d-32ba6a41d7e5
Content: Azure Active Directory activity logs in Azure Monitor
Content Source: articles/active-directory/reports-monitoring/concept-activity-logs-azure-monitor.md
Service: active-directory
Sub-service: report-monitor
GitHub Login: @MarkusVi
Microsoft Alias: markvi

@benjaminjamesowens
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

@benjaminjamesowens
Thank you for pointing this out! I've created a PR to update the documentation and it's currently waiting for the author to review and sign off.
I will now close out this issue. Please allow some time for the author to review and the changes to reflect.
Thank you for your time and patience!


Quadratic runtime when sending many requests

Using NIOHTTP2 version 1.0.1.
Caveat: We might be doing something wrong in SwiftGRPC and/or this might be fixed by @Lukasa's recent changes, but I figured you guys might want to take a look.
When I run https://github.com/grpc/grpc-swift/blob/da1a59c919555367abfd6e2ffb285a175ffa11c0/Tests/SwiftGRPCNIOTests/NIOFunctionalTests.swift#L79 in Release mode with numberOfRequests = 2_000:
Test Suite 'Selected tests' started at 2019-04-08 14:11:22.901
Test Suite 'SwiftGRPCNIOTests.xctest' started at 2019-04-08 14:11:22.901
Test Suite 'NIOFunctionalTestsInsecureTransport' started at 2019-04-08 14:11:22.901
Test Case '-[SwiftGRPCNIOTests.NIOFunctionalTestsInsecureTransport testUnaryLotsOfRequests]' started.
1000 requests sent so far, elapsed time: 0.32004
total time to send 2000 requests: 0.852957
total time to receive 2000 responses: 2.479385
Test Case '-[SwiftGRPCNIOTests.NIOFunctionalTestsInsecureTransport testUnaryLotsOfRequests]' passed (1.644 seconds).
Test Suite 'NIOFunctionalTestsInsecureTransport' passed at 2019-04-08 14:11:24.545.
	 Executed 1 test, with 0 failures (0 unexpected) in 1.644 (1.644) seconds
Test Suite 'SwiftGRPCNIOTests.xctest' passed at 2019-04-08 14:11:24.545.
	 Executed 1 test, with 0 failures (0 unexpected) in 1.644 (1.644) seconds
Test Suite 'Selected tests' passed at 2019-04-08 14:11:24.546.
	 Executed 1 test, with 0 failures (0 unexpected) in 1.644 (1.645) seconds
Program ended with exit code: 0

When run with numberOfRequests = 4_000:
Test Suite 'Selected tests' started at 2019-04-08 14:11:36.312
Test Suite 'SwiftGRPCNIOTests.xctest' started at 2019-04-08 14:11:36.312
Test Suite 'NIOFunctionalTestsInsecureTransport' started at 2019-04-08 14:11:36.312
Test Case '-[SwiftGRPCNIOTests.NIOFunctionalTestsInsecureTransport testUnaryLotsOfRequests]' started.
1000 requests sent so far, elapsed time: 0.345793
2000 requests sent so far, elapsed time: 0.896414
3000 requests sent so far, elapsed time: 2.113964
total time to send 4000 requests: 3.534887
total time to receive 4000 responses: 7.418182
Test Case '-[SwiftGRPCNIOTests.NIOFunctionalTestsInsecureTransport testUnaryLotsOfRequests]' passed (4.771 seconds).
Test Suite 'NIOFunctionalTestsInsecureTransport' passed at 2019-04-08 14:11:41.084.
	 Executed 1 test, with 0 failures (0 unexpected) in 4.771 (4.772) seconds
Test Suite 'SwiftGRPCNIOTests.xctest' passed at 2019-04-08 14:11:41.085.
	 Executed 1 test, with 0 failures (0 unexpected) in 4.771 (4.772) seconds
Test Suite 'Selected tests' passed at 2019-04-08 14:11:41.085.
	 Executed 1 test, with 0 failures (0 unexpected) in 4.771 (4.773) seconds
Program ended with exit code: 0

Partial Instruments screenshots:

Huh, weird. I'll investigate.
As a quick note, I don't think my recent changes will have affected that, as they imposed a linear cost on each header block encoded, and header block encoding is always going to be linear-time anyway. So we need to investigate further and find where the linear operation count is.

Hrm, this is a nasty one.
Regardless of whether or not the HTTP/2 stack has any quadratic runtime in it, we're not getting a chance to exercise it. This is because we're hitting a quadratic runtime problem in NIO's scheduler first. We'll need to resolve that before we go any further.
The issue is fundamentally to do with the way our Heap is implemented. Specifically, we're hitting a weird edgecase which appears to cause Swift to emit unnecessary ARC traffic, and that unnecessary ARC traffic leads to an unnecessary CoW of the backing array storage. Tracking that down took quite a while, but the result is that a loop spinning on any of the SelectableEventLoop functions that modifies the task queue (execute, submit, schedule) exhibits quadratic behaviour.
While we wait for the above Swift bug to be fixed I'm also going to rewrite the Heap. The weird edge case was hit because of our use of static funcs, and those were only there to allow us to feel more confident that we hadn't misimplented the algorithms. We clearly haven't, and we also wrote a bunch of tests, so I'm going to just pull those functions down into instance methods that Swift is more capable of seeing through, which should resolve the problem nicely.
I am not confident this is the end of the quadratic behaviour this test will see. In particular, I'm sure there is a quadratic loop in the HTTP/2 code that I've already found that this test should hit. With that one I'm less confident whether we should fix it or let it sit there, but that's a discussion for another day: first, let's fix the quadratic behaviour we know about.

See apple/swift-nio#960 for the fix for Heap.

Wow, impressive detective work! Looking forward to seeing what the performance of this test will be once all the quadratic runtime issues are fixed.

Incidentally, there's another major performance gain you can have here that works today.
Right now the test spins in a loop on client.get, which ends up calling EventLoop.execute to swap onto the event loop thread. The effect of that is that you are acquiring and releasing the event loop task queue lock many times in a tight loop. This lock will simultaneously be being contended on by the event loop thread itself, so this lock acquisition pattern ends up being quite slow.
In the pre-Heap-fix code I changed this by moving the loop execution onto the event loop thread. This eliminated the cross-thread traffic, and in one case dropped the runtime for preparing 20k requests from 13 seconds to 2 seconds.
Put another way, the cross-thread communication still utterly dominates the quadratic runtime of the heap logic if the iteration count gets large enough.

@MrMage Is this problem still outstanding for you?

@lukasa I haven't tried recently; my understanding was that there were other causes of quadratic behavior that have yet to be fixed. Is that still the case or should I re-run our tests?

So there's one possible source of quadratic behaviour in your code, which is that calls to flush from the child channels will lead to a loop over the number of streams that are being buffered to avoid violating SETTINGS_MAX_CONCURRENT_STREAMS. As you attempt to create a bunch of streams all at once, and flush each of them, that buffer will be sized O(n), and will be flushed O(n) times, leading to a quadratic loop.
However, I don't believe that quadratic behaviour is likely to be a performance problem in real programs. Your test wildly exceeds SETTINGS_MAX_CONCURRENT_STREAMS (which is usually set to 100), and so is an absolute worst-possible-case for that code. It's also profoundly difficult to fix within the semantics of NIO's flushing model: I end up needing to maintain a separate data structure that indicates which streams need to be flushed, and in the common-case (where there are only a handful of streams buffered at most) that's more expensive than the current model.
So I'm interested in seeing whether you're still having trouble. If your test runs in an acceptable amount of time then I'm going to consider that quadratic behaviour low-urgency to address.

@lukasa thank you for the elaboration! I can confirm that sending requests is now very fast, even from "off" the event loop (I guess acquiring 2000 locks isn't a major bottleneck yet). However, waiting for all requests to be received takes three times longer for each doubling of the request count:
1000 requests sent so far, elapsed time: 0.085628
total time to send 2000 requests: 0.12969
total time to receive 2000 responses: 1.721965

1000 requests sent so far, elapsed time: 0.110867
2000 requests sent so far, elapsed time: 0.176551
3000 requests sent so far, elapsed time: 0.232632
total time to send 4000 requests: 0.291121
total time to receive 4000 responses: 4.914795

1000 requests sent so far, elapsed time: 0.090735
2000 requests sent so far, elapsed time: 0.151104
3000 requests sent so far, elapsed time: 0.2133
4000 requests sent so far, elapsed time: 0.269586
5000 requests sent so far, elapsed time: 0.312878
6000 requests sent so far, elapsed time: 0.355842
7000 requests sent so far, elapsed time: 0.410365
total time to send 8000 requests: 0.453256
total time to receive 8000 responses: 15.107122

Looking at the Instruments traces, it does appear that flushing is the culprit here, and is a bottleneck, mostly on the client:

I assume this is the behavior you are describing; given that it only occurs in a fairly "extreme" test right now, there's probably no point in trying to fix this.

Follow-up: I can confirm that injecting a
Thread.sleep(forTimeInterval: 0.00025)

inside the "send" loop completely eliminates the quadratic-runtime issue. However, that runtime appears to not be very relevant for 2000 requests, anyway; it only becomes apparent when sending 4000 or more requests.

Ok, for now I think we can accept that if you're exceeding SETTINGS_MAX_CONCURRENT_STREAMS by 40x then you may begin to see performance problems and want to rearchitect your application. We can revisit this decision down the road if it becomes worthwhile.
Let's call this done for now. Thanks for the report, it led to a number of useful fixes!

Follow-up: I can confirm that injecting a
Thread.sleep(forTimeInterval: 0.00025)

inside the "send" loop completely eliminates the quadratic-runtime issue. However, that runtime appears to not be very relevant for 2000 requests, anyway; it only becomes apparent when sending 4000 or more requests.

Sorry, why does this work?

Sorry, why does this work?

The test runtime explodes because each flush call needs to iterate over all open streams. Throttling the number of send operations in flight reduces the amount of streams that are still open and thus need to be iterated over.

The test runtime explodes because each flush call needs to iterate over all open streams. Throttling the number of send operations in flight reduces the amount of streams that are still open and thus need to be iterated over.

Ahh of course, thanks!


gaussian measure for bq

Issue #130 , if available:
Description of changes:

added gaussian integration measure
added q-rbf kernel that integrates agains gauss measure
deleted integration agains uniform measure after the loop. This was not nice in the first place. We can add this as another q-kernel. but I did not want to overload this PR as it is already cluttered.
adapted tutorial notebook accordingly
added some tests

Tests pass.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #247 into master will increase coverage by 0.33%.
The diff coverage is 78.52%.

@@            Coverage Diff             @@
##           master     #247      +/-   ##
==========================================
+ Coverage   89.11%   89.45%   +0.33%
==========================================
  Files         114      114
  Lines        3343     3403      +60
  Branches      360      371      +11
==========================================
+ Hits         2979     3044      +65
+ Misses        291      280      -11
- Partials       73       79       +6

Impacted Files
Coverage Δ

emukit/quadrature/interfaces/base_gp.py
75% <ø> (ø)
:arrow_up:

emukit/quadrature/loop/quadrature_loop.py
47.61% <0%> (ø)
:arrow_up:

emukit/quadrature/kernels/__init__.py
100% <100%> (ø)
:arrow_up:

emukit/quadrature/kernels/bounds.py
100% <100%> (ø)

emukit/quadrature/methods/vanilla_bq.py
100% <100%> (+36.95%)
:arrow_up:

emukit/model_wrappers/gpy_quadrature_wrappers.py
77.46% <33.33%> (-15.64%)
:arrow_down:

emukit/quadrature/kernels/integration_measures.py
80% <80%> (ø)

emukit/quadrature/kernels/quadrature_kernels.py
80.55% <85.71%> (-0.93%)
:arrow_down:

emukit/quadrature/methods/warped_bq_model.py
83.72% <85.71%> (-2.33%)
:arrow_down:

emukit/quadrature/kernels/quadrature_rbf.py
95.77% <92.85%> (-4.23%)
:arrow_down:

... and 2 more

Continue to review full report at Codecov.

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


select2 closes before selected on android chrome mobile

Hi all I have a problem to all contributors, my select2 version 4.0.5 closes before I do a select an option . any suggestion to handle this ? it only happens for some android phones and using chrome mobile. Thank you

This issue should be fixed in a newer version of Select2. Try out 4.0.10, it's almost 2 years newer than the version you are using.


New layout > styling corrections

[ ] Add some margin to the bottom of the app selector

[ ] Linux > double scrollbar in messaging

[ ] perhaps the middle vertical line separating panels should be darker and not in the same tone as one of the app colours

[ ]  First tab position could be better parked to the left of the screen

First tab position could be better parked to the left of the screen

let's leave this one as it is.
it's a bit off because of "tab scroller" that appears when tabs do not fit the available width


🚀[Release v3.11.1] Merge into Main

What's New?

Fixed the Segwit (ltc1) addresses which fixes the regression
Removed Litecoin Card
Updated Unstoppable Domains to latest versions
Re-added the gitignored partner-keys file
Minor improvements

Thanks for your time @josikie

Most welcome @kcw-grunt


error: Specified handle 1 already in use on line 604

I tested the dxf with autocad 2002 and 2007.
dxf-rs 35671103fbabc3b5680cda9cbef0f4d39d3eb162
error
Specified handle 1 already in use on line 604.
Invalid or incomplete DXF input -- drawing discarded.

code
extern crate dxf;
extern crate failure;

use failure::Error;

fn test() -> Result<(), Error> {
    use dxf::Drawing;
    use dxf::entities::*;

    let mut drawing = Drawing::default();

    let line = dxf::entities::Line::new(
        dxf::Point::new(0.0, 0.0, 0.0),
        dxf::Point::new(25.0, 40.0, 0.0),
    );

    drawing.entities.push(Entity::new(EntityType::Line(line)));

    drawing.save_file("file.dxf")?;

    Ok(())
}

fn main() {
    test().unwrap();
}

Thank you for the bug report!  I don't have a copy of AutoCAD that I can test with but after trying your code I have a theory and I'm hoping you can help me test it.  If you get the opportunity can you do this:

Generate file.dxf exactly like you specified above.
Open file.dxf in a text editor (e.g., Notepad, etc.) and find the line that contains the value $HANDSEED.  There should be only one and my machine generated it at line 402.
Two lines below $HANDSEED, there should be a line that says 1; update this value to 2.
Save the file and try to open it in AutoCAD.

E.g., change this:
$HANDSEED
  5
1

to this:
$HANDSEED
  5
2

If you're curious, the $HANDSEED header variable is supposed to be the next available handle, but this is incorrect because the LINE entity specifies a handle of 1 on line 604 so the proper value of the next handle is actually 2.

Thank you for testing.  I'll start working on a fix.

Apologies for taking so long to get back to the initial issue.  I just pushed a change to master that correctly writes the $HANDSEED header variable.


Imagen.Line doesn't always reach the edge

Try looking at this pattern:
imagen.Line(thickness=0.1, xdensity=9, ydensity=9, smoothing=0, orientation=55*np.pi/120)[:]

The line doesn't reach the edge! And here is the raw array:
array([[ 0.,  0.,  0.,  0.,  0., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0.,  1., -0., -0., -0., -0.],
       [ 0.,  0.,  0.,  0., -0., -0., -0., -0., -0.]])

I don't think this issue is to do with reaching the edge, but with falling between the cracks between locations in the pixel grid.  E.g. try changing the 55 to 54, and you should see a gap at a different location, not the edge.
The underlying cause is just that the line thickness you specified is smaller than the distance between grid cell centers, in some directions in the Cartesian grid (though not in the vertical or horizontal directions), and thus in those positions on the grid, the line covers neither the grid cell to the left nor the grid cell to the right, and thus neither is turned on.  See https://github.com/ioam/imagen/pull/23 for more explanation.
If you want to keep to the strict definition that grid cells are turned on if and only iff the center of the grid cell is within the specified line thickness (which is true by default), you can either increase your line thickness or increase your density, as you wish.
Otherwise, you can set enforce_minimal_thickness=True to ensure that there are never any gaps, but it's not on by default, for backwards compatibility and because it deviates from the strict definition of how the line function should be evaluated on a grid.

Ok. That explanation makes sense but I did find it rather odd that one one frame had this issue out of the animation I was looking at (a rotating line). All the other frames reached the edge for the orientations I used.
Good to know about the enforce_minimal_thickness parameter though.

Just luck and geometry.  You should get no line at all in the worst case, e.g. a vertical line falling entirely between the centers:
imagen.Line(thickness=0.1, xdensity=9, ydensity=9, smoothing=0, orientation=np.pi/2,x=0.06)()


Rename auto traits feature

At present, ed doesn't compile with Rust nightly because the optin_builtin_traits feature has been renamed to auto_traits. This PR fixes that.
Minor formatting changes are due to rustfmt.

Thanks @thanethomson, sorry for never getting around to merging this. Looks like we already renamed the feature at some point but I'll merge this because it also fixes some trailing whitespace :)


LOG Error: get current Channel and Name error: Error: timeout

Hey Together,
my log is spammed with following error.
I hava a LG OLED55CX. I'am using HOOBS. The Homekit integration works fine but I would like to get rid of these Errors.
25.11.2020, 09:43:20 [LgWebOsTv] Device: <IP_ADDRESS> LG TV Channels, get current Channel and Name error: Error: timeout
    at Timeout._onTimeout (/home/hoobs/.hoobs/node_modules/lgtv2/index.js:228:32)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7).

{
            "platform": "LgWebOsTv",
            "plugin_map": {
                "plugin_name": "homebridge-lgwebos-tv"
            },
            "devices": [
                {
                    "name": "LG TV Channels",
                    "host": "<IP_ADDRESS>",
                    "mac": "58:FD:B1:7F:D6:90",
                    "switchInfoMenu": false,
                    "inputs": [
                        {
                            "name": "YouTube",
                            "reference": "youtube.leanback.v4",
                            "type": "APPLICATION",
                            "mode": 0
                        },
                        {
                            "name": "XBox",
                            "reference": "com.webos.app.hdmi1",
                            "type": "HDMI",
                            "mode": 0
                        },
                        {
                            "name": "Disney Plus",
                            "reference": "com.disney.disneyplus-prod",
                            "type": "TUNER",
                            "mode": 0
                        },
                        {
                            "name": "HDMI 2",
                            "reference": "com.webos.app.hdmi2",
                            "type": "HDMI",
                            "mode": 0
                        },
                        {
                            "name": "Netflix",
                            "reference": "netflix",
                            "type": "APPLICATION",
                            "mode": 0
                        },
                        {
                            "name": "Amazon Prime",
                            "reference": "amazon",
                            "type": "APPLICATION",
                            "mode": 0
                        },
                        {
                            "name": "Apple TV",
                            "reference": "com.apple.appletv",
                            "type": "APPLICATION",
                            "mode": 0
                        }
                    ],
                    "manufacturer": "Manufacturer",
                    "modelName": "Model",
                    "serialNumber": "58:fd:b1:7f:d6:90",
                    "firmwareRevision": "11.25"
                }
            ]
        },

Hi,
you are using the other plugin which is a rip off of this one.
You should switch to this plugin or open the issue on the other repo.

Thank you very much. Switched to your version and no more problems what so ever. Amazing how fast you responded and how well this implementation works


Why is docker image "latest" aligned with the latest tag?

Hi,
As for now, on https://quay.io/repository/goswagger/swagger?tab=tags docker image "latest" is aligned with v0.17.0 even though there are newer tags (v0.18.0 for example). Why is it not aligned with latest tag?
Thanks,
Dror

I'd add my plus one here for making latest point to the most recent release.

This is a regression caused by the following change here:

docker push quay.io/goswagger/swagger
became:
docker push quay.io/goswagger/swagger:$CIRCLE_TAG


Update software versions

Updated all software versions to the latest I found. Except nss_wrapper which didn't compile on a first attempt. I've only tested this with python 2.7 and then only as far as reproducing a mod_wsgi problem before raising an issue. (You'll be looking forward to receiving that I'm sure)

This is stale.


Crash when clicking the info icon on a logistic chest in ALS.

Hi,
When I click on that "search icon" in the View column, I get the following crash:
Error while running the event handler: __advanced-logistics-system__/control.lua:638: LuaEntity API call when LuaEntity was invalid.
Running ALS 0.2.2

This seems to trigger because the chest doesn't exist anymore, but it shouldn't since the chests are removed from the internal lists when they are deconstructed or destroyed.
does the chest still exist? is it a normal chest or a modded one?

It happends on any chest I try with. Only normal chests (Logistic chests and steel chests).

Version 0.2.3 fixed the issue


Update to ROTP 6.x

@bsedat Could you take a look at this? We're seeing deprecation warnings in the form of:
ruby/2.7.0/gems/rotp-2.1.2/lib/rotp/totp.rb:56: warning: URI.escape is obsolete

I apologize for kinda bungling the merge, but this landed in v4.0.0. Thank you!


DEV-1061: ADR for DID Resolver

Task linked: DEV-1061 Define architecture for DID resolver (on-ledger) and universal resolver driver (off-ledger)

ADR completed and approved by @ankurdotb .
DO NOT MERGE this PR until the Gitbook issues are fixed!

@Tweeddalex @Toktar Has this been shifted over to the identity-docs repo?

Yes, I have added the latest version to the identity docs repo


flatbuffers: 1.10.0 -> 1.11.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/flatbuffers/versions.
meta.description for flatbuffers is: '"Memory Efficient Serialization Library."'.
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/bin/sh passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 1.11.0 with grep in /nix/store/555lh0clgw4kfiqg04i1k0d6572hdh7w-flatbuffers-1.11.0
directory tree listing: https://gist.github.com/8af79e8caf77088e852d921031787f6e
du listing: https://gist.github.com/a61f89af3b4eadea258b496875cf9902

Rebuild report (if merged into master) (click to expand)

96 total rebuild path(s)
26 package rebuild(s)
26 x86_64-linux rebuild(s)
25 i686-linux rebuild(s)
20 x86_64-darwin rebuild(s)
25 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
arrow-cpp
flatbuffers
kodi
kodi-wayland
kodiPlain
kodiPlainWayland
kodiPlugins.inputstream-adaptive
kodiPlugins.joystick
kodiPlugins.kodi
kodiPlugins.kodi-platform
kodiPlugins.pvr-hdhomerun
kodiPlugins.pvr-hts
kodiPlugins.pvr-iptvsimple
kodiPlugins.steam-controller
kodiPlugins.vfs-libarchive
kodiPlugins.vfs-sftp
python27Packages.awkward
python27Packages.google_cloud_bigquery
python27Packages.pyarrow
python27Packages.uproot
python27Packages.uproot-methods
python37Packages.awkward
python37Packages.google_cloud_bigquery
python37Packages.pyarrow
python37Packages.uproot
python37Packages.uproot-methods

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/555lh0clgw4kfiqg04i1k0d6572hdh7w-flatbuffers-1.11.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A flatbuffers https://github.com/r-ryantm/nixpkgs/archive/ad937778754811d73ab7e6ebe07009a3472adaff.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/555lh0clgw4kfiqg04i1k0d6572hdh7w-flatbuffers-1.11.0
ls -la /nix/store/555lh0clgw4kfiqg04i1k0d6572hdh7w-flatbuffers-1.11.0/bin

cc @teh for testing.

This looks like a pretty big update. No objections in general but would need some testing by other users as well.

Builds on Ubuntu. Reverse dependencies: python27Packages.uproot and python37Packages.uproot fail to build.

cc Kodi maintainers @domenkozar @titanous @edwtjo @peterhoeg @sephalon

@domenkozar any objections to this? Kodi seems to still be on flatbuffers 1.9 (https://github.com/xbmc/xbmc/blob/master/tools/depends/native/flatbuffers/Makefile) but given that 1.10 seems to have worked maybe 1.11 will as well?

Given the changelog in https://github.com/google/flatbuffers/releases it should work

@GrahamcOfBorg build kodi

@GrahamcOfBorg build kodi

@GrahamcOfBorg build kodi


Exclude MultiJobAnalysis jobs from stable release verification jobs

When verifying Stable releases, the release-controller reaches down into the respective release's "nightly" release configuration and runs its Blocking jobs as Informing jobs.  Due to how the MultiJobAnalysis jobs are performed, they are guaranteed to always fail whenever the get run against a Stable releases.
This PR excludes all the MultiJobAnalysis from being added to the Stable release verification all together.

/lgtm


[NOD-830] Remove omitEmpty from TransactionResponse.AcceptingBlockHash

Rebuild after update in master

Rebuild after update in master

Rebuild after update in master

Rebuild after update in master


rubocop: Use Sorbet/StrictSigil as it's better than comments

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Part of https://github.com/Homebrew/brew/issues/17297.
Previously I thought that comments were fine to discourage people from wasting their time trying to bump things that used undef that Sorbet didn't support. But RuboCop is better at this since it'll complain if the comments are unnecessary.
Suggested in https://github.com/Homebrew/brew/pull/18018#issuecomment-2283369501.
I've gone for a mixture of rubocop:disable for the files that can't be typed: strict (use of undef, required before everything else, etc) and rubocop:todo for everything else that should be tried to make strictly typed. There's no functional difference between the two as rubocop:todo is rubocop:disable with a different name.
And I entirely disabled the cop for the docs/ directory since typed: strict isn't going to gain us anything for some Markdown linting config files.

This means that now it's easier to track what needs to be done rather than relying on checklists of files in our big Sorbet issue:

$ git grep 'typed: true # rubocop:todo Sorbet/StrictSigil' | wc -l
    268

And this is confirmed working for new files:

$ git status
On branch use-rubocop-for-sorbet-strict-sigils
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        Library/Homebrew/bad.rb
        Library/Homebrew/good.rb

nothing added to commit but untracked files present (use "git add" to track)

$ brew style
Offenses:

bad.rb:1:1: C: Sorbet/StrictSigil: Sorbet sigil should be at least strict got true.
# typed: true
^^^^^^^^^^^^^

1340 files inspected, 1 offense detected

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"


DOC: typo in /v0.2/docs/integrations/vectorstores/clickhouse/

URL
https://python.langchain.com/v0.2/docs/integrations/vectorstores/clickhouse/
Checklist

[X] I added a very descriptive title to this issue.
[X] I included a link to the documentation page I am referring to (if applicable).

Issue with current documentation:
The cell towards the bottom references AstraDBVectorStore when it should be Clickhouse:
For detailed documentation of all `AstraDBVectorStore` features and configurations head to the API reference:https://python.langchain.com/api_reference/community/vectorstores/langchain_community.vectorstores.clickhouse.Clickhouse.html

Idea or request for content:
Change AstraDBVectorStore to Clickhouse

shouldn't this Issue be closed due to #26598?


Add Web Demo & Docker environment

Hey @yoyo-nb ! 👋
This pull request makes it possible to run your model inside a Docker environment, which makes it easier for other people to run it.  We're using an open source tool called Cog to make this process easier.
This also means we can make a web page where other people can try out your model! View it here: https://replicate.com/yoyo-nb/thin-plate-spline-motion-model. The docker file can be found under the tab ‘run model with docker’.
Do claim the page so you can own the page, customise the Example gallery as you like, push any future update to the web demo, and we'll feature it on our website and tweet about it too. You can find the 'Claim this model' button on the top of the page ~ When the page is claimed, it will be automatically linked to the arXiv website as well (under “Demos”).
In case you're wondering who I am, I'm from Replicate, where we're trying to make machine learning reproducible. We got frustrated that we couldn't run all the really interesting ML work being done. So, we're going round implementing models we like. 😊

Hi, thanks for your contribution.
However, I encountered an error when using cog build -t test to build:
File "predict.py", line 19, in <module>
     from ffhq_dataset.face_alignment import image_align
ModuleNotFoundError: No module named 'ffhq_dataset'

Failed to get type signature: exit status 1

Maybe you should add .py code or add dependencies in cog.yaml?


Add support for big endian in function endpoint_attribute_list

The function endpoint_attribute_list should support the generation of default values for big endian systems.
The rationale is that the current generated values are only working in little endian systems.
See also:
https://github.com/project-chip/connectedhomeip/pull/6175

@pjzander-signify : if you're happy with your fix, please close this issue.


Add export & apply policy commands to cli readme

Purpose

Apply cli readme file content for apply and export policy commands.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #511   +/-   ##
=======================================
  Coverage   64.45%   64.45%
=======================================
  Files          34       34
  Lines        1176     1176
  Branches       98       98
=======================================
  Hits          758      758
  Misses        365      365
  Partials       53       53

Continue to review full report at Codecov.

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


Add :vars to options to allow variables to be specified

Because this requires string->json-node to be defined before new-scope, the function gets moved down a bit.

Is 15f683d more like what you had in mind?

Is 15f683d more like what you had in mind?

Yes, looks great!


Add ibmcloud provisoner self-managed cluster for e2e test

This will extend https://github.com/confidential-containers/cloud-api-adaptor/issues/490 to support self-managed cluster in IBM Cloud, besides IKS managed cluster.

[ ] Self-Managed Cluster

[ ] VSI
[ ]  K8s Cluster

This isn't high priority, as we can use terraform to create clusters, so closing this.


Fix Configuration regarding new changes

Jira issue:
https://glia.atlassian.net/browse/MOB-1684
Additional info:
Changes based on - https://github.com/salemove/mobile-sdk-unified/pull/19
MOB 1684

!squash

!squash

!squash


Assignment 2

What changes are you trying to make?
I am including code and comments needed to complete assignment_2.
What did you learn from the changes you have made?
I learned how to create an empty numpy array of a specified dimension and how to check the shape of the array.  I also learned how to use os and the 'join' method to add files to a specified path, and loop through files to create a list. Additionaly, I learned that I could use 'r' in front of a file path to make it readable in Python, so as not to have to adjust the backslashes.
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
I had tried to use the all_paths list of files provided in the assignment, but realized that my working directory was not the same relative to the files given and I had to use the full path name.
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
I had to spend some time understanding how to create an empty array for the ouput of the patient_summary function. I looked in the notes and in the numpy manual.
How were these changes tested?
I printed the output of the first file. I tested the patient_summary function by checking the max, min and mean values and confirming the answers for one line of the data. I tested the shape of the output of the patient_summary function. Lastly, I tested the 'detect_problems" function on the first file to make sure the output was as expected.
A reference to a related issue in your repository (if applicable)
Checklist

[ X] I can confirm that my changes are working as intended

I realized after submission, that I could have simplified my code by using the numpy operations:
patient_array.mean(axis=1)
patient_array.min(axis=1)
patient_array.max(axis=1)
to find the mean, minimum, and maximum for each patient.


Fix deprecated ternary usage

This fixes the deprecated ternary usage in Credentials.php, which causes issues running this on recent PHP versions.
Fixes #26

@lyubo-slavilov Are there any plans to merge this soon?

Hi there,
I will take care of it tomorrow.
On Tue, Jun 1, 2021, 15:03 bastiaansenglenn @.***>
wrote:

@lyubo-slavilov https://github.com/lyubo-slavilov Are there any plans
to merge this soon?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/double-break/spapi-php/pull/29#issuecomment-852068637,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEGJUIUTKHLJX6YMWQ4EJ3TQTEBFANCNFSM43IU454A
.


Unable to location .toc files

Hello,
The workflow is unable to locate my .toc files. I even tried working directories as well.
Repo Link
Workflow Link

Don't change the working directory to src/, your toc files aren't in there.


Objects being destroyed while touching the camera will cause a permanent black screen.

Hello, the issue here is that if I have enemies who fire rockets, balls or items at the player's head and the items are set to be destroyed upon collision, the onTriggerExit in VRTK_HeadsetCollisionFade.cs event will not be called.
This results in the screen becoming permanently black (my current fade colour).
I have made a simple and cheap solution: move the items to Vector3.zero then delete them, but I thought it would be a good addition to VRTK itself to have "black-screen due to objects being deleted in-camera" prevention built in, as it could occur in random or unpredictable instances (such as a player having their head accidentally in a prop they shouldn't be in that's about to be destroyed).

I would have thought the OnTriggerExit would have been called when the object was destroyed. I'll look into it and see what's going on.

Fixed with https://github.com/thestonefox/SteamVR_Unity_Toolkit/commit/49bc483cb1b75efe436cc60d54c1c6f4c694cc1a
Sorry for the delay


plenty to read at what?

It’s not quite so simple. Others have already documented the value of monorepos (plenty to read at ).

Plenty to read at what? Is something missed?

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

ID: b96a80c2-e52c-85b6-d472-ced16f9154a2
Version Independent ID: f721244d-2d89-8fce-4db6-ab0b6db25225
Content: Git Virtual File System Design History - Azure DevOps
Content Source: docs/git/gvfs-design-history.md
Product: devops
Technology: devops-learn
GitHub Login: @SamGu
Microsoft Alias: sanoursa

@cblp  Thank you for the feedback.
The documentation has been updated and is pending review.


Memory leaks backend

Describe the bug
Since the release 2024.5.1 we are facing memory leaks on production.
https://github.com/digitalfabrik/entitlementcard/releases/tag/2024.5.1-all
Rollout of the update on production: 2024-06-07 - 11am
It may be related to the javalin update, but its not clear what causes this issue
Currently the backend service will be restarted (scheduled) every 12h as a workaround.
To Reproduce
Steps to reproduce the behavior:

Go to grafana and check increasing memory usage
Also check the server logs if you can find something

Expected behavior
Memory usage is not constantly increasing
Screenshots

Additional context
We already tried to fix it by a possible issue with jetty (used by javalin) but it seems like it didn't fix the issue
https://github.com/digitalfabrik/entitlementcard/pull/1510
Check directly grafana here:
https://grafana.tuerantuer.org/d/l3Gr9b5Vk/server-vitals-with-host-selection?orgId=1&refresh=5m&var-HOST=entitlementcard.tuerantuer.org&viewPanel=8&from=now-24h&to=now

I could only find this jetty issue https://github.com/jetty/jetty.project/pull/11782
Is that the one you mean?

I plan on using this profiler: https://www.yourkit.com/docs/java-profiler/latest/help/remote_profiling.jsp


Resolve incorrect generation of meta count when there are remote branches

Added a failing test which https://github.com/MeirionHughes/GitVersion/commit/f61179cbd95fde509ab4d018dbae332cc8b40850 will fix.


Use EIP-4906 for NFT metadata updates

EIP-4906: EIP-721 Metadata Update Extension

This needs a solidity interface. @OpenZeppelin/contracts does not provide it yet (as of 4.8.1)


Periodic Bad Gateways

ATN (well Cloudflare in this case) will display a 502 Bad Gateway with the host failing. This is probably caused by requests taking too long, and a refresh tends to clear it up.
It can be tricky to reproduce though. I've had it happen on search results, and extension details pages.

This happens frequently for me when attempting to visit ATN:

It also seems to be the source of the errors in: https://github.com/thunderbird/thunderbird.github.io/pull/3#issuecomment-1540168654

These should be a lot better since we've made some adjustments to the infrastructure. It's still going to happen sometimes with any queries that are particularly slow.
Any API calling should be error tolerant and have retries with exponential backoff, of course.


grpc library keeps retrying openssl connection, even though client received certificate expired message from server.

What version of gRPC and what language are you using?
v1.24, go
What operating system (Linux, Windows,...) and version?
yocto
What runtime / compiler are you using (e.g. python version or version of gcc)
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39.0.3)
What did you do?
I used go gnmi client, which uses grpc library. The gnmi client tries to establish TLS connection with grpc server, grpc server replies with "Certificate Expired". The gnmi client keeps sending Client Hello, after receiving "Certificate Expired" message.
What did you expect to see?
gnmi client should not retry after receiving "Certificate Expired" message.
What did you see instead?
gnmi client keeps retrying(sending client hello)
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).
pcap attached.
ha.txt
Anything else we should know about your project / environment?
Opened a jira against openssl. Here is the link
https://github.com/openssl/openssl/issues/12552

Any update?

This issue does not point out any actual problems. If there is a real problem, please explain, ideally in the form of a reproducibly failing test case. Otherwise, this would appear to be working as intended.
So closing because this seems like a question rather than a bug.
For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc
For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io

When you receive SSL error message from the server such as certificate expired, the gnmi client which uses grpc library, should not send client hello again. Since the error messages are final. Whats the use of retrying(sending client hello again)?
On Wednesday, August 12, 2020, 12:37:12 PM PDT, apolcyn<EMAIL_ADDRESS>wrote:

This issue does not point out any actual problems. If there is a real problem, please explain, ideally in the form of a reproducibly failing test case. Otherwise, this would appear to be working as intended.
So closing because this seems like a question rather than a bug.
For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc
For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

For one, it's not clear that the error is final -- what guarantees that the second connect attempt will go to the same exact server and so result in the exact same error, for example?

Thank you so much for your reply. Your answer makes sense.
On Wednesday, August 12, 2020, 03:20:04 PM PDT, apolcyn<EMAIL_ADDRESS>wrote:
For one, it's not clear that the error is final -- what guarantees that the second connect attempt will go to the same exact server and so result in the exact same error, for example?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


API is down

Hello, the API has been down for 2 days, and I can't access it.
Is there any update on the status of the API or when it will be back online?
Thank you.

Fixed


Add len() to InMemoryWriteableCursor

Which issue does this PR close?
Resolves the https://github.com/delta-io/kafka-delta-ingest/issues/38
Rationale for this change
There's no efficient way to get buffer length unless copying the data via .data() func. These changes provide easy and safe way top achieve that.
What changes are included in this PR?
Basically the same impl as in .data(), but once we've got the ref then the len() on the underlying is called instead of copying the bytes.
Are there any user-facing changes?
new pub api (?).

Thanks @mosyp

@mosyp  it appears clippy has a problem !
https://github.com/apache/arrow-rs/pull/564/checks?check_run_id=3107500562
Can you please fix the error?
warning: build failed, waiting for other jobs to finish...
error: struct `InMemoryWriteableCursor` has a public `len` method, but no `is_empty` method
   --> parquet/src/util/cursor.rs:159:5
    |
159 |     pub fn len(&self) -> usize {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `-D clippy::len-without-is-empty` implied by `-D warnings`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#len_without_is_empty

error: aborting due to previous error

Codecov Report

Merging #564 (c441d0d) into master (f873d77) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #564      +/-   ##
==========================================
- Coverage   82.47%   82.47%   -0.01%
==========================================
  Files         167      167
  Lines       46144    46147       +3
==========================================
  Hits        38059    38059
- Misses       8085     8088       +3

Impacted Files
Coverage Δ

parquet/src/util/cursor.rs
81.03% <0.00%> (-2.16%)
:arrow_down:

Continue to review full report at Codecov.

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

Thanks @alamb. I've added the is_empty() to make clippy happy

Thanks @mosyp !


Unity+IOS+Plugin VuFORIA === problema

I am encountering an error while using the vuforia plugin in Unity. Simply when using the vuforia plugin, the branch does not get me any console. It is noted that when using on the android platform. I did not get problems, only in IOS. I need to use deeplinks but I do not get any info when I use the vuforia plugin (Augmented Reality)

Hi @lucasunity , I think Vuforia uses custom AppController.
You can read our readme.md to understand how you can solve that issue.
Also, in folder ThirdPartySolutions/CardboardSDK_ios you can see changed files to solve that issue between Branch SDK and Cardboard SDK.

@lucasunity one more possible trouble - you didn't tap button "update ios wrapper" and your key was not added to ios wrapper. Check please.

Yes
I clicked on update ios wrapper, problems persist

@lucasunity try please our solution for solving ios troubles between plugins.

I tested ThirdPartySolutions / CardboardSDK_ with the vuforia and continue to encounter problems. (I did update the wrapper). I did other tests, I created another blank project, I imported the branch.io project and I imported the Vuforia plugin. again. Replaces the files in ThirdPartySolutions / CardboardSDK_ and not the same problem.

The problem only happens for IOs, in android works perfectly

Hi @lucasunity , sorry for delay.
I don't understand why you use Cardboard solution for Vuforia.
Look please, that is our step-by-step solution:
https://github.com/BranchMetrics/unity-branch-deep-linking#several-impl_app_controller_subclass
That is solution for Cardboard and you can use that solution like an example "how to solve troubles with several AppController classes", you should not use Cardboard solution for Vuforia. That is just example in your case:
https://github.com/BranchMetrics/unity-branch-deep-linking/tree/master/ThirdPartySolutions/CardboardSDK_ios

That's what I needed. The problem really was the conflict between the App controller. Thank you very much for the help

@lucasunity, I glad to hear!
Good luck!

@antonargunov I solved my problem too!
Thank you

@carlosfarinhas , thank you for your report!


Usage with consul-template

Hi and thanks for the interesting tool.
Have I understood the use case correctly,

I would use approle-login tool output vault-token into file
Then use this token file together with consul-template to render secrets into templates?

Hi @kakoni,
Yes, you can use approle-login to login using the approle method and then use the obtained token with other tools as consul-template.
For some cases you can use pouch directly for everything, it runs as a daemon and it can login using the approle method (or use an existing token) and automatically renovate the token if needed. It can obtain secrets from vault and use them with templates to render configuration files. If secrets expire, 'pouch` also takes care of renovating them and update the files. It also allows to trigger notifications when files change, what can be used for example to restart services.


Boots with devtools open

And the normal COMMAND+OPTION+J does not close them

Derp. Just need to recomment in main.js


Improve Google PageSpeed Score

These insights show some things we can improve upon.  If you run the test twice, you'll see that we do improve quite a bit due to caching: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fschoolofsustainability.asu.edu

This should be in the Web Standards Theme!
Closing! And moving!


reformat dictionary

What
Reformat dictionary.js so that each word occurs on its own line.
Motivation
Having the entire dictionary on a single line causes some developer headaches:

git (and GitHub) don't produce a useful diff, which makes it hard to view historic changes
It's hard to manipulate the words in the file using sed/awk/grep because they all work on a per-line basis

Safety
The file still parses correctly according to node.
% node dictionary.js
% echo $?
0

File size
According to @canadianveggie the file was originally formatted with all words on a single line to reduce the download size and make the game load faster. But if HTTP compression is enabled with gzip, the difference is negligible:

Raw size: 12% larger (382 KiB vs. 341 KiB)
GZIP size: 1% larger (112.3 KiB vs. 111.5 KiB)

Before
% git log -n1 --pretty=oneline dictionary.js
074e038551720c2156d69aced3486dceeb24ae2e (HEAD, upstream/main, origin/main, origin/HEAD, main) Remove bad words (#52)

% ls -l dictionary.js
-rw-r--r--  1 nicwaller  staff  349210 20 Feb 09:34 dictionary.js

% gzip dictionary.js
% ls -l dictionary.js.gz
-rw-r--r--  1 nicwaller  staff  114179 20 Feb 09:34 dictionary.js.gz

After
% git log -n1 --pretty=oneline dictionary.js
cb739307a021e1b12d78105ff93361a1761daf63 (HEAD -> dictionary-format, origin/dictionary-format) reformat dictionary

% ls -l dictionary.js
-rw-r--r--  1 nicwaller  staff  390675 20 Feb 09:25 dictionary.js

% gzip dictionary.js
% ls -l dictionary.js.gz
-rw-r--r--  1 nicwaller  staff  115039 20 Feb 09:25 dictionary.js.gz

I just noticed @canadianveggie already did this in<PHONE_NUMBER>777f1d4eecd7e57457cdd1caf74dc3. I was literally minutes behind. 🙃


miniflux: 2.0.31 -> 2.0.32

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/miniflux/miniflux/releases.
meta.description for miniflux is: "Minimalist and opinionated feed reader"
meta.homepage for miniflux is: "https://miniflux.app/"
meta.changelog for miniflux is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32/bin/miniflux passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 2.0.32 with grep in /nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32

found 2.0.32 in filename of file in /nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32

directory tree listing: https://gist.github.com/aa43780e7faa79e1340f1bd890e6b211

du listing: https://gist.github.com/f27741c24bf6759118a6cf5517dc2ab6

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
miniflux

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A miniflux https://github.com/r-ryantm/nixpkgs/archive/5f8c724f3b3251eae3f0399c193c02e7cd802918.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32
ls -la /nix/store/9bp22w347x3m770fvg5z8qh0dxgijsqw-miniflux-2.0.32/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

miniflux

Maintainer pings
cc @rvolosatovs @benpye @kalbasit for testing.

Result of nixpkgs-review pr 134417 at 5f8c724f run on x86_64-linux 1

1 package built successfully:

miniflux

1 suggestion:

warning: missing-phase-hooks
checkPhase should probably contain runHook preCheck and runHook postCheck.
Near pkgs/development/go-modules/generic/default.nix:233:5:
    |
233 |     checkPhase = args.checkPhase or ''
    |     ^

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

1 package failed to build:

miniflux


Leave transitions are broken on child routes

Version
v2.10.2
Reproduction link
https://codesandbox.io/s/github/matteo-rigon/nuxt-child-routes-transiton
Steps to reproduce

1 Create a routing structure that contains a child route, for example:

pages/
    index/
        child.vue
    index.vue

2 In the child.vue component add transition listeners to log the transition status

export default {
    transition: {
        beforeEnter: () => console.log('before enter child'),
        beforeLeave: () => console.log('before leave child'),
    }
}

3 Navigate between parent route and child route adding some <nuxt-link> components

What is expected ?
I expect to see a console log with before enter child when entering the child route, and a console log with before leave child when exiting the child route.
What is actually happening?
before enter child is logged, but when exiting the child route nothing is logged.
This breaks the "leave" phase of the transition.
Additional comments?
I've dug around the source code and found out what is causing this behaviour.
In https://github.com/nuxt/nuxt.js/blob/dev/packages/vue-app/template/client.js#L116
// Combine transitions & prefer `leave` transitions of 'from' route
if (from && from.matched.length && from.matched[0].components.default) {
      const fromTransitions = componentTransitions(from.matched[0].components.default)
     ....
}

Usually from.matched[0] is the right route record mapping to the component that is being destroyed, however in the case of child routes Vue Router always matches 2 components,

the first is a route record that maps to a copy of the parent component without any transition property

{
  path: ""
  regex: /^(?:\/(?=$))?$/i
  components: {default: ƒ}
  instances: {default: VueComponent}
  name: "index"
  parent: undefined
  matchAs: undefined
  redirect: undefined
  beforeEnter: undefined
  meta: {}
  props: {}
}

the second is a route record with the child component that is being destroyed

{
  path: "/child"
  regex: /^\/child(?:\/(?=$))?$/i
  components: {default: ƒ}
  instances: {default: undefined}
  name: "index-child"
  parent: {path: "", regex: /^(?:\/(?=$))?$/i, components: {…}, instances: {…}, name: "index", …}
  matchAs: undefined
  redirect: undefined
  beforeEnter: undefined
  meta: {}
  props: {}
}

So when retrieving transition data upon leaving child routes,  from.matched[0].components.default should actually be from.matched[1].components.default , however i don't know what would be the best way to detect this particular case.

This bug report is available on Nuxt community (#c10122)

I've created a quick sandbox with an equivalent app created with Vue CLI and the leave transition is logged correctly.
https://codesandbox.io/s/vue-cli-child-routes-transitions-cirwp


gulp 4, lodash 4.17

This PR will move gulp to version 4 and uses latest lodash.

Thank you for taking time to submit this - please accept my apologies for being radio silent for 2 years! 😱 😭
I fixed the lodash dep in v2.0.6. I'm planning to remove gulp from the repo once I have some time to get v3 squared away. I'm going to close this PR for now - but if v3 takes longer than I hope, I may pull in the gulp update as a transient step.