31147 DEM Start Time Adjustment support

This PR adds support for the Start Time Adjustment test cases to Example Energy Management App.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: jamesharrow:x: fraiyatfraiyat seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Marzipano stand alone  viewer

It only seems that, what marzipano can do is to generate cubes of each photo. The only function it has is generation of 1..Generated Cube All this other capabilities which Marzipano has are not working 2.Simple Tour 3. Single Resolution Cube 4.Multiresolution Cube 5.Multiresolution Flat 6. Equirectangular 6.Video 7.Hotspot Styles 8.
Embedded Hotspots 8.Layers look at demo, after much testing I found those capabilities are missing.You mean it can't play jpeg, jpg or PNG file format which all photos are based on. In their website look at demo and they say its possible to Display a single resolution cubic image with Marzipano, Display an equirectangular image with Marzipano. A normal image will be uploaded into where images are being stored. That's why we were developing this application.The images are hosted in my server

It's a stand alone Marzipano viewer

I'm sorry, I don't understand the point are trying to make. The features you mention are all illustrated by the demos at http://www.marzipano.net/demos.html. Do you mean they're not working for you? What happens when you open them?

I am facing issues  relating to open source viewer after following the
stand alone viewer API docs and installation of all software's
successfully. generations of  cubes is all I can see whereby each photo is
generated to so many cubes of  itself.
On Thu, May 28, 2020, 10:44 PM Tiago Quelhas<EMAIL_ADDRESS>wrote:

I'm sorry, I don't understand the point are trying to make. The features
you mention are all illustrated by the demos at
http://www.marzipano.net/demos.html. Do you mean they're not working for
you? What happens when you open them?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/marzipano/issues/317#issuecomment-635557097,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALKLNUNCN7H56XAPSNQRXUTRT25JPANCNFSM4NM7IJJA
.

If this is still a problem, please reopen with a link to a demo so we can see what is working incorrectly.


Record from a streamed source (e.g. Podcast)?

Is it possible to use this to play an audio stream (e.g. Podcast) and save on the device?
If not, would appreciate ideas on which direction to look to accomplish this.

You want to offer offline downloads? use a different module and download the podcast to the device and when the user plays an episode check your localstorage for the file


Add short-hand form for simple selects

Placeholder data might easily need to reference existing rows, such as when using reference tables that get populated by external processes (eg. migrations), and there needs to be some strategy for referencing these.
For example, given some super basic database schema like...
create table species (
  id serial primary key,
  name text unique not null
);

insert into species (name) values
    ('Felis catus'),
    ('Canis familiaris'),
    -- TIL that Furbies are egg-laying mammals most closely related to platypuses and echidnas
    ('Furbi bipodus');

create table pets (
  id serial primary key,
  species_id int not null references species (id),
  name text not null
);

There needs to be some way to create a pet that references an existing species, potentially (and probably most simply) by allowing inline SQL that returns a single column.
table pets (
  purple (
    name 'Furby purple'
    species_id `select id from species where name = 'Furbi bipodus'`
  )
)

This might not be the absolute worst, especially if stored in a variable referenced by multiple records, but maybe there needs to be a more concise shorthand to build a small subset of SQL expressions.
table pets (
  purple (
    name 'Furby purple'
    species_id #species.id [name 'Furbi bipodus', ..]
  )
)

Note: Both of the above options might be useful, the latter just to have a sane short-hand and the former to allow the user to more generally leverage SQL whether it be selecting data from a table, executing a function, refreshing a materialized view after inserting data in the underlying tables, etc.

Inline SQL fragments are now tracked via https://github.com/crudecomputer/hldr/issues/59


OpenAI o1-like Chain-of-thought (CoT) inference workflow

Well, I am surprised that the "main" and "great" new feature of the new OpenAI o1 model is actually doing say "more sophisticated" inference workflow while employing something like Chain-of-thought process. Basically I understand it that even a "dumb" model can perform much better when it "thinks more" during inference. The great news they are telling us is that by "thinking more" you can get smarter, which is probably very true also for humans.
The o1 model is probably trained to come up with its own CoT workflow for any given prompt, but I think it could be interesting to try to even hardcode some kind of workflow which any standard LLM model may try to follow during inference. Basically let the model analyze the prompt from various perspectives first and then try to judge on what type of "inference workflow" it should employ.
The hardcoded workflow could look like this:

Prompt is submitted to the model.
The model asks itself couple of hard-coded questions about the prompt, maybe:

is that some light conversation (needing soft-skills like empathy etc)
does it look like a science problem (math, physics etc.)
can I break the prompt down to subtasks - if yes, the workflow will feed each subtask into the model separately, then combine the result etc.
is the problem easy/hard
do I have all information I need (do I need to ask the user for further input/clarification)

The workflow would run, maybe in multiple iterations on various its levels, maybe trying to fit some "quality checks" for the answer
The output is presented to the user (the "hidden" thinking may be optionally viewed by user)

Anyone having the same feelings as I do about the CoT thing? Looks like even a hard-coded process may give some interesting results.

You can do this with my open-source optimizing inference proxy optillm - https://github.com/codelion/optillm There are several other SOTA techniques that are implemented in that proxy that all trade inference time compute for accuracy.

@MichaelFomenko ollama has an OpenAI API compatible endpoint so just run the optillm proxy with python optillm.py --base_url http://localhost:11434/v1 make sure to set the OPENAI_API_KEY with  export OPENAI_API_KEY=ollama, it is not used by the OpenAI client expects it. Then you can call proxy in your own code as shown in here and it will use ollama in background.

You can do that by just pointing Open WebUI to use the proxy endpoint as the backend. There is documentation on how to do it https://docs.openwebui.com/getting-started/env-configuration#openai

You can do that by just pointing Open WebUI to use the proxy endpoint as the backend. There is documentation on how to do it https://docs.openwebui.com/getting-started/env-configuration#openai
If you are just looking to compare and see how it works you can try my HF space - https://huggingface.co/spaces/codelion/optillm

https://www.reddit.com/r/LocalLLaMA/comments/1fnjnm0/visual_tree_of_thoughts_for_webui/


Cannot find ApplyUncontrolledSWAP in original package

Description
The namespace of ApplyUncontrolledSWAP  can be found in page https://docs.microsoft.com/en-us/qsharp/api/qsharp/microsoft.quantum.intrinsic.applyuncontrolledswap.
But when running the following program,it failed because cannot find the ApplyUncontrolledSWAP in the package Microsoft.Quantum.Intrinsic .Has ApplyUncontrolledSWAP been moved to a new library?
Error message is shown below.

/home/htm/quantumDemo/Program.qs(40,9): error QS5022: No identifier with the name "ApplyUncontrolledSWAP" exists. [/home/htm/quantumDemo/quantumDemo.csproj]
/root/.nuget/packages/microsoft.quantum.sdk/0.24.210930/Sdk/Sdk.targets(147,5): error MSB3073: The command "dotnet "/root/.nuget/packages/microsoft.quantum.sdk/0.24.210930/DefaultItems/../tools/qsc/qsc.dll" build --format MsBuild -v Normal --response-files obj/qsharp/config/qsc.rsp" exited with code 253. [/home/htm/quantumDemo/quantumDemo.csproj]
/root/.nuget/packages/microsoft.quantum.sdk/0.24.210930/Sdk/Sdk.targets(152,5): error : Q# compiler failed with exit code: 253. [/home/htm/quantumDemo/quantumDemo.csproj]
The build failed. Fix the build errors and run again.

Testcase
namespace NISLNameSpace {
	open Microsoft.Quantum.Intrinsic;

	@EntryPoint()
	operation NISLOperation () : Unit {
		use q = Qubit[2];
        ApplyUncontrolledSWAP(q[0],q[1]);
        ResetAll(q);
	}
}

Environment
operating system:Windows 10
dotnet version:6.0.300
QDK:v0.24.210930

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

ID: 080f8964-0c43-bb59-713f-28a8a356008f
Version Independent ID: 05ca13a0-3313-4a38-5cef-bc93103add47
Content: ApplyUncontrolledSWAP operation - Q# reference - Microsoft Quantum
Content Source: api/qsharp/microsoft.quantum.intrinsic.applyuncontrolledswap.md
Product: qsharp
GitHub Login: @anjbur

@weucode The Core packages are generally automatically pulled in by the compiler, and not intended to be referenced directly. I recommend simply using SWAP, and the compiler will automatically resolve this to the corresponding backend function as appropriate. What was the reason you wanted to use it directly?

@cgranade @msoeken @bettinaheim This was indeed left public by mistake and should have been an internal operation to the target package. I have a PR out to fix it, but I wonder if it makes sense to suppress documentation for the target packages since they are not meant to be used directly but rather brought in automatically based on targeting logic?


[WIP] StoreKey: Introduce 3rd encryption level 16k, default

Description
StoreKey: Introduce 3rd, in-between encryption level (16k), and make that default .
Levels are now:

Minimal -- 4k
Weak -- 16k <-- new, this is also Default
Standard -- 262k

