Alternate background colors for lines

This will be part of the experimental features we may ship in the beta release.

A pure CSS solution has some drawbacks, as demonstrated in issue 18:

it will only work reasonably well in the scrolled view;
we have to claim responsibility for at least the line-height (paragraphs);
you can end up with the same background color at the end of one paragraph and the beginning of another;
I’m unable to tell how much memory and CPU this will consume since linear-gradient is quite heavy, CSS-wise.

Possible alternative is something like lining.js, which might bring support to the paged view – right now, I can’t tell.

Related: https://twitter.com/Bunker_D_/status/994921740039008256 (sorry, tweet in French)
But you can test the Chrome or Firefox extension.
Unfortunately, I could neither find a repo nor an account so it’s difficult to get insights about this particular feature and its implementation.
Help from @garconvacher to contact the creator of this extension, maybe?

Oops... I didn't see your request for help before :-/
I'm going to dig.

Thanks @garconvacher 🙏

Did a super quick test with lining.js and results are obviously a lot better since each line is wrapped in a <text-line> element.

As you can see, works with pagination.
The main caveat though is that you have to modify the DOM and this can possibly screw the CSS cascade + it takes some time to update when resizing the window – it’s pretty visible, I’d say it’s feeling like 1 second or so.

(Found this tweet from the developer of the DysAide extension. I send him a PM on Twitter with a link to this thread :) )

@JayPanoz

The main caveat though is that you have to modify the DOM and this can possibly screw the CSS cascade + it takes some time to update when resizing the window – it’s pretty visible, I’d say it’s feeling like 1 second or so.

Also, modifying the DOM potentially breaks existing CFI references that are used internally to record bookmarks / annotations.
In Readium "1" there is a mechanism / API to blacklist DOM fragments during CFI "processing" (i.e. when a CFI expression is generated from a DOM location / range, and when a DOM location / range is resolved from a CFI expression). If I remember correctly, blacklisted DOM fragments are effectively ignored from the root down (in their entirety), in other words it is not possible to "skip" intermediary wrapping elements such as <text-lines> added by the lining.js utility library.
PS: blacklisted elements are defined via their ID or CSS Selector, and this typically includes well-known items such as the additional HTML markup that can potentially be injected by MathJax.
In Readium2 there is currently no such mechanism at all, ... but then there is no real support for CFI either, yet ;)  That being said, readium-desktop currently uses a CSS Selector to record the reading location (DOM element), so modifying the DOM in order to implement special reading system features (such as line-by-line highlighting, page-break formatting, etc.) still has a disruptive ; if not destructive ; effect.

This has been resolved during today’s engineering call.
Here are the notes:

Pushed by associations for dyslexic / dyspraxic people
Difficult with CSS (because of columns).
With some time, JS and CSS, we could get something. With the code blocks used for highlighting. - Complexity is when there are images or other complex structures.
Probably done by others already. Maybe contact Learning Ally, Mobidys.
Here’s a proof-of-concept: http://jsfiddle.net/Fptq2/4/
MS Immersive Reader SDK is an interesting solution, but not free. https://www.onenote.com/learningtools

So this is out of scope for Readium CSS, and should be handled programmatically.

Instead of closing this issue, could we move it to the architecture repo? I think that all of these discussions are still relevant to our project.

Ah so I can reopen the issue but not transfer it via the built-in feature.
But someone being an admin in both the ReadiumCSS and Architecture repos should be able to do so.

Issue moved to readium/architecture #114 via ZenHub


parser+typechecker: Implement restricted(Foo,Bar,Baz) visibility qualifier

This corresponds to the Badge<Foo> pattern in Serenity. A restricted method or field is only accessible to the types listed, allowing more granular access control than public and private.
As implemented, a restricted(Foo, Bar) function hello() {} is only accessible to Foo and Bar. Their subclasses cannot access it, and nor can the class where hello() was defined, unless it's listed. Neither of those can be done with Serenity's Badge either, but it might be nice to support them.

Added hints to the error messages, as suggested by Mr Byte.

Looks cool, has conflict :)

Fixed the conflict, it was a nice easy one. :^)


add visual servo Objective to ur_site_configs

Adds Visual Servo Objectives to the UR5 site configs.
This is to run them on the real UR5s.
Follow-up will update picknik_ur5e_configs to bump the submodule to include this change.
Closes https://github.com/PickNikRobotics/moveit_studio/issues/5922.

I tested it on the hardware and it worked great! I left one comment, but otherwise looks good.


Release Amplify Codegen v2.26.6

Description of changes

Add manyToMany directive for relation improvement
Remove UUID check for java modelgen
Add additional regions for e2e tests

Issue #, if available

Description of how you validated changes
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[x] Relevant documentation is changed or added (and PR referenced)
[x] Breaking changes to existing customers are released behind a feature flag or major version update
[x] Changes are tested using sample applications for all relevant platforms (iOS/android/flutter/Javascript) that use the feature added/modified

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

Codecov Report

Merging #246 (87c1176) into release (d05da1e) will increase coverage by 0.18%.
The diff coverage is 97.05%.

@@             Coverage Diff             @@
##           release     #246      +/-   ##
===========================================
+ Coverage    85.34%   85.52%   +0.18%
===========================================
  Files          144      144
  Lines         6551     6605      +54
  Branches      1475     1517      +42
===========================================
+ Hits          5591     5649      +58
+ Misses         879      875       -4
  Partials        81       81

Impacted Files
Coverage Δ

...elgen-plugin/src/visitors/appsync-swift-visitor.ts
95.76% <ø> (ø)

...nc-modelgen-plugin/src/visitors/appsync-visitor.ts
95.42% <95.34%> (+2.47%)
:arrow_up:

...odelgen-plugin/src/utils/process-connections-v2.ts
90.32% <100.00%> (+3.36%)
:arrow_up:

...delgen-plugin/src/visitors/appsync-java-visitor.ts
93.02% <100.00%> (-0.09%)
:arrow_down:

Continue to review full report at Codecov.

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


New Update Method.

Hello, i like this program but ur update method is kinda bad, you should take a look to Squirrel.NET.

@ffgapple Use {Scoop.sh]().


[Hub Generated] Review request for Microsoft.HybridCompute to add version stable/2020-08-02

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Contribution checklist:

[x] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

/azp run automation - sdk

The generated PR was released but I forgot to merge this one. Sorry.

The generated PR was released but I forgot to merge this one. Sorry.

/azp run

/azp run

@ArcturusZhang would you please help to check 'SDK azure-sdk-for-go' failure? Thanks

@ArcturusZhang would you please help to check 'SDK azure-sdk-for-go' failure? Thanks

/azp run

/azp run


SAKIII-4875 Fixes per code review on Github

https://jira.sakaiproject.org/browse/SAKIII-4875

Moved to https://github.com/sakaiproject/3akai-ux/pull/1705


Use the correct URL in nova-api F5 heath checks

The v3 endpoint went away.  Both v2 and v2.1 are in use in
Liberty, however, going forward v2.1 seems to be used more (see
current upstream Mitaka docs).  Because of this, we change the
healthcheck to monitor the v2.1 endpoint.
related: #965

recheck_upgrade

recheck_upgrade

recheck_upgrade

recheck_upgrade

recheck_upgrade

you know, one of these times....

Please ignore the job labelled default.

@prometheanfire I think you'll need to rebase to pass continuous-integration/travis-ci/push because it's still failing on something that has been fixed in master.

Ya, that's because it's checking out my branch, not testing it as merged with master.  Kinda a useless test :|

:+1:  I don't have an F5 to test on, but this change makes sense

👍


TypeScript Map<T, U>  type check bug Object is possibly 'undefined'.ts(2532)

Bug Report

🔎 Search Terms

Object is possibly 'undefined'.ts(2532)
🕗 Version & Regression Information

test versions ^4.7.4 and 4.9.4

⏯ Playground Link

Playground link with relevant code
💻 Code

function majorityElement2(nums: number[]): number[] {
  const base = ~~(nums.length / 3);
  const map = new Map<number, number>();
  const set = new Set<number>();
  for(const num of nums) {
    if(!map.has(num)) {
      map.set(num, 1);
    } else {
      map.set(num, map.get(num) + 1);
    }
    if(map.get(num) > base) {
      set.add(num);
    }
  }
  return [...set];
};

🙁 Actual behavior

TypeScript can not understand the if...else condition, and shows an error.

🙂 Expected behavior

TypeScript can understand the if...else condition, without showing an error.
It should work like below with optional chaining ??.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining
function majorityElement2(nums: number[]): number[] {
  const base = ~~(nums.length / 3);
  const map = new Map<number, number>();
  const set = new Set<number>();
  for(const num of nums) {
    if(!map.has(num)) {
      map.set(num, 1);
    } else {
      map.set(num, (map.get(num) ?? 0) + 1);
    }
    if((map.get(num) ?? 0) > base) {
      set.add(num);
    }
  }
  return [...set];
};

Duplicate of #30268 / #9619.

~~(nums.length / 3)

I know this isn't related to the issue but you might want to think twice about using ~~ in place of Math.floor - it coerces to 32-bit:
> ~~3000000000
-1294967296

Ouch.

Yeah, you are right. Thanks for your time.
But in my scenario, using it is not only suitable but also improves performance, nothing more.

but also improves performance

Did you actually measure if it has a positive performance impact in your application? Otherwise you should prefer clean and easy to understand code. I wouldn't have a clue what ~~number does and would first have to look it up. Probably every time I see it, given the obscurity of it.

@MartinJohns
Your question is beyond the topic of this issue.
If you don't know something new, maybe you should take the initiative to learn it first.
this article might help you
<EMAIL_ADDRESS>

Oh wow, what astonishing ignorance.

You completely missed the point of my comment.

Because it's a duplicate of another issue


fix/deps: upgrade rollup-plugin-typescript2 to fix cache issue

