Annotation Sources Showing in Annotations Tab

Work in progress... still need to resolve hidden Annotation Sources when Manifest has a TOC.

Tabs and other events are being re-bound every time a new object is loaded into the window. Refactor window to not call its own init function.


Make Lockscreen notification Visible

1.make notification visible on lockscreen
2.add Chninese Translation

This does fix the issue, but it kind of breaks the idea of making the notification always dismissable, and instead sends an ongoing notification by default, and only makes it dismissable when the always dismissable switch is enabled and nothing is playing.
Recommended fix: replace the "always dismissable" switch with a drop-down allowing users to select either "always", "only when paused", or "never". I'll work on this tomorrow if I have time.

Ok,i will have a try later


certificate can be downloaded as pdf

merge this pull request @Durgesh4993

@Krishna100604 Resolve Conflicting files

@Krishna100604 ?

@Krishna100604 ?

i think you merged some wrong pull request and that is conflicting with mine so that's why this issue is occuring you can pull my request and the code you pulled yesterday has made css bad you can cross check it


Slim support

Would love Slim support.
https://github.com/sds/slim-lint/blob/master/lib/slim_lint/linter/rubocop.rb

When to expect?

Beta release is now in production. You can opt-in by adding this to .hound.yml:
slim_lint:
  enabled: true


Add links to google-cloud-logging log correlation examples.

Codecov Report

Merging #1339 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1339      +/-   ##
============================================
+ Coverage     83.16%   83.17%   +0.01%
  Complexity     1368     1368
============================================
  Files           218      218
  Lines          6604     6604
  Branches        601      601
============================================
+ Hits           5492     5493       +1
  Misses          947      947
+ Partials        165      164       -1

Impacted Files
Coverage Δ
Complexity Δ

...census/implcore/trace/export/SpanExporterImpl.java
93.15% <0%> (+1.36%)
8% <0%> (ø)
: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 c7d36a0...5418a08. Read the comment docs.

Thanks!


How to read many images and how to use with python

The tool only supports processing one image per call. If you want to process many images just create a loop in a shell script. If you need more efficiency you could parallelize for example using GNU parallel.
The tool itself is a single command line tool, not a library or including a python wrapper. You could call from python the tool for example using popen. Alternatively there is kind of a successor to imgtxtenh which is a library and has a python wrapper. However, there are a few differences with respect to imgtxtenh, it is not well documented and it is not available to install from pypi. So you need to build it yourself. You can find the source code at https://github.com/omni-us/pagexml/tree/master/py-textfeat and the automatically generated API documentation at https://omni-us.github.io/pagexml/py-textfeat/.

thank you very much


Folder styling disappears on hover

Hello, I really appreciate the work done so far on this plugin.
However a big issue for me currently is that even if you applied a color or a bold font to the folder, it disappears on hover, which is quite off-putting.
I would try to help, but my Typescript skills are very limited.
Again, thank you for working on this plugin!

Hi @TaouMou , thanks for the feedback. I'm glad you're enjoying the plugin. I've just uploaded version 1.4.0, with the changes for hover styling. I can't make it track folders by ID, however.
I've also added a new style snippet which works with the Style Settings plugin, and lets you style filenames based on their extension. The Color-Folders-Files plugin styling takes precedence, and I think that the two work quite well together.


Some blocks prevent the app from generating the pack

if your exported structure contains one of the following blocks (there are many I will edit this as i find more) the pack won't generate:
-shulker box
-barrel
-grindstone
-extended piston

If you want a local work around. go into Vanilla_Resource_Pack\textures\blocks open the .tga files, export as png.
If you know how to use git, branch and submit a PR and i will take it.
If anyone sees this bug before i get to it, i will take a pr on it gladly

If you want a local work around. go into Vanilla_Resource_Pack\textures\blocks open the .tga files, export as png.
If you know how to use git, branch and submit a PR and i will take it.
If anyone sees this bug before i get to it, i will take a pr on it gladly

Adding the fixed images here, getting ready for a patch of these, they are simple to fix

Will be fixed in the next update

Adding the fixed images here, getting ready for a patch of these, they are simple to fix

Will be fixed in the next update

-grindstone_side
-stonecutter2_saw
-cactus_side
-seagrass_doubletall_top_a
-kelp_top
-reeds
-more to be added since I've encountered a different error

-grindstone_side
-stonecutter2_saw
-cactus_side
-seagrass_doubletall_top_a
-kelp_top
-reeds
-more to be added since I've encountered a different error

Fixed in 1.1.1

Fixed in 1.1.1


Huge untracked gap in timeline for E2EWidgetsFlutterBinding

I'm verifying the overhead of e2e and WidgetTester and find a weird timeline scheduling:
With e2e binding, the timeline looks like:

while normally it looks like (profile mode):

and even debug mode is faster than this:

where there's a huge gap with no timeline event tracked. The json file for the above timeline graphs is here:
https://drive.google.com/drive/folders/13yhs4ebggOi8tk4WOk7Kxdd3RPaM2UDR?usp=sharing
The above can be reproduced by:
A minimal demo here: https://github.com/CareF/timeline_scheduling
The profile result is given by running
flutter run --start-paused --profile

or
flutter run -t test/runapp_e2e.dart --start-paused --profile

press v to open DevTools; and copy URL and open Observatory -> debugger -> press c to continue.
The above result is tested on a Pixel 4.

cc @liyuqian

We are suspecting that there's a bug in scheduling. Any suggestions where to look are very appreciated!

CC @dnfield @albertwang0116 and @cyanglaz to see if there's any thought on this. (BTW, I wonder if plugins are the biggest user of e2e inside Flutter team?)
The json attached above can be loaded from about:tracing in Chrome. Within a 1-second time window, I can see a lot of frame requests in the UI thread, but only 1 raster thread frame rasterization. Neither thread seems to be busy at doing any work.

You probably want to try setting the binding's scheduling policy to fullyLive, or at least to benchmark. Can you share the reproducing code?

Ahh sorry, I see the link now.  I think here: https://github.com/CareF/timeline_scheduling/blob/master/test/runapp_e2e.dart#L15
Try instead:
final E2EWidgetsFlutterBinding binding = E2EWidgetsFlutterBinding.ensureInitialized() as E2EWidgetsFlutterBinding;
binding.framePolicy = LiveTestWidgetsFlutterBidningFramePolicy.fullyLive;

Ahh sorry, I see the link now. I think here: https://github.com/CareF/timeline_scheduling/blob/master/test/runapp_e2e.dart#L15
Try instead:
final E2EWidgetsFlutterBinding binding = E2EWidgetsFlutterBinding.ensureInitialized() as E2EWidgetsFlutterBinding;
binding.framePolicy = LiveTestWidgetsFlutterBidningFramePolicy.fullyLive;

Thanks. This solves the problem!

We should either document this better or make the API usage clearer - perhaps adding it as a optional named parameter in ensureInitialized.


Upgrade to OpenSSL 1.1.1 (LTS)

I upgraded all rubies depended on OpenSSL 1.1.0x to OpenSSL 1.1.1 (LTS). I tried to compile several rubies, and no problem occurred.

@hsbt there are any known problems with OpenSSL 1.1.1 from ruby-core side?

I'm not sure that current stdlib fully supports OpenSSL 1.1.1 now. @rhe Can you confirm this?

@hsbt Hello, why https://github.com/rbenv/ruby-build/commit/62c391df5af391a519a1c53d07b1879d9ddf7fa2 or https://github.com/rbenv/ruby-build/commit/01fbd545adb4bce45da4fd494cc1e16331002a9e use OpenSSL 1.1.1?

@hsbt ^^

why 62c391d or 01fbd54 use OpenSSL 1.1.1?

There is no reason. I have no opinion about OpenSSL version.

#1306 should be a good test of OpenSSL 1.1.1c if we merge it since it's just a 2.7.0-preview1 and won't impact too many people.

@hsbt Is there anything other than Net::HTTP I can use to test OpenSSL 1.1.1? See: https://github.com/rbenv/ruby-build/pull/1306#issuecomment-497511754

IMO, We should upgrade openssl-1.1.1 with Ruby 2.5+. Because Ruby 2.4 is security maintenance status. If we got an issue related to openssl-1.1.1, We couldn't fix it.

@eregon Is it okay to be bumping OpenSSL to 1.1.1 for truffleruby as well?

@mislav OpenSSL 1.1.1 should be fine for TruffleRuby as well (I use 1.1.1c locally, TruffleRuby uses the same OpenSSL C extension as MRI).


Add a test for the TCP_USER_TIMEOUT option.

See #1188, #1190

cc @yossigo I need a review approval to merge :). Or feel free to merge if you prefer.


Codify the pony(min)threads behavior

Draft in order to fix #3152
This won't work… I have many questions already but, wrt the issue at hand:

