Qvis - downloadable

I use https://qvis.edm.uhasselt.be/#/files to visualize qlogs. At times the qlogs are more than 100MB and it seems pretty slow to navigate through. Is there a way to have qvis tool installed on the machine. I also notice that QUICvis is deprecated. Any suggestions please?

Hey Samy,
Thank you for using qvis!
Currently we don't have an official standalone build, since this would lack support for loading pcap files (as we rely on wireshark to do the conversion, which requires more work). However, @lpardue has recently been tinkering with an electron-based setup that seems to work for the basic usecase of visualizing qlog files directly, see https://github.com/LPardue/qvis/releases/tag/qvis-app-rc1. Maybe you can beta-test that?
However, I'm not sure that will be much faster than loading the files in the browser, since Electron still uses the browser's engines to render the visualizations. While qvis' JavaScript approach is slower than other languages might be, it should still be quite usable even for large files (I've tested files of several 100 MBs myself). Would you be able to somehow share some more details (potentially even an example file?) of what exactly is slow so I can try to reproduce/optimize? Also do let us know if the standalone build is faster for you!
Finally, QUICvis  is indeed deprecated, but this was the "old" project on which qvis is based. qvis itself is very much alive and well and planned to continue for quite some time to come. You can just keep using the URL you mention or the code in this repository for that. I hope that's clear.
If you have any more questions, please let us know!
With best regards,
Robin

Hello Robin,
I am experiencing the same issues, however with the standard 31 MB demo file.
Loading it is certainly possible but switching between the different tools, using the zoom function to view packet details and other actions slow down the web browser so much that these actions are delayed by 10 seconds or more. Tools especially affected are the sequence, multiplexing and packetization tools.
Both the multiplexing and packetization tools share a performance issue concerning zoom. The packetization tool also takes about the same time to initially load as the sequence tool. The congestion tool is the quickest to respond of all tools, the zoom works without delay.
I tried all this in Firefox.
In Chromium, delays still happen but are certainly shorter. However, after zooming in and out a few times (and zooming while the zoom action has not yet been performed) in the packetization tool, I manage to make the site crash consistently with the error code SIGTRAP. In Firefox, it simply takes very long for the zooms to happen.
As I am a CS student and currently writing a paper on qlog, qvis and their capabilities, I am interested if a native application, multi-threading or other solutions are planned for better performance with larger qlogs?
I also tried to test the electron application but it could not find a package.json file in the extracted directory and failed. The warning first appeared after running vue add electron-builder.
Thank you and best regards,
Dominik

Hello Robin,
I am experiencing the same issues, however with the standard 31 MB demo file.
Loading it is certainly possible but switching between the different tools, using the zoom function to view packet details and other actions slow down the web browser so much that these actions are delayed by 10 seconds or more. Tools especially affected are the sequence, multiplexing and packetization tools.
Both the multiplexing and packetization tools share a performance issue concerning zoom. The packetization tool also takes about the same time to initially load as the sequence tool. The congestion tool is the quickest to respond of all tools, the zoom works without delay.
I tried all this in Firefox.
In Chromium, delays still happen but are certainly shorter. However, after zooming in and out a few times (and zooming while the zoom action has not yet been performed) in the packetization tool, I manage to make the site crash consistently with the error code SIGTRAP. In Firefox, it simply takes very long for the zooms to happen.
As I am a CS student and currently writing a paper on qlog, qvis and their capabilities, I am interested if a native application, multi-threading or other solutions are planned for better performance with larger qlogs?
I also tried to test the electron application but it could not find a package.json file in the extracted directory and failed. The warning first appeared after running vue add electron-builder.
Thank you and best regards,
Dominik

if you're building your own electron application, make sure you run vue add electron-builder in the right directory. I think this is at /visualizations

if you're building your own electron application, make sure you run vue add electron-builder in the right directory. I think this is at /visualizations

@toasthorse Thanks a lot for the detailed explanation. Also happy to hear you're writing something on the tools, would love to read that when it's done.
I have only ever used Chromium on Windows when developing and testing the tools, so it's not really a big surprise that things don't work as well in Firefox. I also don't have concrete plans to go in and optimize for other browsers at this point.
I am a bit surprised about the crash in Chromium. Can you confirm the steps to reproduce are: a) load the 31 MB demo file b) open it in the packetization tool c) zoom in/out 5+ times? Could you also say which OS+version you're using (I'd assume linux or OSX?)? Here, the 31MB file is indeed slow in the packetization view, but doesn't crash.
In general, it is expected that the performance of the tools will suffer with (very) large files. This is partly because most tools utilize SVG rendering, drawing each packet/frame as a separate SVG entity, which is slow. The only way to work around that is to use canvas-based rendering, which is what the congestion graph currently does. This however makes it much more difficult to implement picking/hover effects (the congestion graph can be somewhat buggy on that point), which is why we've gone with the SVG approach for the other tools at the moment to get a Proof-of-Concept that works in most cases for now. For the future, the goal is to port the other tools to the canvas-based method as well.
The one exception is the sequence diagram, which uses SVG rendering but doesn't draw the entire trace, but only the currently visible part + a little bit before and after that. As such, I was surprised to hear the sequence diagram is also slow in chromium on large traces for you. It can be slow loading the initial trace, but should be very smooth interacting after that. Could you give a bit more information on what you're seeing there?
However, even with the canvas method, it's still browser-based, which will probably never scale to very large logs (e.g., 500MB+). It's also not possible (afaik) to (easily) make that multi-threaded in things like electron. For this, we have plans to write qlog importers for other native tools (like Windows Performance Analyzer).  Porting qvis to native code is also an option, but that would likely have to come from the community (i.e.,: not me ;) )
Finally: have you tried the pre-built electron .exe from the link I provided above instead of building it yourself (assuming you have access to a Windows machine)? What performance does that give you?
Please let us know any other things you find. Feel free to open new issues here. Don't assume this is all highly polished or tested code ;) The goal is to make it better over time, so hearing concrete experiences from users only helps with that.
Best of luck with the paper!
Robin

@toasthorse Thanks a lot for the detailed explanation. Also happy to hear you're writing something on the tools, would love to read that when it's done.
I have only ever used Chromium on Windows when developing and testing the tools, so it's not really a big surprise that things don't work as well in Firefox. I also don't have concrete plans to go in and optimize for other browsers at this point.
I am a bit surprised about the crash in Chromium. Can you confirm the steps to reproduce are: a) load the 31 MB demo file b) open it in the packetization tool c) zoom in/out 5+ times? Could you also say which OS+version you're using (I'd assume linux or OSX?)? Here, the 31MB file is indeed slow in the packetization view, but doesn't crash.
In general, it is expected that the performance of the tools will suffer with (very) large files. This is partly because most tools utilize SVG rendering, drawing each packet/frame as a separate SVG entity, which is slow. The only way to work around that is to use canvas-based rendering, which is what the congestion graph currently does. This however makes it much more difficult to implement picking/hover effects (the congestion graph can be somewhat buggy on that point), which is why we've gone with the SVG approach for the other tools at the moment to get a Proof-of-Concept that works in most cases for now. For the future, the goal is to port the other tools to the canvas-based method as well.
The one exception is the sequence diagram, which uses SVG rendering but doesn't draw the entire trace, but only the currently visible part + a little bit before and after that. As such, I was surprised to hear the sequence diagram is also slow in chromium on large traces for you. It can be slow loading the initial trace, but should be very smooth interacting after that. Could you give a bit more information on what you're seeing there?
However, even with the canvas method, it's still browser-based, which will probably never scale to very large logs (e.g., 500MB+). It's also not possible (afaik) to (easily) make that multi-threaded in things like electron. For this, we have plans to write qlog importers for other native tools (like Windows Performance Analyzer).  Porting qvis to native code is also an option, but that would likely have to come from the community (i.e.,: not me ;) )
Finally: have you tried the pre-built electron .exe from the link I provided above instead of building it yourself (assuming you have access to a Windows machine)? What performance does that give you?
Please let us know any other things you find. Feel free to open new issues here. Don't assume this is all highly polished or tested code ;) The goal is to make it better over time, so hearing concrete experiences from users only helps with that.
Best of luck with the paper!
Robin

