A new home for Open Collective's documentation

I've been working with Open Collective's documentation platform of choice, GitBook, every day. GitBook, for those who aren't familiar with that name, used to be a popular open source CLI tool used by many open initiatives such as Django Girls, and is now a documentation platform.
Our main issue
GitBook is a great tool for projects with a fixed release development model as it offers many tools to separate old and new versions of the documentation, but using it can get tricky in a rolling release project. Making aggressive changes in the structure of the documentation often made multiple pages disappear with no explanation whatsoever, and GitBook's interface and documentation would offer us no explanation on why it kept happening.
Lastly, even though the GitBook team states that all features offered on the CLI tool were incorporated to the (now) proprietary platform, there are quite a few significant differences between them, including:

Use of a specific versioning system
No internationalization support
No offline documentation
No native tool to export documentation

And while they have finally added native analytics support, they only offer integration with Google Analytics (and even that it's limited to general page views).
For a more detailed analysis of GitBook, refer to two of my blog posts on the matter:

My first impressions of GitBook
Is GitBook the right tool for your organization?

My insight
I believe that a perfect documentation tool for Open Collective should fulfill the following requirements:

Use Markdown
Be open source (to avoid the perils of vendor lock-in)
Be well documented
Blend well with Open Collective’s visual identity
Be compliant with W3C’s accessibility standards
Be simple to set up, manage and maintain
Offer an easy process to create and edit pages for both core contributors and external ones
Offer internationalization tools
Have some degree of integration with a version control tool
Have an integrated search tool or make it easy to integrate one
Let us use any analytics solution

Negotiable features:

Have a database
Have an integrated editing interface

As a technical writer, I would recommend a new documentation tool. GitBook, as it stands now, cannot fulfill all of those requirements.
Options
I made a small research on what other open source projects use and asked the fediverse what would they recommend to replace GitBook. Here are a few options focused on documentation:

Read the Docs, which supports both MkDocs and Sphinx (note: see pricing)
mdBook, a re-implementation of GitBook created by the Rust team
Docsify
Docusaurus

There are ways to build documentation with frameworks and static site generators such as Hugo, but they weren't created specifically for documentation.
One of Florence's contributors kindly shared their report on documentation tools with us. It's a great read and a lot of their needs are similar to ours.
I want to hear from you

Should we abadon GitBook?
When it comes to documentation, what are your needs?
What is your favorite option?
What should we be careful about?

Thank you @contraexemplo ! I am following this discussion with interest.
I will bring it up with @piamancini @znarf and the rest of the team in our meeting today.
@jaskirat2000 do you have any thoughts?

Hi ! Thanks for taking this up. So when it comes to Gitbook I think that is one of the best option which allow the docs in an organized way. But at the same time experiencing features that caused problems can be a great issue and gives a hint to move out of it.
I would prefer the "Read the docs" documentation set up because it has got mant well organized set of features which are way better than gitbook and even support markdown. But I see a high configuration cost for it.
If cost is not a problem we can definitely go for "Read the Docs"
Thanks

@znarf - did you want to add the comments here that you brought up in the meeting?

@alanna sure
@contraexemplo I understand where you're coming from, the frustrations with GitBook, and your list of requirements makes perfectly sense. I'm afraid however that we'll not find the perfect tool matching all these requirements. To get facts, would be great to start the research, compare the different alternatives in a table, see how they score compared to these requirements.
Regarding the implementation, the GitBook setup was initially tackled independently from the engineering team, which is great because we have very limited resources right now. If the documentation team decide on using a new tool, I should warn that we'll not have much time to help, because we need to focus on our set priorities.
So, from my point of view, I think it's great to research what tool could be better than GitBook.  However I would not rush the implementation and would recommend to push GitBook to its limit, at  least until the end of the year.

@znarf I agree with that! That's something Alanna and I discussed a bit last night during our own meeting. We solved most of the main issues in the last few days (redirecting old links to the right content, restructuring the whole documentation switching branches). This is something Open Collective should think about in the long-term, not necessarily something that should be solved at this very moment.
I worked with an organization that changed their documentation tools four times in two years — GitHub Wiki to DokuWiki to MediaWiki and then to Docsify. I wasn't their technical writer nor the person responsible for their tools, I was just an intern that tried to help them anytime I could. Every time it happened it was such a rushed process I could feel everyone getting more and more frustrated with each shortcoming they would find in every tool.
That's why I proposed this issue — with a bit more of experience with a few more tools and having another person's perspective in mind, you are able to paint a good picture of the current state of the documentation process and decide what should change and what should be kept. But that's something that should be done slowly, it should be a separate project even (which is what happened with MediaWiki in this round of Google Season of Docs — another technical writer used my work as an Outreachy intern to understand better the state of MediaWiki's documentation and to propose a related project).

Just a small note, docsify and docusaurus are on Open Collective, so it's always a plus when picking a tool.

Has anyone reached out to @ericholscher about seeing if https://readthedocs.org/ could provide a better option? Seems like there could be some opportunities to collaborate on tools and models to sustain https://readthedocs.org/sustainability/

Happy to chat -- of note, readthedocs.org for open source stuff is free, whereas readthedocs.com is paid for closed source. We love Open Collective, and would happily offer a discounted or free plan if y'all have specific need of private repos. :+1: :tada:

Thank you @ericholscher ! We'd love to collaborate. We're not ready to make the jump right away due to lack of team capacity, but we'll certainly follow up in the future. As of now all our docs are totally open so we don't have a need for private repos.

Circling back here after a nice discussion with @contraexemplo and @alanna in Slack. I proposed the idea of putting together some contribution events where I reside in Portland, OR. Considering Read/Write the Docs is one of many OSS projects/communities with a substantial presence here, we could probably assemble a team to work on migration (or really any type of OSS project).
The following are the steps @alanna proposed upon hearing about this potential collaboration -

make the case for switching to RTD on the github thread and get buy in
scope out what the migration project would actually entail and run it by @François Hodierne to clarify what dev resources would be required
if he says it’s something an external contributor can handle with minimal support, then we can go for it
if it turns out that it will require substantial support for the core team, we need to hold off until that capacity is available

Considering @contraexemplo is wrapping up involvement with Google Season of Docs soon, continuing to make the case for switching to RTD could be a great next project.
If it turns out we can make a technical and business case (there are multiple ways these projects/communities could collaborate), @contraexemplo and other folks interested in documentation could collaborate with Open Collective and hundreds of other projects using the platform who need great documentation.

@ericholscher We had an incident with our current documentation platform last week that left me curious about how RTD deals with downtime.

Do you have an estimate of RTD uptime?
Have you ever faced an incident that caused RTD to become unstable or unavailable for a few minutes or hours? How did RTD address that issue and communicated with all communities which rely on that service?

Bumping this, Gitbook broke the images on https://docs.opencollective.com/help/collectives/subcollectives for the second time and it's pretty frustrating.

@Betree It's a really good thing you're sharing that because I noticed something like that recently and I was afraid it was my fault for not paying enough attention. :grimacing: I went through every page last month to check on every link and image and I had the impression that a few sections broke again weeks after I fixed them. :thinking:

Some of them are still broken like https://docs.opencollective.com/help/internal/moderation but I don't want to fix them now, I spent some time doing it too last week and don't want to loose more time if they haven't fixed it.
We should contact Gitbook to report this. Let me know if you want me to take care of it.

@Betree Could you try sending them an email reporting this? I've sent them some emails a few times on bugs like this and some suggestions, but the only time I actually got a response was when GitBook had a long downtime last year. Also, should we open a new issue dedicated to this to track it or should we keep any discussions on that here?

Extracted the issue to https://github.com/opencollective/opencollective/issues/2917. I think we can send the text or a link to the issue directly to Gitbook.

@contraexemplo are you still looking into this? Do you think it's worthwhile?

@alanna We had a few issues with GitBook earlier this year (as stated in some comments above) and by the end of last year, but since then things have been pretty stable from a infrastructure standpoint. They're starting to add multilingual functionality (see https://blog.gitbook.com/changelog#2019-12-26) and allow clients with certain paid plans to enable PDF exports (https://blog.gitbook.com/changelog#2019-12-12).
However—and this is probably going to be true for a long time if not for as long as GitBook exists— they still remain a closed source platform with a closed development that is sometimes quite difficult to contact (and this will always introduce some kind of risk—like that episode in which our documentation was unavailable for almost a day, or that time our images would break within hours). They have all the power to remove functionality we use extensively, or limit our actions in some way.
In my opinion, our docs as code approach works fantastically, and this shouldn't change. But we still should think about "freeing" our docs from a platform that we can't control as much as we wish, and collaborate with projects that are more aligned with our values.
Moving to another platform would still be extremely time-consuming, though, even if it is compatible with Markdown. And—I have to reiterate as this is my greatest fear—it has to be done strategically to avoid multiple migrations over time (like it happened on a research project I worked for in the past).

Here are my findings so far

Read the Docs seemed promising, but I don't think it's the platform that will better fit our needs. While they support Markdown, configuring it can be quite intimidating and tiresome. It would require someone to have a good amount of familiarity with Python, and while I am comfortable working with Python builds, someone else may not. I'm trying to aim for maintainability while keeping in mind the bus factor.
Docusaurus and Docsify seem to be very fitting, and they remind me a lot of what GitBook used to be. In fact, while reading Docusaurus' introduction, I was surprised by the mention of this issue from Redux that mentions all the problems we're currently having! In 2018!

One other thought: when we do revamp the main Redux docs content, I would want to start moving around a bunch of our pages - recategorizing existing pages, as well as merging/changing others. It would be really beneficial if there's a good redirect solution as part of this. For example, if "Immutable Update Patterns" got moved from /structuring-reducers/immutableupdatepatterns to, say, /reducers/immutable-update-patterns, then I'd want to have a redirect in place so that external links don't break.

Their solution ended up being Docusaurus deployed with Netlify. They address custom redirects directly on Netlify, which also makes the case for a Docsify adoption. Here's the issue in which they test Docusaurus and Netlify, by the way.
What I'm planning to do next
I'll test both documentation software on Netlify with a mirror of our docs. I want to test:

Our docs' compatibility level with their Markdown flavor
The amount of time it takes to get a working proof-of-concept
How easy it is to make contributions
If Netlify redirects will be enough to address our issues with frequently-changing-URLs

I'll also investigate all of our deployment options if we decide not to use Netlify's services. I'm hoping to update this issue soon with a list of requirements to execute this project, as well as an estimate of how much time it would take to get a stable build for production.

Sounds great @contraexemplo ! Thanks for the update.
@znarf @piamancini or anyone else - if you have any requirements for our docs solution please let Anna know.
One thing that would be helpful is an easy way to host multiple docs, such as seperate ones for Open Source Collective and Open Collective Foundation, without needing to do a lot of configuration, etc.

Hi, @contraexemplo Good research!
Well, I always prefer having those documentation platforms which have better easiness that means which can be used by "non-tech" people to for their contribution. Open source communities merely depend upon the contribution and documentation contains valuable inputs for various activists like "Developer". "Designer","Researcher", "Marketer", etc. So it is not necessary always that they contributors we receive will only be the developer rather we would be receiving many contributors who work in various fields and these all activist have to put input or maintain things at their end when it comes to maintai9niong their field documentation.
So I think this is the reason we should those platforms which are easy and few clicks away.

Just that Docusaurus is a collective so bonus points for that.