Should we introduce some value as a magic value for "not provided" (e.g. -1, tho it's currently a uint32_t;
Only allow for --ponynoscale when --ponyminthreads wasn't provided?
What about if --ponyminthreads == --ponythreads and yet --ponynoscale is provided; these two would effectively mean the same thing…

Trying to get the discussion going… I'll then wrap this up (and update the usage and other docs if these exists)

Took a shot at prohibiting --ponyminthreads && --ponynoscale at the same time… Let me know what you think and if that all makes sense, let's update the doc.

Magic value for what but being provided?
By default minthreads default should be 0.
I think your other questions are answered in the ticket. See https://github.com/ponylang/ponyc/issues/3152#issuecomment-503211484

Should have added a note, I think the latest stuff does that:
$ ./helloworld --ponyminthreads=0 --ponytherads=2
Hello, world.

From sync. We believe there should be a flag for "don't scale my threads".
And --ponyminthreads will error out if it is greater than --ponythreads.

$ ./helloworld --ponyminthreads=20 --ponytherads=2
Can't have --ponyminthreads > --ponythreads (20 > 0)

--ponynoscale is the current idea for turning off scaling.

$ ./helloworld --ponynoscale --ponythreads=20
Hello, world.
$ ./helloworld --ponynoscale
Hello, world.

if --ponynoscale is used on application startup then it should be a startup error to use --ponyminthreads.
$ ./helloworld --ponyminthreads=20 --ponynoscale
--ponyminthreads & --ponynoscale are mutually exclusive
 $./helloworld --ponyminthreads=20 --ponythreads=20 --ponynoscale
--ponyminthreads & --ponynoscale are mutually exclusive
$ echo $?
255

I just use a bool to see whether --ponyminthreads=0 was set by the user explicitly (as 0 is fine). I think that covers it just fine…
Open questions:

[ ] return code? -1 (-> 255) reused the default of the switch statement, but they mean different thing. Should there be or is there a return value (>0) for these kinda errors?
[ ] Should we deal with negatives properly? How? Validate the argument was >= 0?

$ ./helloworld --ponyminthreads=-1 --ponythreads=20
Can't have --ponyminthreads > --ponythreads<PHONE_NUMBER> > 20)

Alright, I think that's fairly complete. Added the check for when not specifying --ponythreads as so:
$ ./helloworld --ponyminthreads=2048
Can't have --ponyminthreads > physical cores (2048 > 6)

Let me know what you think!

Alex this looks pretty good.
Small thing. You are checking to see if minthreads is greater than cores. We discussed and think that that should be if threads is greater than number of cores, it should be disallowed.
Once that is in, do you feel comfortable updating the performance cheat sheet section related to this?
https://www.ponylang.io/reference/pony-performance-cheatsheet/#ponythreads

I'm not sure of all the permutations of things to check for. Minthreads without setting threads is something I'd never do. But I guess you could do it (although in my mind it would be odd) so I can see how having that check makes sense.
-1 for return exit seems fine to me. Can always be changed later.
Are you asking if there should be checks to make sure someone doesn't do --ponyminthreads=-1 ?

I'm not sure of all the permutations of things to check for. Minthreads without setting threads is something I'd never do. But I guess you could do it (although in my mind it would be odd) so I can see how having that check makes sense.

I agree it's not really sensible to me neither, but would it in virtualized environments? Where I don't ever want less than 2 threads, but say for some reason I'm deploying on a single vCPU node? Dunno… nothing prohibits setting --ponyminthreads w/o --ponythreads or should it become a requirement to set both?
In anycase, I think 36d91237528c74c30c33586e7f68331bd490e873 does what you wanted (i.e. check for --ponythreads being <= cores available…

Are you asking if there should be checks to make sure someone doesn't do --ponyminthreads=-1 ?

Yeah, cause currently:
$ ./helloworld --ponythreads=-1
Can't have --ponythreads (the number of threads you'd be running with) > physical cores<PHONE_NUMBER> > 6)

Which might be surprising to some (tho to others, the issue is probably very obvious!)

btw, I realize the --ponyminthreads can be clarified at the doc level, i.e. --ponyminthreads=2048 is either the value provided or the --ponythreads, whatever is smaller and where the latter defaults to the number of cores… I can take a shot at trying to clarifying it this way, and get rid of the actual check

I'm not worried about the negative value issue, but checking it isn't less than 0 and reporting on that would be a nice UI improvement. I think that would make sense as a commit unto itself.

btw, I realize the --ponyminthreads can be clarified at the doc level, i.e. --ponyminthreads=2048 is either the value provided or the --ponythreads, whatever is smaller and where the latter defaults to the number of cores… I can take a shot at trying to clarifying it this way, and get rid of the actual check

I didn't follow that. Sorry, can you try saying in another way?

--ponyminthreads=2048 is either the value provided or the --ponythreads, whatever is smaller and where the latter defaults to the number of cores

sounds wrong to me. if ponyminthreads is greater than ponythreads, that should error out. which is not what i think you are saying in the quoted bit.

Cool, I'll prepare all of this in a cleaned up commit history and with all the changes discussed.
I'll summarize in another comment here and (hopefully) the doc changes make it all clear in any case. Thanks for the review 🙏 !
(I'll start tonight, but … will probably push it all only tomorrow)

I can avoid the explicit check, and let the code in scheduler.c reduce minthreads to threads "silently" (the code I added was trying to avoid silently changing user settings), if you think that's preferable. But in that case I'd be explicit about it in the docs…

Still not sure I follow. But, I'm in favor of explicit checks and explicit errors as a general rule of thumb.

Right, but ponythreads is "only" set in scheduler.c in case it was not explicitly specified…

Sorry @alexsnaps. I still didn't follow that.

Still not sure I follow. But, I'm in favor of explicit checks and explicit errors as a general rule of thumb.

No worries, that last bit:

I'm in favor of explicit checks and explicit errors

Is what I'm arguing for too! So I'll just:

[ ] consolidate,
[ ] update all the docs,
[ ] add a summary to this PR of the changes;

And hopefully we can agree this all makes sense :)
Code speaks best…
As I said on Zulip tho, and as you can now see here, I trust my code more than my English sentences, so please, please, double review the error messages! :)

Sounds good @alexsnaps!

So here's the consolidated output & errors on my 6 core CPU:
$ ./helloworld
Hello, world.

Behavior is unchanged
 $ ./helloworld --ponyminthreads=12
Can't have --ponyminthreads > --ponythreads (12 > 6)

--ponythreads took the default value, i.e. the numbers of physical cores, in this case 6. So we can't have --ponyminthreads be higher than 6
$ ./helloworld --ponyminthreads=4
Hello, world.

This is fine, given --ponythreads took the default value, i.e. the numbers of physical cores, in this case 6.
 $ ./helloworld --ponyminthreads=4 --ponythreads=6
Hello, world.

Explicit case, all good as --ponythreads is <= physical cores on my machine!
 $ ./helloworld --ponyminthreads=4 --ponythreads=3
Can't have --ponyminthreads > --ponythreads (4 > 3)

Explicit case, but with erronous values provided
$ ./helloworld --ponyminthreads=3 --ponythreads=12
Can't have --ponythreads > physical cores, the number of threads you'd be running with (12 > 6)

Explicit case, but with --ponythreads being larger than the physical cores on the machine.
$ ./helloworld --ponyminthreads=3 --ponythreads=3 --ponynoscale
--ponyminthreads & --ponynoscale are mutually exclusive

Incompatible arguments provided
 $ ./helloworld --ponyminthreads=4 --ponythreads=3 --ponynoscale
--ponyminthreads & --ponynoscale are mutually exclusive

Explicit case with erronous values and incompatible args. The latter error wins…
 $ ./helloworld --ponythreads=3 --ponynoscale
Hello, world.

--ponynoscale sets --ponyminthreads to the value provided in --ponythreads, i.e. 3
./helloworld --ponynoscale
Hello, world.

--ponynoscale sets --ponyminthreads to the implicit value of --ponythreads, i.e. 6 physical cores on my machine.
I'll still:

[ ] add the bound check on provided values (atoi signedness issue)
[ ] clean up commits
[ ] update docs

@alexsnaps let me know when you are ready for another review (and maybe even... a merge!)

let me know when you are ready for another review (and maybe even... a merge!)

Wrapping up the doc & unsigned atoi at the airport (and on the flight if need be) right now… I think this should be fine in the next couple of hours…

I’m again a disappointment. Didn’t get to finish the unsigned int atoi the way I wanted, so I think it might be best to do this as a separate PR to not hold this one back.
So if you think that behavior sounds good, let’s say this is ready for actual review and possibly a merge. I’ll open the PR against the other repo tomorrow (as I forgot to clone it prior boarding). wdyt?
And sorry about the slow follow up here.

@alexsnaps couple of things before full review.
1- are you comfortable rebasing against master to resolve the CHANGELOG.md conflict?
2- can you add some nice release notes for this change to https://github.com/ponylang/ponyc/issues/3295

@alexsnaps fyi, im planning on reviewing this today or tomorrow. i'd like for it to go out with the 0.32.0 release.

@alexsnaps this looks good. there's a few small { related formatting changes, can you do those in another PR? i'm going to merge this as the core of it is solid. Thanks!


[FEATURE] [MR] Fast fail job when too many fetch failed happen.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the feature
In #477 and #1011, job will resubmit upstream stage/vertex when many fetch failed. It is not useful for MR, because there are only 2 stage. For MR, we should fast fail the job.
But now MR can not fast fail. When the selected shuffle server is down or stuck, MR job fail until the number of task attempts is larger than max. It is very slow.
For now, shuffle does not send fetch failed event. We should fail the job according to the number of fetch failed event.
Motivation
No response
Describe the solution
No response
Additional context
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

MR example job have 8 map and 30 reduce. Here I stuck the shuffle server. application fail very slow unit the number of task attempts exceed max.

the number of failed task is 74, most of attempts are unnecessary.


FoxxManager.install fails

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[x] 3.3

Mode:

[x] Single-Server

On this operating system:

[x] Linux

[x] Ubuntu .deb

Foxx
We are trying to install a Foxx service as part of the DB initialization step in Docker. We have an init.js file with the following content:
const foxx = require("@arangodb/foxx/manager")
foxx.install("git:Lean5/arango-prometheus-exporter:master", "/metrics")

This worked fine in ArangoDB v3.1.8. When we updated to v3.3 we noticed that this no longer works. A quick test showed that this problem already existed in 3.2 - just execute these two lines in arangosh. This results in the following error:
JavaScript exception in file<EMAIL_ADDRESS>at 98,7: ArangoError 3101: syntax error in module
File: /var/lib/arangodb3-apps/_db/_system/metrics/APP/index.js
!      throw error;
!      ^
stacktrace: ArangoError: syntax error in module
File: /var/lib/arangodb3-apps/_db/_system/metrics/APP/index.js
    at Object.exports.checkRequestResult (/usr/share/arangodb3/js/client/modules/@arangodb/arangosh.js:96:21)
    at Object.install (/usr/share/arangodb3/js/client/modules/@arangodb/foxx/manager.js:281:12)
    at <shell command>:1:6

What I found strange is the path APP/index.js, because the service has no injex.js file in the root directory. I tried to hunt this down in the code and found that by specifying force: true the created files are not deleted. Executing the install function with "force" leaves two files in /var/lib/arangodb3-apps/_db/_system/metrics/APP/:

index.js - with the content: https://github.com/Lean5/arango-prometheus-exporter/archive/master.zip
manifest.json - with the content: { "main": "index.js" }