@rmarx
Yes, this is how I produced the crash in Chromium. I am running Arch Linux 5.10.4. However I think that this might be exclusive to Linux, I could not reproduce it on Windows 8 (I currently don't have access to a Windows 10 machine).
Regarding the sequence diagram, I should have been a bit more clear; it only takes a while to load, but it is indeed smooth after loading it :)
I tried the pre-built electron .exe on Windows 8 and I could only load the small demo files, but not the 31 MB one. Only the blue banner appears, but not the green one to confirm that it has been loaded; when clicking on the different tools, it only says "Loading files...". In Chromium, Google Chrome and Firefox on Windows 8 I can load it without a problem.
Thank you for the explanations regarding the implementation of the tools and future plans! I will make sure to let you know if I find anything else.
@LPardue
Thank you, running it in the /visualizations directory worked! However it did not compile, there seems to be an error in the implementation:
ERROR in /home/dominik/downloads/qvis/qvis-qvis-app-rc1/visualizations/src/components/sequencediagram/renderer/SequenceDiagramD3Renderer.ts
366:12 Type 'Timeout' is not assignable to type 'number'.
    364 |
    365 |            clearTimeout( scrollTimer );
  > 366 |            scrollTimer = setTimeout( execute, 250 ); // 250 ms
        |            ^
    367 |
    368 |            ++scrollEventCount;
    369 |            if ( scrollEventCount % 5 === 0 ){ // 5 = magic number, from experimental experience in chrome, very scientific

 ERROR  Vue CLI build failed. Please resolve any issues with your build and try again.

@rmarx
Yes, this is how I produced the crash in Chromium. I am running Arch Linux 5.10.4. However I think that this might be exclusive to Linux, I could not reproduce it on Windows 8 (I currently don't have access to a Windows 10 machine).
Regarding the sequence diagram, I should have been a bit more clear; it only takes a while to load, but it is indeed smooth after loading it :)
I tried the pre-built electron .exe on Windows 8 and I could only load the small demo files, but not the 31 MB one. Only the blue banner appears, but not the green one to confirm that it has been loaded; when clicking on the different tools, it only says "Loading files...". In Chromium, Google Chrome and Firefox on Windows 8 I can load it without a problem.
Thank you for the explanations regarding the implementation of the tools and future plans! I will make sure to let you know if I find anything else.
@LPardue
Thank you, running it in the /visualizations directory worked! However it did not compile, there seems to be an error in the implementation:
ERROR in /home/dominik/downloads/qvis/qvis-qvis-app-rc1/visualizations/src/components/sequencediagram/renderer/SequenceDiagramD3Renderer.ts
366:12 Type 'Timeout' is not assignable to type 'number'.
    364 |
    365 |            clearTimeout( scrollTimer );
  > 366 |            scrollTimer = setTimeout( execute, 250 ); // 250 ms
        |            ^
    367 |
    368 |            ++scrollEventCount;
    369 |            if ( scrollEventCount % 5 === 0 ){ // 5 = magic number, from experimental experience in chrome, very scientific

 ERROR  Vue CLI build failed. Please resolve any issues with your build and try again.

Ah yes, I think this is fixable by a very small tweak. I don't have the
exact code available to me right now but see this comment that I think
inspired me:
https://github.com/microsoft/TypeScript/issues/842#issuecomment-252445883
On Wed, Jan 6, 2021 at 5:08 PM toasthorse<EMAIL_ADDRESS>wrote:

@rmarx https://github.com/rmarx
Yes, this is how I produced the crash in Chromium. I am running Arch Linux
5.10.4. However I think that this might be exclusive to Linux, I could not
reproduce it on Windows 8 (I currently don't have access to a Windows 10
machine).
Regarding the sequence diagram, I should have been a bit more clear; it
only takes a while to load, but it is indeed smooth after loading it :)
I tried the pre-built electron .exe on Windows 8 and I could only load the
small demo files, but not the 31 MB one. Only the blue banner appears, but
not the green one to confirm that it has been loaded; when clicking on the
different tools, it only says "Loading files...". In Chromium, Google
Chrome and Firefox on Windows 8 I can load it without a problem.
Thank you for the explanations regarding the implementation of the tools
and future plans! I will make sure to let you know if I find anything else.
@LPardue https://github.com/LPardue
Thank you, running it in the /visualizations directory worked! However it
did not compile, there seems to be an error in the implementation:
ERROR in /home/dominik/downloads/qvis/qvis-qvis-app-rc1/visualizations/src/components/sequencediagram/renderer/SequenceDiagramD3Renderer.ts
366:12 Type 'Timeout' is not assignable to type 'number'.
364 |
365 |            clearTimeout( scrollTimer );

366 |            scrollTimer = setTimeout( execute, 250 ); // 250 ms
|            ^
367 |
368 |            ++scrollEventCount;
369 |            if ( scrollEventCount % 5 === 0 ){ // 5 = magic number, from experimental experience in chrome, very scientific

ERROR  Vue CLI build failed. Please resolve any issues with your build and try again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quiclog/qvis/issues/38#issuecomment-755432423, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSELNOEUVLHFPV7673XTODSYSKIFANCNFSM4VMGI7CA
.

Ah yes, I think this is fixable by a very small tweak. I don't have the
exact code available to me right now but see this comment that I think
inspired me:
https://github.com/microsoft/TypeScript/issues/842#issuecomment-252445883
On Wed, Jan 6, 2021 at 5:08 PM toasthorse<EMAIL_ADDRESS>wrote:

@rmarx https://github.com/rmarx
Yes, this is how I produced the crash in Chromium. I am running Arch Linux
5.10.4. However I think that this might be exclusive to Linux, I could not
reproduce it on Windows 8 (I currently don't have access to a Windows 10
machine).
Regarding the sequence diagram, I should have been a bit more clear; it
only takes a while to load, but it is indeed smooth after loading it :)
I tried the pre-built electron .exe on Windows 8 and I could only load the
small demo files, but not the 31 MB one. Only the blue banner appears, but
not the green one to confirm that it has been loaded; when clicking on the
different tools, it only says "Loading files...". In Chromium, Google
Chrome and Firefox on Windows 8 I can load it without a problem.
Thank you for the explanations regarding the implementation of the tools
and future plans! I will make sure to let you know if I find anything else.
@LPardue https://github.com/LPardue
Thank you, running it in the /visualizations directory worked! However it
did not compile, there seems to be an error in the implementation:
ERROR in /home/dominik/downloads/qvis/qvis-qvis-app-rc1/visualizations/src/components/sequencediagram/renderer/SequenceDiagramD3Renderer.ts
366:12 Type 'Timeout' is not assignable to type 'number'.
364 |
365 |            clearTimeout( scrollTimer );

366 |            scrollTimer = setTimeout( execute, 250 ); // 250 ms
|            ^
367 |
368 |            ++scrollEventCount;
369 |            if ( scrollEventCount % 5 === 0 ){ // 5 = magic number, from experimental experience in chrome, very scientific

ERROR  Vue CLI build failed. Please resolve any issues with your build and try again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quiclog/qvis/issues/38#issuecomment-755432423, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSELNOEUVLHFPV7673XTODSYSKIFANCNFSM4VMGI7CA
.

I've attempted to fix this by making it an "any" instead of "number" in a recent commit (see above). Seems like a later version of TypeScript has different bindings than what I'm using. Please try again?
With regards to the 31MB file in the electron version: @LPardue didn't bundle that in with the .exe, so you should download that separately via https://qvis.edm.uhasselt.be/standalone_data/draft-00/mvfst_large.qlog and then upload it as a local file via Option 2.  Sorry for the confusion :)
Hoping you can test on both Arch and Windows 8 and let us know the results. Thanks!

I've attempted to fix this by making it an "any" instead of "number" in a recent commit (see above). Seems like a later version of TypeScript has different bindings than what I'm using. Please try again?
With regards to the 31MB file in the electron version: @LPardue didn't bundle that in with the .exe, so you should download that separately via https://qvis.edm.uhasselt.be/standalone_data/draft-00/mvfst_large.qlog and then upload it as a local file via Option 2.  Sorry for the confusion :)
Hoping you can test on both Arch and Windows 8 and let us know the results. Thanks!

@rmarx Thank you, I was able to run the built app on Linux and the .exe on Windows by supplying the qlog via option 2, however they both performed about as well as the web tool.

@rmarx Thank you, I was able to run the built app on Linux and the .exe on Windows by supplying the qlog via option 2, however they both performed about as well as the web tool.

Hey @toasthorse. Sad to hear using the built app did not significantly improve performance, but also not entirely unexpected since electron is basically chromium bundled with app code...
Please do let us know if you have any more problems/questions and when you finish your text; I'm interested in hearing your findings and opinions :)
I have now opened an issue on the msquic repo that I'll probably use to track some of the efforts I mentioned above for supporting other, more high-performance tooling like Windows Performance Analyzer: https://github.com/microsoft/msquic/issues/1158

Hey @toasthorse. Sad to hear using the built app did not significantly improve performance, but also not entirely unexpected since electron is basically chromium bundled with app code...
Please do let us know if you have any more problems/questions and when you finish your text; I'm interested in hearing your findings and opinions :)
I have now opened an issue on the msquic repo that I'll probably use to track some of the efforts I mentioned above for supporting other, more high-performance tooling like Windows Performance Analyzer: https://github.com/microsoft/msquic/issues/1158

Hello @rmarx, my finished paper has been published here, it mostly describes qlog and qvis but perhaps you will enjoy reading it nonetheless :)

Hello @toasthorse. Thank you for sharing the paper! I did really enjoy reading it and agree (mostly ;)) with the content and the conclusions :) It's always nice to have your work be of interest to others!


Guessed wrong for http://depsy.org/package/python/sisl

This package is meant for scientific investigations and has at least been used in the following article:
http://www.sciencedirect.com/science/article/pii/S001046551630306X

It is a research software


Reset idle timeout when request is received by blaze-server

This is fix for one (half) of the issues I mentioned in #4761
So it's the same application use-case, but I'll sketch the background one again to highlight the aspects that are important for this specific issue
Background
We have an http4s-blaze-client calling an http4s-blaze-server. These normally run as separate processes on separate machines, but in the process of reproducing this issue I'm running both in one JVM. Requests sent by the client have unique identifiers. There is no retry logic. The same request is never sent twice. The server fails loud when it receives a second request with the same identifier. Detection of such case is not guaranteed but when it happens it's clean and unambiguous. The whole solution worked since years without any duplicates, until we replaced akka-remote communication with the http4s client-server communication. The server is configured with default timeouts (30s response timeout, 60s idle timeout) . The issue affects 0.21.x and probably some other version as well.
The symptoms
From time to time the server processes the same request twice complaining about the duplicate ID.
The issue no. 1
With help of wireshark we can see what happens on the network. This is filtered to show just one TCP (HTTP) connection. The port 10443 is the server, the port 50150 is the client.

At 206.7 the server received a request, at 209.6 it responded with 200. This was the previous request which went fine. At 248.6 the server recieved a new request. At 269.6 the server abruptly terminated the TCP connection, while the request was still being processed. We can see that the connection was terminated ~60 seconds after the response to the previous request was sent.
Debug logs confirm that the termination of the connection is caused by IdleTimeoutStage on the server side.
One would expect that the reception of a new request at 248.6 should have reset the timeout, and that it should not occur until 308.6. But it doesn't work like that in practice. The answer as to why is in the IdleTimeoutStage#readRequest . The readRequest is called immediately after sending a response to previous request (at 209.6) and this is when the timeout is reset. When the new request is received at 248.6 the timeout is not reset.
This PR addresses this issue
Issue no. 2
The timeout problems don't explain why the request is processed twice. This is in my opinion an interaction of two bugs, the one that I described above and a separate on on the client side, that I haven't diagnosed yet, but I will address it in a separate PR. Nonetheless, to complete the story: When the connection is lost at 269.6, the blaze client decides to borrow another connection from the pool and resend the request though it. The server responds immediately with an error due to the duplicate ID.
Solution to Issue no. 1
The timeout should be reset when readRequest completes, not when it's called, because that is (more or less) the time when actual network activity happens in the connection.

needs a scalafmt

Code formatting and build in general should be fine now.


Improve Portability