Follow up on #1766 .
Testing instructions
Unit tests. New wallet creation.
Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] Prefix PR title with [WIP] if necessary.
[x] Add tests to cover changes as needed.
[x] Update documentation as needed.
[x] I have read the guidelines for adding a new blockchain
[x] If there is a related Issue, mention it in the description (e.g. Fixes #<issue_number> ).

Note: with this PR, default wallet encryption parameters are changed, in case level is not specified explicitly, from 4k to 16k.


Pull in any new transcripts automatically and add them to a daily page

I think it'd be great if you could configure plugin to automatically pull-in any new transcripts available in Otter (phonetoroam style)

Closed in https://github.com/dvargas92495/roamjs-otter/commit/1197df03c4951d8fbd23a9b86857f0daa68c94aa


feat: Add ConnectionStringParser

Related to https://github.com/microsoft/ApplicationInsights-node.js/pull/538

/cc: @timothymothra

hi Mark, as part of this PR could you update the Readme with an example snippet of how to set the connection string?

hi Mark, as part of this PR could you update the Readme with an example snippet of how to set the connection string?

:+1: done e4ffd10


Allow dragging nodes to block canvas

In order to call methods on other nodes, you need a reference to the node. This adds a new get_node block definition that has all the other nodes provided as options. It also adds a method to drag a node from the scene tree dock and set the node's path in a get_node block automatically.
Unfortunately, in order to make the drag action usable, I had to drop the multi-select feature that automatically activates the block node's parent in the scene editor. I searched long for a way to do that without selecting the node, but it doesn't appear that there's a way to do it.
https://phabricator.endlessm.com/T35648

One note about the multi-select behaviour: it was also so, when someone is editing a block code node, the node it belongs to is highlighted in the canvas. I think it's fine losing this since it didn't work super well anyway and this feature is far more important, but it was something that was casually requested at some point. A better approach would be actually adding a representation of BlockCode itself in the canvas, but that would have to be pretty clever since it would depend on what type the parent node is.

One note about the multi-select behaviour: it was also so, when someone is editing a block code node, the node it belongs to is highlighted in the canvas. I think it's fine losing that since it didn't work super well anyway and this feature is far more important, but it was something that was casually requested at some point. A better approach would be actually adding a representation of BlockCode itself in the 2D / 3D canvas, but that would have to be pretty clever since it would depend on what type the parent node is.

Ah yes, that would be much welcome. A way to highlight the target node. I think that can be done with an editor plugin for any node that inherits CanvasItem by using get_viewport_rect() to get the bounding box.


Make lean: true by default

Lots of discussion in #110 but basically lean:true doesn't seem to have many drawbacks. It is faster and then people don't have to do the weird toObject everywhere.

Bump.

Bump. This keeps coming up in Slack.


npm run build !error

npm start is working, but i cant build it...
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "D:\Program Files (x86)\nodejs\node.exe" "D:\Program Files (x86)\nodejs\node_mod
ules\npm\bin\npm-cli.js" "run" "lint"
npm ERR! node v4.2.4
npm ERR! npm  v2.14.12
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>lint: esw webpack.config.* src tools
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>lint script 'esw webpack.config.* src tools'.
npm ERR! This is most likely a problem with the react-slingshot package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     esw webpack.config.* src tools
npm ERR! You can get their info via:
npm ERR!     npm owner ls react-slingshot
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     E:..\react-slingshot\npm-debug.log
npm ERR!  Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>prebuild script 'npm run clean-dist && npm run build:ht
ml && npm run lint'.
npm ERR! This is most likely a problem with the react-slingshot package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run clean-dist && npm run build:html && npm run lint
npm ERR! You can get their info via:
npm ERR!     npm owner ls react-slingshot
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     E:..\npm-debug.log

Questions:

Does this work? npm run prebuild
If 1 doesn't work, try changing the lint script to look like this: "lint": "node_modules/.bin/esw webpack.config.* src tools", and change the remove-dist script to: "remove-dist": "node_modules/.bin/rimraf ./dist",
What OS?
What command line?
What Node and npm version?

Turns out to be webpack setting errors.

@joodies I'm confused. Are you saying you had to change the Slingshot webpack configuration? What did you have to change?

The reason is:
import avatar from './images/avatar.jpg';
load image file failed in this way,  have to change to
const avatar = require('./images/avatar.jpg');
and use url-loader.


plugins: Fix alias-completion by comparing completions to alias literally

So, after having issues with alias-completion again, I re investigated and found out the correct fix
Description

The completion comparison to the alias should not be regex at all, it should be literal check
Motivation and Context

Local bug in alias-completion
How Has This Been Tested?

Locally, but better
I will add a test to combat the bugs here
Types of changes

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

Checklist:

[x] My code follows the code style of this project.
[ ] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
[ ] I have added tests to cover my changes, and all the new and existing tests pass.

The completion comparison to the alias should not be regex at all, it should be literal check

This seems legit, but I think its time to cite some official documentation on this.  ie. How did you come to know it should be a literal check?
Any links to share so we can all better-understand how this works?

The completion comparison to the alias should not be regex at all, it should be literal check

This seems legit, but I think its time to cite some official documentation on this. ie. How did you come to know it should be a literal check?
Any links to share so we can all better-understand how this works?

Hmm, to be honest, I am not quite sure why this fixed it.. I went by the changes we did in the linting process and tried to see which one of them fixes the problem I had. I think the best solution would be to add tests to this kind of thing, and I plan on adding tests (maybe in a future PR)

One last note and I think we got it

One last note and I think we got it

Thank you @davidpfarrell for the thoughtful review! You are always welcome to add notes/thoughts to the CR- you greatly improve the code quality of PRs :smile:


Multiple tabs in a single notebook

Description
I am hoping to be able to have multiple similar examples of some computations on a single document. Having one document for each example is very inefficient.
A single document for related examples makes it easier to share it.
Suggested solution
Each "Tab" could hold a separate example in an independent way.
Maybe some cells could be common to all tabs.
Silly example:
Common cell for all tabs: p=2 + More setup required.
Tab 1: a=1 + some other computations
Tab 2: a=5 + Other computations needed in this case
Tab 3: a=7 + Other computations needed in this case
Alternative
No response
Additional context
No response

Have you tried mo.ui.tabs? https://docs.marimo.io/api/inputs/tabs.html

Mi request is having some sort of "global" tabs. And in each tab there would be multiple cells, like a normal notebook.
The point is that the same variable could be defined in each tab with different values without getting an error.

that seems like it would get confusing to know which variable belongs to which.
we do plan to add notebook composition (you can import and embed one notebook in another). you will likely be able to achieve this much more easily with that feature. each notebook would have their own encapsulation of variables

ok that sounds similar than this request.


log: Use the same format when we're in INFO / DEBUG mode

It's nicer when gprofiler: is always included, and generally it's nicer to have the same format for file / stdout.

------
 > [node-package-builder-musl 6/6] RUN ./build_node_package.sh:
10.37 gyp ERR! stack at require (internal/modules/cjs/helpers.js:107:18)
10.37 gyp ERR! stack at Object.acc.<computed> [as install] (/usr/local/lib/node_modules/node-gyp/lib/node-gyp.js:80:32)
10.37 gyp ERR! stack at getNodeDir (/usr/local/lib/node_modules/node-gyp/lib/configure.js:53:26)
10.37 gyp ERR! stack at configure (/usr/local/lib/node_modules/node-gyp/lib/configure.js:24:10)
10.37 gyp ERR! System Linux 6.2.0-1015-azure
10.37 gyp ERR! command "/usr/bin/node" "/usr/local/bin/node-gyp" "configure" "--target=10.10.0" "--build_v8_with_gn=false"
10.37 gyp ERR! cwd /tmp/module
10.37 gyp ERR! node -v v14.21.3
10.37 gyp ERR! node-gyp -v v10.0.1
10.37 gyp ERR! not ok
------
executable.Dockerfile:112
--------------------
 110 |     RUN ./node_builder_musl_env.sh
 111 |     COPY scripts/build_node_package.sh .
 112 | >>> RUN ./build_node_package.sh
 113 |
 114 |     # building bcc along with helpers
--------------------

bleh, will fix in a different PR

Merged https://github.com/Granulate/gprofiler/pull/858 so the build will pass and the tests run.


🔧 vue3 composition api pages

part of #4750

remove ExperimentMixin
vue3 composition /:prefix/collection/:id/activity page
vue3 composition /:prefix/explore/items page
vue3 composition /:prefix/explore/collectibles page
vue3 composition /identity page
vue3 composition /sustainibility page

edit: DRAFT doesn't work yet

Looks good sir

did not find any strange behavior or different console warnings compared to canary on those pages

As suggested by @roiLeo, i'm testing share preview on the modified pages
Problems encountered so far:
https://deploy-preview-6379--koda-canary.netlify.app/bsx/collection/1194754914/activity

As suggested by @roiLeo, i'm testing share preview on the modified pages
Problems encountered so far(telegram, discord): https://deploy-preview-6379--koda-canary.netlify.app/bsx/collection/1194754914/activity

I've made some test and it's not related with this PR, preview doesn't work for url starting with deploy-preview-...
Tested on https://deploy-preview-6380--koda-canary.netlify.app/bsx/collection/1194754914/activity

I've made some test and it's not related with this PR, preview doesn't work for url starting with deploy-preview-... Tested on https://deploy-preview-6380--koda-canary.netlify.app/bsx/collection/1194754914/activity

Good to know! thank you

works well now


draft: support for backend list

Builds backend_list from a list of backend dicts
GUI: Adds support to show 6 backends
GUI: Adds icon for ovos and neon backends
WIP

also add the new icons to assets repo please


@cds/react components fail to import with Webpack 5

Describe the bug
Webpack 5 (released in Oct. 2020) introduced a lot of breaking changes and seems to fail to bundle @cds/react imports. Webpack 4 seems to bundle without problems.
How to reproduce
Run the following commands to create a new project that imports a single cds component:
mkdir -p repro/src && cd repro
npm init -y
npm install webpack webpack-cli @cds/react
# @cds/core and react are not installed because they're not needed to reproduce this issue
echo "import { CdsAlert } from<EMAIL_ADDRESS>" > src/index.js
npx webpack  --mode=production

Running the above gives me the following output:
assets by status 103 KiB [cached] 1 asset
orphan modules 345 KiB [orphan] 143 modules
./src/index.js + 109 modules 309 KiB [built] [code generated]

ERROR in<EMAIL_ADDRESS>3:0-61
Module not found: Error: Can't resolve '../converter/react-wrapper' in '/Users/ben/git/repro/node_modules/@cds/react/alert'
Did you mean 'react-wrapper.js'?
BREAKING CHANGE: The request '../converter/react-wrapper' failed to resolve only because it was resolved as fully specified
(probably because the origin is a '*.mjs' file or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
resolve '../converter/react-wrapper' in '/Users/ben/git/repro/node_modules/@cds/react/alert'
  using description file<EMAIL_ADDRESS>(relative path: .)
    Field 'browser' doesn't contain a valid alias configuration
    using description file<EMAIL_ADDRESS>(relative path: ./react-wrapper)
      Field 'browser' doesn't contain a valid alias configuration
      /Users/ben/git/repro/node_modules/@cds/react/converter/react-wrapper doesn't exist
 @ ./src/index.js 1:0-52

webpack 5.24.4 compiled with 1 error in 1855 ms

Expected behavior
A successful bundle
Versions
Clarity project:

[ ] Clarity Core
[ ] Clarity Angular/UI

Clarity version:

[ ] v3.x
[ ] v4.x
[x] v5.x

Framework:

[ ] Angular
[x] React
[ ] Vue
[ ] Other:

Framework version:
Tried with and without React 17
Device:

Type: MBP
OS: macOS 10.15.7

Additional notes
The error message seems to describe exactly what's needed: when I change line 3 of @cds/react/alert/index.js like this, it fixes this particular import:
- import { createComponent } from '../converter/react-wrapper';
+ import { createComponent } from '../converter/react-wrapper.js';

Cool, that was fast!


Browse page: Content enhancement - rewrite the intro

Which page is this about?
https://cfpb.github.io/design-system/pages/browse-pages
What kind of issue is this?
Add one or more of the issue labels below to the right-hand sidebar AND issue title.
(We strongly encourage you to make content changes yourself where possible!)

[ ] Info incorrect
[x] Content enhancement (e.g. confusing or redundant content, small content items need to be added, etc.)
[ ] Needs content written (page is missing key information, e.g. use cases)
[ ] Needs code snippet
[ ] Overhaul page (page needs large-scale content rewriting and restructuring)
[ ] Something else (please explain)

Describe your issue

Intro could use some plain languaging. Should make clearer that left hand nav always appears on these pages.

Size this request (1=tiny, 5=enormous)
1
Add any additional background info as needed
Make sure NOT to include internal links.
Thanks. Don't forget to add labels indicating issue type and size before submitting!
Once you've submitted your issue, please add it to the content backlog project board: https://github.com/cfpb/design-system/projects/1

Yay! https://github.com/cfpb/design-system/pull/1142

Yay! https://github.com/cfpb/design-system/pull/1142


[Bug]: Reading the file failed, and the cfs-client log reported "super.go:405: Flush: ino(318538) err(bad file descriptor) and Get node cache failed: ino(16927248)"

Contact Details
No response
Is there an existing issue for this?

[X] I have searched all the existing issues

Priority
low (Default)
Environment
- CubeFS version: 3.3.0
- Deployment mode(docker or standalone or cluster):
- Dependent components:
- OS kernel version(Ubuntu or CentOS): Ubuntu 20.04.4 LTS
- CPU/Memory:
- Others:

Current Behavior
During the process of compiling the code, reading the file failed.
Expected Behavior
No response
Steps To Reproduce
No response
CubeFS Log
2023/11/29 17:07:05.029505 [ERROR] file.go:507: TRACE Flush err: ino(34263044) err(bad file descriptor)
2023/11/29 17:07:05.336461 [ERROR] extent_client.go:508: Read: stream is not opened yet, ino(318538) offset(0) size(4096)
2023/11/29 17:07:05.336508 [ERROR] super.go:405: Read: ino(318538) req(Read [ID=0xfdd310 Node=0xac3 Uid=51266 Gid=51266 Pid=2674155] 0x81 4096 @0x0 dir=false fl=0 lock=0 ffl=OpenReadOnly) err(bad file descriptor) size(0)
2023/11/29 17:07:05.336586 [ERROR] extent_client.go:508: Read: stream is not opened yet, ino(318538) offset(0) size(4096)
2023/11/29 17:07:05.336645 [ERROR] super.go:405: Read: ino(318538) req(Read [ID=0xfdd316 Node=0xac3 Uid=51266 Gid=51266 Pid=2674155] 0x81 4096 @0x0 dir=false fl=0 lock=0 ffl=OpenReadOnly) err(bad file descriptor) size(0)
2023/11/29 17:07:05.340646 [ERROR] extent_client.go:493: Flush: stream is not opened yet, ino(318538)
2023/11/29 17:07:05.340652 [ERROR] super.go:405: Flush: ino(318538) err(bad file descriptor)
2023/11/29 17:07:05.340657 [ERROR] file.go:507: TRACE Flush err: ino(318538) err(bad file descriptor)
2023/11/29 17:07:05.973957 [ERROR] extent_client.go:493: Flush: stream is not opened yet, ino(55612111)
2023/11/29 17:07:05.973971 [ERROR] super.go:405: Flush: ino(55612111) err(bad file descriptor)
2023/11/29 17:07:05.973976 [ERROR] file.go:507: TRACE Flush err: ino(55612111) err(bad file descriptor)
2023/11/29 17:07:05.974243 [ERROR] extent_client.go:508: Read: stream is not opened yet, ino(34263044) offset(0) size(4096)
2023/11/29 17:07:05.974308 [ERROR] super.go:405: Read: ino(34263044) req(Read [ID=0xfdfa78 Node=0xd69 Uid=51266 Gid=51266 Pid=2674186] 0x42 4096 @0x0 dir=false fl=0 lock=0 ffl=OpenReadOnly) err(bad file descriptor) size(0)
2023/11/29 17:07:05.974393 [ERROR] extent_client.go:508: Read: stream is not opened yet, ino(34263044) offset(0) size(4096)
2023/11/29 17:07:05.974411 [ERROR] super.go:405: Read: ino(34263044) req(Read [ID=0xfdfa7a Node=0xd69 Uid=51266 Gid=51266 Pid=2674186] 0x42 4096 @0x0 dir=false fl=0 lock=0 ffl=OpenReadOnly) err(bad file descriptor) size(0)
2023/11/29 17:07:05.976486 [ERROR] extent_client.go:493: Flush: stream is not opened yet, ino(34263044)
2023/11/29 17:07:05.976495 [ERROR] super.go:405: Flush: ino(34263044) err(bad file descriptor)
2023/11/29 17:07:05.976502 [ERROR] file.go:507: TRACE Flush err: ino(34263044) err(bad file descriptor)
2023/11/29 17:23:13.512579 [ERROR] file.go:121: Get node cache failed: ino(16927248)
Anything else? (Additional Context)
No response

cfs-client.err.zip

find . -inum 318538
./.ldm/x86_64-conda-linux-gnu/sysroot/usr/include/bits/wordsize.h
^C
  less ./.local/miniconda3/envs/trtllm/x86_64-conda-linux-gnu/sysroot/usr/include/bits/wordsize.h

There is no problem in checking this file directly according to the log error report.

@bboyCH4 please check this out


SES module init

what

terraform SES module that creates domain identity, IAM user that can send emails and optionally verification DNS records in Route53

why

Use SES to send transactional emails from services that need an SMTP gateway (e.g. Sentry)

/codefresh run test

/rebuild-readme

/terraform-fmt

/codefresh run test


How to install it in Vue-Cli?

Are you reporting a bug or requesting a feature?

Bug / Question

What is happening?

I'm trying to install your plugin using npm.
Unsure the proper process in installation...

What is the expected behaviour?

No errors
I thought it was simple???

Which version of LazyLoad are you using?

Latest version

In which browser(s) and browser version(s) are you experiencing the problem?

Latest Chrome

Thank you.

Sorry @nnagewad, I'm failing to understand what you're asking here.
Maybe you can ask a more specific question?

@nnagewad, I'm assuming you solved after months of inactivity. Feel free to reopen the issue if you still need help.


Fails in combination with Node interface

In my application I am adding the Node interface via a custom directive:
    $nodeType = Parser::parseType(GlobalIdServiceProvider::NODE, [
      'noLocation' => true,
    ]);
    assert($nodeType instanceof NamedTypeNode);
    $objectType->interfaces[] = $nodeType;

Unfortunately, this causes issues in this call because the Node interface is not yet known:

The Node interface is only available later on:
https://github.com/nuwave/lighthouse/blob/d4ea07d61f1a0254bc979ab0d20ab33730edbd85/src/GlobalId/GlobalIdServiceProvider.php#L28-L37

Do you mean "TypeDefinitionUnknown: Type Definition Node is not defined." error? This is expected - type should be known before transformation, because types of the fields may not be updated correctly and the schema will be invalid :(
You can try to override GlobalIdServiceProvide to call GlobalIdServiceProvider::addNodeSupport() manually before transformation. Or you can define input with required (same) fields without the GlobalIdServiceProvider::NODE interface and use it as argument type: field(where: MyInput @searchBy): MyType).
Maybe @spawnia can suggest something too.

this call

Which call? Where?

If I understand the issue correctly: when @node used it will automatically add interface Node, but the Node is not available in the schema yet (it will be added later via GlobalIdServiceProvider) and @searchBy/@sortBy will fail:
type Query {
  users(where: _ @searchBy): [User!] @all
}

type User @node {
  id: ID! @globalId
}

@jaulz , right?

@LastDragon-ru almost... except for that the query is on another type, something like this:
type Query {
  users: [User!] @all
}

type User @node {
  id: ID! @globalId
  emails(where: _ @searchBy): [Email!] @all
}

type Email @node {
  id: ID! @globalId
}

@spawnia sorry, "this call" referred to the screenshot and is about getNodeInterfaces: https://github.com/LastDragon-ru/lara-asp/blob/4e0b2abda5850766bc8feb25c8e3ab876ce4c9ce/packages/graphql/src/Builder/Directives/HandlerDirective.php#L242
It reads the interfaces of the given node and expects them to already exist.
So yeah, I could of course register the type manually before but I thought that it would not be the optimal solution 😊

which is the parent node!

Otherwise it will fail if
type User implements UserInterface {
  emails(where: _ @searchBy): [Email!] @all
}

interface UserInterface {
  emails(where: _): [Email!] # <-- fields will be incompatible
}

Or you can define input with required (same) fields without the GlobalIdServiceProvider::NODE interface

Seems it will not work :(

Fix released with https://github.com/nuwave/lighthouse/releases/tag/v6.6.1.

@spawnia thank you :)


python-periphery Control step-by-step motor problems

My expected function is to control the stepper motor to move step by step, the motor stops after 15 steps,but the result of the test is that the motor cannot stop.
I use the following code:
from periphery import PWM,GPIO
import time
pwm = PWM(0, 0)
def duty(angle):
duty_cycle = ((0.0550)+(0.1950*angle/180))/100 #frequency=50
return duty_cycle
for angle in range(0,181,15):
dc = duty(angle)
pwm.duty_cycle = dc
print('{},{}'.format(angle , dc))
time.sleep(1)
pwm.close()
print('end')

@LINYOUWEI0804 hey!
Could you reformat the code? It's very hard to tell what exactly it is doing without spacing especially in python.
FYI: This is a better question for [python-eriphery as we didn't write that library!
Closing for now, but I can continue to give suggestions on this threads.

The frequency parameter can adjust the speed of the stepper motor, so which parameter can adjust the number of pulses

Encountered the same error：OSError: [Errno 22] Invalid argument
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "x1.py", line 12, in
pwm.frequency = b+i
File "/usr/local/lib/python3.7/dist-packages/periphery/pwm.py", line 270, in _set_frequency
self.period = 1.0 / frequency
File "/usr/local/lib/python3.7/dist-packages/periphery/pwm.py", line 228, in _set_period
self.period_ns = int(period * 1e9)
File "/usr/local/lib/python3.7/dist-packages/periphery/pwm.py", line 179, in _set_period_ns
self._write_channel_attr("period", str(period_ns))
File "/usr/local/lib/python3.7/dist-packages/periphery/pwm.py", line 118, in _write_channel_attr
f_attr.write(value + "\n")
OSError: [Errno 22] Invalid argument
I run this code :
from periphery import PWM
pwm = PWM(0, 0)
b=1
for i in range(0,100,2):
pwm.frequency = b+i
pwm.duty_cycle = 0.75
pwm.enable()
pwm.duty_cycle = 0.50
pwm.disable()
pwm.close()
Line 4 of the code 「 for i in range(0,100,2):」  This error occurs as long as the third parameter is not 1,If it is 1, you can make the motor rotate normally.Is this problem caused by the frequency suddenly being too large?

Does this problem still occurs if you keep the frequency at constant?

At first, if the value is too large, an error will occur.For example, give 200, but give 50 without problems,If you want to give a value of 200, you can only start from 50, and then the program value is changed to 60, 70 and slowly change to 200 before there will be no errors.


[INLONG-7958][Sort] Fix MongoDB's schema becomes unordered after extracting the row data

Prepare a Pull Request
[INLONG-7958][Sort] Fix MongoDB's schema becomes unordered after extracting the row data

Fixes #7958

Motivation

MongoDB's schema becomes unordered after extracting the row data

For all database migration, Mognodb CDC does not specify a primary key, so upsert cannot be implemented. Refer to https://ververica.github.io/flink-cdc-connectors/master/content/connectors/mongodb-cdc.html, we should specify _id as the default primary key.

MongoDB’s change event record doesn’t have updated before message. So, we can only convert it to Flink’s UPSERT changelog stream. An upsert stream requires a unique key, so we must declare _id as primary key. We can’t declare other column as primary key, because delete operation does not contain the key and value besides _id and sharding key.

Modifications

Use LinkedHashMap instead of HashMap to make the schema ordered.
Use _id as the default primary key
Refactor the code

@e-mhui Why to keep schema order? I suggest that add reason.

@e-mhui Why to keep schema order? I suggest that add reason.

The sink (e.g. iceberg) automatically builds the table, and the source schema being shuffled during the synchronization process will result in inconsistent schema order between source and sink.

@e-mhui Why to keep schema order? I suggest that add reason.

The reason has been added to the description.

@e-mhui Why to keep schema order? I suggest that add reason.

The sink (e.g. iceberg) automatically builds the table, and the source schema being shuffled during the synchronization process will result in inconsistent schema order between source and sink.

look good to me


Flowtypes not working

Hey guys, I am getting an error on Flowtype. I also added "flow" present to .babelrc but none of them works.

My fault, I was using .jsx files, but babel-loader's regex in webpack config was only matching .js. This might be an issue as well.
Fixed with:
module.exports = {
    modify: (config, { target, dev }, webpack) => {
        config.module.rules[1].test = /\.(js|jsx)$/;
        config.module.rules[0].test = /\.(js|jsx)$/;
        return config;
    },
};

We fixed this already but we have yet to release a new version

Released


Large(64 bit) integers

In terms of 64 bit integers, I found a 'strange' behavior of Freddy. Here's my test code:
    do { // big integer test
        let str = "{\"value\":<PHONE_NUMBER>415}"
        let data = str.data(using: .utf8)
        let jsonObj = try JSON(data: data!)
        let value = try jsonObj.getInt(at: "value") // getting big integer as Int causes error
        print("int value: \(value)")
    } catch {
        print("error: \(error)")
    }
    do { // small integer test
        let str = "{\"value\": 1467}"
        let data = str.data(using: .utf8)
        let jsonObj = try JSON(data: data!)
        let value = try jsonObj.getInt(at: "value") // getting small integer as Int works fine
        print("int value: \(value)")
    } catch {
        print("error: \(error)")
    }
    do { // big integer as string test
        let str = "{\"value\":<PHONE_NUMBER>415}"
        let data = str.data(using: .utf8)
        let jsonObj = try JSON(data: data!)
        let value = try jsonObj.getString(at: "value") // getting big integer as String worked unexpectedly
        print("string value: \(value)")
    } catch {
        print("error: \(error)")
    }

And I get this result:
error: valueNotConvertible(1467675897415, Swift.Int)
int value: 1467
string value:<PHONE_NUMBER>415

It seems that Freddy parses big integers as Strings, and I guess it might have to do something with the old 32bit iOS hardwares. Any suggestion on how to deal with integer sizes?
[UPDATE] Actually, I was running the test code in the 32bit hardware simulator. When I ran it later with the latest hardware simulator(iPad Pro), Freddy did parse the big integer as Int and there was no error. It still raises a question though. How do I manage to work with both 32 and 64 bit platforms? I wish there were something like getInt64() method for the cases where I'm sure that the value is in the range of 64 bit integers.

This is intentional if the value doesn't fit into Swift's Int (which as you mention in your update, it doesn't on a 32-bit device). There is some background/rationale in the discussion on #76.
I could see an argument for something like a getInt64(). For now, though, your current options are:

Handle the conversion to Int64 yourself (try to get the value as an Int, catch the value not convertible error and try to get the value as a String, converting either to Int64)
Treat the value as a String regardless of the platform you're running on. If the value is something like an ID that you don't need to do any math on, this might be the most straightforward solution.


Allow mockServer to mock mutations

Hello !
I'm successfully using mockServer to test my queries, but now I need to test my mutations.
I found this, confirming this is possible but I can't find a proper way to implement it (Source)
My attempts :
this.mockServer.query(`
    mutation updateItem (id: 1, title: "Test") {
        id, title, price
    }
`).then(....)

... gives ...
GraphQLError: Cannot query field "mutation" on type "Query"
this.mockServer.mutation(`
    updateItem (id: 1, title: "Test") {
        id, title, price
    }
`).then(....)

...gives...
GraphQLError: this.mockServer.mutation is not a function
this.mockServer.query(`
    updateItem (id: 1, title: "Test") {
        id, title, price
    }
`).then(....)

...gives...
GraphQLError: Cannot query field "updateItem" on type "Query"
None of them worked.
Outside of the mock server context, my mutation works perfectly.
Thanks in advance for your help.

I think you might be misunderstanding GraphQL - try copying a mutation example from GraphQL.org.

@stubailo Care to explain?
Because I too am a bit lost and don't see the problem going on here, for it seems to be a proper usage of the mockServer from graphql-tools

I think this would be a better question for stackoverflow, since it isn't an issue with the library per se.

wow was it so hard to just answer to wrap the query like this?
this.mockServer.query(`mutation {
  updateItem (id: 1, title: "Test") {
    id, title, price
  }
}`);

help your bros out guys ✌


added option to use additional custom modules in config

As we (Dynatrace) want to be able to inject custom modules into the configuration file, i added a step that reads the environment variable "CUSTOMMODULES" and looks for them.
Format of the config in the variable is "modulename,modulepath;modulename,modulepath;...". So, for example, CUSTOMMODULES might be set to "yourModule,C:\path\to\module.dll"
I tried to keep it as generic as possible, so others can use that option as well. And i also added a basic integration test for the functionality.

Hey arthfl,
Thanks again for the PR and the recent offline discussion. I've been hacking through a reference implementation since then using this feature and I realize it won't work older Cloud Foundry (older than late March 2018) due to this bugfix which enable proper environment variable support.

Lastly, I think that having just files on the in the app directory or buildpack directory might make local debugging a bit more consistent - if have your app running in IIS or IIS Express locally, all you'd need to do is copy the files into the right place, then cf push them up with a new app... no need to run cf push --no-start ..., cf set-env CUSTOMMODULES ..., cf start ...

Hey @danirabiser @arthfl . We're starting on the change now. We gathered some feedback from other buildpacks teams and it looks like we'll modify the PR a bit but will build on the change you introduced.
Our Pivotal Tracker is here if you want to follow our progress: https://www.pivotaltracker.com/story/show/162561949

Hey @danirabiser @arthfl,
My name is Steve. I have been working with @micahyoung on extending your contributions to be the first release of Native Modules support described above. These changes can be utilized via the latest version of the HWC Buildpack (https://github.com/cloudfoundry/hwc-buildpack/releases/tag/v3.1.3).
We have written a bit of documentation describing how to pull in Native Modules via the HWC_NATIVE_MODULES environment variable located here: https://github.com/cloudfoundry/hwc-buildpack/wiki/HWC-Native-modules-via-extension-buildpacks
When you have a moment, could you follow the documentation and pull in your agent DLL to confirm that this will resolve this issue?
Thanks,
Steve


Add function to set authorized issuers

Objective
We need to allow the authorization and revocation of multiple issuers simultaneously in the Vault contract. This will be achieved via a authorize_issuers function.
Checklist

[ ] Update the authorize_issuer to authorize an issuer.
[ ] Update the revoke_issuer to remove an issuer.
[ ] Create a new function authorize_issuers that should receive the list of addresses representing the authorized issuers.
[ ] Update documentation.

Released in v0.15.0


Bug with maximizing window when "Automatically hide the taskbar in desktop mode" is "on" on Windows10

VSCode Version: 1.40.1 (system setup) [8795a9889db74563ddd43eb0a897a2384129a619]
OS Version: Windows_NT x64 10.0.18363

Steps to Reproduce:

Update your VSCode to 1.40.0.
Switch "Automatically hide the taskbar in desktop mode" to "on" on your Windows10.
Make sure that "Window: Title Bar Style" of your VSCode is "custom".
Maximize the window of your VSCode.
Then, you may reproduce the bug like ones in following gifs.

Can't call taskbar by sliding the mouse to the edge of the screen, until you press the "Windows" key on keyboard.

Bad "maximize" button, but the window would work normally when double click on title bar.

Does this issue occur when all extensions are disabled?: Yes
P.s. In fact the first bug also could be reproduced on some of other softwares which based on electron.js, but before I updated to 1.40.0, VSCode didn't have this problem, may be you could fix it. 😊

duplicate of #81102
Please always search before posting new issues.

duplicate of #81102
Please always search before posting new issues.

Yep, I have got it, vscodebot has told me that and I would do as you told me in the future (I really have searched related issues, but I am not familiar to the usage of issue search and I used keyword which is not suitable, so... I am sorry 😓).
But this issue is more like with #84342 than #81102.

But this issue is more like with #84342 than #81102.

Yes, you are right, sorry I didn't read your issue carefully.

Yes, you are right, sorry I didn't read your issue carefully.

That's all right. And thanks for your contributions. 😀

The root cause is same for all these issues, I am merging them together. Thanks for the report!
/duplicate https://github.com/microsoft/vscode/issues/81102


depth

How to use "depth" option?
this is in my plan:
  - get: pullrequest
    version: every
    params:
      depth: 20
    trigger: true

But when it checks for new PR, it checks all old PRs (hundreds in my case), I need to check only last 20..

I found what I was looking for here: https://github.com/ywei2017/concourse-bitbucket-pullrequest-resource


Port 9199 conflicts with officially supported Cloudflare exporter

Per https://github.com/prometheus/prometheus/wiki/Default-port-allocations, port 9199 is reserved for the Cloudflare Exporter. This GraphQL Exporter should coordinate with Prometheus to reserve a unique port in order to avoid conflicts.

This is actually on purpose.
This exporter began as a Cloudflare exporter with a wider scope than wehkamp/docker-prometheus-cloudflare-exporter, which only works for Enterprise plans.
Some months into it, Cloudflare deprecated their old analytics API in favor of its new GraphQL one.
By adapting my old Cloudflare exporter to the new GraphQL API, I figured it'd be more versatile to just write a generic GraphQL exporter, which could be then used for Cloudflare or anything else.
In any case, changing the port now will break everyone's integration.
If there's conflict, I suggest you modify the EXPORTER_LISTEN_ADDR environment variable:
export EXPORTER_LISTEN_ADDR="<IP_ADDRESS>:12345"


[fix-dns64-install] correctly update bind9 configuration

Codecov Report

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

@@           Coverage Diff           @@
##           master     #209   +/-   ##
=======================================
  Coverage   87.13%   87.13%
=======================================
  Files          39       39
  Lines        2317     2317
=======================================
  Hits         2019     2019
  Misses        298      298

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 aad361b...63f6e0a. Read the comment docs.


Refactor duplicated ConfigMap code

With the introduction of Vector metrics collection, we have added duplicated code around handling of ConfigMaps. Duplicate code increases the maintenance burden, so it would be good to try to consolidate some of that code.
For example:
We have this to deal with Vector ConfigMaps  for Cassandra:
https://github.com/k8ssandra/k8ssandra-operator/blob/main/controllers/k8ssandra/vector.go#L19
And this to deal with them for Stargate:
https://github.com/k8ssandra/k8ssandra-operator/blob/main/controllers/stargate/vector.go#L22
And are about to duplicate it again for Reaper:
https://github.com/k8ssandra/k8ssandra-operator/pull/838/files#diff-49b4878a0509bc364d174219a6906417836a62323a8fef85c0cd2b035c42635dR22

This one needs to wait for https://github.com/k8ssandra/k8ssandra-operator/issues/827.


Add generic key:value store into Zarf

As a package developer, I want Zarf to remember variable values from a zarf package deploy and make them available to future zarf package deploy actions so that engineers do not need to specify variables on subsequent deploys.
As a package developer, I want Zarf to remember component outputs from a zarf package deploy and make them available to future zarf package deploy actions so that components can share information with future components in a single Zarf package or between Zarf packages.

Incorporating a key:value store in Zarf can satisfy both user stories above. During a zarf package deploy, a golang map[string]string is instantiated and Zarf attempts to populate it from a Kubernetes secret. If the secret does not exist, the map remains empty. While the Zarf package deployment workflow is executed, variables and their values are stored in the map. Optionally, components can publish additional values to the map and also consume values from the map using the standard ###ZARF_PKG_VAR...### nomenclature. When the Zarf deployment workflow is coming to an end, the contents of the map are written to a Kubernetes secret.

Part of the idea around config files was the ability to re-run the variables consistently without managing command flags. Curious how that plays into this idea.


552 max slice

Coverage increased (+0.04%) to 66.738% when pulling 81621e07b20855e31c9caebb65afba3e321b2702 on linhvo:552-max-slice into f3d0aec46d3fdf9d8d005de120a1c31ec67077d3 on pilosa:master.


Allow for jumping backwards.

Creates a jumpstack that allows for jumping backward until the jumpstack is empty.
Solving issue:
https://github.com/aeosynth/bk/issues/27

looks good, but can you make it go forwards as well? shouldn't be much more code

I can, I can.  Do you mean putting the other ' mark ocurrences as the stack?

it looks like you're not updating the ' mark when using the jump stack, that is not great behavior. opening vim it seems that their behavior isn't obvious to me either when using jump stack and the ' mark. we need to be clear on when it does and doesn't update. i'm not sure about the implementation, do whatever you like and i'll review.

my initial implementation thought was that ' could be a pointer to the stack, iow just the index number, but that might not be useful

@lsponzoni how's it going?

I think as a feature it is complete. I could refactor the code.
What do you think of it?


Date locale functions fail if Map is overridden

https://stackoverflow.com/a/44637643/646551
Steps to reproduce
Run the following code using ch.exe:
// var earlyDateString = new Date().toLocaleString();
Map = {};
var dateString = new Date().toLocaleString();

Expected result
dateString contains something like "20/06/2017 5:46:36 PM"
Actual result
TypeError: Intl is not available.
   at Global code (e:\my downloads\cc_windows_1_5_2\bin\x64_release\test.js:3:1)

Workaround
Uncomment the first line so Intl is initialised before Map is overridden.
Other browsers
Google Chrome: Not affected
Mozilla Firefox: Not affected

Probably regression from #2358

Yep, looks like tainting affected the maps being used in the caches which caused Intl to fail to initialize. The fix is probably to expose a platform.Map and use new platform.Map() instead of new Map().

I have a fix. Will post the PR momentarily.


How to realize simulation

Demo of MPC using gazebo simulator and audibot car

This is on my todo list. This repository is a mirror of a gitlab repository for the student organization DNV Fuel Fighter. The simulator is another repo on gitlab. However this is currently a bit of a mess. I'm working towards cleaning this up and making a github repo for it.
In the meantime I can describe how to do it yourself. The simulator used is Gazebo and the audibot repo is used to simulate the car. The modifications done are as follows:

Publishes current steering angle. You could also skip this and just publish "0.0" on the desired topic. However, this will effect performance.
control system for audibot. I have implemented at control system for the car that takes in a cmd_vel message and figures out what the steering angle and throttle should be. I made this using a PID controller and the bicycle model. It is also possible to publish the steering angle directly from the mpc and publish a constant value for throttle for example.

The goal is that the mpc should work for several simulators and most importantly in the real world.

Hi again @yinflight!
I have now merged the necessary chages of audibot into the orginal repo. So that is compatible with what data the MPC requires.
Follow these steps if you want to test the mpc.
1. Clone audibot
git clone https://github.com/robustify/audibot.git

2. Install mpc
Install the mpc as described in the readme.
3. Changed params
change actual_steering_topic to "/steering_state" and map_frame to "world" in params/mpc.yaml
4. Run
First run audibot using
roslaunch audibot_gazebo single_vehicle_example.launch

In another terminal you can run the mpc
roslaunch mpc_local_planner mpc.launch

Doing this the car should drive autonomously in a loop. Let me know if you have any issues.


Update Configure_matx.cmake

Fix for cmake
Description
closes #40
Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.

/merge


Misc error checking issues with certificate handling in edgexproxy

There is no error checking of the response code from vault. If there's an issue with accessing the certs from vault, there will be a non-200 response code and so before unmarshalling the body of the response we should be checking the response code. That would be done right after this bit of code:

https://github.com/edgexfoundry/security-api-gateway/blob/96482b5a8dbee3213916b39e23d37dd61c08bdda/core/certs.go#L63-L69

The error returned from Decode should be checked here and returned if non-nil:

https://github.com/edgexfoundry/security-api-gateway/blob/96482b5a8dbee3213916b39e23d37dd61c08bdda/core/certs.go#L72

The decoded JSON should be checked to see if the certificate and the key are non-empty as they could be empty from vault, or vault could have returned some other kind of JSON object in which case the decoding would have succeeded but resulted in an empty object. That kind of check should happen just after we decode the JSON object here:

https://github.com/edgexfoundry/security-api-gateway/blob/96482b5a8dbee3213916b39e23d37dd61c08bdda/core/certs.go#L72

The logger info should not be logging the cert at level Info, I think it should be a debug output, and there should be some labeling of what is being output here:

https://github.com/edgexfoundry/security-api-gateway/blob/96482b5a8dbee3213916b39e23d37dd61c08bdda/core/certs.go#L73

All of these things are now checked in https://github.com/edgexfoundry/edgex-go/pull/1537, so once that is merged I will close this


Add check to publish only when repository is "Qbeast-io/qbeast-spark"

Adding a simple check for the repository name to avoid running the sbt publish on the repository forks' CI. The syntax used is the one from GitHub Actions Quickstart.
Fixes #52

Seems good to me!

I can confirm it has been fixed. Publish step is not being executed on forks:
https://github.com/eavilaes/qbeast-spark/runs/4607461599?check_suite_focus=true


[stdlib] Uninline float description

May help with some code bloat caused by the new string interpolation.

@swift-ci please test

@swift-ci please benchmark

@tbkka I also removed some checks for inf that the C code was already handling. Be nice to remove the NaN check too but that results in more debug-style printing of nan that might not be desirable.

This would also mean we don't need to export swift_format_double

Build comment file:
Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Improvement

CStringLongAscii
3677
3282
-10.7%
1.12x

Code size: -O

TEST
OLD
NEW
DELTA
RATIO

Improvement

FloatingPointPrinting.o
7223
6583
-8.9%
1.10x

Performance: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

Array2D
6612
7208
+9.0%
0.92x

Improvement

CStringLongAscii
3540
3293
-7.0%
1.08x

Code size: -Osize

TEST
OLD
NEW
DELTA
RATIO

Improvement

FloatingPointPrinting.o
6576
5712
-13.1%
1.15x

Performance: -Onone

TEST
OLD
NEW
DELTA
RATIO

Improvement

ArrayOfPOD
847
758
-10.5%
1.12x

ArrayOfGenericPOD2
1179
1066
-9.6%
1.11x (?)

How to read the data
The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@swift-ci please benchmark

@swift-ci please test

@swift-ci please benchmark

@swift-ci please test

Build comment file:
Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

IterateData
1720
1905
+10.8%
0.90x (?)

Code size: -O

TEST
OLD
NEW
DELTA
RATIO

Improvement

FloatingPointPrinting.o
7223
6583
-8.9%
1.10x

Performance: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

Array2D
6612
7208
+9.0%
0.92x

Code size: -Osize

TEST
OLD
NEW
DELTA
RATIO

Improvement

FloatingPointPrinting.o
6576
5712
-13.1%
1.15x

Performance: -Onone

TEST
OLD
NEW
DELTA
RATIO

Regression

RandomDoubleLCG
51076
63761
+24.8%
0.80x

How to read the data
The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

Build failed
Swift Test Linux Platform
Git Sha - 92f8f80aeb42e20b70538f136d5fb825199e8550

@swift-ci please clean test linux platform

Build failed
Swift Test Linux Platform
Git Sha - 92f8f80aeb42e20b70538f136d5fb825199e8550

Unrelated linux failures need #20036

Thanks for doing this!  When I initially did this, I was a little alarmed at the amount of inlining going on, but never got back to it.

@tbkka I also removed some checks for inf that the C code was already handling. Be nice to remove the NaN check too but that results in more debug-style printing of nan that might not be desirable.

Regular description and debugDescription differ only in NaN printing.  But you could handle that distinction further down in the code. Right now, I think the debug flag might be entirely ignored.

Cool. I'll merge this for now and we can revisit sinking the nan handling later, once it's not inlinable we have flexibility to do that whenever.

@swift-ci please test linux platform


ccblc cleanup

This PR contains no associated issue, but it addresses a couple of small outstanding enhancements.
First, it updates the conda environment to use pip install -e . for installing the local version of earthlib. This is important because it means the changes you make to your local code will be available every time you use import earthlib after making a change.
Better yet, when working with this code in jupyter notebooks, by using the following two lines (which are also implemented in notebooks/development-unmixing.ipynb ), you'll automatically reload the changes you make to your local code without having to re-run any notebook blocks.
%load_ext autoreload
%autoreload 2

The second updates below remove an old code block used for manually reloading extensions (which is no longer necessary), and I added some comments clarifying which sensor each version of visBands referred to.

@lingling-liu , there are two ways to implement this on your side. First is to re-create your conda environment (navigating to the root directory and running conda env update). This may take a long time, and create a duplicate environment, so I don't necessarily recommend it.
The other way is, once you have your environment activated, just navigate to the repository base directory and run pip install -e .. This will make it so your conda environment's python install is referencing your local code and you'll be able to more rapidly test changes you make.

@lingling-liu , there are two ways to implement this on your side. First is to re-create your conda environment (navigating to the root directory and running conda env update). This may take a long time, and create a duplicate environment, so I don't necessarily recommend it.
The other way is, once you have your environment activated, just navigate to the repository base directory and run pip install -e .. This will make it so your conda environment's python install is referencing your local code and you'll be able to more rapidly test changes you make.


Improve theme-related variables

Describe the problem to be solved
Hey there,
My goal with this issue is to maybe agree on some refactoring on theme variables. The actual endgoal is:

make it easier to create color themes
make it easier to style specific parts of the UI (related: #1054)
make it possible to customize UI more with themes

I want to do this because, with the recent discussion on colors, we will most likely end up with at least one new "high contrast" theme. The idea of a "grist original colors" theme has also been discussed (since we want to change the green used to improve contrast, this would let current users keep the colors they are used to). And, we could also imagine having a dark high contrast theme.
So, as @dsagal mentioned it in the other issue, maybe working on simplifying theme code first would be a good idea:

For any themes, I know @georgegevoian had some thoughts about drastically reducing the number of CSS variables that we have today, which should make multiple themes easier to maintain (e.g. as new components are added). @manuhabitela , let me know if you are interested in looking into that -- that sounds like more work upfront, but may save work later.

Describe the solution you would like
After recently discovering the CSS and theme code more, here are some thoughts:
1. Reduce the number of CSS variables in theme files
I'm wondering if there is particular reason that, in the current GristDark and GristLight theme files, all CSS variables are setup, instead of only the main color ones? From my understanding, most component-specific variables default to the main color variables.
If all theme props in the cssVars.ts file had fallbacks correctly setup to colors props (which is mostly the case besides white or black or few other hard-coded strings), would there be any issue in removing 90% of the code in GristDark and GristLight?
I feel this is the most impactful change we could make as some preparation step before creating new themes, amongst all the things I mention in this issue.
2. Add variables to allow more customization
This is not really my main issue here but since we're on this topic: how about, for some specific components, creating a few more variables, that would allow easier customization?
For example, for buttons, we could provide border-radius, box-shadow, font-weight variables. That would allow to easily match the Grist visuals to a specific design system when self-hosting.
This is an easy thing to do and I know it would be helpful (at least to GristGouv team ;)).
3. Component-specific variables: are they all necessary?
Disclaimer: genuinely asking, this is not a criticism ;)
What value do you see in having all the component-specific variables existing? Would there be any value in just keeping color variables, and then some core semantics variables (like the "control" variables for example), that components would directly consume?
I ask because my feeling is that for now, specific variables are created as a convention for every component.
But most variables just consume more globally used values, and for lots of use cases, we'll basically never want to customize a specific component. To insure some visual cohesion, I'd guess we want to allow to customize what a panel looks like; but do we want to allow to customize just one specific panel? Or, do we want to be able to customize inputs, without having selects following their style?
From my point of view I'd create component-specific variables only in the cases where I know that a component has value in being customized independently.
Example
For example, let's take the right tab header items (Table / Column):
Instead of defining their own rightPanelTabFg, rightPanelTabBg, rightPanelTabIcon and so on variables, they could directly consume some generic panel ones, using some new panelBg, panelFg. And directly use some already existing generic variables, like primaryBg or primaryFg.
:warning: Note that I'm not saying we should directly use color variables without any "semantic" variable in-between. Actually I think we should be careful about always having this semantic step to avoid issues like this. I'm suggesting: create more generic "semantic" variables and remove most specific ones.
There would be no more rightPanelTab*** specific variables, while keeping customization possible.
Customization would become "lighter", in the sense that now, you couldn't decide that a tab header has colors totally unrelated to its panel, or that the focused tab color is not the "primary color". But I feel this is kind of a good thing to have: to be able to customize the design as a whole rather than on each and every component?
My feeling is it would make the code more maintainable and approachable:

adding a component wouldn't mean an obligatory "add 5 css vars for this specific thing"
when looking at a component code, we would directly understand what part of the design system as a whole it consumes. Because we would see it uses "panel background" (this, I understand directly what it means), instead of "right panel tab background" (this, I must go see in the css vars file what it leads to).

I admit this wouldn't take 5 minutes to change and the impact wouldn't be that important. Feels more like a day-to-day "comfort" refactor than something that drastically improves the code.

What do you think about all this? I'm really interested in your point of view, especially the 3rd item.
My short term goal would to be work on the 1st item I mention here first, as I feel it would greatly help then adding new themes (like the high contrast one).
Thanks!

Hi @manuhabitela.
Thanks for taking this on.

If all theme props in the cssVars.ts file had fallbacks correctly setup to colors props (which is mostly the case besides white or black or few other hard-coded strings), would there be any issue in removing 90% of the code in GristDark and GristLight?

I don't think so. APP_STATIC_INCLUDE_CUSTOM_CSS is the only reason why the color props still exist (the fallback maintains backward compatibility by applying the styles from color props when themes are disabled, which is done automatically whenever that environment variable is set).
I had hoped to eventually remove the color props (or at least formally deprecate them), as they aren't particularly semantic, and make assumptions about colors (e.g. green as accent). But your plan to trim down the files sounds good to me, and maybe we can worry about the rest later.

This is not really my main issue here but since we're on this topic: how about, for some specific components, creating a few more variables, that would allow easier customization?

That's fine with me.

What value do you see in having all the component-specific variables existing? Would there be any value in just keeping color variables, and then some core semantics variables (like the "control" variables for example), that components would directly consume?

There's not much value in it, in my opinion. I'm 100% in agreement that a core set of semantic variables is the direction we should be going in instead.
Why component-specific variables exist is a long story, but the short answer is that it was done due to time constraints. The theme system as it exists today was created retroactively to add support for dark mode to Grist, and some of the decisions made were compromises in order to ship it sooner rather than later. In particular, deciding what the set of semantic variables should be, and how to incorporate them while maintaining the same look and feel of Grist proved challenging, and it was easier and faster to settle on a component-specific approach and give each component its own variable.
One of the problems is that Grist's current themes use too many close variations of some colors (gray, in particular), not all of which are even exported from the colors object. I think updates to GristLight and GristDark that reduce the color palette would help make it easier to settle on what the semantic variables should be. I briefly considered doing this back when working on dark mode and themes, but opted against it to avoid changing how Grist looked.

Hey, thanks for your comprehensive feedback.
Knowing all this, I'm starting to clean the current theme files.
That will allow us to have an actual view of what are the colors that are the "close variations" and the colors that are actual theme ones.
And I think just that first step will be a great starting point to have as an example for new themes.

Hey, sorry for the long time without news.
After digging into it, it's (obviously 🙃) less simple than I though.
Note: when I write something like cssVars.colors, I refer to the colors const from the app/client/ui2018/cssVars.ts file.
The most straight-to-the-point "fix" to be able to define a theme without having to setup hundreds of variables, from my understanding, would be to allow overriding cssVars.colors in a theme.
This would basically allow the behavior of using a custom.css file like we do in our instance, but in a theme. By directly overriding the colors and not the component-specific props, we could define a theme with like 30 color overrides instead of 400 component overrides.
But it's obviously pretty weird as themes could now work by saying stuff like color-light-green: blue. So, from my point of view, while it's an acceptable solution in the current custom CSS escape-hatch, it is not in the theme-related code.
If that sounds an acceptable solution for you right now, we could follow that route anyway. But I feel it's opening a weird door that allows creating themes faster for now but at a cost of a weird-to-maintain codebase.

Here is what I have in mind/trying to do right now. Sorry for the big wall of text, I feel like being precise is needed :)
1) CSS variables loading
Change the way the CSS variables are loaded in the DOM. Use CSS @layer rules to make sure that default, fallback CSS variables are loaded with the least priority, and theme-specific variables are loaded in a layer above it.
This eases up the way we can then override everything in a theme.
I have a commit ready for that that I think is already OK in the current codebase.
2) Make cssVars.colors just a fallback
Ditch cssVars.colors and prefer defining a fallbackColors or defaultColors, defined only in the case a theme can't be loaded.
Ideally, the codebase outside cssVars wouldn't consume these colors directly. In fact I'm thinking it wouldn't be exported. The few cases where we are 100% sure in the codebase we want to target colors, and not generic design-system tokens (like the ACL rules green/red flags), I think we should handle in step 3) described below.
3) Add new things in cssVars.vars
Sidenote: maybe rename cssVars.vars to be clearer of its new intent, like maybe designTokens or tokens. Kinda nitpicking here, vars is actually not an issue, but maybe it helps understanding my point right now and helps people understand better the intent, as I feel tokens is a word more commonly used for this.
So anyway. Have the cssVars.vars now contain new variables that act as a step between component-specific variables and default color variables. The same way it already defines control-specific colors, it would also list other globally used colors, like dialog colors, panel colors… About the ACL green/red example above, we could have "acceptColor" and "denyColor" tokens there.
This ties to the work on semantic variables you already talked about above. This might lead to some analysis-paralysis on "what are the good semantic variables to make" but I guess we can have a good, kinda dumb, first step of just abstracting the currently used colors without necessary making big decisions about actual specific meaning… I don't know.
By default, the props here would fallback to values from the default colors, like current cssVars.theme props.
3) Make cssVars.theme use cssVars.vars colors
Stop directly consuming colors there, but instead, consume the things in vars. Now the component-specific variables are tied to the actual design system as a whole instead of the default colors.
4) Allow overriding cssVars.vars in a theme
While allowing a theme to directly override colors is weird, I feel allowing a theme to change the global design system tokens is the solution.
This would allow defining a theme, not by listing the hundreds of component-specific variables anymore, but only the main "design system tokens and colors" we would add in step 3.
And it would allow having themes that do more than just changing colors: for an accessibility-specific theme, we could imagine wanting adding borders, increasing font sizes, disabling animations, setting a specific font, etc. I guess this asks the question of "is that really the role of a theme". I'd say it's okay?
5) Rename current cssVars.theme
With all this work, I feel all the component specific variables wouldn't be as much necessary as they are now. We could keep them for now to prevent having to rework everything. But maybe renaming this to cssVars.components, as most of the variables there are component-specific?
Or maybe my tokens renaming idea of  vars is not a good idea, and the better thing to do would be to just rename theme to components and vars to theme. As those would now be the main variables overriden by the theme?

