feat: fieldset

How to review this PR
Leave this text block for the reviewer

Check component hierarchy is followed correctly
Check the design Heuristics have been followed
Check naming conventions have been applied
Check for these gotchyas:

Missing exports for Oak components
Accidental export of Internal components
Snapshots of unexpected components have been modified
Circular dependencies
Code duplication (via not using base components)
Non-functional storybook for this or related components
Sensitve files changed eg. atoms, or style tokens
Relative imports
Default exports

Add your PR description below
This add's a very simple unstyled fieldset component
Link to the design doc
A link to the component in the deployment preview
Testing instructions
ACs

Oops missed the story!


Error occurs when running flame_audio example

When I run the flame_audio example, I get the following error.
Error: NotAllowedError: play() failed because the user didn't interact with the document first.
flame: ^1.0.0-releasecandidate.15
flame_forge2d: ^0.8.2-releasecandidate.15
flame_splash_screen: ^0.1.0
flame_audio: ^1.0.0-rc.15

This is not a Flame issue, this is a general thing with browsers and audio. Some background can be seen here: https://gamedev.stackexchange.com/a/165431
Basically you'll have to start playing the audio once something is clicked, like a "start game"-button for example.


vLoggingPrintf assert failed on IotMqtt_Init();

Describe the bug
Just trying to "recreate" mqtt_demo the code only calls IotMqtt_Init(); but when run keeps rebooting then I got logging errors like in the gist below
System information

Which hardware board or part numbers?
ESP32 DEVKITV1

IDE used
VSCode

Operating System [Windows|Linux|MacOS]
Linux

Version of FreeRTOS (run git describe --tags to find it)
201912.00-96-g306c3bca9

Project [Custom Application|MQTT|Shadow|Greengrass|OTA|Device Defender|TCP Echo|Sub pub Demo|Simple TCP Server]
Just MQTT

If your project is a Custom Application, please add the relevant code snippet in the section Code to reproduce the bug.

Expected behavior
Well I'm just calling the init() so I would expect IOT_MQTT_SUCCESS or even FAILURE. But definetelly not the ESP32 rebooting with panic
GIST with Code and Error logs
https://gist.github.com/aviler/70594006336b47bde64050d5bad769c9
Thank you!

It sounds like xQueue or the logging task could not be created.
Could you put some logging into xLoggingTaskInitialize()?

Hi @htibosch ! Thanks for the reply.
I added a esp-idf log in the beginning of the xLoggingTaskInitialize() and you're right is not been called. Thanks again!


Powerline fonts work in console vim, but not in gvim

Yes, I checked, they do work with powerline, both in gvim and console vim. They don't work in gvim if I use airline.
I made an album with screenshots. I've installed the patched fonts using the fontconfig method.
 ~ LANG=C gvim --version | head -n 3
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep  3 2013 20:01:21)
Included patches: 1-16
Compiled by Arch Linux

However, the glyphs show up if I use a patched font.

I use DejaVu Sans Mono, and encountered this problem tonight when looking into GVim. The patched font from powerline-fonts fixed it for me.

On my machine it seems like some colorschemes dont show airline correctly

I had the same identical problem as in @ravicious screenshot, fixed by setting font in gVim using
:set guifont=* and select some powerline font.

@verden11's solution doesn't work for me.
vim in console:

gvim with default font configuration:

gvim using @verden11's solution:

+1 Also having this issue on both patched and fontconfig method.

Issue with airline_symbols.branch only
Powerline Fonts installed using sudo apt install fonts-powerline
In Vim

In Gvim

:h airline

when i change airline_symbols.branch to '⭠' it works

any possible troubleshooting suggestions or solutions?

try to use a different font or change the symbol.

@chrisbra, we've found work-arounds, suggesting more doesn't really help move this forward:
In regards to changing the font, isn't powerline supposed to work in gvim if it works in vim?
In terms of changing the symbol, as @stadniklksndr pointed out, that works.  But it's not ideal for several
reasons:

It's buggy out of the box.
You don't get the intended symbol.
Less advanced users aren't going to find it easy to fix, even if they find this issue.  (The solution to this would be to document the kludge in the official documentation, but that's even kludgier.)

The bottom line is that this needs to be debugged.  It's been reproduced by many different people, so in principle should be considered a confirmed bug.
So my question to the devs is this: should we expect this issue to be reopened, or should we file a new one?