Based on this I figured that _prepareService takes the path where serviceInfo is a Buffer instance and therefore does not correctly download the zip-File.
So the root cause seems to be either in the code that issues the POST request to /_api/foxx (missing content-type?) or in the according request handler.

Hi @mpoeter ,
Thanks for reporting this bug
We have released 3.3.4, and it includes a fix for it
I am closing this ticket now. Please feel free to reopen if the problem persists

We updated to 3.3.4 and everything works again as expected. Thanks for fixing this!


Traffic disruption during cilium-agent upgrade/restart with Mellanox NICs

Bug report
We found that when upgrading cilium-agent from 1.7.4 to 1.8.4, both node traffic as well as Pod traffic would get interrupted for a few seconds (e.g. 1~10s according to our observation). The problem is 100% reproducible.
Further tests show that event restart cilium-agent container could reproduce this interruption.
General Information

Cilium version: 1.8.4
Kernel version: 4.19.118
NIC: mlx5, Mellanox Technologies MT27710 Family [ConnectX-4 Lx]

Note that we find this problem only appears on nodes that shipped with Mellanox NICs.
Trace the problem
We notice that each time the problem appears, there will be a Link up message in dmesg:
[Tue Oct 13 10:12:03 2020] mlx5_core 0000:08:00.0 eth0: Link up
[Tue Oct 13 10:12:03 2020] mlx5_core 0000:08:00.1 eth1: Link up

Further digging we find that it is originated from init.sh during agent start/restart, which unconditionally performs XDP resets:
https://github.com/cilium/cilium/blob/master/bpf/init.sh#L658
# Remove bpf_xdp.o from previously used devices
for iface in $(ip -o -a l | awk '{print $2}' | cut -d: -f1 | cut -d@ -f1 | grep -v cilium); do
	[ "$iface" == "$XDP_DEV" ] && continue
	for mode in xdpdrv xdpgeneric; do
		xdp_unload "$iface" "$mode"
	done
done

function xdp_unload()
{
	DEV=$1
	MODE=$2

	ip link set dev $DEV $MODE off 2> /dev/null || true
}

It seems this works fine for NICs from many vendors (e.g. Intel), but not for Mellanox ones.
As a quick test, comment out the above xdp_unload, the problem disappears.
@jaffcheng is working on a patch to fix this.

same question with xdpgeneric on virtualbox
ethtool -i enp0s3
driver: e1000
version: 7.3.21-k8-NAPI
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

cilium-agent --version
Cilium 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64

level=warning msg="+ ip -force link set dev enp0s3 xdpdrv obj bpf_xdp.o sec from-netdev" subsys=datapath-loader
level=warning msg="Error: underlying driver does not support XDP in native mode." subsys=datapath-loader

#use xdpgeneric is ok
ip -force link set dev enp0s3 xdp obj /run/cilium/state/bpf_xdp.o sec from-netdev

full log
level=warning msg="+ for mode in xdpdrv xdpgeneric" subsys=datapath-loader
level=warning msg="+ xdp_unload enp0s3 xdpdrv" subsys=datapath-loader
level=warning msg="+ DEV=enp0s3" subsys=datapath-loader
level=warning msg="+ MODE=xdpdrv" subsys=datapath-loader
level=warning msg="+ ip link set dev enp0s3 xdpdrv off" subsys=datapath-loader
level=warning msg="+ true" subsys=datapath-loader
level=warning msg="+ for mode in xdpdrv xdpgeneric" subsys=datapath-loader
level=warning msg="+ xdp_unload enp0s3 xdpgeneric" subsys=datapath-loader
level=warning msg="+ DEV=enp0s3" subsys=datapath-loader
level=warning msg="+ MODE=xdpgeneric" subsys=datapath-loader
level=warning msg="+ ip link set dev enp0s3 xdpgeneric off" subsys=datapath-loader
level=warning msg="+ CIDR_MAP='cilium_cidr_v*'" subsys=datapath-loader
level=warning msg="+ COPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp'" subsys=datapath-loader
level=warning msg="+ '[' true = true ']'" subsys=datapath-loader
level=warning msg="+ COPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB'" subsys=datapath-loader
level=warning msg="+ '[' true = true ']'" subsys=datapath-loader
level=warning msg="++ cat /sys/class/net/enp0s3/ifindex" subsys=datapath-loader
level=warning msg="+ NATIVE_DEV_IDX=2" subsys=datapath-loader
level=warning msg="+ COPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2'" subsys=datapath-loader
level=warning msg="+ '[' <IP_ADDRESS> '!=' '<nil>' ']'" subsys=datapath-loader
level=warning msg="+ COPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a'" subsys=datapath-loader
level=warning msg="+ '[' '<nil>' '!=' '<nil>' ']'" subsys=datapath-loader
level=warning msg="+ xdp_load enp0s3 xdpdrv '-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a' bpf_xdp.c bpf_xdp.o from-netdev 'cilium_cidr_v*'" subsys=datapath-loader
level=warning msg="+ DEV=enp0s3" subsys=datapath-loader
level=warning msg="+ MODE=xdpdrv" subsys=datapath-loader
level=warning msg="+ OPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a'" subsys=datapath-loader
level=warning msg="+ IN=bpf_xdp.c" subsys=datapath-loader
level=warning msg="+ OUT=bpf_xdp.o" subsys=datapath-loader
level=warning msg="+ SEC=from-netdev" subsys=datapath-loader
level=warning msg="+ CIDR_MAP='cilium_cidr_v*'" subsys=datapath-loader
level=warning msg="++ ip link show enp0s3" subsys=datapath-loader
level=warning msg="++ awk '{print $2}'" subsys=datapath-loader
level=warning msg="++ grep ether" subsys=datapath-loader
level=warning msg="+ NODE_MAC=02:35:62:3f:30:df" subsys=datapath-loader
level=warning msg="++ mac2array 02:35:62:3f:30:df" subsys=datapath-loader
level=warning msg="++ echo '{0x02,0x35,0x62,0x3f,0x30,0xdf}'" subsys=datapath-loader
level=warning msg="+ NODE_MAC='{.addr={0x02,0x35,0x62,0x3f,0x30,0xdf}}'" subsys=datapath-loader
level=warning msg="+ bpf_compile bpf_xdp.c bpf_xdp.o obj '-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a -DNODE_MAC={.addr={0x02,0x35,0x62,0x3f,0x30,0xdf}}'" subsys=datapath-loader
level=warning msg="+ IN=bpf_xdp.c" subsys=datapath-loader
level=warning msg="+ OUT=bpf_xdp.o" subsys=datapath-loader
level=warning msg="+ TYPE=obj" subsys=datapath-loader
level=warning msg="+ EXTRA_OPTS='-DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a -DNODE_MAC={.addr={0x02,0x35,0x62,0x3f,0x30,0xdf}}'" subsys=datapath-loader
level=warning msg="+ llc -march=bpf -mcpu=v2 -mattr=dwarfris -filetype=obj -o bpf_xdp.o" subsys=datapath-loader
level=warning msg="+ clang -O2 -target bpf -std=gnu89 -nostdinc -emit-llvm -Wall -Wextra -Werror -Wshadow -Wno-address-of-packed-member -Wno-unknown-warning-option -Wno-gnu-variable-sized-type-not-at-end -Wdeclaration-after-statement -I. -I/run/cilium/state/globals -I/var/lib/cilium/bpf -I/var/lib/cilium/bpf/include -D__NR_CPUS__=2 -DENABLE_ARP_RESPONDER=1 -DSECLABEL=2 -DCALLS_MAP=cilium_calls_xdp -DDISABLE_LOOPBACK_LB -DNATIVE_DEV_IFINDEX=2 -DIPV4_NODEPORT=0xf02000a '-DNODE_MAC={.addr={0x02,0x35,0x62,0x3f,0x30,0xdf}}' -c /var/lib/cilium/bpf/bpf_xdp.c -o -" subsys=datapath-loader
level=warning msg="+ rm -f '/sys/fs/bpf/xdp/globals/cilium_cidr_v*'" subsys=datapath-loader
level=warning msg="+ cilium-map-migrate -s bpf_xdp.o" subsys=datapath-loader
level=warning msg="+ set +e" subsys=datapath-loader
level=warning msg="+ ip -force link set dev enp0s3 xdpdrv obj bpf_xdp.o sec from-netdev" subsys=datapath-loader
level=warning msg="Error: underlying driver does not support XDP in native mode." subsys=datapath-loader
level=warning msg="+ RETCODE=2" subsys=datapath-loader
level=warning msg="+ set -e" subsys=datapath-loader
level=warning msg="+ cilium-map-migrate -e bpf_xdp.o -r 2" subsys=datapath-loader
level=warning msg="+ return 2" subsys=datapath-loader
level=error msg="Error while initializing daemon" error="exit status 2" subsys=daemon
level=fatal msg="Error while creating daemon" error="exit status 2" subsys=daemon

@vsxen It's a different problem. The e1000 driver doesn't support XDP. It's usually not deployed on 10Gbps+ interfaces so supporting XDP in such driver probably makes little sense. Cilium requires native driver support to use the XDP acceleration.

Thank you, I use virtualbox just for test.
and this args same not work?
      --prefilter-mode string                 Prefilter mode via XDP ("native", "generic") (default "native")


[CI] - Fixed Celebration Image Bug

Signed-off-by: Adithya Krishna<EMAIL_ADDRESS>Description
This PR fixes the issue of celebration.png not being visible when a new person opens his first PR
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

Argh.

I admit to looking at the change only after merging. 😬
You'll want to use the raw reference to the image - https://raw.githubusercontent.com/layer5io/preview-layer5/master/.github/welcome/Layer5-celebration.png

I'll Then create a PR from my another account to check this 👀

Good of you to highlight the possible lack of sign-off. No issue about DCO on items like this. 👍


Use singer-io/target-csv instead of our own fork

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2197
Originally created by @DouweM on 2020-07-22 22:45:08