And now a Theme would mostly allow customizing those design tokens, while still giving the possibility of overriding specific component variables if necessary. But maybe in a components prop, to show that it's not the intended way anymore.
GristLight.ts could look like this:
export const GristLight: ThemeColors = {
   'primary-bg': 'orange',
   'primary-fg': 'black',
   // […]
   components: {
      'modal-close-button-fg': 'red'
   }
}

So, what do you think @georgegevoian? :pray:

I'd be interested in seeing a proposal for what the pieces would be and how they'd fit together, with an example. Maybe picking some color used somewhere, and showing where it's defined (in what files / what blocks), and where the theme color and default/fallback (if needed) are set, and an example of how it's used in code.
Also, perhaps we don't really need default/fallback if we can ensure at build or testing time that we do have some expected complete theme(s)? (In case that makes things simpler?)

Great :)

Also, perhaps we don't really need default/fallback if we can ensure at build or testing time that we do have some expected complete theme(s)? (In case that makes things simpler?)

You are totally right. I actually just followed the few comments in the code saying some things were there "just in case" without going deeper, but yeah removing those default colors would make more sense.

:wave:

In fact, I'd suggest taking an incremental approach overall, regardless of how the trial run goes. (Perhaps adding at most a few new variables to cssVars.vars at a time in each PR; GristLight.ts would still ultimately end up looking like your example - it'd just take some unknown number of passes to replace all the component-specific variables.)

