Nanostores in SSR

Hi there!
I saw news on new release, saw allTasks API and decided to research, how nanostores is compatible with SSR
Loading of Node.js template in codesandbox takes forever for some reason, so i decided to create similiar reproduce with basic one:
https://codesandbox.io/s/loving-wilson-4vp4r?file=/src/index.js
(see index.js and console)
Idea is the same:

Request happens
Request-handler task is added to event-loop and starts some logic and web or db requests
Once those web or db requests are over, state is recalculated with new data
State injected in the app, which then rendered to string
Resulting string sent as response

During all of these operations is important to isolate state that "belongs" to different requests from each other - otherwise data from one request will leak to the other
Nanostores have two issues there:

States of nanostores are shared between requests, which then leads to data prepared for one request to show in another - in result rendered html-string is not correct.

State of internal allTasks counter is also shared between all requests, which leads to weird bug: responses are not sent until all requests are handled, even if their data is ready.

Possible solutions:

Many state-managers require creation of new instance of store/stores for every request, like this

const ssr = async (request) => {
 const stores = initStores()

 await stores.startLogic(request)

 return renderAppToString(stores)
}

This will effectively isolate requests from each other, because all of them will have their own instance of stores and all pending operations also will be bounded to this instance
Mobx example: https://github.com/vercel/next.js/tree/master/examples/with-mobx-state-tree

Some other state-managers, like effector, allow to create separate instance of app state in special way, allowing to reuse already initialized stores and connections, like this:

const ssr = async (request) => {
 // all stores and connections already defined somewhere
 const scope = fork()

 await allSettled(startLogic, { scope, params: request })

 return renderAppToString(scope)
}

Example: https://github.com/GTOsss/ssr-effector-next-example/blob/effector-react-form-ssr/src/pages/ssr.tsx

I think, nanostores could utilize similiar stack-based approach like the one in effector 🤔
(+ React.Context and Hooks are also working like this, but in a bit diffirent situation though)
General idea is something like this
https://share.effector.dev/sr3BtOLj
// internal field
let scope = null

const makeStore = (name, initState) => ({
 // all stores will need an unique name or identifier, which should be the stable between server and client
 name,
 state: initState,
 getState() {
  // if scope is set during operation, use state from scope
  if (scope) {
   return scope[name] ?? initState
  }
  return this.state;
 },
 set(v) {
  if (scope) {
   scope[name] = v;
   return;
  }
  this.state = v;
 }
})

// scope fabric
const getScope = () => ({});

// general pattern for working with scope
// pass target scope explicitly
const runInScope = (s, cb) => {
 // set it to internal field
 scope = s;
 // run logic
 cb()
 // thanks to callstack all store api calls will see
 // which scope is set now
 // but requires additional work to handle async stuff

 // clear internal field
 scope = null;
}

This would allow to automatically collect all the states during SSR and then transfer it to the client:
// ssr
const myServerScope = getScope()
// ... run some logic on scope
const stringifiedStateOfTheApp = JSON.stringify(myServerScope)

// client
const myClientScope = JSON.parse(stringifiedStateOfTheApp)

And also separate state of different requests/tests:
const myTestOrSsrRequestHandler = () => {
  // each test/request gets its own isolated box for app state
 const myScope = getScope()
 ...
}

This is roughly (very roughly) how effector scopes work, but advantages are the same: effector is able to both isolate and automatically collect all atomic stores states without any manual boilerplate

Yeap, Effector’s scope isolation is very good for SSR, when you render HTML for multiple users in the same context.
Maybe we can create some sort of the wrap around current minimalistic stores to support scope?

I don't think that wrapper would work - if user missed some store, then it will be missed from serialization and further hydration at the client, which is no good
Probably it should be a core feature, so all APIs of the library are aware of the scopes and can properly handle it 🤔
I don't think that it is actually matter, if server context is isolated or not - the problem of collecting all parts of decentralized state of the app is still persists, since it is needed to hydrate app state at the client somehow anyway 🤔

Hm, could we pass getServerSnapshot to the React hook to prevent render time side effects on Server?

Any updates on using SSR? The documentation is very short and I don't get enough clarity.
My use case is to be able to hydrate the store from a Server Component in React 18 / Next.js. The underlying reason is that by hydrating I hope to avoid an extra re-render.
Thanks!

I don’t use Next.js and we need some advanced user to do the research and optimization

I've used the following with Next.JS and it seems to work properly.
const $atom = atom<string>('initial');

const hydratedSet = new WeakSet();
function useHydrateAtom<T>(atom: WritableAtom<T>, value: T) {
  if (!hydratedSet.has(atom)) {
    hydratedSet.add(atom);
    atom.set(value);
  }
}

export default function Page({ value }: Props) {
  const atomValue = useStore($atom);
  useHydrateAtom($atom, value);

  return
Atom Value: {atomValue}
;
}

export const getServerSideProps: GetServerSideProps<Props> = async () => {
  return {
    props: {
      value: 'value',
    },
  };
};

I've been using the following to hydrate atoms on Next.js with Pages Router, but it should work fine on App Router too:
const hydratedSet = new WeakSet();

function useHydrateAtom<T>(atom: WritableAtom<T>, value: T) {
  if (!hydratedSet.has(atom)) {
    hydratedSet.add(atom);
    atom.set(value);
  }
}

const $atom = atom<string>('');

// value is coming from the server-side
export default function Page({ value }) {
  useHydateAtom($atom, value);

  return (
    // ...
  )
}

@bernatfortet I think the above may help you


disper: repair missing libXrandr and libX11 dependencies

Motivation for this change
Things done

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

[X] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

This change is

With or without this PR, disper -l fails with the following error for me:
No suitable backend found

Seems to be an issue with multiple outputs, disper -l works for me with the following change to the PR:
diff --git a/pkgs/tools/misc/disper/default.nix b/pkgs/tools/misc/disper/default.nix
index ea503b9..5042c33 100644
--- a/pkgs/tools/misc/disper/default.nix
+++ b/pkgs/tools/misc/disper/default.nix
@@ -11,7 +11,7 @@ stdenv.mkDerivation rec {

   postInstall = ''
       wrapProgram $out/bin/disper \
-      --prefix "LD_LIBRARY_PATH" : "${xorg.libXrandr}/lib:${xorg.libX11.out}/lib"
+      --prefix "LD_LIBRARY_PATH" : "${xorg.libXrandr.out}/lib:${xorg.libX11.out}/lib"

   '';

Nice catch, @rycee. I must have missed than when I ported it from 16.03 to unstable. Thanks!
Updated the PR to include the fix. @fpletz, can you try again?

Review status: 0 of 1 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

I've merged this into master in commit 32744b72e5a048fea7250c444e73d2c0b605d50b. Thanks for the contribution!

Thank you!


Move sourcekit-lsp off of SwiftPM's POSIX

SwiftPM's POSIX is going removed soon in order to make it more cross-platform. This removes all usage of POSIX from sourcekit-lsp.
rdar://problem/49198341 Move sourcekit-lsp off of SwiftPM's POSIX

@swift-ci smoke test

@benlangmuir I can't trigger CI for some reason

@swift-ci please test

@aciidb0mb3r we don't have a smoke variant yet

Hmm @shahmishal my test request is building (macOS job and linux job), but the status isn't showing up here on the PR.  Any ideas?


Animal game

The Game is ready to deploy

mention the issue no

What is the issue?

where this issue assign to you


[GCP FileShare Support] Add GCP Driver Adapter Framework

Issue/Feature Description: This issue is to add GCP Driver Adapter Framework for the FileShare Driver Factory
Why this issue to fixed / feature is needed(give scenarios or use cases): To support GCP FileShare
How to reproduce, in case of a bug:
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)

https://github.com/sodafoundation/multi-cloud/pull/1089
PR merged


feat(generators): add Quay generator support

Problem Statement
Add a new generator to support Quay Robot Account federation
Related Issue
Fixes #4251
Proposed Changes
Added new generator. I am relatively new to Go, I would appreciate input/feedback on how best to write tests + e2e tests. To use robot account federation with Quay, you must have a cluster with a publicly available OIDC service account issuer.
Checklist

[x] I have read the contribution guidelines
[x] All commits are signed with git commit --signoff
[ ] My changes have reasonable test coverage
[x] All tests pass with make test
[x] I ensured my PR is ready for review with make reviewable