Untested, but I'm reasonably confident it'll at least compile. (Provided I didn't overlook anything.)
Arduino.h is still quite a notable dependency, but a less niche one, so it'll still be easier to port than before, particularly to other Arduino boards.
I was tempted to replace the _BVs inside the .cpp file as well, but they're all concentrated in FX:drawBitmap which already relies on Arduboy2Base::sBuffer, so I'm not sure if it's worth it or not.
I still think it would improve readability because _BV is quite a niche thing specific to avr-libc compared to the universality of 1 <<, but practically there probably won't be many people reading the function, let alone modifying it. (At least not for a while anyway.)
Resolves #5.

Note that Arduino.h includes ArduinoAPI.h which includes stdlib.h and stdint.h. stdlib.h includes stddef.h so the includes stdint.h and stddef.h are redundant.

stdlib.h includes stddef.h

That might be the case for avr-libc's implementation, but the standard doesn't guarantee it.

Arduino.h includes ArduinoAPI.h which includes stdlib.h and stdint.h

If someone is porting using an official version of the Arduino library then it may well already be using stdlib.h and stdint.h.
However, if someone is porting to a non-Arduino platform then having stddef.h and stdint.h already included will save them the work of including those themselves or ensuring that whatever they include to replace the Arduino-dependent features (which might not be an implementation of the Arduino API) would have those included.

See also:

https://softwareengineering.stackexchange.com/questions/262019/is-it-good-practice-to-rely-on-headers-being-included-transitively
https://stackoverflow.com/questions/3945899/should-i-include-a-header-that-is-already-included-via-other-headers

If porting an Arduino project to another platform then it would make more sence to to use an Arduino.h wrapper that includes the required includes (and defines). It is likely that an Arduino project uses the include at multiple locations. Besides that, having an Arduino.h wrapper would make it easier to port other Arduino projects too.

It might make sense if someone is trying to port a large number of programs, but writing an entire Arduino wrapper is a lot of effort. Even porting just the things Arduboy2 uses is quite a bit of effort. (I know from experience.)
If someone wanted to port just the FX library or the FX library and Arduboy2, it would be far less effort to remove all the Arduino stuff and replace it.
Particularly since in this case what's Arduino-specific in the .h file is all low-level platform-specific stuff like SPDR and PORTD. It would be far less effort to just replace it with something platform-specific than it would be to try to emulate the behaviour of the ports. Especially for something that's not even using SPI in the first place (e.g. writing to a file).
Two lines of code seems a very small price to pay for the sake of following good practice and potentially making porting slightly easier.


Add a Github action to test on Alpine

Proposed changes:

Add a Github action to test on Alpine

Benchmark results:

Before: not relevant
After: not relevant

Test suite changes:

This PR introduces a new github action to build and test graphene on a musl-libc based distribution.

Thanks, much appreciated!


Add proper windows support.

Seems like we use some bash features. See: #145
We need to add some proper support for windows.
cc @mnmtanish

I think we can use shelljs to write scripts so it'll work on all platforms. Eg. prepublish.js instead of prepublish.sh.
I'm working on integrating Appetize.io to react-native-storybook these days. I'll get back to react-storybook as soon as it's ready.

@mnmtanish sounds like a good plan.

Its possible to fix that soon ?

It's working for me on Windows now. Thanks!

Fixed with #308


Remove global CustomEvent polyfill.

Polyfilling the Customevent constructor for IE11 must be handled per module due to bug in the MDL framework.
Will use a strategy similar to what is provided i the Google Dialog Polyfill.

Actually the global CustomEvent polyfill is only provided in the component demo. But since we can not rely on a "standard" CustomEvent polyfill  when using MDL, an per module CustomEvent is required.


Add beta commands with support for new directory layout

Closes: #881

What changed?
This adds a new command beta with sub-commands for adding applications and initializing clusters.  When initializing clusters - only external repositories  (GitOps repo) are supported.  Also, when initializing the GitOps runtime is persisted into the GitOps repo.  This allows users to recover a cluster and associated workloads by run install after the cluster is re-created.

Why?
These changes are needed to solve the shortcomings and limitations of the existing GitOps repository layout.

How did you test it?
Unit tests and manual execution

Release notes
The release notes will need to cover these changes.

Documentation Changes
Yes, we need to add documentation for the new beta command and its associated sub-commands.  Along with the new directory layout.

@jpellizzari   I'm really sorry, but I missed this comment -

Since we are moving to the new directory structure as of this PR (rather than via the beta command), I would like the implementation to match more closely with how we have spec'd it out in this ticket: #768

Is it OK to put this in a follow-up story.

@jpellizzari I'm really sorry, but I missed this comment -

Since we are moving to the new directory structure as of this PR (rather than via the beta command), I would like the implementation to match more closely with how we have spec'd it out in this ticket: #768

Is it OK to put this in a follow-up story.

Works for me.


Code/Instructions incomplete??

Hi Team, I am trying to run the sole-planning for mistral-7B model, but realized that there is API kept up and running at the local "http://localhost:8301/v1"
What are the steps to run those local APIs for mistral, mixtral and ChatGLM3 models??
Please mention them here or in README file

Hi Nikhil,
Thank you for your interest in our work.
We use fastchat to deploy our local model, you can see the details in here.
Please feel free to adjust the local port settings in the code to suit your specific setup.
I hope this can help you. Feel free to contact us if you have further questions.
Best,
Jian

Thankyou, it was helpful and I was able to run the mistral model. Is this detail mentioned in paper or anywhere else on site or github. The only line I could see in paper is Section 4.1 mentioning "For all these models, we adopt the official
instruction formats whenever available."
Thanks again for the help.

Hi,
Sorry to say that we didn't use this model. We use the official model provided by Mistral. Actually, all the models mentioned in the paper were evaluated using their official parametric weights, given the abundance of unofficial versions.  However, it's totally fine if you are interested in these models. We are also glad to see more results on TravelPlanner.
Hope this can help you.
Best,
Jian

Thanks again for confirming the exact model repo, since in official mistral there are v0.1 and v0.2(that you used)


Added missing include to awaitable.h

Added missing include optional to awaitable.h.
Required for line 140.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[Vue] Tabs value is not working as intended

Description
When I use the value prop that is documented for the TabsProps here, I don't get the desired effect of programmatically changing the tab.
In fact it looks like the value prop is not even defined on the Tabs component as you can see that it is actually treated as an attribute (inspect the tabs element an see it showing up there, or open the Vue devtools).
Link to Reproduction
https://codesandbox.io/s/sleepy-cache-9gxlx6?file=/src/App.vue
Steps to reproduce

Go to the example and expect the 'solid' tab to be the first one selected (it is not)
Change the value of the select box and expected the selected tab to change
Observe that the tab does not change at all

Ark UI Version
0.5.1
Framework

[ ] React
[ ] Solid
[X] Vue

Browser
No response
Additional Information
No response

The desired effect has also been mentioned here, as to be documented.

Thanks for taking your time to report the issue. The Tabs component has been revised. Please check the tab stories for guidance.
This change will be part of the next release.


Admin user sees archived postings belonging to other users

We fixed this issue for un-archived postings, but we'll need to do it for archived ones as well.

Actually, all users can see archived postings right now. I'm guessing that postings are entirely unscoped in the archive view. Should be a simple fix.

Oh my that’s bad. I’ll try to push a fix tonight with tests.

Matthew Riley MacPherson | tofumatt.com

On 26 January 2015 at 17:07:12, sarah ✈ semark<EMAIL_ADDRESS>wrote:
Actually, all users can see archived postings right now. I'm guessing that postings are entirely unscoped in the archive view. Should be a simple fix.
—
Reply to this email directly or view it on GitHub.


Asynchronious operations progress reporting

ErrorReporterInterface and MainWindowInterpreters interface now can beautifully show some QtConcurrent progress.
Removed deprecated invocation framework.
Added runextensions.h from QtCreator src for more convenient QtConcurrent::run usage.

Current coverage is 24.72%

Merging #1672 into master will increase coverage by +0.06% as of 9f1af62

@@            master   #1672   diff @@
======================================
  Files         1832    1828     -4
  Stmts        76976   76834   -142
  Branches         0       0
  Methods          0       0
======================================
+ Hit          18985   18996    +11
  Partial          0       0
+ Missed       57991   57838   -153

Review entire Coverage Diff as of 9f1af62

Powered by Codecov. Updated on successful CI builds.


fix codecov

Pull Request Description
Describe what this PR does / why we need it
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

/close


[BUG] 3.4.12 - NPC picture picker does not work

NPC picture picker does not work, at least the UI does not pop up, only the normal image picker does.
On PC's it works fine.
I'm using SWN:R system (if it helps)

Tokenizer looks for a class on the image in the source, it has a list of supported types here: https://github.com/MrPrimate/vtta-tokenizer/blob/master/src/hooks.js#L312
SWN:R will need to support one of these, or let me know what class I can look for that is unique to npc images.
As a workaround in the settings you can select "Title link bar?" which will place a link to Tokenizer in the title bar of the character sheets.

Sadly i'm not a programmer so i cant tell you exactly what class it is. The SWN:R dev who works on the system should best be contacted about this issue.
As for the title token link, this seems to work, thx.
Thank you

This was fixed upstrea,m


Create a Prometheus ServiceMonitor object that can capture/collect metrics from deployed SonataFlow instances

Description
The operator can track in the cluster if Prometheus Operator is installed. If this condition is true and the SonataFlowPlatform is marked with .spec.monitoring: true, then each workflow instance can have a ServiceMonitor object bound to it.
Implementation ideas
Each SonataFlow already exposes a Service. Hence, in this issue, it's expected that each ServiceMonitor instance binds to it.
Verify with kogito-runtimes the endpoints to scrap for metrics (should be /metrics).
Prereqs

Prometheus operator is installed
Prometheus CR is already deployed and configured in the cluster. The operator won't provision a Prometheus server.

We decided to modify the scope for this issue so that the operator only creates a service monitor for workflows deployed as k8s deployments. A separate issue has been created to track the work for workflows deployed as Knative services:
https://github.com/apache/incubator-kie-kogito-serverless-operator/issues/550


Use onViewCreated instead of onActivityCreated for AboutFragment

Kind (Required)

Improvement

Overview (Required)

We use onViewCreated for binding view data

Links

https://android-review.googlesource.com/c/platform/frameworks/support/+/1189651

@roana0229 @takahirom
I'm sorry for the delay. It seems that this issue is fixed. Please confirm if you have no problem and close.

👀  https://github.com/DroidKaigi/conference-app-2020/blob/master/feature/about/src/main/java/io/github/droidkaigi/confsched2020/about/ui/AboutFragment.kt
Thank you, I confirmed that it was already solved. 👍


Don't need the go script

Hi, first of all, great idea to use Zenity! And thanks for providing the vim plugin script.
Since I don't use go for anything else, I didn't feel like installing the go compiler for this one off thing. But I realised that you can achieve the same functionality without the go script, just by putting the zenity command into vimscript:
function CJKInput()
    let l:cmd = 'zenity --entry --text=CJK-Input'
    let l:output = system(l:cmd)
    let l:output = substitute(l:output, '[\r\n]*$', '', '')
    execute 'normal i' . l:output
endfunction
nmap <silent> <leader>j :call CJKInput()<CR>

by the way, this also removes the need for xclip

What a better way ! Thank you, @MachFour .


It would be great it there was an official CMake FindNetcdf.cmake

Not for the first time, some modelers at NOAA and NCAR are tripping over different FindNetcdf.cmake files being used in different projects, coming up with different results.
It would be great if someone who knows cmake a whole lot better than I do could select from among the candidates and promote an official FindNetcdf.cmake file, which correctly handles all the complexity of finding netcdf-c and netcdf-fortran, and setting the appropriate cmake variables to help projects build with netCDF.
Last time I checked, there was a FindHDF5.cmake actually distributed with cmake. If we could select a working FindNetcdf.cmake, we could submit it to the cmake team, and hope to solve this problem for all cmake users in a standard way.
This would help cmake-using HPC teams a lot! As it is, they write or find a FindNetcdf.cmake somewhere, and all end up with different variables and options. Hilarious build confusion may then ensue.

This would be great; it feels like starting with one of the extant FindNetcdf.cmake files being used would be a good starting place. I'll see what I can find. I agree that getting something bundled with cmake would be fantastic.
Are any of the NOAA projects using FindNetcdf.cmake using publicly-available projects/code? I can spin up a netcdf hello-world project to test with/against, but if I can avoid reinventing the wheel, I'll take it.

This would be great; it feels like starting with one of the extant FindNetcdf.cmake files being used would be a good starting place. I'll see what I can find. I agree that getting something bundled with cmake would be fantastic.
Are any of the NOAA projects using FindNetcdf.cmake using publicly-available projects/code? I can spin up a netcdf hello-world project to test with/against, but if I can avoid reinventing the wheel, I'll take it.

Yes, for example: https://github.com/NOAA-EMC/UFS_UTILS

Yes, for example: https://github.com/NOAA-EMC/UFS_UTILS

Here's an issue in NOAA codes which seems to be caused by differing FindNetCDF.cmake files: https://github.com/NOAA-EMC/hpc-stack/issues/149#issuecomment-769903241

Here's an issue in NOAA codes which seems to be caused by differing FindNetCDF.cmake files: https://github.com/NOAA-EMC/hpc-stack/issues/149#issuecomment-769903241

OK, this is not really a netcdf-c issue. I will close it...


problem in installing

Hi. Thankyou for your opensource code, and wonderfull work.
i am having problem in isntalling this repo on colab
pip is not able to find model==0.6.0.
can you guide me how to get around this or is there a type in library name.
I shall be very thankful for your help

Thanks for using! This could be a redundant requirement. You could try running the code without this library, and if this works, we will remove this requirement.

Hi, Sorry for the late response. I was able to run the test without above mentioned requirement. So you can remove it.
But I noticed that it is taking too long to run on google colab. So can you provide detection results of Transferable-Interactiveness-Network on HICO-DET Dataset. That will be extremely helpful. Thankyou.

You could download it from this link.

Thank you for your help. I am closing the issue.


SoCC '20 | Elastic Parameter Server Load Distribution in Deep Learning Clusters

Presented in SoCC '20. [ Paper ]
Authors:
Yangrui Chen, Yanghua Peng, Yixin Bao, Chuan Wu, Yibo Zhu, Chuanxiong Guo
The University of Hong Kong, ByteDance Inc.

A work across HKU and ByteDance.
Motivation

Parameter servers (PS) are widely used in distrubuted DNN training. But their performance will be damanged by stragglers because of some reasons (e.g., imbalanced parameter distribution, bandwidth contention, or computation interference).
Few existing studies have investigated efficient parameter (aka load) distribution among parameter servers (PS).

Solution

Propose a dynamic parameter server load distribution scheme called PSLD.

Mitigate PS straggler issues and accelerate distributed model training.
An exploitation-exploration method is used to 1) scale in and out parameter servers, 2) adjust parameter distribution among PSs.
Implemented on BytePS and vanilla MXNet PS architectures.