Our fork (https://gitlab.com/meltano/target-csv) of https://github.com/singer-io/target-csv was created to fix https://gitlab.com/meltano/target-csv/-/issues/1 (aka https://github.com/singer-io/target-csv/issues/14) without having to wait for singer-io to release a new version. Now that that has happened (https://github.com/singer-io/target-csv/releases/tag/v0.3.0), we can deprecate our fork and change the pip_url for target-csv back to git+https://github.com/singer-io/target-csv.git so users benefit from the latest changes, like a new destination_path setting.

View 2 previous comments from the original issue on GitLab


Fix incorrect rendering as HTML

Due to the use of < and > inside the text, the first Remarks paragraph is rendered incorrectly on docs.microsoft.com.

Thanks, @yoni1
Appreciate the PR!


Password Length policy is not updated in Japanese version

Please update the below section indicating the max is 256 characters in the Japanese translation version.
>A minimum of 8 characters and a maximum of 256 characters.
Japanese version:
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-sspr-policy#userprincipalname-policies-that-apply-to-all-user-accounts

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

ID: b1765376-03c9-829a-9e42-e72cc8a0daea
Version Independent ID: 684c7d7c-09f4-8170-6f7a-132b2d79e1df
Content: Azure AD Self-service password reset policies - Azure Active Directory
Content Source: articles/active-directory/authentication/concept-sspr-policy.md
Service: active-directory
Sub-service: authentication
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@UKayo Thanks for the feedback! We will check on this and update as appropriate.

Translation updates take several days to propagate. #please-close


Dropping trrntzip maintainership

I am no longer using Nix, thus I am not maintaining trrntzip anymore

You can open a PR removing yourself from meta.maintainers.

Ah indeed, thanks, I've just done that https://github.com/NixOS/nixpkgs/pull/331048


Addred real property and is_integer function to float.

Yet another two small and obscure additions to the float type.

Codecov Report

Merging #534 into master will increase coverage by 0.01%.
The diff coverage is 76.47%.

@@            Coverage Diff             @@
##           master     #534      +/-   ##
==========================================
+ Coverage   48.41%   48.43%   +0.01%
==========================================
  Files          69       69
  Lines       14375    14398      +23
  Branches     3591     3593       +2
==========================================
+ Hits         6960     6973      +13
- Misses       5554     5562       +8
- Partials     1861     1863       +2

Impacted Files
Coverage Δ

vm/src/obj/objfloat.rs
66.46% <76.47%> (-0.75%)
: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 d44f1b3...f4e6e5d. Read the comment docs.


Major Helm plugin security issue

Output of helm version: 3.7.1
Output of kubectl version: 1.22.3
There is a major problem with how plugins are installed and updated. It is basically the same as piping a foreign bash script into your shell. An exploited user may not even know, but they could easily have their entire production Kubernetes clusters exposed, passwords, and more.
For example, take the helm-push plugin:
plugin.yaml
name: "cm-push"
version: "0.10.1"
usage: "Please see https://github.com/chartmuseum/helm-push for usage"
description: "Push chart package to ChartMuseum"
command: "$HELM_PLUGIN_DIR/bin/helm-cm-push"
downloaders:
- command: "bin/helm-cm-push"
  protocols:
  - "cm"
useTunnel: false
hooks:
  install: "cd $HELM_PLUGIN_DIR; scripts/install_plugin.sh"
  update: "cd $HELM_PLUGIN_DIR; scripts/install_plugin.sh"

As you can see, it is blanket running a script during install scripts/install_plugin.sh as the user. Let's say a malicious user wanted to get your ~/.kube credentials and ~/.config/glcoud. All they have to do is include commands to silently upload those. This exposes all files that user has access to, can add commands to run on user login and more. A malicious actor could even have a useful plugin, but with an undisclosed exploit.
Users installing plugins are not going to be aware that simply installing a plugin could do something as damaging as remove their entire user directory, and it shouldn't be allowed. Kubernetes is a big ecosystem, and I doubt it would be that hard to convince users to install your Helm plugin.

Hi @braderhart.
When you install a third-party plugin, it is your responsibility to audit the code and ensure it is not malicious. We've discussed this with several independent security audit teams and they all agreed that it is the responsibility of the user to audit any third party code before installing it. In other words this is a known risk of using "unofficial" code and is therefore a non-issue. If Helm was distributing this code then it'd be a different story, but this is effectively the same as adding a third party repository to apt and calling apt install totally-not-a-bitcoin-miner.
in other words, Helm is not responsible for auditing third party code. That is on you.
In the future, please make sure to disclose security issues responsibly. See both https://github.com/helm/helm/blob/main/CONTRIBUTING.md#reporting-a-security-issue as well as https://github.com/helm/helm/blob/main/SECURITY.md for more information. Thanks!

Closing as a non-issue.

@bacongobbler The issue with privately reporting security vulnerabilities is that there is no public record. Because this appeared to be more of a willful choice, and as you've stated this is a non-issue, what precisely would be the benefit of being told something is a non-issue privately? At least this way, if it does become an issue it will be publicly documented that someone brought it to the attention of the Helm authors before and they declared it a non-issue.
Here is an example of a plugin install:
helm plugin install https://github.com/chartmuseum/helm-push.git
Downloading and installing helm-push v0.10.1 ...
https://github.com/chartmuseum/helm-push/releases/download/v0.10.1/helm-push_0.10.1_linux_amd64.tar.gz
Installed plugin: cm-push

There is no prompt before installing. helm plugin install --help shows no message about auditing third party code. While you may have talked to third-party auditors about this before, there is no prompted message to the user; nor any indication that installing a plugin allows a plugin author to run scripts as that user. There are plenty of actions Helm could take to restrict the attack vector here, but that isn't being done. I wouldn't have even reported the issue if there was a prompt at least informing the user.
I can't predict what would happen, but let's say hypothetically this does become an issue and a major enterprise does end up getting attacked due to this problem.  What do you think the general consensus is going to be in the security community? That users should have just known installing a Helm plugin allowed them to be exploited? No warning message, but they should have predicted it?
I find your reasoning here concerning because you act like there is nothing that can be done here to improve the security, even if it is prompting the user on install.

what precisely would be the benefit of being told something is a non-issue privately? At least this way, if it does become an issue it will be publicly documented that someone brought it to the attention of the Helm authors before and they declared it a non-issue.

The goal of responsibly disclosing security issues is to provide maintainers time to write a fix, test it, announce a new security release to the community on the mailing list, issue a CVE, and cut the release. It also gives maintainers a bit of time to assess the situation and test fixes over regular business hours.
Consider the situation: had this actually been a major [zero-day](https://en.wikipedia.org/wiki/Zero-day_(computing), by disclosing it publicly you now have given attackers an opportunity to write exploits well before the maintainers have an opportunity to write and release a fix. And the maintainers would've been called in on their Friday night to work on a fix well into the weekend.

Here is an example of a plugin install:

Again, you are just arguing the semantics of what happens when you call helm install https://github.com/bacongobbler/totally-not-a-bitcoin-miner. Even if there was no exec-hook available, I could just as easily embed the bitcoin miner in the plugin's source code. If you have ideas or suggestions on how to improve this, please feel free to write a HIP as described in https://github.com/helm/helm/blob/main/CONTRIBUTING.md#proposing-an-idea.
If there was a way to either
a) coerce the user to install a plugin without them explicitly calling helm plugin install, or
b) exploit a helm plugin install to execute an RCE,
Then it's a security issue in Helm. Otherwise it's third-party (read: untrusted) code.

I can't predict what would happen

That's on you. You're responsible for auditing any code you use.

@bacongobbler

Consider the situation: had this actually been a major zero-day, by disclosing it publicly you now have given attackers an opportunity to write exploits well before the maintainers have an opportunity to write and release a fix. And the maintainers would've been called in on their Friday night to work on a fix well into the weekend.

If this had been a 0-day with Helm itself, then yes I would have used responsible disclosure. Instead, this is a willful decision that makes exploiting users relatively easy.

Again, you are just arguing the semantics of what happens when you call helm plugin install https://github.com/bacongobbler/totally-not-a-bitcoin-miner. Even if there was no exec-hook available, I could just as easily embed the bitcoin miner in the plugin's source code.

There is a clear distinction between what happens when you install something and run something. I don't disagree that that there a lot of ways a plugin author could run an exploit once you install a plugin, and there could be improvements to address those—but that would require a lot of extra work and is not practical without a new major release and deprecation notice.
I may consider writing a HIP. However, I only have so much time to point out obvious issues mixed with family, work, etc. I understand that is part of open source, so I'm willing to do if it will get done, but if I am going to spend time writing something up to have it get dismissed as "intended" behavior then I don't see the point.

There is a clear distinction between what happens when you install something and run something.

Every package manager has a mechanism of a pre-install hook. dpkg has both dpkg::Pre-Invoke and dpkg::Post-Invoke, both of which are called without user interaction after calling dpkg -i or apt install. Helm plugin install hooks are no different.


how to convert original data to mhd format

Excuse me! I am dealing with the DIR-Lab data, but I have got trouble in converting the original data format (.img) to mhd format. Could you tell me  the method of converting the data format? Looking forward to your reply!

You are welcome.
DIR-lab provided the matlab script to load img file. You can follow instruction there
https://www.dir-lab.com/DownLoads/SoftwareSummary/MatlabUtilityPack1.pdf
To save the image to mhd format, you can use this function
https://www.mathworks.com/matlabcentral/fileexchange/52982-matlab-elastix

Thank you for your reply! I have solved the problem by your method. Thanks very much!


(WIP) Add keepVueInstance config option to avoid externalization of Vue in Lib mode

This PR resolves an issue when build is targeting Lib, but for whatever reason Vue instance should be preserved in final bundle.
I followed @seteam1 original suggestion. And also added test case and updated docs.
Option is only used for --target lib, but might be useful for --target wc as well. Let me know and I update this PR.
Would like to hear some feedback is if this change might be accepted to upstream.
Resolves #4055

Rebased on top of dev branch. WIP on reworking this PR from vue.config.js option into --inline-vue command line flag.

Pushed code style fixes and also improved consistency for related docs.


Trigger build

@hans-landa tertiarty

@hans-landa tertiarty

@hans-landa tertiarty

@hans-landa tertiarty

@hans-landa tertiary

@hans-landa primaryAndTertiary


Making the remaining links Clickable(Hyperlink) in the generated Resume(NOT PDF) and changing color of hyperlinks.

Is your feature request related to a problem? Please describe.

In the Generated Resume(NOT PDF) Blog and Github profile links are not hyperlink.
Hyperlinks are not differently colored.