The doc needs to be located under docs/api/generator and then linked in hack/api-docs/mkdocs.yml.


Fixed-Gas

Motivation
Prior to executing a transaction, we should be able to tell what its price will be in terms of gas units.
In the future, we could extend the gas pricing to support metering. Since we only deal with fixed-gas Wasm programs for now - we compute the gas costs offline before actually executing the transaction.
Even though the internals of SVM infers a Gas minimum and maximum range to be paid, in practice the maximum gas units will be charged off the sender.
Using pricing should be integrated into the Runtime as part of the validation of a transaction. This will be done in a future PR.
In case a transaction has not enough gas (i.e the gas limit is too small) the transaction should be discarded.
(it won't be part of a block and won't get a chance to execute at all).

Reopened here:
https://github.com/spacemeshos/svm/pull/237


jqLite dumps  while running jqLiteBuildFragment

$compile service will call jqLite to convert html to JQuery element. It's found that in jqLiteBuildFragment function, if a customized directive tag like <tr-xxx> will be wrapped to <table>... due to this regexp var TAG_NAME_REGEXP = /<([\w:]+)/; does not capture 'dash-delimited' tag name. And the fragment tr is in wrapMap which will be wrapped to a comprehensive table html later.
As a result, the directive cannot be compiled successfully.
I wonder any reason behind this or it's a bug to be fixed, should I PR for this?

https://github.com/angular/angular.js/blob/master/src/jqLite.js#L145

It looks liek a pretty valid bug to me (easily fixed by changing the RegExp to /<([\w:-]+)/).
Is the - deliberately ignored or was it indeed just an oversight ?

@gkalpak it was an oversight. If someone creates a PR, it should get merge fast

#10618 fixes it for jqLite, but jQuery still fails.
How should we address this ?

Upon further investigation, it seems like the RegExp and the implementation were based on jQuery (see here and there).
Not sure if making the same RegExp change makes sense for jQuery (or breaks other things there).
Should we look for alternative ways of solving this ? E.g. normalizing node names before passing to jqLiteBuildFragment/jqLiteParseHtml ?

Mmm... it looks like this needs further investigation. @gkalpak do you want to take care of this? BTW, the issue with jQuery implies that #10618 as is, is not a good solution

#10618 will fix the issue when jqLite is used, but will not make any difference when jQuery is used instead (it keeps the current "buggy" behaviour). So, it won't hurt landing #10618 (althought there will be one test failing on jQuery), but it won't thoroughly solve the problem either.
Right now, jQuery does not properly handle constructing nodes from HTML text that has a root element with dash-delimited node name whose first subpart is a wrappable element.
The previous weird sentence in code:
$('<xyz></xyz>')          -> [<xyz></xyz>]          // OK
$('<xy-z></xy-z>')        -> [<xy-z></xy-z>]        // OK (`xy` is not a wrappable element.)
$('<tr-z></tr-z>')        -> []                     // Not OK (`tr` is a wrappable element.)
$('<x><tr-z></tr-z></x>') -> [<x><tr-z></tr-z></x>] // OK (`tr-z` is not the root element.)
$('<tr:z></tr:z>')        -> [<tr:z></tr:z>]        // OK (The node name is `:`-delimited.)

The way I see it, this is a bug with jQuery and should be fixed. I am not a jQuery guru, but from what I can tell the fix is the same as with jqLite (just adding - in the RegExp) and it shouldn't have any side-effects, since the RegExp is not used for any other purpose than to find if an element's node name is in the wrappable elements list).
--
So, if jQuery fixed this bug, then #10618 would be sufficient for solving the issue for Angular (with or without jQuery).
Not sure what is the indicated course of action. A few I can think of:

Sugmit a bug on the jQuery repo and merge #10618 once jQuery has fixed it. (Possibly submit a PR for jQuery to help speed things up.)

Keep the current behaviour (in order to retain jqLite-to-jQuery compatibility) and document the issue (i.e. that compiling (or even angular.element-ing) HTML strings that have a dash-delimited root element whose first subpart is a wrappable element does not work as expected). (Several work-arounds are available.)

Fix jqLite and document the buggy behaviour of jQuery. (Optionally combined with option (1).)