Your comment is making me think. Maybe I'm too greedy on this one indeed haha.
As we already pointed out, the whole "remove all the component specific variables" stuff, while interesting, is maybe more bonus material than actually a blocking/necessary change to move forward.
Maybe the better idea would be leave those variables as is and just to decide a few things:

new components should prevent creating specific variables and should consume global design tokens, to stop adding any new variable
mark current theme variables as "legacy" to explicitly tell in the code that those shouldn't be targeted first when writing themes (this is something I more or less done in the example PR)

But if we don't feel an important need to remove them all right now, maybe it just means it's not that big of a deal. The value we would get from this global change might not justify the cost it has.
My main goal right now is to be able to define/change a theme without having to think about 400+ hard-coded color values.
So, just having the part of "rework the global color vars so that they have abstracted names, and make them overridable by a theme" solves my problem. This would mean, lots of changes in cssVars, GristDark and GristLight files, but not much more anywhere else. So I could focus on that. I think that would an acceptable pull request as a whole.


[wip] Generating a DocSoucre class from a Document object

#45

Codecov Report

Merging #99 (e1fcc87) into master (0a2e7f8) will decrease coverage by 16.54%.
The diff coverage is 45.53%.

@@             Coverage Diff             @@
##           master      #99       +/-   ##
===========================================
- Coverage   84.09%   67.56%   -16.54%
===========================================
  Files          62       62
  Lines        6591     6619       +28
  Branches      703      702        -1