Describe the solution you'd like

Adding anchor tags to the mentioned links
Changing the color of anchor tags in CSS

I have sent a pull request of this one.

@ShauryaBhandari  @garimasingh128 I would like to work on this issue, as the link of github profile in generated resume (PDF) is not a hyperlink. It should be hyperlink so that a person can go from pdf version to the actual github profile directly.

@kaushiksriram16  has already made a PR. Please look into that PR and mend if something is missing there.

@garimasingh128  have you merged that PR to the hakincodes branch?

Not yet. Use this to check the code: https://gist.github.com/adam-p/15413fabef6cffecd897

@kaushiksriram16 has done perfect. But its done only on the web resume.
@garimasingh128 I am doing this on PDF based resume. I am hyperlinking the links of blog and github profile in PDF version. So that the user can directly go to respective addresses directly.

@tanishq98 then that's the issue #30

@tanishq98 then that's the issue #30

Ohh Sorry, I didn't see that


Continuous auto-focus doesn't work on Android devices

Bug Report
Current behavior

When performing a video chat on an Android device, the device camera doesn't auto-focus. When running on an iOS device, the auto-focus works as expected.

Steps to reproduce

Publish a video on an Ionic app using the Cordova plugin (we are using v3.1.2).
Make sure you are using the back camera.
Move the device to be very close and very far away from objects.

What is the current bug behavior?

On Android devices, the focus remains at a fixed spot.

What is the expected correct behavior?

On iOS devices, the focus adjusts as needed.

Relevant logs and/or screenshots

A community post on the TokBox website references setting Camera.Parameters.FOCUS_MODE_CONTINUOUS_VIDEO in a custom video capturer class. I tried implementing this in the plugin but it didn't seem to have any effect.

Is autofocus working at all on your side? Im having trouble having any focus at all on android devices!

Yeah, the same app has functionality to record regular video using the native camera app and the autofocus works fine on that.

I see that the config.xml has permission declared for auto focus:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
But its not working..

@bobtheowl @smuaq the autofocus require feature is set to false, does it work for you when you set it to true?

No, I tried it with true but still the same


Add schema version to csolution files

Problem Statement
The CMSIS ecosystem includes various tools that consume csolution files, for example CMSIS-Toolbox and VS Code extensions such as cmsis-csolution. To give a good user experience, these tools should notify the user when their csolution is written for a version of the schema that is incompatible with the tool version. This is not possible currently without using heuristics on file content, for example looking for unknown fields.
Proposal
Add a schema-version property to csolution files. The details can be discussed, but as an example:
schema-version: 1.6.0
csolution: …

Update the csolution schema to include it:
{
  "properties": {
    "solution": {
      "$ref": "./common.schema.json#/definitions/SolutionDescType"
    },
    "schema-version": {
      "type": "string"
    }
  },
  "required": [ "solution", "schema-version" ]
}

Tools could check whether this version falls within their supported range when reading a csolution file. CMSIS-Toolbox could print a warning to the command line, and VS Code extensions could show a warning notification when the schema version is unsupported. It would even be possible for tools to support multiple versions of the schema.
This pattern is already used by other tools, e.g.:

Node JS's package.json engines. This describes what NPM versions the project works with.
Kubernetes pods. The apiVersion field is similar to the version in this proposal.
JSON schema. This is more complex than a simple version, but a similar concept.

Alternative Schema Definitions

Require the version to match exactly. This would guarantee the user is checking their csolution against the correct schema version, but would be quite restrictive."schema-version": {
  "const": "1.6.0"
}

Include a list of valid versions. This guarantees the user is checking their csolution against a valid schema version, without being as restrictive as const."schema-version": {
  "enum": ["1.5.0", "1.6.0"]
}

Versioning
The version number could match the CMSIS-Toolbox version, but it might be better to introduce an independent version number for the schema. Using semantic versioning would help tools to maintain their version range.

@mcgordonite we csolution 2.0 we indent only to make upward compatible changes. By applying a schema check, a syntax problem with a csolution.yml file could be identify.  What is then the real benefit of requesting a schema-version in yml files?

I think we need to distinguish between forwards and backwards compatibility here. For example, say we want to add a new feature to the processor node in future:
project:
  processor:
    trustzone: secure
    new_feature: enabled

This is a backwards compatible change: a csolution written for the old schema is compatible with the new one. However, it is not forwards compatible: an old version of cbuild cannot build a csolution file that enables the new feature.

An alternative proposal is to specify the tool that has been used when creating the example, i.e.
 ctools<EMAIL_ADDRESS>

Cab be a bit more complex, because you create a project with one version of a tool but we do not know which features supported by this tool have been used or not.
So:

you check the reference version ==> you already know if you have a chance to support the project or clearly not (semantic versioning)
you check the features in use by analyzing the content of the project
you check this list of "features in use" versus the list of supported features of your own tool

Some points from the Technical Project Meeting yesterday:

The version of the schema itself might not be sufficient. There are additional rules (e.g.: access sequences) that cannot be encoded in the JSON schema.
Separating the format version from the tool version was considered important, since some partners may provide their own tools that interpret csolutions.
Partners may want to track which tool generated the csolution.

This suggests we want to store the version of the format or the specification rather than the schema or the tool. Additionally, we could track metadata about which tool generated the file, but I think that should be raised as a separate issue.
spec-version: 1.5
solution: <solution description>

Then tools would basically follow the process outlined by @fred-r in https://github.com/Open-CMSIS-Pack/devtools/issues/819#issuecomment-1503504013:

Check if the spec version is known by the tool. If it isn't, it can't know what features are unsupported. For example, we can't know to look for new file types. This check could use semver. For example, if the tool understands version 1.5.0 and the csolution uses spec 1.5.3, it can assume there are no new file types.
Check for unsupported features. For example, if the tool doesn't support layers, it can check for the layers node in cproject files.

Yes, and with semver you could also save some time for step 2:

if you support revision 1.5.0 of the spec "fully" (all features)
and if only the .patch has been updated, then there is no new feature, so you know you can use this file

If you support only a subset of 1.5.0, then you need to do the analysis.
Alternate solution: define "interoperability profiles"
For instance:

1.5.0-full: full profile by default (all features)
1.5.0-core: only the "core" features so no advanced features like the "clayer support"

Yes, I think the Csolution extension could use created-for to check compatibility by extracting the version from<EMAIL_ADDRESS>It might not work so well when the solution is created-for a different tool, e.g<EMAIL_ADDRESS>since we won't know what specification version 2.3.1 of that tool uses.

I know you can only handle tools that are known.

Dear all,
first of all I apologize in advance for this very long (and very boring) contribution.
I think the point being discussed in this thread is wider than just a matter of schema versioning.
1. "Philosophy"
This Open-CMSIS-Pack project is defined like this:
The Open-CMSIS-Pack project offers a flexible and easy to use end to end development flow for embedded software - from project creation to software execution on real or virtual hardware.
So, to me, it is not only about software packaging and delivery (CMSIS-Pack), but also project management (csolution).
To day, the first point is covered by a spec: Open-CMSIS-Pack-Spec.
But, the latter point is covered "only" by a reference tool: csolution
I think this raises issues because a tool is not a specification.
So, today, we can't really handle the interoperability at project management level, we can do this only at CMSIS-pack level.
I agree that the tool is managed by its contributors and I assume the maintainer is @brondani, I do not challenge this.
But, if the project management is part of the Open-CMSIS initiative then I think a spec is needed, so that we can know if a tool complies to it or not (just like for the CMSIS-Packs).
Today, I think having only the vanilla/reference tool is probably fine for ARM but I am not sure it is sufficient for the other partners in this initiative (@iomint to provide his point of view here).
2. Proposal to allow interoperability at project management level
I would like that we create a real specification of the project manager tool.
The basis for this could be this (user manual)[https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/Overview.md].
This spec should be versioned.
3. Consequence for the initial issue discussed here
If we have a spec, then I think we can do 2 things.
On tools side (can be the vanilla tool or any other tool implementing the spec), we can indicate what we support.
On project sides, we can add an information about the spec features we use.
This would be more precise than created-by and created-for.
4. Proposal
I suggest having a field like this:

"in the tool" to define its capabilities
in the project YML file(s) to define the capabilities it requires

So, to be more specific a tool from ARM could define this:
capabilities:
  core-spec-version:
    revision: 1.5.0
    optional_features:
      feat_clayer:
        description: clayer concept
        supported: true
      feat_hwproject:
        description: hw project concept
        supported: false

and a tool from ST could define this:
capabilities:
  core-spec-version:
    revision: 1.5.0
    optional_features:
      feat_clayer:
        description: clayer concept
        supported: false
      feat_hwproject:
        description: hw project concept
        supported: true

Then, a project would indicate what it requires:
required_capabilities:
  core-spec-version:
    revision: 1.5.0
    optional_features:
      feat_clayer:
        description: clayer concept
        required: false
      feat_hwproject:
        description: hw project concept
        required: true

So, the interoperability would become predictable:
if (project.required_capabilities == tool.capabilities) then
    the project can be managed by the tool
else
    vendor specific implementation depending on what is missing
endif

@jkrech and @ReinhardKeil, I know you are not in favor of going in this direction, but it is the way I see to ensure interoperability at project level.

So, to me, it is not only about software packaging and delivery (CMSIS-Pack), but also project management (csolution).
To day, the first point is covered by a spec: Open-CMSIS-Pack-Spec.
But, the latter point is covered "only" by a reference tool: csolution

@fred-r I think the manual is doing the job of the specification for project management.

Hi @mcgordonite  and all,
one again I apologize in advance for probably complexifying things...
But, I agree that the manual is more or less the spec.
My point is not only about the content, but more about the doc status and management.
To me, to become a specification handled by this working group, it should have its own placeholder here:
https://github.com/Open-CMSIS-Pack#specifications
At the moment it is a user manual, and to me a user manual is dedicated to one specific implementation while a specification describes a set of requirements, principles and mechanisms that can be implemented in various manners.
So, as long as we have only a user manual then I think there is no possibility to talk about interoperability, because a user manual describes 1 tool so 1 implementation.
My point is more to say that:

the project management is probably part of the wharter of this working group
the project management requires a spec
anybody could decide to implement this spec or not