Bumped into #888/#892 when creating a new repo, and the workaround mentioned here didn't work for me.
This patch brings in the permanent fix from ezolenko/rollup-plugin-typescript2#243. Tested by yarn linking tsdx across repos, and the build looks to be working ok with this change.
Guess dependabot would have eventually updated this dep, but figured it was important enough to do ASAP?

Thanks for the patch @tanem -- was actually looking to bump this myself once v0.28.0 is released, because that will contain my fix that was recently merged: https://github.com/ezolenko/rollup-plugin-typescript2/pull/221 (which resolves a few issues and does a root cause fix for a PR of mine in TSDX)

and the workaround mentioned here didn't work for me.

If that didn't work for you could you provide more details on that? Neither nuking the cache nor all of node_modules worked?
That might suggest https://github.com/ezolenko/rollup-plugin-typescript2/pull/243 isn't a root cause fix then. Though now I think I understand why it's occurring, it's because the cache dir was changed/set to the default in #691 . But if everything is nuked that should be the same as a new install / fresh slate, which should be handled... And #691 was released in v0.13.3... And cache only gets rolled after a build, not before... 🤔

Tested by yarn linking tsdx across repos, and the build looks to be working ok with this change.

💯

Guess dependabot would have eventually updated this dep

I've temporarily disabled it because all the dep updates were spammy (duplicate PRs, unnecessarily updating patches/minors, updating peerDeps that can't be updated in isolation, etc). Need to add a bunch of filters to it, but even then, it's not feasible, not always necessary, and may actually be a bad idea stability-wise to update deps immediately after release.
Whereas a PR like this or bugs reported actually demonstrate a need to update.

Hey @agilgur5 👋
Here's what I did to get the issue:
$ npx tsdx create my-lib
[chose react template]
$ cd my-lib
$ yarn build --format cjs,esm,umd
[error]

Then I tried:
$ rm -rf node_modules/.cache/rollup-plugin-typescript2/
$ yarn build --format cjs,esm,umd
[error]

Finally:
$ rm -rf node_modules
$ yarn
$ yarn build --format cjs,esm,umd
[error]

Once I applied the update in this PR to my local copy of tsdx, then linked that over to my-lib, yarn build --format cjs,esm,umd ran without error.

On the topic of dependabot, have you considered using Renovate instead? I find it gives a lot more control in terms of how much noise you have to deal with as a maintainer. It also has a stabilityDays config option which addresses your point about updating immediately following a release.
One thing it doesn't do that dependabot does do is update nested dependency versions for security updates (hopefully I described that correctly, don't want to misrepresent Renovate 😅). In those cases, I've seen other open-source repos use dependabot just for security patches, and renovate for the rest. For my own repos I usually manually update if I need a security patch applied promptly.

Thanks for the additional details @tanem

$ npx tsdx create my-lib
[chose react template]
$ cd my-lib
$ yarn build --format cjs,esm,umd
[error]

This is pretty intriguing; I thought most folks, like Jared, were getting this during an upgrade of TSDX, but this is happening to you on a fresh install.... yea that's even more confusing since rpts2 hasn't been updated since TSDX v0.13.0 / #506 . And #691 / #758 were the only changes to the options and were in v0.13.3... but for some reason this wasn't discovered until v0.14.0 🤔 🤔
The cache code initiates both directories in its constructor which would by definition be called before its roll() call... weird.
#691 made it so it was a single cache instead of a per-format cache (because the config is hashed anyway) so I guess it may have created a race??
Will have to follow up on this upstream

On the topic of Dependabot, have you considered using Renovate instead?

I have not. I didn't realize Renovate did dependencies, I thought it was an automated merge bot for some reason based on past usage I'd seen.
It seems to have an enormous list of configuration options that are potentially useful, though even those don't handle cases like https://github.com/formium/tsdx/pull/889#discussion_r496208822 . Dependencies are pretty manual in my experience; updating all the time without a defined need just adds a lot of noise.
Also recently switched from Greenkeeper to have even more issues with Snyk (as linked above), then to Dependabot (#846 ), so I'm not clamoring to change and learn another potentially problematic bot, especially if I need to use two for security issues (which are the few that are quite important / aren't noise) 😕  But I'll keep it in my mind for the future

I had checked this already when looking to update previously, but confirming here that I see no relevant breaking changes in rpts2 v0.27.0. The release notes aren't particularly detailed but the diff was small enough to read through and check.

Reproduced and confirmed #892 as well as did some more investigations there, including finding that this bug did start with TSDX v0.13.3, just with less popular combinations of formats than v0.14.0 for unknown reason.
I'm not going to wait on the release of https://github.com/ezolenko/rollup-plugin-typescript2/pull/221 / rtps2 v0.28.0 anymore since this issue seems to be quite widespread, #898 and #900 hit into it as well.
I'll probably merge and release TSDX v0.14.1 tomorrow, but I'd like to add a smoke test that tests a build of all formats simultaneously to confirm this works and doesn't regress. Apparently there weren't any tests of umd or system before, can't remember why I didn't add them when I built out a lot of the test suite in #627... maybe I was just sticking to integration tests then.. 🤔

@allcontributors please add @tanem for bug, code

@agilgur5
I have the feedback.
I had released 2 new versions of my library @react-google-maps/api
1.12.1 includes tsdx update to 0.14.1
1.13.0 includes updated<EMAIL_ADDRESS>I see the bundle size grow from 15.2kb to 17.5kb for no obvious reason.
https://bundlephobia.com/result?p=<EMAIL_ADDRESS>- bundle size is grown after update tsdx
https://bundlephobia.com/result?p=<EMAIL_ADDRESS>- bundle size did not changed by updating webpack version
There is definitely some degradation in build tool optimizations.

for no obvious reason.
There is definitely some degradation in build tool optimizations.

@JustFly1984 you upgraded from v0.13.3 to v0.14.1, i.e. two versions, one of which was a breaking change. The v0.14.0 Release Notes are very explicit as to possible bundle size increases and even give directions on reductions, please read those.
As such, this is unrelated to v0.14.1 or this PR, so this is not the right place either.

@agilgur5 thank you for clarifications!

Thanks for the merge @agilgur5 🙏


Breadcrumbs

Trying develop a breadcrumb snippet:
      {%- if current_page.id == '/' -%}
        This is the homepage
      {%- else -%}
        home/{{ meta.title }}
      {%- endif -%}

This doesn't work, so what i try to do:

When the user on the homepage, show intro text
Else show the breadcrumb-links

The most md-files have the meta attribute template.
The templates are province, city and dogzone.
Is there a way build an if-statement like this:
{%- if {{ page.meta.template }} == 'province' -%}
...
{%- elseif {{ page.meta.template }} == 'city' -%}
...
{%- elseif {{ page.meta.template }} == 'dogzone' -%}
...
{%- endif -%}

Or is it possible check the twig template files:

province.twig
city.twig
dogzone.twig

Hope someone can give me a hint?

Okay,
I found, it is not page.meta.template, but meta.template .
Okay but how test, if it is the homepage?
Try this, but doesn't work:
{%- if current_page.id == '/' -%}
...
{% endif %}

Hey there. 👋🏻
Sorry, getting behind on things again. 😅
So, is_front_page is actually depreciated.  This is why it isn't mentioned in the Docs.  It's from Pico 1.0 and earlier.
If I had to guess, you're probably not using a pico-theme.yml file in your Theme, which means the Pico Deprecated plugin is giving you access to old stuff like is_front_page (it's assuming your Theme is very old).
The proper way to do this is like your earlier example, except the page id isn't /, it's index.
{% if current_page.id == "index" %}
...
{% endif %}

Though, if is_front_page is more readable for you (or more convenient, if you're using it frequently), there's no reason you couldn't define it yourself.
{% if current_page.id == "index" %}
  {% set is_front_page = true %}
{% endif %}

Hey there. 👋🏻
Sorry, getting behind on things again. 😅
So, is_front_page is actually depreciated. This is why it isn't mentioned in the Docs. It's from Pico 1.0 and earlier.
If I had to guess, you're probably not using a pico-theme.yml file in your Theme, which means the Pico Deprecated plugin is giving you access to old stuff like is_front_page (it's assuming your Theme is very old).
The proper way to do this is like your earlier example, except the page id isn't /, it's index.
{% if current_page.id == "index" %}
...
{% endif %}