The workflow of PSLD is as follows:

Not read the details of the algorithms.


Adding a reference to "Feed the Boids!" for Coding Challenge 69: Steering Evolution

Fantastic, thank you!


very noob here, golang library?

I have no idea what Golang Library is? or how to get a phone number on there. is it US only? like I feel like the ReadMe..needs more of in-depth step-by-step explanation

Superb


OP config options aren't functioning

As of LuckPerms-Bukkit-5.0.16.jar the default config options aren't working:
enable-ops: true
auto-op: false
commands-allow-op: true
The settings are seemingly ignored as in game/through console the op and deop commands are ignored, when performing it in game it just gives the LuckPerms version and in console the command isn't recognized. I've attempted deleting the configs and having them be recreated on a server restart, I've tried /lp sync through console, I've tried to change the config and then revert it back in between server restarts, there aren't duplicate configs or duplicate entries within the main config, but the default config options that should have the server use the vanilla op system instead of LuckPerms permission and op system are ignored/don't work.
Server Start Log:
https://hastebin.com/qomexuwupo.apache

Seems to be working fine for me with a minimal server setup. (LP v5.0.39, Spigot 1.14.4)

So my guess is another plugin is interfering with the OP system on your server.


Added NodeMCU board support.

It adds the following features:

Added NodeMCU support

It fixes the following issues:

Fixed Wemos D1 R2 pin D6, D7
Changed input validation for analogwrite, value range 0-1023 for ESP8266 and 0-255 for the rest

Hi,
Thank you very much for the submission, it'd be great to add this to the Ardublockly repository, but this PR contain a lot of changes not related to the required changes (and a lot of formatting changes). It'd be great if you update this PR or create a new one with just the changes needed for this additional board support. It'd be even better if you could also separate the fixes to the Wemos support into a different PR, as that would make it easier for me to review and test.


White and black console

Timings link
https://timings.aikar.co/?id=9c50ff0b4f954ada892eb697c56b54d7
Expected behavior
Color codes should correctly be displayed on the console.
Observed/Actual behavior
Color codes are not correctly displayed on the console.
Steps/models to reproduce
Start the server and print something colorful on the console, for example:
Running command /version essentials

The colorful text are all shown in gray.
Purpur version
Current: git-Purpur-1602 (MC: 1.18.2)*
Previous: git-Purpur-1566 (MC: 1.18.1)

You are running the latest version

Agreements

[x] I am running the latest version of Purpur available from https://purpurmc.org/downloads.
[X] I have searched for and ensured there isn't already an open issue regarding this.
[X] My version of Minecraft is supported by Purpur.

Other
I checked the update log and found:

Seems this issue already got fixed, but for now seems it's not really fixed ...

Unable to reproduce.

I confirmed again this is build 1602 ... did it have something to do with the java version I used? or the OS?
I'm using Dragonwell Java 17
OS information:
> uname --all
Linux minecraft 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I'm adding more information. Some colorful text are shown properly but some are not.

I tried oracle java 17 and there was still the issue ...

Your terminal may not be showing colors correctly, try using a different one or consider taking a peek to your configs.


Live stops if Date value is changed.

Hello, good afternoon,
The live functionality stops working when you update the date object and the component re-renders. Is there any way to prevent this?
Thank you very much!

I'm experiencing this as well. any suggestions?

same problem here.

I am also experiencing this issue and think it's also probably the cause of the problem on this Stack Overflow question:
https://stackoverflow.com/questions/66322904/how-to-fix-react-timeago-not-updating-on-its-own

I was stuck on this for awhile, what worked for me was to add the date prop to the useEffect dependencies and then change Infinity to a large number.

Brilliant. I didn't need to add the date prop to useEffect - I don't actually have a useEffect clause where that would be relevant.
However, updating the max prop with a large integer did solve my issue:
Original Code:
<TimeAgo live={true} date={lastUpdated} formatter={timeFormatter} />
Updated Code:
<TimeAgo live={true} date={lastUpdated} formatter={timeFormatter} max={Number.MAX_SAFE_INTEGER} />
The time now updates as expected. Thank you for your help @BrennanWilkins - you've saved me a headache!

Unfortunately I had to download the src files and make the edits to the index.js file. The useEffect in index.js was what I was referring to.

Thanks @BrennanWilkins - that's sorted the issue now. I don't actually need to update the max prop to Number.MAX_SAFE_INTEGER - just adding the date prop to deps works. I've submitted a pull request with the fix.

Since the pull request was merged a  new version has been published to NPM.


Update mod to 1.12

Highlights

uses new forge registry system
minimum forge version <IP_ADDRESS>3
Reflection no longer needed for potion ingredients, method is public

Any comments or concerns? @HenryLoenwind  @tterrag1098


Self hosted HTTP - Notification panel translation key(?) visible

With the 1.27.2 ntfy server, while self hosting and using HTTPs, the notification prompt panel in the upper left shows:

Notifications not supported
alert_not_supported_context_description

looks like the second line is localization key or similar

This is very odd. I just tested with the exact same binary and it doesn't happen for me.
Which browser?
Which OS?
Can you try to hard-refresh your browser cache (Alt-F5 on Linux/Windows)

As for why you are seeing this error: Notifications are only supported via HTTPS or on localhost. That's a browser restriction.

looks like a caching issue, I can't repro after emptying caches in safari

:+1:


feature: fix linting problems

Is there an existing issue for this?

[X] I have searched the existing issues

Feature idea
fix issues found by linter
Alternatives

Implementation idea
No response
Participation

[X] I am willing to submit a pull request to implement this feature.

Link to the idea discussion
No response

relates to #194 #157


build: run tests against ios10

@jelbourn FYI: There are a few flaky tests on the select right now. Also one tooltip test is failing on Mobile Safari (even with iOS 9 -> unrelated)


Save user selection as cookie

Save the user's selection as a real cookie in the browser.
The cookies should not have an expiration date.
Make sure that the selection is not requested again when reloading the page.

I would like to be assigned this task.  Thanks!

@alexjharrison assigned. have a great time doing this. :-)


/sector/{key}/treediff gives empty response

/sector/{key}/treediff?attempts=1..2

URL has changed, see https://github.com/CatalogueOfLife/clearinghouse-ui/issues/186

there was a bug in the generation of sector metrics so that all sector trees and name sets were empty. Unfortunately we cannot rebuild the older attempts, but for future syncs this should be fixed now