Find a way to handle this inside of Angular (e.g. normalizing dash-delimited node names before passing to angular.element/compile ?
Since all this boils down to jqLite('...'), I am not ure how easy it would be to handle this in the presence of jQuery.

I would start with opening an issue with jQuery (to include a PR would be ideal) and see how things move from that side... and until there is a definition from jQeury, I would leave #10618 on hold

Will do over the weekend.

@LeonardoBraga beat me to it :smile:

We have a fix ready to be merged at #12759


Install from cargo backend using --git

For one reason or another, some Rust projects are not published on crates.io. For example, zenith does not have a crate. Instead, they ask their users to install via --git flag. I could not see any way to specify this using Mise.
It would be nice to be able to specify this as an option in the config file. Or better yet, support a similar syntax to the Go backend where it would just install using --git if it detects a path instead of a package name.

we would do this via ref: syntax—though admittedly the work around that is only partially complete. The gaps are around updating. That said, it's really strange to me that a rust cli wouldn't be distributed via crates. I don't think I've ever seen that before.

I’ve seen it a few times (and there's times that you need to clone a repository with a Go cli tool, which is even weirder), especially when there's a crate that has the desired name of the tool (https://crates.io/search?q=zenith for this one shows both an exact match and at least one other match that would be desirable, although zenith-top and zenith-cli are both available). I also think that in some cases, the preference is either to (a) go through GitHub releases or (b) keep it installable via --git because they're not yet ready for casual users to adopt the tool.

it's really strange to me that a rust cli wouldn't be distributed via crates

The reasons for this were discussed in this issue. My understanding is that a forked dependency meant that it couldn't be easily published. I'm not hugely experienced with Rust, so forgive my ignorance on the topic.
It actually seems like the PR in question has since been merged, so I'm not sure if this is still a blocker. However the package is still only installable with the --git flag if using Cargo. Not sure if this is a common problem and I agree the best fix would be for the author to publish a package, but in lieu of this, it would be a useful feature for mise to support provided the implementation isn't too difficult.

there's a crate that has the desired name of the tool

This is actually how I ran into the issue in the first place. I attempted to add "cargo:zenith" to my config without checking crates.io (stupidly) and got some very unexpected output.


Update installation.rst

A little correction :)

Codecov Report

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

@@           Coverage Diff           @@
##           master      #20   +/-   ##
=======================================
  Coverage   73.87%   73.87%
=======================================
  Files          10       10
  Lines         513      513
=======================================
  Hits          379      379
  Misses        134      134

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 54783ae...8b25690. Read the comment docs.

Thanks guys
For the record, test is failing due to https://github.com/pypa/pipenv/issues/2438


Add mocking api for easy UI development

What this PR does / why we need it:
Add API mock for UI development.
Update web's README.md and add some commands for the web to Makefile.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

/lgtm

🏃
/approve


Valid Prisma 2+ schema is seen as invalid and halts the complete migration

When migrating our Prisma 1 to latest, our introspected schema is not seen as valid.

We created a new Prisma environment with the yarn prisma init command, just as specified in the documentation.

After a yarn prisma db pull, we saw the created schema in prisma/schema.prisma.

A yarn prisma validate reported that the freshly created schema.prisma was valid.

The yarn prisma-upgrade prisma1/prisma.yml prisma/schema.prisma reported:

Error Error parsing the Prisma 2 file.

Are you sure "/home/jw/projects/graphql/prisma/schema.prisma" is a valid Prisma 2 schema file?

You might want to use an older Prisma version, not the latest Prisma 4.x. Since this tool was created, Prisma Schema got a few additions that it can not handle (and will not be updated to).
Start with 3.x and see if that validates, if not go back a bit further until you hit one that works. Then you can do the upgrade with that version, and then do another upgrade later to the newest Prisma 4+.

(Parallel discussion in Slack: https://prisma.slack.com/archives/C0152UA4DH9/p1671533194688039)

Indeed, with the invaluable help of Muhammad Usman we found out that Prisma 4 creates a valid schema when doing a db pull.  But that schema is not valid for the prisma-upgarde.  When running the dp pull on the Prisma 3, the resulting schema can be read by the prisma-upgrade.

Might be a nice thing add this to both the prisma-upgrade and the prisma website documentation sections.

What version exactly did you use?


genLinkDeviceCodeForPhoneNumber_Result_Error : Invariant Violation: Minified invariant #56367; %s

If I run a minimal function on Android, using linkWithPhoneNumber, I get an exception:
genLinkDeviceCodeForPhoneNumber_Result_Error : Invariant Violation: Minified invariant #56367; %s
However, if I run the same minimal function in debug-view-mode, and have breakpoints at
whatsapp_bot_flutter_mobile_src.dart:38
and
login_helper.dart:60
the function runs correctly, giving me a link-code
main.dart
import 'dart:typed_data';
import 'package:flutter/cupertino.dart';
import 'package:whatsapp_bot_flutter/whatsapp_bot_flutter.dart';
import 'package:whatsapp_bot_flutter_mobile/whatsapp_bot_flutter_mobile.dart';
void main(List args) async {
WidgetsFlutterBinding.ensureInitialized();
WhatsappBotUtils.enableLogs(true);
try {
WhatsappClient? client = await WhatsappBotFlutterMobile.connect(
linkWithPhoneNumber: '31612345678', // this phone number altered for privacy reasons
onConnectionEvent: (ConnectionEvent event) {
debugPrint('event $event');
},
onQrCode: (String qr, Uint8List? imageBytes) {
String qrText = WhatsappBotUtils.convertStringToQrCode(qr);
debugPrint('qrText $qrText');
},
onPhoneLinkCode: (String code) {
debugPrint('code $code');
},
);
flutter.doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.24.4, on Ubuntu 24.04.1 LTS 6.8.0-48-generic, locale nl_NL.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio (version 2024.1)
[✓] Connected device (3 available)
[✓] Network resources
• No issues found!
// subscribe to connection events
client?.connectionEventStream.listen((event) {
  debugPrint("ConnectionEvent : $event");
});

} catch (e) {
debugPrint(e.toString());
}
}
whatsappbot.error.log

it also runs correctly if i alter login_helper.dart inserting at line 60
await Future.delayed(const Duration(seconds: 15));
the same line with a 10 seconds delay does not work

having same error while login. if i pass phone number like this<EMAIL_ADDRESS>i see a phonelinkcode.
else if pass like<EMAIL_ADDRESS>it throws invalid invarient error.


Warnings with Ruby 2.4.0

Once updated to Ruby 2.4.0, I get following warnings when running my test suite:
/usr/local/bundle/gems/dragonfly-1.1.1/lib/dragonfly/temp_object.rb:55:in `initialize': Dragonfly::Content#tempfile at /usr/local/lib/ruby/2.4.0/forwa
rdable.rb:156 forwarding to private method Dragonfly::TempObject#tempfile

Thanks

Sorry, duplicated of #468


Format Request/Response Bodies for Referenced .feature Files

When referencing a .feature file, the log output while the test is running displays the request and response bodies as one line only.  Please format request and response bodies for referenced .feature files using pretty JSON.

You can configure logPrettyResponse in the called files.

on further discussion - realized that the setting in the global karate.config is not propagating or cascading down into 'called' features. looks like we need to have this config percolate down.

actually I just checked the flow and this is working as expected. setting karate.configure('logPrettyResponse' true); in karate-config.js indeed propagates down to all called features.

It works but it doesn't pretty print JSON within error/exception blocks on the report.

It works but it doesn't pretty print JSON within error/exception blocks on the report

can't comment without seeing an example - but yes if a snippet of JSON is part of a Java exception we don't do anything to pretty-print it. you are always able to pretty print any valid json at any time by using the print statement: https://github.com/intuit/karate#print


[Feature Request]

What is the idea?
Feature request
add to softaculous
Why would this be beneficial
Benefits

Duplicate of #1041.


Add new fields to redaction

Add new fields to redaction - Based mostly on API proposal from NUI-728
Description
Adds new field names to be redacted from logs.
Supports NUI-728
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Unit test to be added today.


Fixes #5006

Reference Issue
Fixes #5006
What does this implement/fix? Explain your changes.
With this PR a query atom containing an atomAnd query is depicted as a ? rather than causing an exception to be raised.

Thanks @ptosco!


kitchendisplay extra buttons (more then 3)

What is the feature?
Hi Guys,
is there a way to add extra buttons to the kitchen display ?
my customer would like six.
thanks !
Version
3.0.4 (Stable)

Best to ask this on the kitchen display repo, but the short answer is no, you would need to modify the extension yourself.

oki thanks :)


[ENG-3449][Hotfix] Account for AVOLs in update dropdown

Ticket: ENG-3449
Feature flag: n/a

Purpose

Show all the publicly available updates when viewing a registration through an AVOL

Summary of Changes

Updated condition to show a revision in the UpdateDropdown

Screenshot(s)
Side Effects

none, this will only impact AVOLs

QA Notes

All public updates will be visible in the Updates dropdown in the overview for AVOLs, not just the original one

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 73.165%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
5175

Relevant Lines:
6810

💛  - Coveralls

How hot is this hotfix?

How hot is this hotfix?

I would say it's one Kelvin less hot than it's associated BE hotfix https://github.com/CenterForOpenScience/osf.io/pull/9843
This will address an issue that will be apparent once that hotfix is merged

Cherry-picked to hotfix/21.10.2


Feature request: Render whitespace

Just like in VSCode, it would be nice to have a way to display whitespaces.

Fixed in https://github.com/lapce/lapce/pull/1284


gg and G no longer working in jupyterlab 4.1.0

Description

After updating from jupyterlab 4.0.11 to jupyterlab 4.1.0, the commands gg and G to navigate to the top/bottom cell of the notebook in jupyter mode no longer seem to work. Going back to jupyterlab 4.0.11 both gg and G work as expected.
Can anybody else confirm this?
Context

Python version: 3.12.1
jupyterlab-vim version: 4.1.0
Operating System and its version: Linux Manjaro
Browser and its version: Firefox 122.0-1

I was not able to replicate on:
python : 3.12.1
jupyterlab-vim: 4.1.0
jupyterlab : 4.1.0
firefox: 112 (on linux)
Was this in a totally fresh environment?

I was not able to replicate on:
python : 3.12.1
jupyterlab-vim: 4.1.0
jupyterlab : 4.1.0
firefox: 112 (on linux)

Huh, weird.

Was this in a totally fresh environment?

Yes, new virtualenv...

I tried again with a fresh virtualenv of python version 3.11.5. Same thing, gg and G work in jupyterlab==4.0.11, but do not work in jupyterlab==4.1.0...

ahhh sorry i misread the original issue, i thought you were talking about inside of a cell. I agree I see the same

ahhh I suspect we need to update the CSS selectors: https://jupyterlab.readthedocs.io/en/latest/extension/extension_migration.html#change-of-notebook-focus-handling-impacting-command-mode-shortcut-selectors

Yes, but JupyterLab 4.1 was supposed to handle the transition by transparent substitution in the background. I must have missed some selectors, sorry :facepalm:

So https://github.com/jupyterlab/jupyterlab/pull/15639 should have caught .jp-Notebook:focus usage as in:
https://github.com/jupyterlab-contrib/jupyterlab-vim/blob/fc42ef650142f95aa8f8f5e3b4f82b2fef03a996/schema/plugin.json#L173-L177

Ok, the selector substitution rules are good but only first shortcut gets fixed (for me Y Y):

instead there is a bug in the logic in:
if (
  oldSelector.includes(change.old) &&
  !selectorsAlreadyWarnedAbout.has(oldSelector)
) {
  newSelector = oldSelector.replace(change.old, change.new);
  selectorDeprecationWarnings.add(
    `"${change.old}" was replaced with "${change.new}" in ${change.versionDeprecated} (present in "${oldSelector}")`
  );
  selectorsAlreadyWarnedAbout.add(oldSelector);
}

selectorsAlreadyWarnedAbout should not be checked in the outer if as it skips subsequent shortcuts. I will open a PR against JupyterLab,

This is getting fixed in:

https://github.com/jupyterlab/jupyterlab/pull/15762 and
https://github.com/jupyterlab-contrib/jupyterlab-vim/pull/135

reviews for both pull requests would be greatly appreciated!

I can confirm that with #135 gg and G now jump to the top and bottom cell of the notebook, respectively.
However, it seems the view does not jump. For example, if I am at the bottom of the notebook viewing the bottom cell which is currently highlighted, and I then press gg, then the highlight vanishes (and presumably jumps to the top cell), but I am still looking at the bottom cell. Only after pressing j or k or zz (at least twice actually...) does the view follow and jump to the selected cell...

Thank you @ianhi for the quick release and @lukashergt for testing. The scroller node has also changed in lab 4.1 (https://jupyterlab.readthedocs.io/en/latest/extension/extension_migration.html#css-class-name-change-in-the-windowedlist-superclass-of-staticnotebook), and instead of using the public API of notebook, this extension was doing scrolling manually:
https://github.com/jupyterlab-contrib/jupyterlab-vim/blob/a6520efded5415c0bdcb4beffab5b77dd3550d51/src/labCommands.ts#L248-L253
I can take a look tomorrow.

ahhh sorry I didn't catch this. I did make a enough cells in my test notebook to trigger scrolling. I will add that to my mental checklist of things to check.

Wow, completely resolved as far as I can tell, thanks for these quick fixes @krassowski, @ianhi!


Add a CosmosChain pre start hook

Add a function to the CosmosChain struct which does a callback before the node is started. This would allow the cosmos chain creator to implement a function which modifies any configuration parameter they would like. With this addition, the ModifyGenesis function could be deprecated and we could expect the genesis modifications to occur within the pre startup hook.
The use case which motivates this proposal is having the ability to modify the app.toml file (setting the halt height) before chain startup. I will be working on my fork for this to test an e2e we are adding on ibc-go, I can open a pr with the suggested changes
I plan to add a cosmos.ChainConfig type which has:
// existing type
type CosmosChain struct {
    ...
    chainConfig ChainConfig
    ...
}

type ChainConfig struct {
    numValidators int
    numFullNodes  int
    PreStartupHook func(node *ChainNode)
}

After SetPeers before StartContainer here add:
if c.ChainConfig.PreStartupHook != nil {
    c.ChainConfig.PreStartupHook(n)
}

No strong preference on function naming. The numValidator/numFullNodes/ChainConfig changes can be left out if desired

Hi @colin-axner , this is already possible with ConfigFileOverrides in the chain config. https://github.com/strangelove-ventures/interchaintest/blob/4e43739472a180c802943a1594ff26e74688088d/ibc/types.go#L40
ModifyGenesis is also useful as it will only run once on the genesis file before distributing it out to all nodes, rather than running for all nodes.
Let me know if this does not work for your use case.

Nice that should work, thanks!


go-to declaration

not sure if this kind of issue is useful, but in case it helps, here is it: https://github.com/epost/psc-ide-emacs/pull/66

Yes. You need to pass source globs to psc-ide-serverthough, and I'm not sure where to get these yet for the editors.

Implemented 3da674ed92ae707150bfe0fa1082c430361002b3 (globs are specified in config but the usual defaults)


Replace ts::string_view with std::string_view

[approve ci icc]

[approve ci autest]

[approve ci autest]

Added @d2r patch as a commit and changed the author to him.


[DNM] improvement: silence pydantic v2 warnings

@armandobelardo another potential fix here https://github.com/cohere-ai/cohere-python/issues/559

@armandobelardo another potential fix here cohere-ai/cohere-python#559

Will try it out, you can see that the top level conditional (e.g. this PR) leads to mypy errors, so will try this out


[SUGGESTION] Zooming-Slow-Mo implementation

Very cool fork...
According to this video they achieved better (quality) performances of DAIN+EDVR, so it would be great to be implemented in standard-motion too:
https://github.com/Mukosame/Zooming-Slow-Mo-CVPR-2020
Hope that inspires !

Thanks for the suggestion! One limitation for integrating ZSM was, similar to EDVR, the dependence on custom CUDA kernels for the Deformable Convolutions v2, but since it looks like it will be soon integrated in a new version of mainline PyTorch, it could be added as an option soon!

Thanks for the suggestion! One limitation for integrating ZSM was, similar to EDVR, the dependence on custom CUDA kernels for the Deformable Convolutions v2, but since it looks like it will be soon integrated in a new version of mainline PyTorch, it could be added as an option soon!


Refactor [WIP]

This is a full refactor of the base code that will include the following:

[x] An interface for interaction potentials, with some examples.
[x] A new type hierarchy for the system and simulation information.
[x] An interface for the simulation itself.
[x] An implementation of the canonical ensemble (NVT).
[ ] A logging implementation to save quantities of interest.
[x] Tests and documentation.

Logging can be left for later, I think this is a good place to merge.


Upload to hackage and stackage

We should upload the tool once we have some feedback that from the team.
TODO:

[x] Upload to hackage
[ ] Upload to stackage

In order to upload to hspec-golden to stackage we need to also upload simple-opt or use a different library.

The package is already in hackage and stackage nightly.


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 931 ms

Resolved: Bofrost.be performance has improved in c071919.


Failed to load resource: Method PUT is not allowed by Access-Control-Allow-Methods.

I am able to generate what looks like a valid signing url from my back-end, but after selecting a file this is what I see in the console:
Upload progress: 0% Waiting
Failed to load resource: Method PUT is not allowed by Access-Control-Allow-Methods.
XMLHttpRequest cannot load https://amazon.s3.endpoint/myKey?AWSAccessKeyId=myValidAcccessKey&Expires=1471656383&Signature=xYZpoaKUlgMjPdarhSaqu4AwCE0%3D. Method PUT is not allowed by Access-Control-Allow-Methods.
error – "XHR error"

I have spend a lot of time making sure the CORS settings on S3 and my back-end are correct, but no joy. I have tried this with both Amazon and an S3-compatible alternative, both with the same result.
Anything I can try?

Some weird CORS thing documented nowhere.

Yeah, CORS can be weird sometimes.  Sounds like you just needed to set Access-Control-Allow-Methods correctly.
Side note: I've found that Chrome Canary provides really useful error messaging in their Network tab... way better than standard chrome.

Yeah, this was all CORS stuff on the side of the S3 hosts. Fixed now.

@OKNoah I am facing the same issue, Can you tell me the setting you did to resolve this issue?


Move servicelb into cloudprovider

Proposed Changes

Implement the newer, more efficient InstancesV2 interface which doesn't require us to get the node on our own
Drop the InformerUser interface, since we are using InstancesV2 or Wrangler controllers and no longer make use of core Kubernetes shared informers.
Move servicelb into cloudprovider and implement the LoadBalancer interface with the help of some Wrangler controllers to paper over holes in the upstream integrations. This appears to have been planned for upstream, as cloudprovider.ImplementedElsewhere can be returned most places to indicate a no-op status.
Using the core LoadBalancer interface gives us all the normal Service events that other cloud providers expose, handles finalizers, and many other niceties that we were previously hand-rolling.
Moving it into the cloud controller means we can easily enable it on RKE2 if we so desire.

Types of Changes
enhancement
Verification
Normal servicelb tests
Testing

Linked Issues

User-Facing Change
The ServiceLB (klipper-lb) service controller is now integrated into the K3s stub cloud controller manager. Disabling the k3s CCM will also disable ServiceLB.

Further Comments

Codecov Report
Base: 9.72% // Head: 9.79% // Increases project coverage by +0.06% :tada:

Coverage data is based on head (3c8f3e0) compared to base (53c268d).
Patch coverage: 3.80% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##           master   #6181      +/-   ##
=========================================
+ Coverage    9.72%   9.79%   +0.06%
=========================================
  Files         138     139       +1
  Lines       10057   10058       +1
=========================================
+ Hits          978     985       +7
+ Misses       8880    8871       -9
- Partials      199     202       +3

Flag
Coverage Δ

unittests
9.79% <3.80%> (+0.06%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

 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.

How could we use this in rke2

Update the k3s version in https://github.com/rancher/image-build-rke2-cloud-provider
Update k3s in rke2
Update the rke2 CLI wrapper so that servicelb isn't always disabled
Update the rke2 RBAC helpers to sync the CCM RBAC changes from k3s
Update the rke2-cloud-provider image tag in rke2


Remove Expo.Messages.find/2 with lists

It looks like we're not using this in Gettext.

Pull Request Test Coverage Report for Build 0229f087e37cb8ee6276e7f377ae5a73862adfca-PR-71

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build d3b6377edf24884f290efcaae1f5e346c39e3555:
0.0%

Covered Lines:
364

Relevant Lines:
364

💛  - Coveralls

Pull Request Test Coverage Report for Build 18c8915474f6727ef950e83cc5d40224e74080ea-PR-71
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 2164566cb21dc88f237a5350cd4372aa257d4976:
0.0%

Covered Lines:
364

Relevant Lines:
364

💛  - Coveralls


my.$id.new-item route matches my.$id route

What version of Remix are you using?
2.2.0
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
I have a route that defines a form with a list of sub items that have their own form.
The route setup is as follows
settings.instructors._index.ts - list
settings.instructors.$id.tsx - edit form parent
settings.instructors.$id.new-item.tsx - create form child
settings.instructors.new.tsx - create form parent

When I access /settings/instructors/1/new-item I get the page content for /settings/instructors/1
When I change the route name to
settings.instructors.new-item.$id.tsx - create form child

and access /settings/instructors/new-item/1
I get the correct page content
This seems weird to me. Am I wrong?
Expected Behavior
I would expect to get the content for the correct page
Actual Behavior
I get the content for the parent page

v2 flat convention nests routes by looking at the parent prefix.
settings.instructors.$id.tsx <- parent layout
settings.instructors.$id.new-item.tsx <- prefix matches parent layout
^^^^^^^^^^^^^^^^^^^^^^^^

When you have a child route, your parent layout must include an <Outlet> to render the child route.

As @kiliman said, this is by design that child routes automatically inherit the parent layouts and parent's must include an <Outlet /> informing Remix where to render the child content.
It sounds like you may not want to inherit the parent layout, so you may want to opt out of layout nesting.


Make constant renamer handle aliases

Motivation

Fixes https://github.com/sorbet/sorbet/issues/5463
Test plan

See included automated tests.

Somehow this breaks type_members
# typed: true
class Parent
  extend T::Generic
  Klass = type_template
end

class Child < Parent
  Klass = type_template(fixed: String)
end

starts breaking. Going to have to spend some time figuring that out, don't see an easy fix. Moving to draft for the time being.

With #5836 applied and placeholderText: MyAlias filled in on the testcases, we now get:
froydnj@pyro:~/src/sorbet$ ./bazel test -c opt //test:test_corpus_lsp
INFO: Invocation ID: f5a53f05-4d4b-497b-bc43-f33d2426465a
INFO: Analyzed 1225 targets (0 packages loaded, 0 targets configured).
INFO: Found 1225 test targets...
FAIL: //test:test_LSPTests/testdata/lsp/rename_alias_transitive (see /home/froydnj/.cache/bazel/_bazel_froydnj/c161c0eb7edcd00e8e8eaa053696c88e/execroot/com_stripe_ruby_typer/bazel-out/k8-opt/testlogs/test/test_LSPTests/testdata/lsp/rename_alias_transitive/test.log)
INFO: From Testing //test:test_LSPTests/testdata/lsp/rename_alias_transitive:
==================== Test output for //test:test_LSPTests/testdata/lsp/rename_alias_transitive:
+ exec test/lsp_test_runner --single_test=test/testdata/lsp/rename_alias_transitive.rb
Pausing
Resuming
[doctest] doctest version is "2.3.7"
[doctest] run with "--help" for options
===============================================================================
test/lsp_test_runner.cc:486:
TEST CASE:  LSPTest

test/helpers/position_assertions.cc:1383: FATAL ERROR: REQUIRE_EQ( this->placeholderText, placeholder ) is NOT correct!
  values: REQUIRE_EQ( MyAlias, MyModule )

===============================================================================
[doctest] test cases:      1 |      0 passed |      1 failed |      0 skipped
[doctest] assertions:     43 |     42 passed |      1 failed |
[doctest] Status: FAILURE!
================================================================================
FAIL: //test:test_LSPTests/testdata/lsp/rename_alias (see /home/froydnj/.cache/bazel/_bazel_froydnj/c161c0eb7edcd00e8e8eaa053696c88e/execroot/com_stripe_ruby_typer/bazel-out/k8-opt/testlogs/test/test_LSPTests/testdata/lsp/rename_alias/test.log)
INFO: From Testing //test:test_LSPTests/testdata/lsp/rename_alias:
==================== Test output for //test:test_LSPTests/testdata/lsp/rename_alias:
+ exec test/lsp_test_runner --single_test=test/testdata/lsp/rename_alias.rb
Pausing
Resuming
[doctest] doctest version is "2.3.7"
[doctest] run with "--help" for options
===============================================================================
test/lsp_test_runner.cc:486:
TEST CASE:  LSPTest

test/helpers/position_assertions.cc:1383: FATAL ERROR: REQUIRE_EQ( this->placeholderText, placeholder ) is NOT correct!
  values: REQUIRE_EQ( MyAlias, MyModule )

===============================================================================
[doctest] test cases:      1 |      0 passed |      1 failed |      0 skipped
[doctest] assertions:     43 |     42 passed |      1 failed |
[doctest] Status: FAILURE!
================================================================================
INFO: Elapsed time: 0.536s, Critical Path: 0.15s
INFO: 3 processes: 4 processwrapper-sandbox.
INFO: Build completed, 2 tests FAILED, 3 total actions
//test:test_LSPTests/testdata/lsp/rename_alias                           FAILED in 0.1s
  /home/froydnj/.cache/bazel/_bazel_froydnj/c161c0eb7edcd00e8e8eaa053696c88e/execroot/com_stripe_ruby_typer/bazel-out/k8-opt/testlogs/test/test_LSPTests/testdata/lsp/rename_alias/test.log
//test:test_LSPTests/testdata/lsp/rename_alias_transitive                FAILED in 0.1s
  /home/froydnj/.cache/bazel/_bazel_froydnj/c161c0eb7edcd00e8e8eaa053696c88e/execroot/com_stripe_ruby_typer/bazel-out/k8-opt/testlogs/test/test_LSPTests/testdata/lsp/rename_alias_transitive/test.log

INFO: Build completed, 2 tests FAILED, 3 total actions

which suggests that we just need to be a little more careful about what text we're presenting to the user here.


Crash in user_leds_set() -> xEventGroupSetBits()

Under heavy leds artnet -> update_leds() -> user_activity() load, user_leds_set() -> xEventGroupSetBits() will occasionally crash:
Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4008e16b  PS      : 0x00060a33  A0      : 0x8008bba2  A1      : 0x3ffdd590
0x4008e16b: uxListRemove at /opt/esp-idf/components/freertos/list.c:199

A2      : 0x3ffc1dc0  A3      : 0x3ffb3c5c  A4      : 0x00000001  A5      : 0x00060a23
A6      : 0x00000005  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3ffafb28
A10     : 0x3ffafb28  A11     : 0x00000000  A12     : 0x00000001  A13     : 0x00060a23
A14     : 0x00000003  A15     : 0x00060f23  SAR     : 0x0000001f  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000004  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff

Backtrace:0x4008e168:0x3ffdd5900x4008bb9f:0x3ffdd5b0 0x4008d482:0x3ffdd5d0 0x400fc596:0x3ffdd5f0 0x400d8099:0x3ffdd630 0x400d80e9:0x3ffdd650 0x400d7bb9:0x3ffdd670 0x400dcfe8:0x3ffdd690 0x400dd758:0x3ffdd6b0 0x4008e1d1:0x3ffdd7b0
0x4008e168: uxListRemove at /opt/esp-idf/components/freertos/list.c:193

0x4008bb9f: vTaskRemoveFromUnorderedEventList at /opt/esp-idf/components/freertos/tasks.c:3751

0x4008d482: xEventGroupSetBits at /opt/esp-idf/components/freertos/event_groups.c:664

0x400fc596: user_leds_set at /build/components/user_leds/user_leds.c:216

0x400d8099: set_user_led at /build/main/user_leds.c:257

0x400d80e9: set_user_leds_activity at /build/main/user_leds.c:278

0x400d7bb9: user_activity at /build/main/user.c:74

0x400dcfe8: update_leds at /build/main/leds.c:169

0x400dd758: leds_artnet_main at /build/main/leds_artnet.c:232

0x4008e1d1: vPortTaskWrapper at /opt/esp-idf/components/freertos/port/xtensa/port.c:131

ELF file SHA256: a1b9c594030c662c

Rebooting...

Similar conditions also lead to an occasional lockup, where the ESP32 just freezes without a panic, and the watchdog fails to reboot.

https://github.com/espressif/esp-idf/issues/8336 seems suspisciously similar

The patch fixing this bug in #24 is kinda experimental, and may possibly introduce some other bugs in the event group behavior in this race condition case, but it shouldn't affect behavior outside of this race condition case.
This race condition only happens when a task calls xEventGroupWaitBits() with a 0 < timeout < portMAX_DELAY, and a task running on a different core calls xEventGroupSetBits(). I suspect the workaround could cause missed wakeups in these cases, but the potential effect should be limited if the waiting task keeps calling xEventGroupWaitBits() with a nonzero timeout :thinking:

https://github.com/qmsk/esp/pull/25 should fix this properly, it was possible for event bits to be completely lost in the race condition case


IDEAS - DatePicker: Design system website contextual example updates

Date picker examples/use cases:
Using the date picker in a service can get complicated working with different timezones and saving date vs date and time. Below are suggested examples to add to the design system website documentation to show how a service can save a date to a database:

Allow user to select a date and/or time and save to database, then later load from database and display same date in datepicker (regardless of user's timezone).
Allow user to select a date and time, save to database, then later load from database and display same date and time in user's local timezone (e.g. 3pm if Mountain time, 5pm if Eastern time). That third example is used when needing to save/display a "moment in time" whereas the other examples are not. Then it sounds like you've considered date ranges before, which work the same as those 3 examples with a bit more complexity.

Since there is some additional design and exploration that needs to be done before this can be implemented we will track this work in our "design" repo on this issue


.Net Agents: Should InvokeAsync for ChatCompletionAgent return an IAsyncEnumerable?

Once we have the streaming version of agents, shouldn't ChatCompletionAgent just return a list of chat messages?

This decision point might not be necessarily linked to streaming support.

Curious to know if the streaming version of agents provide a new API call for streaming or the whole agent is stream. This question relates to how we do in SK services where we do provide two APIs for Streaming and Not-Streaming scenarios in the same service.
graph LR
Agent --> InvokeAsync
Agent --> InvokeStreamingAsync

OR
graph LR
Agent --> InvokeAsync_
StreamingAgent --> InvokeAsync

@RogerBarreto - Likely the former.  Do you have thoughts / suggestions?

@matthewbolanos - Signature modification also indicated for https://github.com/microsoft/semantic-kernel/issues/6813.

@matthewbolanos - For the Open AI Assistant case, a run can produce multiple messages which are sometimes separated by tool calls that might have latency (i.e. code-interpreter).  IAsyncEnumerable enables earlier messages to be accessed while the run proceeds.  Returning the messages in a syncronous fashion may increase the percieved latency.
This consideration may also be applicable to chat-completion scenarios.

Already is!


check function if reset all bids works as it should

sometimes bids are not reset when they should. It might be the problem with variable, where latest bid price is saved

corrected & updated

corrected in new version, which will be published soon


Event List not updating automatically after creation

Is it a ?

[x] Bug Report

[ ] Feature Request

[ ] Chore

Bug Report
Actual Behaviour
After an event is created, the list is not updated automatically
Expected Behaviour

[ ] Once the event is created, it's response is the event itself and hence should be saved in the repository on receiving.
[ ] Then, a change listener should be created in the event list presenter, so that any change in database is reflected in the list

@iamareebjamal Can i work on it?

Sure, please go ahead

@Masquerade0097 Are you working on this?

Sorry, I'll work on it.

@Masquerade0097 Are you working on it?

@sridharjajoo  No.

So I am taking up this issue :)

@iamareebjamal I have implemeted the change listener so that any change in database can be reflected in the list but still the events are not getting shown up.The created event is already getting saved in the repository right?

Yes

@sridharjajoo Are you stil working on this ? If no, then i will take it. If yes and still facing the problem, then IMO you should open a WIP PR so that others can point out the mistake if any.

@srv-twry I was actually on this issue but for the past few days the event creation wasn't taking place and hence I was not able to go any further. But since the latest commit event creation is taking place and I will be again working on it. If I encounter any problem I'll surely ask.

Nevertheless create a WIP PR. The reason list is not updated is because once createventactivity is opened, the database listener(even when it is added), stops listening and one the event is created and the activity is closed, the database loading takes place and for some reason returns the old event list and not the new one

@iamareebjamal If it's not an issue can I make a WIP PR by day after tomorrow? Actually I don't have my laptop currently.

@iamareebjamal Should I create a bottomsheetfragment for the creation of new event rather than opening a new activity? I think then the event list will get updated automatically.

No, the form is too big for BottomSheetView, you can use standard fragment though


Remove the error msg from listAutotuneTunables output

Remove this error msg from listAutotuneTunables output -   "Error: Tunables matching sla_class throughput not found"
http://localhost:8080/listAutotuneTunables?sla_class=throughput
[
    {
        "layer_level": 0,
        "tunables": [
            {
                "value_type": "double",
                "lower_bound": "150M",
                "name": "memoryRequest",
                "upper_bound": "300M"
            },
            {
                "value_type": "double",
                "lower_bound": "1.0",
                "name": "cpuRequest",
                "upper_bound": "3.0"
            }
        ],
        "layer_name": "container",
        "layer_details": "generic container tunables"
    },
    {
        "layer_level": 0,
        "tunables": [{
            "value_type": "double",
            "lower_bound": "2.0",
            "name": "cpuRequest",
            "upper_bound": "4.0"
        }],
        "layer_name": "mycontainer",
        "layer_details": "mycontainer tunables"
    },
    "Error: Tunables matching sla_class throughput not found"
]

Steps to recreate:

Apply a new autotune config yaml by removing throughput sla_class

Issue is resolved in Autotune 0.0.5 release


Add fungible token information to exchange integration page

We need to provide a way to allow exchanges to query information about fungible tokens. Particularly balances and when transfers happen. We want to be as specific as possible and include RPC calls instead of abstractions of our library or tools.

[ ] Document simple transfer using the recommendations in this comment.
[ ] Document transfer and call using the recommendations in this comment.

I've provided a little skeleton of the sections here and fleshed out the first one.
Useful links:

https://nomicon.io/Standards/FungibleToken/Core.html
https://github.com/near-examples/FT

Hey @frol and @bowenwang1996 I think the RPC response has changed since publishing the documentation we're adding to here:
https://docs.near.org/docs/roles/integrator/exchange-integration
For example, in the link above we have a section I'm focusing on has a bolded title:
Example of transfer from a lockup contract
Here's a quick snippet from the top of the tx status query:
  "result": {
    "receipts": [
      {
        "predecessor_id": "evgeny.near",
        "receipt": {

Right off the bat this is different than what I'm seeing in my responses. predecessor_id seems to have been changed to executor_id. Is that correct? (Just making sure)
And I also don't see a receipts section.
But anyway, aside from that, here's my base understanding of how to approach this… It'll probably be useful for one of us to take a stab at a solution and you tell me if I'm wrong and what it should be instead.
Goal: we are trying to determine if a fungible token transfer was successful or not, and for how much. This will be ingested by exchanges as they use their own form of indexer that may or may not use the node indexer framework.
Here I have a transaction for an FT transfer. This is the simple kind. Let's not worry about transfer_and_call yet which is more complex.
Explorer:
https://explorer.testnet.near.org/transactions/CLScKgKkuUfjiR3xghy52Men7F95Q1uysJKfmQ1cnV4J
Get results via HTTPie:
http post https://archival-rpc.testnet.near.org jsonrpc=2.0 id=ft-transfer method=tx params:='[ "CLScKgKkuUfjiR3xghy52Men7F95Q1uysJKfmQ1cnV4J", "ft.demo.testnet"]'
Result (clickto expand/collapse):

JSON response to ft_transfer
{
  "id": "ft-transfer",
  "jsonrpc": "2.0",
  "result": {
    "receipts_outcome": [
      {
        "block_hash": "EMyNdkeYJQVJFPPqRoQxZh5i6XTs6bUh5CrTfATPh23K",
        "id": "DYgNBp8svBJLMJaRawJTW2DEVRcaYYVE5EJ1a6f47sdv",
        "outcome": {
          "executor_id": "ft.demo.testnet",
          "gas_burnt":<PHONE_NUMBER>840,
          "logs": [
            "Transfer 1000000 from ft.demo.testnet to mike.testnet"
          ],
          "receipt_ids": [
            "AaKuP3PjbzBnu42WomNbSjsjrgvMXTQkyuvN5EY1uh6z"
          ],
          "status": {
            "SuccessValue": ""
          },
          "tokens_burnt": "477009437484000000000"
        },
        "proof": [
          {
            "direction": "Left",
            "hash": "2QzJXjSPDCYTw9z4CZqdN6mvzrKxxLb1sw6v7BrA2Ydy"
          },
          {
            "direction": "Right",
            "hash": "9MAZmB81AqSPJso6xomyNDziqF6imgUknzvkpJExXpLc"
          }
        ]
      },
      {
        "block_hash": "9eRSDDoJ8KjEVKfQtZjMEVoDNhubBKytoQYu84KYMXK1",
        "id": "AaKuP3PjbzBnu42WomNbSjsjrgvMXTQkyuvN5EY1uh6z",
        "outcome": {
          "executor_id": "ft.demo.testnet",
          "gas_burnt": 0,
          "logs": [],
          "receipt_ids": [],
          "status": {
            "SuccessValue": ""
          },
          "tokens_burnt": "0"
        },
        "proof": []
      }
    ],
    "status": {
      "SuccessValue": ""
    },
    "transaction": {
      "actions": [
        {
          "FunctionCall": {
            "args": "eyJyZWNlaXZlcl9pZCI6Im1pa2UudGVzdG5ldCIsImFtb3VudCI6IjEwMDAwMDAifQ==",
            "deposit": "1",
            "gas":<PHONE_NUMBER>00000,
            "method_name": "ft_transfer"
          }
        }
      ],
      "hash": "CLScKgKkuUfjiR3xghy52Men7F95Q1uysJKfmQ1cnV4J",
      "nonce":<PHONE_NUMBER>0006,
      "public_key": "ed25519:2JvNesazERwBkbFsgFsESvZ5bh78jTVEkjLP8tfLYbz2",
      "receiver_id": "ft.demo.testnet",
      "signature": "ed25519:2jQnRj5tvnPx4eoFTt54CgxsuVxXmxGn7DaZNqA8Yqpxshbdw52ZdkjiziiWoW51e4zkN81RYp7u3C25VwihGqUk",
      "signer_id": "ft.demo.testnet"
    },
    "transaction_outcome": {
      "block_hash": "EMyNdkeYJQVJFPPqRoQxZh5i6XTs6bUh5CrTfATPh23K",
      "id": "CLScKgKkuUfjiR3xghy52Men7F95Q1uysJKfmQ1cnV4J",
      "outcome": {
        "executor_id": "ft.demo.testnet",
        "gas_burnt":<PHONE_NUMBER>040,
        "logs": [],
        "receipt_ids": [
          "DYgNBp8svBJLMJaRawJTW2DEVRcaYYVE5EJ1a6f47sdv"
        ],
        "status": {
          "SuccessReceiptId": "DYgNBp8svBJLMJaRawJTW2DEVRcaYYVE5EJ1a6f47sdv"
        },
        "tokens_burnt": "242805515604000000000"
      },
      "proof": [
        {
          "direction": "Right",
          "hash": "Em1LTLKfAp9CHsESqSu2GeQhahkNNFssR2jL8Ekeh6Vx"
        },
        {
          "direction": "Right",
          "hash": "9MAZmB81AqSPJso6xomyNDziqF6imgUknzvkpJExXpLc"
        }
      ]
    }
  }
}

Here's what I am guessing the exchanges should do to ensure the FT transfer was successful and for how much.
Look for result » transaction_outcome » outcome » (see if SuccessReceiptId is a key)
if SuccessReceiptId is not a key, this fungible token transfer has failed.
If it does have that key, get the value, which is a receipt ID.
Loop through result » receipts_outcome until you find an object that ID (from above) under the id key, then in that object check outcome » status » (see if SuccessValue is a key)
If SuccessValue is a key, fungible token transfer succeeded, if not, it failed.
To determine how many fungible tokens were transferred, look at:
result » transaction » actions » FunctionCall » args, then take the args and base64 decode it, that will give you a JSON payload and look for the amount key. It will contain a stringified number that represents the number of fungible tokens that were successfully transferred.
Good approach? Right? Wrong? Leave you comments below and don't forget to hit like and subscribe.

@mikedotexe I have added near-cli and JSON RPC examples with responses to Simple transfer example.

I have used your explanation about how to check if the transaction was successfull. Please, review.
cc @thisisjoshford

Right off the bat this is different than what I'm seeing in my responses. predecessor_id seems to have been changed to executor_id. Is that correct? (Just making sure)

No. executor_id only exists in execution outcomes and it is not part of Receipt.

Right, I think we're saying the same thing. I'm pointing out that this document is wrong now.

I don't believe the above screenshot happens anymore, and unfortunately we have instructions to exchanges to look for predecessor_id here.

I think we need to make another pass at the native token instructions in addition to the fungible token instructions.

I don't believe the above screenshot happens anymore, and unfortunately we have instructions to exchanges to look for predecessor_id here.

@mikedotexe I believe that output is from EXPERIMENTAL_tx_status endpoint, we have not had a chance to stabilize it yet (it is absolutely safe to use this method, we will just replace the old tx method eventually)

Task: fix the broken code and logic. I believe everything under the section Example of transfer from a lockup contract has been outdated for a while. We also have logic explaining to exchanges:

they only need to filter receipts that only contain Transfer action and whose predecessor_id is not system

There may be more that's wrong, but for sure it's not predecessor_id when we use NEAR CLI's tx-status
I think that's because NEAR CLI uses the tx instead of EXPERIMENTAL_tx_status. So either we need to meet with @frol about expectations for this getting a different name, or being backwards compatible, and if we should change NEAR CLI to use it. OR we need to remove all NEAR CLI references here. We just have to make sure exchanges can follow these instructions and can see the same thing we're showing them they should see, which is currently not the case.

hey @thisisjoshford I see you have a change requested, but think it might be a comment. All good?
Everyone else: ready to review


Killing machine doesn't migrate the pod immediately

I'm running kubernetes on top of coreos machines inside of vagrant.
It looks like if I deploy some pods into a cluster with 1 master and 4 minions, and then kill one of the vagrant machines running a given pod, kubernetes does not immediately migrate the pod to another machine. It seems to take about 13 minutes to notice that the machine is dead. During that time, if I run kubectl get pods it still shows the pod as "running", even though the machine is gone and has been for awhile.
Eventually it does migrate the pod, but the last time I tried this it took 13 minutes to notice the machine died before doing so.
I originally raised the issue here on the chance that it was an issue that is specific to the implementation. But it seems like @pires believes this to be an issue he's seen before with kubernetes.
I tried it a number of times with both 0.11.0 and 0.12.1, and the issue continues.
I searched through the issues and couldn't find an obvious reference to this. Is this a known issue?
Is there anything else I can do to help debug it? It's easy for me to reproduce.

I think this has to do with our notion of "forgiveness" when a node disappears. @erictune?

I don't think that anything has been implemented around "forgiveness".  We just talked about that.

Interesting. I did a similar test the other day and had just assumed that was what was going on. Any ideas what could actually be happening then?

PodEvictionTimeout:      5 * time.Minute
I don't see how we are getting to 13 minutes.

@erictune I got the 13 minutes by observing the difference in pod created time. I'll reproduce the issue right now and double check that.
In addition, prior to the eviction timeout expiring, should the pod be reported as 'running' when it's missing entirely? I guess that's a different issue.

We've been working on pushing pod status to the master from the machines. We'd need a mechanism through which the master can see when the statuses have not been updated in EXPECTED_TIME and reflect that.

Right now, it should be Unknown
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/master/pod_cache.go#L199

@ehacke Oh, I believe you.  I just don't have any idea why yet.

@erictune I'm not sure I believe me, so I'm double checking.

So it's possible I could have just done bad math for the 13 minute case, because it does look like it's ~5 minutes in the three cases I just tried.
In terms of status, it does continue to report as 'Running' even if the machine is dead. Though it seems like if I bring the formerly dead machine back with the same IP, the reporting updates to 'Unknown'.

Look at the node.status.conditions. You should see a condition with kind==Ready with the status, last probe time, etc.
If you want to change the 5-minute default, you can set --pod_eviction_timeout= on the controller-manager command line.
@ddysher

I encountered the same issue and found that the POD was evicted pod_eviction_timeout seconds after the minion is considered not ready anymore.
The problem is that if the minion is totally unresponsive, its status is not updated.
Here is what I observe if I pause the VM hosting the minion <IP_ADDRESS> :
$ cluster/kubectl.sh get minions
NAME                LABELS              STATUS
<IP_ADDRESS>        <none>              Ready
<IP_ADDRESS>        <none>              Ready
<IP_ADDRESS>        <none>              Ready

$ cluster/kubectl.sh get minions -o yaml | grep lastProbeTime:
      lastProbeTime: 2015-03-16T08:55:27Z
      lastProbeTime: 2015-03-16T08:43:39Z
      lastProbeTime: 2015-03-16T08:55:29Z

@lhuard1A This is a similar, but different issue.  The unresponsive vm is due to the fact we switched node status update from controller to kubelet itself.
PR is here #5399; I think we need to get that in this week.
@bgrant0607 @dchen1107


Mysql Api

How  should I save flows into mysql?
I want to save each flow in flow.response function.

Hi,
You can save different parts of the flows as different columns by using a third-party module mysql.connector, third-party modules don't work with our precompiled binaries, more info here
Also, you can save all flows in a file instead using pressing w on mitmproxy console window and then providing the path, clicking on mitmproxy(top-left) -> Save if you are using mitmweb, or directly stream the flows to a file as soon as they arrive by mitmproxy -w PATH or mitmdump -w PATH

Thanks @kira0204 and @Gigiarum!

Discourse post

In this Discourse post there is my script to save requests and responses to MongoDB.

Thanks a lot!


Add Docker functionality for Solder

This PR adds Docker functionality to TechnicSolder. Docker gives the solder user the ability to quickly setup an instance without needing to worry about what software runs on their system. As long as they can install Docker / Docker Compose, this will run. I was setting it up for a separate project (Endermedia solder) and worked a little with Pyker. There was another open PR, but it doesn't really work and doesn't have any contextual information. So with some help, I set this up and tested for reproducibility by following the steps outlined in the readme.
This PR makes zero changes to the app or php. It just adds some docker stuff. It won't effect solder if a person chooses to not use it. But if they do choose to use it, it can save them some time in getting things setup.
If there was any sort of setup that I missed along the way, please let me know. For example, I didn't know Redis was a thing before starting this xD. I'm not sure if it's setup correctly but everything appeared to work with it.

Thanks!


How to properly visit a list of links ??

I am on a main page and have used evaluate to gather a list of href's
I would like to  do the following from the main page
For each link:

goto(link)
collect some data (I already have the logic)
goto('mainpage.com')

let linksArr = [];
    async function run() {
      const chromeless = new Chromeless()
      jobs = await chromeless
        .goto('https://someurl.com')
        .wait('#someId')
        .evaluate(() => {
          // this will be executed in headless chrome
          const jobs = [].map.call(
            document.querySelectorAll('a.someClass'),
            function(job){
              // I have a list of links, each link can be accessed individually inside map via job.href
              //??? What do I do now to visit each link ??? while maintaining the same chrome window that will allow me to revert back to the main page.
              return {title: job.innerText, href: job.href}

            });
          return JSON.stringify(jobs)
        })
        await chromeless.end()
    }
    run().catch(console.error.bind(console))
  }

If jobs contains all of the title and hrefs you want to process, I would just iterate through jobs and have a function that takes the chromeless object and the job element and processes it.
Maybe something like this?
const { Chromeless } = require('chromeless')

const mainUrl = 'https://some-main-url';

async function visitSubPage(chromeless, job) {
  console.log('visiting', job.href);
  return chromeless
    .goto(job.href);

  // do stuff on the sub page
}

async function run() {
  const chromeless = new Chromeless();
  let jobs = await chromeless
    .goto(mainUrl)
    .evaluate(() => {
      // this will be executed in headless chrome
      const jobs = [].map.call(
        document.querySelectorAll('#some-selector'),
        function(job){
          // I have a list of links, each link can be accessed individually inside map via job.href
          //??? What do I do now to visit each link ??? while maintaining the same chrome window that will allow me to revert back to the main page.
          return {title: job.innerText, href: job.href}
        });
      return jobs;
    })

  // iterate through hrefs that were found
  for (var job of jobs) {
    await visitSubPage(chromeless, job);
  }

  // once done iterating through subpages, return back to the main url
  await chromeless.goto(mainUrl);

  await chromeless.end()
}

run().catch(console.error.bind(console))

Thanks @youhyunkim appreciate the push in the right direction! Back to scraping :)

Thank you for that helpful response, @youhyunkim! 😃


Application permits TX frame configuration with invalid DLC

The application should clamp the user input to the closes possible valid DLC value.

Should be fixed in version 4.3.4 on master branch.

Looks good in 4.3.4


feat: add door handler

add door service for opening the door
add publish door status to /vehicle/status/door_status

@tkimura4 , Hi can you review this PR when you free?

Thanks
TODO: test this in real vehicle before merge @tkhmy

Memo:
After the PR is merged, the pacmod_interface will not work if the version of pacmod < 2002.1.0-0focal.


phenotype terms for geneomic dataset

Fungal phenotype terms:
phenotype: resistance to azole
http://purl.obolibrary.org/obo/OMP_0006055
phenotype: resistance to posaconazole
http://purl.obolibrary.org/obo/PHIPO_0000625
phenotype: resistance to voriconazole
http://purl.obolibrary.org/obo/PHIPO_0000590
(Details see https://redmine.apidb.org/issues/46756)
Please import the terms to VEuPathDB ontology

Agree that this should go in next release.


[elasticsearch] skip setting the node.remote_cluster_client env for ES6

[ v ] Chart version not bumped (the versions are all bumped and released at the same time)
[ v ] README.md updated with any new values or changes
[ v ] Updated template tests in ${CHART}/tests/*.py
[ ] Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

https://www.elastic.co/guide/en/elasticsearch/reference/6.8/modules-node.html - missing in ES6.

Yes, I've just noticed and switched to 6.8...
If esMajorVersion is going away, I suppose it doesn't make sense to extract the test from this PR then.
But it makes sense to add information that esMajorVersion is deprecated.


[FEATURE] Integrate oneDNN binary primitive support for forward add, subtract, multiply, divide.

Description
Binary broadcast operators such as add, subtract, multiply, divide are implemented in both NDArray and NumPy modules and no oneDNN support exists for those operators. Goal of this task was to dispatch execution of those operators to oneDNN binary primitive.
Checklist
Essentials

[x] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage
[x] Code is well-documented

Changes

[x] Merge execution of add, subtract, multiply, divide operators to one NNVM_REGISTER_OP() function
[x] Implement oneDNN dispatch for binary broadcast operators

Comments
Speedup for all cases noticed, up to ~350%.

@mxnet-bot run ci [unix-cpu]

@mxnet-bot run ci [sanity]

@mxnet-bot run ci [all]

@mxnet-bot run ci [windows-gpu]

您好，您发给我的邮件已收到，我会尽快查看。


Speech recognizer won't start

Hi,
When started, the SpeechRecognizerActivity gets stuck immediately.
Logcat says "SpeechRecognizer ..... org.vosk.service ..... E .. bind to recognition service failed" , when calling speechRecognizer.startListening(speechRecognizerIntent)
This error happens with both AnySoftKeyboard and SwiftKey (I didn't try other keyboards).
Note: I have the same error when using LocalSTT
Android 9 (api 28)
vosk-android-service 0.3.42

@gweltou , think I fixed this and put in a PR as #29.

Merged, let us know how it feels. Thanks @drew-sinha

Amazing ! I can confirm that it solved the issue.
Thanks @drew-sinha