Though, if is_front_page is more readable for you (or more convenient, if you're using it frequently), there's no reason you couldn't define it yourself.
{% if current_page.id == "index" %}
  This is the homepage
{% endif %}

No problem @mayamcdougall , i'm happy you or other member(s) answers within a few days :smiley:
hmm, very strange, there is a pico-theme.yml exist.

Change my code and works like a sharm :heart_eyes:
{%- if current_page.id == "index" -%}
This is the homepage
{%- elseif meta.template == 'city' -%}
...
Where can i found all the attributes and functions in Pico? Not all this stuff is documented in the docs. I found is_front_page in one of the available pico theme's.

hmm, very strange, there is a pico-theme.yml exist.

I'm not sure then. I'm not an expert at Pico's inner workings. 😅
The is_front_page variable is definitely deprecated though.  You can see it in the changelog.  It was introduced in Pico 0.5, and removed in 2.0.
So, I'm not sure what is triggering it, but it's definitely only being provided by pico-deprecated, and isn't something you should use in modern code. (@PhrozenByte, is this accurate? Are there other situations that could result in pico-deprecated being activated?)
Actually, come to think of it, I think you were using some older plugins, right?  I'm not sure if the compatibility modes for Themes and Plugins are triggered separately, so it's possible that those might be what's causing pico-deprecated to run.
Other than a lack of documentation around pico-theme.yml, I'm not sure as there's anything outright missing from the Docs.  The main issue is that the Docs are very information dense and often explained somewhat poorly.
All of the "attributes and functions" you're looking for are listed under the Customizations > Themes section that you've seen before.  If there's something you saw in another Theme that you can't find in the Docs, it was probably either removed from Pico a long time ago (like is_front_page) or maybe it was being provided by a plugin.
And, I know I've linked them before, but the Twig Docs are also really handy for looking up all of Twig's functions.  I tend to use them more than Pico's Docs, as usually when I'm coding a theme, it's Twig functions I need to search through (and/or remember how to use 😅 ), not Pico-specific ones.
Finally, if you're interested, you can view my Work-in-Progress Docs Rewrite*, which attempts to simplify things and break topics into their own pages. Theming with Twig would be the page to look at, though other than the revised content, the lists of Pico-specific variables will be largely the same as what's already in the Docs.
(* Not a permalink, as sometimes I need to point GitHub Pages to a different branch, depending on what I'm working on.)
(And any feedback you want to give on that project is appreciated.  Maybe someday I'll even finish it. 😅😒)

So, I'm not sure what is triggering it, but it's definitely only being provided by pico-deprecated, and isn't something you should use in modern code. (@PhrozenByte, is this accurate? Are there other situations that could result in pico-deprecated being activated?)

Old plugins also trigger the deprecated theme features, because plugins might also include Twig templates.
I'm a bit ambivalent about PicoDeprecated in general, because it doesn't create any real reason to actually upgrade stuff. On the other hand we have a pretty limited number of 3rd-party plugins and themes, a lot of them unmaintained, so dropping more features more frequently is a likely a bad idea, too. So, in the end it's a trade-off...

@PhrozenByte @mayamcdougall ,
Indeed there is a older plugin installed (Pico Editor) so this can be the reason :smiley:
Hi thanks for the info, this link is really useful and help me a lot, also the Twig docs are very handy :smiley:

@PhrozenByte Maybe PicoDeprecated should be optional?  Either a separate download or require it to be manually enabled?
In a perfect world, that would probably help, but unfortunately, I don't think there's enough active developers for that to actually "incentivize" any updates.  It'd only be inconveniencing users. 😔
If we did want to force this change though... 3.0 would technically be a good time to do it, since theme compatibility is already breaking. 😓

Hi thanks for the info, this link is really useful and help me a lot, also the Twig docs are very handy 😃

No problem. 😉
Glad you like the rewrite.  If I could just get around to finishing the rest of it, maybe we could update the website with it, lol. 😅
And yeah, the Twig Docs are great.  I plan to mention them more in the rewritten docs, because they really are the best place to learn everything you'd ever need to know about Twig.
It's funny because, if you ask me, there's more to learn about Twig than Pico.  Once you've mastered it, you can really make just about anything you'd ever want in Pico. 😁

It's funny because, if you ask me, there's more to learn about Twig than Pico. Once you've mastered it, you can really make just about anything you'd ever want in Pico.

I know, but sometimes there are specific Pico variables(?), so the Puico doc pages can help devs a lot.
I'm starting my own picocms-notes.

I know, but sometimes there are specific Pico variables

I mean, there's pages, and knowing how to navigate its contents (page content, metadata, etc).  But other than the few tidbits you see in the section I linked (the meta properties and the few Pico-specific filters), there really isn't anything else.
It's more about knowing how to leverage that data, like with the snippets you're collecting. 😉
In the end, I would like to provide more snippets like those in the Docs rewrite.  I plan to have a dedicated page for them.  Just some nice, free, building blocks to get people started with things that go deeper than what the Default Theme shows.


Session Page

Fixes #30
Description
This PR is for the session page. While the design is clear on what should be displayed, there were certain edge cases not accounted for such as multiple speakers in one session, and also the design does not explain what happens when the share button or twitter handle is pressed. Moreso, the data structure lacks twitter_handle field so I have added some helper functions to handle this.
Fixes # (30)
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] 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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

This issue will be closed as soon as the PR gets merged, but there are some things that still need to be done on this screen. We have some TODOs in the code, but it is better to make a new issue for these remaining tasks for better visibility. @kharioki Can you open a new issue to remind us to work on what happens when we press the star icon, the share button and the twitter handles, and working on a proper "Session not found" screen to cater for broken slugs? The designs are missing these things and @brianwachira needs to get more info.

True, I hadn't comprehended some of these features.

The star icon bookmarks a session, ( there's an endpoint for that) then on the sessions screen you can toggle the view to see only your bookmarked sessions.
Twitter button upon tapping it, it takes you to the speaker's Twitter profile. However, there are scenarios where a speaker didn't have a handle.
The "Session Not Found " one...hadn't thought of that.
Lemme inquire what that share button should do.


Copy nvcomp-2.3 shared libs from the cudfjni build

Add support for building with the nvcomp-2.3 shared libraries release.
Most of the work for supporting nvcomp-2.3 is in related cudf PR: 10837.  For spark-rapids-jni, all we have to do is copy the shared libraries from that build so they can be included in the resulting jar file.
NOTE: we should not merge this until the CUDF support is finalized.  It is possible that changes on the CUDF side might require changes here as well.  For this reason, I am filing this as a draft PR.

build


Enable USB serial and other improvements

This PR enables USB serial support. It also adds cmake options instead of the prior status of uncommenting defines.
Additionally, there are some minor cleanups, and the USB device now uses a unique serial number.

Note, USB serial has been made optional, and is disabled by default for now.

Looks good to me.


Update AKS Create example help text to reflect change of defaults to Standard LB and VMSS

Fixes #11642

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[X] I adhere to the Command Guidelines.

@qwordy can we merge this fix? causing some user confusion currently

@qwordy can we merge this fix? causing some user confusion currently

OK


Downloads hang at 99%

Downloads seem to almost complete but stall just short of 100% (3069 / 3089) seems to occurr with very long streams or large files.

I've experienced this issue several times too. Today for example. The cause is that you don't have enough free space on your disk for temp files needed to convert the stream. Once you make enough free space on your disk restart your download and it will finish.


Provide panelapp linkouts

Currently the panelapp list does not provide any linkouts. These would be useful to quickly inspect the original panelapp information, especially why genes were included in certain panels.
Panels themselves should provide a linkout to the specific panelapp panel.
Genes should provide a linkout to the panelapp Gene description: e.g. https://panelapp.genomicsengland.co.uk/panels/entities/<GENE NAME>

In addition the gene specific panel descision and description can be accessed via https://panelapp.genomicsengland.co.uk/panels/<panel id>/gene/<GENE NAME>/


[ART-5914] Automatically trigger build sync after gen-assembly

Automatically trigger build sync after gen-assembly and comment the link of the build sync URL on the auto generated PR.
Changes:

gen-assembly: new TRIGGER_BUILD_SYNC option which will trigger build-sync with the auto-generated PR
build-sync: if triggered with assembly (not with stream) and DOOZER_DATA_GIT_REF is not empty, it will try to look for the PR and comment before and after the job. If failed, it will report that as well. It will work for build-sync directly triggered by humans as well.

Continuation of https://github.com/openshift-eng/aos-cd-jobs/pull/3605

Tested gen-assembly (job), automatically triggered build sync job
Test build-sync run which commented on PR
Test build-sync commented on the PR that I created from my own branch

Changes look good! Now the only thing missing is tests for the new code, let's add some basic unit tests

Let's add 1/2 unit tests for the new code

Okay I'll work on those, but not sure if I can finish it today. So can use this feature in next week's release then

If https://github.com/openshift-eng/aos-cd-jobs/pull/3925 is merged, please migrate this PR to art-tools, if not urgent.
If urgent, please create a duplicate PR to art-tools.

/hold for the corresponding art-tools PR

Moving to my fork


GoPro Fusion - overview() is erroing

Hi Konrad,
I have just noticed that the overview() method return a error.
gpCam = GoProCamera.GoPro(constants.gpcontrol)
gpCam.overview()

return this :
camera overview
current mode: Video
current submode: Video
Traceback (most recent call last):

  File "<ipython-input-9-c0b03d50bfb9>", line 1, in <module>
    gpCam.overview()

  File "C:\Users\harry\Anaconda3\lib\site-packages\goprocam\GoProCamera.py", line 1027, in overview
    print("current video resolution: " + "" + self.parse_value("video_res",self.getStatus(constants.Status.Settings, constants.Video.RESOLUTION)))

TypeError: Can't convert 'NoneType' object to str implicitly

Any ideas ?
H.

Try now with the latest commits

Fixed in e51c56b7f6c3f97a4fe62d2945228c9093947908 . Tested on Fusion 1 with 1.80 FW.


Can we apply styling in json_to_sheet and sheet_add_json

I want to apply style to my excel sheet like align center and border but didn't found any.
I am working like this.
xlsx.utils.json_to_sheet(arrayOfObject, { skipHeader: false, origin: 'A1' });
And I want something like below:'
xlsx.utils.json_to_sheet(arrayOfObject, { skipHeader: false, origin: 'A1' , align: 'center'});
Is there any way to do so

Cell styling is a feature of our Pro builds


changed naming of jobs

@psiroky pls review this and let me know if you're fine with the job renaming

Do we have a naming scheme that all the jobs follow and that we should follow from now on?

This is the naming scheme suggested by @mbiarnes (next time please do share this kind of info directly in the comment, so that others (who are not part of the e-mail discussions) can have the same info)
daily builds:         <jop purpose>-kieAllBuild-<branch>
kie releases:         <job purpose>-kieReleases-<branch>
PR jobs:              <rep>-pullrequest-<branch>
normal build jobs:    <rep>-<branch>

This should be fine as long as we stick to it consistently.

@psiroky did much changes and at the end I did git commit --amend - thus a new OR was created
we can close this one

@mbiarnes please don't create new PRs when changing an already existing PR. We loose all the comments and all the reviews. Let's leave it this time since it's already done, but please think about this for the future PRs.

@psiroky yep - it was not my intention to create a new PR - now I know that changing wit --amend the commit message a new PR is created. I will not do it again.

Amending the commit will not create new PR. It will just update the current commit. After that you need to force push into your fork and the PR gets automatically updated.

this PR will be closed since another already merged PR #32 does the same thing


Add WHZ_KRB5_DIR environmental variable to the search path for gss-jass.conf & krb5.conf files.

Also remove the unset WH_HOME directory from the search path.

Coverage remained the same at 0.0% when pulling 5e934a561a438e4e9bb866ff410992c353df10be on mars-lan:krb5 into 6c2d63da327cd1c6757613b32d2479419b43138f on linkedin:linkedin.


[tests-only] allow single suite pipeline to be defined without a list

see https://github.com/owncloud/ocis/pull/922#issuecomment-731985967

Needs a rebase due to ther .drone.star changes in master. I will do that in a moment.


Supporting BoolQA through run_mrc script

jaydesen created the following on May 25:
boolqa functionality should be supported under the same run_mrc script .
Original issue: https://github.ibm.com/ai-foundation/PrimeQA/issues/215

inference-only pipeline for boolean questions in Tydi incorporated into run_mrc.py


Upgrading from 0.4.6 instructions, can I still use with navigation controller?

Hi,
I've been happily using MFSideMenu 0.4.6 for some time, however with iOS8, there's a bug when calling...
[self.sideMenu setMenuState:MFSideMenuStateClosed];
.. from a row, that fails to hide the side menu.
To be honest, I'd be happy if I could just work around this, I think, unless there are other issues I've not found. Perhaps you might comment on this?
But I am keen to upgrade to the latest version, however I'm using a navigation controller and following the old 0.4.6 functionality approach. Can you offer me any advice and if possible any guidance about upgrading?
Thanks so much, in advance.
Best regards,
Jules.
PS. Good job with the library :)

Just to highlight my current setup... in appdelegate I have....
I can't find example code showing tab controller with multiple navigation controllers.
self.tabBarController.viewControllers = [NSArray arrayWithObjects:[self cbSideMenu].navigationController, navController2, navController3, navController4, navController5, nil];

self.window.rootViewController = self.tabBarController;

Then...
- (MFSideMenu *)calcBalSideMenu {

SideMenuViewController *leftSideMenuController = [[SideMenuViewController alloc] init];

UIViewController *vcCB = [[CBViewController alloc] initWithNibName:@"CBView" bundle:nil];

UINavigationController *navController1 = [[UINavigationController alloc]
                                          initWithRootViewController:vcCB];

navController1.tabBarItem.image = [UIImage imageNamedTK:@"calc"];

MFSideMenu *sideMenu = [MFSideMenu menuWithNavigationController:navController1
                                         leftSideMenuController:leftSideMenuController
                                        rightSideMenuController:Nil];
leftSideMenuController.sideMenu = sideMenu;

return sideMenu;
}


PinBuilder has trouble centering some high-Unicode symbols

Sandcastle example: I kinda-sorta made Character Map in Cesium
Browser: Chrome
Operating System: Win10
I'm trying to use symbols ("wingdings"?) as icons on PinBuilder pins, and sometimes the result looks a little off:

I'm not sure if this is the font, or Canvas, or the browser, or some combination of thereof -- and I don't know if Cesium can do anything about it -- but I thought I should at least check here.  If it turns out that this is e.g. Chrome's fault, I'm happy to file an issue with them instead.

I've updated my Sandcastle example to draw the same characters in a table, letting the browser center them, here.

The "problem" symbols center correctly:

while in PinBuilder they're pretty far off:

Looking through the PinBuilder cold, the line that calculates the position of the icon is below:
Permalink
// x and y are the center of the pin box
var x = Math.round((size - sizeX) / 2);
var y = Math.round((7 / 24) * size - sizeY / 2);

I wonder why the code does not work for those select symbols.


Batch query test

This adds a test for batch() and each() query with large table as some issues have been reported in the past. The default table will be created with 1000 records to not stress travis too much. You can try it locally by setting the table size to 100 000 or even 10 000 000.
I was not able to reproduce the problem with this test on my machine, maybe someone else can run it and see what happens.

Q
A

Is bugfix?
no

New feature?
no

Breaks BC?
no

Tests pass?
lets wait for travis ;)

Related issues
#8420, #9269

/cc @particleflux can you try this test on your machine?

here is my environment:
$ dpkg -l |grep mysql
ii  libmysqlclient18:amd64                 5.5.47-0+deb8u1                      amd64        MySQL database client library
ii  mysql-client-5.5                       5.5.47-0+deb8u1                      amd64        MySQL database client binaries
ii  mysql-common                           5.5.47-0+deb8u1                      all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  mysql-server                           5.5.47-0+deb8u1                      all          MySQL database server (metapackage depending on the latest version)
ii  mysql-server-5.5                       5.5.47-0+deb8u1                      amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.5                  5.5.47-0+deb8u1                      amd64        MySQL database server binaries
ii  php5-mysql                             5.6.17+dfsg-0+deb8u1                 amd64        MySQL module for php5

$ php --version
PHP 5.6.17-0+deb8u1 (cli) (built: Jan 13 2016 09:10:12)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

with size = 100 000:
$ phpunit --debug tests/framework/db/BatchQueryResultTest.php
PHPUnit 4.8.24-1-g1a1b632 by Sebastian Bergmann and contributors.

Starting test 'yiiunit\framework\db\BatchQueryResultTest::testQuery'.
.
Starting test 'yiiunit\framework\db\BatchQueryResultTest::testActiveQuery'.
.
Starting test 'yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #0 (array(true))'.

Starting test 'yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #1 (array(false))'.

Time: 9.01 minutes, Memory: 61.00Mb

There was 1 failure:

1) yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #0 (array(true))
Failed asserting that 55286712 is less than 36538512.