I am rebuilding all current metrics, so they all have tree, name index ids and name string metrics which can be diffed to future imports/syncs.
Name matching against the names index also doesnt work nicely anymore, many names have no match. Thats the reason why many id files are empty. I'll address that when I switch to the stable ids business.


TS package: Fix HostStatus any

export interface HostStatus {
  HostBase: HostBase;
  Status: any /* host_api.Status */;
}

The juicy parts are not included in the ts package

@saffronjam Host api is TS itself afaik right? so should be pretty easy to publish that too

sys-api is deprecated


Not possible to purchase the same renewable subscription again after it has once expired (iOS)

Hello,
I am not sure if its a bug or if I am doing something wrong.
I have just updated from version 4.0.2 to version 5.4.0 (I have also tested version 6.4.0 with the same result). Since version 5.4.0 I call the FinalizePurchaseAsync-function after the validation of the iOS renewable subscription purchase. That is all, that I have changed in my code.
Since version 5.4.0 I cannot purchase the renewable subscription with the same product_id after it was once expired with the sandbox tester account. In the old version 4.0.2 it works as expected.
Does anyone have any idea what went wrong here?
With regards
DiebBlue
Bug Information
Version Number of Plugin: 5.4.0 (same behavior with 6.4.0)
Device Tested On: iPhone SE (2016)
Simulator Tested On: no
Version of VS: 2019 Version 16.11.18
Version of Xamarin: <IP_ADDRESS>
Versions of other things you are using:
Xamarin Forms <IP_ADDRESS>7
Xamarin Essentials 1.7.3
Xamarin.CommunityToolkit 2.0.1
Xamarin.iOS and Xamarin.Mac SDK <IP_ADDRESS>
Steps to reproduce the Behavior

Delete purchase history for Sandbox test account in Apples App Store Connect
Start the App and purchase a 1 month renewal subscription
Close the App
Start and Close the App - The subscription will renew a few times correctly until it has been expired after a few loops
Start the App and purchase a 1 month renewal subscription again after it has been expired

Expected Behavior

the subscription dialog window raises and the user can purchase again the 1 month subscription as before

Actual Behavior

no subscription dialog window raises
the billing.PurchaseAsync functions just returns the already expired old purchase

Code snippet
//You must connect
bool connected = await billing.ConnectAsync();

if (!connected)
{
    //Couldn't connect
    return null;
}

//make purchase
purchase = await billing.PurchaseAsync(product.ProductInfo.ProductId, product.ProductType);

//possibility that a null came through.
if (!CheckPurchase(product.ProductType, purchase))
{
    //did not purchase
}
else
{
    if(Device.RuntimePlatform == Device.Android)
    {
        // Android
        await ValidatePurchase_Android(purchase, billing, product, false);
    }
    else
    {
        // iOS
        await ValidatePurchase_iOS(purchase, billing, product, false);
    }
    return purchase;
}

Screenshots
Debug breakpoint:

Contents of the purchase at the breakpoint:

I wonder if this is just an issue with the test environment? Not brave enough to test this in production though ;-)
Here is my thinking:
I compared the code from the 4.0.2 release with the latest code. The biggest difference that I can see is here:
            if (string.IsNullOrWhiteSpace(applicationUserName))
            {
                var payment = SKPayment.CreateFrom(product);
                //var payment = SKPayment.CreateFrom((SKProduct)SKProduct.FromObject(new NSString(productId)));

                SKPaymentQueue.DefaultQueue.AddPayment(payment);
            }
            else
            {
                var payment = SKMutablePayment.PaymentWithProduct(product);
                payment.ApplicationUsername = applicationUserName;

                SKPaymentQueue.DefaultQueue.AddPayment(payment);
            }

Before there was no if statement - it just used the SKPayment.CreateForm() method.
I haven't confirmed that this is the issue, but I saw this in the documentation for SKMutablePayment:

Simulating Buy for Testing
simulatesAskToBuyInSandbox
A Boolean value that produces an “ask to buy” flow for this payment in the sandbox.

Maybe that parameter needs to be set if we are in Sandbox mode?
Anyways, I don't have time to investigate this further at the moment, but thought I'd share what I found. Might be completely wrong though...

Does anyone know if this is only an issue for Sandbox purchases?

@DiebBlue I actually encountered the same thing. Not sure why I decided to upgrade the package, since 4.0.2 had been working solidly for me for a while. When I first upgraded it, I changed the code per the documentation and tested purchasing a subscription, and thought, man that was easy, since it worked no problem. Yeah, I was wrong about that. Renewals and purchasing again are very tough in 5.x+.
I'm still trying to figure out the right flow, partially just updating this with what I've figured out. The behavior isn't always reproducible, and I can't quite tell if it's just because of my code.
I think there might be a couple things missing from the documentation. Apple's documentation says you have to call finishTransaction (which is called from FinalizePurchaseAsync) on Restored and Failed transactions, as well. (4.0.2 did this automatically) I might have missed something, but I think the plugin documentation should mention calling FinalizePurchaseAsync on those statuses, too.
If you have an unfinished transaction, PurchaseAsync ends up returning an "old" transaction that hasn't had finishTransaction called on it, and doesn't even present the payment popup.
Anyway, I also implemented OnPurchaseComplete, and made sure to call FinalizePurchaseAsync from there for Purchased and Restored, and also made sure to call FinalizePurchaseAsync for Failed from the return on PurchaseAsync It seems to mostly work, but it's not as solid as what was running on 4.0.2 (any failures when doing things with in app purchases are very concerning). Part of it, I think may have to do with the way FinalizePurchaseAsync works now for iOS -- it restores purchases, then finds the transaction based on transaction id, then finishes it. The old version 4.0.2 just finished the actual SKPaymentTransaction that came through UpdatedTransactions which seems a lot more foolproof to me, but I might be off base here.
Anyway, like I said, there's probably something I'm not doing correctly or missing, not sure if you've figured out a good flow since you added this issue?

Thanks @adam-russell!
It's not working for me though - I did implement OnPurchaseComplete and call FinalizePurchaseAsync  from there but I'm still having the same issue.
I did notice something very strange though - there are tons of purchases that are the same:
var purchases = await billing.GetPurchasesAsync(ItemType.Subscription);
foreach (var inAppBillingPurchase in purchases)
{
    Log.Info($"TransactionDateUCT: {inAppBillingPurchase.TransactionDateUtc}. Id: {inAppBillingPurchase.TransactionIdentifier}. State: {inAppBillingPurchase.State}");
}

You can see there are just a ton of these. The TransactionDate is the original time, not the renewal time.

... might get a chance later to investigate this.
I might have to go back to 4.0.2, but Android won't allow that beyond November. So need to figure this out soon :P

@yonkahlon Wow, ok.
I believe there are a couple problems here.
GetPurchasesAsync calls RestoreAsync which, after actually doing the restore, loops through transactions on SKPaymentQueue.DefaultQueue and adds the original transactions into the transaction list. I looks like this is a problem because there isn't a dupe check, so if you have multiple transactions with the same original, that original gets added to the list multiple times. On a subscription, I think there may be a lot of transactions with that first original, too. (Which may explain why you have a ton of those in your list.)
I'm not sure what your actual SKPaymentTransactions look like, but the code in FinalizePurchaseAsync has this code:
var transaction = purchases.Where(p => p.TransactionIdentifier == transactionIdentifier).FirstOrDefault();
So it'll only ever update the first one in the list with that TransactionIdentifier. Apple's documentation on transactionIdentifier https://developer.apple.com/documentation/storekit/skpaymenttransaction/1411288-transactionidentifier makes this a little scary to me, too, since it says it's only defined except with the state is purchased or restored (So what happens with failed? Do these become transactions that can never be finished with the current version of the library? Not sure.)
I actually rolled back to 4.0.2 temporarily, too, because I haven't quite wrapped my head around everything. I'm pretty sure that it needs a code fix in the InAppBillingPlugin library, though.
I think the easiest "fix" would be to add a flag to have UpdatedTransactions automatically call FinishTransaction on any SKPaymentTransactions like 4.0.2 did. It looks like some older versions of the code had this flag, too.
That might be a little hacky, though. Here's what I'm currently thinking without doing that, though (and I might be off base and missing some of the flow):

UpdatedTransactions needs to call FinishTransaction all the time on Failed transactions.
RestoreAsync needs to have a dupe check adding original transactions.
FinalizePurchaseAsync should loop through any purchases with the TransactionIdentifier (maybe this isn't necessary to loop, but I don't think it hurts) and finish them if they're Purchased or Restored.

It's a slightly separate concern, but I would be tempted to associate SKPaymentTransaction more directly InAppBillingPurchase which probably defeats part of the purpose of a cross platform library. It would make finishing them more straightforward, and eliminate the need to restore transactions for so many calls. The other thing this would help is the speed. Not sure if I'm the only one, but my purchase flow works more slowly than I'd like (and definitely much slower than other apps I've seen).

