Add method: VM.Bind()

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

45 of 57 (78.95%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 67.83%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/program/static_analyzer.go
4
6
66.67%

interpreter.go
24
26
92.31%

internal/program/program.go
0
4
0.0%

vm.go
15
19
78.95%

Totals

Change from base Build<PHONE_NUMBER>:
0.08%

Covered Lines:
5168

Relevant Lines:
7619

💛  - Coveralls


Greek island bordered by the continental Turkey

One of the Greek islands in the game is connected to the mainland and is bordered by Turkey

Will correct

And there are other examples - need to address them as well


fix(ddd-kata): Fix Domain Role Definition + DDD Aggregate Video

Fixing https://github.com/SAP/curated-resources-for-domain-driven-design/issues/33

The Language Check is complaining of a link using a unwanted word.


Colour Format

Hi, I've just installed and started configuring ly. I'm sorry if this is a dumb question but what colour format does ly use?

nvm, got it


Add support to vscode.dev for remote tunnels

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

I like to use this extension on my local, but is very frustating when want to use it in my remote tunnel in vscode.dev
Describe the solution you'd like:

Add support to vscode.dev for remote tunnels to use the extension.
Describe alternatives you've considered:

Does not exist.
Additional context:

Thank you for reaching out. This enhancement is already tracked in #989. So I'm closing this one as a duplicate.


Managed Clusters Generate SDK

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run automation - sdk

/azp run automation - sdk

No ARM API review needed.  These are swagger fixes and don't represent changes to the underlying API.

@NullMDR can we bypass the breaking changes and merge the pr? the changes here are issues that were not showing up on the automation on the original pr https://github.com/Azure/azure-rest-api-specs/pull/10085

/azp run

/azp run automation - sdk

@jianyexi Could you please help to point out what is this error message related to?
R4005 - UniqueXmsEnumName
Must not have duplicate name of x-ms-enum extension , make sure every x-ms-enum name unique.
at specification/servicefabric/resource-manager/Microsoft.ServiceFabric/preview/2020-01-01-preview/nodetype.json:539

@jianyexi Could you please help to point out what is this error message related to?
R4005 - UniqueXmsEnumName
Must not have duplicate name of x-ms-enum extension , make sure every x-ms-enum name unique.
at specification/servicefabric/resource-manager/Microsoft.ServiceFabric/preview/2020-01-01-preview/nodetype.json:539

Pls ignore  the error, the result of staging LintDiff  is correct , the version in prod has a bug wihch has been fixed in staging version

@akning-ms Please help to merge this PR with known issue in lintdiff


Remove deprecated dynamic exception specification

gcc 7.1.1 says:
/build/clasp/src/clasp-3.3.0/src/clasp_options.cpp:96:15: warning: dynamic exception specifications are deprec
ated in C++11 [-Wdeprecated]
  ~ArgString() throw (std::logic_error) { POTASSCO_ASSERT(!ok() || !*in || off(), "Unused argument!"); }
               ^~~~~

This pull request fixes that.

Hi,
thank you for your pull request.
I know that  dynamic exception specifications are deprecated since C++11 (and removed in C++17),
however, they are currently the lowest common denominator to express what is intended here
given that current versions of clasp still support C++03 and older compilers (e.g. Visual Studio 2013).
Simply removing the specification (as suggested in your request) is not an option and actually wrong
if the code is compiled as C++11.
This is because in C++11 destructors are noexcept if not explicitly specified otherwise. Hence, an exception from ~ArgString() without the specification would result in a call to std::terminate, which is not what is intended.
The correct fix would be to explicitly mark ~ArgString()  as noexcept(false). However, this is not supported by C++03 and/or older compilers. I will probably add some kind of conditional compilation to get rid of the warnings and/or support C++17.


Cleanups prior to repo move

Make code of conduct consistent with other swift.org repos
Remove shippable.yml as we will be using Swift CI in future
Reword PROJECT.md slightly

CI failed because this PR removes the CI 😁


Support overlay on Layouts

Is there a deep reason why overlaying an annotation onto a Layout doesn't work?

Of course, I can overlay it on each of the items in the layout, but can't the overlay operation simply iterate through the items in the layout and overlay the annotation on each one?  That's what happens for NdLayouts and GridSpaces, so I'm not sure why it doesn't work here.  Sure, there can be times that doing so will lead to an error, but I don't think those times should stop it working when it makes sense as it does here.

This might be ok in cases like this where you are overlaying a simple element but we are more uncertain of how to distribute containers, e.g layout * layout for example...
Generally we never intended to support * at the layout level.

I'm pretty sure that LayoutAnnotation always makes sense and that it's very useful, because annotating the same location on a bunch of plots is a very reasonable thing to want to do.  LayoutElement in general also seems like it it would make sense, i.e. to see how one set of data relates to a lot of other sets of data. Both of these are a distributive operation of scalars over lists, which is very clearly meaningful and useful.
Layout*Layout would presumably be elementwise multiplication (not cross product! :-), which is well defined when the lists are the same length, and seems like it would be very useful in some cases, but maybe those don't come up often.  If they are different lengths, I'm sure we could define a default behavior, but my gut feeling is that such a default is very unlikely to be very useful, so it seems reasonable not to allow it unless some amazing application for it comes up.
So I vote for LE to be supported, and LL to be supported when the lists are the same length.

Seems fine. I'd be happy to support Layout * Element/Overlay/HoloMap/DynamicMap but nothing else.

We have discussed the elementwise zipping semantics for layout * layout a number of times but we have never really known how to feel about it. Supporting the components Philipp makes sense at this time though.

Is there an issue documenting the L*L discussion that I could look at?  To me that seems very well defined (when they are the same length) and sometimes useful, and supporting it seems reasonable to me, but I may not have thought of some subtlety.  I'm not arguing strongly about it, just don't see the problem.

(when they are the same length)

That doesn't sound very well defined to me, what happens if they are not the same length? Some of that discussion is here: https://github.com/ioam/holoviews/issues/2075 but some of it wasn't captured I'm guessing.

This is what I mean about us not knowing what we feel about it!
That is why we should tackle the case we do agree makes sense first allowing us to decide how to handle layout * layout later.

Seems very straightforward to me.

Sure it's straightforward in itself but it's also hard to discover and raises all kinds of expectations about what might and might not be supported. A user who tries it and gets an exception will assume it's not supported while a user who tries it and it does work will start expecting it to always work. For all the other types the semantics of * are very straightforward and unambiguous, the mere fact that we are having this discussion shows that's not the case here. That definitely makes me question that the utility of allowing it in one very specific case, outweighs the possible confusion it might cause about what is and isn't supported.

I guess I disagree with that approach in itself, then.  I think that if we support the cases that are straightforward, then that will cover what normal people will do, and they don't need to even ever dream that there are non-straightforward cases.  Whereas if we fail to allow what is very clearly meaningful, many people will try it and have no idea why it doesn't work, then move on slightly bewildered.  Basically, people really don't care what happens for some case they aren't trying, so if it works for the cases they do try, then they are happy. Why should the fact that some cases are not straightforward have any bearing on the ones that are?

The mere fact that we are having this discussion is a case in point -- I expected L*L to work for equal-length lists, and I know exactly what should happen in that case, and I think everyone will agree on what they think should happen there if it's supported.  So I would have been happy and moved on with my life, never worrying about what would happen if the lengths were unequal, since I'm not going to try that (and if I did, I would have no idea what to expect).

I'm still at a strong -1 for allowing overlays of two Layouts, the zipping semantics is only one possibility you could imagine, while all other supported overlay operations are all very clearly defined. Indeed those semantics differ substantially to the behavior of NdLayouts which are matched on their keys:

There is no other overlay operation in holoviews that has zipping semantics so this is an entirely new concept to introduce. In all my years of using holoviews I have also never once thought to try doing this and to be quite honest overlaying by position rather than by matching on some key also scares me too much to ever consider using it. It's way to easy to get the ordering wrong and end up with something you didn't intend.

I have no strong commitment to L*L other than to have expected it to work, so it's fine to decide not to support it. But this issue isn't about L*L, which only came up later, it's about L*A (broadcasting, not zipping).

But this issue isn't about LL, which only came up later, it's about LA (broadcasting, not zipping).

Which I've implemented in the PR referenced above.


Add Mixpanel for usage analytics

This is so we can get a sense of adoption and usage for current users, and have a baseline in looking at rolling out to other roles or schools.
It adds a stub of JS in the main template, that requests the script from Mixpanel, and then each page's entrypoint tracks page views for now, along with data about the user role).  We can add other data later if we need it (eg., usage of particular features).
This PR also cleans up some dead code for the school overview page leftover from a previous merge.

Also, to be explicit, no personally identifiable end-user data is being sent here (even for teachers and principals).


Skill Name
Jekyll
Why?
Jekyll is a static site generator written in Ruby by Tom Preston-Werner. It is distributed under the open-source MIT license
Reference Image

Code of Conduct Acknowledgment

[X] I have read and agree to the Code of Conduct.

In this repo, things move quick!
same as in the other one lol

Just curious, how do you create the icons? I would like to contribute and design one myself.

Just curious, how do you create the icons? I would like to contribute and design one myself.

You may want to read the contributing guidelines, if you get stuck because some lack of precisions, you can ask us ;)


move css and view engines out of the main code

Imho, having all this stuff in one place is better than having it scattered all around the code.
This properly errors out on invalid options. Generated output should be the same as before.
ref #44

I love this.

might as well be separate files!

Sorry this got closed from some GitHub voodoo. It doesn't have the option for me to re-open it form some reason! :( Please re-create your pull request.


'sevctl ok' reports wrong C-bit position?

I ran sevctl ok on an AMD Rome machine:
...
[ PASS ]     - Physical address bit reduction: 47
[ PASS ]     - C-bit location: 15
[ PASS ]     - Number of encrypted guests supported simultaneously: 509
...