/home/stefan/yii2/tests/framework/db/BatchQueryResultTest.php:191
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:147
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:99
/home/stefan/.composer/vendor/phpunit/phpunit/phpunit:36

FAILURES!
Tests: 4, Assertions: 206039, Failures: 1.

env (mysql running remote over VPN)
# dpkg -l | grep mysql
ii  libdbd-mysql-perl                  4.021-1+b1                    amd64        Perl5 database interface to the MySQL database
ii  libmysqlclient18:amd64             5.5.44-0+deb7u1               amd64        MySQL database client library
ii  mysql-client-5.5                   5.5.44-0+deb7u1               amd64        MySQL database client binaries
ii  mysql-common                       5.5.44-0+deb7u1               all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  mysql-server                       5.5.44-0+deb7u1               all          MySQL database server (metapackage depending on the latest version)
ii  mysql-server-5.5                   5.5.44-0+deb7u1               amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.5              5.5.44-0+deb7u1               amd64        MySQL database server binaries
ii  php5-mysqlnd                       5.4.45-0+deb7u1               amd64        MySQL module for php5 (Native Driver)

$ php --version
PHP 5.6.18-pl0-gentoo (cli) (built: Mar 12 2016 21:12:13)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans

local libmysqlclient is also 18

With 1M it gets worse:
Time: 3.93 hours, Memory: 289.50Mb

There was 1 failure:

1) yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #0 (array(true))
Failed asserting that 303197336 is less than 36536400.

Another machine with:
PHP (no xdebug this time)
PHP 7.0.4-pl0-gentoo (cli) (built: Mar  8 2016 13:57:47) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
MySql 5.6.29 (localhost), mysqlclient 18
Output:
Running each() query... (Memory: 8532704)[>           ] 0% (64100/10000000) ETA: 537077 sec.

Time: 4.62 hours, Memory: 4393.24Mb

There was 1 error:

1) yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #1 (array(false))
Empty row packet body

/home/stefan/yii2/framework/db/DataReader.php:111
/home/stefan/yii2/framework/db/BatchQueryResult.php:143
/home/stefan/yii2/framework/db/BatchQueryResult.php:112
/home/stefan/yii2/tests/framework/db/BatchQueryResultTest.php:197
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:147
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:99
/home/stefan/.composer/vendor/phpunit/phpunit/phpunit:36

--

There was 1 failure:

1) yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #0 (array(true))
Failed asserting that<PHONE_NUMBER> is less than 31554568.

/home/stefan/yii2/tests/framework/db/BatchQueryResultTest.php:191
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:147
/home/stefan/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:99
/home/stefan/.composer/vendor/phpunit/phpunit/phpunit:36

FAILURES!
Tests: 4, Assertions: 728238, Errors: 1, Failures: 1.

// tests/framework/db/BatchQueryResultTest.php
    protected static $largeTableCount = 100000;
    protected static $largeTableInsertBatch = 100000;

~ $ dpkg -l | grep -E 'mysql|percona'
ii  libmysqlclient18:amd64                      5.6.29-1~dotdeb+7.1                                 amd64        MySQL database client library
ii  libperconaserverclient18.1                  5.6.29-76.2-1.trusty                                amd64        Percona Server database client library
ii  mysql-common                                5.6.29-1~dotdeb+7.1                                 all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  percona-server-client-5.6                   5.6.29-76.2-1.trusty                                amd64        Percona Server database client binaries
ii  percona-server-common-5.6                   5.6.29-76.2-1.trusty                                amd64        Percona Server database common files (e.g. /etc/mysql/my.cnf)
ii  percona-server-server-5.6                   5.6.29-76.2-1.trusty                                amd64        Percona Server database server binaries
ii  php5-mysql                                  5.5.33-1~dotdeb+7.1                                 amd64        MySQL module for php5
~ $ php -v
PHP 5.5.33-1~dotdeb+7.1 (cli) (built: Mar  3 2016 17:11:35)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
    with Xdebug v2.3.3, Copyright (c) 2002-2015, by Derick Rethans
 ~ $ mysql --version
mysql  Ver 14.14 Distrib 5.6.29-76.2, for debian-linux-gnu (x86_64) using readline 6.3

Test:
~/www/yii2 $ phpunit tests/framework/db/BatchQueryResultTest.php
PHPUnit 4.8-g0fe5ed3 by Sebastian Bergmann and contributors.