Thank you for this research @contraexemplo.
The points you made about Gitbook are very valid. I want to point out that despite these bugs and the decreasing trust that we have toward their service, Gitbook also still has some arguments in their favor: mainly a nice UI, and the ability to easily create new documentations and host them on their own domains. Plus it's already there and working.
As a general practice, we like to use hosted services. We avoid deploying tools ourselves because it's time consuming and, as you said, bus factor. I guess we could try a solution deployed on Netlify, because once it's configured the maintenance work required is very low.
I'm looking forward the results of your experiment, it will be quite important to make an informed decision.

Hello! I'm here with a more complete perspective about this issue, hopefully. The two questions we need to answer here are:

Does this make technical sense?
Does this make economical sense?

Summary: to me, it makes some technical sense — switching platforms would allows us to control a little more our infrastructure, improve our external contribution process, and get access to localization functionality that may be very important in the future —, but (and this one is a pretty big but), it may not make economical sense as we're still navigating a pandemic (and current resources would be better used somewhere else), and our current documentation solution still meets our current needs. As Open Collective discusses goals and needs frequently, I believe that a change in demands would be appropriately addressed if and when the time comes. I invite you to chime in and weigh the pros and cons.

I'd like to preface this by mentioning that both of them are on Open Collective and they are really great tools.
I'm really, really, really impressed with Docsify — it was by far the easiest to deploy locally with almost no changes to our current documentation as the configuration is really simple. I was even able to deploy a proof-of-concept on Netlify in less than 30 minutes: https://musing-brattain-657da9.netlify.app/ As it is, my proof-of-concept is not perfect (I would need to solve conflicts related to file names, images and shortcodes), but I did this with almost no need to edit our files in a different way — and it generates a pretty light website too! Docusaurus, on the other hand, needs way more dedication — and I found it quite difficult to make a successful deploy with little editing. If we were to choose one, I would recommend Docsify for making it really easy to maintain and deploy documentation.
As I'm still exploring Netlify as a tool since I'm still new to their product, I estimate it would take me two working weeks, working 4 hours a day, to fully migrate from GitBook (total of 40 hours). The only things I'd need from the Engineering team would be related to setting up a Netlify account for Open Collective (if there isn't one) and domain preferences.
So, in the end, we have two choices: migrating or letting our documentation be. To GitBook's credit, they are getting better at dealing with incidents — and our latest issue was ultimately solved. They offer convenience at the expense of some level of difficulty to coordinate external contributions outside GitBook's panel and control. Their interface is easy to navigate, and core contributors have access to a number of functionalities through their dashboard that makes it worth a lot of praise. They're growing and learning, just like us — and that means that sometimes, we'll stumble upon a few issues.

Great research Anna! I can help you with migration if needed.
Thanks
On Wed, 1 Jul 2020, 9:15 pm Anna e só<EMAIL_ADDRESS>wrote:

Hello! I'm here with a more complete perspective about this issue,
hopefully. The two questions we need to answer here are:

Does this make technical sense?
Does this make economical sense?

Summary: to me, it makes some technical sense — switching platforms
would allows us to control a little more our infrastructure, improve our
external contribution process, and get access to localization functionality
that may be very important in the future —, but (and this one is a
pretty big but), it may not make economical sense as we're still
navigating a pandemic (and current resources would be better used somewhere
else), and our current documentation solution still meets our current
needs. As Open Collective discusses goals and needs frequently, I believe
that a change in demands would be appropriately addressed if and when the
time comes. I invite you to chime in and weigh the pros and cons.
I'd like to preface this by mentioning that both of them are on Open
Collective and they are really great tools.
I'm really, really, really impressed with Docsify — it was by far the
easiest to deploy locally with almost no changes to our current
documentation as the configuration is really simple. I was even able to
deploy a proof-of-concept on Netlify in less than 30 minutes:
https://musing-brattain-657da9.netlify.app/ As it is, my proof-of-concept
is not perfect (I would need to solve conflicts related to file names,
images and shortcodes), but I did this with almost no need to edit our
files in a different way — and it generates a pretty light website too!
Docusaurus, on the other hand, needs way more dedication — and I found it
quite difficult to make a successful deploy with little editing. If we were
to choose one, I would recommend Docsify for making it really easy to
maintain and deploy documentation.
As I'm still exploring Netlify as a tool since I'm still new to their
product, I estimate it would take me two working weeks, working 4 hours a
day, to fully migrate from GitBook (total of 40 hours). The only things I'd
need from the Engineering team would be related to setting up a Netlify
account for Open Collective (if there isn't one) and domain preferences.
So, in the end, we have two choices: migrating or letting our
documentation be. To GitBook's credit, they are getting better at dealing
with incidents — and our latest issue was ultimately solved
https://github.com/opencollective/opencollective/issues/3165. They
offer convenience at the expense of some level of difficulty to coordinate
external contributions outside GitBook's panel and control. Their interface
is easy to navigate, and core contributors have access to a number of
functionalities through their dashboard that makes it worth a lot of
praise. They're growing and learning, just like us — and that means that
sometimes, we'll stumble upon a few issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opencollective/opencollective/issues/2595#issuecomment-652497435,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOBHK5PLELJCZCPVCB3BQ3RZNK3FANCNFSM4JIYWVWA
.

Thank you @contraexemplo ! I've brought this to the attention of the team and we'll get back you soon.

We have discussed it and decided we want to go ahead with migration to a new platform, and we've approved a budget for @contraexemplo to lead the project. It seems like Docsify is the way to go but we'll leave that to Anna to confirm. We want a platform which is open source and is a Collective as well as meeting the other requirements.

@contraexemplo From what I understand, any update to the docs will require a new deploy on Netlify. How does that take place, is it an automated process triggered on edit or every xx minutes/days? Also do you know what's the approximate build time?
We used to use Netlify to host our styleguide, but moved away because there are two limitations with the free plan:

No team collaborators
Max 300 build minutes per month

The basic plan to get rid of these limitations (which adds 3 team members, 1000 build minutes) is $45/month.
We've switched the styleguide to https://render.com, which offers unlimited collaborators and build minutes for static websites with pretty much the same features than Netlify has.

@Betree It takes a total of 14 seconds (7 seconds to build and 7 seconds to deploy, according to Netlify). A build and deploy is triggered every time someone add commits to the main branch. I wonder if their continuous integration with GitHub (especially generating previews when someone opens a pull request) may also influence in the # of builds per month? It isn't quite clear from their blog post on the matter.
Could you please tell me a bit about your workflow with Render? How similar to Netlify it is in terms of processes? (You can message me privately on Slack if you wish to share more information on this.)

It takes a total of 14 seconds

Good to know, that's super fast!

I wonder if their continuous integration with GitHub (especially generating previews when someone opens a pull request) may also influence in the # of builds per month?

From what I remember, it does. That was the main reason why we reached the limit so quickly.

Could you please tell me a bit about your workflow with Render?

In terms of process, it's very similar to Netlify. You add a new project (new service) by selecting the repo and then it auto-deploys whenever someone push on master.

Long-due progress update (sorry for taking so long, I had to take care of some personal matters):

Instead of trying to upkeep the latest version of the docs on my current fork, I decided to establish a point of time and later merge any changes to content made after my fork. I'll send a notification for everyone with some days of advance for when I'm be ready to do so so we can coordinate this.
I was spending most of my time with a local build, adding any features we already have on GitBook plus testing those who were particularly problematic there. Docsify heavily depends on snippets of code/add-ons written in JavaScript so that gives us quite a lot of flexibility even to fork them and make any changes we want.
However, when I finally set up a Render environment, I ran into a few problems with the search and some images (see https://open-collective-docs.onrender.com). I'm investigating them.

Since deploying with Render is our goal, I'll abandon the local environment for the most part and run a lot of tests on my build there. I should also test things like URL redirects to make sure that's a painless (or at least well-documented) process too.
I've set up a deadline for August 24 (that's 12 days from now).

Hey. I had ~10 days of downtime after my current glasses broke a day after I posted the last update — I wasn't able to work for more than a couple of hours with my old ones without some awful side effects. I got a new pair this weekend and will proceed with what I had planned this week instead.

Sorry to hear about the glasses situation! That sounds frustrating. Keep us
posted :)

@contraexemplo - what is the status of this project?

Hello! First of all, I'm sorry for being absent for so long. The TL;DR is that this semester... wasn't what I expected it to be: I had COVID-19, my partner suffered an accident and I was forced to re-evaluate the priority a lot of things for a while. But I'm back!
@piamancini mentioned Nextra on Twitter. It isn't production ready yet —there's a few reported bugs here and there. It's Markdown compatible and promise to have a less scary configuration/deployment method. It also shares a good bunch of functionalities with other solutions I've seen.
I have quite a good amount of catch up to do with Docsify so I'm going to run some tests with Nextra on the side too.

Welcome back @contraexemplo, I hope things are better for you now :crossed_fingers:
Nextra looks good, and the fact that it build upon NextJS is definitely an advantage for us. But as you mentioned, they clearly state that it's not production ready yet.
We should be extra careful about adopting such project at an early stage for our production documentation. If we decide that it's the one we want to use in the future, maybe we can wait for it to be more mature. To be honest Gitbook hasn't been so bad lately, nothing like the bugs we faced a few months ago. I wouldn't be against delaying a bit, though I think we still want this migration at least to move to an open source solution.

@Betree Thank you, it's good to be back! Things are definitely better on my side!
I agree 100% with you, there's quite a road ahead of Nextra still and OC is at a moment where stability is a must.

Link to Document: https://docs.google.com/document/d/1HhDJnHtMiyF4rJuvU9c9bkO-GcYY7thaiJy86kIaGj8/edit


Fix variable bindings in use of dplyr and ggplot2 functions

@kevinlkx At several points you use dplyr and ggplot2 functions that produce "no visible binding for global variable" errors in the R package checks. These errors can be fixed following the instructions given here.
I believe this approach should fix all or most of these errors:
anno_finemap_res: no visible binding for global variable 'start'
anno_finemap_res: no visible binding for global variable 'end'
anno_finemap_res: no visible binding for global variable 'chrom'
anno_finemap_res: no visible binding for global variable 'id'
anno_finemap_res: no visible binding for global variable 'susie_pip'
load_weights : <anonymous>: no visible binding for global variable 'cm'
make_locusplot: no visible binding for global variable 'pos'
make_locusplot: no visible binding for global variable 'p'
make_locusplot: no visible binding for global variable 'type'
make_locusplot: no visible binding for global variable 'object_type'
make_locusplot: no visible binding for global variable 'r2_levels'
make_locusplot: no visible binding for global variable 'label'
make_locusplot: no visible binding for global variable 'susie_pip'
make_locusplot: no visible binding for global variable 'id'
summarize_param: no visible binding for global variable 'niter'
summarize_param: no visible binding for global variable 'value'
summarize_param: no visible binding for global variable 'group'

fixed. Thanks Peter!


I18N updates, various bugfixes

change svgSprite to null, assume assets loaded, only load if set
Refactor mi18n to accept preloaded languages.
Added i18N to Formeo class. Can now call setLang(locale) to change language without full reload.
add panelResize function to Panels class. Used when editing attributes and panel heights change.
Fix Option editing data bug
Started icon font fallback for svg icons

:+1:


EKF errors with Fixed Wing