===========================================
- Hits         5543     4472     -1071
- Misses        800     1941     +1141
+ Partials      248      206       -42

Impacted Files
Coverage Δ

...in/dev/evo/elasticmagic/qf/AttrRangeFacetFilter.kt
74.50% <ø> (-23.00%)
:arrow_down:

.../kotlin/dev/evo/elasticmagic/serde/Deserializer.kt
29.85% <0.00%> (-2.99%)
:arrow_down:

...otlin/dev/evo/elasticmagic/ElasticsearchCluster.kt
4.41% <ø> (-85.30%)
:arrow_down:

...onMain/kotlin/dev/evo/elasticmagic/bulk/Actions.kt
0.00% <0.00%> (-45.95%)
:arrow_down:

...ev/evo/elasticmagic/compile/SearchQueryCompiler.kt
35.09% <0.00%> (-57.58%)
:arrow_down:

...onMain/kotlin/dev/evo/elasticmagic/doc/Document.kt
79.46% <50.00%> (-0.77%)
:arrow_down:

...ain/kotlin/dev/evo/elasticmagic/types/FieldType.kt
67.98% <50.00%> (-4.86%)
:arrow_down:

...monMain/kotlin/dev/evo/elasticmagic/SearchQuery.kt
69.16% <52.94%> (-27.32%)
:arrow_down:

...nMain/kotlin/dev/evo/elasticmagic/doc/DocSource.kt
70.64% <53.84%> (-6.66%)
:arrow_down:

...c/commonMain/kotlin/dev/evo/elasticmagic/Result.kt
20.94% <66.66%> (-74.33%)
:arrow_down:

... and 2 more

... and 27 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Update stable version in repo from 0.0.0 to 0.0.4

Think about adding version 0.0.4 to stable repository.
Version: stable=0.0.0 (0 days old) => latest=0.0.4 (255 days old)
Installs: stable=0 (0%), latest=111 (63.43%), total=175
Click to edit

@Newan
Fixing #13 is a requirment for stable repo addition


add streaming read retry for fast compaction

Is your feature request related to a problem? Please describe.
Currently fast compaction will not try to recreate the read stream like normal compaction based on compactor_iter_max_io_retry_times
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response

Before implementing stream reconstruction at the object store level, I added stream reconstruction as a workaround fix to the fast compactor iterator.

We can use a separate issue to track the changes to the object store behaviour and refactor the iterator-related code, but for now we can close the PR.


Update JSX.md for TS 2.2

This PR updates JSX docs for TS 2.2.
Specifically, it talks about the new react-native JSX emit mode.

(Sorry, I couldn't find a release-2.2 branch to target.)


why use conv2d rather than ConvTranspose2d in decoder?

I'm new in Pytorch, but I've found out in the autoencoder part, you use conv2d in decoder, I wonder why?
Also, if I increase epoch in training autoencoder, the AUC of ae will be larger than SVDD, does this mean ae is better than SVDD?

I agree that applying transposed convolutions using the ConvTranspose2d module in PyTorch is more appropriate for the decoder part of convolutional autoencoders.
I've updated the network architectures accordingly. Though there's not much of a difference in performance.


Recent brew list sysntax

*** Updating submodules...
*** Checking dependencies...
Error: Calling brew list to only list formulae is disabled! Use brew list --formula instead.

I'm not opposed to it, but right now my priority is to (try to) get a release out with updated dependencies, and I depend on CI handling iOS correctly, which #710 doesn't.
But this is so flaky it's not fun. I can usually build fine locally (at least #713 did, and on CI as well). But then #714's macOS build failed to test by failing to find headers 😭.


Should this be a package or a single-file module?

We could either have this as a mini-package on PyPI, or a single-file module, where the intent is that packages that need it can just bundle it. The use case I have right now is that:
https://github.com/astrofrog/cube-viewer
should be usable without glue installed, which it could do if I used the helpers here.
@ChrisBeaumont - any thoughts?

Why not both? There's nothing preventing us from using a single code file + a setup.py file to register on PyPI. I think the only difference is that a naked file gets copied into site-packages instead of a directory. So people could either pip install or easily copy the source file into their project.
This is what I did for https://github.com/chrisbeaumont/soupy

Good point! I can try and re-arrange it this way. What do you think about the name? Do you have any better suggestion than qt-helpers?

qt-helpers sounds good to me!

Done in d2cf40e9a70788b65769e783c2ac3cc50f8bc825


[DOCFIX] Link to Java setup page in Quick Start.

For easier navigation.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12873/
Test PASSed.


Add changelog entries for 0.5.0

Will assemble them here, so that we can just do one PR at the end.

#200,

- :support:`200` :class:`~galgebra.dop.Pdop` and :class:`~galgebra.dop.Sdop` instance are no longer associated with a Ga. As a result, their ``.Ga`` attribute no longer exists, and the :meth:`~galgebra.ga.Ga.pdop` and :meth:`~galgebra.ga.Ga.sdop` methods of :class:`~galgebra.ga.Ga` are deprecated in favor of calling the constructors directly.
  For Ga-aware operators, continue to use :class:`~galgebra.mv.Dop` .

Will assemble them here, so that we can just do one PR at the end.

:support:200 :class:~galgebra.dop.Pdop and :class:~galgebra.dop.Sdop instance are no longer associated with a Ga. As a result, their .Ga attribute no longer exists, and the :meth:~galgebra.ga.Ga.pdop and :meth:~galgebra.ga.Ga.sdop methods of :class:~galgebra.ga.Ga are deprecated in favor of calling the constructors directly.
For Ga-aware operators, continue to use :class:~galgebra.mv.Dop .

:support:216 galgebra.metric.test_init_slots has been removed. The functionality this provided is superceded by the language feature of keyword-only arguments.

:bug:319 :meth:galgebra.mv.Mv.get_coefs now returns 0 in the place of empty coefficients.

:bug:319 :meth:galgebra.mv.Ga.make_grad no longer has a broken cache that ignores cmpflg if both the left and right gradient operator are requested for the same vector

:bug:319 :meth:galgebra.mv.Ga.make_grad no longer crashes when called on an algebra with no :attr:~galgebra.ga.Ga.coords.


Difficulty getting framework to properly render on development server from <IP_ADDRESS>

I am developing my site on a remote server, so I need to be able to render the site on an address other than localhost. I have made the necessary changes to packages.json and added --bind <IP_ADDRESS> -b ./ --disableFastRender, yet still assets are referenced to localhost.
Is there a way to change this?

I have never tried developing live on a remote site. Did you put the live domain in baseURL: ''?

I use this command to develop on a remote server + VS code SSH plugin. No changes to package.json or hugo.yaml
sudo hugo server --bind <IP_ADDRESS> --baseURL http://<IP_ADDRESS>

Change <IP_ADDRESS> to your server IP

@nusserstudios It does the same thing with every theme

I use this command to develop on a remote server + VS code SSH plugin. No changes to package.json or hugo.yaml
sudo hugo server --bind [<IP_ADDRESS>](http://<IP_ADDRESS>) --baseURL http://<IP_ADDRESS>

Change <IP_ADDRESS> to your server IP

I was using -b ./. That works.


Stack trace for logged errors is useless

Describe the bug
When using +[Flurry logError:message:error:] to log errors the stack trace that is sent to Flurry doesn't contain the stack trace from where the error is logged.
We use the error logging because we want to have more information about what went wrong and which circumstances ultimately lead to the error. However, with the included stack trace that's impossible. It seems like Flurry does the error logging on a separate queue/thread and because of that the actual stack trace is lost.
The stack trace as it is reported is completely useless. At the very least the stack trace as returned by +[NSThread callStackSymbols] should be captured right where the +[Flurry logError:message:error:] method is called. This might not be a real stack trace as recorded by FlurryPLCrashReporter but is definitely more useful.
This Bug is About

[ ] Integration
[x] Analytics
[ ] Ads
[ ] Messaging/Push
[ ] IAP
[ ] Remote Configuration
[x] Flurry Website/Dashboard
[ ] Other

Platform

[x] iOS
[ ] tvOS
[ ] WatchOS

Environment

Flurry SDK: 10.0.2
XCode: 11.2 (11B52)
iOS: 13.2

To Reproduce
Steps to reproduce the behavior:

Integrate Flurry in an app
Call +[Flurry logError:message:error:] to log an error
Inspect the error on the Flurry website

Screenshots
Original stack trace:

Flurry Website:

Hello @fabiankr Thank you for using Flurry Analytics. We will investigate this issue and provide an update soon.

Hi @fabiankr, thank you for reporting this issue. The stack trace shown on Flurry website is only the partial report from original crash logs. You might download the full crash report by clicking export button on the same page.

@yhantao Thank you for the clarification! Indeed the full report contains the relevant stack trace.
Any chance that the preview on the Flurry website can show the correct thread instead of the thread where the crash report is collected in the future?

@fabiankr We will looking into fixing this issue on the developer portal as well. I cannot provide a timeline on when that may happen but will certainly keep you posted.

@rajkaur01 This issue was closed but it was not actually resolved. The behaviour is still as described by @fabiankr .
Will this be fixed?

@fabiankr @guillerodriguez, sorry for the late response, we have made the fix to capture the full stacktrace from client's thread and the fix will be out with the next GA release in March.


Datasets not reshuffling between epochs in eager mode

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): 10.14
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 1.13.0-dev20190227
Python version: 3.7

Describe the current behavior
Iterating a shuffled dataset returns elements in the same order each time it is iterated over, and the order is unaffected by the random seed.
Describe the expected behavior
The order should be deterministic given the random seed, and there should be a way to reshuffle between epochs.
Code to reproduce the issue
import tensorflow as tf

tf.enable_eager_execution()

d = tf.data.Dataset.range(5).shuffle(5)
tf.set_random_seed(0)
elems = [item.numpy() for item in d]
print("First epoch: ", elems)
elems = [item.numpy() for item in d]
print("Second epoch: ", elems)

Running this twice produces:
First run:
First epoch:  [4, 2, 1, 3, 0]
Second epoch:  [4, 2, 1, 3, 0]

Second run:
First epoch:  [3, 1, 0, 2, 4]
Second epoch:  [3, 1, 0, 2, 4]

So even though the same random seed is used in both runs, the order of elements differs between them. And additionally, the order is the same between epochs, which you wouldn't necessarily want in your training loop.

Actually, it looks like this is all explained by d.shuffle caching the random seed when it's called instead of when the dataset is iterated over. That seems a bit strange since it means I need to recall shuffle at the start of each epoch and so eg passing a dataset to Keras's fit method is going to use iteration over for every epoch.

Thanks for reporting this problem! This is definitely surprising behavior, and we should find a way to make it easier.
@rohan100jain Do you think it would be possible to extend your solution from b397935bae2530e1cf5022ca6f85a0b898a795d6 to work as expected in the eager case?
Also CCing @wangpengmit because whatever happens here ought to be compatible with [https://github.com/tensorflow/community/blob/master/rfcs/20181217-tf2-random-numbers.md](the TF 2.0 randomness interface), and @jsimsa FYI.

This still occurs in tf2.0.0-beta1. In my case I have a multitask training scenario where the training set sizes are very different. I would like to set a Keras epoch to correspond to the smaller training set size but because of this issue (or something related to it) it appears that the training data for the task with the larger training set size resets and repeats. This effectively truncates the size of the large training set to be ~same as the small one. Is there a work-around other than setting the epoch to correspond to the large training set size?

A workaround for this problem is to set the seed argument of the shuffle transformation to 0. This will result in reshuffling each epoch. However, the behavior will not be deterministic.
Being able to provide deterministic reshuffling each epoch requires maintaining the RNG state outside of the tf.data graph and is currently not supported.

@jsimsa When I add seed=0 to shuffle() in the sample code given by @malmaud, the results don't appear to change: the random order is the same between epochs. Also it appears that 0 provides a deterministic order similar to other values.

@rob-rowe mea culpa, as it turns out the argument only controls the op-level seed and the graph-level seed will still end up being non-zero. I have updated my original answer.

Hi There,
We are checking to see if you still need help on this, as you are using an older version of tensorflow which is officially considered end of life . We recommend that you upgrade to the latest 2.x version and let us know if the issue still persists in newer versions. Please open a new issue for any help you need against 2.x, and we will get you the right help.
This issue will be closed automatically 7 days from now. If you still need help with this issue, please provide us with more information.

@malmaud , you can mention seed inside shuffle to produce shuffled data between epochs. Please find the gist here with the working code in Tensorflow 2.5.


Standardize theme CSS

The formatting/design of the CSS in the themes directory is a bit all over the place, so I tried to tidy it up. I broke this change up into 4 commits, the first two being less controversial than the second two.

Four themes (seti, yeti, dracula, and material) use three-line css definitions where every other theme uses one-liners. I switched those four to use one-line definitions as well.
A fair amount of themes use !important in their .CodeMirror-selected definitions. Since https://github.com/codemirror/CodeMirror/commit/e1e9aca0c7c90695d600b0cf38e2798f2de9f83d got checked in, this is unnecessary (and problematic for users to override). Now, all themes that specify a rule for .CodeMirror-selected do so with .themename div.CodeMirror-selected and no !important clause.
Some themes have definitions like .cm-s-material span.cm-meta{ color: #80CBC4; } where there is no space between meta and the opening brace. This commit adds spaces there.
This is probably the most contentious change. The majority of one-line css definitions look like .selector { attr: value; }, that is, with one space after the selector, one after the opening brace, and one before the closing brace. However, there are a lot of nonstandard one-liners, the most common form being something like .selector {attr:value}. This commit ensures that all the definitions have the same spacing and that a semicolon is present.

Feel free to pick and choose if you don't want all of this! The last commit definitely touches a lot of lines, so I can understand not wanting to dirty up the blame log for essentially a cosmetic change.

Thanks for doing this boring work! I had plans to do something about all the !important annotations, but hadn't gotten around to it. Very glad you did it. Whitespace inconsistency doesn't bother me much, but since you already went through the work of fixing it, I've merged those patches too.


adds --all flag, adds bin to gitignore

fixes cri-o/cri-o#3149
Signed-off-by: Skyler Clark<EMAIL_ADDRESS>

/ok-to-test
/approve

/assign @mrunalp
Apparently I don't have approve permissions :laughing:

LGTM
@haircommander @mrunalp PTAL

https://github.com/cri-o/cri-o/pull/3892#issuecomment-648150305
not needed anymore


Implement markdown and yaml linting, prepare eslint infrastructure

This enables some linting/checks for Markdown, GH Action, YAML, and Shell Linting.
This introduces GitHub actions to check those things and allows users to check locally before submitting a PR. Running locally requires docker, but the user doesn't necessarily need to install or check manually before submitting a PR. To download all dependencies (ie make check = run all lints, checks), they can run make ensure-deps to download all dependencies, tools, and etc.
Addresses the following issues: https://github.com/deepgram/deepgram-js-sdk/issues/286 https://github.com/deepgram/deepgram-js-sdk/issues/285 https://github.com/deepgram/deepgram-js-sdk/issues/284
The updates to the Markdown are from the issues raised by the mdlint check.
If you don't feel this adds value to the project, feel free to close this PR and the issues as well.

Yup, I get it. It was the easiest lift without investing too much time (as in like 5mins). This isn't required for someone to open a PR as it will check in the GH action. If this is too much for the project to add, you can close this PR.

And we should be linting the JS/TS with the eslint package (and prettier if we want to be extra robust). There's also a markdownlint-cli npm package we can use if we want to lint markdown.

This doesn't tackle any JS linting.

Doesn't matter. It's your work and code.


⚠ Bofrost.de has degraded performance

In 167311d, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 772 ms

Resolved: Bofrost.de performance has improved in 924b113.


Lock and document cloudfuzzer commands

In this point of development we start to have a clear picture which of the current commands are "permanent" and could be locked.
Current functions.bash.inc, for remote-machine, has following command:
Available commands:
	bastion <command> - run <command> on bastion
	create-keys - create new vm-keys for packer build
	get-results - get results from cloudfuzzer
	get-stats - get various stats and logs from cloudfuzzer fuzzvm docker swarm
	help - print this
	send-docker-data <directory> - send docker data directory to bastion
	ssh - ssh to bastion

I suggest we lock these commands and start to add documentation/examples for them.

Closing issue