Time: 8.43 minutes, Memory: 161.75Mb

There was 1 failure:

1) yiiunit\framework\db\BatchQueryResultTest::testBatchHugeTable with data set #0 (array(1))
Failed asserting that 142464504 is less than 34859560.

/home/GURTAM/loal/www/yii2/tests/framework/db/BatchQueryResultTest.php:191
/home/GURTAM/loal/www/yii2/vendor/phpunit/phpunit/phpunit:36

FAILURES!
Tests: 4, Assertions: 136047, Failures: 1.

@cebe I think you should also add a test for batch queries using ActiveRecord. I found, that they currently don't work at all (unless you have the schema already cached by accident). See https://github.com/yiisoft/yii2/issues/8420#issuecomment-295609656.


Could you release a v2 ?

My last PR is actually solving the macOS workflow break, I can already use it with the hash key but it would be easier if you release a v2. would it be possible ?

I've updated the v1 tag, since this is basically still v1 and should even bei compatible with all existing code before.

I didn't know it was possible, even better !


Streaming I/O (pipes, ...)

I would like to output my HDF5 to STDOUT (for piping to other tools like gzip), but currently I can only do that by first writing to a temp file and then copying it to STDOUT. This is awkward and slow due to the unnecessary copying.
Would it be feasible for hdf5::File::open/create to take io::Read/Write implementors, instead of just file names?

I'm afraid Read/Write is not possible, as this is not compatible with the underlying c-library. There is a function H5Fget_file_image one could use to get the underlying bytes. Would this be useful for you?

I'm afraid Read/Write is not possible, as this is not compatible with the underlying c-library. There is a function H5Fget_file_image one could use to get the underlying bytes. Would this be useful for you?

Thanks for the response. H5Fget_file_image would help only with reading, right? Unfortunately that's not what I need.
Do you know if the C library doesn't support streams because it needs to seek while writing, or is it just that no one's requested that?

Thanks for the response. H5Fget_file_image would help only with reading, right? Unfortunately that's not what I need.
Do you know if the C library doesn't support streams because it needs to seek while writing, or is it just that no one's requested that?

It is also possible to write your entire file in memory, avoiding disk entirely. This should avoid the copy entirely, but requires your data to fit in memory. This is not currently implemented in this wrapper.
hdf5 needs random access, either by working in-memory, from a file, or by caching bytes from the network. It is not designed to be used as a streaming format, it acts more like a file system.

It is also possible to write your entire file in memory, avoiding disk entirely. This should avoid the copy entirely, but requires your data to fit in memory. This is not currently implemented in this wrapper.
hdf5 needs random access, either by working in-memory, from a file, or by caching bytes from the network. It is not designed to be used as a streaming format, it acts more like a file system.

(for piping to other tools like gzip)

HDF5 already supports gzip and other filters internally, why would you pipe its output anywhere?
Again, it's not a streaming file format, it's a model of entire file system (and memory system). One of the reasons it needs random access is that it stores various metadata in headers and has a notion of "heap" and "cache" etc, so while writing datasets it may need to seek back and update/mutate some bytes that have already been written.

(for piping to other tools like gzip)

HDF5 already supports gzip and other filters internally, why would you pipe its output anywhere?
Again, it's not a streaming file format, it's a model of entire file system (and memory system). One of the reasons it needs random access is that it stores various metadata in headers and has a notion of "heap" and "cache" etc, so while writing datasets it may need to seek back and update/mutate some bytes that have already been written.

Makes sense, thanks.

Makes sense, thanks.


Add database host and port to instructions

Description
The instructions don't tell people how to specify a host and port if TSDB is not running locally on the default port. I've just added the two parameters to the promscale command.

bors+


import statement with \ right after import will get removed on sort

Let's say I have a peice of code like this:
#!/usr/bin/python

from os import\
		getuid

print getuid()

After isort, it will become:
#!/usr/bin/python

print getuid()

@junzh0u, Thanks for reporting!
A fix has been prepared by @bootandy  and will be included in the next point release (4.2.6)
Thanks!
~Timothy


Removed throwing an exception when the installation process is closed…

… or canceled by user at language selection stage.

This looks good. It needs an entry in https://github.com/dblock/dotnetinstaller/blob/master/CHANGELOG.md please, and possibly documentation changes. I also believe we have tests around this, does everything pass? Maybe add a test for the cancelation story if it's not too difficult too.

I will delete the commented out code and add a test for the cancellation at next commit.
In what format do I make changes to the changelog?

Just make it look like every other line in there, thanks.

Done.

Do I understand correctly that this only affects a UI-full installation?
Do we need any changes in https://github.com/dblock/dotnetinstaller/blob/master/Documentation/Content/Multilingual.aml?
I also made two nitpicky comments, sorry for being a hassle. I'd appreciate if you could fix space/tabs here so we don't start having a codebase that looks like it's all over the place.

@icnocop You're still using DNI? Want to take a look/merge?

Now everything is OK?

Do I understand correctly that this only affects a UI-full installation? Before a user would see an error, now they just see setup canceled, right?

Only in the case when we see the language selection window. Right.

Do we need any changes in https://github.com/dblock/dotnetinstaller/blob/master/Documentation/Content/Multilingual.aml?

On this occasion, I do not know anything.

Looks good, merging.
@genI3 Are you actively using this? I haven't in years, we could use some help co-maintaining the project, maybe making a release?

I use it from time to time to build the bootstrapper of the installer. Regarding the release of the dotNetInstaller - I don't know.


Missing documentation for new Azure.Messaging.ServiceBus nuget package

The provided documentation assumes the old Microsoft.Azure.ServiceBus package; updated documentation for the new Azure.Messaging.ServiceBus package is missing.

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

ID: c8c95270-3f41-13fb-5676-f3c61d00e64e
Version Independent ID: b25b389a-feac-7cf1-b2b7-df0a24fa412a
Content: Azure Service Bus end-to-end tracing and diagnostics - Azure Service Bus
Content Source: articles/service-bus-messaging/service-bus-end-to-end-tracing.md
Service: service-bus-messaging
GitHub Login: @axisc
Microsoft Alias: aschhab

Related to https://github.com/MicrosoftDocs/azure-docs/issues/68093

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

@hansmbakker Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

#in-progress

#in-progress

@hansmbakker - Thanks for the feedback. I worked with our product team to update the article for the new SDK.
#please-close

@hansmbakker - Thanks for the feedback. I worked with our product team to update the article for the new SDK.
#please-close


Orientation

Could it be possible to rotate thermometer's orientation from vertical to horizontal?

@russellhoff I have never heard of a horizontal thermometer before. Can you show any examples?

Hi @DavidBanksNZ.
It's just a matter of layout, I'd like to fit it in a rectangular-like card.

It's such a rare usage I don't think I'll be adding this feature here, not anytime soon anyway. You could fork the project if you are comfortable working with Javascript and D3.


feat: Support --target input in args

This is really not a nice solution, but a better one would need a bigger rewrite which i don't have time for tbh. We should have a cargo metadata follow-up PR either way in case people commit their config.toml file.
Another problem is how it deletes existing release assets. The way it is now it will remove them per OS, not per arch, so you can't upload a .dmg file for example for both arches. The .app file obviously has a naming problem, so maybe we don't want to support this at all right now?
Successful run: https://github.com/FabianLars/mw-toolbox/actions/runs/3078695681
Now with macos asset renaming per arch and better asset overwrite handling: https://github.com/FabianLars/mw-toolbox/actions/runs/3333153297 - i wonder how happy github was with me uploading over 30 release assets 🤔
Release: https://user-images.githubusercontent.com/30730186/191006883-9a3e9887-e240-4067-8bf8-6733dbaf3c6a.png
New release:

p.s. i didn't plan to PR from this branch so the commit messages are weird, but squash merge to the rescue 🥳
resolves #252
resolves #243
resolves #176

Thanks so much for this change. I know it hasn't been tagged so shouldn't be being used at the moment, but i was testing it out with the commit hash as the action version and get the error assetPath is not defined which looks like it's coming from https://github.com/tauri-apps/tauri-action/blob/ce22b932cbf2a84235742c1bf7624da3af4e7277/packages/action/src/upload-release-assets.ts#L54 (other references were changed to asset.path) just a heads up @FabianLars

thanks, fixed it.
If it still doesn't work you can try the commit hash of the merge of this PR before the other pr got merged: a99d0bae58a558b23da95394a2a38122574b0f78 (but please report any other issues before that :D )

I am still receiving the assetPath is not defined error

Summary of run: https://github.com/Layendan/NineAnimator-Tauri/actions/runs/3381798110
The only reference to assetPath that I can find that would break the action is this line
a.rest.repos.uploadReleaseAsset({headers:r,name:p,data:s().readFileSync(assetPath),owner:o.context.repo.owner,repo:o.context.repo.repo,release_id:t})

in /packages/action/dist/index.js which I do not know where that comes from.

The last part of my last message is still the case. I didn't have access to my dev system today so I couldn't rebuild the action yet. Gonna do that first thing in the morning tho.

Pushed it @Layendan , thanks for the report and sorry for this issue, it was probably a wrong merge.

No problem and thank you for the help!

So After a few tests, I have found an error.
Trying to create a release.json for multiple platforms fails after the first one.
The workflow successfully creates the release.json file for the first action that completes, but fails on the other actions of the matrix with a Unexpected token N in JSON at position 0 error.
I am using this https://github.com/tauri-apps/tauri-action#uploading-the-artifacts-to-a-release example to create the release.
Here is my workflow file: https://github.com/Layendan/NineAnimator-Tauri/actions/runs/3401839275/workflow
And here are a list of different workflows showing that the platform that finishes first is the one that succeeds while all the others fail:

https://github.com/Layendan/NineAnimator-Tauri/actions/runs/3389322461
https://github.com/Layendan/NineAnimator-Tauri/actions/runs/3401831189
https://github.com/Layendan/NineAnimator-Tauri/actions/runs/3382179264