This was tested on a slightly modified version of PX4 Master
After letting the vehicle sit for an extended period of time we are experiencing two errors "PREFLIGHT FAIL: EKF INTERNAL CHECKS" and "PREFLIGHT FAIL: HIGH IMU ACCEL BIAS". We recalibrated the accelerometers but still experienced these issues. If the plane is armed moderately quickly after booting up and there are no errors thrown, and the aircraft flies normally.
Here are some log examples of the preflight fails on ground:
https://review.px4.io/plot_app?log=a0fb96a2-de2f-4e2d-a4f6-0f930ea53248
https://review.px4.io/plot_app?log=42eda972-2802-4d1e-b236-bed93244427c
We also had a case where the aircraft threw a "PREFLIGHT FAIL: HIGH IMU ACCEL BIAS" error but then still allowed us to arm. On takeoff the aircraft flew erratically and had to be taken over with manual control. Log is posted below.
https://review.px4.io/plot_app?log=e29821e7-9539-46ec-b563-79be1b655cf4

EKF INTERNAL CHECKS refers to a set of additional low pass filters and checks in the EKF frontend checking horizontal and vertical velocity innovations.
I'll need to take a closer look to see why you're getting the "HIGH IMU ACCEL BIAS" error.

Odd, here's the EKF accel bias from https://review.px4.io/plot_app?log=a0fb96a2-de2f-4e2d-a4f6-0f930ea53248

@dagar do you want me to post one of our good flights for comparison?

Yes, that might be helpful.
Look at the accel magnitude change with the FW_ARSP_MODE parameter change. The system wasn't moving. I'll do some bench testing/debugging.

Gyro as well. This doesn't correspond with any sensor calibration.

When did sensor recalibration happen relative to the above logs?

The first two logs are based off calibrations done on the 10th of may which was our first flight test on the build. The last log was a flight on may 10th which was using calibrations from earlier that day in a lab environment.

https://review.px4.io/plot_app?log=7f3d1365-11eb-485f-850b-b8824882e4ed
Here is another bad log. After digging through some more logs I'm noticing that a common theme is that if parameters are changed the ekf appears to freakout for a bit.

We figured out how to repeat this error on multiple different aircraft running a slightly modified version of a recent master build.
Steps to repeat error

Boot up vehicle

Hold the vehicle directly nose down for greater than 10 seconds with vehicle running. From what I can tell you can do this at any point while the vehicle is disarmed and it will create this error.

Place level and attempt to arm. Should trigger the "PREFLIGHT FAIL: HIGH IMU ACCEL BIAS" error.

Here are a bunch of logs from two different vehicles repeating the error.
https://review.px4.io/plot_app?log=4ca0d516-f9a7-4eed-9ea2-4f7a16d51ce1
https://review.px4.io/plot_app?log=3987ea04-d32a-4058-8739-a0b25a90f823
https://review.px4.io/plot_app?log=38587fee-ef9c-4a39-9a83-11186357980f
https://review.px4.io/plot_app?log=47c77c7d-8dcf-4c67-b52c-280b30e77b14
https://review.px4.io/plot_app?log=0c941809-fb0d-47b0-a2da-af65941d38c3
https://review.px4.io/plot_app?log=2436da7d-c47a-4da1-b7bf-09910b736723

@Kjkinney You need to modify your autopilot installation so that the propeller slipstream does not produce 25 metre changes in baro height.

I'm guessing this was reopened because of my comment https://github.com/PX4/Firmware/pull/9553.
I haven't been able to reproduce this on the bench, but there appears to be some edge case where calibration parameters aren't actually applied within drivers.
See comments https://github.com/PX4/Firmware/issues/9474#issuecomment-389937506 and https://github.com/PX4/Firmware/issues/9474#issuecomment-389938236 above for why I suspect this.


Cosmos DB Firewall

The screenshot looks outdated. I do not see any of the ON / OFF(Enable IP Access Control, Allow access to azure portal Allow access to azure servic es) options in firewall blade of cosmos db. These are now checkboxes options

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

ID: 5d6fa068-69da-7a32-6479-1145f14f2ed2
Version Independent ID: 952c3241-3f4c-b319-6457-02701b24d46d
Content: Azure Cosmos DB firewall support & IP access control
Content Source: articles/cosmos-db/firewall-support.md
Service: cosmos-db
GitHub Login: @shahankur11
Microsoft Alias: ankshah

@PrateekChaudharyDevOps Thanks for the feedback! We are currently investigating and will update you shortly.

@mimig1 I am unable to assign the content owner this issue, so I am hoping this could be assigned to you or you know who this needs to be directed to? I did just compare the current views in the Azure Portal with this document and the screen views need to be updated.

@Mike-Ubezzi-MSFT - Leave it assigned to me and I will fix the issue. I will also update the meta and assign a new author in the md file.

#in-progress

Hi @PrateekChaudharyDevOps - Thank you for alerting us to this issue. I've made the updates in the documentation and they are live on the site: https://docs.microsoft.com/en-us/azure/cosmos-db/firewall-support. #please-close

Thanks everyone for your quick action
Best Regards
Prateek chaudhary
On Fri, 30 Mar 2018 at 21:00, Mimi Gentz<EMAIL_ADDRESS>wrote:

Hi @PrateekChaudharyDevOps https://github.com/PrateekChaudharyDevOps -
Thank you for alerting us to this issue. I've made the updates in the
documentation and they are live on the site:
https://docs.microsoft.com/en-us/azure/cosmos-db/firewall-support.
#please-close
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/6338#issuecomment-377597274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Af2iAM6972vC3GL_zuYCQtZ6bpBPbWztks5tjoDPgaJpZM4S8u5E
.

--
Best Regards
Prateek Chaudhary
M:+47-48625016

@PrateekChaudharyDevOps We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


[Bug] 使用 iceberg rest catalog + oss 要求配置 AWS S3

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
2.1.7
What's Wrong?

What You Expected?
期望可以读取 oss 上的数据
How to Reproduce?
CREATE CATALOG ic PROPERTIES (
  'type' = 'iceberg',
  'iceberg.catalog.type' = 'rest',
  'uri' = 'http://<IP_ADDRESS>',
  'warehouse' = 'oss://bucket',
  ‘oss.endpoint' = 'http://endpoint',
  'oss.access_key' = 'ak',
  'oss.secret_key' = 'sk'
);

SELECT count(*) from ic.db.table;

Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

这个现在只支持s3的fs后端，用s3的那套endpoint属性吧


some changes

Heyy @vishesh13byte, what changes do you intend to propose in this PR?
Otherwise we may have to close this PR

Closing the PR because of no response.


Footer links are dysfunctional and lack aesthetically pleasing design.

Hi @Sayak-Bhunia
I want to mention that footer links are not working. We can improve this easily and the scope of design can be increased.
I want to work on this issue myself
Thanks

Hi, I want to work on this issue Please assign under GSSOC24
thanks

assigned.
please provide a better minimal design for the footer.

closed.


Sansio

Codecov Report
Attention: Patch coverage is 87.92160% with 265 lines in your changes missing coverage. Please review.

Project coverage is 94.28%. Comparing base (5243283) to head (a0589e9).

Files with missing lines
Patch %
Lines

...clude/async_mqtt/protocol/impl/connection_impl.ipp
88.48%
105 Missing :warning:

include/async_mqtt/impl/endpoint_impl.ipp
63.18%
67 Missing :warning:

...clude/async_mqtt/protocol/impl/connection_send.hpp
93.44%
24 Missing :warning:

include/async_mqtt/impl/endpoint_recv.hpp
88.35%
17 Missing :warning:

include/async_mqtt/impl/endpoint_send.hpp
89.69%
10 Missing :warning:

include/async_mqtt/protocol/event_timer.hpp
50.00%
10 Missing :warning:

include/async_mqtt/protocol/impl/timer_impl.ipp
0.00%
10 Missing :warning:

...t/predefined_layer/customized_websocket_stream.hpp
93.93%
4 Missing :warning:

..._mqtt/predefined_layer/customized_basic_stream.hpp
94.33%
3 Missing :warning:

...nc_mqtt/predefined_layer/customized_ssl_stream.hpp
93.87%
3 Missing :warning:

... and 10 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #373      +/-   ##
==========================================
- Coverage   97.34%   94.28%   -3.06%
==========================================
  Files         154      158       +4
  Lines        9474     9943     +469
==========================================
+ Hits         9222     9375     +153
- Misses        252      568     +316

Files with missing lines
Coverage Δ

include/async_mqtt/client.hpp
100.00% <ø> (ø)

include/async_mqtt/detail/client_impl.hpp
100.00% <ø> (ø)

include/async_mqtt/detail/endpoint_impl.hpp
100.00% <ø> (ø)

...clude/async_mqtt/impl/buffer_to_packet_variant.ipp
97.77% <100.00%> (ø)

include/async_mqtt/impl/client_auth.hpp
100.00% <100.00%> (ø)

include/async_mqtt/impl/client_close.hpp
100.00% <ø> (ø)

include/async_mqtt/impl/client_impl.hpp
100.00% <100.00%> (ø)

include/async_mqtt/impl/client_impl.ipp
93.10% <100.00%> (-6.90%)
:arrow_down:

...nc_mqtt/impl/endpoint_acquire_unique_packet_id.hpp
97.72% <100.00%> (ø)

...l/endpoint_acquire_unique_packet_id_wait_until.hpp
98.27% <100.00%> (ø)

... and 67 more

... and 15 files with indirect coverage changes

----
🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Node pool get removed when adding a new node pool

Rancher versions:
rancher/server:master 03/16
Steps to Reproduce:

Create a cluster with one node with all roles.
After the cluster is active, Go to "Edit Cluster" and add a node pool of one node with worker role. Click "Save".

Results:
The first node pool is removed and second node pool is added.  The first one should not be removed.

The following API requests are observed:

Put request to the original nodepool

Post request to v3/nodepool

Delete request to the original nodepool

I think UI only need to call Put request on nodepool.

Version - 2.0  master 3/26
Verified fixed


[BEAM-664] Revise examples to be more independent of runner and execution style

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[x] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[x] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[x] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[x] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

R: @francesperry love to get your thoughts on these. Feel free to directly reword things.

Can you file a bug in the website component when this is submitted to update the wordcount walkthrough?

The Jenkins precommit is blocked on BEAM-910, to explicitly provide --output always.

OK, now we need to adjust the Jenkins IT tests to use -P some-particular-runner to get signal there.
Independently, it looks like the dependencies of the starter archetype have been broken in the meantime, causing all Travis builds but Eclipse to fail.

To get test signal, I'll have to revise the matchers. Currently there are already pretty common flakes with the only message being a mismatched checksum, but it is likely enough that the new matcher needs fix-ups. While I'm at it, I might as well improve the extant matcher so it can give a hint about what is wrong.

See #1314 and #1315 for the easy parts of this PR.

To avoid confusing things, I will close this and re-open a PR later just for WindowedWordCount


Allow tag values to be variables, filled in by snmp metadata

Given a tag selection like:
      user_tags:
        level: provider
        test: one
        type: nas
        location: "$SysLocation"

This will replace $SysLocation in the tag value with whatever is found in snmp Metadata. For example, "tags.location": "Unknown",.
Any tag value with a prefix of $ will be interpreted as a variable.
If the variable isn't found, this tag is removed. @thezackm  -- what do you think about this behavior? Or can just keep the $whatever value if not found.
Closes #469

I think dropping the tag for nulls is better than passing across the variable name, thats extra data on ingest that could be confusing.  Im imagining someone trying to select uniques()  and getting a mess.

how is a user to understand that their SysLocation field is null if we drop their entire tags.location and return nothing at all?
IMO; respecting the data sovereignty means that we keep the placeholder for the tag and pass an empty string or null as appropriate. The user intends for there to be a tag, we cannot assume that they only want the tag IF there is an associated value.
Adding that type of feature (drop if null) would be a solid compromise too.