(At the very least, someone could tell us why they believe the bug is gone—e.g., in some code that hasn't made it into our package managers yet.)


Some xiaomi sensors have no battery status via integrations with DeConz

Home Assistant release with the issue:
Home Assistant 0.91.4
Last working Home Assistant release (if known):
None.
Operating environment (Hass.io/Docker/Windows/etc.):
Home Assistant / Raspbian Stretch / DeConz
Component/platform:
deCONZ Zigbee gateway integration.
deCONZ was installed in accordance with official documentation https://github.com/dresden-elektronik/deconz-rest-plugin.
Devices were added automatically via standard HA integration with "discovery:" option enabled.
Description of problem:
A number of Xiaomi Mi Sensors (round temperature/humidity version) were added to Phoscon deCONZ tool as sensors and then automatically appeared in dev-state as temperature and humidity sensors via HA deCONZ integration.
But some of these sensors occasionally have no attribute "battery_level", while other do.
See attached example screenshots with "Sensor Bath" having battery status and "Sensor 3DPrinter" which has no one.

Additional information:
Deletion the sensors from Phoscon and re-addition of them had no effect, as well as re-enable of deCONZ integration.

Is this in connection with you restarting both deconz and hass?

I didn't see Battery sensor for some specific Xiaomi Mi sensors at all. Neither just after full reboot, nor after a some while.

So this is how it works:
For battery sensors, it might take up to an hour or so for Xiaomi to report battery after deconz have restarted.
For battery entities for remote controls hass will only create the entity on start up. I think for battery attributes hass will load them dynamically as the sensor reports its batterystatus

I understand what you mean but it’s not the case. For these problem sensors I’ve never seen the battery value, even after a week of HA work without any reboot.
Best regards,
Vladislav

26 апр. 2019 г., в 18:29, Robert Svensson<EMAIL_ADDRESS>написал(а):
So this is how it works:
For battery sensors, it might take up to an hour or so for Xiaomi to report battery after deconz have restarted.
For battery entities for remote controls hass will only create the entity on start up. I think for battery attributes hass will load them dynamically as the sensor reports its batterystatus
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

If you don't see it in phoscon either it is better to create an issue with deconz GitHub.

I see it in deconz as a battery symbol but still don't see in hass. Please, investigate.

Ok, please share logs. They should show the battery sensor

Improvements made in deCONZ backend.


FIX: [CADT] Fix regex validation issue detected by code scanning tools

Issue explained here
https://github.com/Chia-Network/cadt/security/code-scanning

Check during next standup


Not a single photo of the editor ?

Like in the readme? https://raw.githubusercontent.com/google/xi-mac/master/doc/img/xi-mac-screenshot.png?


parse config to prep mirror

Codecov Report

Merging #429 into master will decrease coverage by 0.51%.
The diff coverage is 85.18%.

@@            Coverage Diff             @@
##           master     #429      +/-   ##
==========================================
- Coverage   97.97%   97.45%   -0.52%
==========================================
  Files          33       33
  Lines        1977     2045      +68
  Branches      131      147      +16
==========================================
+ Hits         1937     1993      +56
- Misses         27       33       +6
- Partials       13       19       +6

Impacted Files
Coverage Δ

...rthBoundControllerAbstraction/UpdateSwitchState.py
99.11% <ø> (ø)
:arrow_up:

...ndControllerAbstraction/proxy/faucet/connection.py
71.73% <ø> (ø)
:arrow_up:

...dControllerAbstraction/proxy/faucet/test_faucet.py
100% <100%> (ø)
:arrow_up:

...hBoundControllerAbstraction/proxy/faucet/faucet.py
100% <100%> (ø)
:arrow_up:

...dControllerAbstraction/proxy/faucet/test_parser.py
100% <100%> (ø)
:arrow_up:

...hBoundControllerAbstraction/proxy/faucet/parser.py
84% <75%> (-16%)
:arrow_down:

Continue to review full report at Codecov.

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


Update Menu Options

Removed Apps by Me.
Changed Upload an App href to TODO (pending github repo details),.
Removed all Upload an App code.

:+1:


npm run package not working

I have developed my application using electron-react-boilerplate master branch.  The app is running very well with npm run dev but I am not able to package my application.
I am using few native dependencies which I am putting inside app\package.json properly. Looking at logs I suppose I am getting error in one of the native dependencies adbkit which says ERROR in unknown: arguments is a reserved word in strict mode (135932:37)
Environment:
Node Version: 8.9.1 LTS
npm version: 5.5.1
Logs
0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files (x86)\nodejs\node.exe',
1 verbose cli   'C:\Program Files (x86)\nodejs\node_modules\npm\bin\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'package' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prepackage', 'package', 'postpackage' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>7 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
8 verbose lifecycle<EMAIL_ADDRESS>PATH: C:\Program Files (x86)\nodejs\node_modules\npm\bin\node-gyp-bin;D:\MyApp\GitRepo\WD\PlaybackApp\Desktop\Electron App\node_modules.bin;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;C:\Users\Expertadmin\AppData\Local\Android\sdk\platform-tools;C:\WINDOWS\system32\config\systemprofile.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\TortoiseSVN\bin;C:\Program Files\MySQL\MySQL Server 5.6\bin;C:\Program Files\MySQL\MySQL Utilities 1.6;E:\Software\Dev\ant\apache-ant-1.9.7\bin;C:\Program Files (x86)\PDFtk\bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\ManagementStudio;C:\Program Files (x86)\PuTTY;C:\Program Files (x86)\Skype\Phone;C:\Users\Expertadmin\AppData\Local\Android\sdk\build-tools\25.0.3;E:\Software\Dev\gradle\gradle-4.0\bin;C:\Program Files\MySQL\MySQL Server 5.7\bin;E:\Software\Dev\xml_tools;C:\Program Files\Git\cmd;C:\Program Files (x86)\Yarn\bin;C:\Python27;C:\Python27\DLLs;C:\Python27\Lib\lib-tk;C:\Python27\Lib\lib-tk;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files (x86)\nodejs;C:\Users\Expertadmin\AppData\Local\Microsoft\WindowsApps;C:\Users\Expertadmin.babun;C:\Program Files (x86)\Microsoft VS Code\bin;c:\Program Files\Saxonica\SaxonHE9.8N\bin;C:\Users\Expertadmin\AppData\Local\Yarn\bin;C:\Users\Expertadmin\AppData\Roaming\npm
9 verbose lifecycle<EMAIL_ADDRESS>CWD: D:\MyApp\GitRepo\WD\PlaybackApp\Desktop\Electron App
10 silly lifecycle<EMAIL_ADDRESS>Args: [ '/d /s /c', 'npm run build && build --publish never' ]
11 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
12 info lifecycle<EMAIL_ADDRESS>Failed to exec package script
13 verbose stack Error<EMAIL_ADDRESS>package: npm run build && build --publish never
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter. (C:\Program Files (x86)\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:280:16)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at EventEmitter.emit (events.js:214:7)
13 verbose stack     at ChildProcess. (C:\Program Files (x86)\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at ChildProcess.emit (events.js:214:7)
13 verbose stack     at maybeClose (internal/child_process.js:925:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd D:\MyApp\GitRepo\WD\PlaybackApp\Desktop\Electron App
16 verbose Windows_NT 10.0.14393
17 verbose argv "C:\Program Files (x86)\nodejs\node.exe" "C:\Program Files (x86)\nodejs\node_modules\npm\bin\npm-cli.js" "run" "package"
18 verbose node v8.9.1
19 verbose npm  v5.5.1
20 error code ELIFECYCLE
21 error errno 1
22 error<EMAIL_ADDRESS>package: npm run build && build --publish never
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>package script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
npm-run-package-2017-11-16T05_09_26_634Z-debug.log

@chentsulin, @amilajack  Could you please help here ?

Update: When I run package with yarn package command it gives me following output:
Tell the author that this fails on your system:
npm ERR!     concurrently "npm run build-main" "npm run build-renderer"

Any help? I am facing the same problem.

Hey, I can try to help you.

Try running yarn run lint and see if there are any errors.

Thanks uppe-r for your help. However, in my case disabling babili-webpack-plugin from webpack.config.main.prod.js and webpack.config.renderer.prod.js worked.

Cool! The boilerplate's next version (v0.13.0) will be using uglify instead of Babili.

@uppe-r v0.13.0 is OK?

Its not ready yet. I just closed this because the solution is known


segfault with tcb on docker

goaccess crashes on startup when built with --enable-tcb=btree in alpine OS docker environment (migrated from #795).
Use the following Dockerfile to build a goaccess image from the current working directory:
FROM alpine:edge

COPY . /goaccess
WORKDIR /goaccess

ARG TCB=tokyocabinet-1.4.48
ARG TCB_URL=http://fallabs.com/tokyocabinet/$TCB.tar.gz

ARG test_deps="bash vim"
ARG build_deps="build-base ncurses-dev autoconf automake git gettext-dev wget"
ARG runtime_deps="tini ncurses libintl gettext zlib libbz2 zlib-dev bzip2-dev"

RUN apk update && \
    apk add -u $runtime_deps $build_deps $test_deps && \
    ([ -d $TCB ] || wget $TCB_URL && tar -xzf $TCB.tar.gz) && \
    cd $TCB && ./configure --prefix=/usr --enable-off64 --enable-fastest && \
    make && make install && cd .. && \
    autoreconf -fiv && \
    ./configure --enable-utf8 --enable-tcb=btree && \
    make && \
    make install && \
    cd /

EXPOSE 7890

ENTRYPOINT ["/sbin/tini", "--"]
CMD ["goaccess", "--no-global-config", "--config-file=/srv/data/goaccess.conf", "-l", "/srv/data/logfile.txt"]

(it is modified/simplified a bit for testing, so please don't integrate this directly into master)
Assuming it is saved in the root directory of goaccess as Dockerfile.tcb it can be built as follows:
docker build -t goaccess_tcb -f Dockerfile.tcb .

Now, setup configuration files for testing:
mkdir -p srv/{data,logs,report}

cp /var/log/nginx/access.log srv/logs

cat <<EOF >srv/data/goaccess.conf
time-format %H:%M:%S
date-format %d/%b/%Y
log-format %h %^[%d:%t %^] "%r" %s %b "%R" "%u"
log-file /srv/logs/access.log
output /srv/report/index.html

keep-db-files true
load-from-disk true
db-path /srv/data/
EOF

Upon running as follows:
docker run \
    -v `pwd`/srv:/srv \
    --name goaccess_tcb \
    goaccess_tcb

It shows the following error:
==5== GoAccess 1.2 crashed by Sig 11
==5==
==5== VALUES AT CRASH POINT
==5==
==5== Line number: 0
==5== Offset: 0
==5== Invalid data: 0
==5== Piping: 0
==5== Response size: 0 bytes
==5==
==5==
==5== Please report it by opening an issue on GitHub:
==5== https://github.com/allinurl/goaccess/issues

It could very well be that the error occurs due to some fault in my install process or config file.
Otherwise, it might also be an issue, specifically occuring in the alpine-os environment. In this case, It might be useful to switch into the docker container and try things interactively.
Docker/Debug
I have compiled a few notes for convenience (I tend to forget the exact commands, have to look them up or remember which folders should go where, etc...):
Run container interactively:
docker rm goaccess_tcb
docker run \
    -v `pwd`/srv:/srv \
    --name goaccess_tcb \
    -it goaccess_tcb bash

and then run goaccess/inspect logfiles/install packages/rebuild/... from there, e.g.:
# apk add -u PACKAGE
# goaccess --no-global-config -p /srv/data/goaccess.conf -l /srv/data/logfile.txt

Alpine Package index: https://pkgs.alpinelinux.org/packages
Best, Thomas

The on-disk storage issue has been addressed. It now supports native on-disk persistence storage (no dependencies). New command line options are --persist, --restore, --keep-last=<num_days>. It also adds the ability to re-parse the same log(s) without counting data twice (see #334 or for exact details this post).
This will be pushed out in the upcoming release. However, it would be great if you could test this out before deployment by building from development.
Closing this as fixed. Feel free to post back as needed.


Scenes not working if added as button in Lovelace UI

Describe the bug
IR Remote scenes not working if added as button in Lovelace UI. Failed to call service scene/* ; Service not found.
If opened from device list and activated it runs fine.
Expected behavior
Call scene service from Lovelace Button
Screenshots
If applicable, add screenshots to help explain your problem.
Home Assistant Version
Home Assistant OS 6.1
**Device info
2021-07-28 12:02:25 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration tuya_v2 which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
device specifications (please complete the following information, which can be found in log):**
Same device's id, like this:
aditional context**
Product:  Mirrabella Genio IR Blaster

Service is not supported now.
We will consider it in the future.

OK, thankyou for consideration and response :)


fix #198 - delete MainOnlyNodes and children

Change works well for me:

Left the removal in CoreNode as well. @frank-weindel can you update the VRT for me please 🙏

However, you're now cleaning up MainOnlyNodes and recursively cleanup MainOnlyNode children. The CoreNode will still have children as we're only unsetting the parent on node destroy(). This means that, although disconnected from the parent, each CoreNode will still have an array of children with nodes that could potentially leak.

Each MainOnlyNode that you set its parent to null on also causes its corresponding CoreNode parent to be set to null. And both have handlers in this case to remove themselves from their old parent's children array. So I'd fully expect just doing the tree traversal on the MainOnlyNode (and ThreadXMainNode) to clean up everything.
Am I missing something perhaps?

Each MainOnlyNode that you set its parent to null on also causes its corresponding CoreNode parent to be set to null. And both have handlers in this case to remove themselves from their old parent's children array. So I'd fully expect just doing the tree traversal on the MainOnlyNode (and ThreadXMainNode) to clean up everything.
Am I missing something perhaps?

No you're absolutely right, I've overlooked the cleanup on the set parent. We might just move the:
this.parent.setUpdateType(UpdateType.Children); down to where we update the parents children for other cases when we null the parent of a node.
Also might be good to check for a null already being set in that section. I believe we ran into that when Blits tried to already null the parent prior to calling destroy on the node.


Bump intl to 0.15.1

requires bumping process to a version that has
relaxed version restrictions on intl

https://github.com/flutter/flutter/issues/10650

After discussing with @goderbauer, merging on red to test out theory that build failures are transient error.


evaluator: cyclic data structure fails to evaluate if not top level

What version of CUE are you using (cue version)?

$ cue version
cue version +c942d0af linux/arm64

Does this issue reproduce with the latest release?
Yes
What did you do?
Distilled from https://github.com/cue-lang/cue/discussions/1676
The example below presents three cases that should all evaluate to the same result.

where a cyclic data structure is defined at the top level and referenced from a field within a struct that is then used as part of a unification with the data
where a cyclic data structure defined as part of a non-top-level field is referenced directly as part of a unification with the data
where a struct containing a cyclic data structure is unified with the data

# case 1
exec cue eval -e o x.cue o1.cue
cmp stdout stdout.golden

# case 2
exec cue eval -e o x.cue o2.cue
cmp stdout stdout.golden

# case 3
exec cue eval -e o x.cue o3.cue
cmp stdout stdout.golden

-- x.cue --
package x

#Secret: {
	$secret: id: string
}

secrets: #Secret | {[string]: secrets}

src1: output: secrets
src2: output: #Secret | {[string]: output}

out: {
	FOO: $secret: id: "100"
	ONE: TWO: THREE: $secret: id: "123"
}
-- o1.cue --
package x

o: src1 & {
	output: out
}
-- o2.cue --
package x

o: output: src2.output & out
-- o3.cue --
package x

o: src2 & {
	output: out
}
-- stdout.golden --
output: {
    FOO: {
        $secret: {
            id: "100"
        }
    }
    ONE: {
        TWO: {
            THREE: {
                $secret: {
                    id: "123"
                }
            }
        }
    }
}

What did you expect to see?
A passing test.
What did you see instead?
# case 1 (0.016s)
# case 2 (0.015s)
# case 3 (0.014s)
> exec cue eval -e o x.cue o3.cue
[stderr]
o.output: 4 errors in empty disjunction:
o.output: field not allowed: FOO:
    ./o3.cue:3:4
    ./o3.cue:4:10
    ./x.cue:3:10
    ./x.cue:10:15
    ./x.cue:13:2
o.output.FOO: 2 errors in empty disjunction:
o.output.FOO: field not allowed: FOO:
    ./o3.cue:3:4
    ./o3.cue:4:10
    ./x.cue:3:10
    ./x.cue:10:15
    ./x.cue:10:36
    ./x.cue:13:2
    ./x.cue:13:7
o.output.FOO.FOO: structural cycle
[exit status 1]
FAIL: /tmp/testscript218994319/repro.txt/script.txt:10: unexpected command failure

i.e. case 3 fails to evaluate with structural cycle errors.

cc @helderco

I can confirm this is fixed in the cycle/comprehension rework I have locally in my client.

Almost done with the cycle rework. And now I noticed it is not fixed. Not sure why it was working before, but upon further investigation, this is actually working as intended! (My apologies for the big twist!)
It is quite subtle, but understandable. Consider
src2: output: #Secret | {[string]: output}

vs
src2: output: #Secret | {[string]: secrets}   // s/output}/secrets}/

The second one would also work.
The big difference between the latter case, case o1 and o2 on the one hand and o3 on the other hand, is that in the former cases the reference of the pattern constraint refers to a value that is not unified into o. This means that each time when this reference is dereferenced, it gets a fresh copy of secrets.
In the failing case, however, the reference to secrets is replaced with output,  and o is unified with the entirety of src2, which includes the output field itself. In this case, output will reference the struct in the resulting field, not the original field.  This means it will also contain the fields that are unified in at o. As there are two fields which both reference output at different levels, this will result in a continuous invocation of output, which will lead to a cycle.
It essentially then results in something like:
a: [string]: b: a
a: c: b: {}

which results in a cycle as whenever a is referenced it also inserts a field that triggers the pattern on a new level.
Note that the difference here is akin to having a list:
Foo: #List: {
    Next:   #List | null
    Value: _
}
list: Foo.#List & {Value: 3, Next: Value: 1}

which works, versus
Foo: #List: {
    Next:   #List | null
    Value: _
}
list: Foo & {#List: {Value: 3, Next: Value: 1}}

which doesn't work as it is essentially redefining #List to have a fixed value of 3, while simultaneously demanding that the next element be 1.
Strictly speaking, it is not even necessary to include output to create cycles with pattern constraints. Consider the following example:
y: [string]: b: y
x: y
x: c: y

This result in a structural cycle at: x.c.b.b.b.b. As the two fields x each reference the y at different depth, the field b of the pattern constraint will trigger a match of the constraint alternating between the two conjuncts of x. That is not what's going on with secrets, but it illustrates how the use of pattern constraints may cause cycles if one is not careful.
As this is a simplified reproducer, I don't know enough of the context to recommend how this could be avoided.

Thanks @mpvl, the intent is to type a structure like this (i.e., variable key depth, ending in a $secret):
{
    FOO: {
        $secret: {}
    }
    ONE: {
        TWO: {
            THREE: {
                $secret: {}
            }
        }
    }
}

Is it possible?

I attempted this, but isn't working in practice:
exec cue eval x.cue

-- x.cue --
src: {
	#Secret: {
		$secret: _id: string
	}

	a: {
		output: _#out
		_#out: #Secret | {[!~"\\$secret"]: _#out}
	}

}

out: {
	FOO: $secret: _id: "100"
	ONE: TWO: THREE: $secret: _id: "123"
}

final: src & {
	a: output: out
}

From https://github.com/cue-lang/cue/discussions/1676#discussioncomment-2656886

Maybe what doesn't works for you in practice is when you have separate packages ? Ie: #Secret comes from a separate package.
Because in this case hidden fields will not unify.
For example:
a/a.cue
package a

#A: {
	_x: 1
	a:  string
}

x.cue
package x

import (
	"example.com/x/a"
)

x: a.#A & {
	a:  "foo"
	_x: 24
}

 cue eval
x: {
    a: "foo"
}

As you can see _x is unified only in the scope of the package. If in the same package there would be an error as 1 cannot be unified with 24.
Sorry if this is irrelevant as I don't know exactly how dagger manages this _id field.

@eonpatapon We're filling with cue.Hid():
var secretIDPath = cue.MakePath(
	cue.Str("$dagger"),
	cue.Str("secret"),
	cue.Hid("_id", pkg.DaggerPackage),
)
// ...
v.FillPath(secretIDPath, s.id)

https://github.com/dagger/dagger/blob/b4f934a6ea2d9787fb66bf2cbfac8d4f9ded4141/plancontext/secret.go#L39
Wouldn't this be a better representation?
exec cue eval x.cue

-- cue.mod/module.cue --
module: "example.com"
-- core/types.cue --
package core

#Secret: {
	$secret: _id: string
}

out: {
	FOO: $secret: _id: "100"
	ONE: TWO: THREE: $secret: _id: "123"
}
-- x.cue --
package x

import "example.com/core"

src: {
	a: {
		output: _#out
		_#out: core.#Secret | {[!~"\\$secret"]: _#out}
	}

}

final: src & {
	a: output: core.out
}

Output:
...
final: {
    a: {
        output: {
            FOO: {
                $secret: {}
            }
            ONE: {
                TWO: {
                    THREE: {
                        $secret: {}
                    }
                }
            }
        }
    }
}

I just tried @helderco's latest example with 537831: internal/core/adt: reimplementation of cycle algorithm | https://review.gerrithub.io/c/cue-lang/cue/+/537831
And, it works! So, this CL should hopefully solve the issues we're encountering with this.

My example works even in current version, as you can see in the output, but just in CUE. When I say it doesn't work in "practice" I mean in Dagger.

@jlongtine - per our conversation on Friday, please can we see a version of what you and @helderco are doing in Dagger here? We're missing too much context in the cut down repro to help beyond @mpvl's explanation in https://github.com/cue-lang/cue/issues/1680#issuecomment-1117943928. That comment effectively amounts to "this is working as intended" - with more context I think we will be better placed to collectively identify the right solution.

Sorry @myitcv, I should have been clearer, there's actually two errors we're dealing with here.
This is how this progressed:

Structural cycle cause by output: #Secret | {[string]: output}
Fixed cycle with _#out: dagger.#Secret | {[string]: _#out} and output: _#out but shows an unresolved disjunction
Tried to fix with _#out: dagger.#Secret | {[!~"\\$dagger"]: _#out}... appears to resolve the disjunction (when debugging the value) but still has an attached "unresolved disjunction" error

The first one only happened when using a FillPath. The latter two it's just the opposite, only work with FillPath.
So I think we can close this issue which is about the first error, and continue with the unresolved disjunction in:

https://github.com/cue-lang/cue/discussions/1676

I'll add more details there.


Do you have a node to run inspect command?

Hello , I want to analyze the storage of the data space in eth, and want to know percentage of each part,do you have a node to run the command 'geth db inspect' (cannot be executed simultaneously as another geth is running)? Example output: https://github.com/ethereum/go-ethereum/pull/25896#issue-1391842360

This snapshot uses erigon, not geth.


Which font?

I think the most important question when it comes to a map is the font. Which font should we use?

I would vote for Noto Sans because it fits the concept of our Löli Style of being not the best font ever but gets you quite far.
https://fonts.google.com/noto/specimen/Noto+Sans

Absolutely! Noto seems like a good pick for a not so great map, which just works everywhere!

Good Noto it is


Finding Common Substrings

Hey,
Is it possible to find all the sub-strings in the string along with the count using lcss.Qsufsort? It could be great if there is some way to say extract all sub-strings that repeats more than 5 times. I think it's theoretically possible to find that from suffix tree. Any help would be great.
Thanks. :smile:

Hi @n-is I coded this project 3 years ago and honestly don't remember a thing about the internals already. Maybe yes, maybe no :smile: If you really need to solve a business problem here, I'll be happy to review your PR and merge it eventually.


Flux Request returns data for incorrect organization

The following end-to-end unit test fails as a result: https://github.com/influxdata/influxdb/blob/7f8e2c6952924773eaa1b9bde559f6a69a2eec08/cmd/influxd/launcher/storage_test.go#L15-L50.
Setup
Two organizations are created:
user  : USER-1
pass  : PASSWORD-1,
org   : ORG-01
bucket: BUCKET

and
user  : USER-2
pass  : PASSWORD-1,
org   : ORG-02
bucket: BUCKET

A Flux request is constructed to query a bucket named BUCKET for organization ORG-02 and USER-2 using a valid token for for this user / org, however, data for ORG-01 is returned.
Notes

A flux request is handled by the http.FluxService, which requires a server address and a valid token
A http.QueryRequest struct is constructed, containing the Flux query and most importantly OrgID
The http.QueryRequest is transformed into a *query.ProxyRequest via the ProxyRequest API, which correctly transfers the OrgID here
A flux query is executed as a HTTP request via the FluxService.Query API using the ProxyRequest

The FluxService.Query API transforms the ProxyRequest back to a QueryRequest via the QueryRequestFromProxyRequest API

Issue 1: QueryRequestFromProxyRequest fails to transfer the OrgID back from the inner Request struct

Assuming this is resolved

The http.QueryRequest is then serialized to JSON and POSTed to the server
The server handles the request via the FluxHandler.handleQuery HTTP handler
Within the handler, it decodes the incoming request via the decodeProxyQueryRequest API which calls decodeQueryRequest
Given the request mime type is application/json, it is decoded as such, however, the Org organization ID specified in the original request is overwritten by this line, which calls queryOrganization
queryOrganization attempts to retrieve the organization via the *http.Request object by inspecting the URL and looking first for a query parameter named orgID (which is not set). Secondly it attempts to find an org using a filter from the org parameter (also not set) and appears to return the first matching organization
It finds the first org created and allows the request to proceed
Because the buckets are named the same for two independent orgs, the query proceeds and returns invalid data

Closed by #12040


Testing

#33 will make testing easier:

[x] Test #33 thoroughly, then be sure to test:
[ ] Dimensionalization #27
[x] Many diff formats and kernels
[ ] Sparse Accelerator Initialization #7
[x] Protocols
[ ] Other Index Modifiers #19 #20 #21 #22 #23
[ ] Embedding (especially error handling) #24
[x] Pretty printing of kernels #40

I'm closing this as we mostly the stable parts of Finch, and we will continue to add tests as we make changes and additions to Finch.


How to set up configs for fine tuning (transfer learning)

Hi, I am having trouble doing transfer learning with mmdetection. I have two datasets:
A - Synthetic dataset. 100k images, 1 class. Used for pretraining
B - Real world dataset. 3k images, 1 class. Used for transfer learning.
I've previously been using TF object detection API. My procedure has been: pretrain on A, then transfer learning on B. This has worked well on TF object detection API. When trying the same thing with mmdetection, I get good convergence for pretraining, but when I do transfer learning, the loss does not converge at all, it begins at 0.2 and rises to around 0.35.
My question: is there something I am forgetting to do in order to switch to transfer learning? Here are the modifications I made to the config for transfer learning:

Switch data config to point at new dataset
Switch "img_scale" argument to account for size of new images
Switch "img_norm_cfg" to have the image stats of the new images
Switch "frozen_stages" from -1 to 4
Add "pretrained" arugment to point at epoch_30.pth from pretraining.

I've also tried setting frozen_stages to everything from 1-4, with no change. I've tried using learning rates 0.02, 0.002, and 0.0002, with little change, the loss just changes more slowly, but still fails to ever drop.
I feel that I am missing something obvious here in configs, since the same datasets with the same network (Faster RCNN with resnet 101) have worked well using TF api.
Any suggestions? Thanks!! :)

You may just follow what you did with TF, but if you have any specific questions on the apis or configs of mmdetection, we can provide some help.
frozen_stages means freezing the stages of ResNe(X)ts.
pretrained only affects the backbone.

Thank you! When doing transfer learning, is there anything else I should do besides these? I wonder if I'm missing a step and that is why I see poor performance. TF does all these things for you itself when transfer learning.

what about the instruction
load_from=''
is it used for a transfer learning ,and fine tuning? what is the different between it and  pretrained argument in the config of the backbone.
i am little bit confused about doing transfer learning using mmdetection library.


UTM Vagrant plugin support

Hello UTM Developers,
With the transition to M1 max architecture (macOS Monterey), one of the issues I have faced is getting an Ubuntu x86_64 working.  UTM was perfect as the emulation mode solved this issue perfectly.  I was interested in using vagrant with UTM and wanted to find out if there was a plugin available, or if this was on the roadmap?   Additionally it would be helpful on the gallery page to include the Ubuntu 20.04 x86_64 version (currently only arm64) if possible.
Thanks,
Ajay

Duplicate of #3718


Scrollbar in repeater bleeds into header

Because of the viewport positioning and sizing the scrollbar is not cleanly/natively positioned with the records and overlaps with the header content.

This will be fixed with my pull request for issue #1254

This is a different issue. This design bug still exists after the fix to .scrolling

I just remembered some more history on this. Before you joined the team, Stephen. Kevin and I asked design about this issue in the large pattern library meeting. It would have been May or June of 2014.
I'm still looking into this, but we may be spinning our wheels and did have design approval previously. If things have changed and design has said this is important, than we can try to accommodate for that.
Looking into creating another view / options override.

Ok. Good to know. I was having a hard time remembering those conversations, but it’s probably because I wasn’t there. :) I think this is something we should definitely fix.  As to how high we prioritize and when we fix it, I think there’s room for discussion.
This example feels off, but I think we can live with temporarily while we find a fix.
[cid:BFA06D17-DB52-425E-8115-D6BF2EEF1054]
This example feels broken and we should fix as soon as possible. Might seem superficial, but if a user sees this it communicates a lack of polish and plants a seed of mistrust.
[cid:B2038122-2417-406D-89EA-D5FDBBAF9954]
From: Stephen James <notifications<EMAIL_ADDRESS>Reply-To: ExactTarget/fuelux <reply<EMAIL_ADDRESS>Date: Thursday, April 23, 2015 at 10:13 AM
To: ExactTarget/fuelux <fuelux<EMAIL_ADDRESS>Subject: Re: [fuelux] Scrollbar in repeater bleeds into header (#1253)
I just remembered some more history on this. Before you joined the team, Stephen. Kevin and I asked design about this issue in the large pattern library meeting. It would have been May or June of 2014.
I'm still looking into this, but we may be spinning our wheels and did have design approval previously. If things have changed and design has said this is important, than we can try to accommodate for that.
Looking into creating another view / options override.
—
Reply to this email directly or view it on GitHubhttps://github.com/ExactTarget/fuelux/issues/1253#issuecomment-95600312.

Thanks, Jamin. I'm going to remove the high priority tag based on your feedback, but keep it in a milestone, so that it doesn't get lost.


Set DPI Awareness mode to System Aware

Fixed DPI scaling for HighDPI displays
150% before:

150% after:

It looks nice and I'd really like to have it merged in but it causes an issue that I had not initially planned for. I can probably eventually look into fixing the cluster viewer but I've been really busy lately so I'm not sure when I'll have spare time.
Here is a before and after in case you want to look into it:


Use const ref variable to store AnyMap

Remove unnecessary AnyMap copying
Signed-off-by: The MathWorks, Inc<EMAIL_ADDRESS>

@kevinleeMW I'll go ahead and make the changes in this PR.


Consumer rebalance problem when using docker container

BUG REPORT

Please describe the issue you observed:

docker环境下，2个不同的consumer实例，生成的clientId是重复的，进而导致rebalance的结果混乱。（经过debug发现获取到的ip是一样的，怀疑跟rancher网络有关）

Please tell us about your environment:

rocketmq client "4.3.0"
java version "1.8.0_181"
Docker version "18.09.0"

Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):

建议：改进ClientConfig类中instanceName的生成规则

I encountered the same problem. Under HOST networking mode, all dockers managed by Rancher are with the same docker0 IP, which is <IP_ADDRESS>.  Thus, RemotingUtil.getLocalAddress() always returns "<IP_ADDRESS>" for those dockers, which leads to collision between consumers with the same pid, if using default "IP@pid" clientId.

RocketMQ client Version: 4.3.2
Rancher Version: 1.16.10
Docker Version: 18.09.5

@huanwei This is a known problem in the docker container if we deploy mutl-docker containers in the one machine.

@caigy @huanwei if used Rancher to manage container, all docker will always return  "<IP_ADDRESS>" when getLocalAddress, not only in bridge model, but also in host model, so I think it may be an issue caused by Rancher,  so you can temporarily solve this problem by setting the instanceName.

That's known issue caused by Rancher container network. Setting different instanceName should solve this problem, just as @duhenglucky suggested.

Which version have been solved, I also meeting the same problem.

Has this be fixed?

Has this be fixed?

除了通过手动自定义instanceName外，RocketMQ会做什么来兼容吗？还是不考虑兼容了？

I would like a more general way to completely solve the problem of instance conflicts.  https://github.com/apache/rocketmq/issues/3680


[vcpkg baseline][sdl2] Disable uwp build.

F:\vcpkg\buildtrees\sdl2\src\SDL2-2-1f74301957\src\video\winrt\SDL_winrtgamebar.cpp(167): error C2065: '__FIEventHandler_1_IInspectable': undeclared identifier

This error seems by design or a upstream bug.
So disable uwp build now.
Related: #11637.

The macro __FIEventHandler_1_IInspectable has been moved to other header files in Windows 10 SDK 10.0.19041.0.
I've report this issue to upstream: https://bugzilla.libsdl.org/show_bug.cgi?id=5170

The upstream has been fixed this issue in master branch.

Will fixed in #11365.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.7 to before v5.15.20",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8edf5332c39340b9583cf9cba659eb7ec71f75b5",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1db58c6584a72102e98af2e600ea184ddaf2b8af"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "8edf5332c39340b9583cf9cba659eb7ec71f75b5",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "1db58c6584a72102e98af2e600ea184ddaf2b8af",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "PCI: pciehp: Fix infinite loop in IRQ handler upon power fault\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.20 by commit 1db58c6584a72102e98af2e600ea184ddaf2b8af, it was introduced in version v5.7 by commit 8edf5332c39340b9583cf9cba659eb7ec71f75b5. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000269


Mbart, pegasus, blenderbot, marian, m2m_100 support scaled_dot_product_attention

Most probably wav2vec2, whisper, hubert would support as well, but I'll leave it to an other PR once we have benchmarked with what we already have.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Cool, but the other models you mentioned are more used and more downloaded so maybe more important ! 🚀 Can't wait for Whisper


GC optimizations

There are a couple of optimizations that can be done to improve GC-related performance during runtime. Will get to do these at some point soon.

One obvious optimization is to cache the name of each state. We are already caching state instances (they are created only once). However, every time we query the name of the current state, we allocate a new string, and re-compute the format of the string:
https://github.com/p-org/PSharp/blob/master/Libraries/Core/Library/Machine.cs#L192
In experiments, this causes quite a bit of churn in Gen2, since we query this property all the time (for logging). Solution: caching the string at state creation, which significantly reduces the number of Gen 2 collections.
There are more string-related GC problems that we can improve with caching (instead of re-computing/re-allocating each time).

Would something like using Lazy to initialize the name work? We get the benefit of Lazy being thread-safe (if created properly), and also only creating the string once.
Although, looking through https://github.com/p-org/PSharp/blob/master/Libraries/Core/Library/Machine.cs, I'm not sure if it's a candidate for Lazy or not.

Thanks, @formlesstree4. In our case, I think creating the string that corresponds to a machine/state name once and storing it for further reuse during logging (instead of allocating the same string each time) is probably the best and simplest way. I do not think Lazy<T> is a good candidate here.

Performance opts were done in #425. Will revisit as necessery.


Very less number of options for choosing colour and colours are not attractive.

I want to provide user a lot of options for chosing colour , assign me this project to make changes in the file.

@piyushsahujtp
Can you explain this issue once? or you are talking about the second input?

Thank you for creating this issue! 🎉 We'll look into it as soon as possible. In the meantime, please make sure to provide all the necessary details and context. If you have any questions or additional information, feel free to add them here. Your contributions are highly appreciated! 😊
You can also check our CONTRIBUTING.md for guidelines on contributing to this project.

I want made some additional features like  adding an option for choosing more and more colours, button for restart the game and more additional features.

@piyushsahujtp
Could you please provide me with the details for all those features?

I want to add a feature in which user swith to light mode and dark mode and along with it user manage the sound volute as per their need , They can save screenshot using a screenshot button on the top .

@piyushsahujtp
Thank you for raising this issue. We've reviewed it, and it seems that some of the features are already there like changing theme & issues have been created & assigned for other features. If you have any additional issues, feel free to reach out. To keep our issue tracker organized, I will be closing this issue.


added navbar

Fixes #

Description:  The title should be short and relevant.
Checklist

[x] I've followed the Contributing guidelines provided in the repository.
[x] I've made the changes which were demanded in the linked issue.
[x] I've tested my code on a Chromium based browser.
[x] I've tested my code on Mozilla Firefox.
[x] My code gave a clean console on debugging. (no warnings/errors)

Testimonial

thank you @himanishu-2512 :tada: . you should ideally delete the branch you were working on for now


Button height is changed to kButtonBottomMargin and kButtonHeight now give button a height.

The update changed how kButtonHeight works previously it gave a bottom margin to a button. I have changed the code by adding kButtonBottomMargin which now does what kButtonHeight previously done add kButtonHeight now gives a button a height

I submitted a pull request that fixes this.


Does Hololens2 have plan to support offline TTS suport?

Does Hololens2 have plan to support offline TTS suport?

Hi @Hawkpool, offline text to speech isn't part of Graphics Tools. But because HoloLens 2 is a Windows device it does have TTS support. The OpenXR plugin provides options to bind speech commands to Unreal input actions: https://docs.microsoft.com/en-us/windows/mixed-reality/develop/unreal/unreal-voice-input
There might also be a way to synthesize speech with this  UWP class. @fieldsJacksonG might have more info to share.


rdma-core: Fix pkg-config files

Description of changes
This patch fixes double-appearance of the nix store path in the generated pkg-config file.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@markuskowa good point. will do.

@markuskowa done


Fix GroupNorm to support Opset21

Updating GroupNorm to create a bias tensor and scale tensor using (C) Channel instead of (G) numGroups. The previous understanding was incorrect, I changed the code to reflect the updates made in ONNX.
Right now I included support for Opset18 as well as Opset21.
Here is more information on why the changes were made:
https://github.com/onnx/onnx/issues/5466

@jenkins-droid Test this please

@AlexandreEichenberger @chentong319 Okay, I took the feedback from you both and made some changes. Let me know what else needs to be fixed and if I got the reshape for biasScaleShape correct. The backend tests for GroupNormalization Passes and I added two new lit test for Opset21.

FYI- @Sunny-Anand

Jenkins Linux s390x Build #15627 [push] Fix GroupNorm to support... started at 16:50

Jenkins Linux amd64 Build #15624 [push] Fix GroupNorm to support... started at 15:50

Jenkins Linux ppc64le Build #14654 [push] Fix GroupNorm to support... started at 17:01

Jenkins Linux amd64 Build #15624 [push] Fix GroupNorm to support... passed after 1 hr 8 min

Jenkins Linux s390x Build #15627 [push] Fix GroupNorm to support... passed after 1 hr 29 min

Jenkins Linux ppc64le Build #14654 [push] Fix GroupNorm to support... passed after 2 hr 1 min


[Doc] : Visual Enhancements , Fostering Contact Channel and enabling Contributors List in README

Is your feature request related to a problem? Please describe.
Issue Description
Problem: A poorly structured or visually unappealing README can create confusion and hinder user engagement with a project.

This can lead to:

Difficulty understanding the project: Newcomers may struggle to grasp

Reduced contributions: Potential contributors may be deterred by a lack of clear information

Negative first impression: An unprofessional README can reflect poorly on the project and discourage users from
exploring further.

Describe the solution you'd like

To enhance communication and provide direct access to Project Guidance, I plan to include a dedicated Contact section 👤. This section will feature the LinkedIn and GitHub profiles of each mentors and Admin⚡ enabling contributors to readily connect with them and address any project-related queries.

Additionally, to improve readability and organization, I Planned to implement clear visual separations between each section of the contributor documentation, ensuring a user-friendly and easily navigable 🚏 experience.

Finally, to foster a welcoming 🙏🏻 and inclusive environment, I will incorporate personalized welcome messages for our Repository.

To effectively convey the essence of our project and its objectives, I propose creating a customized cover image for the repository.

Kindly Assign me this Issue Under 🌸 Gssoc, ☘ hacktoberfest . I'm grateful to work with Talented Crews ✨.

hey , thanks for the input but we are okay with the readme we have right now , it covers what we want !


Case-insensitive history search

I'd like to have case-insensitive search of the history. And it looks like history search is hardcoded now. How should I approach the problem:

Allow customizing history search?
Add case_insensitive (or similar) config parameter?
Make case insensitive default (if that makes more sense)?

If possible we should behave like readline which seems to be case-sensitive.
So (2) seems good to me.
I will try to see how other libraries behave by default.

It seems that we need the regex crate (https://github.com/rust-lang/rfcs/issues/1988).
And we cannot use std::str::pattern (yet): https://docs.rs/regex/1.1.0/regex/struct.Regex.html#using-the-stdstrpattern-methods-with-regex

See #546 but you may not like the cargo feature...

I'm fine with it being cargo feature. I think that case-insensitive here is what users would expect, and it's fine that it's a feature because of having an extra dependency.

Version 9.0.0 released.


Tcm vis swim3

Add the swimming animation and swimming sound to the app
sibling:
https://github.com/webaverse/water/pull/2
https://github.com/webaverse/three/pull/16

This PR caused major code quality regressions.


[BUG] S3 Sink Avro Output issues

Describe the bug
A few bugs found for S3 Sink Avro output codecs:

With compression: gzip specified, the files are still uploaded with just a .avro suffix. This should be .avro.gz
The contents of the avro file show null for all fields:

{"version":null,"srcport":null,"dstport":null,"accountId":null,"interfaceId":null,"srcaddr":null,"dstaddr":null,"start":null,"end":null,"protocol":null,"packets":null,"bytes":null,"action":null,"logStatus":null}
{"version":null,"srcport":null,"dstport":null,"accountId":null,"interfaceId":null,"srcaddr":null,"dstaddr":null,"start":null,"end":null,"protocol":null,"packets":null,"bytes":null,"action":null,"logStatus":null}
{"version":null,"srcport":null,"dstport":null,"accountId":null,"interfaceId":null,"srcaddr":null,"dstaddr":null,"start":null,"end":null,"protocol":null,"packets":null,"bytes":null,"action":null,"logStatus":null}
{"version":null,"srcport":null,"dstport":null,"accountId":null,"interfaceId":null,"srcaddr":null,"dstaddr":null,"start":null,"end":null,"protocol":null,"packets":null,"bytes":null,"action":null,"logStatus":null}

The timestamp in the file name is 12 hours behind UTC. I am not sure what the "correct" time is but UTC seems logical

To Reproduce
Sink config:
sink:
    - s3:
        aws:
          region: "us-west-2"
          sts_role_arn: "<my role>"
        bucket: "my-sink-bucket"
        object_key:
          path_prefix: "s3-sink"
        threshold:
          event_collect_timeout: 600s
        compression: "gzip"
        codec:
          avro:
            schema: >
              {
                "type" : "record",
                "namespace" : "org.opensearch.dataprepper.examples",
                "name" : "VpcFlowLog",
                "fields" : [
                  { "name" : "version", "type" : ["null", "string"]},
                  { "name" : "srcport", "type": ["null", "int"]},
                  { "name" : "dstport", "type": ["null", "int"]},
                  { "name" : "accountId", "type" : ["null", "string"]},
                  { "name" : "interfaceId", "type" : ["null", "string"]},
                  { "name" : "srcaddr", "type" : ["null", "string"]},
                  { "name" : "dstaddr", "type" : ["null", "string"]},
                  { "name" : "start", "type": ["null", "int"]},
                  { "name" : "end", "type": ["null", "int"]},
                  { "name" : "protocol", "type": ["null", "int"]},
                  { "name" : "packets", "type": ["null", "int"]},
                  { "name" : "bytes", "type": ["null", "int"]},
                  { "name" : "action", "type": ["null", "string"]},
                  { "name" : "logStatus", "type" : ["null", "string"]}
                ]
              }

Screenshots
File name times example:

The Avro codec does not work with union types, nor is there any support for it in the code. https://github.com/opensearch-project/data-prepper/blob/60f69b3c565e7a10e6459d6bbe694d74ae6e6d96/data-prepper-plugins/avro-codecs/src/main/java/org/opensearch/dataprepper/plugins/codec/avro/AvroOutputCodec.java#L192-L227

For the timestamp in the file name, the same behavior is seen with ndjson so it doesn't look related to avro, rather S3 sink as a whole

#3171 fixes number 3

PR #3194 fixes item 2.

Item 1 should be resolved by #3196.


Support for Python 3.9

VERSION: 0.4.0b4
I see here that a Python version of '>=3.6.2,<3.9' is enforced. If you're using conda, this isn't much of an issue –– but if you're only trying to use some of the vak utility functions, this is a bit of a tricky constraint. Changing Python versions is quite a hassle (and I'm not particularly keen to downgrade). If this constraint is only needed because of coverage, I wonder if there's an easier solution?

I think the upper bounding is just an artifact of when I first switched to poetry.
But yes CI takes forever to run already, not sure what will happen if I add a run on 3.9 to GitHub Actions.
Let me try bumping it in a branch, adding a run for 3.9, and seeing what happens.
If it finishes (eventually) I can just go ahead and merge in that change.

Finished :)
Do you need me to put a new version on PyPI?
I can just bump the pre-release number.
off-topic but I'd be curious to know which functions you're using as utilities

closing as fixed by #368


SCRD-2080 Revert to expecting logrotate.conf not to be modified

DON'T MERGE until gerrit#I51c2bf0c is merged
Ardana was incorrectly modifying /etc/logrotate.conf, so we had to temporarily add an exception to the rpm verification whitelist for modified files in order to avoid ardana-job permanently failing.  However once gerrit#I51c2bf0c (SCRD-2080 don't replace standard /etc/logrotate.conf) is merged, this exception is no longer necessary.

@dirkmueller Not quite yet, gate jobs are still in progress ...

Not quite yet, gate jobs are still in progress ...

Now it is merged


Separation of concern for database administrators (Cassandra) during Kong migration process

Kong migration process assumes that the Cassandra Database administrator running the Kong migration up command has the full privileges on the DB.
However, for separation of concerns in Production, it often happens that several actors are involved into a system deployment:

A DBA (Database Administrator) first: holding the keyspace creation rights, he is the one allowing a new application to be deployed on a Cassandra Cluster, by creating a new keyspace
Then an application administrator: he is the one installing the required tables for an application. It only holds the table creation right; not the keyspace creation right.
Finally, an applicative runtime account holding neither the keyspace creation not the database table creation rights: this is a basic account used for running the service itself.

The new split between Kong migration and Kong service execution newly introduced in 0.11 allows a applicative runtime account to run Kong. However, the Kong migration process does not allow the separation of concern between the DBA and the application administrator as the Kong migration up command always starts by running the keyspace creation command, and stops immediately in case of error during this keyspace creation (including if the root cause is a “not sufficient privilege” error). It is consequently not possible for the application administrator to run Kong migration process.
A possible solution for the Kong migration up command execution would be to first try to “use keyspace”

If OK, then it means that the keyspace already exists and it can proceed to table creation
If not OK, then the process can try to create the keyspace (for backward compatibility with what is done today, and to manage deployments without the separation of concern mentioned above), then it shall “use keyspace” and proceed to table creation (same process as today).
The potential error raised during the keyspace creation (because the user executing the script might not have sufficient privileges) is acceptable as it highlight the fact that the application administrator shall first ask the DBA for the keyspace creation

Another possible solution (more a workaround…) is to comment out the lines 36 to 38 of the kong/dao/migrations/Cassandra.lua file:
35      local res, err = db:query(keyspace_str, nil, nil, nil, true)
36      --if not res then
37      --  return err
38      --end
39
40      local ok, err = db:coordinator_change_keyspace(keyspace_name)
41      if not ok then
42        return err
43      end

If so, keyspace creation is still executed in any case. However, in case of error (whatever it is due to an access right issue or to any other keyspace creation issue), the processing would not be stopped and would continue up to line 40 that runs a “use keyspace” command. Lines 41 and 42 would then handle any of the errors that might be generated at that time, including the case where the keyspace creation has failed before.
If the user running the migration script has sufficient privilege (today’s situation), then both lines 35 and 40 will be executed correctly.
Additional Details & Logs

Kong version 0.11.0

Hi all,
Any feedback on this deployment issue ?
Thanks.


Add moenda engine Node API

Motivation
I am developing a tool similar to linter and would like to integrate moenda into the system to run the rules of the tool, but currently moenda only works for a CLI client, this PR creates new modules enabling the use of Moenda as an API.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
Use the test.js file, but you'll need to create the files required.
const moenda = new Moenda({
 parser: 'md',
  rules: path.resolve(__dirname, './rules'),
  files: [path.resolve(__dirname, './teste.md')],
  processor: require(path.resolve(__dirname, './core/processor.js'))
    .createContext,
  rulesConfig: config,
});

Related PRs or/and Issues
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/SPLAB-UFCG/Moenda, and link to your PR here.)

I'm curious why package-lock json changed a lot, I added one dependency 🤔

missing processor.js?

Actually, when I was creating the files, I didn't structure well 😞  you'll see this module in /tests folder


Update asto to 0.23.4

Update asto to 0.23.4 and TestResource from asto instead of TestResource from rpm.

@rultor release, tag=1.0

@rultor release, tag=1.0

@olenagerasimova OK, I will release it now. Please check the progress here

Job was finished in 1 hours, bonus for fast delivery is possible (see §36)

@rultor release, tag=1.0

@olenagerasimova Done! FYI, the full log is here (took me 12min)


licenses: add BSD-3-Clause-Go

This is the BSD-3-Clause license used by the Go language project.
The motivation for adding this is to add the header version, which
is otherwise not detected.
The license text is copied from:
https://go.googlesource.com/go/+/refs/heads/master/LICENSE

Initial reaction: I don't think we want to merge this.  We don't generally add project specific licenses.
This is https://github.com/google/licenseclassifier/blob/master/licenses/BSD-3-Clause.txt formatted with bullet points (UL) instead of numbered bullets (OL) and copyright holder replaced by "Google inc."
@wcn3 FYI, as this relates closely to what you're working on.

The interesting part (to me) is the header license. If it's possible to add a header without a corresponding full license, that definitely seems like the right approach. The classifier handles the non-header form fine, correctly recognizing it as BSD-3-Clause.
I don't know anything about the classifier internals, so I don't know how much of an issue false positives on the header are likely to be.

This header is short and ambiguous, so may cause issues.  But @wcn3 may have more to say.


[DNM][NP-3321] Fix detailView layout

address:
https://nanopay.atlassian.net/browse/NP-3452
https://nanopay.atlassian.net/browse/NP-3321
summary:
remove display grid layout from the table and make the table scrollable when the contents overflow

note: downside is that a view (i.e., content in the right column) looks cut off if width of the view is large. If you have any other suggestions, I will try to address it.

@jinn9 can you test that your changes don't re-cause this: https://nanopay.atlassian.net/browse/NP-3321
which was fixed with this: https://github.com/foam-framework/foam2/pull/4706

@Nauna Yes, I was aware of the change in https://github.com/foam-framework/foam2/pull/4706 and tested to make sure it doesn't recreate the issue. Still the change I made is up for discussion, and I will bring this topic up during the R&D brainstorming, as suggested by Kevin.


Direct link to GitHub for Content feedback is broken

Original GitHub issue https://github.com/dotnet/docs/issues/8676 from @Structed
On this documentation page, the direct link to leave feedback on GitHub is broken.

Instead, it points to https://docs.microsoft.com/en-us/dotnet/api/%7B0%7D

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

ID: 71654f5f-8c0e-87c9-8b8c-ad17f578d427
Version Independent ID: ab6d5a69-3cbc-fcf7-10f2-6e2deb1ed30c
Content: DataType Enum (System.ComponentModel.DataAnnotations)
Content Source: xml/System.ComponentModel.DataAnnotations/DataType.xml
Product: dotnet-api
GitHub Login: @dotnet-bot
Microsoft Alias: riande

It might be due to the fact that are issues from dotnet-api-docs are configured to go to dotnet/docs. But still this should work given we tell the target repo for issues: https://github.com/dotnet/dotnet-api-docs/blob/master/docfx.json#L53

@jialge Can you take a look at this bug?

This appears to be affecting a lot of repos not just dotnet

I am looking at this now.

This seems to be fixed now, correct?

@mairaw Yes, this is fixed. I will update the status.


Detect UTF-32

Currently only UTF-8 and UTF-16 are detected, with the explanation that the JVM does not support UTF-32.
It would be useful to at least detect UTF-32, even if reading it is not possible.

Enables an app to emit a useful error message.
Some applications only need detection

decode() can throw an IOException if the input is UTF-32.
See:
https://github.com/sigpwned/chardet4j/blob/2737978f2cfc69cadb933f7cca54b4e75f9e16ef/src/main/java/com/sigpwned/chardet4j/ByteOrderMark.java#L27-L50

Good point. We can do more here. Let me poke around this week and see what I see.

I've added support for detecting UTF-32 (among others), and added some methods to help with detection.
If you'd like to decode, then this should work:
try (Reader chars=Chardet.decode(bytes, StandardCharsets.UTF_8)) {
    // Process chars here
} catch(UnsupportedCharsetException e) {
    // The charset was detected, but is not supported by current JVM. There are a
    // few ways this is typically handled:
    //
    // - Propagate as an IOException, since the content cannot be decoded properly
    // - Ignore the error and use a default charset
}

If you just want to detect, one of these should do:
// Throws an UnsupportedCharsetException if the charset is not supported by JVM
Optional<Charset> maybeCharset = Chardet.detect(bytes, declaredEncoding);

// Never throws
Optional<String> maybeCharsetName = Chardet.detectName(bytes, declaredEncoding);

The README is updated as well, which provides further context.
I've released these changes under version 75.1.1. It takes Maven a minute to make new artifacts available, in my experience, but they should be ready by evening at the latest, I should think.
Thanks again for the suggestion! Please don't hesitate to open new issues with any more suggestions or questions!

Amazing! thank you so much!

Shouldn't it be UnsupportedEncodingException and not UnsupportedCharsetException? UTF-32 and UTF-8 both use the same charset (Unicode), don't they?

I love good questions. :)
Unfortunately, Java's handling of encodings and charsets is a bit muddled, IMO.
A charset is a logical set of characters. UTF-1, UTF-7, UTF-8, UTF-16, and UTF-32 are all different encodings for the Unicode character set. You're spot on there. However, Java puts all of these in the Charset class, alongside things like US-ASCII and ISO-8859-1, which are legitimately different character sets. To make things even more confusing, the char type is explicitly required to be a UTF-16 code unit, per the spec, so Java's view of the character encoding and charset world is really just things that convert to and from UTF-16 code units in memory.
So while Java's support for character encodings and character sets is outstanding, its model for same is, well, not so good.
At the end of the day, I opted for UnsupportedCharsetException for a few reasons, in rough order of importance:

It's unchecked, so I can start using it without changing the method signatures of existing code to maintain backwards compatability. UnsupportedEncodingException is checked, which would have broken backwards compatibility.
It was natural the way I wrote the code. I pass around Charset objects internally, so I see UnsupportedEncodingException. If I were passing around names to things like InputStreamReader, then I would be seeing a lot more of UnsupportedEncodingException instead.
It's just newer. New code seems to be using UnsupportedEncodingException, for better or for worse. And since Java's model for character encodings and charsets is a bit fluid anyway, I didn't get too worried about it.

Hopefully that gives a bit of a window into the logic!


[Feature] Add Support for Historical Data Points

Initial implementation to support historical data points by having a new flag addHistoricalMetrics at the job config level
Related to #985
Pending tasks

[ ] Build docker image and test to see if the Prometheus graphs are as accurate as the ones provided by AWS CloudWatch
[ ] Go over the code to change the implementation and use a hashmap to store the "template" metric
[ ] Make the new flag configurable at the metric level to keep it consistent with the other flags!? Check how easy/difficult is going to be
[ ] Add tests
[ ] Linting

I'm planning to make more changes but marking this PR as ready for review to get early feedback

Love the idea of it :)

I'm using this from our environment. Works nice

This would also drastically reduce costs for people who are currently looking to get metrics in a 1 minute resolution (scrape-interval=60s / period=60s / length=60s), right? @gavin-jeong you've been using this for a while without issues?

@ecktom about this PR, seems there are no issue. it works as expected.

@ecktom no any issue yet. seems it works well.

Apologies for the delays on this one. I'm planning to spend some time next weekend refreshing this with the latest from master.
I hope the rebase is not too painful 😢

I completed the rebase locally a while back but I can see that there are more changes lol. Let's see if can get to a "safe" place this week 😭

@luismy would be highly appreciated if you can give it another shot. We also tried to get it rebased but were stuck in some segfaults which we couldn't get right

👋 as the main person who's been driving a lot of the conflicts here I'm sorry @luismy. I honestly didn't realize this existed for so long but I'm "done" enough with the getmetricdata refactoring work I set out to to enablehttps://github.com/nerdswords/yet-another-cloudwatch-exporter/issues/1094 that should prevent further major conflicts. I will leave a comment with a suggestion that I think could cleanup the implementation and will happily help with conflict resolution if needed.


Analyzer calculates volatility and returns it either

The reason Analyzer calculate volatility constantly is to know the strong change of trend.

Consider the recent historic level of volatility when the Analzyer calculate the strength signal.

Volatility will be calculated before market opens.


Couldn't find rpy v2.9.5

The most recent version available on Anaconda is v2.9.4, could this be a typo in requirements.txt?

Actually on PyPI it looks like the latest version is 3.0.4:
https://pypi.org/project/rpy2/
I'd recommend installing via pip. Does that work for you?

Thanks for the response, Tony.
I initially tried installing via the pip command suggested in the README, but encountered an issue with the installation of rpy, which is why I tried Anaconda as an alternative. You are correct that the latest version is 3.0.4. It was my fault for trying to install in a way that was not intended.
I will open a separate issue for the pip installation problem.


Security exception Elmah.AccessErrorLog in a Medium Trust

From @atifaziz on August 25, 2015 16:35
What steps will reproduce the problem?

Configure an ASP.net 4.0 web site with <trust level="Medium" />
Add Elmah
Configure Elmah AccessErrorLog

For obvious security reason I copied a precreated Elmah.MDB file into the App_Data folder.
but during elmah initialisation the system throw the following Security Exception:
Stack Trace:
[SecurityException: Request failed.]
   Elmah.AccessErrorLog.InitializeDatabase() +0
   Elmah.AccessErrorLog..ctor(IDictionary config) +59

Version Information:
Microsoft .NET Framework Version:4.0.30319;
ASP.NET Version:4.0.30319.272

Originally reported on Google Code with ID 323
Reported by damiano.gambarotto on 2013-01-02 11:10:01
Copied from original issue: elmah/Elmah#323

I think the promlem is
ProcessStartInfo psi = new ProcessStartInfo("cscript", "\"" + scriptPath + "\" \""
+ dbFilePath + "\" //B //NoLogo");

see
http://msdn.microsoft.com/it-it/library/system.diagnostics.processstartinfo(v=vs.100).aspx

Reported by damiano.gambarotto on 2013-01-02 13:54:03


Add some doc for Twig Extension

While reading the doc and opening https://github.com/symfony/symfony-docs/pull/16292 as well

@bocharsky-bw  thanks for the first approval
I've reworded the comment to point to the documentation instead, perhaps a new check would be great, thank you

Thank you Antoine.


cmd/compile: 63% benchmark slowdown in 1.7 ->  1.8rc2

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
$ go version
go version go1.7 darwin/amd64
$ go1.8rc2 version
go version go1.8rc2 darwin/amd64
What operating system and processor architecture are you using (go env)?
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/smansfield/gopkg"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f2/wwlcfvc5267dkl3c2_5_mcsw0000gp/T/go-build461692826=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
I have the disasm output for both 1.7 and 1.8 with a command to run benchtime 10s
1.7: https://play.golang.org/p/N04n8MwmS4
1.8: https://play.golang.org/p/sZpOz59PbS
What did you expect to see?
Approximately equal or better performance
What did you see instead?
Worse performance by far for 1.8, by 63% - 65%
What's interesting in the 1.8 output is that the profiling shows a single MOVL taking 4.98 of the 9.37 seconds
4.98s    1144938: MOVL 0x30(SP), CX
Unfortunately the code to do all this is private, but I might be able to extract an example if it's necessary. Right now I don't have one outside my project.

I think a code example will probably be necessary.

Of at least that function.
Unless @randall77 or @josharian can tell by glancing at the assembly output.

I'm working on extracting the function and the inputs the benchmarks generate

I see nothing obviously wrong with the assembly.  I see no reason why that particular instruction should be slow - it's just reading a stack slot that was written dozens of instructions ago.

Got it isolated. Right now I have an example of the benchmark case that had the worst slowdown. Unfortunately the benchmark included somewhat large generated input data, so I have had to manually include that as very large arrays. I can work on a smaller one, but this shows pretty easily the slow down.
I can't paste it at play.golang.org (I get a server error) so I put it in a github gist: https://gist.github.com/ScottMansfield/c129bd11b66a19e50ed1bab1444bd389
I see not quite the same, but still significant, difference. Running the benchmark 30 times each I get:
$ benchstat go1.7 go1.8rc2
name          old time/op  new time/op  delta
Issue18740-8  26.1µs ± 3%  40.5µs ± 2%  +55.31%  (p=0.000 n=30+29)

go1.7, for binary.LittleEndian.Uint32(b), is generating
movzwl 0x38(%rsp),%eax
movzbl 0x3a(%rsp),%ecx
shl    $0x10,%ecx
or     %ecx,%eax
movzbl 0x3b(%rsp),%ecx
shl    $0x18,%ecx
or     %ecx,%eax

while go1.8 is generating
mov    0x38(%rsp),%eax

this is due to 26a6131bacb5dbc491f77329557580df0a310858.
Unfortunately the single mov generated by 1.8 is stalling the CPU at the following instruction, a mov generated by the if curId == id line, (which is present, unchanged, in both 1.7 and 1.8):
mov    0x68(%rsp),%ecx

If you substitute the following line:
curID := binary.LittleEndian.Uint32(b)

with:
_ = b[3]
curId := uint32(b[0]) | uint32(b[2])<<16 | uint32(b[1])<<8 | uint32(b[3])<<24

the performance is restored to go1.7 levels (at least on my machine).

So, increased memory latency due to unaligned memory access in 1.8.  Interesting to read and compare with http://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/

This looks like some sort of partial read/write stall.
Compare these two benchmarks:
var g [4096]byte
var sink uint32

func BenchmarkA(b *testing.B) {
	for j := 0; j < b.N; j++ {
		s := uint32(0)
		for i := 0; i < 4096; i += 4 {
			s += binary.LittleEndian.Uint32(g[i:])
		}
		sink = s
	}
}

func BenchmarkC(b *testing.B) {
	var buf [4]byte
	for j := 0; j < b.N; j++ {
		s := uint32(0)
		for i := 0; i < 4096; i += 4 {
			copy(buf[:], g[i:])
			s += binary.LittleEndian.Uint32(buf[:])
		}
		sink = s
	}
}

1.7 to 1.8:
BenchmarkA-8     1948          1340          -31.21%
BenchmarkC-8     5419          7477          +37.98%

BenchmarkA is faster probably exactly because of the load combining in the binary.LittleEndian.Uint32 call that 1.8 does.  Alignment doesn't matter, I get approximately the same performance if we load from g[i+1:] instead.
The copy is what makes BenchmarkC fall over.  I think what is happening is that the copy is done inside memmove with 2 2-byte load/store, and then we read the result with a 4-byte load.  I'm guessing the processor is barfing (stalling somehow) on such a combination.  In 1.7, we do 2 2-byte load/stores and then 4 1-byte loads, which the processor can handle effortlessly.
If I fix memmove to use a 4-byte load/store in the 4 byte case, that fixes BenchmarkC.
BenchmarkA-8     1948          1349          -30.75%
BenchmarkC-8     5419          4987          -7.97%

Patch:
--- a/src/runtime/memmove_amd64.s
+++ b/src/runtime/memmove_amd64.s
@@ -146,10 +146,16 @@ move_1or2:
 move_0:
        RET
 move_3or4:
+       CMPQ    BX, $4
+       JB      move_3
+       MOVL    (SI), AX
+       MOVL    AX, (DI)
+       RET
+move_3:
        MOVW    (SI), AX
-       MOVW    -2(SI)(BX*1), CX
+       MOVB    2(SI), CX
        MOVW    AX, (DI)
-       MOVW    CX, -2(DI)(BX*1)
+       MOVB    CX, 2(DI)
        RET
 move_5through7:
        MOVL    (SI), AX

@TocarIP : Intel guys, does this sound right?  Expected?
I'll prepare a CL.

CL is https://go-review.googlesource.com/c/35567/

Looks like store-forwarding issue.
Optimization manual says  (<IP_ADDRESS>):
The following rules must be met for store to load forwarding to occur
...
The store must be equal or greater in size than the size of data being loaded

Just to be sure I've collected perf events ( ld_blocks_store_forward).
As expected, there is a 3 orders of magnitude difference
301,876,563 vs 276,025 (before vs after patch)


Meteor cannot start when using with nami

I am using npm nami package inside Meteor app to listen to events from an Asterisk server. In server side, I have this code:
namiLib = Meteor.npmRequire "nami"
namiConfig =
    "host": "..."
    "port": 5038
    "username": "..."
    "secret": "...
nami = new namiLib.Nami namiConfig

If I remove the line nami = new namiLib.Nami namiConfig, the server runs fine. But with that line, the server stops at following step, and I cannot access http://localhost:3000, which is the default url for Meteor app. Nami package prevents Meteor from starting.

Any idea to help resolve this issue?
I have posted this question on Stackoverflow but still no solution except using other package instead of nami.
http://stackoverflow.com/questions/28430613/meteor-cannot-start-when-using-meteorhacksnpm-nami-package-cannot-access-loca/28445368?noredirect=1#comment45222484_28445368

Hello. I have to close this one until there's a clear sign of an issue in Nami itself and not in your code or meteor. Feel free to reopen it with specific details if you think this is a nami issue.

I used other package, e.g., asterisk-manager and it works fine. Seems that Nami has blocked other execution.

I'm not a meteor user, so perhaps you could try to debug and find out what could be wrong


Enable null in regex character classes

Closes https://github.com/NVIDIA/spark-rapids/issues/5909
Enable the null terminator \u0000 in character classes, character class ranges, and in the POSIX predefined character classes.

build


Error if using along with seo tools plugin

Hello, first of all, this is a great tool that you have here, It can be very useful for using Sanity with Typescript!
I understand that right now there is no support for additional types, which is not the problem I'm facing.
When I use the SEO plugin  I need to include a "seo-tools" type in the document, like this:
{
      name: "seo",
      title: "SEO",
      type: "seo-tools",
      options: {...},
}

It seems that the generator doesn't like that naming and throws
Error: Name "seo-tools" is not valid. Ensure camel case, alphanumeric and underscore characters only

I'm not very familiar if snake case is a valid type name, but since SEO tools are using it, I'm guessing it is. Would you consider adding this to the validation rules?

This one is kind of interesting actually. Looking at the sanity docs for object names, they actually explicitly say that fields cannot include a hyphen.

Field names
A field name must start with a letter from a-z, and can can only include:

Letters
Numbers
Underscores

This means field names can't contain hyphens. We also recommend using the camel case naming convention for field names.

https://www.sanity.io/docs/object-type#field-names-9a9a8b5c6404

I mean it works and that's a sanity-backed plugin so I guess those same rules don't apply to document names?
Let me think on this for a sec. Thanks for bringing this to my attention!

This one is kind of interesting actually. Looking at the sanity docs for object names, they actually explicitly say that fields cannot include a hyphen.

Field names
A field name must start with a letter from a-z, and can can only include:

Letters
Numbers
Underscores

This means field names can't contain hyphens. We also recommend using the camel case naming convention for field names.

https://www.sanity.io/docs/object-type#field-names-9a9a8b5c6404

I mean it works and that's a sanity-backed plugin so I guess those same rules don't apply to document names?
Let me think on this for a sec. Thanks for bringing this to my attention!

Maybe I misunderstand it but isn't this for object names. Like the name: "seo" part of the snippet above. Not the actual type of the document

Maybe I misunderstand it but isn't this for object names. Like the name: "seo" part of the snippet above. Not the actual type of the document

Oh sorry I forgot some context. I followed the link you sent to the seo-tools repo and my confusion (and maybe this just me complaining 😅) is that Sanity disallows hyphens in object field names but allows it in document names.
Referring to this:
https://github.com/LiamMartens/sanity-plugin-seo-tools/blob/88c116fc24cf41d86d584d1a506532ed7c3ec43b/src/schema/index.tsx#L4

Oh sorry I forgot some context. I followed the link you sent to the seo-tools repo and my confusion (and maybe this just me complaining 😅) is that Sanity disallows hyphens in object field names but allows it in document names.
Referring to this:
https://github.com/LiamMartens/sanity-plugin-seo-tools/blob/88c116fc24cf41d86d584d1a506532ed7c3ec43b/src/schema/index.tsx#L4

Ohh, yeah, that makes sense now. It's not an official plugin, but it's "Featured" on their website, so I'm guessing the naming is legit.
Perhaps they disallow it only in the fields?
E.g. this is ok:
{
  type: 'object',
  name: 'this-is-a-person',
  fields: [
    {
      title: 'Name',
      name: 'name',
      type: 'string'
    }
  ]
}

This is not:
{
  type: 'object',
  name: 'this-is-a-person',
  fields: [
    {
      title: 'Name',
      name: 'this-is-a-name',
      type: 'string'
    }
  ]
}

Ohh, yeah, that makes sense now. It's not an official plugin, but it's "Featured" on their website, so I'm guessing the naming is legit.
Perhaps they disallow it only in the fields?
E.g. this is ok:
{
  type: 'object',
  name: 'this-is-a-person',
  fields: [
    {
      title: 'Name',
      name: 'name',
      type: 'string'
    }
  ]
}

This is not:
{
  type: 'object',
  name: 'this-is-a-person',
  fields: [
    {
      title: 'Name',
      name: 'this-is-a-name',
      type: 'string'
    }
  ]
}

https://github.com/ricokahler/sanity-codegen/pull/61#issuecomment-762434472

https://github.com/ricokahler/sanity-codegen/pull/61#issuecomment-762434472

@ricokahler I'm still getting an issue when using the SEO plugin with 0.8.2
"sanity-codegen": "^0.8.2"

import path from 'path';
import { SanityCodegenConfig } from 'sanity-codegen';

const config: SanityCodegenConfig = {
  schemaPath: path.resolve(
    __dirname,
    '../../../universal-content/schemas/schema.js'
  ),
  outputPath: path.resolve(__dirname, './schema.ts'),
  babelOptions: {
    ignore: [], // <-- this resets the ignore option (but makes codegen super slow)
  },
};

export default config;

@ricokahler I'm still getting an issue when using the SEO plugin with 0.8.2
"sanity-codegen": "^0.8.2"

import path from 'path';
import { SanityCodegenConfig } from 'sanity-codegen';

const config: SanityCodegenConfig = {
  schemaPath: path.resolve(
    __dirname,
    '../../../universal-content/schemas/schema.js'
  ),
  outputPath: path.resolve(__dirname, './schema.ts'),
  babelOptions: {
    ignore: [], // <-- this resets the ignore option (but makes codegen super slow)
  },
};

export default config;

@NK-WebDev let me know how v0.8.3 works for you

@NK-WebDev let me know how v0.8.3 works for you

@ricokahler Thank you for all your hard work and quick response ❤
It's working for me now.
I did get this log, but I don't think It's gonna be a problem for our project right now
Could not find types for: "SeoTools", "Table". Ensure they are present in your schema. Future versions of sanity-codegen will allow you to type them separately.
[SanityCodeGen]: types written out to /home/nirjan/work/digital-media/manifold/packages/manifold-services/schema.ts)

@ricokahler Thank you for all your hard work and quick response ❤
It's working for me now.
I did get this log, but I don't think It's gonna be a problem for our project right now
Could not find types for: "SeoTools", "Table". Ensure they are present in your schema. Future versions of sanity-codegen will allow you to type them separately.
[SanityCodeGen]: types written out to /home/nirjan/work/digital-media/manifold/packages/manifold-services/schema.ts)


[DO NOT MERGE] Test whether tests pass in ocis

This PR tests whether https://github.com/owncloud/core/pull/37496 passes in ocis.

This PR successfully passed in CI


Pathslider responsive

Hi Rob,
Is there a way to make the pathslider responsive?  Thanks!

Hi @rr20eid10!
What exactly do you mean by responsive? Currently, if you resize the browser window, the grip position is updated to ensure it is still positioned correctly on the curve.

I'm not sure what's wrong but when I resize the browser (Chrome 52.0.x) the svg graph resizes, but the slider isn't resizing.
screen >1140px

screen <600px

<svg width="100%" height="100%" viewbox="0 0 800 600" preserveAspectRatio="none" class="graph" aria-labelledby="title" role="img">
                          <title id="title">Conversion</title>
                        <g class="grid x-grid" id="xGrid">
                          <line x1="90" x2="90" y1="5" y2="371" ></line>
                        </g>
                        <g class="grid y-grid" id="yGrid">
                          <line x1="90" x2="705" y1="370" y2="370"></line>
                        </g>
                          <g class="labels x-labels">
                          <text x="100" y="400">15</text>
                          <text x="190" y="400">25</text>
                         . . .
                        </g>
                        <g class="labels y-labels">
                          <text x="80" y="15">1K</text>
                         . . .

                        </g>
                        </svg>

Would you please set up a JSFiddle demo. And make sure to use the files from the gh-pages domain:

https://mottie.github.io/Pathslider/css/pathslider.css
https://mottie.github.io/Pathslider/js/jquery.pathslider.js

Hmm, maybe you can try this code: http://stackoverflow.com/questions/4288253/html5-canvas-100-width-height-of-viewport
Don't use the window dimensions! Instead use the div wrapper dimensions to apply to the canvas.

Hi Rob,
I read through the link on SO, thank you!  There's a few answers there and although one is marked as the right answer, some commenters claim it's wrong. :)  I'll have to read carefully.

Don't use the window dimensions! Instead use the div wrapper dimensions to apply to the canvas

I'm not sure I understand what you mean use div wrapper dimensions?
Here's a fiddle of my code.  I don't know why nothing is displaying in the fiddle.  Also, when I resize, the slider (in my browser Chrome on my box) turns black (it looses the gradient and the end gray color).  When  I refresh the window, the gradient returns, but turns to black again on resize.  Thanks.


Kafka connector revamp, schema registry support, py-operators

This PR supersedes #312
It started as a PR to support schema registries, but ended up a revamp of the whole connector, in preparation for when we'll move this to its own repository.
Module structure
I split the bytewax.connectors.kafka module into different files:

__init__.py: now only exposes the public api
message.py: Definition of KafkaMessage
operators.py: custom kafka specific operators
registry.py: Registry related stuff
serde.py: Kafka's own (de)serialization interface
sink.py: KafkaSink definition
source.py: KafkaSource definition
_types.py: Typing stuff, private, for internal use

KafkaSource changes
KafkaSource now returns a stream of KafkaMessage rather than a stream of (key, value) tuples.
Users can decide to still key the stream on KafkaMessage.key, but they can also do anything else.
KafkaMessage includes all the metadata we get from each message, including an optional KafkaMessage.error field to hold error info.
KafkaSource now accepts a raise_on_error parameter (True by default). If set to False, errors while receiving kafka messages won't crash the dataflow, and the error itself will be set into KafkaMessage.error
Other than that, KafkaSource and KafkaSink are the same.
Schema registry support
The connector offers a SchemaRegistry abstract class that can be subclassed to implement support for a specific schema registry.
Two implementations are offered:

ConfluentSchemaRegistry
RedpandaSchemaRegistry

You instantiate the schema registry object you want, then use SchemaRegistry.serializer and SchemaRegistry.deserializer functions to instantiate a specific (de)serializer.
You can specify a schema either by its schema_id, or using the SchemaRef object, specifying the subject and optionally the version of the schema:
registry = RedpandaSchemaRegistry(redpanda_url)
key_deserializer = registry.deserializer(SchemaRef("key-schema"))

Custom operators
This PR introduces some new custom operators.
kafka_in and deserialize* operators return an object with two named streams: oks and errors. Users can ignore errors, log them, or still crash the dataflow by using the raises operator.
kafka_in
Wraps a KafkaSource, forcing raise_on_errors to False to return a stream of ok messages and another of error messages:
from bytewax.connectors.kafka import operators as kop
# ...
flow = Dataflow("schema_registry")
kinp = kop.kafka_in("kafka-in", flow, brokers=KAFKA_BROKERS, topics=IN_TOPICS)
op.inspect("inspect-msgs", kinp.oks)
op.inspect("inspect-errors", kinp.errors).then(op.raises, "raise-on-error")

deserialize_key
# ...
key_de = registry.deserializer(SchemaRef("sensor-key"))
msgs = kop.deserialize_key("key_de", kinp.oks, key_de)

deserialize_value
# ...
key_de = registry.deserializer(SchemaRef("sensor-value"))
msgs = kop.deserialize_value("value_de", kinp.oks, value_de)

deserialize
This chains deserialize_key and deserialize_value:
# ...
key_de = registry.deserializer(SchemaRef("sensor-key"))
val_de = registry.deserializer(SchemaRef("sensor-value"))
msgs = kop.deserialize("de", kinp.oks, key_deserializer=key_de, val_deserializer=val_de)

serialize_key
# ...
key_ser = registry.serializer(SchemaRef("sensor-key"))
serialized = kop.serialize_key("key_ser", msgs, key_ser)

serialize_value
# ...
val_ser = registry.serializer(SchemaRef("aggregated-value"))
serialized = kop.serialize_value("val-ser", msgs, val_ser)

serialize
# ...
key_ser = registry.serializer(SchemaRef("sensor-key"))
val_ser = registry.serializer(SchemaRef("aggregated-value"))
serialized = kop.serialize("ser", msgs, key_serializer=key_ser, val_serializer=val_ser)

kafka_out
# ...
kop.kafka_out("kafka-out", serialized, brokers=KAFKA_BROKERS, topic=OUT_TOPIC)

Ok, as soon as CI passes I'm merging this. The only open point is restrict the key and value types in the output operator (see the comment), but we don't need to block the new release for this and can do that later on.

Looks good. A few last minor comments. Thanks for all the back and forth here. I'm very happy we've hammered out some new patterns for using generics and errors and serialization that we can use elsewhere now.

Yes, I learned a lot about python type hints with this PR, thanks for the several rounds of reviews here


Remove preprod paas env from workflow

Context
Remove preprod paas env from workflow after preproduction_aks has been successfully migrated
Changes proposed in this pull request
Remove the preprod paas env from the workflow and from the
Remove preprod from the scheduled DB copy
Checklist

[ ] Attach to Trello card
[ ] Rebased main
[ ] Cleaned commit history
[ ] Tested by running locally

 Remove the Preprod PaaS Workflow


[Doc] add json_keys/length and array_cum_sum

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

@mergify backport branch-2.4

run starrocks_admit_test


date-input and normalization

I write this suggestion once and maybe it's breaking too much code but well – if I could design the input of dates I would keep the current format:
some written date-text <2021-01-12>
1.2.2012
2021-12-09
but if the parser is able to understand and import an iso-date it should empty the written date field. so in all given examples the written-date would be empty except for the first one, where it should be just some written date-text without the part in <…>
in short: the iso-part from an written date is removed. written date only contains text, when it's different from the iso-date.
currently it is difficult to handle if the written date is the same as the iso-date

After consideration IRL this is not helping. So let's forget it


bug/#1226 refactor to include other exposed type in enterprise

What type of PR is this? (check all applicable)

[ ] Refactor
[x] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description
Related Tickets & Documents
#1226

I'll test it when released in a dev version


Migrate Junk Away from Controllers

Create a lib instead.... Refactoring

Reopening this until you guys merge with master.

closed in #44