keyboard always show up.

Hi,
first of all, let me thank the developer for this great and useful flutter package.
The keyboard seems to always show up when the dropdownMenu button is pressed. Can it be possible to only show the keyboard when the user presses the search input TextField?
I took a look at the package's code and it seems that autofocus: true is calling the keyboard, right? How to avoid this?
Thanks,
Ricardo

Hey, I'm feeling the same, by any chance, did you found some work around?

You can copy the whole code for you and change autofocus: to false for testing your side of the app. But this way you no longer will receive updates and new stuff that the original plugin might receive.  It would be great if owner or someone provide an upgraded version with autofocus accessible from the outside. I don´t know how to help the developer on this task yet.

yes, autofocus control as widget property is really needed.

I have added a PR with isAutoFocus option to switch on and off keyboard by default.

Any new status about this?

@kazyamof

Any new status about this?

You can check my branch here,
https://github.com/utkarshmarwaha/searchable_dropdown/tree/keyboard_off_default

@kazyamof

Any new status about this?

You can check my branch here,
https://github.com/utkarshmarwaha/searchable_dropdown/tree/keyboard_off_default

Nice, well done!


Fix symbol deprecation

I second that.

does anyone active have commit access here? if not, packages that use this one should consider updating to avoid it. if that's not practical, we can consider redirecting metadata to point to a fork somewhere such as JuliaMath.

I do. And I can merge after the 0.3 issue is fixed.

or 0.3 support could be dropped

Perhaps we should deprecate this package and put a link to StatsFuns.jl on README.

Guess I'll just close this if this package is defunct now.


Added MoM-EE-1.6 to our SI tests

added 1.6 definitions (copied from 1.5 with minimal changed)
removed 1.3 definitions and tests since it supports has run out.

In some places just marathon-user-ee is used, in some other places there is a version appended to it. It would be nice to have it consistent.

only the mom-ee Id is without a version - everything else is with it. Interestingly enough we didn't have the versions at all at the beginning but there is an admin-router bug that needs this workaround.


Can not make a event click on View after Sliding UP

Hi team,
I have updated from 3.0.0 -> 3.1.1
I'v got a problem:
Couldn't click TextView/Button on The view After Sliding up.
Please have a look on it. I have to down it to 3.0.0 again. thanks

Need to know solution too.

I'm using 3.2.0 and it works just fine. Did you set the onClickListener inside onCreate() or onPanelExpanded()?

I'm experiencing same Issue, I have a recyclerview inside the sliding layout and with 3.0.2 I can't click list items, reverting to 3.0.0 fixes problem

Please update to the latest version.
On Thu, Oct 29, 2015 at 3:39 AM, Pablo A Martínez Andrés <
<EMAIL_ADDRESS>wrote:

I'm experiencing same Issue, I have a recyclerview inside the sliding
layout and with 3.0.2 I can't click list items, reverting to 3.0.0 fixes
problem
—
Reply to this email directly or view it on GitHub
https://github.com/umano/AndroidSlidingUpPanel/issues/547#issuecomment-152142217
.

I meant the bug is happening in 3.2.0, can't see there is a newer release

Can you create a sample project with an issue? I can't seem to reproduce it.

I fixed it adding the recyclerview id to sothree:umanoScrollableView attribute

Please reopen if still having issues.


feat(TError) : Make TError default to Error instead of unknown

This PR makes the TError default to Error instead of unknown, more info about this here

closes https://github.com/TanStack/query/issues/4676

@TkDodo done with this one too

can you please resolve the conflicts? We've merged the big syntax change (object syntax) PR and sadly it causes quite some conflicts. Should be straight forward to solve though - sorry!

can you please resolve the conflicts? We've merged the big syntax change (object syntax) PR and sadly it causes quite some conflicts. Should be straight forward to solve though - sorry!

can you please resolve the conflicts? We've merged the big syntax change (object syntax) PR and sadly it causes quite some conflicts. Should be straight forward to solve though - sorry!

done

formatting is failing:
> query@ prettier /home/runner/work/query/query
> prettier "{packages,examples}/**/src/**/*.{md,js,jsx,ts,tsx,json,vue}" "--check"

Checking formatting...
[warn] packages/solid-query/src/createQueries.ts
[warn] Code style issues found in the above file. Forgot to run Prettier?

formatting is failing:
> query@ prettier /home/runner/work/query/query
> prettier "{packages,examples}/**/src/**/*.{md,js,jsx,ts,tsx,json,vue}" "--check"

Checking formatting...
[warn] packages/solid-query/src/createQueries.ts
[warn] Code style issues found in the above file. Forgot to run Prettier?

ah yeah! sorry, forgot to run it, fixed

seems like the same solid tests is always failing, and its one that was touched in this PR. do you maybe know why? Or should we ask @ardeora 😅

seems like the same solid tests is always failing, and its one that was touched in this PR. do you maybe know why? Or should we ask @ardeora 😅

oh that's odd!all the test is passing locally, i'll investigate

@TkDodo this a new error from the merge, it has something to do with the suspense

@TkDodo this a new error from the merge, it has something to do with the suspense

I think it's because the ts-expects-error was spanning the whole line, and now it's two lines because of syntax changes, and the second line is not "covered" anymore. It only errors in the local IDE, not in the typecheck task. But yeah, this test is accessing private fields, which it shouldn't - but I've already re-written it in a different branch.
Anyways, this is not the problem here. The problem was that we still had some tests that rejected a promise with a string. I fixed that here: b2d62d9266ac75d88606e889f4b5eac38cb0b76a

Codecov Report

:exclamation: No coverage uploaded for pull request base (v5@3b45591). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@          Coverage Diff          @@
##             v5    #4706   +/-   ##
=====================================
  Coverage      ?   90.73%
=====================================
  Files         ?       89
  Lines         ?     3487
  Branches      ?      896
=====================================
  Hits          ?     3164
  Misses        ?      301
  Partials      ?       22

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Shape inference for tile and gather

Please also add corresponding unit tests for it.

@fchollet Added test for gather. Tests for tile were already added.

LGTM, thanks!

Guys, what about bringing this feature back?
#2359


typo

never heard of a copy in a "swallow way", presumably "shallow"

the swallow copy is actually the one performed by Object.assign ;-)

ah, i see what you meant there. I'll tweak it.

Oh, that was purposeful! Sorry all.  Other references I found to "swallow copy" elsewhere looked like typos too.
I'm glad the rephrasing won't be confused as a typo down the road.

if it looks like a typo is bad anyway so thanks for pointing this out


Travis test under Ruby 2.7.0

Only Rails 6, don't bother testing previous Rails under 2.7.0

There are lots of deprecation warnings generated; I think they are all from Rails and other dependencies, not from our code.
The main thing is to demo we're passing, we can't do anything about deprecation warnings in our dependencies, although they do make the test output hard to read.


Prevent author vote manipulation

don't allow poll authors to vote in their own polls

Shouldn't we allow people to vote on their own polls but disqualify them on when tallying side? We can't be sure clients are following the spec and people can always send events by hand.

Shouldn't we allow people to vote on their own polls but disqualify them on when tallying side? We can't be sure clients are following the spec and people can always send events by hand.

Yes, most of the checks remain to be written on the tallying still. While we're still the only client emitting poll events, this still works, but all remaining tally side protocol checks will have to be written asap. I think it's best we don't allow authors to vote on their own polls, just so there's no confusion on what will be included in tallies, similar to how users aren't allowed to send zaps that won't be included in tallies.


Reject invalid dot method call after match predicate or after match required

Partially fixes:  https://github.com/ruby/prism/issues/3171

Thank you so much for the fix here! (And the other fixes also!) I won't have time to review this week (Thanksgiving tomorrow) but I will take a look first thing next week.


Update config.js

Added following States
A_CYC_RH_LEVEL_MODE
A_CYC_SUPPLY_HEATING_ADJUST_MODE
A_CYC_OPT_TEMP_SENSOR_MODE
and Workaround for Unit Detection

great, looks good!
btw. you can add more commits to a open pull request. you could have just added them to the other pull request.
i will bump the vallox-api version and merge as soon as daniel published his release


tddft.org is down

PySCF cannot be compiled because it depends on a download from tddft.org, which is currently down.
It would be good to mirror your dependencies to avoid this in the future.
-- Up-to-date: /Users/jrhammon/Work/CHEMISTRY/PySCF/pyscf/lib/deps/include/xcfun.h
-- Up-to-date: /Users/jrhammon/Work/CHEMISTRY/PySCF/pyscf/lib/deps/include/xcfun_autogen.h
-- Installing: /Users/jrhammon/Work/CHEMISTRY/PySCF/pyscf/lib/deps/lib/libxcfun.dylib
[  5%] Completed 'libxcfun'
[  8%] Built target libxcfun
[ 10%] Performing download step (download, verify and extract) for 'libxc'
-- File already exists but no hash specified (use URL_HASH):
  file='/Users/jrhammon/Work/CHEMISTRY/PySCF/pyscf/lib/build/deps/src/libxc-2.2.2.tar.gz'