The challenge is that there's top level code which drops every attribute which is the empty string before it is sent out from New Relic. One idea is that we just keep the $SysLocation value if SysLocation isn't found. Then the user gets a signal that things are working, but also that there's no value for this in this instance. Also would fix a corner case where a user already has a tag set with a $ prefix.


Cast to Pid on Monterey M1

Hi there! This might be silly of me. Very new to rust. But I can't get the example to work properly
When I run exactly the same code as on the main page it crashes and gives me this:
Error: Os { code: 0, kind: Uncategorized, message: "Undefined error: 0" }
I've debugged and that happens on the TryInto
let handle: ProcessHandle = (&child).try_into().unwrap();
I run macOS Monterey with M1 chip.

Getting a Mach port from an existing PID is fiddly and Apple has locked it down tighter over the years. You might try using my spawn-task-port crate (which I admittedly haven't tested on Monterey or M1) to get one while launching a child process.

@Goffen Can you try running it with sudo? I get that same error when I run the tests as a normal user, but sudo cargo test works fine.


🐛 walkthrough: wrong regions path

The path for REGIONS_LATEST_VERSION was not correctly set. Maybe related to the recent countries_region.csv deprecation.

@lucasrodes I was making some changes, thanks for spotting this. I've added new commit to your PR (and approved it 😉), go ahead and ship it.


Maybe mention SWATing?

I think that due to the fact that this seems to be a common occurrence (maybe even more so then doxing), it might be a good idea to say that doxing and/or SWATing should be against the rules too, but it doesn't necessarily just mean people streaming video. It could also be SWATing from VOIP, IRC, maybe you know where the person lives by some other means, etc.
Any thoughts would be nice. :smile:
I would do a pull request, but I didn't know how well this would be received.

@vgturtle127 we are looking at updating the explicit harassment definitions here:
https://github.com/todogroup/opencodeofconduct/pull/17
We may link to the definitions listed in the GF as an example of unwarranted behavior. Not sure if that will cover it, but let us know.

@vgturtle127 I need more coffee this morning, my previous post was a mistkae.
I believe this is mentioned in the Be careful in the words that you choose" section:

Posting (or threatening to post) other people’s personally identifying information (“doxing”).

Let me know if that works!

Well, my thought was that doxing is only the first part of the SWATing. After that, they have to call the police and pretend somebody is in danger or something (a crime all by itself). So, maybe after that sentence you could add something about using identifying information against somebody? I don't know, tell me what you think.

SWATing as you call it is illegal and is covered by law. We should not include obviously illegal conduct as prohibited, as it would be superfluos and for the same reason we should not include murder or theft.

I guess that's true, but there isn't any law against any part other than calling the police without just cause, so maybe just include the part about misuse of identifiable information?

Stalking users is already under this list, which you need private info to call the SWAT on somebody.

@CoWinkKeyDinkInc not always the case. My address and phone number are both attainable without stalking (honestly, I just hand them out), but that doesn't mean I shouldn't be protected from SWATing

Thanks for your feedback. See https://github.com/todogroup/opencodeofconduct/issues/84.


Uncaught TypeError: kakao.maps.LatLng is not a constructor"

개발중인 앱에 적용하고 있는데 다음과 같은 에러가 나고 있습니다.
`I/chromium( 3453): [INFO:CONSOLE(4)] "A parser-blocking, cross site (i.e. different eTLD+1) script, http://t1.daumcdn.net/mapjsapi/js/main/4.4.9/kakao.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.", source: https://dapi.kakao.com/v2/maps/sdk.js?autoload=true&appkey=hideappkey&libraries=services,clusterer,drawing (4)
I/chromium( 3453): [INFO:CONSOLE(4)] "A parser-blocking, cross site (i.e. different eTLD+1) script, http://t1.daumcdn.net/mapjsapi/js/main/4.4.9/kakao.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.", source: https://dapi.kakao.com/v2/maps/sdk.js?autoload=true&appkey=hideappkey&libraries=services,clusterer,drawing (4)
I/chromium( 3453): [INFO:CONSOLE(4)] "A parser-blocking, cross site (i.e. different eTLD+1) script, http://t1.daumcdn.net/mapjsapi/js/libs/services/1.0.2/services.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.", source: https://dapi.kakao.com/v2/maps/sdk.js?autoload=true&appkey=hideappkey&libraries=services,clusterer,drawing (4)
I/chromium( 3453): [INFO:CONSOLE(4)] "A parser-blocking, cross site (i.e. different eTLD+1) script, http://t1.daumcdn.net/mapjsapi/js/libs/clusterer/1.0.9/clusterer.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.", source: https://dapi.kakao.com/v2/maps/sdk.js?autoload=true&appkey=hideappkey&libraries=services,clusterer,drawing (4)
I/chromium( 3453): [INFO:CONSOLE(4)] "A parser-blocking, cross site (i.e. different eTLD+1) script, http://t1.daumcdn.net/mapjsapi/js/libs/drawing/1.2.6/drawing.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.", source: https://dapi.kakao.com/v2/maps/sdk.js?autoload=true&appkey=hideappkey&libraries=services,clusterer,drawing (4)
I/chromium( 3453): [INFO:CONSOLE(22)] "Uncaught TypeError: kakao.maps.LatLng is not a constructor", source: about:blank (22)`
sdk가 정상적으로 로드가 되지 않은거 같은데 InAppWebView를 이용할때도 마찬가가지로 "Uncaught TypeError: kakao.maps.LatLng is not a constructor" 에러가 납니다.
해결에 도움이 될만한 내용이 있을까해서 문의 드립니다.
참고로
다른앱에서 InAppWebView를 이용하여 Kakaomap이 정상적으로 동작 했었습니다.
문제가 되는 앱에서 InAppWebView에서 GoogleMap으로 했을떄는 정상적으로 표시됩니다.
로그에서appkey는 'hideappkey'로 대체 했습니다.

android:usesCleartextTraffic="true"
문제 였습니다.

아 해결되어서 다행이네요! 혹시 사용하시다가 다른 문제가 발생되면 말씀해주세요!


Animating Views/On Load

I am in an Angular app and I am trying this with both Motion UI standalone and the one packaged with Foundation Apps.
My issue is if I want to use Motion UI Javascript, it is executed before DOM elements are loaded so it does not work. I tried to follow the docs and setting this up using UI router.
$stateProvider
        .state('login', {
            url: '/login',
            templateUrl: 'login/login.html',
            controller: 'LoginCtrl',
            authenticate: false,
            animation: {
                enter: 'slideInRight',
                leave: 'fadeOut'
            }
        })
        .state('dashboard', {
            url: '/dashboard',

            views: {
                '': {
                    templateUrl: 'dashboard/dashboard.html',
                    controller: 'DashboardCtrl'
                },
                'current-status-module@dashboard': {
                    templateUrl: 'current-status/current-status.html'
                },
                'alerts-module@dashboard': {
                    templateUrl: 'alerts/alerts.html',
                    controller: 'AlertCardsCtrl'
                },
                'alert-cards-module@dashboard': {
                    templateUrl: 'alerts/alert-cards/alert-cards.html'
                },
                'zones-module@dashboard': {
                    templateUrl: 'zones/zones.html'
                },
                'map-grid-module@dashboard': {
                    templateUrl: 'zones/zone-map/zone-map.html'
                }
            },
            authenticate: true,
            animation: {
                enter: 'fadeIn',
                leave: 'fadeOut'
            }
        })

I also made sure all the modules were included in my App
var dashboardApp = angular.module('dashboardApp', [
'ui.router',
'ngAnimate',
'ui.grid',
'ui.grid.pagination',
'ui.grid.autoResize',
'ui.grid.selection',
'config',
'foundation',
'foundation.dynamicRouting',
'foundation.dynamicRouting.animations'

])
I also made sure the distribution files are linked in the index.html
This is my HTML. I have a few attributes in there because at this point I was just trying things.

Content

There is this code in the app
var cards = document.getElementById('cards');
MotionUI.animateIn(cards, 'fade-in');

So when I run
MotionUI.animateIn(cards, 'fade-in');
in console after page load it works perfectly.

Putting animation-in or animation-out on elements won't work unless the plugin is configured for it. The Foundation for Sites and Apps components that support animation all have those hooks, but you can't add those attributes to any element and have it go.
It looks like you got something working—can you clarify what you want to accomplish that you haven't yet figured out?


FF Display Length Review Example

FF Display Length Review Example (from 3.1.3 Part 3).
Start Test 3.12 - DM24: SPNs Supported
14:57:40.7037 Destination Specific DM24 Request to Engine #1 (0)
14:57:40.7059 18EA00F9 [3] B6 FD 00 (TX)
14:57:42.5587 1CFDB600 [588] 5C 00 1C 01 00 02 1C 01 01 02 1C 01 20 02 1C 02 1B 02 1C 01 1C 02 1C 01 1D 02 1C 01 1E 02 1C 01 1F 02 1C 01 6E 00 18 01 AF 00 1C 02 BE 00 1C 02 E5 0C 1C 02 54 00 1C 02 6C 00 1C 01 9E 00 1C 02 5A 15 1C 02 74 0E 1C 01 CB 14 1C 01 85 05 18 02 86 05 18 02 87 05 18 02 88 05 18 02 89 05 18 02 8A 05 18 02 AC 00 1C 01 69 00 1C 01 EB 0D 1C 01 84 00 1C 02 AB 00 1C 02 E7 0A 1C 02 1B 00 1C 02 D0 03 1C 01 5B 00 1C 01 3F 0A 1C 01 B7 00 1C 02 66 00 18 01 9D 00 18 02 C1 14 1C 02 AA 0C 1C 02 1A 0E 1C 02 AE 0C 1C 02 B3 0C 1C 02 F0 18 1C 02 AD 00 1C 02 EB 0A 1C 01 81 02 1C 01 39 04 1C 01 9C 01 1C 02 51 15 1C 01 E1 06 1C 01 90 0C 18 02 91 0C 18 02 9A 0C 18 02 64 00 1E 01 F7 00 1C 04 45 0A 1C 02 46 0A 1C 02 79 02 1E 02 DC 04 1E 02 2E 02 1E 01 54 02 1E 01 55 02 1E 01 56 02 1E 01 83 03 1E 01 95 03 1E 04 BF 03 1E 01 C0 03 1E 01 C1 03 1E 01 C2 03 1E 01 C3 03 1E 01 C4 03 1E 01 EB 10 1A 02 77 0E 1E 01 BC 0D 1C 01 D7 0B 1C 01 C5 16 1C 02 08 11 1C 02 0B 11 1C 02 9D 12 1C 02 CD 16 1C 01 33 00 1C 01 88 0D 1C 01 0A 10 1D 01 E7 0C 1D 02 FD 0B 1D 02 DE 0C 1D 02 E6 0C 1D 01 C4 04 1D 02 BD 04 1D 01 1F 10 1D 01 22 10 1D 02 4E 15 1D 04 A5 1C 1D 02 02 02 1D 01 EF 1A 1D 03 E1 1C 19 01 57 15 1D 02 B7 1C 1D 01 B9 1C 1D 01 EE 14 1B 01 F2 14 1B 01 F0 14 1B 01 F3 14 1B 01 EF 14 1B 01 F1 14 1B 01 2B 05 1B 01 2C 05 1B 01 2D 05 1B 01 2E 05 1B 01 2F 05 1B 01 30 05 1B 01 63 0A 1B 01 90 12 1B 01 2A 05 1B 01 B2 14 1B 01 0C 11 1B 01 15 15 1B 01 C7 14 1B 01 A7 13 1B 01 F5 0B 1B 01 22 0D 1B 01 60 0F 1B 01 EE 10 1B 01 A0 13 1B 01 A5 14 1B 01 73 16 1B 01 CB 16 1B 01 76 1A 1B 01 7C 1A 1B 01 A2 1C 1B 01 92 0C 1B 01 9C 0C 1B 01 BB 12 1B 01 EB 00 1D 04 F8 00 1D 04 A2 0B 1D 02 41 15 1B 01 ED 14 1B 01 9B 0C 1B 01 9C 06 1D 02 80 09 1D 01 CE 31 1D 02 CF 31 1D 02 4A 00 1D 01 44 15 1D 02 A6 00 1D 02
DM24 from Engine #1 (0): [
D F T D F
a r e M F
t F s 5 l
a r t 8 n  SPN — SP Name
D F     2  SPN 27 - Engine EGR 1 Valve Position
D F     1  SPN 51 - Engine Throttle Valve 1 Position 1
D       1  SPN 74 - Maximum Vehicle Speed Limit
D F     2  SPN 84 - Wheel-Based Vehicle Speed
D F     1  SPN 91 - Accelerator Pedal Position 1
D F     1  SPN 92 - Engine Percent Load At Current Speed
F     1  SPN 100 - Engine Oil Pressure 1
D F T   1  SPN 102 - Engine Intake Manifold #1 Pressure
D F     1  SPN 105 - Engine Intake Manifold 1 Temperature
D F     1  SPN 108 - Barometric Pressure
D F T   1  SPN 110 - Engine Coolant Temperature
D F     2  SPN 132 - Engine Intake Air Mass Flow Rate
D F T   2  SPN 157 - Engine Fuel 1 Injector Metering Rail 1 Pressure
D F     2  SPN 158 - Key Switch Battery Potential
D       2  SPN 166 - Engine Rated Power
D F     2  SPN 171 - Ambient Air Temperature
D F     1  SPN 172 - Engine Intake 1 Air Temperature
D F     2  SPN 173 - Engine Exhaust Temperature
D F     2  SPN 175 - Engine Oil Temperature 1
D F     2  SPN 183 - Engine Fuel Rate
D F     2  SPN 190 - Engine Speed
D       4  SPN 235 - Engine Total Idle Hours
D F     4  SPN 247 - Engine Total Hours of Operation
D       4  SPN 248 - Total Power Takeoff Hours
D F     2  SPN 412 - Engine EGR 1 Temperature
D F     1  SPN 512 - Driver's Demand Engine - Percent Torque
D F     1  SPN 513 - Actual Engine - Percent Torque
D       1  SPN 514 - Nominal Friction - Percent Torque
D F     1  SPN 539 - Engine Percent Torque At Idle, Point 1
D F     1  SPN 540 - Engine Percent Torque At Point 2
D F     1  SPN 541 - Engine Percent Torque At Point 3
D F     1  SPN 542 - Engine Percent Torque At Point 4
D F     1  SPN 543 - Engine Percent Torque At Point 5
D F     2  SPN 544 - Engine Reference Torque
F     1  SPN 558 - Accelerator Pedal 1 Low Idle Switch
F     1  SPN 596 - Cruise Control Enable Switch
F     1  SPN 597 - Brake Switch
F     1  SPN 598 - Clutch Switch
F     2  SPN 633 - Engine Fuel Actuator 1 Control Command
D F     1  SPN 641 - Engine Variable Geometry Turbocharger Actuator #1
F     1  SPN 899 - Engine Torque Mode
F     4  SPN 917 - Total Vehicle Distance (High Resolution)
F     1  SPN 959 - Seconds
F     1  SPN 960 - Minutes
F     1  SPN 961 - Hours
F     1  SPN 962 - Day
F     1  SPN 963 - Month
F     1  SPN 964 - Year
D F     1  SPN 976 - PTO Governor State
D F     1  SPN 1081 - Engine Wait to Start Lamp
D       1  SPN 1213 - Malfunction Indicator Lamp
D       2  SPN 1220 - OBD Compliance
F     2  SPN 1244 - Engine Fuel Actuator 2 Control Command
T   1  SPN 1322 - Engine Misfire for Multiple Cylinders
T   1  SPN 1323 - Engine Cylinder 1 Misfire Rate
T   1  SPN 1324 - Engine Cylinder 2 Misfire Rate
T   1  SPN 1325 - Engine Cylinder 3 Misfire Rate
T   1  SPN 1326 - Engine Cylinder 4 Misfire Rate
T   1  SPN 1327 - Engine Cylinder 5 Misfire Rate
T   1  SPN 1328 - Engine Cylinder 6 Misfire Rate
D F T   2  SPN 1413 - Engine Cylinder 1 Ignition Timing
D F T   2  SPN 1414 - Engine Cylinder 2 Ignition Timing
D F T   2  SPN 1415 - Engine Cylinder 3 Ignition Timing
D F T   2  SPN 1416 - Engine Cylinder 4 Ignition Timing
D F T   2  SPN 1417 - Engine Cylinder 5 Ignition Timing
D F T   2  SPN 1418 - Engine Cylinder 6 Ignition Timing
D       2  SPN 1692 - Engine Intake Manifold Desired Absolute Pressure
D F     1  SPN 1761 - AFT 1 DEF Tank Volume
D       1  SPN 2432 - Engine Demand - Percent Torque
D F     1  SPN 2623 - Accelerator Pedal #1 Channel 2
D F     2  SPN 2629 - Engine Turbocharger 1 Compressor Outlet Temperature
D F     2  SPN 2630 - Engine Charge Air Cooler 1 Outlet Temperature
T   1  SPN 2659 - Engine EGR 1 Mass Flow Rate
D F     2  SPN 2791 - Engine EGR 1 Valve 1 Control 1
D F     1  SPN 2795 - Engine Variable Geometry Turbocharger (VGT) 1 Actuator Position
D       2  SPN 2978 - Estimated Engine Parasitic Losses - Percent Torque
D F     1  SPN 3031 - AFT 1 DEF Tank Temperature 1
T   1  SPN 3061 - Engine Cold Start Emission Reduction Strategy System Monitor
D       2  SPN 3069 - Distance Traveled While MIL is Activated
D F T   2  SPN 3216 - Engine Exhaust 1 NOx 1
D F T   2  SPN 3217 - Engine Exhaust 1 Percent Oxygen 1
T   1  SPN 3218 - Engine Exhaust 1 Gas Sensor 1 Power In Range
D F T   2  SPN 3226 - AFT 1 Outlet NOx 1
T   1  SPN 3227 - AFT 1 Outlet Percent Oxygen 1
T   1  SPN 3228 - AFT 1 Outlet Gas Sensor 1 Power In Range
D F     2  SPN 3242 - AFT 1 DPF Intake Temperature
D F     2  SPN 3246 - AFT 1 DPF Outlet Temperature
D F     2  SPN 3251 - AFT 1 DPF Differential Pressure
D       2  SPN 3294 - Distance Since DTCs Cleared
D F     2  SPN 3301 - Time Since Engine Start
D       1  SPN 3302 - Number of Warm-ups Since DTCs Cleared
D       2  SPN 3303 - Continuously Monitored Systems Enable/Completed Status
T   1  SPN 3362 - AFT 1 DEF Dosing Unit 1 Input Lines
D F     1  SPN 3464 - Engine Throttle Actuator 1 Control Command
D F     1  SPN 3516 - AFT 1 DEF Concentration
D F     1  SPN 3563 - Engine Intake Manifold #1 Absolute Pressure
D F     2  SPN 3610 - AFT 1 DPF Outlet Pressure
D F     1  SPN 3700 - AFT DPF Active Regeneration Status
F     1  SPN 3703 - DPF Active Regeneration Inhibited Due to Inhibit Switch
T   1  SPN 3936 - AFT DPF System
D       1  SPN 4106 - Emission-Related MIL-On DTC Count
D       1  SPN 4127 - NOx NTE Control Area Status
D       2  SPN 4130 - PM NTE Control Area Status
F T   2  SPN 4331 - AFT 1 DEF Actual Dosing Quantity
T   1  SPN 4334 - AFT 1 DEF Doser 1 Absolute Pressure
D F     2  SPN 4360 - AFT 1 SCR Intake Temperature
D F     2  SPN 4363 - AFT 1 SCR Outlet Temperature
T   1  SPN 4364 - AFT 1 SCR Conversion Efficiency
T   1  SPN 4752 - Engine EGR 1 Cooler Efficiency
D F     2  SPN 4765 - AFT 1 Diesel Oxidation Catalyst Intake Temperature
T   1  SPN 4795 - AFT 1 DPF Missing
T   1  SPN 5024 - Engine Exhaust 1 NOx Sensor Heater Ratio
T   1  SPN 5031 - AFT 1 Outlet NOx Sensor Heater Ratio
T   1  SPN 5285 - Engine Charge Air Cooler 1 Efficiency
T   1  SPN 5298 - AFT 1 Diesel Oxidation Catalyst Conversion Efficiency
D F     2  SPN 5313 - Commanded Engine Fuel Rail Pressure
T   1  SPN 5319 - AFT 1 DPF Incomplete Regeneration
D F     1  SPN 5323 - Engine Fuel Control Mode
T   1  SPN 5357 - Engine Fuel Injection Quantity Error for Multiple Cylinders
T   1  SPN 5358 - Engine Cylinder #1 Fuel Injection Quantity
T   1  SPN 5359 - Engine Cylinder #2 Fuel Injection Quantity
T   1  SPN 5360 - Engine Cylinder #3 Fuel Injection Quantity
T   1  SPN 5361 - Engine Cylinder #4 Fuel Injection Quantity
T   1  SPN 5362 - Engine Cylinder #5 Fuel Injection Quantity
T   1  SPN 5363 - Engine Cylinder #6 Fuel Injection Quantity
T   1  SPN 5397 - AFT 1 DPF Regeneration too Frequent
T   1  SPN 5441 - Engine Fuel Injection Timing Error for Multiple Cylinders
D       2  SPN 5444 - Engine Crankcase Breather Oil Separator Speed
D       4  SPN 5454 - AFT 1 DPF Average Time Between Active Regenerations
D F     1  SPN 5457 - Engine Variable Geometry Turbocharger 1 Control Mode
D       2  SPN 5463 - AFT SCR Operator Inducement Active Traveled Distance
D F     2  SPN 5466 - AFT 1 DPF Soot Load Regeneration Threshold
T   1  SPN 5747 - AFT 1 Outlet Soot Sensor Heater
D F     2  SPN 5829 - Engine EGR 1 Valve 1 Position Error
T   1  SPN 5835 - AFT 1 Particulate Sensor
D F     1  SPN 5837 - Fuel Type
D F     2  SPN 6384 - Engine Exhaust Pressure 1 (Extended Range)
T   1  SPN 6774 - AFT 1 Particulate Sensor Regeneration State
T   1  SPN 6780 - AFT 1 Particulate Sensor Temperature
D       3  SPN 6895 - Engine Exhaust Flow Rate
T   1  SPN 7330 - AFT 1 Particulate Sensor Heater Power Supply Diagnostic Status
D       2  SPN 7333 - Cylinder Fuel Rate
D       1  SPN 7351 - AFT 1 Outlet Corrected NOx
D       1  SPN 7353 - Engine Exhaust 1 Corrected Nox
D   T   1  SPN 7393 - AFT 1 Particulate Sensor Current
D       2  SPN 12750 - AFT 1 SCR 1 Engine Exhaust NOx Mass Flow
D       2  SPN 12751 - AFT 1 SCR 1 Tailpipe NOx Mass Flow
]
SPs Supported in Expanded Freeze Frame from Engine #1 (0): [
LN  SPN — SP Name
1  SPN 92 - Engine Percent Load At Current Speed
1  SPN 512 - Driver's Demand Engine - Percent Torque
1  SPN 513 - Actual Engine - Percent Torque
2  SPN 544 - Engine Reference Torque
1  SPN 539 - Engine Percent Torque At Idle, Point 1
1  SPN 540 - Engine Percent Torque At Point 2
1  SPN 541 - Engine Percent Torque At Point 3
1  SPN 542 - Engine Percent Torque At Point 4
1  SPN 543 - Engine Percent Torque At Point 5
1  SPN 110 - Engine Coolant Temperature
2  SPN 175 - Engine Oil Temperature 1
2  SPN 190 - Engine Speed
2  SPN 3301 - Time Since Engine Start
2  SPN 84 - Wheel-Based Vehicle Speed
1  SPN 108 - Barometric Pressure
2  SPN 158 - Key Switch Battery Potential
2  SPN 5466 - AFT 1 DPF Soot Load Regeneration Threshold
1  SPN 3700 - AFT DPF Active Regeneration Status
1  SPN 5323 - Engine Fuel Control Mode
2  SPN 1413 - Engine Cylinder 1 Ignition Timing
2  SPN 1414 - Engine Cylinder 2 Ignition Timing
2  SPN 1415 - Engine Cylinder 3 Ignition Timing
2  SPN 1416 - Engine Cylinder 4 Ignition Timing
2  SPN 1417 - Engine Cylinder 5 Ignition Timing
2  SPN 1418 - Engine Cylinder 6 Ignition Timing
1  SPN 172 - Engine Intake 1 Air Temperature
1  SPN 105 - Engine Intake Manifold 1 Temperature
1  SPN 3563 - Engine Intake Manifold #1 Absolute Pressure
2  SPN 132 - Engine Intake Air Mass Flow Rate
2  SPN 171 - Ambient Air Temperature
2  SPN 2791 - Engine EGR 1 Valve 1 Control 1
2  SPN 27 - Engine EGR 1 Valve Position
1  SPN 976 - PTO Governor State
1  SPN 91 - Accelerator Pedal Position 1
1  SPN 2623 - Accelerator Pedal #1 Channel 2
2  SPN 183 - Engine Fuel Rate
1  SPN 102 - Engine Intake Manifold #1 Pressure
2  SPN 157 - Engine Fuel 1 Injector Metering Rail 1 Pressure
2  SPN 5313 - Commanded Engine Fuel Rail Pressure
2  SPN 3242 - AFT 1 DPF Intake Temperature
2  SPN 3610 - AFT 1 DPF Outlet Pressure
2  SPN 3246 - AFT 1 DPF Outlet Temperature
2  SPN 3251 - AFT 1 DPF Differential Pressure
2  SPN 6384 - Engine Exhaust Pressure 1 (Extended Range)
2  SPN 173 - Engine Exhaust Temperature
1  SPN 2795 - Engine Variable Geometry Turbocharger (VGT) 1 Actuator Position
1  SPN 641 - Engine Variable Geometry Turbocharger Actuator #1
1  SPN 1081 - Engine Wait to Start Lamp
2  SPN 412 - Engine EGR 1 Temperature
1  SPN 5457 - Engine Variable Geometry Turbocharger 1 Control Mode
1  SPN 1761 - AFT 1 DEF Tank Volume
2  SPN 3216 - Engine Exhaust 1 NOx 1
2  SPN 3217 - Engine Exhaust 1 Percent Oxygen 1
2  SPN 3226 - AFT 1 Outlet NOx 1
1  SPN 100 - Engine Oil Pressure 1
4  SPN 247 - Engine Total Hours of Operation
2  SPN 2629 - Engine Turbocharger 1 Compressor Outlet Temperature
2  SPN 2630 - Engine Charge Air Cooler 1 Outlet Temperature
2  SPN 633 - Engine Fuel Actuator 1 Control Command
2  SPN 1244 - Engine Fuel Actuator 2 Control Command
1  SPN 558 - Accelerator Pedal 1 Low Idle Switch
1  SPN 596 - Cruise Control Enable Switch
1  SPN 597 - Brake Switch
1  SPN 598 - Clutch Switch
1  SPN 899 - Engine Torque Mode
4  SPN 917 - Total Vehicle Distance (High Resolution)
1  SPN 959 - Seconds
1  SPN 960 - Minutes
1  SPN 961 - Hours
1  SPN 962 - Day
1  SPN 963 - Month
1  SPN 964 - Year
2  SPN 4331 - AFT 1 DEF Actual Dosing Quantity
1  SPN 3703 - DPF Active Regeneration Inhibited Due to Inhibit Switch
1  SPN 3516 - AFT 1 DEF Concentration
1  SPN 3031 - AFT 1 DEF Tank Temperature 1
2  SPN 5829 - Engine EGR 1 Valve 1 Position Error
2  SPN 4360 - AFT 1 SCR Intake Temperature
2  SPN 4363 - AFT 1 SCR Outlet Temperature
2  SPN 4765 - AFT 1 Diesel Oxidation Catalyst Intake Temperature
1  SPN 5837 - Fuel Type
1  SPN 51 - Engine Throttle Valve 1 Position 1
1  SPN 3464 - Engine Throttle Actuator 1 Control Command
]
// Add FF record length including DTC here
End Test 3.12 - DM24: SPNs Supported
Start Test 3.13 - DM25: Expanded freeze frame
14:57:42.5726 Destination Specific DM25 Request to Engine #1 (0)
14:57:42.5760 18EA00F9 [3] B7 FD 00 (TX)
14:57:43.0207 1CFDB700 [134] 85 83 10 01 01 07 84 84 D7 0A A5 D5 B0 DD E1 64 47 29 4C 25 12 00 00 00 C6 06 01 E0 09 00 01 B4 60 B4 60 B4 60 B4 60 B4 60 B4 60 46 52 2B 46 1E 3B 25 00 00 00 00 1F 26 2B 7A 00 00 A8 75 FF 74 1C 33 0C 00 79 33 01 00 51 01 3D 3E 9E 9E 00 B7 26 01 5F 00 FB FF FF 00 FB 87 37 06 00 00 77 28 76 26 62 11 FE 0D 01 00 03 02 01 90 CC 02 00 06 39 13 04 07 25 00 00 00 7F 42 11 7A 8B 32 A0 FC 18
DM25 from Engine #1 (0):
Freeze Frames: [
Freeze Frame: {
DTC 4227:1 - Engine Crankcase Breather Oil Separator, Data Valid But Below Normal Operational Range - Most Severe Level - 1 times
SPN Data: 07 84 84 D7 0A A5 D5 B0 DD E1 64 47 29 4C 25 12 00 00 00 C6 06 01 E0 09 00 01 B4 60 B4 60 B4 60 B4 60 B4 60 B4 60 46 52 2B 46 1E 3B 25 00 00 00 00 1F 26 2B 7A 00 00 A8 75 FF 74 1C 33 0C 00 79 33 01 00 51 01 3D 3E 9E 9E 00 B7 26 01 5F 00 FB FF FF 00 FB 87 37 06 00 00 77 28 76 26 62 11 FE 0D 01 00 03 02 01 90 CC 02 00 06 39 13 04 07 25 00 00 00 7F 42 11 7A 8B 32 A0 31 50 35 04 28 FC 18
}
]
<IP_ADDRESS>.c - Received from Engine #1 (0):
Freeze Frame: {
DTC 4227:1 - Engine Crankcase Breather Oil Separator, Data Valid But Below Normal Operational Range - Most Severe Level - 1 times
SPN Data: 07 84 84 D7 0A A5 D5 B0 DD E1 64 47 29 4C 25 12 00 00 00 C6 06 01 E0 09 00 01 B4 60 B4 60 B4 60 B4 60 B4 60 B4 60 46 52 2B 46 1E 3B 25 00 00 00 00 1F 26 2B 7A 00 00 A8 75 FF 74 1C 33 0C 00 79 33 01 00 51 01 3D 3E 9E 9E 00 B7 26 01 5F 00 FB FF FF 00 FB 87 37 06 00 00 77 28 76 26 62 11 FE 0D 01 00 03 02 01 90 CC 02 00 06 39 13 04 07 25 00 00 00 7F 42 11 7A 8B 32 A0 31 50 35 04 28 FC 18
}
WARN: <IP_ADDRESS>.e - Unable to determine engine speed from freeze frame data
FAIL: <IP_ADDRESS>.c - Received data (129) does not match expected number of bytes (128) based on DM24 supported SPN list for Engine #1 (0)
End Test 3.13 - DM25: Expanded freeze frame