Can we have Language wise channel selections???

Love the work you have done... Really appreciate !!
Just a suggestion: can you add language-wise selections of channels? Like If I want to only view Hindi, English and Punjabi Channels and rest can be hidden. Maybe a language selection checkbox.
Thanks
Maddy

Will do that soon. I got this idea but forgot to add in my latest release

Thanks mate!

Any ETA for next release ?

Any ETA for next release ?

It's out now. Check out in repo

@botallen : Failed to install add on. after the new release.


Vertical align by colon

ESLint has key-spacing rule with options to converts this object
var obj = {
    foobar:42,
    bat: (2 * 2),
    abc :   'value'
}

to this
/*eslint key-spacing: [2, { "align":"colon", "beforeColon":true, "afterColon":true }]*/

var obj = {
    foobar : 42,
    bat    : (2 * 2),
    abc    : 'value'
}

Is it possible in TSLint?

This is not possible in tslint right now. Currently the whitespace rule (I believe) has an option to force the colons to have no prefixed spaces (see example below). I think this tends to be the preferred method of formatting for js/ts and as such a rule to align by colon would probably not have a place in the tslint core rule set (we try to avoid heavily conflicting rules). That said, you can always write a custom rule yourself, and include it in your tslint config.
var obj = {
    foobar: 42,
    bat: (2 * 2),
    abc: 'value'
}

Add this code to your rules .eslint
key-spacing: ["error", { "align": "colon" }]

For more informations all here Docs

@uulgie you're giving example for ESLint, but this is TSLint repo ;)

@igor-sky Did you figure out how to do this?
I'm from .NET and it's common to do something similar so things look less noisy. I want to do this:
var obj = {
    foobar: 42,
    bat:    (2 * 2),
    abc:    'value'
}


python3Packages.privacyIDEA: 3.5.1 -> 3.5.2

Motivation for this change
ChangeLog: https://github.com/privacyidea/privacyidea/blob/v3.5.2/Changelog#L1
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 118300 at 0af9c974 run on x86_64-linux 1

2 packages built successfully:

python38Packages.privacyidea
python39Packages.privacyidea


Formatting: repetitive line breaks

I think the latest release broke some of the formatting logic. If you repeatedly format this snippet, the lines keep moving down.
foo([_], []).
bar([_, _], []).

After formatting three times I get this snippet (two spaces are added on purpose so that markdown does not ignore the newlines):

foo([_], []).

bar([_, _], []).

@watjurk the extension have just been updated with the fix !


feat(jpath): allow other entrypoints than main.jsonnet

Adds an optional flag -f / --file to specify the file to start
with (defaults stays main.jsonnet). File must be at the root of baseDir

Can we just check the path? If the baseDir is a dir, then look for main.jsonnet? Else just evaluate that file?


Auto-mTLS doesn't consider actual destination when determining whether to include client certs/XFCC in request

Bug description
When a source service with an Istio proxy makes a request to a proxyless in-cluster destination endpoint, Istio is smart enough to not include the X-Forwarded-Client-Cert header on the outgoing request to the destination, because it knows the request is bound for a destination that doesn't support Istio mTLS and isn't proxied by an Istio/Envoy sidecar.
Istio service->non-Istio service = no XFCC header, which makes sense
However, if one adds a VirtualService which redirects traffic from that source service to an in-cluster endpoint that does have a Istio proxy with STRICT mTLS mode enabled, the source Istio proxy still leaves off the XFCC header, even though it should know that regardless of the original destination, there is a VSVC rule defined which means the actual destination will be a known Istio-proxied service with mandatory mTLS enabled.
Istio service->non-Istio service->VSVC rule redirecting to an Istio service with STRICT mTLS = no XFCC header and rejected connections which seems like a bug, or at least isn't consistent behavior.
It seems to me that the source proxy should be able to take into account the actual destination and VSVC routing rules when determining whether to include the XFCC header, rather than assuming the initial destination is also the ultimate destination, otherwise we get inconsistent mTLS behavior when routing rules are applied.
Affected product area (please put an X in all that apply)
[X] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
It seems to me that the source proxy should be able to take into account the actual destination versus the original destination when determining whether to include the XFCC header, otherwise we get inconsistent behavior.
In other words:
Istio-controlled service->non-Istio-controlled service->VSVC rule redirecting to an Istio-controlled service with STRICT mTLS = **should** result in the XFCC header being included in keeping with the ultimate destination's STRICT mTLS mode configuration.
I do not know if this is technically impossible due to how Envoy or Istio works - but I do know that it's a surprising and counterintuitive behavior that should either be fixed, or documented.
Steps to reproduce the bug

Create a proxied service that makes a request to an in-cluster workload which is outside of the Istio mesh
Create a VSVC which intercepts and redirects requests from that source service to a different in-cluster workload which IS inside the Istio mesh and has mTLS STRICT enabled
Note that the XFCC header is not included in the request from the source service - it ignores current Istio routing rules when determining if the XFCC header should be included in outgoing requests.

Version 1.8.1
How was Istio installed?
istioctl
Environment where the bug was observed (cloud vendor, OS, etc)
Minikube, EKS

I have also confirmed that this behavior does not change if PeerAuthentication/DestinationRules are defined.

I have also confirmed that this behavior does not change if PeerAuthentication/DestinationRules are defined.

Nevermind - not a bug.
I had an incorrectly-named Service port: https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/ and it was manifesting with this issue.
Apologies!

Nevermind - not a bug.
I had an incorrectly-named Service port: https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/ and it was manifesting with this issue.
Apologies!


Is it correct that addWebpackModuleRule add rule at oneOf?

export const addWebpackModuleRule = rule => config => {
for (let _rule of config.module.rules) {
if (_rule.oneOf) {
_rule.oneOf.unshift(rule);
break;
}
}
return config;
};
The above code is adding rule into oneOf? Is it correct?

this project has nobody answer


Add unit tests for core/modules/wishlist

What is the motivation for adding/enhancing this feature?
Add unit tests for the module. Reference/example:

https://github.com/DivanteLtd/vue-storefront/tree/develop/core/modules/catalog-next/test/unit
https://github.com/DivanteLtd/vue-storefront/blob/develop/core/modules/url/test/unit/formatCategoryLink.spec.ts

What are the acceptance criteria

[ ] all the actions should be tested
[ ] all the helpers should be tested
[ ] all the mutations should be tested

This will be a good place to start for me


Nvidia 555 driver does not work with Ollama

What is the issue?
I just updated nvidia drivers in my host to this version. I have a RTX4070ti.