Old file will be removed and new file downloaded from URL.
-- Downloading...
   dst='/Users/jrhammon/Work/CHEMISTRY/PySCF/pyscf/lib/build/deps/src/libxc-2.2.2.tar.gz'
   timeout='none'
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
-- Retrying...
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
-- Retry after 5 seconds (attempt #2) ...
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
-- Retry after 5 seconds (attempt #3) ...
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
-- Retry after 15 seconds (attempt #4) ...
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
-- Retry after 60 seconds (attempt #5) ...
-- Using src='http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.2.tar.gz'
CMake Error at libxc-stamp/download-libxc.cmake:157 (message):

This is not a local issue.  I independently confirmed with http://www.downforeveryoneorjustme.com/www.tddft.org and earlier today we had to work around it for the MADNESS project (https://github.com/m-a-d-n-e-s-s/madness/issues/222).

There is a backup URL in the CMakeLists.txt for a relatively old libxc version
https://github.com/sunqm/pyscf/blob/master/lib/CMakeLists.txt#L100

Thanks!  I'll try that.
Apparently tddft.org had server issues in the host university and will be back soon.

I'm trying to install CP2K with spack but it currently fails as www.tddft.org is once again down. The above link needs to be updated. For anyone interested, the backup URL for libxc is:
http://www.sunqm.net/pyscf/files/src/libxc-3.0.1.tar.gz


Add tab navigation and update layouts for Provider page

Fixes #531
Fixes #607
Also improves testing for existing organization views, and aligns permissions with our permissions doc.

Member view:

Owner view:

@marlo-longley a couple other things to check permissions-wise:

As an org member I should be able to view other orgs' normalized files, but I cannot.
As an org member I should NOT be able to view other orgs' token page, but I can. (The tokens don't appear but we should probably just hide the tab and the page if the user does not have permission to view them)

@corylown your points about permissions should be addressed in this new commit. Thanks for catching those!
https://github.com/pod4lib/aggregator/pull/620/commits/3633ce38a43bdd726a731c0dd13eb3e1d7cd46fa

@marlo-longley I think this is still not quite right. Maybe we can pair on this when you're ready?


Strange behavior in a niche use of teams-web via chrome app shortcut

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.778]
PowerToys version: 0.17
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce
When using teams (web version) as a chrome app shortcut and snapping it to a smaller priority grid the close (X) goes missing off screen.  This only seems to occur when the grid is smaller than the normal minimum.  However, it is actually slightly worse when the grid is larger, but still smaller than the normal minimum size, in which case the maximize button also goes missing off screen.  The chat and other elements seem to mostly stay on screen (except the scroll bar goes missing in the larger (but still technically smaller than minimum) grid.
Expected behavior
Expected the window/browser/app to fit into the zone/grid, with any clipping happening inside the constraints of the window.
Actual behavior
See steos ti reoriduce
Screenshots

I think we need bigger screenshots here as i'm not exactly sure what we're trying to see here based on those screenshots.
Also does this happen when without PT running.

It appears to be resolved with the newest version of PowerToys (or there was an update to teams).  I am no longer able to reproduce the error at current versions


Lints android-test

When complete, this should allow folks running the android-test more success.
Depends on feedback in general and specifically here https://github.com/square/okhttp/pull/6008#discussion_r496553972

This is me warming back up, so wanted to improve the setup instructions. If anything is worse than before please note!

Big sincere thanks from me for the critical attention here, I've been lazy in running these.  Ideally we will eventually move CI to github and run these tests on every PR and master nightly.
https://github.com/square/retrofit/blob/master/.github/workflows/build.yml

I will save the logging related glitch to another PR as I want to think more about it..

Thanks for the help @yschimke!


Configuring sass-resources-loader using Rails/Webpacker

I have tried multiple ways to include a variables.scss file in a Rails 5.2.1/VueJS/Webpacker project, with no joy. This is what I have for my webpack/loaders/sass-resources-loader.js:
environment.loaders.get('vue').use[0].options.loaders = {
  scss: [
    'vue-style-loader',
    'css-loader',
    'sass-loader',
    {
      loader: 'sass-resources-loader',
      options: {
        resources: [
          path.resolve(__dirname, 'app', 'javascript', 'variables.scss'),
        ],
      },
    },
  ],
}

but the Vue component that references a variable defined in variables.scss fails to compile with a message Undefined variable: "$header-background-colour".
I've tried various other means of specifying the path:

variables.scss
javascript/variables.scss
app/javascript/variables.scss
../app/javascript/variables.scss
../../app/javascript/variables.scss
../../../app/javascript/variables.scss

All fail.
Currently I have to manually @import 'variables.scss'; into every component, which is not ideal. What is the correct way to specifying the path <rails root>/app/javascript/variables.scss? I'd be happy to add a PR to the docs to give an example of configuring for Rails once I've worked it out :)

@unikitty37 I'm not using Vue nor standalone webpacker. If you were on https://github.com/shakacode/react_on_rails, I could help you better.
Have you tried inserting some debugging print statements to figure out the issue?

@unikitty37 Which version of vue-loader do you use? I may be able help you configuring it.

Having this same issue using create-react-app.

@zmanning29 can you try the previous release to see if the issue is with the current release?

I'm working on a migration from sprockets to webpacker, and I came across this GH issue when googling, so I figured I'd share the config I've got that seems to be working:
// config/webpack/environment.js

// ...

// sass/scss loader config
const sassLoader = environment.loaders.get('sass')
const sassLoaderConfig = sassLoader.use.find(function (element) {
  return element.loader === 'sass-loader'
})

const options = sassLoaderConfig.options
options.implementation = require('sass') // Use Dart-implementation of Sass (default is node-sass)

const sassResourceLoader = require('./loaders/sass-resource-loader')
environment.loaders.prepend('sass', sassResourceLoader)

//...

// config/webpack/loaders/sass-resource-loader.js

module.exports = {
  test: /\.scss$/,
  use: [
    'style-loader',
    'css-loader',
    'sass-loader',
    {
      loader: 'sass-resources-loader',
      options: {
        resources: [
          './app/javascript/styles/abstract/*.scss' // I've got all my "global" stuff in this one abstracts folder
        ]
      }
    }
  ]
}

At the moment, I think this is loading my variables and mixins and such correctly, though my compilation is still not working, but I think it's for unrelated reasons.

figured this out. I think my issue may be a little unique because I am using Adobe Experience Manager. Here was the solution though:
const { override, adjustStyleLoaders } = require("customize-cra"); module.exports = override(   adjustStyleLoaders(rule => {     if (rule.test.toString().includes("scss")) {       rule.use.push({         loader: require.resolve("sass-resources-loader"),         options: {           resources: "./src/styles/_base.scss"         }       });     }   }) );


bennaaym/yaml_support : lg_units to YAML parser

Description
This feature implements a python-YAML parser that's able to read a python file, parse the different LabGraph units found within the file and serialize them into YAML.
to run the parser the following dependencies are required :

PyYAML
typed-ast

Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)
[X] This change requires a documentation update

Checklist:

[ ] Have you added tests that prove your fix is effective or that this feature works?
[ ] New and existing unit tests pass locally with these changes?
[X] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Looks like this PR is WIP, please help check the open task lists in your Checklist session. Please help comment again when you think this PR is ready for a full review. In mean time, I can check in the PR's progress from time to time.


[stable/jenkins] Updating the agent.slaveConnectTimeout value does not take effect

We needed to kill the worker pods if it stays in ContainerCreating state for more than 30 seconds. So we updated the value of agent.slaveConnectTimeout in values.yaml and upgraded our helm release. But it stays up till its default value which is 100 seconds. Is there anything we are missing?
Version of Helm and Kubernetes:
$ helm version
Client: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.8-eks-b7174d", GitCommit:"b7174db5ee0e30c94a0b9899c20ac980c0850fc8", GitTreeState:"clean", BuildDate:"2019-10-18T17:56:01Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/jenkins
What happened:
The pods are still in ContainerCreating state even after set value of 30 secs in agent.slaveConnectTimeout:
worker-test-commands-034pm-zrb64                 0/2     ContainerCreating   0          62s

What you expected to happen:
Worker pod should start terminating, after 30 secs as per the value set in agent.slaveConnectTimeout rather than 100 secs which is the default.
How to reproduce it (as minimally and precisely as possible):

Update the below value in values.yaml :

# Timeout in seconds for an agent to be online
  slaveConnectTimeout: 30

Upgrade or Install the helm chart.
Run a few jobs/pipelines in jenkins, if the worker pod is in ContainerCreating state for more than 30 secs, it should start terminating as it does after 100 secs.

Jenkinsfile:
def label = "worker-test-commands"
podTemplate(label: label, name: label, containers: [
	containerTemplate(name: 'docker', image: 'vishnuhdadhich/docker-awscli-curl:18.06', command: 'cat', ttyEnabled: true)
],

volumes: [
	hostPathVolume(mountPath: '/var/run/docker.sock', hostPath: '/var/run/docker.sock')
]) {
	node(label) {
			stage('Pre Build') {
			    container('docker') {
				script{
					sh "docker images"
				    }
			    }
			}
	}
}

Silly, but I checked it later, the slaveConnectTimeout needs to be updated in pod templates as well - slaveConnectTimeout: 30, closing the issue.


Make Node Map object options "request" property optional

The current Node Map requires you to implement a request function, so everything Node Map needs, it asks to this function. This PR allows you to choose if you really want this, or if it's ok to let Node Map use its internal loaders.

Whats the difference between the internal loaders and the one you implement youself? Would it work with http and local files or would it depend what you wanted to use this with if you need to implement your own.

The internal loaders implement their own logic, you can learn about them here. But they work well for the basics. There is a provider for local files (local_file_source.cpp), or online files (http_file_source.cpp), and a dedicated provider for MBTiles as well. So unless they don't do something specific you need, they are a good fit, so there's no point in reimplementing something they already do, like dealing with all those HTTP status codes and stuff. But of course, if your logic is more complex, like doing specific things depending on the resource requested, you still can implement your request function.

An addendum: if you implement your request function, then the internal loaders are disabled and all requests are sent to your function, exactly like it was before this PR.

Done!

Nice. Please check if the README.md changes are reflecting all those changes.


Add extensive Linux Docker setup instructions

Tried ddev for the first time, on a brand new Ubuntu 18.04 install. I've previously only played with Docker on a mac, so this was new ground for me, making me your ideal test subject. My experience was bumpy, I spent an under-caffeinated hour getting everything to work.
Once I installed ddev, I got a message saying that Docker and Docker Composer are not installed.
My expectation was that the ddev install script would do this for me, since I'm on a OS where both are a few commands away. Nevermind, I'll just paste the commands from the docs. However, ddev didn't give me a link to its docs that shows what I need to paste, it sends me to Docker's confusing marketing website, which takes me to a page listing supported Ubuntu versions, none of them 18.04. I get confused and give up. Decide to install Docker myself. Google for "Install docker" and click the first link, which tells me to do an "apt install docker-io". This is the Docker from the official Ubuntu repo, and it's too old for ddev. I learn that after I've installed it. I go back and uninstall docker-io. Then I follow the next link, which tells me to add the external Docker repo and do an apt install.
The tutorial that did the trick was https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04, though I also initially skipped the "optional" step of configuring Docker for non-root, which required me to sudo all ddev commands. This step was mentioned in the ddev docs, but I was already away from them due to needing to figure out what to do with Docker.
My bumpy experience would have been much less bumpy if there was an official ddev docs page that at least sent me to the digitalocean tutorial, with notes saying "don't use ubuntu's docker" and "now setup docker to run without root".

Great to have you taking ddev for a spin!
Linux is kind of hard because docker has different instructions for every variety. The right way to do ubuntu and debian is to install the docker debian repo, I imagine that's what you did.
Don't forget the post-install instructions, which we do have several links to. https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user
Thanks for the prod, we can maybe have a separate section with links on ubuntu techniques, I agree it's hard to get to the right place on docker.com, and they keep fooling with it. We currently link to https://www.docker.com/community-edition, which finally links to the right place, https://docs.docker.com/install/linux/docker-ce/ubuntu/ but it's definitely a crazy set of links.

It might be possible for ddev or the install script to just check to see if the group setup has been done, would save Linux users new to docker a lot of pain.

@bojanz would love it if you could review the docs changes in https://github.com/drud/ddev/pull/1041

Fixed in #1041


Request: allow administrators to always hide the Deferral button during any refresh window.

In issue #548 , I have asked for deferRunUntil to reflect a time that includes the duration of the various refreshCycle timers, depending on what window Nudge is in (initial, approaching, imminent).  As an alternate behavior, please consider an option that would allow administrators to always hide the Deferral button under any circumstance.  That way the users can be given a promised interval before Nudge pops up, but they can still pile their windows on top, since Nudge cannot be currently moved.
Edit: I would like to do this without lowering the deferral threshold to zero, which would trigger aggressive behavior.  I'd like to reserve aggressive mode for the expired refresh cycle ONLY.

allowUserQuitDeferrals already exists.


[JS][KeyVault] Ensure KeyVault Secrets SDK meets guidelines

We should double check that the SDK matches the requirements here. If there are differences, we'll file as separate issues and work through them.

@jonathandturner Do we want to keep this issue open?


Navigate to chapter verse in TSV

Issue:
Users want to be able navigate to the chapter and verse quickly and easily so they don't have to page in order to get back to where they were or fix the specific issue they are working on
DoD:
Users can jump directly to a chapter and verse in a TSV (both TN and TWL).
Details:
This could be done with a special search function, or with a filter.   To do this well, we'll need to implement #928, but it is not a blocker.

@Joel-C-Johnson Can you please add a screenshot or steps to Navigate to a chapter/verse?

@elsylambert
Now users can jump directly to a chapter and verse in a TSV (both TN and TWL). This is done inside the filter option.
Here are the steps,
In TN

Login to tc-create-app.
Select any organisation.
Select Resource "en_tn"
Select any book.
On the top right corner click on the filter option and you can see the updated chapter and verse field inside it.

In TWL

Login to tc-create-app.
Select any organisation.
Select Resource "en_twl"
Select any book.
On the top right corner click on the filter option and you can see the updated field "reference" inside it.


MSGID kludges from Synchronet are not interpreted correctly

The BBS software/FidoNet reader SynchroNet generates messages that has a MSGID kludge line on the format "(something)@(FidoNet address) (timestamp)" (e.g. "29.fidonet-fn_sysop@1:2320/33 25a3ef3b")
Most other systems (including NiKom) use the format "(FidoNet address) (timestamp)" (e.g. "1:2320/33 25a3ef3b") and this is the format that NiKom expects when parsing the MSGID kludge to try to figure out to and from address of a text. As a result the interpreted address may be wrong (especially the zone part). In the example above NiKom interprets it as "29:2320/33".
The FTS (http://ftsc.org/docs/fts-0009.001) is not super clear about what the format actually should be. I believe though that Synchronet's format is wrong. Other BBS softwares seems to have had similar problems: http://wiki.mysticbbs.com/doku.php?id=whats_new_112
Since it's unlikely that Synchronet will change, NiKom needs to understand this format.

The FTN message ID isn't for "parsing". It's for unique message identification (e.g. for dupe detection) and reply-linking.  If you're parsing the message ID for some purpose (e.g. to figure out to and from address of a text), you're misusing this (optional) control information.


chore: update use-case & license year

Fixes
A short description of what this PR does.
Checklist

[x] I acknowledge that all my contributions will be made under the project's license
[ ] I have made a material change to the repo (functionality, testing, spelling, grammar)
[ ] I have read the Contribution Guidelines and my PR follows them
[ ] I have titled the PR appropriately
[ ] I have updated my branch with the main branch
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added the necessary documentation about the functionality in the appropriate .md file
[ ] I have added inline documentation to the code I modified

If you have questions, please file a support ticket.

when we are using sendgrid functionality for assessment or trigger event it is working fine. while we are calling the function for rest password it is not getting triggered first time while resending it is working.
Note: it is happening in vercel server , from localhost it is working again properly. how to resolve this. as it is in production . i'm sharing snapshot of code and activity feed for reference.
server giving 200 status no errors, but email is not triggering for the first time to the person while resending it , it is coming.
and our api key is set for full access , then in vercel server only reset email is not working , template email or event email working fine


Fix: Body Overflow  in y-direction- Adjust Flex Direction for Buttons

This pull request addresses the overflow issue in the Y-direction caused by the Roadmap Section. The flex direction for the roadmap buttons has been changed to column to better fit smaller screens, resolving the overflow and improving the user experience on mobile devices.
Fixes

Fixes issue #149

Changes Made

Updated the flex direction of the roadmap buttons from row to column to ensure proper layout on smaller screens.
This resolves the vertical overflow and aligns the content correctly on all screen sizes.

Screenshots

BEFORE
AFTER

Checklist

[x] Changed flex direction for roadmap buttons to column.
[x] Tested the changes on multiple screen sizes to ensure responsiveness.
[x] Code follows the established coding style guidelines.

Please review and merge. Thank you!

Fixes #149


Add .recommenders to gitignore

Description
This PR adds the .recommenders directory to .gitignore. .recommenders is a new directory for code recommendations from the latest eclipse update and as such should be excluded from the repo.

Hooray Jenkins reported success with all tests good!


I wish /v1.1/docs/roadmap.html existed

I wish /v1.1/docs/roadmap.html existed

That page was really always hosted here, so I pulled it:
https://github.com/kubernetes/kubernetes/milestones/

@johndmulhausen I still find the original link vie Google Search, and it still gives me a 404.
http://kubernetes.io/docs/roadmap/
Is it not better to put a redirector on the old URL for all such URL's.  I'm sure that there are tons of third party links out there (e.g. in press releases, blog posts etc) that we won't be able to update.

@johndmulhausen I don't seem to be able to re-open this issue (permissions problem?).  Can you fix that too?  I guess that the Kubernetes team should continue to have the same permissions as they had on the previous docs repo.

Reopened

We don't have a useful roadmap doc, but I agree we should have a placeholder or redirect or anything other than 404.

Added a redirect in https://github.com/kubernetes/kubernetes.github.io/commit/ef891efae587c35cbf81ab7f9efc05c9ee114741

Awesome @johndmulhausen!  Thanks!


[move-prover] Verified save_account in LibraAccount

Updated Prelude to add the builtin Boogie model for the native function LibraAccount::save_account
Corrected the forward declarations of $LibraAccount_T_type_value and $LibraAccount_Balance_type_value in Prelude and bytecode_translator.rs
Added and verified a temporary function verify_save_account in LibraAccount
Added a FIXME in libra_account.move

the current spec of create_account should be verified, but Z3 does not terminate on this.

Motivation
(Write your motivation for proposed changes here.)
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
(Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

What does "only_verify_spec" option do?

What does "only_verify_spec" option do?

With this option, Prover generates _verify procedures only for the functions having their specifications defined (https://github.com/libra/libra/pull/3357).

@bors-libra r=wrwg

:pushpin: Commit e4a863d has been approved by wrwg

:hourglass: Testing commit e4a863d442539e55776777ca503d414e42254d4e with merge 03f5200e05f40f26c337f8e8f5481dcc89332ed4...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: wrwg
Pushing 03f5200e05f40f26c337f8e8f5481dcc89332ed4 to master...


Add Response

This PR introduces the Response object that is now returned (as a specialized Struct) from the various API methods.
/cc @aeden

@aeden this is ready for cross-review.
Here's the relevant changes

Added a common Response struct
Changed Response and ErrorResponse to both store the *http.Response for further usage
Added support for rate-limit details using RateLimit(), etc.
Changed all the methods to return a tuple of *Response, error instead of *object, *Response, error :tada:

I also added an example of a state-less helper that returns the data.
You can check the code, and/or run the tests using
$ go test ./... -v

There are also some live tests test_live.go that hits sandbox and give you an idea on how some usage may look like
$ DNSIMPLE_TOKEN=xxx go test ./... -v --run "TestLive"

:shipit:


Can´t collapse

Hi, my name is Abel , I have implemented this library in my app but the plus and minus icons not appear, so is impossible to collapse the nodes.
Thanks in advance.

I have fix it. The problem was i had installed the bootstrap 4.0.0 and I now I have installed the 3.3.7 and all works. Maybe incompatibilities problems with the new version of bootstrap??

https://getbootstrap.com/docs/4.0/migration/#components


⚠ Bofrost.be has degraded performance

In d60968e, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1036 ms

Resolved: Bofrost.be performance has improved in 15cf4c2 after 31 minutes.


formatString() TypeScript type specifies Array as a return value

Hello, thanks for making this package. I enjoy using it.
However, I encountered a potential issue while using it with TypeScript.
It seems that formatString() return type specifies an Array as well as string.
Shouldn't it only be a string? Since even docs specify that it returns a string.

formatString() - formats the input string and returns a new string, replacing its placeholders with the other arguments strings

See the location of the type and commit in question:
https://github.com/stefalda/react-localization/commit/8a700b20b51cd3415f6ee35ee36a4f538d59862c#r133591646
Seems that this the potential issue has been introduced in:
https://github.com/stefalda/react-localization/commit/f3f73851364aae8948d8daa1e0f56195bd308000

Do you think it is a good decision to have both JSX and string formatting for 1 function?
It generally doesn't matter if the output is used directly in the renderer. But when the formatString output is used as an function argument there will have to be additional checking on every use.

The JSX interpolation wasn't an option at start, it was added in a second time... but if we create a separate function we break existing uses..

It's a hack, but you can override this behavior in your project by extending the LocalizedStringsMethods type.
// copied from type definition
// https://github.com/stefalda/react-localization/blob/master/lib/LocalizedStrings.d.ts
type Formatted = number | string | JSX.Element;
type FormatObject<U extends Formatted> = { [key: string]: U };

interface FixedLocalizedStringsMethods extends LocalizedStringsMethods {
  formatString<T extends Formatted>(
    str: string,
    ...values: Array<T | FormatObject<T>>
  ): string;
}

// now strings.formatString just returns a string
export type strings = FixedLocalizedStringsMethods & ILocalizedStrings;


scrollTop / scrollLeft binding

Investigate support for two-way scrollTop / scrollLeft binding using the scroll event.

Let's hold off on this until after the perf work. If you don't have anything else that's really important, then we need to start on benchmarking the binding engine immediately so we can start to work on the improvements ASAP. Let me know.

I've already implemented this- it's a basic attributeMap, EventManager.registerElementConfig

Cool :)
On Sun, May 31, 2015 at 8:51 PM, Jeremy Danyow<EMAIL_ADDRESS>wrote:

I've already implemented this- it's a basic attributeMap,
EventManager.registerElementConfig
—
Reply to this email directly or view it on GitHub
https://github.com/aurelia/binding/issues/98#issuecomment-107271001.

--
Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

PRs in binding + templating-binding ready for review.


useSignalEffect won't fire.

I'm unable to get use signal effect to fire in my React Application if I follow the following set up.(adjRow is the deep signal.)

useSignalEffect(()=>{
    if(finalTableRows.length > 0 && adjRow.action=== 'adding'){
      // some code here
      adjRow.reset();
    }
  })

However I can get the useSignalEffect to fire if instead I assign adjRow.action to a variable.
useSignalEffect(()=>{
    const action = adjRow.action
    debugger;
    if(finalTableRows.length > 0 && action=== 'adding'){
     // some code here
      adjRow.reset();
    }
  })

is this something to do with the way signals / reactivity works ?
Please not i am using / have tried babel transform and the useSignals hook to wire my react appication in.

### Versions

react - 18.3.1
@preact/signals-react - 2.2.0
deepsignal - 1.5.0

Could you please reproduce the error using StackBlitz so I can take a look? You can fork this template to get started.

Hi, here's the code, but it seems to work fine. I can access the signal without having an assignment operator. I can't reproduce my error means it has something to do with my set up.
https://stackblitz.com/edit/vitejs-vite-cyswtz?file=src%2Fmain.jsx
But in my codebase we are using webpack and babel also in the babel trasform i have set it to manual,
{
    "presets": [
        "@babel/preset-env",
        "@babel/preset-react"
    ],
    "plugins": [
        ["@babel/transform-runtime", {
          "regenerator": true
        }],
        ["module:@preact/signals-react-transform", {
          "mode":"manual"
        }]
      ]
}

as auto gives me this error
 Warning: Invalid hook call. Hooks can only be called inside of the body of a function component.

now that i test it out with just preact, it happens with preact too. Doesn't matter if I use the useSignals hook or if i annotate my components like

/**
 * @useSignals
 */
const Component = (props) => {

More info.
"webpack": "^5.51.1",
"webpack-cli": "^4.7.2",
"webpack-dev-server": "^3.11.2"
"babel-loader": "^8.2.2",
"@babel/core": "^7.15.0",
Another interesting observation is our node is locked in at v14.
I think I'll file an issue over at preact as well. We can close this because this is clearly not an issue with deep signals.

We can close this because this is clearly not an issue with deep signals.

Alright, I'll close it then. Feel free to reopen it if you find that the issue is indeed related to deepsignal.


param_get() simple c++ wrapper

This PR adds a float and int32 param_get() c++ wrapper. I'm not sure if this is worth merging, but I noticed the common param_get() usage was prone to subtle errors and this seemed like a good way to at least discuss alternatives.
__EXPORT bool param_get(param_t param, float &val);
__EXPORT bool param_get(param_t param, int32_t &val);

For example
    param_get(_params_handles.mc_airspeed_min, &_params.mc_airspeed_min);

If the parameter mc_airspeed_min were an int32, but _params.mc_airspeed_min a float this won't produce an error, but the value of _params.mc_airspeed_min will be bogus.
This also changes the return value to bool to encourage actually checking, including multiple successive param_get() calls.
param.cpp could be used as a base to build out a newer c++ param and type safe API.

Another example.
param_get(_param_sys_type, &(status.system_type));

https://github.com/PX4/Firmware/blob/5c524e15f8e1a16cabe1dba3400cb91fa314ef83/src/modules/commander/commander.cpp#L1643
status.system_type is a uint8_t, but the param_get call is copying the full param (MAV_TYPE 32 bits) starting at this address. In this case it doesn't cause serious problems because the fields after system_type are bools that are updated.

Sorry for realising this only now, but we can't merge this as is: You've created a C++ variant of param_get with an inverted return value: bool vs int and the meaning of if (param_get()) is inverted.
I think there are two optimal solutions:

Have the C++ wrapper mimic the C API and just making it safer
Allow the use of BlockParam (which is very clean and nice) outside of a SuperBlock class

I would vote for doing 1) in this PR.

I agree that was shady, but thought it might be acceptable given how rarely we're checking return values.
What about a new name for the c++ version and keep the bool? The use of int return on its own can cause confusion, so if possible I'd like to try to move away from it.
param_update, param_fetch, param_copy?

I'm very much in favour of type-safety. The existing API was designed to be easy-to-use. But I think by adding more API calls, I probably would be confused as a novice/irregular contributor as to which one I should use.
We already have a separate API, the BlockParam, more suited for C++ (It has a different drawback, as it needs 50% more memory per parameter, because it's based on a linked list).

I agree, I'm just concerned by the accidental misuse of param_get() I've already seen.
I generally like using controllib. Is it feasible to gradually move everything in that direction or do we need/want a solution without a Superblock (and additional overhead)?

Is it feasible to gradually move everything in that direction or do we need/want a solution without a Superblock (and additional overhead)?

If the overhead is gone, it would be the superior solution. When used within the whole system, the overhead is quite noticeable: https://github.com/PX4/Firmware/commit/7c6d99d30f2cb83fbf


Corruption: block checksum mismatch

While monitoring ITN, we saw the following error message on a node:
Raised at Yojson.Safe.float_needs_period in file "write.ml", line 117, characters 15-25	monitor.ml.Error, Failure,
Corruption: block checksum mismatch: expected<PHONE_NUMBER>, got<PHONE_NUMBER>  in /home/minaT/.mina-config/frontier/000346.sst offset 25578147 size 3204200,
Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33,
Called from Rocks__Rocks_common.finalize in file "src/external/ocaml-rocksdb/rocks_common.ml", line 98, characters 8-12,
Re-raised at Rocks__Rocks_common.finalize in file "src/external/ocaml-rocksdb/rocks_common.ml", line 102, characters 21-30,
Called from Rocksdb__Database.Batch.with_batch in file "src/lib/rocksdb/database.ml", line 57, characters 4-26,
Called from Async_kernel__Deferred1.M.map.(fun) in file "src/deferred1.ml", line 17, characters 40-45,
Called from Async_kernel__Job_queue.run_job in file "src/job_queue.ml" (inlined), line 128, characters 2-5,
Called from Async_kernel__Job_queue.run_jobs in file "src/job_queue.ml", line 169, characters 6-47,
Caught by monitor coda

We should investigate what could cause this issue, and look out if we see it again

Triage update: this was initially investigated and the theory is that random node crashes could be causing corruption of RocksDB. It is difficult to investigate further without more concrete repro steps and/or history.

Triage update: Michal and team to try and reproduce this and investigate issue further.

Not enough information to continue investigating. Closing.


fix(dataset-import): support empty strings for extra fields

SUMMARY
During the import process, the extra value for datasets is loaded as a dictionary. This operation fails in case the extra key has an empty string (extra: "").
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

Edit an existing dataset.
Add any information to the extra value (in the UI).
Save changes.
Modify the dataset again.
Remove your text changes.
Save changes. The dataset now has extra: "".
Export the dataset.
Import it back.

ADDITIONAL INFORMATION

[x] Has associated issue: Fixes #24662
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

This is great, thanks @Vitor-Avila!


Initial implementation of testing

Implements some tests for the compute_isn function on SNP data.

@GiadaLalli when reviewing can you please check the "expected" numbers carefully. Also, anything using the "dot" metric fails with:
E                   TypeError: max() received an invalid combination of arguments - got (out=NoneType, axis=NoneType, ), but expected one of:
E                    * ()
E                    * (Tensor other)
E                    * (int dim, bool keepdim)
E                         didn't match because some of the keywords were incorrect: out, axis
E                    * (name dim, bool keepdim)
E                         didn't match because some of the keywords were incorrect: out, axis

../../.cache/pypoetry/virtualenvs/isn-tractor-OaWcndho-py3.11/lib/python3.11/site-packages/numpy/core/fromnumeric.py:84: TypeError

There are 2 tests for the "dot" metric that are skipped at the moment. Could you investigate this please?

@GiadaLalli when reviewing can you please check the "expected" numbers carefully. Also, anything using the "dot" metric fails with:
E                   TypeError: max() received an invalid combination of arguments - got (out=NoneType, axis=NoneType, ), but expected one of:
E                    * ()
E                    * (Tensor other)
E                    * (int dim, bool keepdim)
E                         didn't match because some of the keywords were incorrect: out, axis
E                    * (name dim, bool keepdim)
E                         didn't match because some of the keywords were incorrect: out, axis

../../.cache/pypoetry/virtualenvs/isn-tractor-OaWcndho-py3.11/lib/python3.11/site-packages/numpy/core/fromnumeric.py:84: TypeError

There are 2 tests for the "dot" metric that are skipped at the moment. Could you investigate this please?

I was checking this, and I was actually reminded of this: did we actually ever update tractor? I mean, I do remember adding on a Friday evening the dot product, but is it in the library? Because I don't think so. I suppose it fails because when we call "dot" & "avg" or "max" it doesn't recognise the metric as a correct input.

Problem can be solved by updating:
elif method == "dot":  # dot product
# pylint: disable=E1101
scores = t.matmul(X.T, Y).numpy()
score = __pooling(scores, pool)


[Ask] Is there any method to modify mjuiState_ 's rect  mutable ?

First of all, thank you for developing MuJoCo.jl !!!
I'm a beginner in Julia.
I'm trying to re-implement original MuJoCo's simulate.cc by Julia with MuJoCo.jl.
However, I've encountered a big problem:  I found that mjuiState_'s  rect type is NTuple{25, mjrRect} :  it is immutable (I'm supprised and frustrated)
For example, I've tried to re-implement below codes, but I found that MuJoCo.jl's mjuiState_ 's rect type is immutable.
simulate.cc : void Simulate::RenderLoop()
auto [buf_width, buf_height] = this->platform_ui->GetFramebufferSize();
this->uistate.nrect = 1;
this->uistate.rect[0].width = buf_width;
this->uistate.rect[0].height = buf_height;
I wonder that is there any method to modify mjuiState_'s rect type to mutable type ?
I tried to replace NTuple by SVector (StaticArrays), but MuJoCo.jl package was not worked.
If I can't find a solution to this, I may have to give up. (very sad)
If there is a solution, I'd appreciate it if you could let me know.

Since reallocation of NTuple is working, as a temporary method I use this method to modify uistate.rect values.
I wonder if there is a better way.

Thanks @kshfire for the question, and it's great that you are trying to replicate the simulate.cc functionality. This should be fairly similar to what we have in the Visualiser extension, if you want to take a look there for reference.
Most of the underlying bindings to the C library (meaning in the LibMuJoCo module) are auto-generated and essentially map 1 to 1 with the C equivalent. There are good reasons for not making everything mutable by default. In other cases, we have friendly Julia wrappers for the most common structs (mjData, mjModel etc), but we don't have this for the visualisation internals.
You should still be able to do everything you can in C, albeit in a less ergonomic way. One option to make it a bit less painful is to use the Setfield.jl package, which gives you a macro to let you write "pseudo-mutating" code. As an example:
using Setfield, MuJoCo
s = MuJoCo.LibMuJoCo.mjuiState();

# Set nested fields one at a time
s = @set s.rect[1].width = Int32(100)
s = @set s.rect[1].height = Int32(50)
s = @set s.rect[1].left = Int32(0)
s = @set s.rect[1].bottom = Int32(0)
# OR: Set the entire rect at once
s = @set s.rect[1] = mjrRect(Int32(0), Int32(0), Int32(100), Int32(50))

println(s.rect[1]) # MuJoCo.LibMuJoCo.mjrRect_(0, 0, 100, 50)

Unfortunately, the underlying type is a Cint (Int32), so the conversions to Int32 are necessary at the moment, but this would change when we get around to wrapping the structs.
I hope this helps for now, but I think it would be beneficial to add an issue to wrap more of the internals in a Julia friendly way so that making visualisation extensions is easier in the future. I've opened - https://github.com/JamieMair/MuJoCo.jl/issues/115 for when we have some time to implement this.


Stuck on photos script

I get hung up on line 265 of the photos script. Everything else before that seems to work. I started a review in my pull request.

try addressing https://github.com/NewGraphEnvironment/fish_passage_skeena_2022_reporting/issues/14.  Also make sure all sites have comments with period at end (before time) and times are 24hr format.
Print function fpr::fpr_photo_sort_plan to the console (copy and paste into console and run) and check ?fpr::fpr_photo_sort_plan to see if there are hints to missing data that is required to make things happen.
and if still doesn't work break pipes from top down then link issue to line it breaks on.  If you copy the error message to the issue that may provide insight too...


Corrupted outputs with Marlin int4 kernels as parallelization increases

When using MarlinInt4WeightQBitsTensor and its associated optimized gemm kernel, there are issues with the weight/scales/zero-point readback as soon as parallelization increases.
The consequence is that output features higher than 128 are corrupted when a sufficient amount of inputs are parallelized.
Test to reproduce the issue here: https://github.com/huggingface/optimum-quanto/blob/852bb9cb6fb707a6fcebff7e068dc6bbdda779cb/test/tensor/weights/optimized/test_marlin_int4_weight_qbits_tensor.py#L134

Could be related, but I noticed the latest release of optimum-quanto (v0.2.5) corrupts transformer weights during qfloat8 quantization. Downgrading to 0.2.4 solved this issue. Not sure what the exact cause is but will look into it
Code that caused corruption in 0.2.5 but not earlier versions:

quantize(pipe.transformer, weights=qfloat8)
freeze(pipe.transformer)

quantize(pipe.text_encoder, weights=qfloat8)
freeze(pipe.text_encoder)

quantize(pipe.text_encoder_2, weights=qfloat8)
freeze(pipe.text_encoder_2)

Could be related, but I noticed the latest release of optimum-quanto (v0.2.5) corrupts transformer weights during qfloat8 quantization. Downgrading to 0.2.4 solved this issue. Not sure what the exact cause is but will look into it
Code that caused corruption in 0.2.5 but not earlier versions:
pipe = FluxPipeline.from_pretrained(...

quantize(pipe.transformer, weights=qfloat8)
freeze(pipe.transformer)

quantize(pipe.text_encoder, weights=qfloat8)
freeze(pipe.text_encoder)

quantize(pipe.text_encoder_2, weights=qfloat8)
freeze(pipe.text_encoder_2)

Yeah, same here. I was confused at first because the generated image was just pure noise so I downgraded to this version
https://github.com/huggingface/optimum-quanto.git@65ace79d6af6ccc27afbb3576541cc36b3e3a98b
and it worked fine. (This was the 0.25.0.dev0)

@inarikami @Leommm-byte this cannot be related, as the new Marlin kernel is only available for qint4 and is not used by default.
If you have a script allowing to reproduce the corruption on 0.0.25, feel free to open an issue.

I'll dig deeper as I have some time.

@ahadnagy thank you for your feedback: ping me if you need any help.

So far I've found two possible race conditions:

Between fetch_to_shared() and fetch_to_registers():
https://github.com/huggingface/optimum-quanto/blob/66dca87bc7e61ffbf1a06da9fd324469592e17e9/optimum/quanto/library/extensions/cuda/marlin/marlin_cuda_kernel.cu#L395
https://github.com/huggingface/optimum-quanto/blob/66dca87bc7e61ffbf1a06da9fd324469592e17e9/optimum/quanto/library/extensions/cuda/marlin/marlin_cuda_kernel.cu#L451

Between fetch_to_registers() and thread_block_reduce()
https://github.com/huggingface/optimum-quanto/blob/66dca87bc7e61ffbf1a06da9fd324469592e17e9/optimum/quanto/library/extensions/cuda/marlin/marlin_cuda_kernel.cu#L445
https://github.com/huggingface/optimum-quanto/blob/66dca87bc7e61ffbf1a06da9fd324469592e17e9/optimum/quanto/library/extensions/cuda/marlin/marlin_cuda_kernel.cu#L451

The second one appears at relatively small sizes as well:
@pytest.mark.parametrize("tokens", [16])
@pytest.mark.parametrize("in_features", [512])
@pytest.mark.parametrize("out_features", [256])

@dacorvo  Could these be related to the memory issues you suspected? Not sure if these are false positives or not, I'll have to dig into the indexing and pipelining to make sense of it as this kernel is quite involved.
But first, I'm gonna send identities through in a more minimal reproducer, hopefully a pattern will emerge.

Just did the same test on the original Marlin kernel and it exhibists the same behaviour:
https://github.com/ahadnagy/marlin/blob/5a4396ae41ed0acf3b4ac6169ca449eac7717fa1/test.py#L208
For k=32 the result is the same between kernel invocations, at k=62 there are ~60k differing values in the matrices.

FWIW, it fails quite predictably.

@ahadnagy thank you for your investigations. I think that at this stage it may be worth creating an issue in the vLLM repository where the marlin kernels are now maintained, although I don't know how much time it would require to create a reproducible example using that version of the kernels:  https://github.com/vllm-project/vllm/blob/main/csrc/quantization/gptq_marlin/gptq_marlin.cu.
As far as quanto is concerned, do you have ideas how I could narrow down the investigations to identify what could prevent the race condition ?

@dacorvo  I'm happy to do it!
I'll make an attempt to reproduce this in the vLLM version today. Hopefully it won't get too involved.
As far as debugging the kernel goes, there's no easy way to debug these kind of issues unfortunately.
I see two possible causes:

if the race condition is caused by missing barriers, that's most likely a pipelining issue, so I'd start by dissecting the pipeline and the main loop. (CUDA_LAUNCH_BLOCKING =1 could help verifying this, but it won't affect the streaming API, so in this case it might not help at all). I tried sprinkling more synchronisation primitives at critical places, but that didn't help.

It's also possible that the race condition is a symptom of an indexing issue, and sometimes regions overlap in the shared memory. It's gonna be hard to spot the problem without completely understanding how the partitioning, tiling and slicing works in the kernel. It's not something that's easy to eyeball in this kernel. Normally, I just go through the kernel by hand and place counters for global and shared memory accesses, then output stats.
If the situation gets dire enough, it's also a viable option to log all accesses from the places suggested by Compute Sanitizer to another scratchpad tensor, save it as a dataframe, and use statistical methods to find the diverging threads and figure out which indices went over.

In some cases, Nsight Compute's uncoalesced mem. access metrics  can also give a hint on top of what Compute Sanitizer finds.

"Good" news, I was able to reproduce this in the vLLM version as well:
https://github.com/ahadnagy/vllm/blob/d2d7def73a8e9c3843b32fdc9adc8e71605b397c/tests/kernels/test_marlin_gemm.py#L619-L686
It seems like only the gptq Marlin kernel is affected.
It fails for the same shapes, has the same race conditions reported, so everything's in order to submit an issue. I'll do that tomorrow.

Could be related, but I noticed the latest release of optimum-quanto (v0.2.5) corrupts transformer weights during qfloat8 quantization. Downgrading to 0.2.4 solved this issue. Not sure what the exact cause is but will look into it
Code that caused corruption in 0.2.5 but not earlier versions:
pipe = FluxPipeline.from_pretrained(...

quantize(pipe.transformer, weights=qfloat8)
freeze(pipe.transformer)

quantize(pipe.text_encoder, weights=qfloat8)
freeze(pipe.text_encoder)

quantize(pipe.text_encoder_2, weights=qfloat8)
freeze(pipe.text_encoder_2)

Yeah, same here. I was confused at first because the generated image was just pure noise so I downgraded to this version
https://github.com/huggingface/optimum-quanto.git@65ace79d6af6ccc27afbb3576541cc36b3e3a98b
and it worked fine. (This was the 0.25.0.dev0)

but it will lead to KeyError: 'time_text_embed.timestep_embedder.linear_1.base_layer.weight_qtype'


When the Response is not a valid object issue

Hi
I have problem a problem with mocha  sorry if it has been posted before me
When I have a response and is not a valid json object , Its playing creazy the response has a status code and a reponse like this
Status 400 Bad Request
Response body :
{"message": "{ "message" : "Field: 'name' is null" }"}
but the mocha says
TypeError: Cannot read property 'statusCode' of undefined
    at Test.<anonymous> (29.Preference.js:371:27)
    at Test.assert (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:156:6)
    at assert (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:127:12)
    at /Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:124:5
    at Test.Request.callback (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/index.js:781:12)
    at /Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/index.js:955:25
    at IncomingMessage.<anonymous> (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/parsers/json.js:13:7)
    at endReadableNT (_stream_readable.js:903:12)

I know that is not a valid json object but its better to have a better response from mocha
I had many days problem till I found with Postman what was the problem
thank you for your work

I think there might be an issue with the test itself. You're probably doing something like assert.equal(res.statusCode, X); but res isn't defined in this case, hence Cannot read property 'statusCode' of undefined. I'd recommend adding another assertion that res is defined. Hope that helps! :)

The response is a malformed json so this is why it says is not defined
is not a problem with the test

Sure, but you can write your assertions so that they're more helpful. E.g.
var expect = require('chai').expect;
// Instead of this:
expect(res.foo.statusCode).to.equal(200);
// => TypeError: Cannot read property 'statusCode' of undefined

// You can do this:
expect(res).to.have.property('foo');
expect(res.foo.statusCode);
// => Assertion error: res does not have property foo

Mocha can't help much with a TypeError, but an AssertionError should look cleaner! :)

I have the same problem too.
If the API returns somehow an object like this: {"message": "{ "message" : "Field: 'name' is null" }"}, then mocha crashes and i cant even read the response, and sure not any type of value of response, like statusCode, body, header etc.
In this case response(or res) is undefined, like the error of @GranitB states:
TypeError: Cannot read property 'statusCode' of undefined     at Test.<anonymous> (29.Preference.js:371:27)     at Test.assert (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:156:6)     at assert (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:127:12)     at /Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/supertest/lib/test.js:124:5     at Test.Request.callback (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/index.js:781:12)     at /Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/index.js:955:25     at IncomingMessage.<anonymous> (/Users/macbookpro/Desktop/java-api/hk-api-v3/hotelkey/node_modules/superagent/lib/node/parsers/json.js:13:7)     at endReadableNT (_stream_readable.js:903:12)
If response is undefined, we cannot read anything. I think this is an error in API because it shouldn't return a message with another object of message key, but mocha should handle this. If you still do not understand, or think this is not an error, i will give you a sample.

Also, im sory to say this but i think you shouldn't close one issue, when its still an issue!
I wouldn't figure it out never this problem with mocha, if i would not have Postman.

Sorry, I closed this cause because it's an expected JS exception with a clear description. You're accessing a property of something that's undefined. I'm not sure what else you'd like to decorate it with.
If you wanted the message to instead read TypeError: Cannot read property 'statusCode' of undefined variable Foo, that would require parsing the exception stack trace to get the line/column numbers, and then reading the file to extract the relevant identifier. A PR would be welcome, but I don't see this as gaining much.
In your example, it should be clear from the stack trace that at line 156, you're trying to access statusCode of a variable or property that's undefined.

For example, it should be clear why this happens from the stack:
try {
  var foo = {};
  foo.bar.invalid = 'will throw';
} catch (e) {
  console.log(e.stack);
}

$ node test.js
TypeError: Cannot set property 'invalid' of undefined
    at Object.<anonymous> (/Users/dstjules/git/test/test.js:3:19)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:140:18)
    at node.js:1001:3


macOS Support

Will macOS be added at some point? so that it can be installed as a service.

Hi,
sorry for the late answer.
I have no knowledge of macOS.
Can you explain me if you encounter problem please?

Well for one thing it would be nice if a Launchctl Service File could be generated that would start matterbridge. Similar to how you have a systemctl for linux here: https://github.com/Luligu/matterbridge/blob/main/README.md#run-matterbridge-as-a-daemon-with-systemctl-linux-only
I was receiving an error but tried installing again and not getting that right now

eneralDiagnosticsCluster.setNetworkInterfacesAttribute for Matterbridge error: ValidationError: Validation error for attribute "networkInterfaces"in field [0].iPv6Addresses.[0]: (Validation/135) String is too short: 12, min 16.
2024-05-24 10:43:41     at StringSchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvString.js:39:13)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:62:34)
2024-05-24 10:43:41     at tryCatch (file:///app/node_modules/@project-chip/matter.js/dist/esm/common/TryCatchHandler.js:8:12)
2024-05-24 10:43:41     at file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:61:7
2024-05-24 10:43:41     at Array.forEach (<anonymous>)
2024-05-24 10:43:41     at ArraySchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:60:10)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvObject.js:137:24)
2024-05-24 10:43:41     at tryCatch (file:///app/node_modules/@project-chip/matter.js/dist/esm/common/TryCatchHandler.js:8:12)
2024-05-24 10:43:41     at ObjectSchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvObject.js:136:9)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:62:34) {
2024-05-24 10:43:41   code: 135,
2024-05-24 10:43:41   clusterCode: undefined,
2024-05-24 10:43:41   fieldName: '[0].iPv6Addresses.[0]'
2024-05-24 10:43:41 }

Hm ... I also use macos and I never got that error. I will enhance the exception to also contain the invalid value and not only the details about the error, then we might be able to see a reason.
It might help to show your network interfaces. ideally do on a command line
node and then enter os.networkInterfaces()  ... please post the result

Thanks Apollon

Hm ... I also use macos and I never got that error. I will enhance the exception to also contain the invalid value and not only the details about the error, then we might be able to see a reason.
It might help to show your network interfaces. ideally do on a command line
node and then enter os.networkInterfaces() ... please post the result

eneralDiagnosticsCluster.setNetworkInterfacesAttribute for Matterbridge error: ValidationError: Validation error for attribute "networkInterfaces"in field [0].iPv6Addresses.[0]: (Validation/135) String is too short: 12, min 16.
2024-05-24 10:43:41     at StringSchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvString.js:39:13)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:62:34)
2024-05-24 10:43:41     at tryCatch (file:///app/node_modules/@project-chip/matter.js/dist/esm/common/TryCatchHandler.js:8:12)
2024-05-24 10:43:41     at file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:61:7
2024-05-24 10:43:41     at Array.forEach (<anonymous>)
2024-05-24 10:43:41     at ArraySchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:60:10)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvObject.js:137:24)
2024-05-24 10:43:41     at tryCatch (file:///app/node_modules/@project-chip/matter.js/dist/esm/common/TryCatchHandler.js:8:12)
2024-05-24 10:43:41     at ObjectSchema.validate (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvObject.js:136:9)
2024-05-24 10:43:41     at error.fieldName (file:///app/node_modules/@project-chip/matter.js/dist/esm/tlv/TlvArray.js:62:34) {
2024-05-24 10:43:41   code: 135,
2024-05-24 10:43:41   clusterCode: undefined,
2024-05-24 10:43:41   fieldName: '[0].iPv6Addresses.[0]'
2024-05-24 10:43:41 }

Just to be sure what version of Matterbridge are you using ?

sorry have been busy. Th latest version seems to resolve this and I am not seeing this error.
However I am not seeing the bridge in the Home App.

@Luligu would you know his to create a startup script for macOS? If a user closes terminal the matterbridge dies

maybe that could be an ideal topic to deliver by the community? ;-))
But yes, maybe looking at how homebridge or iobroker does it could help? (iobroker like https://github.com/ioBroker/ioBroker/blob/master/installer.sh#L429-L465)


Add the ability to add ::apt module from external source

Hi !
I need to import ::apt class from my own custom modules, because of special parameters. So your way to manage this was a problem for me.
Now, the module is able to use apt functionnalities without  import the module.
This can be inconsistency, but far more flexible.

What is this providing that isn't already covered with manage_repo ?

If we want the repo to be managed by the module BUT not the apt external module.
Without manage_repos, we have to install manually the sensu apt source repo. The other option i see is to remove  the line "if defined(apt::source) {" in ::sensu::repo::apt.

I'm not sure I'm following?

If we want the repo to be managed by the module BUT not the apt external module.

You've just added a boolean parameter which essentially does the same thing as $manage_apt - I don't think this is giving anyone any additional functionality.

No. The parameter i added ($manage_apt) impacts only the inclusion of external module ::apt.
Your parameter, $manage_repo, impacts both inclusion of external module ::apt AND the management of apt sensu repository.
There's the difference.
My need is to manage myself the way to include ::apt. Instead of doing
include ::apt
I must do
class { apt:
purge => {
'sources.list' => true,
'preferences' => true
}
}
But I still need $manage_repo at true, to automatically manage sensu upstream repository.
I don't know how to explain myself better than this.

I'm pretty sure you do not need to to this in order to achieve what you want, @gpenaud.
include sensu
# alternatively class{something::sensu: some_param => value}
class
{
  apt:
  purge =>
  {
    'sources.list' => true,
    'preferences' => true
  }
}
contain 'apt'


Fix the Webjobs command to use slots API when starting a Webjob (#9116)

Starting a Webjob while specifying a slot was not using the slots API, so the slot was being seen as a custom header
This checklist is used to make sure that common guidelines for a pull request are followed.

[x] 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.

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


OneUI 6.0 update causes issues with forced rotation

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: Windows 10
scrcpy version: 2.2-2.3.1
installation method: win64 zip
device model: Galaxy S21+ 5G
Android version: 14

Describe the bug
After updating to the newest OneUI (v6.0), scrcpy runs into issues when forced to rotate (e.g. opening an app that requires horizontal orientation from the main screen). The screen in scrcpy becomes cut off, see attached images, and unable to fix itself. Only a full restart helps, until the next time a rotation is forced.
The actual phone screen is unaffected, it is solely in scrcpy.

After looking into it further, I realized that the shortcut I was using had the --lock-video-orientation flag set. After removing it, it works as expected. Probably still worth to look into, but no longer as disrupting.

--lock-video-orientation is broken in Android 14: #4011

How can I remove that setting?
I remember I turn that on after update one UI 6 and now I can't find that setting menu anymore.
I just wanna turn that off. 😩

Just do not pass --lock-video-orientation to scrcpy.


Methods on WMI providers.

Is it possible to execute a WMI method from MDM? I'm trying to disable/enable an Adapter using the Win32_NetworkAdapter methods and get a 406.

disable

./cimV2/Win32_NetworkAdapter/Win32_NetworkAdapter.DeviceID%3D%221%22/Disable

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

ID: 04405438-4b80-b996-3421-a831353be2f7
Version Independent ID: 5c0bf4d4-fa8b-85d4-41dd-3267534f3217
Content: WMI providers supported in Windows 10
Content Source: windows/client-management/mdm/wmi-providers-supported-in-windows.md
Service: w10
GitHub Login: @nickbrower
Microsoft Alias: maricia

@officedocsbot assign @mypil

Hello @dfconroy Win32_NetworkAdapter class only supports data reading. Enabling / Disabling is the part of NetworkAdapter Configuration which is not supported as of now. Please see https://docs.microsoft.com/en-us/windows/client-management/mdm/wmi-providers-supported-in-windows#win32-wmi-classes
Thanks.

@dfconroy - From our understanding, the issue you raised has been answered by joinimran. If you feel it hasn't been answered, please re-open this issue.
Thank you for your contribution to make the docs better! Much appreciated!

@officedocsbot close


CPAL v1 field name was meant to be changed but was not changed

The change log for OT 1.8.4 indicates that the CPAL v1 header field name "offsetPaletteEntryLabelArray" was changed to "paletteEntryLabelsArrayOffset". However, it appears that change was not actually made in OT 1.8.4.
Perhaps fix as an erratum?

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

ID: 649f6376-f113-0a6f-d633-37ed967d8c29
Version Independent ID: 043109db-6c34-6c15-b4fb-6280b5131fcc
Content: CPAL - Color Palette Table (OpenType 1.8.4) - Typography
Content Source: typographydocs/opentype/spec/cpal.md
Product: typography
GitHub Login: @PeterCon
Microsoft Alias: alib

fixed as erratum


Example doesn't seem to be json-api

The implementations page links to an example at https://restpack-serializer-sample.herokuapp.com/
On a quick observation the responses don't provide the main data in an entry named "data" and resource objects don't include types. Maybe it conformed to an earlier version of the spec.
This should be removed to avoid confusion - It would be good to have another example.

It did conform to an earlier version of the spec. Yet it should be noted that the spec is still in active development, so implementations are almost always going to be behind until it reaches 1.0 final.

Thanks, I'm looking forward to the final version.


Listening on wrong addresses

What did you do?
Start prometheus with --web.listen-address=<IP_ADDRESS>:9090
> ps aux | grep prom
prometh+ 27719  339  1.0 5369168 700096 ?      Ssl  06:22   0:47 /usr/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.console.libraries=/etc/prometheus/console_libraries --web.console.templates=/etc/prometheus/consoles   --web.listen-address=<IP_ADDRESS>:9090

What did you expect to see?
Expected to see it listen on IPv4 localhost. I also semi-expected it to generally listen on localhost only by default.
What did you see instead? Under which circumstances?
It listens on IPv6 all-hosts (::), and prints IPv4 all-hosts.
> netstat -nlp | grep 9090
tcp6       0      0 :::9090                 :::*                    LISTEN      26163/prometheus
> journalctl -xe | grep prom | grep -i listening
Apr 02 05:55:47 myhost.net prometheus[26163]: level=info ts=2018-04-02T03:55:47.963398278Z caller=web.go:382 component=web msg="Start listening for connections" address=<IP_ADDRESS>:9090

With --web.listen-address=localhost:9090 and --web.listen-address=[::1]:9090 it also reports listening on <IP_ADDRESS>, and listens on the same IPv6 all-hosts (instead of localhost), but only responds with 503 (I think the 503 might be unrelated).
Environment

System information:
Linux 4.13.0-36-generic x86_64

Prometheus version:

prometheus, version 2.2.1 (branch: master, revision: bc6058c81272a8d938c05e75607371284236aadc)
  build user<EMAIL_ADDRESS>  build date:       20180326-06:31:27
  go version:       go1.10

Alertmanager version:
n/a

Prometheus configuration file:

---
global:
  scrape_interval:     15s
  scrape_timeout:      10s
  evaluation_interval: 60s

Alertmanager configuration file:

n/a

Logs:

Apr 02 05:55:47 myhost.net prometheus[26163]: level=info ts=2018-04-02T03:55:47.963398278Z caller=web.go:382 component=web msg="Start listening for connections" address=<IP_ADDRESS>:9090

This is a Linux internal thing, nothing to do with Prometheus.
It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

For the record, I moved --web.listen-address to the front and it now correctly binds to localhost only, i.e.
> /usr/bin/prometheus --web.listen-address=<IP_ADDRESS>:9090 --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.console.libraries=/etc/prometheus/console_libraries --web.console.templates=/etc/prometheus/consoles   --web.route-prefix=/prometheus

instead of
> /usr/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.console.libraries=/etc/prometheus/console_libraries --web.console.templates=/etc/prometheus/consoles   --web.listen-address=<IP_ADDRESS>:9090

That shouldn't make the slightest difference.

Yes, actually it turned out it was an orphaned doublequote somewhere in the systemd unit file, which apparantly made the arguments look correct, but actually get cut off.


flag: compiler not picking up on redefined flags

Go version
go version go1.22.3 darwin/arm64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOOS='darwin'
GOPROXY='direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'

What did you do?
package main

import (
	"flag"
	"fmt"
)

func main() {
	a := flag.String("a", "", "")
	b := flag.String("a", "", "")
	fmt.Println(a)
	fmt.Println(b)
	flag.Parse()
}

What did you see happen?
go build returns no error
What did you expect to see?
Warning about flag redefined

go build does not return an error in this case. Running the program will (a panic).
It is possible vet or some other analysis tool could detect this and report it. But it's probably pretty rare, and is easily detected at runtime, so it is not clear it would qualify for inclusion.

is easily detected at runtime

With all due respect, that's a lazy argument.
It makes the developer look sloppy if you ship out code with errors that could and, frankly, should have been prevented by vet or other linting.

It also makes the developer look sloppy if they don't test their binary at all before shipping it.
Assuming your flag.String calls are at the start of the main function, you literally can't run the binary at all, it will immediately fail.


Add Timer::enableHRTimer()

Adds a way to set sub-millisecond timers. This generates an opportunity for Nighthawk to improve accuracy of request-release timings. The fault filter extension might leverage this as well to inject sub millisecond delays.
Implemented as an extra call instead of an overload or change to the existing one, because that way caller intent explicitly carries information about accuracy expectations. Also, adding an extra call minimizes changes needed to accomplish this.
For best results, libevent needs to be made aware too that we'd like to use precise timers.
One way to do that is by setting an environment variable called EVENT_PRECISE_TIMER.
EVENT_PRECISE_TIMER=1 bazel-bin/nighthawk_client ...

One thing to mind is that the max sleep time will go down from std::chrono:millliseconds::duration::max() to std::chrono::microseconds::duration::max() with this. AFAICT we will still be able to sleep for ~292277 years with that.
Description:
Risk Level: Low
Testing: By proxy, via existing tests

For best results, libevent needs to be made aware too that we'd like to use precise timers.
One way to do that is by setting an environment variable called EVENT_PRECISE_TIMER.
EVENT_PRECISE_TIMER=1 bazel-bin/nighthawk_client ...

/cc @htuch

If the hi-res timers are used in the nighthawk for now, would it make sense to have this functionality just there?
Also would it make sense to make hi-res time enabled in the build files by default, instead of relying on users to remember to set on the command line during build?

@yanavlasov I think it's reasonable to add this to Envoy (I suggest this to @oschaaf). Why not make these the default though, rather than requiring specific enablement? Is there a performance or stability implication?

If the hi-res timers are used in the nighthawk for now, would it make sense to have this functionality just there?

So I thought this might be nice to have here as it seemed the change wouldn't add a significant maintenance burden; as the implementation can be shared across the regular and non-HR versions (at least today).. and potentially Envoy extensions might benefit from it?

Also would it make sense to make hi-res time enabled in the build files by default, instead of relying on users to remember to set on the command line during build?

Yes sure; alternatively this can also be set when initializing libevent instead of via setting an environment variable. But I was trying to minimize the change;

Why not make these the default though, rather than requiring specific enablement? Is there a performance or stability implication?

I was thinking that in Nighthawk this should be enabled by default but with an opt-out escape-latch for those who seek absolute highest throughput, as I remember there is a trade-off involved [1]. IMHO Envoy would probably better be off with an opt-in for those who run specific extensions with strict latency requirements..or maybe it would be nice to facilitate extensions that need it to enable the feature at server boot time automatically; e.g. a new interface call for extensions that Envoy can query as it starts to determine if any of those has strict latency requirements.
[1]   For example, Linux has CLOCK_MONOTONIC_COARSE (1msec
precision), which is over twice as fast as CLOCK_MONOTONIC.  Since
epoll only lets you wait with 1msec precision,
CLOCK_MONOTONIC_COARSE is a clear win.

@oschaaf this makes sense, but the implementation seems to be basically doing HR anyway for the regular timer case.

@htuch this makes sense, but the implementation seems to be basically doing HR anyway for the regular timer case.

correct, but imho consumers shouldn't care about how the two calls are implemented internally; from the outside my idea is that one of them is to express the desire for a reasonably precise but efficient timer, and the other one is to express the desire of favoring high precision.
(the doxygen comments might be a good place to clarify this in case we want to take this forward)
I was thinking that this distinction might some day be useful, perhaps knowledge about caller intent might be leveraged some day to optimize with coarse grained timer coalescing when favoring efficiency

@oschaaf yeah, that's reasonable. Can you add some tests for the new method?

@oschaaf yeah, that's reasonable. Can you add some tests for the new method?

I took a stab at that. 9f00ad8b68374b148926399b986b48ef7c0022dc explicitly shares some test code between enableTimer() and enableHRTimer().

Thanks.. one thing I'd be curious about is whether it's possible to use simulated time to actually capture the timing precision? Not sure how feasible that is, LGTM otherwise.

Nice, that works, and the new tests also functionally covers theoretical precision for the regular enableTimer() implementation: https://github.com/envoyproxy/envoy/pull/9155/commits/2dca2133532280c41c829e55368fa99e0985990a


test(tests-integration): await until node is alive

Stack:

#1895
#1894 ⬅
#1893
#1892
#1891

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

✓ Commit merged in pull request #1895


Manually provide scheme to ingress

Issue
Karma ingress URL remains FQDN even after relating to Traefik.
Solution
Addresses #29.
Testing Instructions
Relate ca - trfk - (karma - ca) - catalogue, and make sure the karma URL displayed in catalogue is the ingress URL and not the k8s fqdn.
In tandem with:

https://github.com/canonical/traefik-k8s-operator/pull/233

Release Notes
Manually provide scheme to ingress.

Verified the prefix handling manually with the following bundle:
bundle: kubernetes
applications:
  am:
    charm: alertmanager-k8s
    channel: edge
    revision: 86
    series: focal
    resources:
      alertmanager-image: 75
    scale: 1
    constraints: arch=amd64
    storage:
      data: kubernetes,1,1024M
    trust: true
  ca:
    charm: self-signed-certificates
    channel: edge
    revision: 23
    scale: 1
    constraints: arch=amd64
  cat:
    charm: catalogue-k8s
    channel: edge
    revision: 24
    series: focal
    resources:
      catalogue-image: 24
    scale: 1
    constraints: arch=amd64
  karma:
    # from https://github.com/canonical/karma-k8s-operator/pull/36
    charm: ./karma-k8s_ubuntu-20.04-amd64.charm
    series: focal
    scale: 1
    constraints: arch=amd64
    storage:
      config: kubernetes,1,1024M
  trfk:
    # from https://github.com/canonical/traefik-k8s-operator/pull/233
    charm: ../traefik-k8s-operator/traefik-k8s_ubuntu-20.04-amd64.charm
    series: focal
    scale: 1
    constraints: arch=amd64
    storage:
      configurations: kubernetes,1,1024M
    trust: true
relations:
- - trfk:ingress
  - cat:ingress
- - karma:dashboard
  - am:karma-dashboard
- - karma:ingress
  - trfk:ingress
- - karma:catalogue
  - cat:catalogue

Seems OK


Set default directory when compiling.

Fix #275.

r? @brotzeit
(rust_highfive has picked a reviewer for you, use r? to override)


feat(withDirty): combined the withDirty examples with the input examples

Proposed Changes
Combined the Dirty management HOC components examples with the input examples
Potential Breaking Changes
Only affect the demo
Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[ ] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

Codecov Report

Merging #1387 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1387   +/-   ##
=======================================
  Coverage   99.23%   99.23%
=======================================
  Files         476      476
  Lines        9955     9955
  Branches     2278     2278
=======================================
  Hits         9879     9879
  Misses         76       76

Impacted Files
Coverage Δ

...es/react-vapor/src/hoc/withEditing/withEditing.tsx
100% <100%> (ø)
:arrow_up:

...ckages/react-vapor/src/hoc/withDirty/withDirty.tsx
100% <100%> (ø)
:arrow_up:

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 d09d0e5...8171881. Read the comment docs.


Add a more type-safe way to assert object's property with returns API

We can verify object's multiple properties using extracting API to generate ObjectArrayAssert instance, but it does not provide type-driven code assist because the type of test subject is changed to Object[].
Though custom assertion generator is provided in AssertJ project, I think more easy and flexible way to assert method's return value (including getter method) of a test subject helps writing test code.
Check List:

Fixes N/A
Unit tests : YES
Javadoc with a code example (API only) : YES

Interesting ... my first thoughts is the proposed API readability is a bit clumsy because you have the method/lambda before the result, thining out loud I would written something like
assertThat(yoda).returns("Yoda", from(Jedi::getName))
                .returns(150, from(Jedi::getWeight));

from is just syntactic sugar to wrap the lambda but it does not do anything, this means you can also write the assertions without from.

Awesome! The better argument order is the point i've looking for but good idea didn't come up with. The idea wrapping with from syntax sugar looks nice to me because it's not the mandatory API so that it's easy to understand the way to use. I'll improve the API. Thanks! 😉

As a side note from method should be added in Assertions to make it easier to discover it.

Thanks! I've amended the original commit.

Thanks @Mura-Mi ! PR Integrated.


Implements US 02.02.01 (organizer view entrants on waiting list) and refactors Event activity

Implements US 02.02.01 Organizer - view the list of entrants who joined my event waiting list.
EventActivity was being to dynamically display multiple pages (multiple different views for entrant depending on waitlisted, attending, etc and one for admin). Organizer needed EventActivity as well to display organizer-specific information (for this user story, needed to display the entrants on the waiting list). One activity shouldn't have logic for all these different views so I refactored everything into ViewEventActivity, which shows the event details (name, facility, date/time), and child fragments which show the entrant-specific info, organizer-specific info, and admin-specific info. Since the entrant has multiple displays, I made each display its own fragment.
I created the fragments and refactored everything that used EventActivity to use this new design. I also updated the existing tests to reflect the change. I left the existing EventActivity for now but it is no longer used.

Also implements US 02.02.02: Organizer -- See on a map where entrants joined my event waiting list from and writes intent test for this user story.


Updated loader$() documentation

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests

Description
An example in docs does not work without a ".use()" when using the loader.
I also changed a few loader names to stay consistent.
Why

I got confused while working on a personal project because I was missing .use() and trying just to call the loader.

Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[x] I have made corresponding changes to the documentation
[x] Added new tests to cover the fix / functionality

THe docs are correct as the are, you should update to latest release!


Ferret doesn't regrid climatological axes before 1900 correctly

Reported by sirott on 6 Jul 2000 17:59 UTC
Inconsistent results occur when differencing a variable with a climatological
time axis with itself when a time point before 1900 is used.
Example:
use coads_climatology
!
! This doesn't work
!
let var1_ = SST[var2_ = SST[T=31-JAN,D=1](T=31-JAN-1899,D=1]
let)
sha/l=1 var2_ - var1_
message
!
! This does work
!
let var1_ = SST[T=31-JAN-1900,D=1]
sha/l=1 var2_ - var1_
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/91

Comment by<EMAIL_ADDRESS>on 17 Aug 2000 17:19 UTC
! err521_1899_clim.jnl 7/00 sh
! modulo calculation prior to 1900 is done incorrectly
! solved 17-Aug sh
! RED HERRING -- this is not a bug at all
! It arises from the difference between the length of a climatological year
! and the length of any give (leap-sensitive) year
! Since Ferret is in non-INTERPOLATE mode the date 31-Jan-year may actually
! lie in Jan or in Dec of the climatological year -- leading to 2 possible
! solutions for the difference variables below
! ==> CONSISTENTLY:  THE PROBLEM DOES NOT OCCUR FOR 15 JAN AS FOR 31 JAN
use coads_climatology
!show data
!show grid sst
let var1900 = SST[var1899 = SST[T=31-JAN-1899,D=1](T=31-JAN-1900,D=1]
let)
let var0000 = SST[T=31-JAN-0000,D=1]
set mode diag   ! note that modulos on T are 11 instead of 12 months diff
stat var1900 - var0000   ! identical zero (modulo from T=22801)
stat var1899 - var0000   ! is not identical zero (modulo from T=22790)

Comment by<EMAIL_ADDRESS>on 21 Oct 2003 20:15 UTC
Moving from the<EMAIL_ADDRESS>user to the<EMAIL_ADDRESS>user.


Research: Testing

Goal
Research how we can test the controller and which type of tests we should use.
Acceptance Criteria

[ ] Define how we can test CRD in isolation: maybe using K3s/K3d/Kind
[ ] Define what type of tests we should execute:

[x] Unit tests
[ ] Contract tests
[x] E2E & run them on multiple K8s versions
[ ] Load tests

[ ] Define a testing strategy and how to automate it

DoD

[ ] A PoC with tests is created
[ ] Best practices on how to structure the code are documented in a Developer.md

References

[ ] KUTTL
[ ] Dynatrace Operator
[ ] NewRelic Operator
[ ] DataDog Operator

Also:
https://github.com/marketplace/actions/kind-cluster
https://github.com/marketplace/actions/kind-kubernetes-in-docker-action

Pactflow
A useful tool for contract testing

Like stated in the documentation
Contract testing might not be the right choice for this project, since the controllers are mainly communicating with the Kubernetes API server.
Contract testing has a consumer based testing strategy and is mainly designed to test the integration of two microservices.
In the context of this project, the API server can be considered the provider, and the controllers can be considered to be the consumers.
Since it would be required to test the integration with the generated contract on the provider side as well, this approach might just not be the right one for this project.

Created https://github.com/keptn/lifecycle-toolkit/issues/319 based on this ticket results


Not compatible with libsql v0.6

When using libsql v0.6, I get the error below when trying to run migration scripts based on a database initialize with libsql.
thread 'test_utils::tests::db_source_migration_should_create_empty_companies_table' panicked at /Users/sejunpark/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libsql-0.5.0/src/local/database.rs:209:17:
assertion `left == right` failed: libsql was configured with an incorrect threading configuration and
                    the api is not safe to use. Please check that no multi-thread options have
                    been set. If nothing was configured then please open an issue at:
                    https://github.com/libsql/libsql
  left: 21
 right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Here's a reproduced repo.
You can just run just bin.
I'm not sure what's not compatible, but I think the error will go away if geni uses libsql v0.6.
Haven't got the time to check it out myself.

When using libsql v0.6, I get the error below when trying to run migration scripts based on a database initialize with libsql.
thread 'test_utils::tests::db_source_migration_should_create_empty_companies_table' panicked at /Users/sejunpark/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libsql-0.5.0/src/local/database.rs:209:17:
assertion `left == right` failed: libsql was configured with an incorrect threading configuration and
                    the api is not safe to use. Please check that no multi-thread options have
                    been set. If nothing was configured then please open an issue at:
                    https://github.com/libsql/libsql
  left: 21
 right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Here's a reproduced repo.
You can just run just bin.
I'm not sure what's not compatible, but I think the error will go away if geni uses libsql v0.6.
Haven't got the time to check it out myself.

Hey! Thank you for reporting. I haven't got the time to merge the libsql upgrade branch but will look into it

@emilpriver That was fast, works fine thanks 👍


BUGFIX: SolrVersionedTest_Index causing crash in unit tests when Phockito is not installed

When Phockito is not installed the SolrVersionedTest_Index causes an invalid argument exception to be thrown. Stating "Can't add classes which don't have data tables (no $db or $has_one set on the class)". This appears to be caused by the return in SolrIndexVersionedTest.php inside of a check for the Phockito class. Moving the SolrIndexVersionedTest_Object class above that check stops the exception. This pull request does that.

Thanks!