@adam-russell thanks for that! In my brief look through the code I saw the RestoreAsync call and suspected that loop.
So essentially FinalizePurchaseAsync ends up adding SKPaymentTransactions to the queue each call instead of removing it.
Yeah you right - there is no event called when the transaction fails (TransactionCompleted isn't publicly available, only onPurchaseSuccess is):
		public override void UpdatedTransactions(SKPaymentQueue queue, SKPaymentTransaction[] transactions)
		{
			var rt = transactions.Where(pt => pt.TransactionState == SKPaymentTransactionState.Restored);

			// Add our restored transactions to the list
			// We might still get more from the initial request so we won't raise the event until
			// RestoreCompletedTransactionsFinished is called
			if (rt?.Any() ?? false)
				restoredTransactions.AddRange(rt);

			foreach (var transaction in transactions)
			{
				if (transaction?.TransactionState == null)
					break;

				Debug.WriteLine($"Updated Transaction | {transaction.ToStatusString()}");

				switch (transaction.TransactionState)
				{
					case SKPaymentTransactionState.Restored:
					case SKPaymentTransactionState.Purchased:
						TransactionCompleted?.Invoke(transaction, true);

						onPurchaseSuccess?.Invoke(transaction.ToIABPurchase());
						break;
					case SKPaymentTransactionState.Failed:
						TransactionCompleted?.Invoke(transaction, false);
						break;
					default:
						break;
				}
			}
		}

I think that not completing the purchase automatically is okay - apple suggest that you do it after you verify the receipt. This lib no longer does the validation automatically, so now we have to validate then complete the purchase.

If you validate receipts, validate them before completing the transaction, and take one of the paths described above.

Yes, this was a big change because it actually causes a lot of issues when you finalize things with consumable items. So you much now call var ack = await CrossInAppBilling.Current.FinalizePurchaseAsync(purchase.TransactionIdentifier); directly after you call PurchaseAsync for all platforms.
As documented here: https://jamesmontemagno.github.io/InAppBillingPlugin/PurchaseSubscription.html
We had thought of trying to make things autofinalize, but again it just seems like bad practice from what is there there.
Now, I will look into the other thing which is

Alright....
Sooooo

@jamesmontemagno Awesome, thanks James, I know that'll help at least my case out a lot! I think those changes will help a lot, though I realize the finalize flag isn't good practice.
I think the first big things on subscriptions (prior to adding you adding back the finalize flag, which I'll probably take advantage of) for me were documentation based:

You have to call FinalizePurchaseAsync on Restored and Failed in addition to Purchased (I only see it being called on Purchased in the documentation, but I may be missing something.)
You pretty much have to implement OnPurchaseComplete and call FinalizePurchaseAsync for subscriptions otherwise you'll end up with renewals that aren't finished, and can never finish them in normal purchase flow, because a regular purchase only returns one object.

I do also think RestoreAsync should have a duplicate check for original transaction (because you probably end up with a bunch of renewal periods with the same original), but again, I might be missing something.
Also, hopefully I don't sound too critical in the above comments -- I personally really appreciate this library. It's saved me a lot of time, and maybe I'm just being picky because 4.0.2 was really rock solid, at least for my use case. I never had any bugs reported in purchasing and I never saw failures in the logs from it, so thank you very much for it.

Thanks for all the research and write-up on this. I guess that all makes sense to me on the renewals for sure.
I did make a change in this latest beta that I just pushed out.
When you call FinalizePurchaseAsync... it will find all with the transactionIdentifier:
			var transactions = purchases.Where(p => p.TransactionIdentifier == transactionIdentifier);

            if ((transactions?.Count() ?? 0) == 0)
                return false;
			try
			{
                foreach(var transaction in transactions)
				    SKPaymentQueue.DefaultQueue.FinishTransaction(transaction);
			}
			catch(Exception ex)
			{
                Debug.WriteLine("Unable to finish transaction: " + ex);
				return false;
			}

On a real flow I would:
1.) User purchases sub
2.) Finalize
3.) When you need to "renew" or you have "restored" call "GetPurchasesAsync"
4.) Loop through and finalize ALL purchases.
That should handle it to be honest. You could also do step 3/4 when the user tries to buy  the purchase again.

Hello,
See all same issues here so will try not to reiterate ALL that has been covered already.

When the await billing.PurchaseAsync(productId, ItemType.Subscription); runs, it completes returning the purchase object but no purchase dialogue shows up on device. Ever.

If the subscription has expired, it will not allow that to be repurchased or re-instated/renewed.

it would be great to see documentation/code on renewing a subscription that has not expired yet
AND to renew/reinstate a subscription that has expired/cancelled OR allow repurchase.

await billing.FinalizePurchaseAsync(purchase.PurchaseToken); never returns true, acknowledging any purchase.

This library/plugin was running really well until version 5.4.0 and now 6.4.0.
Only updating because we have to, to be able to update app for Android and THAT deadline is looming FAST!
PLEASE GET THIS FIXED ASAP. PLEASE.

@blmiles
You should be able to use the new beta that James put out if you include prerelease versions -- it's 6.5.0-beta. Then, set the new flag so it works like 4.0.2 where you initialize the plugin in your AppDelegate:

InAppBillingImplementation.FinishAllTransactions = true;
InAppBillingImplementation.OnShouldAddStorePayment = OnShouldAddStorePayment;
var current = CrossInAppBilling.Current;