See #1047


App Resolutions not working correctly with lower runtimes.

In runtime 4.0 and lower the app id is present with the the property appId and not id.
https://github.com/microsoft/navcontainerhelper/blob/89c424816ab8c4ae6cfd5f903d50cb24da00cb4e/AppHandling/Extract-AppFileToFolder.ps1#L165-L176

Thanks


Can't build valid extension from master branch

I tried to build the extension from master branch.
But the result vsix didn't contain the necessary files, which are in the official vsix (downloaded from market).
And therefor it didn't work when I uploaded to azure devops.
I built the dev and release version either.
I used node 18.16.1 and 20.8.1.
And the vss-extension.json is missing from the repository.

Hi, I will take a look at it and get back to you


Bindings is undefined

I have a hasMany relationship
                .fetch({ withRelated: ['cards'] })
                .then(function (account)```

Any reason why bindings is  undefined in the second query from the debug log below?

```{ method: 'select',
  options: {},
  bindings: [ 'c70c06b80e3a42bbb3b6fcb46adaccdf', 1 ],
  sql: 'select `accounts`.* from `accounts` where `accounts`.`accountId` = ? lim
it ?' }
{ method: 'select',
  options: {},
  bindings: [ undefined ],
  sql: 'select `cards`.* from `cards` where `cards`.`accountId` in (?)' }```

What have you set as the idAttribute on your Account model?

I did not set any idAttribute.

No worries.


Restore shapely/geos.py to state at 1.5.9

And move shapely/libgeos.py to shapely/_buildcfg.py. Now it's only ever imported by setup.py when building distributions.
Closes #325.
Status: 30%

This PR also fixes #324. The script in https://github.com/Toblerity/Fiona/issues/276 succeeds now, no matter whether you import fiona or shapely first. If fiona has already been imported, we try to reuse a DLL we find in its .dylibs directory in shapely.
@snorfalorpagus @mwtoews I would very much appreciate your :eyes: on this. Getting a 1.5.13 release out soon would be a huge relief for me. This issue has been bugging me for tooooo long.
/cc @schwehr because you've recently filed a related issue.

And now we reuse any GEOS DLL that we can find already loaded on OS X, not just when the shapely module has its own .dylibs.

Barring objections, I'll merge this after lunch and release 1.5.13.

Changes Unknown when pulling ac3126064d3ad11e7909cf7e7702a1fa87fa0e03 on issue325 into ** on maint-1.5**.


Add Togainu no Chi (Jast USA)

Everything tested

I will accept but I can't do a build right now since I'm in my phone, My PC is without internet.

No prob. Thank you!


TImer can be set to negative durations

Describe the bug

Environment:

Device:
Device version:
App version:

Duplicate of #34


Avoid encoding script and style elements content

Ref https://github.com/svg/svgo/issues/176
@XhmikosR @GreLI

LGTM. Just so that we are safe, do you know what this comment was about? https://github.com/svg/svgo/issues/176#issuecomment-199947766

I actually not sure this is necessary change
https://github.com/svg/svgo/issues/176#issuecomment-913007825

Seems good. But I'm not sure, that things like
<style>
    style::after {
         content: "</style>"
    }
   /* other styles */
</style>

will not be broken. Though it's unlikely will be in SVG, and in JS usually there are ways to avoid that (like '</' + 'script>').

Closing until somebody provide a repro with visual regression


Input mask date does not work anymore with jitMasking enabled

I seem to have found a bug when jitmasking is enabled, I cannot complete the date mask . Year, month works but I cannot add the date.
If I remove the jitmasking option it works
http://codepen.io/stephendesjardins/pen/GrYYEB
Using version : 3.3.5-33
Thanks!

Noticed this as well. Have to manually put the slash between the month and day if using mm/dd/yyyy

Is there any update on this, I'm seeing the same issue.


Add APIs for bypassing the integrated cache in JS SDK

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

Released with https://devblogs.microsoft.com/cosmosdb/azure-cosmos-db-javascript-sdk-4-1-0-preview-is-here/


PLANNER-1038: Removed Old Canvas UI for Roster Screens

TODO: Remove binary files and find out why target is not in the .gitignore


Print warning on unknown rules, do not rebuild application on f5

Two changes which I found helpful while debugging my application.

first change is self-explanitory
second change is specifically motivated by a) being annoyed that my state would reset whenever I hit f5 (the element I was trying to style is not visible by default in my app) and b) noticing that once I added the first change, messages would appear a quadratically increasing number of times each time I hit f5 - each rebuild loads a new theme without clearing the old themes. I don't know if you also want to add logic clearing the user themes and stylesheets to the application logic that rebuilds everything, but this seemed like the easiest solution.

I have a feeling that not rebuilding when reloading might cause some problems, but after testing this with my own app it doesn't seem to cause any noticeable problems so time will tell. As for the styles not getting properly replaced that was an oversight. I'll merge this for now as a solution but at some point I would like to revisit this problem.


Scrivener HTML for Bootstrap style grids or with rows (or flexbox) and cards?

hi
apologies if I am looking/asking in the wrong place
can I use Scrivener.HTML for create rows with cards for Bootstrap style responsive grids?
i.e. Flexbox or Grids ?
am hacking through a solution but I would of thought this is a common scenario

used card columns and will try scrivener.html next
Grid Posts

<%= for post <- @posts do %>

<%= post.title %>

<%= post.body %>

            <%= post.slug %>
            <%= post.intro %>
            <%= post.description %>
        <%= link "Show", to: post_path(@conn, :show, post), class: "btn btn-default btn-xs" %>
        <%= link "Edit", to: post_path(@conn, :edit, post), class: "btn btn-default btn-xs" %>
        <%= link "Delete", to: post_path(@conn, :delete, post), method: :delete, data: [confirm: "Are you sure?"], class: "btn btn-danger btn-xs" %>

<% end %>

<%= link "New Post", to: post_path(@conn, :new) %>

So bootstrap and bootstrap v4 are both view styles supported by Scrivener.HTML. You can see what they produce here:
https://github.com/mgwidmann/scrivener_html/blob/master/lib/scrivener/html.ex#L143
https://github.com/mgwidmann/scrivener_html/blob/master/lib/scrivener/html.ex#L154
If you don't like those or wish to do something custom, you can implement your own helper method which calls Scrivener.HTML.raw_pagination_links/2 and produce your own HTML output from that. See here: https://github.com/mgwidmann/scrivener_html/blob/master/lib/scrivener/html.ex#L302
If you think another view style should be added, I'm open to adding another if it makes sense.


Source Control Panel with new Push/Pull/Sync buttons

Next to commit button, or as part of some submenu shown in the radicle interactive prototypes, here https://www.figma.com/proto/9h2suLnyckUXGmMyReMiYP/LF-Wireframe---Milestone-1?node-id=472684%3A9231&scaling=contain&page-id=77%3A432&starting-point-node-id=472684%3A9231&show-proto-sidebar=1
Notes:
rad push == git push rad && rad sync
As such, we want to consider if it's possible for this action to invoke the native VS Code git push and THEN, once git push is completed, to invoke rad sync. (this is what we do in intellij - if not possible, we can just delegate to rad sync on the commandline)
Resources:

Relevant discussion in intellij plugin as some questions may be relevant here too

Result:
https://user-images.githubusercontent.com/7542054/225074176-0f03486d-9aca-4e92-ac3a-e4d4a37f96a7.mp4
Turns out we can not only create our own Submenu as an entry to the 3dot-menu of Source Control View, but we can also add commands-as-buttons in the View's "navigation" bar. Moreover, we can have such a button open our own Radicle Submenu. Or even append entries to existing Submenues of the 3dot-menu of SCV.
Food for thought... :wink: CC @gsaslis
What is missing is making all those extra UI elements context-aware, so that they are shown only under certain conditions.

Turns out we can not only create our own Submenu as an entry to the 3dot-menu of Source Control View, but we can also add commands-as-buttons in the View's "navigation" bar. Moreover, we can have such a button open our own Radicle Submenu. Or even append entries to existing Submenues of the 3dot-menu of SCV.

as a more experienced vscode user than myself, which approach feels more natural to you?

What is missing is making all those extra UI elements context-aware, so that they are shown only under certain conditions.

see #23 re: context

as a more experienced vscode user than myself, which approach feels more natural to you?

I created my proposal as a new ticket (#24).
If you like it as is, please move it to "Remaining for v0.1.0". Otherwise feel free to make any edits as needed, or ping me on Zulip to discuss.

Started reviewing the closed PRs for the milestone delivery.
These screen recordings in all the PRs are awesome! :D


Dynamic import of TS files from inside node_modules

Describe the bug
If I do await import('./user.ts') from inside a test, it works just fine. If I move this dynamic import into a dependency, it fails with following:
TypeError: Unknown file extension ".ts" for ./user.ts
      1| export async function importTest() {
      2|     return await import('./user.ts');
       |            ^
      3| }
      4|

In actual test i am using absolute paths to be sure, simplifying here for readability. The contents of the file as simplified for testing to just export const User: any = {}.
I even tried to create a simple pkg folder with package.json and a single file exporting that function. Works fine if its outside of node_modules, once I move it there, it fails this way. Doesnt matter if I use import from 'pkg' or import from '../node_modules/pkg/index.mjs'.
Tried to enable registerNodeLoader, that changes the error to following:
SyntaxError: Missing initializer in const declaration

This is because it is TS file, and it fails on the first TS part. If I remove the type hint (which makes it a valid JS file), it works fine.
Then I finally tried inline: ['pkg'] and it started working. But this workaround does not work for me in the actual use case, where it breaks the dependency (@mikro-orm/core).
Reproduction

Create user.ts file with just export const AuthorListing: any = {}.
Create node_modules/pkg folder with index.mjs file:

export async function importTest(file) {
    return await import(file);
}

Run importTest('./user.ts') from a test file.

System Info
System:
    OS: macOS 12.5.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 97.61 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.8.0 - ~/Library/Caches/fnm_multishells/98665_1661811231718/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.18.0 - ~/Library/Caches/fnm_multishells/98665_1661811231718/bin/npm
  Browsers:
    Chrome: 104.0.5112.101
    Firefox: 103.0.1
    Safari: 15.6.1

Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

deps.inline should just work. This is not "a workaround", this is a solution for applying Vite transformations to files outside of your source code. You can use regular expressions, if it doesn't find your package. Your reproduction also doesn't do anything for me - if you still have problems with inline, try creating an actual runnable reproduction using stackblitz or create a repo in GitHub with code itself.

Thanks for the prompt response!

deps.inline should just work.

When I put there the ORM core package, I get this error:
 ❯ node_modules/@mikro-orm/core/dist/index.mjs:4:36
TypeError: Cannot read properties of undefined (reading 'ARRAY_OPERATORS')
      2|
      3| export default mod;
      4| export const ARRAY_OPERATORS = mod.ARRAY_OPERATORS;
       |                                    ^
      5| export const AbstractNamingStrategy = mod.AbstractNamingStrategy;
      6| export const AbstractSchemaGenerator = mod.AbstractSchemaGenerator;
 ❯ async /Users/adamek/htdocs/mikro-orm/tutorial/src/app.ts:5:31
 ❯ async /Users/adamek/htdocs/mikro-orm/tutorial/test/utils.ts:1:256
 ❯ async /Users/adamek/htdocs/mikro-orm/tutorial/test/user.test.ts:3:31

(the file is here: https://unpkg.com/browse/<EMAIL_ADDRESS>The package provides hybrid ESM support for named imports via gen-esm-wrapper.

this is a solution for applying Vite transformations to files outside of your source code.

I get that, but the transformations should happen on a local file, not inside that package, so I was kinda expecting this to work. And then there is the need for registerNodeLoader otherwise it does not understand the TS extension, is that also intended. The package only has dynamic import in the code, the file that is imported is local.
Feels a bit weird that the exact same import behaves differently inside node_modules (using absolute path).

try creating an actual runnable reproduction using stackblitz or create a repo in GitHub with code itself.

I tried to go with stackblitz but for that I need to move things to node_modules, and I dont think I can do that there. Will you be ok with a repo that moves the folder to node_modules in a postinstall hook or something like that? I know its quirky, but this seems to be issue with dependencies, and I dont want to publish some junk because of reproducing things...
Or maybe it wont be needed if you say this is expected behaviour :] Will provide something tomorrow if needed.

And then there is the need for registerNodeLoader otherwise it does not understand the TS extension

registerNodeLoader only transforms import paths, it doesn't do anything with code itself.

Will you be ok with a repo that moves the folder to node_modules in a postinstall hook or something like that?

It will be ok.

When I put there the ORM core package, I get this error

What exactly is the problem? It doesn't understand typescript or mikro imports? If you need to transform files imported from some_file.ts, you need to inline that file manually: Vitest transforms all import calls to __vite_import__, and applies its own resolution, so if import is not transformed to this magical function, it will be imported by native Node, and will fails, unless you have some kind of --loader.

When I put there the ORM core package, I get this error:

Looking at your generated code, I can say that Node doesn't see named imports because they are applied dynamically. You need to use mod.default to access those inside ESM. See: https://github.com/nodejs/cjs-module-lexer/tree/1.2.2

Hmm but that index.mjs file works just fine, only once it gets inlined it fails this way.

Hmm but that index.mjs file works just fine, only once it gets inlined it fails this way.

Interesting. Please, create a reproduction, I will look into it.

Here is the repro, its really as simple as this:
https://stackblitz.com/edit/vitest-dev-vitest-d33pe8?file=test/basic.test.ts
Same code works fine when executed directly, not via vitest. I do have a working ESM project example here (not TS, but thats unrelated).

Here is the repro, its really as simple as this:
stackblitz.com/edit/vitest-dev-vitest-d33pe8?file=test/basic.test.ts
Same code works fine when executed directly, not via vitest. I do have a working ESM project example here (not TS, but thats unrelated).

Ok, if it works without inlining what is the problem?

Ok, if it works without inlining what is the problem?

You said the correct solution to the original problem is inlining. This is the module where dynamic import happens.

Ok, if it works without inlining what is the problem?

You said the correct solution to the original problem is inlining. This is the module where dynamic import happens.

This has nothing to do with TypeScript and your original problem though. The problem here is that Vitest doesn't also store all commonjs properties on default key, which is a bug, you can bypass it by using config
{
  deps: {
    inline: [/mikro\/core\/index.mjs/],
    external: [/mikro\/core\/index.js/],
  }
}

While this fixes the issue with inlining, it doesnt seem to work for the original use case. I still see the same errors as in the OP.
Updated the repro to showcase the actual problem, where I do the dynamic import via MikroORM.
https://stackblitz.com/edit/vitest-dev-vitest-d33pe8?file=user.ts,test%2Fbasic.test.ts,vite.config.ts,package.json
Currently it works via eval trick (Function(return import('${id}'))()) to keep the dynamc import instead of compiling to require. I tried to change this to actual import locally, that itself didnt help, but in this repro I can see it behaves differently too. I think once the code is inside node_modules, it fails the same in both ways.
https://unpkg.com/browse/<EMAIL_ADDRESS>(note: this is using latest dev version, dev versions are published with the dist folder, so I adjusted the paths based on that)

it doesnt seem to work for the original use case

This is why I was confused earlier.

Currently it works via eval trick

Well, Vitest doesn't support this usage, unfortunately. We need to replace it, as I said before, otherwise it can't go through Vite pipeline.

I tried to change this to actual import locally, that itself didnt help, but in this repro I can see it behaves differently too

I don't understand what you mean here 😄 Does it work, or does it not? I can see that you can import user.ts in your reproduction.

What I mean is that I literally changed this eval trick with a real import call locally. And it does not help.
So I understand it will need to be changed on my end to support it, but I tried already and it still fails the same.

What I mean is that I literally changed this eval trick with a real import call locally. And it does not help.
So I understand it will need to be changed on my end to support it, but I tried already and it still fails the same.

Can you give a proper reproduction where Vitest fails for you? You are saying that "when you do something", "something works/doesn't work" - I can't really help, when I don't see code. All previous cases are discussed and explained. If I "change" import to actual import call, I get "No entities were discovered" error, for example.

By the way, even if you could import TypeScript file, I'm not sure if Vitest can properly transform it, since esbuild doesn't support decorator metadata (I don't know if you use it, but I see you are using decorators): https://github.com/vitest-dev/vitest/issues/708#issuecomment-1045161414

Let me quickly fix the imports and publish new dev version so we can forget about this problem. Btw I dont use reflect-metadata, so no problem with decorators (its pretty much unusable with ESM as it fails to resolve cycles and errors on runtime because of it).
If you dont mind, I could invite you to the private repo where I have the full project. It is a tutorial I am working on, so nothing complex. There you could see the app that runs fine (compiled via node as well as TS via ts-node-esm, but same code fails with vitest). I was trying to isolate this, but I see it's not really helpful and only adds confusion (so sorry about that).

If you dont mind, I could invite you to the private repo where I have the full project. It is a tutorial I am working on, so nothing complex. There you could see the app that runs fine (compiled via node as well as TS via ts-node-esm, but same code fails with vitest). I was trying to isolate this, but I see it's not really helpful and only adds confusion (so sorry about that).

Sure, I am open to it.

So now in version dev-33 it is a real dynamic import:
unpkg.com/browse/<EMAIL_ADDRESS>And in that stack blitz it fails the same.
stackblitz.com/edit/vitest-dev-vitest-d33pe8?file=user.ts,test%2Fbasic.test.ts,vite.config.ts

Utils is loaded with require, so it doesn't go through Vite pipeline, since it's asynchronous.

Hmm I see, so this can only work with real ESM projects, and this get-esm-wrapper wont be enough? But if this function which does the dynamic import would be defined directly in the index.mjs file, that might help I guess? Will try to refactor it that way.

Hmm I see, so this can only work with real ESM projects, and this get-esm-wrapper wont be enough? But if this function which does the dynamic import would be defined directly in the index.mjs file, that might help I guess? Will try to refactor it that way.
edit: or it would be still a problem given this function would be called through some other requires anyway? because it will still be triggered from inside some CJS file in the end

If the file where await import is located is loaded with require, then it won't be affected by transformations. All imports in chain should be using import. All require calls are delegated to Node.

Understood. I went with a different approach, using a global variable with a dynamic import callback, which can be overridden by user via Utils.setDynamicImportProvider(id => import(id)), so the actual code that does the import is from userland, seems like this way it works fine. Its a quirk, but at least something :]
Thanks a lot for your insights.


Multidimensional arrays

I tried to compile this JavaScript code into C, but it seems that ts2c is not able to convert multidimensional arrays:
var a = 2;
var b= a+1;
var c = [[a,b],[a,b]];
console.log("Hello world!");

There are some errors in the translated code:
#include <stdio.h>
typedef short int16_t;
static int16_t a;
static int16_t b;
static void * c[2];
int main(void) {
    a = 2;
    b = a + 1;
    /* Unsupported assignment c[0][0] = a */;
    /* Unsupported assignment c[0][1] = b */;
    /* Unsupported assignment c[1][0] = a */;
    /* Unsupported assignment c[1][1] = b */;
    printf("Hello world!\n");

    return 0;
}

Is it feasible to translate these multi-dimensional arrays from JavaScript into C?

I think this is just a bug in types inference which was refactored some time ago.
I'll fix it easily.


Fix CI typing tests

Description
Fixes the cron job typing CI tests:
https://github.com/napari/napari/runs/3387343673?check_suite_focus=true
Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

ok, typing test is passing now here: https://github.com/napari/napari/runs/3390891561
assuming the PR tests pass, this can be merged


[Tracking Issue] Add Tests

This is a tracking issue for us to write some more tests

[ ] Update rules for incremental variance
[ ] Update rules for incremental mean
[ ] Gramian matrices
[x] Link functions
[ ] Distribution functions
[ ] Batch GAMLSS vs R

just as a minor note, integration tests, i.e., that fit and predict and update work as intended, would be automatic when using parametrize_with_checks from skpro or sktime


Add Images for Documentation Here

To create weblinks for images in the package documentation, make a new post in this issue and drag/drop images into the comments field. Copy/paste the weblink that appears.
Examples
UML Diagram for previous model versions :
https://user-images.githubusercontent.com/10178857/158027958-449be0c6-69e0-4f18-b6c9-c97a42bbf698.png

pydeps Module Dependency Diagram:
https://user-images.githubusercontent.com/10178857/158029011-2a1118b7-05e9-4317-934a-7510e723897d.png

I'm closing this issue as its utility seems limited.


how to get value of the column in form before edit

hi
how do i get all value of columm in the form before edit and submit
example:
my table sip_user(userid, password_hash, domain, usercontext) value (7000, 7c8996bd8cbf6292697dced08be86c25, abc.com, default)
and then i edit my table with value(8000, 7c8996bd8cbf6292697dced08be86c25, abc.com, default)
how to get the value (7000, 7c8996bd8cbf6292697dced08be86c25, abc.com, default) before press submit button
thank you

I came up against this problem recently too. I ended up accessing SQLAlchemy's history inside of _on_model_change. Here's an example of using SQLAlchemy's history: http://stackoverflow.com/a/18605213/1364191


Build failure with GHC 7.10

 ~/src/vty % cabal --version
cabal-install version <IP_ADDRESS>
using version <IP_ADDRESS> of the Cabal library

 ~/src/vty % ghc --version
The Glorious Glasgow Haskell Compilation System, version <IP_ADDRESS>41222

 ~/src/vty % cabal build
Building vty-5.2.6...
Preprocessing library vty-5.2.6...
[21 of 33] Compiling Graphics.Vty.PictureToSpans ( src/Graphics/Vty/PictureToSpans.hs, dist/build/Graphics/Vty/PictureToSpans.o )
<command line>: can't load .so/.DLL for: libtinfo.so (libtinfo.so: cannot open shared object file: No such file or directory)

Thanks!
I don't have a 7.10 environment yet. I'll try installing vty once I do. I don't have a system that uses libtinfo. AFAICT libtinfo.so is a alias for ncurses?

https://aur.archlinux.org/packages/libtinfo/

Looks like a template haskell environment issue.
Template haskell cannot find the .so for this library. Typically this occurs if the --extra-lib-dirs does not contain libtinfo.so (or libncurses.so in my case).
What are the configure options and where is libtinfo.so location? EG: shared/static?

I've managed to install vty on that machine (gentoo without libtinfo.so) after cloning terminfo, running autoreconf and cabal-installing it. I'm not sure what's the root cause, maybe a hackage version of terminfo has configure script expecting libtinfo.so to be available.

Closing in favor of #82.
This is another  "bug" caused by requiring a native terminfo library. Too bad I didn't keep a list of all the pain points in setting up build environments properly because of this. haha. There are a lot.

I'm having this problem on OpenSUSE.  On some forum I read that curses split into two libraries, and a recommendation to symlink libtinfo to libncurses, but I can't do that.  I'd love to see this fixed, as I'm interested in trying http://yi-editor.github.io/

As stated previously: this is an issue with terminfo library. Not vty. Please file an issue with that project.

I'm not complaining, I'm voting for moving over to the terminfo-hs library... actually I guess that comment belonged in #82

Ah! My apologies. Yes: definitely vote for #82. :)
On Sun, Dec 27, 2015, 9:49 AM shanemikel<EMAIL_ADDRESS>wrote:

I'm not complaining, I'm voting for moving over to the terminfo-hs
library... actually I guess that comment belonged in #82
https://github.com/coreyoconnor/vty/issues/82
—
Reply to this email directly or view it on GitHub
https://github.com/coreyoconnor/vty/issues/65#issuecomment-167373644.


How to start firefox-nightly?

Use the firefoxExecutable property in your launch configuration or firefox.executable in your VS Code settings. This is documented here.

Thank you!


Reduce memory usage in testgit (#15306)

Backport #15306

from
real    3m11,910s
user    4m4,363s
sys     0m38,704s

To:
real    3m2,304s
user    3m32,308s
sys     0m34,163s

make L-G-T-M work.


chore: vendor dependencies

Changes
Vendor dependencies. This will help resolve conflicts when running multiple prow test jobs.

@lance FYI I've opened depedency update PR, it should be merged prior to vendoring the whole universe or just bump the version as part of this PR.


HDDS-7718. Bump Netty to 4.1.86 and gRPC to 1.51.1

What changes were proposed in this pull request?
Upgrade Netty to 4.1.86 and gRPC to 1.51.1 (same as in RATIS-1760).
https://issues.apache.org/jira/browse/HDDS-7718
How was this patch tested?
Regular CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/3828414627

Should we wait for RATIS-1760 to be closed and a release cut?

Should we wait for RATIS-1760 to be closed and a release cut?

No need for that.

Thanks @kaijchen for reviewing and committing it.


Postgres 10 images do not use --waldir instead of --xlogdir

The Postgres 10 docker entrypoint passes invalid parameters to initdb.
The --xlogdir parameter has been replaced with --waldir.
Trying to use the POSTGRES_INITDB_XLOGDIR env variable fails entirely on startup with
an empty folder.

Oh, it was just rename. It seems no one has tried to use it since we created the 10 beta image in June.  Thanks for pointing it out; let me work up a PR. :smiley_cat:

Excellent. For anyone searching. I worked around this issue using "POSTGRES_INITDB_ARGS" with the --waldir parameter set appropriated.

Updated images should be pushed to Docker Hub shortly: https://github.com/docker-library/official-images/pull/3718.


Add Instant Bandit backend support

Current dependencies on/for this PR:

main

PR #14

PR #15

PR #16

PR #17

PR #18   👈

This comment was auto-generated by Graphite.