As far as I understand it, the C-bit location is 47, and the physical address bit reduction is 1 (instead of 48-bit addresses we can only have 47-bit).
The code in sevctl (ok.rs) is:
                        Test {
                            name: "Physical address bit reduction",
                            gen_mask: SEV_MASK,
                            run: Box::new(|| {
                                let res = unsafe { x86_64::__cpuid(0x8000_001f) };
                                let field = res.ebx & 0b1111_1100_0000 >> 6;

                                TestResult {
                                    name: "Physical address bit reduction",
                                    stat: TestState::Pass,
                                    mesg: Some(format!("{}", field)),
                                }
                            }),
                            sub: vec![],
                        },
                        Test {
                            name: "C-bit location",
                            gen_mask: SEV_MASK,
                            run: Box::new(|| {
                                let res = unsafe { x86_64::__cpuid(0x8000_001f) };
                                let field = res.ebx & 0b01_1111;

The "equivalent" code in QEMU (target/i386/sev.c) is:
host_cpuid(0x8000001F, 0, NULL, &ebx, NULL, NULL);
cap->cbitpos = ebx & 0x3f;

/*
 * When SEV feature is enabled, we loose one bit in guest physical
 * addressing.
 */
cap->reduced_phys_bits = 1;

For the C-bit location 32 should be added. And Physical address bit reduction should be renamed to Physical address bits

For the C-bit location 32 should be added or it should be renamed to C-bit location in page table entry.

I think that the C-bit location ebx mask is wrong:
                                let res = unsafe { x86_64::__cpuid(0x8000_001f) };
                                let field = res.ebx & 0b01_1111;

the mask should be res.ebx & 0b11_1111; (equivalent to qemu's ebx & 0x3f).

For the C-bit location 32 should be added or it should be renamed to C-bit location in page table entry.

I think that the C-bit location ebx mask is wrong:
                                let res = unsafe { x86_64::__cpuid(0x8000_001f) };
                                let field = res.ebx & 0b01_1111;

the mask should be res.ebx & 0b11_1111; (equivalent to qemu's ebx & 0x3f).

Manual says "5:0 C-bit location in page table entry" .. you are right

Luckily our enarx sev kernel does the right thing:
https://github.com/enarx/enarx/blob/d2d2f60fb6453051a68c5388f1da17cfde6f38dd/internal/shim-sev/src/main.rs#L315-L316
        // mask the other bits
        "and    edx,    0x3f",

Do you want to create the PR?

Suggested fix for the C-bit location in PR #85 .


feat(brave): added search bookmarks

Description

Added search bookmarks action
Refactored code to use new useSQL hook

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi @ron-myers 👋
Do you mind checking this?

Hey @pernielsentikaer 👋 - happy to; I am travelling today and tomorrow but will find some time to review/test.

I can do it @ron-myers, I'll give it a quick spin 😊

HI @pernielsentikaer,
Updated with requested changes.


[Enhancement]: Add minimum requirements to README

What would you like to be added:
Minimum specs (CPU,MEM, diskspace) to deploy minishift in the README and maybe install.sh
Why is this needed:
Helps to avoid problems if too small VM or  Computer is used for installation

Sounds a good idea. I think 2 cores and 2GB is the min, based on what we have tested so far. @rhmk PR welcome :D

For me it was 3 GB.
/assign @osilkin98

/assign @osilkin98

If you just running the binary 2 cores and 2 GB. If you are going to build and run from source, it is 2 cores, 3 GB and 20 GB disk

When you're running from source for development purposes, 3 GB still ends up being too small. For my Vagrant setup, I allocated 4 cores and 6 GB, although you can probably get away with 5 GB since I've never seen it grow past that. Otherwise you will occasionally run into severed SSH connections, freezing builds, and failed launches.

Great, thanks for your coments, which is really helpful for now.
@rootfs Don't know how to create PR :-(

/assign @osilkin98 @oglok


How Is DR/Failover/Automatic Replica Discovery Configured with the Azure DevOps Extensions?

If all my Azure Pipelines read config from the ADO task AzureAppConfiguration@8 and they point to an Azure App config resource in South Central US, if the entire South Central US region is down, how should I have AzureAppConfiguration@8 configured so that it fails over to one of my many geo-replicas?

The App Configuration pipeline tasks currently don't have built-in support for replica discovery and failover. We may consider adding these features in the future.
In the meantime, since each replica has its own endpoint, you can parameterize the App Configuration endpoint in the pipeline tasks. This allows you to switch to a different endpoint in case of an outage.

@zhenlan Thank you for the answer and the excellent workaround description. I have updated this question to be a request for the feature.  I understand you will need to gauge interest, prioritize, etc, so this could be quite some time before any action is taken. Thanks!


Fix expectations for PointerAccessChains/pointer_index_is_constant_1.cl

The new code is correct.  The constant indexing into an array of arrays of floats collapses into a constant index of an array of floats.
Ref #1292

cc: @rjodinchr

Thank you @dneto0.
I think I got to this one during the end, and I was a bit confused as to whether losing the arraystride was an issue or not.
In order to unblock TAP, I decided to just mark it as failing to come back to it later.
Thanks again for taking care of it.


TypeScript syntax highlighting error in for-loop

VSCode Version: 0.10.11
OS Version: Mac OS X Yosemite (10.10.5)
Default syntax highlighting
Issue persists when running VSCode with --disable-extensions

Syntax highlighting gets confused within for loop. Strings don't get recognized. Elements that follow a string are considered to be strings instead (as it seems to me).
After the for-loop there are still syntax highlighting errors but line 74 in screenshot looks fine again.
Steps to Reproduce:

Open new TypeScript file within Angular 2 project (aka create new component)
Create for loop (see Screenshot)

I also noticed related issue.
In the following simple code (file named "test.js"):
var l = 5;
for( var i=0; i<l; i++ ) {
var in_loop; /* coloring stops working */
}
After the opening brace '{' in the for loop line, any var declared inside is not colored correctly.
If the color theme being used is "Dark+ (default dark)" most of the color inside the loop is 'green'

Does it persist when you add spacing like this in the loop?
for(var i = 0; i < I; i++)
If that resolves the issue, it is probably https://github.com/Microsoft/TypeScript-TmLanguage/issues/11

I reported a similar issue over here https://github.com/Microsoft/vscode/issues/4841 and I think the problem is the : and other few things that I found. I've updated my original issue with some screenshots that may be useful.

@bgse: You're right. Adding spaces fixed the highlighting. Feels like a kind of workaround though.
@ericmartinezr: Thx!

duplicate of https://github.com/Microsoft/TypeScript-TmLanguage/issues/11


Cannot install - composer problem

When i try to install plugin, i get this error:
Composer output: Package "craftcms/vue-asset" listed for update is not installed. Ignoring.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for selvinortiz/doxter 3.4.7 -> satisfiable by selvinortiz/doxter[3.4.7].
- selvinortiz/doxter 3.4.7 requires erusev/parsedown-extra 0.8.0-beta-1 -> satisfiable by erusev/parsedown-extra[0.8.0-beta-1] but these conflict with your requirements or minimum-stability.

Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.

My system info:
Application Info
PHP version	7.2.2
Database driver & version	MySQL 5.5.5
Image driver & version	GD 7.2.2
Craft edition & version	Craft Solo 3.1.8
Yii version	<IP_ADDRESS>
Twig version	2.6.2
Guzzle version	6.3.3
Imagine version	0.7-dev
Plugins
No plugins are enabled.

Hi, yes, unfortunately due to a security issue in a Doxter dependency, I had to realease a version with a beta package to avoid that.
That means that for now, Doxter requires your minimum stability to be set to beta as shown in the install guide here https://selvinortiz.com/plugins/doxter/installation
I'm sorry about this😔

Thanks for quick reply!
I aded minimum stability setting to composer.json and installed it trough console. I guess it cannot be installed trough control panel for now? Because when i tried to install it trough CP, it displayed same error.

@piotrpog Odd! Once your package.json file is updated, it should install in both places without any problems. I'll take a look tomorrow and see if I can reproduce that issue.

@piotrpog Are you still having this issue? I could not reproduce it locally.


Bug literal obfuscation: garbleDecrypt shows up in obfuscated file

Currently the identifier of the injected function garbleDecrypt doesn't get obfuscated, I don't get why this is as all other identifieres even in the same function get obfuscated.
package main

import (
	"crypto/aes"
	"crypto/cipher"
)

func main() {
	println(garbleDecrypt([]byte("\xbd\x1e\xef\x0e\xc08\xd9\xd1\\Z\x9c6\x83\x8c]\xc3\x18\xca\xf3d\xbblBy<}\xeaw\xfemR\xe0\xe5^^S}\xef\r")))
}
func garbleDecrypt(zz8R2glwq []byte) string {
	zavpGIsKw, zq5L43cyy := aes.NewCipher(z3uyPF0rS)
	if zq5L43cyy != nil {
		panic("garble: literal couldn't be decrypted: " + zq5L43cyy.Error())
	}
	zNZHRXNGb, zq5L43cyy := cipher.NewGCM(zavpGIsKw)
	if zq5L43cyy != nil {
		panic("garble: literal couldn't be decrypted: " + zq5L43cyy.Error())
	}
	z0WzbQH2R, zq5L43cyy := zNZHRXNGb.Open(nil, zz8R2glwq[:12], zz8R2glwq[12:], nil)
	if zq5L43cyy != nil {
		panic("garble: literal couldn't be decrypted: " + zq5L43cyy.Error())
	}
	return string(z0WzbQH2R)
}

var z3uyPF0rS = []byte("\xa0N\xa9\xe7\b\x17\xa3\xbd\xb4\x11\x89\xfd\xd7Ё\xdd")

Huh, I never noticed. Agreed that this is a bug. When it does get fixed, a regression test would be good.


Keep Hierarchy between restarts

Simple suggestion: keep the hierarchy layout between Editor restarts for an even more constistent experience.

They @Thane5 I'm not sure if I understand exactly what you mean, your hierarchy it's not restoring when opening/closing the editor?

Done! Implemented on the release 0.1.1: https://github.com/brunomikoski/SceneKeeper/releases/tag/v0.1.1


line margin -l does not work with 0

Hi there, thanks a lot for building comby-search. It's been absolutely helpful wrapping comby and searching together!
Unfortunately, there's an issue with the line margin property. I was expecting it to show no margins when passing 0 to it and only the matched line. Also, when I pass other values, it returns a different margin. An example is shown below
$ ls
test.txt
$ bat test.txt
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: test.txt
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ a
   2   │ cat
   3   │ in
   4   │ the
   5   │ hat
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
$ cb -f '*.txt' 'cat' -l 0
test.txt
   2 │ cat
   3 │ in

I was expecting it to only show
$ cb -f '*.txt' 'cat' -l 0
test.txt
   2 │ cat

Also, these outputs don't match for 1 & 2
$ cb -f '*.txt' 'cat' -l 1
test.txt
   1 │ a
   2 │ cat
   3 │ in
   4 │ the
$ cb -f '*.txt' 'cat' -l 2
test.txt
   1 │ a
   2 │ cat
   3 │ in
   4 │ the
   5 │ hat

Hey, thank you so much for the feedback! I've pushed a new commit to fix this issue.
With -l 0:

With -l 2:

Regarding the issue that outputs don't match for 1 & 2, I think it's an expected behavior, since the match is at the top of the file, the case -l 1 should show the match at line 2, and line 1 and 3 as a margin. The case -l 2, it should show the margin lines up to line 4 in the bottom, and on top, the minimum will be line 1, right? Or I missed anything? :D

Hey @huytd,
Thank you so much for the fix. I will pull the latest version and test it out.
Yep, I rechecked for the cases of -l 1 & 2, and it makes sense. I'll strikethrough the issue description since its not a bug.
Closing the issue since it's fixed

Tested and it works perfectly.
$ cb -l 0 -f '*.txt' 'cat'
test.txt
   2 │ cat
$ cb -l 1 -f '*.txt' 'cat'
test.txt
   1 │ a
   2 │ cat
   3 │ in


Remove Advanced Table Properties in text editor

The "Advanced" tab in the Table properties editor for TinyMCE is not useful. Most users won't know what to input in these fields anyway. If possible we should remove this tab, if @sjDCC agrees

I think this is no longer and issue (at least I can't find the advanced settings on the write plan tab). Is it ok to close @sjDCC and @stephaniesimms ?

yes ok to close @briri


master doesn't build

For bug reports, please give the relevant info:

Gogs version (or commit ref): 26342b0c2457ba3b8a79e05be75f85258b0e82eb
Git version: 2.8.3
Operating system: alpine linux 3.3
Database:

[ ] PostgreSQL
[x] MySQL
[ ] SQLite

Can you reproduce the bug at http://try.gogs.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist:

Description
gogs.CreateIssueOption.Closed() not defined... but I can't even find where the CreateIssueOption type is defined
$ make -B
go-bindata -o=modules/bindata/bindata.go -ignore="\\.DS_Store|README.md|TRANSLATORS" -pkg=bindata conf/...
lessc public/less/gogs.less public/css/gogs.css
go install "-v" -ldflags '-X "github.com/gogits/gogs/modules/setting.BuildTime=2016-06-15 11:40:01 UTC" -X "github.com/gogits/gogs/modules/setting.BuildGitHash=26342b0c2457ba3b8a79e05be75f85258b0e82eb"' -tags '""'
github.com/gogits/gogs/modules/bindata
github.com/gogits/gogs/modules/setting
github.com/gogits/gogs/modules/base
github.com/gogits/gogs/modules/template/highlight
github.com/gogits/gogs/models/migrations
github.com/gogits/gogs/modules/markdown
github.com/gogits/gogs/models
github.com/gogits/gogs/modules/template
github.com/gogits/gogs/modules/cron
github.com/gogits/gogs/modules/auth
github.com/gogits/gogs/modules/mailer
github.com/gogits/gogs/modules/ssh
github.com/gogits/gogs/routers/api/v1/convert
github.com/gogits/gogs/modules/context
github.com/gogits/gogs/routers/repo
github.com/gogits/gogs/routers/api/v1/misc
github.com/gogits/gogs/routers/dev
github.com/gogits/gogs/routers/user
github.com/gogits/gogs/routers/api/v1/repo
# github.com/gogits/gogs/routers/api/v1/repo
routers/api/v1/repo/issue.go:88: form.Closed undefined (type gogs.CreateIssueOption has no field or method Closed)
github.com/gogits/gogs/routers
github.com/gogits/gogs/routers/org
github.com/gogits/gogs/routers/admin
Makefile:20: recipe for target 'build' failed
make: *** [build] Error 2

...

I can't even find where the CreateIssueOption type is defined

In another repo: https://github.com/gogits/go-gogs-client
You probably just need to run go get -v -u ./... to update all dependencies.

@andreynering thanks. I dumbly assumed I had to use what's specified in the .gopmfile. updating everything to master lets master build :)


Updates Readme to indicate this library is deprecated.

@MicahZoltu should this repo set to "archived" or do you expect others to potentially pick it up?

Good question, we should probably wait to see if anyone chimes in on the deprecation (indicating they want to take over) before archiving it.  My personal recommendation is this project should not be used, and anyone wanting the functionality it provides should start a new project based on the new Ledger suite of JS libraries.  However, there may be people who depend on this that would prefer to maintain it (including addressing the transitive dependency vulnerabilities).
If you think archiving it right now is appropriate, I won't push back against such a decision though.  :)

On further thought, I'm going to take your suggestion @axic and Archive this repository.  If someone wants to pick up the repository, we can always un-archive it.


deprecation: vim.lsp.handlers["textDocument/hover"], vim.lsp.handlers["textDocument/signatureHelp"]

Did you check docs and existing issues?

[X] I have read all the noice.nvim docs
[X] I have updated the plugin to the latest version before submitting this issue
[X] I have searched the existing issues of noice.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.11.0-dev-1066+g05d9e6a9e8
Operating system/version
Arch Linux 6.11.5-arch1-1
Describe the bug
According to this commit, vim.lsp.handlers["textDocument/hover"] is now deprecated.

vim.lsp.handlers["textDocument/signatureHelp"] has also been deprecated, here is the commit.


Ignoring collection order during comparison

It would be great to have the possibility to configure the comparison of collection objects in order to ignore the order of their elements.
When enabled, If all elements of the compared collections are equal but placed in a different order, the comparison should result successfull.
Here's an example of what I would like:
var expected = new List<string> { "A", "B", "C" };
var actual = new List<string> { "B", "C", "A" };
expected.ToExpectedObject().Configure(x => x.IgnoreCollectionOrder()).ShouldEqual(actual);

This feature has been added and is available in version 2.0.0.
ExpectedObjects has been changed to ignore order by default.  Currently to do otherwise would require you to use ExpectedObjectBuilder and replace the strategy with the    OrdinalEnumerableComparisonStrategy.  I'll make this easier in a future release.

Version 2.1.0 now supports the following syntax for achieving the original comparison:
new { ... }
    .ToExpectedObject(ctx => ctx.UseOrdinalComparision());

Why is the default to ignore the order? I was very surprised to find this is how it works now.
new [] {1, 2}.ToExpectedObject().ShouldNotEqual(new[] {2, 1});
I can see why sometimes I would want the order ignored, but in almost all cases, I care very much that the order is tested. I have many tests that specifically check the order of a collection. Those tests are no longer reliable since upgrading to this version. I had a false sense of security, which is exactly what I don't want in unit tests. I'd rather not have to go modify thousands of tests to add code to set the default to be what should be the default anyway.
I like this library a lot, but I think the default should be to compare the order, and allow an override to ignore the order. Certainly it is more common to want the order compared.

I apologize for the inconvenience this change has caused  you.
It's been awhile since I introduced this change, but I believe the decision was made to not consider order by default based upon usage patterns I found to be frequent within projects I work with as well as being influenced by the defaults selected by competing libraries.
What one considers to be the most frequent use case is highly subjective and will depend upon your typical testing style and patterns.  In my own test suites, I've found myself writing far more tests which validate that a specific entity or entities were added, updated, or deleted than tests which validate a request for all items of a set with a specified ordering.  That isn't to say this isn't the most common case for your tests, but it would be difficult to make general statements about what is the most common for all users of the library.
Unfortunately I don't know of a way for you to avoid modifying tests that depend upon the enumerable comparison semantics of the previous major semantic version of the library if you need strict ordering and want to use the latest version.


tooltip option

How can I leave the tooltip always to the top  so it does not appear to the left or right .example:
print

The solution to fix this is to set the alignment of the tooltip. This is tracked in #1977


Map more fields in the Calm transformer

Toni sent across the spreadsheet that explains how the Calm-Sierra harvest works, which exposes a couple of inconsistencies we might want to fix:

~UserWrapped1/ReproductionConditions maps to MARC 540, which we transform as a "Terms of use" note on Sierra records~
Notes maps to MARC 500, which we transform as a General note on Sierra records
PlaceName/Place maps to MARC 651, which we use to create Concept subjects
Name/Person maps to MARC 700/710, which we use to create Person/Organisation contributors

We should add this data when we see it on Calm records.

We don't need to expose ReproductionConditions: https://github.com/wellcomecollection/platform/issues/4773


Add build_info metric to ExternalSecrets

Is your feature request related to a problem? Please describe.
At GrafanaLabs we have an internal mechanism to discover new versions of components and upgrade them. In order to incrementally roll out this changes through our environments, we have an automated step that will verify that all new pods are running the new desired version and are healthy.
Describe the solution you'd like
A *_build_info Prometheus metric is introduced, which includes relevant build information, like the release number.
Ref: https://github.com/prometheus/client_golang/blob/main/prometheus/collectors/version/version.go

I would be happy to contribute this, opening the issue for discussion.


Brainstorm intermediate layer representations

Detailed Description
Brainstorm and compare intermediate layer representations.
Base and research for #486
Definition of Done
Documentation exists about:

[ ] Possible representations (including how and what data can be saved)

[ ] Persistent entity tracking (Ideas blow)?
[ ] What attributes have to be tracked:

static vs. dynamic| permanent vs. temporal
Type/Class
Motion

[ ] How perception is supposed to insert data into representations

[ ] Based on what data
[ ] How we can make sure that algorithms working with the data are reliable (Data Deduplication?)

[ ] How the other parts of the applications are supposed to use the representation and meet their goals.
[ ] Discuss with other Teams how usable the resulting interfaces are
[ ] Flowchart? Simulator scenarios where the representation might improve the situation (with rough application flow)
[ ] Explore visualization options
[ ] Depending on all above: Time/Work estimates and time to minimum viable product (MVP)

Effort Estimate
Open end
Testability
No response
Dependencies
No response

One of the screenshots I added to discord came from #389

Zum Thema Lane Detection: Es wäre an sich möglich die Lidar daten zu nehmen um die Erkennung von den Spuren zu machen, jedoch sind die besten und stabilsten Modelle momentan auf Kameradaten angewiesen, mir ist ein Paper zu dem Thema aufgefallen, das ein Selfsupervised learning Model verwendet, aber das war eher eine Kombination aus 6 Kameras, 5 Radaren und 1 Lidar, was meiner Meinung nach die Grenze der zugelassenen Sensoren für das Qualify überschreitet zudem enorm viel Kapazität der VRAM  für die Berechnung braucht und zudem auch sehr langsam ist wegen der enormen Menge an Daten.

Draft for the map/intermediate layer can be found here
Still a work in progress but feedback is very appreciated

I think you have designed a great draft.
Before you start your implementation, I recommend conducting ROS-specific research to identify elements that could enhance your architecture. This doesn't mean you should use only existing ROS Noetic features, but they can provide helpful inspiration, and you might find pre-existing solutions.
Examples

ROS Perception includes object message definitions: vision_msgs

Detection2D.msg
These messages can include probabilities: ObjectHypothesis.msg

There are ROS message definitions that publish a local map of probabilities: OccupancyGrid
Transforming coordinate systems is very common in robotics; have a look at TF2.
Plan to use the ROS parameter server for all kinds of parameters.

Try to find 2 or 3 team members for feedback because design decisions now are critical.

Props to you for the detailed investigation into the topic. There is loads of information in the Document provided. I suggest to start a similar draw.io project as to our mindmap in order to efficiently communicate the map representation as a UML-class diagram and the data flow chart as a modifieable entity.
One aspect I couldn't find in the document was, that there is currently no Entity in the definition which could represent lane markings. Maybe there should be some sort of Line entity, this could also get used for e.g. the merging of Lidar points, or for entities of which we don't know the depth (row of houses, a wall etc).
Also considering Traffic lights maybe there needs to be some sort of entity state. Which in the case of traffic lights might be red/green/yellow. But for a car this might be brake lights on, right indicator etc.
Regarding TF2: Using tf2 has a big advantage in my opinion:
The usual implementation of a tf2  listener  uses a Buffer. It is therefore possible to look into the past and track frames over time. This is also quite efficient because no global graph has to exist. Rather the combined information of multiple broadcasted messages represents the current state. I recommend reading this TF2 Design
However:
There is no possibility to add additional information to the TransformStamped.msg which are passed in the tf-Graph.
Considering this, a very important aspect is to find a suitable ROS-like way to propagate the information to users of the map. A service like structure (users can query the information at a mapping server) is probably sufficient if there is a limited amount of users. A purely topic based system would require the user to store the data and use it when necessary, which could result in outdated data. A tf2 like buffering system sound promising but is probably tough to implement.
Probably there are more possible solutions I didn't even consider yet.
As mentioned in the beginning there is probably already more information in the document than can be discussed in comments on this Issue. Feel free to arrange a meeting with interested members to further discuss entity structures, map propagation etc.

Thanks for reading and for the feedback of the draft. For further discussion I will be available on Monday from 13:00 until 15:30.
I agree that a lot of stuff still has to be worked out until we can start the implementation.

Just letting you know that I updated the Draft based on your feedback.
Further discussion is still required. Note that the statements made in the draft are mostly my thoughts and not final.

I have just added a draft of diagram corresponding to the current ideas gathered in the design document.
@Zelberor This is probably helpful for your monday presentation. Feel free to contact me for changes.

This issue seems to be completed for now and I would recommend closing it when the first implementation of the intermediate layer (including the draft) is merged.


added unittests

Hi Andres, I have not added documentation, i will add it and update the
pull the request.
-Rashmi
On Tue, Oct 24, 2017 at 9:45 AM, Andres Martinson<EMAIL_ADDRESS>wrote:

Is there documentation, examples how to use, or how to write additional
ones?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hubblestack/hubble/pull/235#issuecomment-339035925,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZ-Qu8cyaFD1b6MT1Qwqb5bvsO6RuIZoks5svgYFgaJpZM4QEi6w
.

@rashmip29 we should go over some git workflow stuff at some point -- PRs are actually pretty easy to add to without closing and opening a new one. Keeps all of the feedback in one place.


Investigate backend tests that relied on the old parser

Some backend tests that had not been switched to the new parser before #5917 don't pass with the new parser; these can be found by searching the codebase for references to this issue number (after that PR merges).
This is due to syntax cases that don't occur outside the tests in question, and that generally relate to type signatures and type declarations.
Each test either needs to be updated or needs a (generally simple) change in translation or the parser.

There seems to be 21 such tests right now:
enso$ grep -r 5894 engine/runtime/src/test/
engine/runtime/src/test/scala/org/enso/compiler/test/pass/desugar/LambdaShorthandToLambdaTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/desugar/FunctionBindingTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/desugar/ComplexTypeTest.scala:    // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/IgnoredBindingsTest.scala:    // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/ExpressionAnnotationsTest.scala:    // FIXME: New parser handles the syntax error differently--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SugaredTypeFunctionsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/TypeSignaturesTest.scala:    // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/TypeSignaturesTest.scala:    // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SuspendedArgumentsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/resolve/SuspendedArgumentsTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/AliasAnalysisTest.scala:    // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/DataflowAnalysisTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/DataflowAnalysisTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/DataflowAnalysisTest.scala:      // FIXME: Not supported by new parser--needs triage (#5894).
engine/runtime/src/test/scala/org/enso/compiler/test/pass/analyse/DataflowAnalysisTest.scala:      // FIXME: Different result in new parser!--needs triage (#5894).

CCing @hubertp


SUDS_subservice.py Is Not Working Correctly On Ubuntu

SUDS_subservice.py is supposed to loop every 60 seconds when run.
The script begins by pulling the JSON information from /api/, it however seems to be stuck when beginning to run the concurrent.Futures parallel action. Unsure if it is stuck on the ping subprocess or not.

While it is not ideal and I'd much rather use a switch, I created SUDS_subservice_LINUX.py
The issue was the subprocess was trying to use "ping -n 1 x.x.x.x" in Ubuntu. -n on windows is the equivalent to -c on Ubuntu. SUDS_subservice_LINUX.py is 99.9% equivalent to the SUDS_subservice.py file except a SINGLE character is changed in the code and that is n was changed to c.
SOLUTION: Linux users, please use SUDS_subservice_LINUX.py -- Windows users, use SUDS_subservice.py


BlueSocket EchoServer from README as a separate repository

It would be very convenient to have the BlueSocket EchoServer from the [README Complete Example](url
https://github.com/IBM-Swift/BlueSocket#complete-example) available as a separate repository.

I had to completely rewrite the “Package.swift” file’s content to get the<EMAIL_ADDRESS>necessary for > Swift 4. Here is my result. It works, but please assume, that I have no idea what I’m doing as I am pretty new to Swift:
// swift-tools-version:4.0

import PackageDescription

let package = Package(
	name: "EchoServer",
	dependencies: [
		.package(url: "https://github.com/IBM-Swift/BlueSocket.git", from: "1.0.44"),
	],
	targets: [
	.target(
		name: "EchoServer",
		dependencies: [
			"Socket"
		],
		path: "Sources"
		)
	]
)


Crypto Payment Gateway (Extension Request)

Add crypto payment gateway like coinbase / bitpay for crypto currency transactions

Is https://litepay.ch/ also good for you?

LitePay.CH is added 🎉


Hip 0019 rebased gtg

What this PR does / why we need it:
Special notes for your reviewer:
If applicable:

[ ] this PR contains user facing changes (the docs needed label should be applied if so)
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

I did this one wrong, didn't mean to include upstream commits

see #25 instead


review tool: reviewer not listed in drop-down for assignment

Describe the issue
This issue is exercising some corner cases:
draft-ietf-anima-constrained-voucher had been in LC and received reviews from several directorates. The document went back to the WG due to the feedback received. The WG chair has requested re-reviews of the updated I-D from directorate reviewers.
The genart directorate received three requests from the chair: an early review request, an updated early review request, and then a LC review request with a note to disregard the first two requests.
The issue is that the secretary cannot assign the original reviewer. Although datatracker shows that Russ submitted a review and is available to do reviews, it does not list him as a choice for assignment.
@rjsparks has attempted to manually assign the document to Russ.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

The assignment has been made.
The request was in an odd state - the document was not actually in IETF LC, and there were other early and LC requests that had been closed in various ways.
I think the only bug to chase here is the one that caused Russ to not be in the list of reviewers that could get an assignment. I suspect it's because he had an assignment for that document that was in a state (or the other request was in a state) that caused him to be incorrectly filtered away as "already assigned".


[1588] Indicate if locations changes will be published

If a course is running - ie it's on Find – then changes to the locations will go live immediately. We previously based this on the enrichment status.

 Button and success text when editing course locations based on wrong status


Bebop rangefinder: Add signal capture command

This PR belongs to PX4/DriverFramework#181and adds the capture command to the DF wrapper.

@eyeam3 did you see the build failure? Rebase on master?

Closing as stale.


Configure custom-file location in rational-config-path

This will cause emacs to write the `custom-set-variables' code to the
rational-config-path/custom.el file, and should fix #83

The config file also need to be loaded with load command.  And that before the first use of custom variables, so possible in the beginning of init.el or early-init.el.

Why does it need to be loaded? Using customize-set-variable does the job for setting values throughout the configuration. The customize-set-variables section in custom is written there assuming the user used the EZ Config UI to set the values. Since we didn't we don't need to actually load the file. Maybe I'm missing something though?

It definitely needs an additional load for the custom config file, Emacs doesn't load it automatically.

It definitely needs an additional load for the custom config file, Emacs doesn't load it automatically.

Then each call to customize-set-variable will set the value and then loading the custom.el file will set the exact same values again in the customize-set-variables form and slows down the start of Emacs. But loading the custom file does no harm.

The custom.el file could be pulled in very early to partially solve this. Due to the way custom work, the setting will not be applied until the relative module is required. However, this leaves us at a place where any of the custom values set in the Rational configuration would always override user configuration.

However, this leaves us at a place where any of the custom values set in the Rational configuration would always override user configuration.

Right. Although, this should be a minimal risk and would be problematic if the user decided to edit the custom-set-variables form or the custom-set-faces form rather than using other configuration forms in either config.el or early-config.el.
The custom.el only contains 2 blocks of code: these are the custom-set-variables form and the custom-set-faces form. Any font updates in either early-init.el or early-config.el would potentially be clobbered by loading custom.el later, which sort of means we would need to load this as the last thing in early-init.el or provide documentation on how to load it very early in the users early-config.el to avoid that situation... and that assumes they don't change things later on in their own configuration for one of the variables. Bottom line is: we just don't need to load it at all, especially since we are (I think) trying to be disciplined about using customize-set-variable for defcustom defined values. Writing these 2 forms to an alternate file can be considered part of the "no littering" philosophy. This file could even live in the rational-config-var-directory.
This file really is for someone who is using the Customization UI to configure Emacs. When using that UI, Emacs needs a way to persist the values so they are loaded the next time Emacs starts. We aren't doing that. We aren't even advocating a user of Rational Emacs should do that.
All that being said, This code could be in a users config.el and (in theory) would be reasonably valid: ( not tested )
;; load rational modules, their customize-set-variables will apply "defaults"
(require 'rational-defaults)
;; require other rational modules as they see fit.
;; tell emacs where the custom file is
(customize-set-variable 'custom-file (expand-file-name "custom.el" rational-config-var-directory))
;; make sure its on the load path
(add-to-list 'load-path rational-config-var-directory)
;; load it... this further assumes the *only* place a user will update customizable values will be
;; either in the  custom.el file itself or through the Customize UI, so this *must* be the last thing
;; that happens in the configuration.
(load "custom" t t)
;; config.el ends here

especially since we are (I think) trying to be disciplined about using customize-set-variable for defcustom defined values.
I agree.

We aren't doing that. We aren't even advocating a user of Rational Emacs should do that.
I don't think we are (or will be) telling users to not use the Customization UI either.  We cannot ignore the possibility that some user will use customize and if they do, the results should not be unexpected.

I believe you have the correct idea to document  the loading of custom.el should the user want to make use of values set through the UI. I don't believe we are targeting users who have no idea how to add their own elisp configuration (the Principles state we are even encouraging it) , especially with an example of what to do.

I added some docs as requested, however, the PR does not appear to be updated...

Thank you for the contribution!


Wires: Need cable management

The cables have extensions but they now get caught in the extension when it comes down.

Related https://github.com/Techalongs/bobba/issues/10


E2E Tests do not use Calico CNI

Now that Provider Network Polices(#833) have merged, the Provider applies Network Policies to each tenant namespace. Breaking changes to this code could make the tenants' workloads inaccessible.
Integration testing should match the Provider's production environment as much as possible; this means running the KinD environment with the Calico CNI plugin enabled to enact the Network Policies; then the assertion of accessible workload will validate expected functionality.
Applying the _run/kind-config-calico.yaml config file to the<EMAIL_ADDRESS>GH plugin, but failed to provision KinD correctly to run containers. The metrics-server never came online, so the test hung forever waiting, it's a difficult issue to debug, so using Calico was punted.
Action Items

[ ] Investigate running KinD with Calico CNI in GH actions further. There might be other GH plugins to use which accommodate Calico better.
[ ] Update k8s-integration workflow to use Calico CNI in KinD env.

@troian thoughts on this? Does it add any value at this time? I don't think we're trying to validate kubernetes with the E2E test. Just that the provider isn't busted.

we run E2E tests on kubernetes instance by kind. i remember some work was done on this but not sure for now


FIX: Datetime call in gdf 2.x age calculation

Reference issue
WIth regards to  #7124 .
What does this implement/fix?
While importing a GDF 2.x file with
from mne import io
io.read_raw_gdf(fname, preload=True)

we encountered the following error:
Extracting EDF parameters from /home/svea/Desktop/mne_examples/sample_data/B0103T.gdf...
GDF file detected
Traceback (most recent call last):
  File "/home/svea/Desktop/mne_examples/online_linear_demo.py", line 17, in <module>
    raw = io.read_raw_gdf(raw_fname, preload=True)
  File "/home/svea/Desktop/mne_examples/venv/lib/python3.7/site-packages/mne/io/edf/edf.py", line 1327, in read_raw_gdf
    verbose=verbose)
  File "<decorator-gen-164>", line 21, in __init__
  File "/home/svea/Desktop/mne_examples/venv/lib/python3.7/site-packages/mne/io/edf/edf.py", line 189, in __init__
    exclude, preload)
  File "/home/svea/Desktop/mne_examples/venv/lib/python3.7/site-packages/mne/io/edf/edf.py", line 377, in _get_info
    edf_info, orig_units = _read_header(fname, exclude)
  File "/home/svea/Desktop/mne_examples/venv/lib/python3.7/site-packages/mne/io/edf/edf.py", line 366, in _read_header
    return _read_gdf_header(fname, exclude), None
  File "/home/svea/Desktop/mne_examples/venv/lib/python3.7/site-packages/mne/io/edf/edf.py", line 865, in _read_gdf_header
    today = datetime.today(tzinfo=timezone.utc)
TypeError: today() takes no keyword arguments

After closer investigation, we suspect that it was caused by the changes introduced by #7124 and released in v0.20.0.
As stated in the Python docs for datetime,
datetime.now(tz=timezone.utc) should be the syntactically correct functional equivalent.
To then make today and patient['birthday'] comparable, we add tzinfo to birthday (in line 860).

#7582 duplicate?

Indeed, @SveaMeyer13 can you see if #7582 also works? I slightly prefer that one since it includes a test

@SveaMeyer13 actually, instead can you update latest.inc with an update about the bugfix (you can take the wording from my PR if you want -- plus change to your name and add yourself to names.inc if not there already) and we can merge this, then I can rebase my PR to get the test in

Done!

Thanks @SveaMeyer13 !


Bump the github actions

I could bump the tag of our forkliftci, but i don't know if it's really necessary

/test-osp-extended

/test-osp-extended


RSDK-8525: New answerer workers adding to a waitgroup must atomicly perform their closeCtx read and wg.Add call.

I'm going to merge this and star the PR on RDK. Can abort that PR if there's some risk we haven't identified yet


Change Book a Call CTAs to "Request a Callback"

All CTAs in which we have "Book a Call", we change that to "Request a Callback".

Duplicate of #128


Using deploy.sh does not create all the resources in the proper namespace

We are using  the script deploy.sh, it creates a file named resources.yaml on which you can find the channel and subscription.
Once you kubectl apply -f resources.yaml (after applying customize) it creates the channel, the subscription, the policies but somehow it does not create the policybindings and the placementrules.
The script deletes the resources.yaml and after running  again the script avoiding the kubectl kustomize command and the deletion of the file.
Manually the command brings the same results.

The deploy.sh script should only create a Subscription and Channel and then GitOps pulls in the Policies, PlacementRules, and PlacementBindings, so it sounds like there might be an issue on the RHACM cluster itself. Does that sound right based on what you're seeing? Is there a status in the Subscription that was created that indicates an issue?

@steinrh we found some policies in not correct namespace and already sent a PR. Please note that there are a few policies where we assigned some example namespaces which need to be customized before using them this is also the idea behind:

fork repo
review policies you need and disable, remove others
modify policies to you need
set Subscription-Admin in 2.4 (it's documented in latest PR)
apply policies via script

To view the subscription resource, run a command like: oc get subscription -n governance grc-sub -o yaml
If there's a problem with some resources being deployed, the status information in the output of your command similar to
the one above should help point us in the right direction.  I'm going to close this for now, but please re-open if you're still
having issues.


Ben temp

Left some comments where I was testing some Regex for helping with sentence edge cases. Not using it for now bc not critical for validation of current functionality, but left in as reminder/to play with later. Let me know your thoughts on this; it also muddies the code so I don't mind taking it out. (It's pushed now anyway so I can always recover it later).
New CSS types "markedOne", "markedTwo", "markedThree". Currently have it set to "markedThree", just bc I prefer it of the three, but we should discuss about which to test with (I'm open to all). markedThree has a MAJOR flaw: the box-shadow that makes it cool also "bleeds through" the tags in the code. With that said, I still prefer it bc I think it accentuates the lines a lot. Let me know what you think. markedOne is normal, markedTwo is lighter blue background.

Oof sorry you had to merge a couple of times before getting in your changes.
Hopefully as we separate out more files (e.g. you can experiment on regex + tracker.js and I touch other files), these will become less frequent.

No no worries at all, they were small changes! But the modularity with the
tracker.js is awesome and I agree will be beneficial in the future!
On Mon, Jul 6, 2020 at 4:39 PM Stephen Joe Jonany<EMAIL_ADDRESS>wrote:

Oof sorry you had to merge a couple of times before getting in your
changes.
Hopefully as we separate out more files (e.g. you can experiment on regex

tracker.js and I touch other files), these will become less frequent.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/benfrancis314/reading_project/pull/21#issuecomment-654479224,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALJ42WGBYSMS42YINOJCE3LR2JACZANCNFSM4OR6YJXQ
.

Hmm, not sure if intentional, but the pr w/ comments ended up not being merged.
and instead a new pr w/ same commits, but no comment reviews was the one that was pushed:
https://github.com/benfrancis314/reading_project/pull/22
Was there a problem in the commit - push flow? If so, I can improve the dev documentation
.

Aghh no not intentional, dev documentation is spectacular I just forgot and accidentally went AWOL (which is bad for the master's integrity). CORRECT course of action would have been to make changes based on comments, push again to temp branch, resolve addressed conversations, wait for reviewer responses, IF LGTM, then squash+merge. [I repeat those steps mostly for myself, but also to make sure I have properly received the dev guide's intent.) Purely my bad/unforced error, thank you for catching this.
I'll roll back master to make sure everything added in has got the LGTM stamp + good practice at doing so.

No worries, and what you described sounds good to me.
Eh, no worries about rollbacking, if it's just a one off thing.

My bad I didn't see this message until already rolled master back ... I'm just going to close this pull request bc it is a little hectic and create a new cr


[camera] Expand CameraImage DTO with properties for lens aperture, exposure time and ISO.

This PR adds additional properties to the CameraImage DTO:

lensAperture
sensorExposureTime
sensorSensitivity

Relevant issue:

flutter/flutter#73250

This PR adds no breaking changes.
As this PR depends on changes made by the Android refactor (#4059), this PR will remain in draft state until those changes have been merged.
Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [relevant style guides] and ran [the auto-formatter]. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the [CLA].
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[x] I updated CHANGELOG.md to add a description of the change.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
[x] All existing and new tests are passing.

@googlebot I consent.

Closing in favour of #4256.

Hi,
I'm working with version 0.9.4 and the properties lensAperture, sensorExposureTime and sensorSensitivity are no more available in the CameraImage DTO.
I'm using them in the following way:
_initializeControllerFuture = _controller.initialize().then((_) async {
        await _controller.startImageStream((image) {
          if (mounted) {
            setState(() {
                 _lensAperture = image.lensAperture ?? 0;
                 _sensorExposureTime = image.sensorExposureTime?.toDouble() ?? 0;
                 _sensorSensitivity = image.sensorSensitivity ?? 0;
            });
        }
    });
});

...

@override
  Widget build(BuildContext context) {
    return Column(
      children: [
        FutureBuilder<void>(
          future: _initializeControllerFuture,

...

I also tried to lock the version of the plugin to 0.9.1 or 0.9.2 but it didn't worked.
Any suggestion?

Hello, I am using the camera plugin: ^0.9.4+14  for camera in flutter, but I want to explore more advance features of camera for IOS and android both. So please help me out for this.I am not able to use the [camera] ISO, Shutter Speed etc like features.


Change megabytes for bytes in withSharedMemorySize method documentation

This is just a simple fix for a method documentation.
In GenericContainer class, withSharedMemorySize method was accepting MB as an argument. This was changed to accept Bytes instead, but the documentation of the method was not fully changed. This PR is just doing this small doc fix.

@aidamanna this simple fix may save hours to someone! Thank a lot for spotting and fixing it 👍

Released in https://github.com/testcontainers/testcontainers-java/releases/tag/1.10.7!


Update iqualify-tutorial.md

Update to map email to user.mail

Learn Build status updates of commit f8f3a6b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/active-directory/saas-apps/iqualify-tutorial.md
:white_check_mark:Succeeded

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 learn.microsoft.com contributor guidesPost your question in the Learn support channel

@sam-iqfy, created a separate PR in our private repo.
#please-close


feat: replace old twitter logo with new one

Fixes #21
Changes

[x] swapped the white bird for an X

API Updates
null

looks perfect to me @peteruche21 - LGMT


Remote Wipe Not Possible

[Enter feedback here]
Step Three says to convert the mailbox to a Shared Mailbox. If the mailbox is converted in step 3 doing a remove wipe in step 5 is not possible.

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

ID: 34c90550-34c3-c6de-81d4-6d85a8bc3f90
Version Independent ID: 151fb754-7bea-f489-5115-e3551db0f303
Content: Step 5 - Wipe and block a former employee's mobile device - Microsoft 365 admin
Content Source: microsoft-365/admin/add-users/remove-former-employee-step-5.md
Service: o365-administration
GitHub Login: @KwekuA
Microsoft Alias: kwekua

@polks71 Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/7591
once the author approves, the changes will be live.
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @polks71 Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


fix: $ escaping in docs

Change Summary

Workaround for $ escaping issue in docs. Open issue in https://github.com/wevm/vocs/issues/164
Merge Checklist

[x] PR has a Changeset
[x] PR includes documentation if necessary
[x] PR updates the boilerplates if necessary

This may break when we fix this in Vocs, but I'll let you know when we fix! Will tag this PR.


Cert-manager currently faces difficulties renewing certificates within the EKS.

The certificate status for t7d-profile-staging in the t7d-staging namespace shows as False, indicating that the certificate issued by letsencrypt-production has expired.
It expired on Monday, 20th November 2023, at 09:40:03 UTC. Currently, it has been 28 minutes since the certificate expired. Upon checking the certificate request status using "kubectl describe certificaterequest" , it shows that the request is still pending, awaiting the issuance of the certificate from the order named t7d-profile-staging-mbr8x-4133884982 in the t7d-staging namespace.

Solution:
<EMAIL_ADDRESS>


Investigate install/setup

Can we create a setup.py?
Do we need to pin a version number for docopt?

Implemented with PR #26


aaaaa"; ls -la; dir #

@g4mm4 as far as I know this repo is immune to this sort of RCE. First of all, the GitHub Action is only executed if the issue starts with Chess: . Second (and most important), I don't directly feed the issue title to the script, but rather I feed it the issue number (so 637 in this case) through an environment variable. The script then uses that number and the repository name to retrieve the issue title, which will always be treated as a string.
Thank you for opening this issue, it made me reconsider the security of this repo :)

@g4mm4 I would also like to point out that publicly disclosing vulnerabilities and attack vectors on other people's repositories is never a good idea to say the least. Indeed my code was vulnerable to RCE and luckily I managed to patch it before anyone else discovered this. But if someone, looking at your attempt just tried to go one step further and managed to get and RCE working, they could have deleted EVERYTHING in this repository. Or even worse: someone could have leaked the GITHUB_TOKEN and published/accessed private repos or any other personal information available through my profile. You had no right to do this publicly. If you wanted to have fun or find bugs/vulnerabilities, you could have created a private repo from my README chess template, experiment for a while and after you find an RCE vulnerability email me so I could fix it PRIVATELY, not publicly.
I hope you reconsider your current behavior and stop trying to show the world which repos are vulnerable and how to exploit that. Once again, you have NO RIGHT to expose people to this level of danger. This is not a game. People's projects, privacy and personal data is on the line. You want to do this? Fine.
It's because of people like you that security policies are even a thing. Because people like you think that publicly disclosing critical vulnerabilities is a good idea and don't even consider doing research on private and then letting the maintainers know what's wrong with their code. It is never a good idea and I hope you reconsider your current actions.

Hi Marc,
Sorry for any inconvenience :). The payload is submitted automatically by
my bot
Congratz on your successful fix
cheers,
~g4mm4
On Wed, Aug 4, 2021 at 9:06 PM Marc @.***> wrote:

@g4mm4 https://github.com/g4mm4 I would also like to point out that
publicly disclosing vulnerabilities and attack vectors on other people's
repositories is never a good idea to say the least. Indeed my code was
vulnerable to RCE and luckily I managed to patch it before anyone else
discovered this. But if someone, looking at your attempt just tried to go
one step further and managed to get and RCE working, they could have
deleted EVERYTHING in this repository. Or even worse: someone could
have leaked the GITHUB_TOKEN and published/accessed private repos or any
other personal information available through my profile. You had no right
to do this publicly. If you wanted to have fun or find
bugs/vulnerabilities, you could have created a private repo from my
README chess template https://github.com/marcizhu/readme-chess,
experiment for a while and after you find an RCE vulnerability email me so
I could fix it PRIVATELY, not publicly.
I hope you reconsider your current behavior and stop trying to show the
world which repos are vulnerable and how to exploit that. Once again, you
have NO RIGHT to expose people to this level of danger. This is not a game.
People's projects, privacy and personal data is on the line. You want to do
this? Fine.
It's because of people like you that security policies
https://docs.github.com/es/code-security/getting-started/adding-a-security-policy-to-your-repository
are even a thing. Because people like you think that publicly disclosing
critical vulnerabilities is a good idea and don't even consider doing
research on private and then letting the maintainers know what's wrong with
their code. It is never a good idea and I hope you reconsider your current
actions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/marcizhu/marcizhu/issues/637#issuecomment-892688494,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIE3DGZICEOQUDHBEPOJRTT3FCOTANCNFSM5BQJXGQA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

In that case I would consider disabling such a bot for the reasons stated above. This is not something that should be automated and mass-tested on publicly-available repositories.


bug: show content button hide the Breadcrumb #1389

PR Fixes:

1 bug: show content button hide the Breadcrumb #1389

Resolves #[ #1389]  #[#1380]
Checklist before requesting a review

[yes ] I have performed a self-review of my code
[yes ] I assure there is no similar/duplicate pull request regarding same issue

@hkirat  @devsargam

Thank you sir


Inline issue action to go to query

Fixes #1622

This is really cool! The "Configure Queries" action for changing the pull request queries just opens the settings page with prefilled search text, this seems much better. I'll create an issue to match this behavior with that action

In very large settings files it will likely be slow, but since it's not an action I expect people to take very often it seemed worth it!


Update arbitrum links

Update arbitrum links and remove archive repo

If you want to farm commits at least don't do it from multiple accounts. #4122


[distributed] add SingletonLogger to avoid duplicate logging, with custom formatting options including file name: line_number

This PR:
1 - adds a new SingletonLogger to eliminate an issue that was popping up with duplicate logging.
Before:

After:

2 - This logger adds a couple useful formatting improvements:
a - option to not display the year in the timestamp to save space
b - avoid putting INFO / DEBUG for the level, again to save space (WARNING / ERROR / CRITICAL) are always shown
c - shows the calling filename and line number even though this is now a singleton setup
d - strips ".py" extension so that it's filename:line_number and not filename.py:line_number, again to save space.

What is the key line that makes the log singleton?

I see. Thanks. I can see this being useful in multi-thread scenario.
Still have to think how it helped in multi-process scenario.
But, nice work. (We will probably run in multi-thread mode later)


1.0.0 release

[ ] Change version and date in time2backup.sh
[ ] Change version in time2backup.example.conf
[ ] Create an archive of the project
[ ] Create a macOS app file

To create a macOS app file, use this: https://mathiasbynens.be/notes/shell-script-mac-apps


[Removal]:

Hotspot Name
Noisy Brunette Snail
Hotspot b58 Address
112Xerj3apQeqQrFuHcjkf4c6EzFJzUjM3K3w4taobWvopzKWBqR
Discord Handle
SkiddedUndiez
Hotspot Manufacturer
Sensecap M1
Removal Reason
I didn't do anything wrong. one Antenna was set up yesterday on my roof after being on stock antenna. Looks like a glitch on the network caused this.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
I setup my antenna yesterday.

I checked hotspotty I am not on the list apparently.


Fixed Disqus comments

Not sure when but at some point disqus has changed there universal comment code since you implemented comments. it's no longer
(function() {
            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body' [0]).appendChild(dsq);
})();

It has since been changed to
var disqus_config = function () {
      this.page.url = '{{ site.url }}{{ post.url }}';
      this.page.identifier = '{{ page.id }}';
      };
      (function() {
        var d = document,
        s = d.createElement('script');
        s.src = '//yoursiteshortname.disqus.com/embed.js';
        s.setAttribute('data-timestamp', +new Date());
        (d.head || d.body).appendChild(s);
      })();

Which means it did not work. I have added a disqus_site_shortname attribute inside the _config.yml so it can be supported. This was a roadblock I ran into when using this template and I hope this helps anyone else who goes to use this.
Also. . .
Thanks so much for the absolute amazing template! I've been building small web apps for almost six months now and it came to the point where my content needed a home. Thank you so much for providing a starting ground for that home :)

Thanks for contributing @NoahVlncrt \o/


Enable custom detailed PV layout models

Enables custom detailed PV layout models for both the detailed (pvsamv1) and simple (pvwattsv8) technology models.

@dguittet

should detailed_pv_layout.py and detailed_pv_config.py be developed more before merging into master?
or should they maybe be located somewhere else, like in /examples?

@Matthew-Boyd Apologies for the delay. Looking at this now. I don't think detailed_pv_layout.py and detailed_pv_config.py were intended to be merged into main HOPP since they're not complete. Do you think it makes sense to not include them in the main HOPP or would something be lacking? Examples could be a good idea!

@Matthew-Boyd Apologies for the delay. Looking at this now. I don't think detailed_pv_layout.py and detailed_pv_config.py were intended to be merged into main HOPP since they're not complete. Do you think it makes sense to not include them in the main HOPP or would something be lacking? Examples could be a good idea, but I think it would need to be more functional / complete.

@dguittet No worries, I got to catch up on other work. I'm content putting them into examples as-is now, and let Engie use this right away. Maybe they would offer comments or a PR during their testing and implementation? I'd rather not let the changes in this PR languish, however, so if you thought it best to develop those two files more, maybe we can still merge the rest? (I would have to remove the affected tests, though.)

@Matthew-Boyd Thanks I've moved the detailed layout files into the examples folder

@dguittet Good to merge?


Only import modules if needed

Some platforms such as Google App Engine blacklist ctypes modules.
See https://github.com/jd/tenacity/issues/116

Thanks!

I cut v1.5, which includes this change.

Thanks @atdt, you rock!


Which version of Waymo Tracking Dataset do you use?

1.0-1.4 which one?

1.2, but I think the lidar files we use are the same across versions.

Preferably 1.2, 1.0 can not generate right files for tracking according to my use of 1.0


Should untitled editor file name index also check opened editor

Issue Type: Bug

If user saves untitled sql/notebook file as default for example: SqlQuery_1/Notebook-0
Then the file name has the extension in the tab. If create untitled Sql/notebook file, it will has the same file name. Check the above screenshot.
Problem:
It is a little bit confusing with two files with exact same name opened. Also could cause overwritten the saved file if user doesn't rename it.
When we check the file name, could we also check opened editor to find the index?
Azure Data Studio version: azuredatastudio 1.6.0 (9ca6200018fc206d67a47229f991901a8a453781, 2017-12-15T12:00:00.000Z)
OS version: Windows_NT x64 6.3.9600

System Info

Item
Value

CPUs
Intel(R) Xeon(R) CPU E5-2695 v2 @ 2.40GHz (48 x 2394)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_offsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
255.93GB (137.94GB free)

Process Argv
.

Screen Reader
no

VM
0%

Extensions (1)

Extension
Author (truncated)
Version

sql-vnext
Mic
0.12.1

I don't think it is feasible to check the open files when determining the name of new unsaved files, and i don't overwrite would happen. to me this is not an actual issue. @yualan  please triage.


ZIP 320 Implementation

Goal
The purpose of this tracking issue is to manage the efficient implementation of 320.
Objectives:

Converge LRZ and zingolib to the best distance for rapid implementation of 320
Provide functionality to unblock mobile developers allowing them to test UI/UX and Front End Test (FET) for 320 ASAP
Implement and test 320

Subtasks

[ ] manage all dependencies such that 1. is rapidly achievable
[ ] ensure that CI functions across cargo updates

[ ] https://github.com/zingolabs/zingolib/pull/1368

[ ]  produce a test showing parse recognizes address types, including TEX
[ ] produce a test showing multi-step transaction created when TEX is parsed

Currently tagged PRs:
https://github.com/zingolabs/zingolib/pulls?q=is%3Apr+is%3Aopen+label%3A320

Some things I’ve seen in other wallets that must be taken into consideration:

don’t show memos on Tex
account for 2x fees
prepare to receive 2 transactions as a result
librustzcash uses the proposal API (I think you already do)
resubmit both tx on expiry (Zashi does this)


findClipTo/FromPlayerProps missing

It makes it really annoying to find stuff owned by a specific player in a single query, such as "find all e2 and egp emitters by owner", one has to add all other players to the blacklist, i could not find other ways that work.
        findIncludeClass("gmod_wire_egp_emitter")
        findIncludeClass("gmod_wire_expression2")
        foreach(N,P:entity=players()){
            if(P!=owner()){findExcludePlayerProps(P)}
        }
        findInSphere(vec(),100000)

findByOwner(Entity) and findAllEntities() would be nice to have as well.

Indeed getAllEntities(), not findAllEntities(). You don't find all, you get all.
Side note: findInBox/findInSphere and such functions has a limit of 512/1024 entities (by engine). So, you don't get them "all", if there's too many of them.
This, I will implement later a bit :)

findAllEntities() would be pretty pointless for E2 since there's going to be thousands of entities on the map at pretty much all times (even when there's not a single prop on the map, there's still hundreds of entities). E2s aren't powerful enough to loop through that entire table in a single tick, so you'd need to spread it out over multiple ticks, which is, relatively speaking, a lot of work. It's much easier to filter down the results in Lua.

findAllEntities would be useful together with the find white/blacklist and filtering, so the e2 would only get what it needs. It would be the equivalent of findInSphere(vec(),100000), without the limits.
And what is bad about giving the e2 all the entities? If the player explicitly requests it he probably understands the consequences.
You wouldn't don't block while(1) just because it might cause tick qouta if the player is unaware.
Anyway the find quota is a good change, was not aware of that.
But it only works if you have just a few things you are looking for. If you want more the number of finds scales with it. With a working clipTo/FromPlayerProps one could have lua do the filtering (which ironically you suggested in response to the findAll).
However the root problem here is that the whitelist is OR, findIn/findBy adds a AND, and you can add further ANDs with ClipTo/From. And the PlayerProps filter is only availible in the whitelist, and as such cannot be added as AND. findByOwner would add one way to AND, with ClipTo/FromPlayerProps the other. Currently there is no way (apart from inverse blacklist).

findAllEntities would be useful together with the find white/blacklist and filtering, so the e2 would only get what it needs. And what is bad about giving the e2 all the entities? If the player explicitly requests it he probably understands the consequences.

I meant it would not be useful because of the sheer number of entities. Like you said, it would only be useful if you filtered it down first.


Add a new semodule back end that forks out to policycoreutils to avoid memory leaks

During stress-testing of SPO it was found that selinuxd leaks memory. It
appears that the leak is coming from libsemanage (confirmed with
valgrind and fixed upstream). Using the policycoreutils back end,
testing on OpenShift 4.x, the selinuxd containers spike at around ~400MB
before falling back to ~30-50 MB. With the semanage back end, the memory
would climb steadily until it would hit the 1GB limit imposed by SPO's
DS definition and be OOMKilled.
To work around that, this PR adds a new back-end for the semodule
package that shells out to the policycoreutils utilities. This back end
is the default on "RHEL-like" distributions, but otherwise selectable
during build using the SEMODULE_BACKEND environment variable that
translates into a build tag.
The "Handler" interface was moved from semodule top-level to
semodule/seiface to avoid circular dependencies.

Local e2e tests with vagrant succeeded, submitting to make sure we pass CI. But please don't merge this yet even if the PR passes because:

The SPO policies must be updated first
I'd like to make sure the policy updates are minimal and the selinux policy additions in the capabilities are giving me the creeps.

Local e2e tests with vagrant succeeded, submitting to make sure we pass CI. But please don't merge this yet even if the PR passes because:
1. The SPO policies must be updated first

OK, this apparently does not need to be done.

Great, CI passes, so this is a 'known good' state. I'll try trimming the policy a little bit to see if there are any excessive syscalls allowed and remove the DNM tag when I'm done.

OK, I removed all syscalls that seemed spurious from the seccomp profile, including keyctl, mount, pivor_root and unshare. The ones that are added seem harmless (fchown is an exception to this but it seems to be required by the policycoreutils back end and setuid seems to be required by the container engine..)

OK, I removed all syscalls that seemed spurious from the seccomp profile, including keyctl, mount, pivor_root and unshare. The ones that are added seem harmless (fchown is an exception to this but it seems to be required by the policycoreutils back end and setuid seems to be required by the container engine..)

How did you verify that this was fine? A lot of these were generated via the SPO, so they might have been needed by crun/runc at the time. Would be good to add an SPO e2e test here so we verify we're not breaking anything there.

OK, I removed all syscalls that seemed spurious from the seccomp profile, including keyctl, mount, pivor_root and unshare. The ones that are added seem harmless (fchown is an exception to this but it seems to be required by the policycoreutils back end and setuid seems to be required by the container engine..)

How did you verify that this was fine? A lot of these were generated via the SPO, so they might have been needed by crun/runc at the time. Would be good to add an SPO e2e test here so we verify we're not breaking anything there.

I ran the e2e tests on an OCP cluster. Given that we don't have an OCP e2e test in the SPO suite, are you suggesting we add a CentOS/AlmaLinux/whatever based e2e test for SPO like we do for Fedora?

OK, I removed all syscalls that seemed spurious from the seccomp profile, including keyctl, mount, pivor_root and unshare. The ones that are added seem harmless (fchown is an exception to this but it seems to be required by the policycoreutils back end and setuid seems to be required by the container engine..)

How did you verify that this was fine? A lot of these were generated via the SPO, so they might have been needed by crun/runc at the time. Would be good to add an SPO e2e test here so we verify we're not breaking anything there.

I ran the e2e tests on an OCP cluster. Given that we don't have an OCP e2e test in the SPO suite, are you suggesting we add a CentOS/AlmaLinux/whatever based e2e test for SPO like we do for Fedora?

I was actually suggesting to add a test that runs the SPO on this repo. Note that I do think we should have an AlmaLinux test in the SPO repo too.

e2e test failed because of gofmt. Will fix later today.

Are the tests taking longer now? This sounds like a regression 😕

Are the tests taking longer now? This sounds like a regression confused

Yes, the policycoreutils back end is slower somewhat. But that's not surprising, is it.


Embeddable example008

Codecov Report

Merging #220 (4d77ef0) into main (78ea0c2) will decrease coverage by 0.1%.
The diff coverage is 100.0%.

@@            Coverage Diff            @@
##             main     #220     +/-   ##
=========================================
- Coverage   100.0%   100.0%   -0.0%
=========================================
  Files          43       43
  Lines        3231     3233      +2
=========================================
+ Hits         3231     3232      +1
- Misses          0        1      +1

Impacted Files
Coverage Δ

examples/example013a_embeddable_agm.cpp
100.0% <ø> (ø)

examples/example008_bernoulli_tgamma.cpp
98.6% <100.0%> (-1.4%)
:arrow_down:

math/wide_decimal/decwide_t.h
100.0% <100.0%> (ø)

test/test.cpp
100.0% <100.0%> (ø)

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 78ea0c2...4d77ef0. Read the comment docs.


Type checker does not require returning

It is currently valid to simply do
let isNone = [maybeStr: maybe[str]] -> bool {
  let output = if let <yes _> = maybeStr {
    true
  } else {
    false
  }
}

print(isNone(none))

(I haven't tested this)
The above snippet I believe causes a nasty runtime error because the function returns Python's None.

Should this cause a Syntax Error or a Compile Time Error?

Should this cause a Syntax Error or a Compile Time Error?

Compile time since the return statements could be inside if statements, for example


Riscv stable CI

Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝

[x] I have updated existing examples or added new ones (if applicable).
[ ] My changes were added to the CHANGELOG.md in the proper section.

Extra:

[x] I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖
Description
Exploring whether this is possible, this seems to work locally but lets try it in a CI run. Builds on top of #1485 as this removes the nightly features from the examples.

So it's possible, but what are the complications if we do?

Could you rebase this when you get a chance, please?

Hmm, this got a bit harder now we have the 802154 driver in tree, I guess I need to figure out what we can do with c_variadic


Fix graceful shutdown convention

What this PR does / why we need it
It fixes the graceful shutdown convention:

Enable graceful shutdown using the correct property.
Configure grace period using the correct property.

Fixes gh-294

Codecov Report

Merging #295 (f9d9b83) into main (41c2085) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #295   +/-   ##
=======================================
  Coverage   69.88%   69.88%
=======================================
  Files          17       17
  Lines         943      943
=======================================
  Hits          659      659
  Misses        263      263
  Partials       21       21

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

Closing since no activity in the last 5 months, @ThomasVitale let us know if you want to rebase and resubmit the MR. Thank you!


Integrate HTML Version of Left Navigation into API server

We would like to improve the look of our admin tools. Please integrate the attached HTML into all API server template pages. Do not remove the "Jump to" horizontal links yet:

Please note that these navigation items should always hug the left of the screen.

This was implemented by @jarodpeachey in this issue:
https://github.com/wevote/WeVoteServer/issues/1502
HTML.side.nav.zip

All those templates will need to changed.

All those templates will need to changed.

That is looking great @SailingSteve! Quick comment:
I don't know you have used Django templates, but this pattern would lend itself to adding this navigation to each page. A template like this one:
/WeVoteServer/templates/candidate/candidate_merge_one_field_decision.html
...can be included in another template:
/WeVoteServer/templates/candidate/candidate_merge.html
You can then pass in variables like with field_name="candidate_name" to control state information like the at-state for indicating which navigation item (i.e. "Admin Tools") should be highlighted.

That is looking great @SailingSteve! Quick comment:
I don't know you have used Django templates, but this pattern would lend itself to adding this navigation to each page. A template like this one:
/WeVoteServer/templates/candidate/candidate_merge_one_field_decision.html
...can be included in another template:
/WeVoteServer/templates/candidate/candidate_merge.html
You can then pass in variables like with field_name="candidate_name" to control state information like the at-state for indicating which navigation item (i.e. "Admin Tools") should be highlighted.

There were three left navigation buttons that were needed (to replace all the links that were in place), so I added them without icons.
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/Home.svg'
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/Elected Offices.svg'
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/VoterGuidePossibilities.svg'

There were three left navigation buttons that were needed (to replace all the links that were in place), so I added them without icons.
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/Home.svg'
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/Elected Offices.svg'
[Errno 2] No such file or directory: '/Users/stevepodell/PycharmProjects/WeVoteServer/apis_v1/static/apis_v1/VoterGuidePossibilities.svg'

Re templates:  Yes that was the way I did it.  It replaced the 15ish blocks of code, that mostly were the same (hard to maintain 15 copied blocks of code).

Re templates:  Yes that was the way I did it.  It replaced the 15ish blocks of code, that mostly were the same (hard to maintain 15 copied blocks of code).

Looks great!!


[iOS] Label not showing

i have a SlidePopupView implemented through the IMenuContainerPage interface.
On Android it works as expected, on iOS all controls are displayed (buttons, entries, etc.) excepting labels.
Any ideas?

i have a SlidePopupView implemented through the IMenuContainerPage interface.
On Android it works as expected, on iOS all controls are displayed (buttons, entries, etc.) excepting labels.
Any ideas?

i have the same problem, everything works fine on android, but on IOS i can only open the menu by swiping it, click to open dsnt work.
Can any1 help?


autosomal recessive cutis laxa type 2, classic type parentage

autosomal recessive cutis laxa type 2, classic type (MONDO:0009054)
(3 causal genes)
is classed as
autosomal recessive cutis laxa type 2A (MONDO:0018163)
this seems incorrect, since MONDO:0018163 is more specific  (for ATP6V0A2  only)
Maybe a sanity. check for the number of associated genes would help identify these?
@cmungall

Thanks @ValWood!
This is based on the orphanet classification: https://www.ebi.ac.uk/ols/ontologies/ordo/terms?iri=http%3A%2F%2Fwww.orpha.net%2FORDO%2FOrphanet_357058&viewMode=All&siblings=false
We added the superclass axiom to 'autosomal recessive cutis laxa type 2A'
'disease has basis in dysfunction of' some ATP6V0A2


Improve assembly output

Right now it is really hard to figure out which part of the assembly correspond to which parts of a rust program source code. Comparing this to godbolt:

playpen: https://play.rust-lang.org/?gist=6114dfcafa455d76d0cb&version=nightly
godbolt:  http://goo.gl/5ptaaZ

Shows that there is a huge room for improvement.
In particular, displaying assembly and code side by side, and coloring the code to match the assembly that corresponds to it, is extremely useful in particular with optimizations enabled.
A similar thing should probably also be done for LLVM IR.

Playpen is not getting much attention and yet, once improved, it could be very helpful for debugging llvm.
Presently, llvm developers are not going to install rust just to look into more complex issues, especially on platforms other than x86_64.

When developing it is also typically hard to set up an editor/IDE to do this so at least being able to use playpen for minimal examples (e.g. when reporting bugs) or for trying out small snippets would be useful.