At least for me, this makes it work nicely like 4.0.2 on initial tests just like @yonkahlon  above.
@jamesmontemagno Great, thanks for the clarifications!
So, with the FinishAllTransactions flag, everything seems to work for me as I mentioned above.
Trying to implement it without that, I'm still having issues.  Because of the version of Xamarin.iOS I'm using in my build, I'm having issues running the debugger on a physical device, so I'm partially guessing below (so take with a grain of salt or whatever):
One of the problems I missed before (sorry about that) that @blmiles is referencing above is that FinalizePurchaseAsync always returns false when I try it with a just completed purchase when the transaction isn't the original. I think the problem is that it's trying to use RestoreAsync then loop through the transactions to finish the right one. (Thanks for the loop in there, just in case!) The problem looks like RestoreAsync adds originals from the current queue and restores completed transactions (https://developer.apple.com/documentation/storekit/skpaymentqueue/1506123-restorecompletedtransactions) so the one you're trying to complete isn't always there. I think it'll be on SKPaymentQueue.DefaultQueue.Transactions while there's an observer attached (https://developer.apple.com/documentation/storekit/skpaymentqueue/1506026-transactions)? I also have OnPurchaseComplete implemented in my version of the code without the FinishAllTransactions flag, and it gets partially sorted out when I kill and restart the app (maybe because I'm also verifying the latest receipt with Apple?) , but without the debugger attached, I'm a little confused about what's happening.

@adam-russell @yonkahlon @jamesmontemagno thanks for your input on this thread!
Setting that flag, did help, thanks for pointing it out, I completely missed adding that.
When calling the PurchaseAsync(); method, the purchase dialogue does not always show on a new subscription. Not sure why but if it doesn't and simply returns the purchase object, all fails. Will keep testing.
When the app starts, I do a GetPurchasesAsync() I loop through all purchases returned (100s in the test env., shouldn't be many on real world), I validate the purchaseToken on each.
I noticed that the IsAcknowledged flag is always false on the most current valid purchase (it was "acknowledged" at time of purchasing. Not sure if we should have to call FinalizePurchaseAsync() method on current purchase/subscription every time, maybe there's a reason for it still being false.
MUCH BETTER! I'm a little less stressed and hopeful this can be deployed soon.
I will pay attention to updates and will add the 6.5.0 release version when it's ready.
Now to test Android...
Thanks to ALL!

@yonkahlon @adam-russell @blmiles @jamesmontemagno Thank you for your commitment to this issue, which has led quite quickly to a short-term solution.
I would also like to join the previous speakers in thanking @jamesmontemagno  for this library, which has also saved me a lot of time and effort.

IsAcknowledged only applies to Android, there is no way to know on iOS if a transactions has been completed. It is silly that Apple doesn't expose it.

I will create another method that will take in an array of transaction identifiers.
On iOS it is absolutely the TransactionIdentifier:
var transactions = purchases.Where(p => p.TransactionIdentifier == transactionIdentifier);
is my code
On Android the TransactionIdentifier and PurchaseToken are the same - https://github.com/jamesmontemagno/InAppBillingPlugin/blob/master/src/Plugin.InAppBilling/Converters.android.cs#L11
The purchase token on iOS is the transcation receipt info: https://github.com/jamesmontemagno/InAppBillingPlugin/blob/master/src/Plugin.InAppBilling/InAppBilling.apple.cs#L336

Alright, so in 6.6.0... you can now pass in a bunch of transactionids to finalize... this should help with speed so it doesn't restore every time.
Additionally... just for good measure specific to iOS i have a new way to finalize products based on IDs... so that should really finalize everything that is restored with a specific Id..... worth a try too

Alright, so 6.6.1 introduces these new methods, but also now turns on FinishAllTransactions automatically for backwards compatibility. I think this is just easier for now. I have unlisted the older stable nugets

Awesome @jamesmontemagno
Hope to get this in and tested shortly!
Thanks for your quick efforts, I was seriously concerned a few days ago...


no integration favicon

after having installed the custom component in its correct folder and the icons in the www folder, and having restarted the HA instance, there is no integration favicon in the integrations list.
not sure what to post since I don't have errors.
ha 103.4 rpi3 hassio

Check if you have an integration with no name, just an empty entry in the list.
If you do, make sure you also got the hidden directory custom_components/favicon/.translations/ in the right place.

i have all the files in the correct position:

and

and no, there was no empty slot in the list, as far as I could see.
For the sake of it I tried to type fav in the search box and this is what popped up:

I then entered my objective name and path to the icon as in the video
page title: Ha Z-wave and icon path /local/favicons/green
but nothing  happening unfortunately.

The same video also shows how the icons folder should look
https://github.com/thomasloven/hass-favicon#about-the-icons

Ok sorry about that,  missed the dedicated icons...
Added them now via the tool you supplied, and left out the android icons, since I do not use that.

Still no icon appears. I've adjusted the path to what is described in your text:
/local/favicons/
(note that the video points to /local/favicons/green , which got me confused at first, seems a typo?)

closing this, as I have successfully installed favicon on 3 instances now, the issue above was a combination with Custom Header, and under the attention of the author.
thanks!


[sourcery] Choose Emojis, as a browser-rendered block

Original: please see https://gitea.com/sourcery/sourcery/pulls/1
Please also see #14581 as background.
My code here replaces a golang .tmpl files using a React component, or a "block".
Necessary information for each component is placed in a JSON blob inside the .tmpl file,
and is read by index.js to build the block.
This is a drop-in replacement for the Emoji add_reaction template,
and paves our road for making similar changes in:

[x] templates/repo/issue/view_content/add_reaction.tmpl
[ ] templates/repo/issue/view_content/reactions.tmpl
[x] templates/repo/issue/view_content/context_menu.tmpl
[ ] templates/repo/issue/view_content/attachments.tmpl

I am opening this issue in case you would like to keep these changes inside mainline Gitea.
Perhaps, you can also deny my changes and I shall keep going inside https://gitea.com/sourcery/sourcery.
Small merges are easier, so if you like my goal maybe we can keep our codebases aligned.
I hope my ideas make your grade.
Cheers and 干杯, @lunny and squad. 🚢

I don't know if I'm comfortable adding React to our stack. We already use a weird mix of vanilla, jQuery, and some Vue.

I'm also not comfortable with this.  ... I think there is an Issue with this discussion if we should have a one-page app or not and the consensus was. That dont do that. Instead enhance the api so others can make it as an own project ... we would then present it as alternative fronted to the docs ...

https://github.com/c4lliope/gitea/commit/7d8a225557d4e4b86ccdcbf6b78244e41506a458
handles templates/repo/issue/view_content/context_menu.tmpl

Putting on project owner hat, and first want to thank you for your PR. However, we won't be merging this, as @jolheiser has said, we have already many frameworks in our stack, and elsewhere we have previously stated we won't be moving towards including react in the project for those reasons as well as as a project we need to maintain these additions of which as a project we are more familiar with Vue. The great thing about SPAs is that you can build one without changing the project at all. In fact, there is one public project that has already build react components for interacting with Gitea (on mobile now, so I can't find link).

@jolheiser and @6543, I'm glad you responded.
I am hoping by changing .tmpl files to React-based blocks, our code can:

drop reliance on JQuery by using core browser apis.
Drop reliance on Vue, choosing React because it requires less preprocessing.
Make use of CSS-in-JS rendering libraries, enabling more unique designs.
Make clear missing API resources which are needed by single-page apps and API consumers.

As I described in #14581, I imagine these goals are enough reason to make a branch of the codebase. I'm only curious how aligned you'd like to keep them.


feat(pipelines): Add focus on newly expanded/collapsed groups

What
Closes #206
Description
Adds a feature to focus on a group after it has been expanded or collapsed.
On expand the group will be shown in the view with the graph set to fit around the group so that the entire expansion can be viewed or be zoomed in on to emphasize the group.
On collapse, the view may be zoomed out so as not to show extra white space due to the collapsing of the group and the group will be centered in the view.
Note that a new method centerInView was added to the Graph interface and an optional parameter node to the fit method on the Graph interface. Any application that is current implementing these interfaces without extending the base implementation will need to adjust accordingly.
Type of change

[x] Feature

Demo app surge: https://expand-collapse-focus.surge.sh/

Preview: https://react-topology-pr-topology-210.surge.sh


compatibility problems

When I use unocss in Nuxt3, the compiled _uno.css uses top-level await. This syntax has poor compatibility. Is there a way to be compatible with slightly lower versions of browsers?

This only seems to happen in a development environment, and it works fine after the build

It's similar to #1461


feat(app): Add attached pipette info to intercom support

overview
This PR closes #2019 by adding attached pipettes info to intercom data when a the api returns 'api:PIPETTES_SUCCESS'
changelog

feat(app): Add attached pipette info to intercom support

review requests
Unfortunately, the imported intercom handler always returned as a noop for Intercom('update') calls. So we had to do it the old fashioned way with window.Intercom(...)
Intercom does not accept arrays or objects for values in custom data fields. So rather than just have a single data attribute Pipettes: {...} with all of the apps info about the pipettes, it needed to be split up into Left Pipette: model string etc.
TODO: (in the future)
Add pipette serial numbers to intercom once they are exposed by the api
We have a test intercom app for these PRs so we can avoid confusing support with our nonsense messages. I will ping you with the intercom ID you need to set in app, and a link to the dashboard to view the user data
Open app (with the intercom id set that I share via slack)

message intercom

Connect to a robot

view the attached pipettes (please use a robot with pipettes so we have data to check)

Go to the dashboard link I share with you for intercom support

find your convo and click on it (you should show up as app user)

scroll all of the way down to details at the bottom of the right column and click show _ hidden

[ ] Robot Name is populated with the robot you last connected to

[ ] Left Pipette and Right Pipette is populated with the model name of the last seen pipettes attached in your app session

Will rebase this PR once #2179 is merged

Testing with @umbhau

Connect to a robot
View attached pipettes

[X] "Robot Name" in Intercom user properties matches connected robot
[X] "Pipette Model Left" and "Pipette Model Right" in user match connected pipettes

View attached pipettes of robot that you're not connected to

[X] "Pipette Model Left" and "Pipette Model Right" remain unchanged

Connect to a robot with different (or empty) pipettes

[X] "Pipette Model Left" and "Pipette Model Right" update or clear accordingly


Command Injection

Sails version: 1.02
Node version: 9.2.0
NPM version: 6.3.0
DB adapter name: N/A
DB adapter version: N/A
Operating system: Ubuntu 16.04

Running NPM Audit throws this critical issue
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Critical      │ Command Injection                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ open                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ sails                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ sails > sails-generate > machinepack-process > open          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/663                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

This is a security vulnerability in sails-generate, meaning that you'd be able to hijack your own computer when running sails new. This one doesn't expose any tangible vulnerability to production applications. Thanks so much for bringing this up though @dev2games!

Is there a timeline when this can be fixed? I see there is already a PR by @hakash to fix the vulnerabilities
https://github.com/balderdashy/sails-generate/pull/35

@dev2games @oaksofmamre @hakash @matdombrock @PavanBahuguni  - Sails is currently working on the patch for this 👍

@dev2games @hakash @matdombrock @PavanBahuguni In addition, please see https://github.com/balderdashy/sails/issues/4699#issuecomment-483829719 and https://github.com/balderdashy/sails/issues/4402#issuecomment-483869476.
(#4699, #4402)

@wulfsolter it's because I accidentally reopened it while logged in as sailsbot

@dev2games @hakash @matdombrock @PavanBahuguni Multiple related PRs for this were merged a day ago - how is the behaviour now? I welcome the rest of the community to test this out as well 👍


GroupLimit create an error

Hello,
Using Soft deletes on a preloaded model with group limit will create an error :
 const associations = await Association.query()
      .preload('tags', (tags) => tags.groupLimit(3))
      .paginate(page, this.PER_PAGE)

There is an error because the no retrieval of deleted items clause is added at the end of the query.

Hi, @Barbapapazes
If you disable Soft Deletes for tags, does the query work?

Yes ! It works fine without SoftDeletes

Fixed in v1.4.1


Add Bors

Adds Bors toml file

bors try

bors -try

bors try-

bors r+

Bots r+

bors r+

bors r+

bors r-

bors r+

bors r-

bors r+

bors r+


VRP Feature support of various pickup & delivery scenarios

There are several business scenarios which I believe belongs to the pickup & delivery problem (PDP). Does ortools already support all of these scenarios?
The basic bussiness scenario is that there are many goods from different customers at different locations, and need to be delivered to the different locations. In addition to this, there are different requirements regarding how to organize the pickup and delivery, as follows:
Scenario 1:
Each truck can perform both pickup and delivery tasks in the same route and the sequence of task is open subject to optimal arrangement. i.e. load1->unload1->load2->unload2 or load1->load2->unload2->unload1
I have taken a read of the existing pickup & delivery example: https://developers.google.com/optimization/routing/pickup_delivery  I believe this scenario is already covered by it and ready to use.
Scenario 2:
Each truck has to load all goods (up to the maxum capacity of this truck, or less) before it can start to arrange visits to unload. i.e. load_all -> unload_all. This is due to some cargo conditions which is not convenient to arrange load and unload. So the driver need to perform all pickups in the first place, then plan to make to delivery.
Scenario 3:
Each truck has to load all goods (up to the maxum capacity of this truck, or less) before it can start to arrange visits to unload. In addition, the unloading sequence must be reverse of the loading sequence. i.e. load1->load2->load3->unload3->unload2->unload1. such arrangement makes sure the truck start to unload outlayer cargos before innerlayer cargos.
How do we manage to adapt the model, particularly for scenario 2 and scenario 3. Many thanks

You can use routing.NextVar(index) to limit the list of available next node.
i.e. pickup node then can visit any node (nothing to do)
delivery node limit to any delivery node or end nodes (i.e. once you visit a delivery node you can't visit a pickup node)
note: this was already discussed on the mailing list...

You can use the PD Policy FIFO or LIFO
-> https://github.com/google/or-tools/blob/stable/ortools/constraint_solver/doc/PDP.md#fifo-policy

note: This is not an issue, you should use the mailing list or the github discussion

You can use routing.NextVar(index) to limit the list of available next node.
i.e. pickup node then can visit any node (nothing to do)
delivery node limit to any delivery node or end nodes (i.e. once you visit a delivery node you can't visit a pickup node)
note: this was already discussed on the mailing list...
You can use the PD Policy FIFO or LIFO
-> https://github.com/google/or-tools/blob/stable/ortools/constraint_solver/doc/PDP.md#fifo-policy

note: This is not an issue, you should use the mailing list or the github discussion

thanks for your reply and help.

Regarding scenario 2, I did not fully understand what you mean by "pickup node then can visit any node (nothing to do)". Could you please show me with a simple example?

how to use the mailing list. where can I find the discussion related to this problem in the mailinglist?

many thanks

https://groups.google.com/g/or-tools-discuss
https://groups.google.com/g/or-tools-discuss/c/Vz4sJtwBM2Q/m/XirUtGPzAwAJ or
https://groups.google.com/g/or-tools-discuss/c/pbf1b_8fGt8/m/DNj8uyGgAgAJ to adapt to your problem


new image from kitematic but docker images missing

Expected behavior
docker images show the container I created from kitematic
Actual behavior
missing
Information about the Issue
Steps to reproduce the behavior

...create "sebp:elk"
...after running, check with terminal > docker images

When creating with Kitematic, you're creating containers not images. Do a docker ps instead.


CLI improvements

Please verify that an old client can talk to the new server.  I expect it works fine, but double check or it will break the verifier.
Looks good

This only adds additional fields to the response, so it shouldn't break anything.


Odd behavior with site.sun_set_time

I've been using astroplan (v0.2) to schedule observations for the LCO global network, in particular for their 1m telescopes at sso, saao, ctio and mcdonald sites. In the process, I've found one very confusing bug:
`
import astroplan as ap
site = ap.observer.Observer.at_site('mcdonald')
date = '2016-12-30'
from astropy.time import Time
site.sun_rise_time(Time(date,format='isot'), which='next')

site.sun_set_time(Time(date,format='isot'), which='next')
WARNING: TargetNeverUpWarning: Target(s) index [0] does not cross horizon=0.0 deg within 24 hours [astroplan.observer]

`
This doesn't happen for any of the other sites, and of course, the negative JD causes PriorityScheduler and plot_airmass to have very odd behavior, should you try to build a Schedule with it.

I think I do understand why this is happening. It's when the provided time is really close to sunset itself. Adjusting the time a little bit (.01 day) is sufficient to get the right value, but it'd be nice to have somewhat more predictable behavior here.
`
site.sun_set_time(Time(2457752.5,format='jd'), which='next')

site.sun_set_time(Time(2457752.49,format='jd'), which='next')

site.sun_set_time(Time(2457752.51,format='jd'), which='next')

`

This has been a point of confusion before, and we should find a better way to handle it, and probably add another note to the docs like this note on precision.
Currently, rise/set times are calculated by looking for the roots in the altitude of a target over the previous/next 24 hours. This can lead to bugs like this one. For example, if a user asks when the next sunrise is relative to a time immediately after sunrise, there may be no sunrises in the next 24 hours, if the time of year being tested is in the autumn, when the sun rises later each day. That's why the error that gets thrown is that the target is "never up", because it hasn't risen within 24 hours.
One possible (but maybe problematic) fix could be to change the duration of the root search from 24 hours to 24.1 hours, which would never miss the Sun. But hen there can be multiple rises/sets within that time span, and we'd need to be careful to return the correct one.
cc @eteq @ejeschke @cdeil

My 2 cents is that it is better returning None in this case, rather than a valid Time object with an invalid value...
For now, I'm just asking for 'next' sunset and if I get JD -999.0, then get 'nearest'. This is the "right" thing in our case. The 24.1 hour fix would be problematic, because there are different objects to be scheduled for the next night.

Originally, the warning that you're seeing raised was an error. Some of the developers thought that raising an error was too harsh, since a user may try to do scheduling computations on targets that never rise/set accidentally, and the whole scheduling script should not crash as a result.
We originally wanted to use JD = nan times as outputs in this scenario, but it turns out that astropy.time.Time doesn't support nans (astropy/astropy4032), and it probably won't any time soon. Lacking nans, we decided on having the JD=-999 "magic value" back in this discussion, so that we could do searches for this error time, which is unlikely to arise naturally from any user inputs, and we can interpret these times as "not useful times".
Could you describe in more detail how the 24.1 hour fix for the sunrise/sunset time wouldn't work for you?

Sure. Given a date, and site, we want to find sunset, and the next sunrise to that sunset to construct the Schedule object for that site. For the LCO observations, we've pre-computed nights following a geometric spacing through the semester to probe variability, and simply want to find the best windows on a given night and site for all the requested blocks. There are four separate sites that we have to schedule for, but each block can have only one request, and must include the requested windows for the same observation from all four sites.
We're trying to not break the geometric spacing, and getting the "next" night through a 24.1 hour fix breaks this pattern. That alone might not make much difference, but we're also trying to get simultaneous spectroscopy with SOAR, and so one site giving a  while the other giving us +1 day is tricky (especially if this happens with SOAR, since what dates we're assigned isn't under our control). astroplan has made most of this a breeze, but I did inadvertently run into the bug I reported here because of the -999.0 JD.
Here's a visual of how densely spaced this gets:
2017-03-19_schedule.pdf

OH THAT'S WHERE YOU GOT THAT PLOT FROM, @bmorris3  - was confused, since I didn't think I'd made those public (totally fine to use btw, and yes, am happy to help improve this viz).

A work around for this issue:
while True:
    rising_time=site.sun_set_time(time, which='next')
    if not isinstance(rising_time.jd, float):
        time=time+24*u.hour
    else:
        break


[8.x] Add binding field to explicit model binding

This PR adds binding field support to model bindings registered via Route::model.
Example:
RouteSerivceProvider.php:
Route::model('root_category', Category::class);

routes/web.php:
Route::get('category/{root_category:slug}', CategoryController::class)->name('category');

Using route function will give us this output:
route('category', ['root_category' => $category]); // http://localhost/category/category-slug

But opening the URL shows a 404 error page.
This PR fixes this issue.

One thing I'm a bit concerned about here is does automatic scoping take place if the explicitly bound model is listed after another bound model? Such as: /users/{user}/posts/{post:slug} Is the post scoped to the user model like it would be when using implicit bindings? If so, can you resubmit this with a test proving that is the case?

@taylorotwell @driesvints
I working on it
Is parent scoping should work only when the route has a model class in parameters like:
Route::get('users/{user}/posts/{post:slug}', function (User $user, Post $post) {
    //
});

Or should work even without using model class in parameters?
Route::get('users/{user}/posts/{post:slug}', function ($user, $post) {
    //
});

@amir9480 the former.


If you were to start typing, it would be a lot more to the left than where the placeholder ...

If you were to start typing, it would be a lot more to the left than where the placeholder text is.

which pages is this?


fix: saving tables

RM-9793

🧰 Changes
Fixes saving 'complex' tables.
In a prior PR, I added a new node type tableau to represent tables with block content. This mostly worked for the editor, but not when doing mdx(mdast(doc)). This PR adds a transformer, so the a tableau is converted to a JSX table just like regular table's.
This also adds the check so, if a tableau no longer has block content, it's saved as markdown!
🧬 QA & Testing
Hard to test outside the main app.

Broken on production.
Working in this PR app.

Not sure I fully understand the content logic, but generally makes sense to me so I'm good with this!

Not sure I fully understand the content logic, but generally makes sense to me so I'm good with this!

Well, it's mostly just looking for any block content in a table cell. Except for the case when the editor likes to wrap the table cell content in a paragraph. So it tries to ignore that paragraph.

This PR was released!
🚀 Changes included in v6.75.0-beta.76


Comments: make comments a flat list

To enable this I had to make new models for load more and continue thread fake comments.
These are now left in the flat list instead of using flags/data on the parent
to know when to show them. I tried to optimize the methods for processing
comment results. Worst case would be for loadMore responses we have to iterate through
the list twice to build the tree (to get depth more easily) then we iterate and walk
the comment trees once to build the instantiate the models, build the
flat list of comment stubs and create the dictionary of  =>
.

:haircut_man:

👓  @schwers


feat(livepeer): integrated livepeer into turboeth

added livepeer ondemand and livestream options.
I have added two routes, one for ondemand viewing, another one for livestream which I demoed from obs app.
ondemand demo: https://www.loom.com/share/23fc3114869d47058e19519d3368624b
livestream demo: https://www.loom.com/share/7674281d761c453e92e0c0a724cb6fd0

Nit: can you do a global change of LivePeer -> Livepeer per project brand guidelines?


Export save parsing as Rust library (wasm compatibility)

I wanted to use a lot of the code in this package on a website so that users can read info from their saves.
I was able to copy all the modules (except ui) from this repo into a wasm-pack template and eventually after adding some
use serde::Serialize;
#[derive(Clone, Serialize)]

I was able to get it to work.
While this does work, it would be beneficial for this project to be broken into 2 packages:

rust save parser lib that can compile to wasm
the ui.

That way everyone can benefit from future updates.
I'd happily make a PR if @ClayAmore is okay with this approach.

Good idea! I've been considering splitting the tool into two separate projects: er-save-lib and er-save-editor. As for serialization, I'm leaning towards using deku  instead of serde.

That's awesome, thanks! I will look more into deku.
Whenever DLC compatibility is merged and I have some time I'd love to try to convert my serde code into more correct deku usages and split the lib and UI code a bit more cleanly.
If I complete that work, I will be sure to publish it in a PR. Feel free to scrap it if its not useful for you :)
Thanks for making this awesome project, I can't think of a better way to practice rust.


Numbers missing from SCM badge in secondary sidebar when changes are larger than 100

Does this issue occur when all extensions are disabled?: No, it also persists in a fresh user dir

Version: 1.90.0
Commit: 89de5a8d4d6205e5b11647eb6a74844ca23d2573
Date: 2024-06-04T19:34:44.157Z
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.90.0 Chrome/122.0.6261.156 Electron/29.4.0 Safari/537.36
Steps to Reproduce:

Open folder w/ 100 new files added
Move SCM view to secondary sidebar
:bug: numbers missing from SCM badge

w/ 99

+99:

I believe that this is by design. @sandy081 could you please confirm? Thanks!

Thats right.

It looks broken, why not show other characters better communicate this?

Would >99 be better?

Possibly, I'll try both and see which feels better

It should probably stay consistent, the activity bar uses 99+:


Read-only MessageActivity support.

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[x] Internal code
[x] Library interface (affecting end-user code)
[x] Documentation

Closes Issue: NaN
Description
This Pull Request adds the possibility to access sent MessageActivity of messages.

@MinnDevelopment should I remove the check fully or change it to a warning / debug message?


Extends approaching roads in intersection template

🎉 New feature
Closes #45
Summary

Adds option for extending approaching road length.
Adds new resource:

resources/intersection/intersection_3_3m_width_6m_radius_300m_approach_stopline.xodr

Test it
EXTENSIONS_LENGTH=300 WIDTH=3.3 RADIUS=6 CROSSWALK=False STOPLINE=True empy3 templates/intersection.xml.em > generated_file.xodr

Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if it affects the public API)

Just noticed that the issue says:
We can name this "intersection_[number]m_width_[number]m_radius_stopline".

I named it intersection_3_3m_width_6m_radius_300m_approach_stopline.xodr
I can adapt names in a follow-up pr if you want. If so let me know if you want to keep the previous version of the map (that has 100 m of extension)
CC: @liangfok

Can you add an intersection_3_3m_width_6m_radius_300m_approach_stopline.geojson?

Can you add an intersection_3_3m_width_6m_radius_300m_approach_stopline.geojson?
It would be good to have that even if it is the same as https://github.com/maliput/maliput_xodr/blob/main/resources/intersection/intersection_3_3m_width_6m_radius_stopline.geojson?short_path=8a8cced, just so we have a 1:1 relationship between an .xodr and .geojson.

Oh I missed adding the geojson file yeah. I will add it asap, if you need it now for testing you can grab the geojson from the end of the xodr file.

Thank you! Testing is ongoing.


dhcpv6 static mappings not working?

Our parallel IPv6 network is set up, the "unmanaged" modus of Router Advertiment (RA) is basically working.
Later we configured dhcpv6 with "managed" modus of RA. Clients receive their dynamic ip adresses, perfect.
But converting dynamic leases to static leases is not working. Under Leases we find two entries with the same DUID and the dynamic ip address is still delivered and "online". The static entry is "offline".
Any hint for us?

With Debian and Centos I face the same problem. The DUI is displayed twice in the lease list and only the dynamic ip is delivered. Strangely, this problem does not occur with Coreos. The same behavior I have also found in PFsense.
Are there any client settings that we have to consider?

I finally found the cause. The problem is how the dhcp client get involved by the most network managers / tools. For example, the dhclient must be called with the "-D LL" option to ensure a static DHCP client id. Unfortunately, this option is not considered by most network manager tools.
I solved the problem by creating a manual net interface and calling the DHCPv6 client manually:
#/etc/network/interfaces
auto ens18
iface ens18 inet dhcp
iface ens18 inet6 manual
  pre-up sleep 2
  up dhclient -6 -D LL -v $IFACE
  down dhclient -6 -r -v $IFACE

Finally, the static DHCPv6 assignment with opnsense works.

I'm not sure if this is related, but I am seeing a similar issue. The only difference is that the dynamically assigned address does not show "online." This is with an ubuntu 18 vm.