Then, when I run ollama inside my container (my container is running Ubuntu 20.04), Ollama is not using the GPU (I can tell because it is at 1% when responding)
This is my log when running Ollama
2024/05/21 21:31:02 routes.go:1008: INFO server config env="map[OLLAMA_DEBUG:false OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://<IP_ADDRESS> https://<IP_ADDRESS> http://<IP_ADDRESS>:* https://<IP_ADDRESS>:* http://<IP_ADDRESS> https://<IP_ADDRESS> http://<IP_ADDRESS>:* https://<IP_ADDRESS>:*] OLLAMA_RUNNERS_DIR: OLLAMA_TMPDIR:]"
time=2024-05-21T21:31:02.076Z level=INFO source=images.go:704 msg="total blobs: 5"
time=2024-05-21T21:31:02.076Z level=INFO source=images.go:711 msg="total unused blobs removed: 0"
time=2024-05-21T21:31:02.077Z level=INFO source=routes.go:1054 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.38)"
time=2024-05-21T21:31:02.077Z level=INFO source=payload.go:30 msg="extracting embedded files" dir=/tmp/ollama53751129/runners
time=2024-05-21T21:31:04.593Z level=INFO source=payload.go:44 msg="Dynamic LLM libraries [cuda_v11 rocm_v60002 cpu cpu_avx cpu_avx2]"
time=2024-05-21T21:31:04.669Z level=INFO source=types.go:71 msg="inference compute" id=0 library=cpu compute="" driver=0.0 name="" total="15.6 GiB" available="165.9 MiB"
[GIN] 2024/05/21 - 21:31:25 | 200 |      34.776µs |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/05/21 - 21:31:25 | 404 |     146.669µs |       <IP_ADDRESS> | POST     "/api/show"
[GIN] 2024/05/21 - 21:31:25 | 200 |  776.506553ms |       <IP_ADDRESS> | POST     "/api/pull"
[GIN] 2024/05/21 - 21:31:35 | 200 |      19.307µs |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/05/21 - 21:31:35 | 200 |     482.647µs |       <IP_ADDRESS> | POST     "/api/show"
[GIN] 2024/05/21 - 21:31:35 | 200 |     323.505µs |       <IP_ADDRESS> | POST     "/api/show"
time=2024-05-21T21:31:36.117Z level=INFO source=memory.go:133 msg="offload to gpu" layers.requested=-1 layers.real=0 memory.available="145.4 MiB" memory.required.full="4.6 GiB" memory.required.partial="794.5 MiB" memory.required.kv="256.0 MiB" memory.weights.total="4.1 GiB" memory.weights.repeating="3.7 GiB" memory.weights.nonrepeating="411.0 MiB" memory.graph.full="164.0 MiB" memory.graph.partial="677.5 MiB"
time=2024-05-21T21:31:36.118Z level=INFO source=server.go:320 msg="starting llama server" cmd="/tmp/ollama53751129/runners/cpu_avx2/ollama_llama_server --model /root/.ollama/models/blobs/sha256-6a0746a1ec1aef3e7ec53868f220ff6e389f6f8ef87a01d77c96807de94ca2aa --ctx-size 2048 --batch-size 512 --embedding --log-disable --parallel 1 --port 34935"
time=2024-05-21T21:31:36.118Z level=INFO source=sched.go:338 msg="loaded runners" count=1
time=2024-05-21T21:31:36.119Z level=INFO source=server.go:504 msg="waiting for llama runner to start responding"
time=2024-05-21T21:31:36.119Z level=INFO source=server.go:540 msg="waiting for server to become available" status="llm server error"
INFO [main] build info | build=1 commit="952d03d" tid="140248322381696" timestamp=1716327096
INFO [main] system info | n_threads=8 n_threads_batch=-1 system_info="AVX = 1 | AVX_VNNI = 0 | AVX2 = 1 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 1 | " tid="140248322381696" timestamp=1716327096 total_threads=16
INFO [main] HTTP server listening | hostname="<IP_ADDRESS>" n_threads_http="15" port="34935" tid="140248322381696" timestamp=1716327096
llama_model_loader: loaded meta data with 22 key-value pairs and 291 tensors from /root/.ollama/models/blobs/sha256-6a0746a1ec1aef3e7ec53868f220ff6e389f6f8ef87a01d77c96807de94ca2aa (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.name str              = Meta-Llama-3-8B-Instruct
llama_model_loader: - kv   2:                          llama.block_count u32              = 32
llama_model_loader: - kv   3:                       llama.context_length u32              = 8192
llama_model_loader: - kv   4:                     llama.embedding_length u32              = 4096
llama_model_loader: - kv   5:                  llama.feed_forward_length u32              = 14336
llama_model_loader: - kv   6:                 llama.attention.head_count u32              = 32
llama_model_loader: - kv   7:              llama.attention.head_count_kv u32              = 8
llama_model_loader: - kv   8:                       llama.rope.freq_base f32              =<PHONE_NUMBER>00
llama_model_loader: - kv   9:     llama.attention.layer_norm_rms_epsilon f32              = 0.000010
llama_model_loader: - kv  10:                          general.file_type u32              = 2
llama_model_loader: - kv  11:                           llama.vocab_size u32              = 128256
llama_model_loader: - kv  12:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv  13:                       tokenizer.ggml.model str              = gpt2
llama_model_loader: - kv  14:                         tokenizer.ggml.pre str              = llama-bpe
llama_model_loader: - kv  15:                      tokenizer.ggml.tokens arr[str,128256]  = ["!", "\"", "#", "$", "%", "&", "'", ...
llama_model_loader: - kv  16:                  tokenizer.ggml.token_type arr[i32,128256]  = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
llama_model_loader: - kv  17:                      tokenizer.ggml.merges arr[str,280147]  = ["Ġ Ġ", "Ġ ĠĠĠ", "ĠĠ ĠĠ", "...
llama_model_loader: - kv  18:                tokenizer.ggml.bos_token_id u32              = 128000
llama_model_loader: - kv  19:                tokenizer.ggml.eos_token_id u32              = 128009
llama_model_loader: - kv  20:                    tokenizer.chat_template str              = {% set loop_messages = messages %}{% ...
llama_model_loader: - kv  21:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:   65 tensors
llama_model_loader: - type q4_0:  225 tensors
llama_model_loader: - type q6_K:    1 tensors
time=2024-05-21T21:31:36.370Z level=INFO source=server.go:540 msg="waiting for server to become available" status="llm server loading model"
llm_load_vocab: special tokens definition check successful ( 256/128256 ).
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = llama
llm_load_print_meta: vocab type       = BPE
llm_load_print_meta: n_vocab          = 128256
llm_load_print_meta: n_merges         = 280147
llm_load_print_meta: n_ctx_train      = 8192
llm_load_print_meta: n_embd           = 4096
llm_load_print_meta: n_head           = 32
llm_load_print_meta: n_head_kv        = 8
llm_load_print_meta: n_layer          = 32
llm_load_print_meta: n_rot            = 128
llm_load_print_meta: n_embd_head_k    = 128
llm_load_print_meta: n_embd_head_v    = 128
llm_load_print_meta: n_gqa            = 4
llm_load_print_meta: n_embd_k_gqa     = 1024
llm_load_print_meta: n_embd_v_gqa     = 1024
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-05
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 14336
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 0
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 500000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_yarn_orig_ctx  = 8192
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 8B
llm_load_print_meta: model ftype      = Q4_0
llm_load_print_meta: model params     = 8.03 B
llm_load_print_meta: model size       = 4.33 GiB (4.64 BPW)
llm_load_print_meta: general.name     = Meta-Llama-3-8B-Instruct
llm_load_print_meta: BOS token        = 128000 '<|begin_of_text|>'
llm_load_print_meta: EOS token        = 128009 '<|eot_id|>'
llm_load_print_meta: LF token         = 128 'Ä'
llm_load_print_meta: EOT token        = 128009 '<|eot_id|>'
llm_load_tensors: ggml ctx size =    0.15 MiB
llm_load_tensors:        CPU buffer size =  4437.80 MiB
.......................................................................................
llama_new_context_with_model: n_ctx      = 2048
llama_new_context_with_model: n_batch    = 512
llama_new_context_with_model: n_ubatch   = 512
llama_new_context_with_model: freq_base  = 500000.0
llama_new_context_with_model: freq_scale = 1
llama_kv_cache_init:        CPU KV buffer size =   256.00 MiB
llama_new_context_with_model: KV self size  =  256.00 MiB, K (f16):  128.00 MiB, V (f16):  128.00 MiB
llama_new_context_with_model:        CPU  output buffer size =     0.50 MiB
llama_new_context_with_model:        CPU compute buffer size =   258.50 MiB
llama_new_context_with_model: graph nodes  = 1030
llama_new_context_with_model: graph splits = 1
INFO [main] model loaded | tid="140248322381696" timestamp=1716327097
time=2024-05-21T21:31:37.123Z level=INFO source=server.go:545 msg="llama runner started in 1.00 seconds"
[GIN] 2024/05/21 - 21:31:37 | 200 |   1.64966928s |       <IP_ADDRESS> | POST     "/api/chat"
[GIN] 2024/05/21 - 21:31:43 | 200 |   4.29836565s |       <IP_ADDRESS> | POST     "/api/chat"

Edit:
In addition, my container detects successfully the gpu passthrough when doing nvidia-smi.
OS
Docker
GPU
Nvidia
CPU
AMD
Ollama version
0.1.38

Interestingly, I experienced a similar phenomenon when I upgraded from driver version 535 to 550 - my CPU usage remained high until I rebooted the host machine.
As for the nvidia-smi command, if it outputs an error message, it's likely indicative of a problem with the connection between the NVIDIA driver and graphics card.

What's the output of ollama ps?

Please add -e OLLAMA_DEBUG=1 to your container and share the log so we can see a little more detail on why it can't discover the GPU.  Also try docker run --gpus all ubuntu nvidia-smi to see if the Docker + Nvidia container runtime has become unhealthy.

There has been a change in nVidia drivers and how they present to Docker after 550. Investigation into the docker container and the toolkit seemed to indicate that the toolkit needed to update the driver identification. Dropping into the cli on the docker and running nvidia-smi will give an error of Failed to initialize NVML: Unknown Error
no-cgroups = false in /etc/nvidia-container-runtime/config.toml
https://github.com/NVIDIA/nvidia-container-toolkit/issues/394
https://forums.developer.nvidia.com/t/nvida-container-toolkit-failed-to-initialize-nvml-unknown-error/286219

I don't believe it's related to Ollama. I also had this issue. I discovered it when setting up a container unrelated to Ollama. It's the new 555 drivers, and affects any cuda/gpu related container (I tested multiple including base pytorch cuda docker image).
For example, trying to list Cuda capability in pytorch docker gives a "CUDA initialization: Unexpected error from cudaGetDeviceCount(). Did you run some cuda functions before calling NumCudaDevices() that might have already set an error?"
Nvidia container tests said 1 device requested, 0 available.
Issue was instantly fixed by reverting to prior drivers.

Thank you very much @brodieferguson ! this seemed to do the trick. Nevertheless, I am not quite happy to downgrade my GPU drivers in order to make Ollama work. For that reason I wouldn't consider this issue resolved and I will cooperate to provide more info to solve this problem in case it is needed.
@dhiltgen I just downgraded my drivers to the immediate version and Ollama started to use the GPU (RTX4070ti) instantly:

There might be an incompatibility with the new drivers as @brodieferguson had the same problem and probably many other users too.
Thank you very much both. I hope I can enjoy Ollama with the latest drivers soon.

same issue here:
Ollama worked fine on GPU before upgrading both Ollama and NVIDIA previous drivers so far I know. I am on Windows 11 with WSL2 and using Docker Desktop. This morning I did two things:

noticed new Nvidia drivers available: 555.85; It also included a PhysX update this time (first time I saw that in years actually): version 9.23.1019 --> installed both
docker pull ollama/ollama to get 0.1.38 version (I was on 0.1.37 before)
deleted the existing OIlama container. Then did: docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Later I noticed that ollama now no longer uses my GPU, noticing it was much slower and looking at resources there GPU memory was not used. Using the newly available ollama ps command confirmed the same thing:
NAME            ID              SIZE    PROCESSOR       UNTIL
mistral:latest  61e88e884507    4.6 GB  100% CPU        4 minutes from now
nvidia-smi clearly showed GPU is available:
nvidia-smi
Fri May 24 07:34:10 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.42.03              Driver Version: 555.85         CUDA Version: 12.5     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4090        On  |   00000000:0A:00.0  On |                  Off |
| 50%   27C    P8             52W /  530W |     933MiB /  24564MiB |      1%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A        23      G   /Xwayland                                   N/A      |
|    0   N/A  N/A        27      G   /Xwayland                                   N/A      |
|    0   N/A  N/A        31      G   /Xwayland                                   N/A      |
+-----------------------------------------------------------------------------------------+
I will downgrade drivers as well, but there clearly is a issue with ollama and these drivers

@nerdpudding thanks for your contribution. We can confirm this is not an isolated issue and nvidia drivers 555.85 causes ollama not to use the gpu for some reason.

Can confirm, no CUDA docker image works with 555. downgrading to 552 fixes the issue. This is unrelated to ollama and needs to be fixed by docker/nvidia.

Hi folks it seems the 555 Nvidia driver branch is not working with Ollama (and other projects that integrate llama.cpp). We're working to resolve this together – in the meantime downgrading to a prior version will fix the issue. So sorry about this and will post more updates here.

You can correct this issue with the proper changes to your config.toml file. There was a driver change in how they exposed the domain and there a github issue in the nvidia-docker-toolkit regarding the change and how to resolve the issue I can't find atm. Here is the executive overview of the issue. https://github.com/NVIDIA/nvidia-container-toolkit/issues/48 This is a working docker container utilizing these drivers.  Changing no-cgfroups to false resolves the issue. You can also verify by adding the line  --device nvidia.com/gpu=all instead of the standard
no-cgroups = false

cat /etc/nvidia-container-runtime/config.toml
#accept-nvidia-visible-devices-as-volume-mounts = false
#accept-nvidia-visible-devices-envvar-when-unprivileged = true
disable-require = false
supported-driver-capabilities = "compat32,compute,display,graphics,ngx,utility,video"
#swarm-resource = "DOCKER_RESOURCE_GPU"

[nvidia-container-cli]
#debug = "/var/log/nvidia-container-toolkit.log"
environment = []
#ldcache = "/etc/ld.so.cache"
ldconfig =<EMAIL_ADDRESS>load-kmods = true
no-cgroups = false
#path = "/usr/bin/nvidia-container-cli"
#root = "/run/nvidia/driver"
#user = "root:video"

[nvidia-container-runtime]
#debug = "/var/log/nvidia-container-runtime.log"
log-level = "info"
mode = "auto"
runtimes = ["docker-runc", "runc", "crun"]

[nvidia-container-runtime.modes]

[nvidia-container-runtime.modes.cdi]
annotation-prefixes = ["cdi.k8s.io/"]
default-kind = "nvidia.com/gpu"
spec-dirs = ["/etc/cdi", "/var/run/cdi"]

[nvidia-container-runtime.modes.csv]
mount-spec-path = "/etc/nvidia-container-runtime/host-files-for-container.d"

[nvidia-container-runtime-hook]
path = "nvidia-container-runtime-hook"
skip-mode-detection = false

[nvidia-ctk]
path = "nvidia-ctk"

Hi all, this seems to be from the nvidia_uvm kernel module not being loaded. You can run:
sudo modprobe nvidia
sudo modprobe nvidia_uvm

to load them manually. A fix is coming with the install script.
Also, adding:
nvidia
nvidia-uvm

to /etc/modules-load.d/nvidia.conf will make sure they are loaded on startup

Hi folks it seems this is from the new driver packages not loading the nvidia_uvm kernel module from what I can see. It should work to re-load the module:
sudo modprobe nvidia
sudo modprobe nvidia_uvm

and then to keep it loaded, edit the conrfig for nvidia-persistenced by adding them to /etc/modules-load.d/nvidia.conf
nvidia
nvidia-uvm

Thanks a lot for the fix! 💙

Hi folks it seems this is from the new driver packages not loading the nvidia_uvm kernel module from what I can see. It should work to re-load the module:
sudo modprobe nvidia
sudo modprobe nvidia_uvm

and then to keep it loaded, edit the conrfig for nvidia-persistenced by adding them to /etc/modules-load.d/nvidia.conf
nvidia
nvidia-uvm

Not sure how to apply these on WLS docker installation. I downgraded my driver for now and it is working again.

Same issue here. The modprobe nvidia fix doesn't seem to work with WSL 2.
I’m not an expert, but I tried different Docker builds using the install script with pytorch:2.3.0-cuda12.1-cudnn8-runtime as the base image. Everything works fine with older NVIDIA drivers, but not with 555.85.
Even though nvidia-smi shows the GPU is available (both in WSL and the running container), Ollama defaults to CPU. The debug logs look like this:
time=2024-06-03T11:59:56.076Z level=DEBUG source=gpu.go:355 msg="Unable to load nvcuda" library=/usr/lib/x86_64-linux-gnu/libcuda.so.1 error="nvcuda init failure: 500"
Any ideas or suggestions on what might be causing this with the latest drivers? Should we just await if a newer nvidia driver release fixes it?

@nerdpudding Did you try using Ollama v0.1.41 (the latest release) ?

@nerdpudding Did you try using Ollama v0.1.41 (the latest release) ?

Yes. First I tried pulling the lates official docker image.
Then I used this custom docker build, which uses the install.sh and installs v0.1.41:
Use the official PyTorch image with CUDA support
FROM pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime
Install dependencies
RUN apt-get update && apt-get install -y
curl
sudo
&& apt-get clean
&& rm -rf /var/lib/apt/lists/*
Create a non-root user
RUN useradd -m -s /bin/bash ollama
RUN echo 'ollama ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
USER ollama
WORKDIR /home/ollama
Install Ollama
RUN curl -fsSL https://ollama.com/install.sh | sh
Ensure the volumes are correctly set up
VOLUME ["/root/.ollama"]
Set environment variables for CUDA and debugging
ENV OLLAMA_DEBUG=1
ENV NVIDIA_VISIBLE_DEVICES=all
ENV NVIDIA_DRIVER_CAPABILITIES=compute,utility
ENV LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib/x86_64-linux-gnu:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:$LD_LIBRARY_PATH
ENV PATH=/usr/local/cuda/bin:$PATH
Ensure correct library links
RUN sudo mkdir -p /usr/local/cuda/lib64/stubs && sudo ln -s /usr/lib/x86_64-linux-gnu/libcuda.so.1 /usr/local/cuda/lib64/stubs/libcuda.so
Run Ollama
CMD ["ollama", "serve"]
This works fine with the old drivers, not with the new.

Yes, Docker Desktop with Windows 11 and WSL2 indeed. Older drivers still work fine. I missed that the workaround with the 'nvidia_uvm' was not possible with docker desktop and I was (pointlessly) trying to look for a something that does...Thanks for pointing out they are still working on a solution for Docker Desktop users, I'll just be more patient :-)

Yes, Docker Desktop with Windows 11 and WSL2 indeed. Older drivers still work fine. I missed that the workaround with the 'nvidia_uvm' was not possible with docker desktop and I was (pointlessly) trying to look for a something that does...Thanks for pointing out they are still working on a solution for Docker Desktop users, I'll just be more patient :-)

Is there a separate issue for that (this one got closed) ? I would like to keep my eye on it. then I would know when to update :D

Yes, Docker Desktop with Windows 11 and WSL2 indeed. Older drivers still work fine. I missed that the workaround with the 'nvidia_uvm' was not possible with docker desktop and I was (pointlessly) trying to look for a something that does...Thanks for pointing out they are still working on a solution for Docker Desktop users, I'll just be more patient :-)

Is there a separate issue for that (this one got closed) ? I would like to keep my eye on it. then I would know when to update :D

Not sure, but to my understanding, it is a NVIDIA issue so...
By the way, I noticed newer drivers where released today (555.99) and hoped it fixed it after reading this:
https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/543951/geforce-grd-55599-feedback-thread-released-6424/
Fixed General Bugs:
CUDA 12.5 does not work with CUDA enabled Docker images [4668302]
I just installed, rebooted and tested with that newer driver using both my own docker file (which uses pytorch:2.3.0-cuda12.1-cudnn8-runtime and then installs ollama using the install.sh script) and the latest official Ollama Docker image. Both still only use the CPU. I reverted back to 551.44 and immediately GPU was used again. So apparently that 'general fix'  still does not apply to WLS2 with Docker Desktop yet then, but only for CE maybe.
I'm not sure if there is another open issue on it here, but I guess it is a NVIDIA issue, so we probably just have to look on forum/threads there and wait until they release a fix with newer drivers.

Is there a separate issue for that (this one got closed) ? I would like to keep my eye on it. then I would know when to update :D

I subscribed to this one

@nerdpudding Are you using Docker Desktop? smi worked for me too, but not the rest.
NVIDIA/nvidia-container-toolkit#520

Docker has released an update for Docker Desktop.
See https://docs.docker.com/desktop/release-notes/
Upgrades:
--> NVIDIA Container Toolkit v1.15.0
I just tested it and GPU is used now with Nvidia drivers 555.99 after upgrading Docker Desktop to 4.31.0
This fixed it for me!
So if you are using Docker on Windows with WSL 2 (Now not only for Docker CE, but also Docker Desktop), after updating, it will work again.


Error using as NPM Package

This what I try now, worked yesterday...
I add you repo as node_module to my designer.
Then I go to the directory node_modules/paint and build it
 npm run build

but there ar eno output files.
Also a "npx run tsc " does not generate any files
And also "npm start" does not work.

There were indeed some changes since yesterday, as I had to downgrade to an earlier version of Snowpack. However, that works on my machine (event after a git clean) and it also works on the CI server: https://github.com/christianliebel/paint/runs/2735591540
Could you try purging your entire node_modules folder and installing it again?

Same problem.
But as I said, I don't use git to clone your repo, I install paint as a npm module inside of my webcomponent designer demo.

I just tried the following:
mkdir foo
cd foo
npm init # + wizard
npm i github:christianliebel/paint
cd node_modules/paint
npm i
npm run build

And that does it for me…

build does work

but there is no build folder after

I see. This appears to be a bug in the particular version of Snowpack that I use… Alright, I'll revert that change. npm start will break in the meantime, I will document it in the README.

Mh, to no avail, as I need a working dev build. I'll prioritize the npm package. Could you please use github:christianliebel/paint#e811a98 as a dependency in the meantime?

@jogibear9988 You can now use @christianliebel/paint 🎉


Comment spelling nit

CYGINW probably should be CYGWIN
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

LOL, yeah :) Nice catch.


Fix uncaught bug with NaN

In general, the way we have to handle URLs and internal state is getting super messy, which will get fixed soon

[pr-server]
View this change on PR Server