So, here the schema version and in the end the interoperability would make sense.
This would be the required cradle to define features, capabilities and what is optional or not to be interoperable.
On another aspect, I also think that today we are in a chicken and egg situation.
Only ARM is contributing to the project management documentation...but this is because this documentation is a user manual describing ARM's implementation.
If you want (more) contributions, then a spec is needed.
As you can see in the Open-CMSIS-Pack spec, there has been contributions from ST for instance.
These were my 2 cents, I let @iomint and my other colleagues -@slhultgren, @mdortelstm - comment further if needed (and maybe disagree)

For examples, I recommend not to add:
# yaml-language-server: $schema=https://raw.githubusercontent.com/Open-CMSIS-Pack/devtools/schemas/projmgr/1.6.0/tools/projmgr/schemas/csolution.schema.json

VS Code picks-up the YML schema of the CMSIS-Toolbox that is installed; users may utilize new features that may be added over time to CMSIS-Toolbox when working on such projects.
Instead add:
` created-for<EMAIL_ADDRESS>
to indicate that an example is created with the feature set of CMSIS-Toolbox 1.6.

I think we have concluded on this one.
*** Please raise a new issue an describe the problem that you want to solve ***


CEL checker mutex

Fixes #13189
/assign @ymesika
Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: kyessenov
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

mixer/OWNERS [kyessenov]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign @geeknoid

@kyessenov: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kyessenov: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn, kyessenov
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

mixer/OWNERS [kyessenov]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kyessenov: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kyessenov: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kyessenov: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kyessenov: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
32e85ed8cfc440e12aa7109d34297cea345efae5
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Registration issue because of timeout during GBIF Registry call

Hello,
We have reached 10k datasets...
IPT (2.5.8) has issue to register new datasets:

The fact is that calling https://gbrds.gbif.org/registry/resource.json?organisationKey=1928bdf0-f5d2-11dc-8c12-b8a03c50a862 took around 40 seconds.
When we had less datasets, it was already an issue since it makes registration really slow (20-25 seconds for each dataset can be long when registering 1K datasets...)
But now, since we are above 30s, we get a timeout, and the registration is failing.
We cannot change the timeout, it's hardcoded (https://github.com/gbif/ipt/blob/master/src/main/java/org/gbif/ipt/config/IPTModule.java#L63)
I compiled my own version with a 2 minutes timeout, and I can now register my datasets.
But maybe, it would be better if we could speed up the https://gbrds.gbif.org/registry/resource.json?organisationKey=1928bdf0-f5d2-11dc-8c12-b8a03c50a862 call...?
Thanks

36 seconds

@sylmorin-gbif Thank you for reporting this.
10k datasets that's a lot! We need to find something there. I think we can do a temporary quick fix like you did, just prevent it from failing, and then find a performance solution

@sylmorin-gbif Now it will be much quicker. It doesn't retrieve all datasets anymore and just quickly checks if dataset belongs to the organization.
I'm also currently finalizing more performance improvements which you're probably interested in #1875

Registry release is required, but IPT part is done. Closing this


Rendering HTML file

"react": "16.8.3",
"react-native": "0.59.4"
Webview bridge is not able to render the page but html file itself. It's showing the html code instead of displaying the proper layout

I'm seeing the same thing


Composer updates

Joe,
I will probably never use this library, as I use PHPFUI/InstaDoc
to output HTML, but thought I would help you on some minor composer issues.
First, you can't use semantic versioning with PHP versions. Common mistake.  I wrote a handy version checker here.  I never fail to not get it right the first time. This helps. I also added 8.1 support, as that is the current version.  You should probably drop 7.3 and 7.4 support, as it is super easy to run specific versions of PHP in a non prod env, so no reason not to leverage the better versions. 8.1 is not quite ready for prime time.  I submitted, and they already fixed, an enum bug, so waiting for 8.1.2 before I do more enum work.
Also removed composer.lock, which is generally only used for releases into production, not for libraries, although you could make an argument to use it here, but thinking letting users update things on their end is best practice, who knows what will be fixed next.
Also added roave/security-advisories that will check for security issues automatically.

@phpfui SemVer works but it should be probably ||.
See also https://github.com/shopware/core/blob/trunk/composer.json#L33

I as actually confused by all the versioning tricks Composer supports, so I ended up writing my own checker (could not find an existing one anywhere). You can see it in action here: (http://instadoc/Examples/ComposerVersion.php).  You can also view the source code (based on the Foundation documentation idea of viewable source!) if you want to check out the logic behind it.  I think it is correct from what I can tell.
Anyway, the basic issue that many people don't understand is PHP does not use the standard semantic versioning that Composer uses.  For example, normally a package major version will 6, with minor versions like 6.1, 6.2, etc.  The ^ implies take the highest minor version update available, since 6.1 should be compatible with 6.0, but with some new features.
This is not how PHP is versioned. PHP 8.1 breaks some things in PHP 8.0 for example (or maybe just issues warnings, whatever).  The point is you probably don't want the package as it currently exists to be able to run on PHP 8.9, which is what the current Composer files allows, as you have no idea of what PHP 8.9 will even look like.
So my preferred version specification is ">=7.4 <8.2" which clearly says (with the implicit &) that you require 7.4, 8.0, or 8.1, but nothing higher or lower.
As I said, common mistake.  I see it all the time.

Partically true. It's true thst warninhs and deprecated features may be errors and removed in the next 8.x release, that is normal. Most stable features are not affected by this in my experience.
Besides this ~ is a better approach. See for example https://github.com/magento/magento2/blob/2.4-develop/composer.json#L14

That does not allow for 8.0.  Again, this stuff is not obvious. Which is why I like my solution.

Sure. That's why we use also ~8.0 in projects. Just saying that there is a valid SemVer selector.
But in most cases projects should just set the start range like >= 7.4. Normally you don't set the upper part. See for example phpunit (18 years old project): https://github.com/sebastianbergmann/phpunit/blob/8.5/composer.json#L24 ;-)

I finally merged this all in. I had made some other changes that caused conflicts so I will close this. The changes are in v0.6.1. Thanks @phpfui


feat: support externally hosted plugins

What does it do?
It extends the PluginHost with functionality to process a list plugins.json of externally hosted plugins and allows to download & cache them, verify their signatures and eventually load them in the main process during runtime. These plugins are stored in a path outside of the main app so that changes to them don't require elevated user permissions or re-installation.
Any helpful background information?
The purpose of this PR is to give external projects more control and autonomy over their integrations and the release lifecycle. Moreover, changes to external plugins won't affect Grid's release cycle since such plugins can be updated, removed and reloaded during runtime.
Problem: the renderer start is deferred until all plugins (local & remote) are processed. This is mostly done because otherwise it would require changes in the state handling in grid-ui. An event hook plugins-loaded was added to allow the UI to listen for state changes.
New dependencies? What are they used for?
It will require a newer version of electron-app-manager that includes the verification info in the plugin's release metadata.
Relevant screenshots?

Notes make mention of a new version of electron-app-manager, but none included in the PR. Is that required to run this changeset or a future iteration?

@PhilippLgh alright, I resumed the debugging session. Some comments:
With a cleared plugins directory, I get this thrown error right after raiden plugin is downloaded. It seems pluginManager.download(latest) does not perform the checks that pluginManager.getLatest() does. The former does not have verificationResults property.
On a second run it worked, because the plugin was already downloaded and getLatest() seems to perform the checks.


WIP: 3-ci-srv-03: [no-test] Update translations from Fedora Weblate

Update translations from Fedora Weblate

[ ] po-refresh

po-refresh in progress on 3-ci-srv-03.
Log: https://logs.cockpit-project.org/logs/po-refresh-1062-20200723-033434/


v9 Warning

Hi.
Please remove the foundry vtt warning.
Replace "compatibleCoreVersion":9.xxx" by "compatibleCoreVersion":"9".
Docs: https://gitlab.com/foundrynet/foundryvtt/-/issues/5635

Fixed in 0.0.8, releasing soon


Create unit tests for new fields

[ ] fieldCleave
[ ] fieldMasked
[ ] fieldNoUiSlider
[ ] fieldPikaday
[ ] fieldSlider
[ ] fieldSpektrum
[ ] fieldVueMultiSelect
[ ] fieldGoogleAddress

I'm going to try after I read a bit more about Karma

OK, but firstly I have to solve the external lib loading problem.

I added external libs to karma. So now can be improve new field unit tests. https://github.com/icebob/vue-form-generator/commit/776f6c479fec8105df55d69288a310cf58b2386c

(I was about to suggest that :smile: )

Passing arrow functions (“lambdas”) to Mocha is discouraged

From the doc
Should we change that ?

Oooo.... what?!?!

basically, don't do this:
describe('my suite', () => {
  it('my test', () => {
    // should set the timeout of this test to 1000 ms; instead will fail
    this.timeout(1000);
    assert.ok(true);
  });
});

but this:
describe('my suite', function() {
  it('my test', function() {
    this.timeout(1000);
    assert.ok(true);
  });
});

You can use arrows because we use webpack as preprocessor and webpack use babel

Unit test are going through Webpack ? Wow ok, I didn't know... Webpack does everything :astonished:

yes :) https://github.com/icebob/vue-form-generator/blob/master/test/unit/karma.conf.js#L35

Sorry, I missed that totally

Nop, so you can use any ES6 feature

Sweet!

what field test are you make? Because I plan to make an other field tests

I'm starting with #36

What we need to test in this external fields:

[ ] check HTML elements (example: https://github.com/icebob/vue-form-generator/blob/master/test/unit/specs/fields/fieldSelect.spec.js#L48 )

[ ] after init check the lib read the value from model and value is correct (example: https://github.com/icebob/vue-form-generator/blob/master/test/unit/specs/fields/fieldSelect.spec.js#L63 )

[ ] if model value change, lib got the new value (example: https://github.com/icebob/vue-form-generator/blob/master/test/unit/specs/fields/fieldSelect.spec.js#L78 )

[ ] if value changed (via HTML element, maye need a trigger with js), check the model got the value (example: https://github.com/icebob/vue-form-generator/blob/master/test/unit/specs/fields/fieldSelect.spec.js#L87 )

I make fieldMasked and fieldSpektrum

I'm going to try fieldVueMultiSelect even if noUiSlider is not finished

Ok, for multiselect I recommend you to use fieldSelect.spec.js as a base

Roger that ! :)
Le 23 août 2016 16:46, "Icebob"<EMAIL_ADDRESS>a écrit :

Ok, for multiselect I recommend you to use fieldSelect.spec.js as a base
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/icebob/vue-form-generator/issues/40#issuecomment-241755645,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADT81G25O1xKPQyHtgIWx081dxjo6zNEks5qiwfcgaJpZM4JpX4g
.

#46 I did something wrong with the branch (a bad rebase), so this one contain a lot a commit from #44.
I hope it's ok.

Ok, #46 & #44 merged

It was too early for #44, I made several mistakes that I'm fixing

Ok, just &46 contains #44 because both was in the same branch, so I can only merge both

My bad sorry about that

Nop :)

fieldMasked done.

fieldPikaday, fieldSlider done.

fieldSpectrum done.

fieldGoogleAddress "done"

Wow cool, you are on :fire:

Now I start the last fieldCleave too.

All test done. :tada:
I made some changes, so if you open the karma debug page ( http://localhost:9877/debug.html ) for test debugging, you will see a similar page instead of empty white blank page :smile:

That's so cool ! I need your help with the doc:

[ ] visible & disabled, values schema functions description
[ ] fieldSubmit
[ ] customizable styles

I hope we can finish everything early next week.

Merged #51


Create scorecard.yml

@jaredfholgate needs header updating

@jaredfholgate needs header updating

@matt-FFFFFF  Done so many, I was starting to get blurred vision. :)
New PR here: https://github.com/Azure/Azure-Landing-Zones-Library/pull/8/


Add team totals and delta

This change to cloc-author-date shows a Team Total and Delta for all the changes. This will help with faster metrics as team metrics used to need to be added up manually.
The final report was updated to be cleaner by removing blank results. Comments were also added to the core script to denote what needs to be commented out in the event of running multiple reports in a timely manner if ./cloc-tmp contains a recent git pull from a first run.

Closing for a cleaner PR


Publish 07/07/2022 3:30 PM PT

Docs Build status updates of commit a879716:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-AutoSensitivityLabelPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

skype/skype-ps/skype/Get-CsOnlineLisLocation.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Get-CsOnlineLisPort.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Get-CsOnlineLisSwitch.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Get-CsOnlineLisWirelessAccessPoint.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/New-CsOnlineLisLocation.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Remove-CsOnlineLisLocation.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Remove-CsOnlineLisPort.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Remove-CsOnlineLisSwitch.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Remove-CsOnlineLisWirelessAccessPoint.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsOnlineLisLocation.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsOnlineLisPort.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsOnlineLisSwitch.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsOnlineLisWirelessAccessPoint.md
:white_check_mark:Succeeded
View (skype-ps)

teams/teams-ps/teams/New-CsTeamsUnassignedNumberTreatment.md
:white_check_mark:Succeeded
View (teams-ps)

teams/teams-ps/teams/Set-CsTeamsUnassignedNumberTreatment.md
:white_check_mark:Succeeded
View (teams-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


[Feature Request] move cursor up and down

At first , thanks very much for this plugin, it's a good way, and the only way AFAIK to implement emacs keybindings in obsidian on windows and linux OS.
I notice that there are move cursor right / left commands and go to previous line /next line commands, but emacs need move cursor up and down commands, because go to previous line is not useful on the lines which are wraped, I need move up as i see,not the previous line as the editor deal with.

I don't have a clear idea of what cursor movements look like in code when dealing with wrapped lines, but I can look into this at some point.
Tracked here: https://github.com/timhor/obsidian-editor-shortcuts/projects/1#card-85220847

This is now available in v1.13.0


[webpack-cli] HookWebpackError: Only file and data URLs are supported by the default ESM loader

[webpack-cli] HookWebpackError: Only file and data URLs are supported by the default ESM loader

Set copy webpack plugin to 8.1.1 temporarily, will check on next update if it can be resolved


Integrate payment gateway in premium page

please assign me this issue under LGMSOC'21

Please may I know through which login email should I integrate the payment button?

Please may I know through which login email should I integrate the payment button?

Do you need a password as well?

No, But a new password will be created and also a registered mobile number for accepting the payment

<EMAIL_ADDRESS>8922075023

Ok thanks a lot

I am signing up on Razorpay they are asking for the verification code came on that mail id

209733


[IMP] compatibility with website_event_sale

i cannot understand what have happened to website_sale_available tour, it seems that the module (available) stopped work, but after some updates in this module

Try run tour manually and check which step doesn't work and why

But finish module updating first

locally all works fine

Ivan, the block transferred to checkout_redirection doesnt change values like in checkout_vakues, so its excessi to put those lines in checkout_vakues


Pooling allocator: investigate combining separate mmaps into one (unified per-instance) slot

After some discussion with @alexcrichton just now, the question of why wasmtime's pooling allocator maintains separate pools for memories, tables, and instance structs (and stacks, but those are special on Windows at least) arose.
Especially if we're considering using madvise to flash-clear state and make instantiation faster, it might make sense to investigate whether we can "transpose" the arrangement and put all of an instance's resources in one contiguous region (with appropriate guards of course).
For example, one instance slot could contain all of that instance's tables and memories, and the Instance struct, and perhaps the stack on non-Windows platforms.
The major advantage of this is that we can decommit (flash-clear) the whole region with one madvise syscall. In contrast, today, we need a separate madvise for each resource. This cost is somewhat hidden today because we write ~every byte of the Instance and the tables (with eager init) but if we lazily initialize state in tables and/or Instances (e.g. lazy anyfunc init) this could matter more.

cc @peterhuene, you probably know the reason for separate mmaps here.
One idea is that we could possibly have less fragmentation by putting everything in one since we don't technically need guards between the instance and the tables (in theory at least), although we do for sure needs guards on stacks and on memories.

The primary reason for the disjoint instance resources is that it greatly simplified the uffd implementation as we could just monitor a single range for all linear memories rather than discrete parts of a range representing a single instance (or have to worry about faults from things like tables or stack pages).
Indeed, the cost was additional madvise calls to make it simpler. Lucet has the design proposed here where all instance resources remain in a continuous slot (and thus a single madvise call), but its uffd handler has to handle faults in pages not meant for linear memory too.
A single madvise call is definitely preferable and if we're replacing the uffd implementation, I think this makes sense.

Using separate pools would also make it harder to leak pointers (or even cause interpret attacker controlled bytes as a pointer) in case of bugs I would guess.

A bit belated but a month or so I did some investigation into this to see what would happen. My findings at the time was that the cost for an madvise call was proportional to the size of the memory that we're madvise-ing, even if that memory wasn't present. My conclusion at the time was that it was better to do the little madvise calls we do today rather than lumping everything into one giant allocation where one madvise call is all that's necessary to blow away.
I wasn't super scientific in my findings, though. Additionally it was also awhile ago I collected data for this and I probably don't have the branch around any more. Wanted to note though that I don't think this is necessarily a slam dunk and before trying to proceed with this (if ever), we'll want to carefully evaluate performance.


add error system

Rich errors in development AND production, but production ones will be a link to the error markdown file.
Also includes the error message added in #1801

Related: https://twitter.com/acdlite/status/1017881577601187840
https://github.com/facebook/react/tree/f8456b2ecbf194d19d70ff057f251cbc5814bc34/scripts/error-codes

✨👏👏👏


DROOLS-1236 MBean aggregation of statistics mechanism

Requires droolsjbpm/droolsjbpm-knowledge#154 .
@etirelli @mariofusco can we review this, please? Thx.

(org.drools.compiler.integrationtests.KieContainerTest.testIncrementalCompilationSynchronization test timed out after 10000 milliseconds)
Jenkins, retest this

(JpaOptLockPersistentStatefulSessionTest.testOptimisticLockInterceptor)
Jenkins, test again :8ball:

@tarilabs lets discuss the registration of the mbeans, but everything else looks good.

Excellent, thank you for the explanations. +1 to merge!

JpaOptLockPersistentStatefulSessionTest.testOptimisticLockInterceptor
Jenkins, test again :8ball:

@etirelli , this additional commit separates MBean for Stateful Vs Stateless, as discussed also with @mariofusco . There is a "companion commit" in the referenced PR too as expected to reflect this. Could you kindly review again, please? Thx.

I think it is good to merge now. +1


Can we add more lib packages like CV3 or Pilllow ?

Hi,
I'm new with sandbox, I just want to know if I can add more lib packages like CV2 or Pillow for image processing ?
If yes, please show me how.
Thanks and regards.

Related https://github.com/langgenius/dify-sandbox/issues/37

1、find the linux pakages the  CV2 or Pillow  needs and add them in conf file   which shows in the FAQ
2、find the system call   CV2 or Pillow  needs and add it   in the https://github.com/langgenius/dify-sandbox/blob/main/internal/static/python_syscall/syscalls_amd64.go
if you do not konw you can add all the sys call 。such as from number 0 to 500     0,1,2,3,4,5...500
3、add the linxu package and apt-install them in the docker file
4、build the source code and rewrite the dockfile file（pip3 install your package ）

1、find the linux pakages the CV2 or Pillow needs and add them in conf file which shows in the FAQ
2、find the system call CV2 or Pillow needs and add it in the https://github.com/langgenius/dify-sandbox/blob/main/internal/static/python_syscall/syscalls_amd64.go
if you do not konw you can add all the sys call 。such as from number 0 to 500 0,1,2,3,4,5...500
3、add the linxu package and apt-install them in the docker file
4、build the source code and rewrite the dockfile file（pip3 install your package ）

These are the steps for creating new dockerfile of sandbox to support cv2/Pillow or these are solutions for it?
Thank you :)


React component

I've just noticed the buttons no longer work on my React site. And i see that the ReadME file has taken out the 'for react component' section. Are you no longer supporting React for this?

The official create-react-app has no problem transpiling ES6 class / module syntax to ES5 for packages in node_modules. Other than ES6 class / module, the code here is actually ES3 compatible.
Therefore I decided to just publish it as ES6, and it's available on npm:
https://www.npmjs.com/package/react-github-btn

Thanks @ntkme! Will try it later 👍

Seems to be working great. Thanks again 👍

Need to re-open this as I'm receiving this error after a hot reload. I'm using GatsbyJS by the way.

  componentDidMount () {
    this.paint()
  }
  componentWillUpdate () {
    this.reset()
  }
  componentDidUpdate () {
    this.paint()
  }
  componentWillUnmount () {
    this.reset()
  }

The error you see could happen only if this.reset() is called twice in a row without this.paint() in between, which should never happen in a proper lifecycle. Somehow your react life cycle is broken by hot reload.

There is nothing to suggest that my react life cycle is broken by hot reload, especially when this is the only component breaking. I'm just running from a standard GatsbyJS v2 install. With a simple GH Button import with 3 GH buttons appearing on the page.

Well, another possibility is that a component is relocated in DOM without properly unmount and then remount. The current implementation relies on properly unmount and remount and component get moved around in VDOM, if that's not the case, then it's screwed.

Can you try if 1.0.3 still has this problem?

Yeah that seems to have worked! :) What was changed?

It was my second guess then. The component was moved with in DOM during the life cycle. In order to make sure DOM modification does not interfere with ability to relocate, the root element for the component cannot change. Basically I wrapped another <span> that does not change to be the root element:
https://github.com/ntkme/react-github-btn/commit/71f5b7b264c19e8870230be17bf05b4d452ae44f#diff-168726dbe96b3ce427e7fedce31bb0bcR11

Excellent - good work! 👍

I have an awkward situation about ES6 in node_modules. I'm using next.js to develop my application, it's not easy to custom webpack config to transpile ES6 packages in node_modules. If I use the HTML version of GitHub Buttons, the data-xxx on a tag will cause a TypeScript error, so that I have to add a new interface. I don't want to do anything of them. So, I choose to copy this component code and import github-buttons...
But after I try, I find another problem, github-buttons use window object and not compatible with next.js so I can only use HTML version.

@yujiangshui Can you open a new issue and be explicit about the errors?


after forbidding uploading files to the channel from the stream: music is not downloaded from vk pages

Hello everyone. After the lock on uploading files to the channel from the stream: music from vk pages is not downloaded. Tracks that are downloaded on request in the p command are downloaded.

Fixed. Thanks.


VUID-vkCmdPushConstants-size-00371 for Ch08_Sample03_LargeScene_Release

Running through the samples on Linux Mesa Ubuntu machine, found this demo is getting
Validation layer:
 Validation Error: VUID-vkCmdPushConstants-size-00371
 Object 0: handle = 0x5fc19fca11e0, type = VK_OBJECT_TYPE_COMMAND_BUFFER;
 MessageID = 0x7596dbc5
 vkCmdPushConstants(): offset (0) and size (132) that exceeds this device's maxPushConstantSize of 128.
The Vulkan spec states: size must be less than or equal to VkPhysicalDeviceLimits::maxPushConstantsSize minus offset

@spencer-lunarg That's an amazing finding! Many thanks!
Fixed in 594c736afa0582a65d4dfc2ad7749687a9c57094 (chapters 8 and 10)


[e2e]: container-based workflow_dispatch main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/5606435561
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.workflow_dispatch.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.workflow_dispatch.main.default.slsa3.yml
Trigger: workflow_dispatch
Branch: main
Date: Thu Jul 20 03:10:11 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/5607033939
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.workflow_dispatch.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.workflow_dispatch.main.default.slsa3.yml
Trigger: workflow_dispatch
Branch: main
Date: Thu Jul 20 05:02:34 UTC 2023
Tests are passing now. Closing this issue.


[SPARK-49175][PYTHON][MIRROR] Use UnsupportedType to check DataType validation for Arrow UDF

What changes were proposed in this pull request?
Use UnsupportedType instead of YearMonthIntervalType for type checking in Arrow UDF.
Does this PR introduce any user-facing change?
Yes. Change the doc as ArrayType<TimeStampType> has already supported in #41240.
How was this patch tested?
GA
Was this patch authored or co-authored using generative AI tooling?
No.

cc @zhengruifeng @ueshin @xinrong-meng


Ability to install a particular version of Kubernetes cluster for Docker Standalone Cluster

Feature Request
Ability to install a particular version of Kubernetes cluster for Docker Standalone Cluster
Describe alternatives you've considered
I couldn't find any alternatives
Additional context
This came up because we are now noticing an issue in K8s 1.21.2 version which is causing issues in Docker E2E tests for standalone and management + workload clusters. Context - https://github.com/vmware-tanzu/tce/issues/1136#issuecomment-896026435
I noticed configuring Kubernetes Version was not possible in Docker Standalone Cluster, haven't tried with AWS/vSphere/Azure
Currently Tanzu Framework's cluster plugin has this feature by having a --tkr option
$ tanzu cluster version
v1.4.0-pre-alpha-2

$ tanzu version
version: v1.4.0-pre-alpha-2
buildDate: 2021-08-10
sha: 5a42a2b

$ tanzu cluster create -h
Create a cluster

Usage:
  tanzu cluster create CLUSTER_NAME [flags]

Flags:
  -d, --dry-run       Does not create cluster, but show the deployment YAML instead
  -f, --file string   Configuration file from which to create a cluster
  -h, --help          help for create
      --tkr string    TanzuKubernetesRelease(TKr) to be used for creating the workload cluster. If TKr name prefix is provided, the latest compatible TKr matching the TKr name prefix would be used

Global Flags:
      --log-file string   Log file path
  -v, --verbose int32     Number for the log level verbosity(0-9)

Looking at the code, given a TKr name, it fetches matching TKrs, then it sets the options.KubernetesVersion which in turn gets used to set the KUBERNETES_VERSION
https://github.com/vmware-tanzu/tanzu-framework/blob/main/pkg/v1/tkg/constants/config_variables.go#L141
https://github.com/vmware-tanzu/tanzu-framework/blob/main/pkg/v1/tkg/client/cluster.go#L453-L461
I tried to use the KUBERNETES_VERSION environment variable but that didn't work with Docker K8s cluster
$ guest_cluster_name="guest-cluster-${RANDOM}"
$ KUBERNETES_VERSION="v1.20.8+vmware.1" CLUSTER_PLAN=dev CLUSTER_NAME="$guest_cluster_name" tanzu standalone-cluster create ${guest_cluster_name} -i docker -v 10

It still used 1.21.2 version and installed the cluster on top of Docker

Closing - there is a new standalone-cluster proposal that uses a different model with a much liter weight methodology. Please look at the proposal, try it out, and give your feedback there!
Since the current standalone-cluster plugin is being deprecated in a future release, we will not be accepting new features.


[CreatePrimFunc] Support multi-source ReduceNode

follow-up to #62 , extend CreatePrimFunc to support Reduction with multiple sources.
i.e argmax example from https://tvm.apache.org/docs/how_to/work_with_schedules/tuple_inputs.html
# x and y are the operands of reduction, both of them is a tuple of index
# and value.
def fcombine(x, y):
    lhs = tvm.tir.Select((x[1] >= y[1]), x[0], y[0])
    rhs = tvm.tir.Select((x[1] >= y[1]), x[1], y[1])
    return lhs, rhs

# our identity element also need to be a tuple, so `fidentity` accepts
# two types as inputs.
def fidentity(t0, t1):
    return tvm.tir.const(-1, t0), tvm.te.min_value(t1)

argmax = te.comm_reducer(fcombine, fidentity, name="argmax")

# describe the reduction computation
m = te.var("m")
n = te.var("n")
idx = te.placeholder((m, n), name="idx", dtype="int32")
val = te.placeholder((m, n), name="val", dtype="int32")
k = te.reduce_axis((0, n), "k")
T0, T1 = te.compute((m,), lambda i: argmax((idx[i, k], val[i, k]), axis=k), name="T")

cc: @YuchenJin @ZihengJiang @tqchen

cc @Hzfengsy , it would be great if you can also take a look.
We can consider upstream this part earlier since they can also benefit upstream

Thank you @hypercubestart, it's merged!

@hypercubestart Hi Andrew, I need to upstream the changes in this PR to mainline to unblock the TIR schedule primitives/transformations for tuple reduction (specifically, reduction factorization and cross-thread reduction). I also will update the behavior of this PR by adding LetStmts on the above of the sequence of BufferStores, to avoid incorrectness issue.
I wonder if it's okay for you to let me upstream it to mainline? Thanks so much!

@hypercubestart Hi Andrew, I need to upstream the changes in this PR to mainline to unblock the TIR schedule primitives/transformations for tuple reduction (specifically, reduction factorization and cross-thread reduction). I also will update the behavior of this PR by adding LetStmts on the above of the sequence of BufferStores, to avoid incorrectness issue.
I wonder if it's okay for you to let me upstream it to mainline? Thanks so much!

@MasterJH5574 hi Ruihang, yes absolutely! Thank you so much for helping upstream this!

@MasterJH5574 hi Ruihang, yes absolutely! Thank you so much for helping upstream this!

@hypercubestart Thank you so much 😆!! Will add you as a co-author and ping you when the PR is ready on mainline!


"Re:amaze" dev issue

The icon entry for "re:amaze" is problematic for WIndows developers:
error: invalid path 'src/drivers/webextension/images/icons/Re:amaze.png'

https://github.com/AliasIO/wappalyzer/blob/master/src/technologies/r.json#L301-L317
I'm not sure if similar issues have come up before. I understand that the product or company does actually have a colon in it's name. However I'd suggest dropping it from all elements (it's not as if it exists in their DNS entries).

What do you mean by the last line? Renaming the icon should be sufficient, right?

Doesn’t the icon file name need to match the product name?

I could be assuming a relationship where there isn’t one.


Clean up etc folder

Why are images in etc folder instead of images? @oaaky any idea?

we can put those images in root directory as well


fix(cmd/cel-key): Add error when no node type is provided to cel-key

In our cel-key utility, we should error out with "no node type provided" during the following:
https://github.com/celestiaorg/celestia-node/blob/8657edc37d3911d42de447d9d0c93c4676a148c9/cmd/cel-key/node_types.go#L29-L32

can I work on it?

@nitinmewar Yes! Feel free

can I work on it?

Are you still working on this?