method_missing when testing "example_open" file

C:/Users/Administrator/robust_excel_ole/lib/robust_excel_ole/workbook.rb:928:in method_missing': (in OLE method Window
s': ) (WIN32OLERuntimeError)
OLE error code:8002000B in

HRESULT error code:0x80020009
Exception occurred.

Hello,
thank you for pointing out this error.
Could you please give more details, e.g. the full trace, and the Excel version and ruby version you are using.
I can't reproduce this error, i.e., it is working in my system.
Best regards,
Thomas

Dr. Thomas Raths
Körperpsychotherapie, Kreativtherapie, WATSU
Friedenstraße 38
97072 Würzburg
0175 - 90 81 668
www.erlebens-raum.de

Gesendet: Sonntag, 21. April 2019 um 12:04 Uhr
Von: "lsq"<EMAIL_ADDRESS>An: Thomas008/robust_excel_ole<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Betreff: [Thomas008/robust_excel_ole] method_missing when testing "example_open" file (#16)
C:/Users/Administrator/robust_excel_ole/lib/robust_excel_ole/workbook.rb:928:in method_missing': (in OLE method Window
s': ) (WIN32OLERuntimeError)
OLE error code:8002000B in
HRESULT error code:0x80020009
Exception occurred.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hello isq,
can you give a more detailed error report of the "method missing" error?
Best regards,
Thomas

Thanks Thomas, the error can't reproduce, it works now.

Hi,
I have another question to you. I saw on your github page, that you had considered RobustExcelOle as an Excel library.
Would you use it now, or what do you think makes RobustExcelOle unsuitable for Excel applications?
Best regards,
Thomas

Gesendet: Sonntag, 09. Juni 2019 um 05:27 Uhr
Von: "lsq"<EMAIL_ADDRESS>An: Thomas008/robust_excel_ole<EMAIL_ADDRESS>Cc: "Thomas R"<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Betreff: Re: [Thomas008/robust_excel_ole] method_missing when testing "example_open" file (#16)
Thanks Thomas, the error can't reproduce, it works now.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


TypeAdapter should have a nice repr

This is very poor <pydantic.type_adapter.TypeAdapter object at 0x1030ec2f0>.
it should show the type as prettily as we can.

@sydney-runkle, relates to https://github.com/pydantic/pydantic/pull/10537/files#r1837161007. Although we have our display_as_type function, might be good to check how Sphinx does it.

Working on this now.


user12986714: Watch chimeratool\W*+utility

user12986714 requests the watch of the watch_keyword chimeratool\W*+utility. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

chimeratool\W*+utility has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Daniil in Charcoal HQ


[WIP] Enable JIT tests in all models and add warnings if they are skipped

In relation to #3028
It's likely to fail for models:

googlenet
inceptionv3
maskrcnn

@fmassa Unfortunately the tests did not fail which means that the JIT scripts did not run. This can be confirm by checking any of the run logs for the following warnings:
test/test_models.py::ModelTester::test_alexnet_cpu
  /Users/distiller/project/test/common_utils.py:281: RuntimeWarning: The checkModule test for AlexNet was skipped. This test checks if the module's results in TorchScript match eager and that it can be exported. To run these tests make sure you set the environment variable PYTORCH_TEST_WITH_SLOW=1 and that the test is not manually skipped.
    warnings.warn(msg, RuntimeWarning)

Any ideas on how we can turn on the PYTORCH_TEST_WITH_SLOW env var at CI? Alternatively we can hardcode it here until this is fixed:
https://github.com/pytorch/vision/blob/b2c0b3dd1a6513c6184fcb42e09d283c3c49383d/test/common_utils.py#L34-L35

Thanks a lot for looking into this, we should get this fixed quickly.
I think we should try to switch the flag to always run the slow tests, and we should see if CI timeout or not.
If you want to set the env var for tests in CI only, you can add it in https://github.com/pytorch/vision/blob/a884cb7bcc03e57a969c1a572b7af85a95b4421c/.circleci/unittest/linux/scripts/run_test.sh#L8 and https://github.com/pytorch/vision/blob/a884cb7bcc03e57a969c1a572b7af85a95b4421c/.circleci/unittest/windows/scripts/run_test.sh#L8

It's likely to fail for models:
maskrcnn

Just note that we have a separate test checking detection models that they run on torchscript, so we should be safe there, see
https://github.com/pytorch/vision/blob/a884cb7bcc03e57a969c1a572b7af85a95b4421c/test/test_models.py#L213-L215


feat: offer standard logging module usage.

Added a new flag to allow using python's standard library logging module.
Default is False so that existing behavior of the library is unchanged.
When set to True and the other debug options are set to True, it outputs to logging with named loggers Mqtt and CB (to stay consistent to the print statements). This allows for more precise control over logging output/format/filtering using the standard python logging configuration.
README.md is also updated to reflect the new setting.

I updated the README and code to use USE_LOGGING instead of USE_LOGS because #namingthings ... USE_LOGGING is more consistent with the fact that we're using the logging module of python instead of print statements.


Fix withComponent() typing

Initial issue happens from #1315
WIP related PR #1201 #1283
Add test cases which are discussed in #1201
Excludes props are set from . attrs()

@styled-components/typers could we get a review here please? 😸

Can we get this one reviewed and merged ASAP?

@probablyup Thanks for your notice about migrating TS typings to DefinitelyTyped.
From what I understand that migration will be done by v4.0, does it mean that typings will be removed by v4.0 release?
I do not think it is a best practise/solution that we can not contribute and merge any typings related PR from now on. Then whoever want to migrate typings to DefinitelyTyped will have to recall all these un-merged/un-reviewed typings PR by himself.
I do not see the reason why we prevent any contribution on typings before the migration is finished.
Even though these changes will not be released by v4.0, but these are still valuable contribution to the codebase, and provide good reference to new migrated DefinitelyTyped too.

does it mean that typings will be removed by v4.0 release

Yup

I do not think it is a best practise/solution that we can not contribute and merge any typings related PR from now on

We're willing to take fixes that will fit in a minor release (e.g. no required upgrade of TS). Just looked over your PR again and it does seem to fit that criteria, so happy to reopen it. Will need a review from someone on @styled-components/typers though.

We're willing to take fixes that will fit in a minor release (e.g. no required upgrade of TS). Just looked over your PR again and it does seem to fit that criteria, so happy to reopen it. Will need a review from someone on @styled-components/typers though.
+1

@patrick91 @Igorbek Can anyone review this PR ?
Really hope someone can review and get it merged ASAP because we get blocked by this issue.

I will look at this later today. Sorry for delay, I just overlooked this PR.

@6r1anchen looks like there's a conflict from some PRs that were merged if you wouldn't mind fixing it up

Thanks @6r1anchen, @Igorbek whenever you have time to give this a look 🙇

ping @Igorbek for review round 2

Thank you for waiting me. As I said before, it is unlikely to have correct typings for withComponent, but at least it is a step forward. Thanks!

Thank you so much for helping us improve styled-components! Based on our Community Guidelines every person that has a PR of any kind merged is offered an invitation to the styled-components organization—that is you right now!
Should you accept, you'll get write access to the main repository. (and a fancy styled-components logo on your GitHub profile!) You'll be able to label and close issues, merge pull requests, create new branches, etc. We want you to help us out with those things, so don't be scared to do them! Make sure to read our contribution and community guidelines, which explains all of this in more detail. Of course, if you have any questions just let me know!


2024-11-12 submission

Hi @Shawn-Tsui , could you ensure your origin_date column is in 'Date' format:
✖ [col_types]: Column data types do not match hub schema.  origin_date should
be "Date" not "character".

Thank you for pointing that out! I will edit that

Hi @Shawn-Tsui, we encountered an error that the checks didn't catch when trying to render the report website. Could you change the 'output_type_id' column from character format to double?


Update apache-client, kinesis, sqs to 2.23.13

About this PR
📦 Updates

software.amazon.awssdk:apache-client
software.amazon.awssdk:kinesis
software.amazon.awssdk:sqs

from 2.23.12 to 2.23.13
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #813.


[helm/toolbox/upsert] fails if no tiller installed

what

If no tiller exists (e.g. helm reset), then install fails

why

Bad conditional logic

✓   (cpco-testing-admin) conf ⨠  make helm/toolbox/upsert
INFO: Perform attempt - 1
Error: could not find tiller
INFO: Helm version:  matches tiller version: .
INFO: Initializing helm client...

@osterman try now, please

Thx - will close for now and reopen if it happens again.


Remove filename argument to x86 asm_init.

@dot-asm, does this seem reasonable to you? We were running into issues on our end with the .file directive in the x86 files. As far as I can tell, it's entirely vestigial (x86_64 doesn't do it), but maybe you know of a reason for them that I'm missing.

The assembler already knows the actual path to the generated file and,
in other perlasm architectures, is left to manage debug symbols itself.
Notably, in OpenSSL 1.1.x's new build system, which allows a separate
build directory, converting .pl to .s as the scripts currently do result
in the wrong paths.
This also avoids inconsistencies from some of the files using $0 and
some passing in the filename.

Yes, makes sense.

maybe you know of a reason for them that I'm missing.

No, I don't, it's too old thing...
Anyway, I'd like to double-check on my computer (a bit later), and then I'll approve.

merged.


Weird login error

@marten @camallen this is the same issue that I mentioned in an email chain, just wanted to pop up here.
The gorongosa folks are having trouble logging in; they've sent this screenshot, which doesn't have any console information, but might be a starting point.

@aliburchard  looks like you forgot the screen shot?

@edpaget check slack - it had some personal details in it.

The login error was just non-intuitive I'm going to work on improving that page.


Azure Language copy via az cli

Describe the bug
While executing in az cli VS Code
curl.exe --request POST   --url 'https://aclu.cognitiveservices.azure.com//language/authoring/analyze-conversations/projects/TestCopy/:authorize-copy?api-version=2023-04-15-preview'   --header 'Content-Type: application/json'   --header 'Ocp-Apim-Subscription-Key: 230498wefuie81749378asdfoi23d69e9512'   --data '{"projectKind":"Conversation","allowOverwrite":false}'
The following error is obtained
{"error":{"code":"InvalidArgument","message":"Failed to parse the input.","details":[{"code":"InvalidArgument","message":"Unexpected character encountered while parsing value: C. Path 'projectKind', line 1, position 13.","target":"projectKind"},{"code":"InvalidArgument","message":"Unexpected character encountered while parsing value: C. Path 'projectKind', line 1, position 13.","target":"projectKind"}]}}
However as described in https://learn.microsoft.com/en-us/azure/ai-services/language-service/conversational-language-understanding/concepts/best-practices#copy-projects-across-language-resources
I am using the correct project type for CLU - analyze-conversations
Related command
curl.exe --request POST   --url 'https://aclu.cognitiveservices.azure.com//language/authoring/analyze-conversations/projects/TestCopy/:authorize-copy?api-version=2023-04-15-preview'   --header 'Content-Type: application/json'   --header 'Ocp-Apim-Subscription-Key: 230498wefuie81749378asdfoi23d69e9512'   --data '{"projectKind":"Conversation","allowOverwrite":false}'
Errors
{"error":{"code":"InvalidArgument","message":"Failed to parse the input.","details":[{"code":"InvalidArgument","message":"Unexpected character encountered while parsing value: C. Path 'projectKind', line 1, position 13.","target":"projectKind"},{"code":"InvalidArgument","message":"Unexpected character encountered while parsing value: C. Path 'projectKind', line 1, position 13.","target":"projectKind"}]}}
Issue script & Debug output
None available
Expected behavior
I expected to actually work, or provide a more precise indication of the error itself.
Environment Summary
azure-cli                         2.63.0
core                              2.63.0
telemetry                          1.1.0
Dependencies:
msal                              1.30.0
azure-mgmt-resource               23.1.1
Additional context
No response

Thank you for opening this issue, we will look into it.

Which CLI command is it related to?

I think this is more an azure language issue so will refer it to the proper team.


carla can generate anomalous data

i want to Detect the matching and authenticity of sensor data
• Input speed, acceleration, throttle, brake, GPS changes
• Detect anomalies such as
◦ GPS change when speed is 0
◦ Speed change when acceleration is 0
◦ Throttle and brake increase at the same time
can carla generate some data like this ?

You can set and get parameters, but it will not be 100% the same as real live ground-proof data.
The parameters  that are similar to the one you need are

get_acceleration
get_angular_velocity
get_location
get_transform
get_velocity

https://carla.readthedocs.io/en/latest/python_api/#carlaactor

thanks for your reply！
I am curious that can Carla generate some anomalous data based on specific guide or random way ?
I do not find this approach.

It would help if you explain what you want to do.
Carla is only a simulation, and if you want to generate data, you need to tell Carla what to do.
You can use ScenarioRunner to add vehicles that drive along the road with an openSCENARIO file.
Carla has a physic engine (Carla is an Unreal Engine project), and if you let the car drive, Carla will calculate how the vehicle moves, based on different variables.
If you want to have some random behavior, you could play around with the acceleration, steering angle, ...  to get different kinds of data.

1.) Carla gives the ground proof data of the Transform (location + rotation), and to have changes which are not the right Transform data, you would have to add a filter to add noise.
location_x = location.x + random_noice

2.) For throttle, brake, ..., you can use the VehicleControl
https://carla.readthedocs.io/en/0.9.15/python_api/#carla.VehicleControl
3.) you can use the generate_traffic.py and look how the Vehicles behave.
In the end, you have to look yourself if the data fits to your purpose.
You can look in the examples folder to get a base script for controlling Carla.


Next 13.3.x breaks edge-csrf

When using next 13.3.1 the token is not accessible in getServerSideProps from the response header. in 13.2.4 everything works fine.
See #7 for some context.

The documentation on edge API Routes states that

Note: Using Edge Runtime with getServerSideProps does not give you access to the response object. If you need access to res, you should use the Node.js runtime by setting runtime: 'nodejs'.

https://nextjs.org/docs/api-routes/edge-api-routes#differences-between-api-routes

This appears to be an issue with the dev server in Next.js 13.3.X: https://github.com/vercel/next.js/issues/48083
I posted a comment there as well. Hopefully someone from the dev team will respond soon to give us an update on the issue.

Hi @amorey
Great work with edge-csrf package.
I would like to know if you have a documentation on how to use this package with Next.js 13.2 using app directory. I went through the README and I noticed the doc was written for pages directory

@olawale-o Here's an example with the app/ directory (using Next.js 13.4):
https://github.com/amorey/edge-csrf/tree/main/example-ts-appdir
I don't have much experience using the app/ directory so let me know if you have any suggestions on how to improve the example.

H @amorey
It worked fine with (Next.js 13.4) however not with (Next.js 13.2). I had to upgrade my project for it to work. I have added an example to the example-ts-appdir on how I used it for my use case. Kindly take a look and review the PR

Yes, that's expected. example-ts-appdir specifies Next.js 13.4 in its package.json. It appears that the bug referred to in this issue is present in the pages/ directory, not the app/ directory. Thanks for your PR, I'll take a look and respond there.

Hi, I've also experienced this issue. As a workaround, I've been able to get the header like this
const csrfToken = res.req.headers["x-csrf-token"] as string;

instead of
const csrfToken = res.getHeader('X-CSRF-Token');

This also works:
export async function getServerSideProps(context) {
    const csrfToken = context.req.headers['x-csrf-token'] || 'missing';
    return { props: { csrfToken } };
}

I don't know if It has to do with but I keep getting Invalid CSRF Token even when it does attach a CSRF token

FYI I just tried edge-csrf with Next.js 13.5.X and it works! I also tried with Next.js 14.0.X and it's also working so it appears the middleware issue in the dev environment was fixed. I added a note to the README to highlight this issue:
https://github.com/amorey/edge-csrf/tree/next14


Support for TestPlan

As starting with Xcode11 Apple introduces TestPlans, XcodeGen still doesn't have support to generate project using Test Plans.

Hi @yonaskolb
Do you have any ETA when the support for the TestPlans will be introduced?

Test plans support has been added to XcodeProj in 7.2, so this can be started. I personally don't have time right now, but if someone wants to pick it up that would be great

Hello @yonaskolb! Any updates on supporting Test Plans for XcodeGen? Would love to take advantage of it.

Released in 2.29.0


Migrate all tooling components to latest LTS of node from node 8.x

As originally raised by @pahans, we need to migrate to NodeJs 10.x as 8.x is no longer supported.
https://blog.risingstack.com/update-nodejs-8-end-of-life-no-support/

No longer relevent


bugfix:标准运维节点重试设置can_operate参数

Codecov Report

Merging #186 (facc670) into v2.6.x_develop (88c41c9) will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           v2.6.x_develop     #186   +/-   ##
===============================================
  Coverage           29.33%   29.33%
===============================================
  Files                   3        3
  Lines                  75       75
===============================================
  Hits                   22       22
  Misses                 53       53

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 88c41c9...facc670. Read the comment docs.


Improve getValidatedFormData type inference

Description
Small update that should allow inferring the schema type from the resolver type when calling getValidatedFormData or validateFormData.
Partially fixes #55, though there's still an annoying upstream issue in @hookform/resolvers that causes zodResolver() to lack type inference as was called out in this comment (some other resolvers e.g. yupResolver should work fine)
Before:
const schema = z.object({ username: z.string(), password: z.string() });
const resolver = zodResolver(schema);

export const action = async ({ request }: ActionFunctionArgs) => {
  const data = await getValidatedFormData<z.infer<typeof schema>>(request, resolver);
  // ...
}

After:
const schema = z.object({ username: z.string(), password: z.string() });

// this annotation is still required for zod because of an upstream bug in @hookform/resolvers
const resolver: Resolver<z.infer<typeof schema>> = zodResolver(schema);

export const action = async ({ request }: ActionFunctionArgs) => {
  const data = await getValidatedFormData(request, resolver);
  // ...
}

Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the guidelines of this project
[x] I have performed a self-review of my own code

fwiw, I also pushed a PR to @hookform/resolvers that would allow full inference for zod resolvers when it's coupled with this one
const schema = z.object({ username: z.string(), password: z.string() });
const resolver = zodResolver(schema);

export const action = async ({ request }: ActionFunctionArgs) => {
  // data is appropriately typed here
  const data = await getValidatedFormData(request, resolver);
  // ...
}

@mintchkin thank you for this! So the generic is passed to the resolver and it should work as long as the upstream supports type inference?

@AlemTuzlak yeah exactly, the Resolver<> type in react-hook-form accepts a generic argument for the shape of the object it returns, so it's possible to go
const schema = z.object({ ... })                    // -> Schema<T>
const resolver = zodResolver(schema)                // -> Resolver<T>
const result = getValidatedFormData(req, resolver)  // -> Promise<T>

without losing any type information, as long as zodResolver() and getValidatedFormData() are good about forwarding the T generic along the chain. unfortunately they both drop it right now, but this PR fixes that for getValidatedFormData() and the upstream PR fixes it for zodResolver()

@mintchkin awesome, thank you for this!


Provisioner from previous Karpenter installation seems non-functional

Version

Karpenter Version: v0.22.1

Kubernetes Version: v1.24.0
Expected Behavior
After uninstalling the Karpenter helm release, I expected that a re-installation would allow everything to work again. No provisioners or nodes are removed before uninstalling the helm release.
The specific case I'm having trouble with is that the default provisioner with ttlSecondsAfterEmpty: 30 does not remove an empty node that only has DaemonSet pods (aws-node-xxxxx, csi-s3-xxxxx, ebs-csi-node-xxxxx, kube-proxy-xxxxx, nvidia-device-plugin-daemonset-xxxxx).
Actual Behavior
Despite having ttlSecondsAfterEmpty: 30 set, the node is never removed.
I removed the provisioner post-installation to have the owned node be removed and created it again with the same setting which going the TTL to work again.
I thought maybe I would need to try to get Karpenter to "re-initialize" the node so I removed the karpenter.sh/initialized label but it gets put back onto the node instantly.
I feel like I need to do something to link the nodes or provisioners to work with the new Karpenter installation but I haven't figure out what that is.
Steps to Reproduce the Problem

Follow the Getting Started instructions.
Ensure that an inflate pod is on the node (by scaling the deployment up from 0 to 1).
Run helm uninstall karpenter --namespace karpenter to remove the Helm release.
Reinstall Karpenter through the Helm chart again. In my case, I'm trying to go to v0.23.0.
Scale down the inflate deployment to 0.
Notice that the node now only has DaemonSet pods but doesn't get removed.

Resource Specs and Logs
I am using the default provisioner with the inflate deployment from the Getting Started guide.
https://karpenter.sh/preview/getting-started/getting-started-with-karpenter/
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

The reason I'm doing this is because I'm trying to avoid doing a Terraform import. I thought I could simply remove my manual installed Karpenter and replace it with a helm_release but I ended up encountering this issue instead.

Confirming: when you uninstall Karpenter, you are leaving behind the provisioner, so that when you install the newer version of Karpenter, the old provisioner still exists and the node still exists?

Hey @kenny-monster, what version of Karpenter are you upgradeing to, and can you share the karpenter logs?

@engedaam I've updated the description to mention that I'm trying to install v0.23.0. I'll try to share some logs soon but I don't recall anything noteworthy.

@kenny-monster Would you also be able to share your Provisioner and AWSNodeTemplate? I was not able to replicate this issue of upgrading from v0.22.1 -> v0.23.0, or any other later versions

@kenny-monster any updates?

Sorry for not following up on this. I don't have much intention to try to reproduce it for now so I'm going to close this.


Format of release tag changed between 0.17.1 and 0.18.0 releases

Compare adam-parent-2.11_0.18.0 to adam-parent_2.11-0.17.1, the dash and underscore traded places.
The artifactId is <artifactId>adam-parent_2.11</artifactId>, so I believe the earlier one is slightly more correct.

Reverting back to the old format SGTM.


Adding star count to slack channel

Signed-off-by: Lidor Ettinger<EMAIL_ADDRESS>
Description

This PR fixes #800
Notes to reviewers
Checklist

[] Signed commits.
[] PR title includes [<name of area>]:<description>

Well! Impressive. I can’t tell you how many times I trIes to do this and failed miserably.

Well! Impressive. I can’t tell you how many times I trIes to do this and failed miserably.

Yes, We tried so many things and it didn't worked.


Install fails

Expected Behavior
Following the instructions in CONTRIBUTING.md should lead to a successfull installation
Actual Behavior
npm test fails with missing packages
Steps to Reproduce the Problem

git clone https://github.com/jscad/OpenJSCAD.org.git
cd OpenJSCAD.org
npm install
npm test

Each time this is run, npm test fails due to missing packages. I had to gradually install all the following:
npm install @jscad/array-utils
npm install @jscad/modeling
npm install @jscad/io
npm install @jscad/core

Each time I installed one package, got a new missing package error, and installed the next one.
I am not a front-end web developer. I know some JS, but lack any knowledge about modern web development flow, so I have to follow the guidelines from CONTRIBUTING.md to the letter.
Specifications

Version: Release : 2022 MAR 03
Platform: Windows 10
Environment: Chrome (Version 98.0.4758.102 (Official Build) (64-bit)), Latest NodsJS LTS (16.14.0), npm 8.3.1

Following on:
C:\Sync\Sync\git\OpenJSCAD.org\packages\web>npm run dev

><EMAIL_ADDRESS>dev
> budo demo.js --port=8081 --css ./css/demo.css --live -- -b

[0001] info  Server running at http://<IP_ADDRESS>:8081/ (connect)
[0001] info  LiveReload running
Error: Can't walk dependency graph: Cannot find module '../../../examples/examples.json' from 'c:\Sync\Sync\git\OpenJSCAD.org\packages\web\src\ui\views'
    required by c:\Sync\Sync\git\OpenJSCAD.org\packages\web\src\ui\views\examples.js
    at c:\Sync\Sync\git\OpenJSCAD.org\packages\web\node_modules\browserify\node_modules\browser-resolve\node_modules\resolve\lib\async.js:55:21
    at load (c:\Sync\Sync\git\OpenJSCAD.org\packages\web\node_modules\browserify\node_modules\browser-resolve\node_modules\resolve\lib\async.js:69:43)
    at onex (c:\Sync\Sync\git\OpenJSCAD.org\packages\web\node_modules\browserify\node_modules\browser-resolve\node_modules\resolve\lib\async.js:92:31)
    at c:\Sync\Sync\git\OpenJSCAD.org\packages\web\node_modules\browserify\node_modules\browser-resolve\node_modules\resolve\lib\async.js:22:47
    at FSReqCallback.oncomplete (node:fs:198:21) {
  stream: [Labeled]
}

Windows? Please see #777

OK, going by the path of least resistance, I'm now cloning OpenJACSD.org on my WSL2 environment instead.

Thanks @udif
Let us know if there are any more problems.


Open Vault Record Page: Displayed Metadata

The following metadata fields should appear in this order on a record page if the metadata exists.
See style comps for design layout: https://atlas.wgbh.org/confluence/pages/viewpage.action?spaceKey=OV&title=OV+Styled+Comps+V.3&preview=/26553443/26553431/OpenVault_final comps_v39.jpg
As a header above the player/thumbnail:
[All titles concatenated from most general to most specific and separated by semi-colons]
Date
Below the player/thumbnail:
Series Title: [value hyperlinked]
Program Title: [value hyperlinked]
Open Vault Title:
Episode Title:
Episode Number:
Series Description: [with Series Date Release appended at the end of the description]
Program Description:
Creators: [Creator Name, Role]
Contributors: [Contributor Name, Role]
Publishers: [Publisher Name, Role]
Subjects: [values hyperlinked]
Location: [values hyperlinked]
Genres: [values hyperlinked]
Topics: [values hyperlinked]
Rights Information: [Rights Holder; Rights Credit]
**[values hyperlinked] should take the user to a search result for other records with that value.

@caseyedavis12 :

Between you and Mike, there's a clear notion of "Open Vault Title"? Do we actually mean something like "Item Title"?
There is no item level description?
The only date metadata we display is the series release date?

@mccalluc: Yes, the Open Vault Title is an item title for the well-cataloged records.
I am meeting with Mike at 11am to confirm the fields in the metadata and I will provide a crosswalk from PBCore to displayed field name. Your other two questions will be answered in that crosswalk.

@mccalluc: See #38 for information about PBCore fields and how each will be displayed.
I updated this ticket, which is primarily to recommend order of displayed fields, but now each field listed on this ticket is named according to the decisions made yesterday.
To answer your questions from yesterday, there is sometimes an item level description in pbcoreDescription descriptionType="Asset Description," which should be labeled as "Description"
There is only one date field: pbcoreAssetDate which should be displayed as Date.

@caseyedavis12 :

Publication Information: [Publisher Name, Role]
In the spreadsheet publisher doesn't have role. Please correct one or the other.

@mccalluc: Fixed on this issue. publisherRole is not in the XML.

@caseyedavis12 : Comparing this to what's currently implemented:

One of the mockups had the description above the player, so that's what I've done, rather than placing it in the longer list here.
Just realized that you've got all the last items as links:

Creator: [Creator Name, Role]
Contributor: [Contributor Name, Role]
Publication Information: [Publisher Name]
Rights Summary: [Rights Holder; Rights Credit]

Do you really want a link on Rights? What query would it do?
For the rest, what search should they do? My thinking right now would be to make a phrase search on all text fields. ie, given John Doe, scriptwriter clicking on the link would find any record with "John Doe" anywhere... put you might want a more precise search?

@mccalluc: The values of rights are controlled. One controlled value, for example, is Public Domain. I think it would be good to have those values linked so that a user can click on "Public Domain" and then see a search results for all items with that value.
For the rest, what search should they do? My thinking right now would be to make a phrase search on all text fields. ie, given John Doe, scriptwriter clicking on the link would find any record with "John Doe" anywhere... GOOD IDEA.

New bugs filed for the remaining items. Closing this.


feat: improve snapping to grid in selector middleware

Codecov Report
Attention: Patch coverage is 0% with 105 lines in your changes missing coverage. Please review.

Project coverage is 6.47%. Comparing base (ee87f3c) to head (9ea6699).
Report is 125 commits behind head on main.

Files
Patch %
Lines

packages/util/src/lib/flat.ts
0.00%
48 Missing and 24 partials :warning:

packages/board/src/lib/calculator.ts
0.00%
15 Missing and 4 partials :warning:

packages/core/src/middleware/selector/index.ts
0.00%
9 Missing and 4 partials :warning:

packages/idraw/src/idraw.ts
0.00%
0 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main    #327      +/-   ##
========================================
- Coverage   6.54%   6.47%   -0.08%
========================================
  Files        105     106       +1
  Lines       6743    6816      +73
  Branches    1315    1346      +31
========================================
  Hits         441     441
- Misses      5042    5084      +42
- Partials    1260    1291      +31

Flag
Coverage Δ

unittests
6.47% <0.00%> (-0.08%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


CCUBE-1264

Changes

Created the validation child entry component
Created unit tests to test the component
Added typings for validation
Added variable to hold validation types & validation to the element object generator

Additional information

You may refer to this CCUBE-1265
There may be a quite a few changes linked to it cause its branched out from CCUBE-1224

can close PR as the changes are being reviewed in 1265 PR


Update vcredist2019 to 14.22.27821

See https://chocolatey.org/packages/vcredist140/14.22.27821

Solved by #2672?

yup!


Cannot connect to http://magento2.docker/

I followed the guide till the end and started the docker. Here is the status for docker-compose ps
             Name                           Command               State                Ports
---------------------------------------------------------------------------------------------------------
dockermagento2master_appdata_1   /true                            Exit 0
dockermagento2master_cli_1       /usr/local/bin/docker-envi ...   Up
dockermagento2master_cron_1      /usr/local/bin/docker-envi ...   Up
dockermagento2master_db_1        docker-entrypoint.sh mysqld      Up       <IP_ADDRESS>:32784->3306/tcp
dockermagento2master_dbdata_1    /true                            Exit 0
dockermagento2master_fpm_1       /usr/local/bin/docker-envi ...   Up       <IP_ADDRESS>:32785->9000/tcp
dockermagento2master_varnish_1   /bin/sh -c /start.sh             Up       <IP_ADDRESS>:32783->80/tcp
dockermagento2master_web_1       /usr/local/bin/docker-envi ...   Up       443/tcp, <IP_ADDRESS>:32782->80/tcp

But in the browser I opened: http://magento2.docker/ just show me that the website cannot be reached.
I am using Mac OS Sierra!

The guide assumes that you are either using dinghy or you have added an entry to your /etc/hosts file to your Docker host (I believe this is <IP_ADDRESS> if you're using Docker for Mac.)

I figured out why it not work. A little bit change for docker-compose.yml file
 web:
    image: meanbee/magento2-nginx:1.9
    ports:
      - 80:80
    links:
      - fpm
      - db
    volumes_from:
      - appdata
    env_file:
      - ./global.env
    #environment:
      #- VIRTUAL_HOST=magento2.docker
      #- VIRTUAL_PORT=80
      #- HTTPS_METHOD=noredirect

Ah ok.  It doesn't look like you're using dinghy then.  I'm glad you've got it working.

I'm not using dinghy and tried with <IP_ADDRESS> and the nginx containers IP address in /etc/hosts to no avail. Do you still recommend using dinghy since Docker for Mac is available?

We still recommend Dinghy. We found docker for mac to be too slow to use in practice.

@julesbravo I have the same problem. Did you manage to solve it somehow?


Do not change crowbar templates during prepareinstallcrowbar

This is a hotfix solution for issue #1947
It fixes the overwrite problems described in the issue by moving the
problematic code blocks from step 'prepareinstallcrowbar' to
'bootstrapcrowbar', thereby delaying the change to the crowbar template
after it was updated in the 'runupdate' step.

thanks for the fix - I triggered a gating run

For a moment I was worried that this might break HA in cloud<7, because bootstrapcrowbar was only added for SOC7, but the if iscloudver is further down, so this even runs on older versions as long as standard aliases like plain are used.


Testing DevExpress VCL components

Hello,
We have software written in Delphi with DevExpress VCL components...
When I use winappdriver everything looks good except VCL components.
Can you help me?

Hi @jerry2007,
Can you provide more details into what issues you encounter? E.g.

What WinAppDriver command/API endpoint is failing?
Logs from WinAppDriver.exe command console
Capture of the target element in your application from inspect.exe

Closing for inactivity. Please reopen if the particular issue persists and more information are provided.


various fixes for 8ec8f75 encapp: Merge and fixes

8ec8f75 ("encapp: Merge and fixes") broke several tools (and the tests). Fixing some of them

Looks good.


Mmap experiments

abstract underlying storage into a trait
add required trait features on the T elements that are stored in the tree
implement backing store using Vec and Mmap
add from_byte_slice for efficient creation if the leafs already exist as a consecutive buffer

Warning: Very crude code.

Drawbacks

additional restrictions for T
currently not super efficient, but could be made so I believe
can not implement Deref when using mmap store, I don't think that is a critical feature though

@schomatis can you please make sure that CI is passing again?

@schomatis can you please make sure that CI is passing again?

@dignifiedquire again? when did it ever passed? see https://github.com/filecoin-project/merkle_light/issues/11 and https://github.com/filecoin-project/merkle_light/pull/10


[HTM-331] simplify push-pin svg and add toggle-button class

I expected this to solve the problem, but no...
the strange thing is that is is picking up the color from the .toggle-button--active rule.
resolves HTM-331

Codecov Report

Merging #79 (05afa1c) into main (32a9a9c) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 05afa1c differs from pull request most recent head 9a8f781. Consider uploading reports for the commit 9a8f781 to get more accurate results

@@           Coverage Diff           @@
##             main      #79   +/-   ##
=======================================
  Coverage   63.80%   63.80%
=======================================
  Files         115      115
  Lines        2387     2387
  Branches      372      372
=======================================
  Hits         1523     1523
  Misses        789      789
  Partials       75       75

Flag
Coverage Δ

unittests
63.80% <ø> (ø)

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

Impacted Files
Coverage Δ

...ked-coordinates/clicked-coordinates.component.html
100.00% <ø> (ø)

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 32a9a9c...9a8f781. Read the comment docs.


Add alternate spelling of Macao/Macau

Macau is used by Stripe
https://en.wikipedia.org/wiki/Macau

Awesome, though the names key is basically the junkdrawer of names, not official translations.
If this should be an official translation that we are getting wrong you can add a correction here https://github.com/hexorx/countries/blob/master/lib/data/translation_corrections.yaml

It seems like Macau can also be called Macao based on what I'm reading about it, so I don't know if we should consider it as an official translation. I.e., some services may use the Macao spelling. In that case, should that still be added to the translations?


Uncaught Exception thrown from connection pool if filter string invalid

Node.js v0.12.2
ldapjs v0.7.1
I may have missed something simple here but I've read through the API and tried a number of things.
  That particular cause is fixed at our end now, but the problem was that it threw an exception at the time the filter was parsed asynchronously in the connection pool, and that went uncaught:
/home/random/dev/adfoo/node_modules/ldapjs/lib/filters/index.js:206
      throw new Error(expr + ' is invalid');
            ^
Error: cn= is invalid
    at _buildFilterTree (/home/random/dev/adfoo/node_modules/ldapjs/lib/filters/index.js:206:13)
    at _buildFilterTree (/home/random/dev/adfoo/node_modules/ldapjs/lib/filters/index.js:164:28)
    at _parseString (/home/random/dev/adfoo/node_modules/ldapjs/lib/filters/index.js:417:17)
    at Object.module.exports.parseString (/home/random/dev/adfoo/node_modules/ldapjs/lib/filters/index.js:547:12)
    at Client.search (/home/random/dev/adfoo/node_modules/ldapjs/lib/client/client.js:640:30)
    at onAcquire (/home/random/dev/adfoo/node_modules/ldapjs/lib/client/pool.js:209:19)
    at f (/home/random/dev/adfoo/node_modules/ldapjs/node_modules/pooling/node_modules/once/once.js:16:25)
    at onCreatedClient (/home/random/dev/adfoo/node_modules/ldapjs/node_modules/pooling/lib/pool.js:268:17)
    at createCallback (/home/random/dev/adfoo/node_modules/ldapjs/node_modules/pooling/lib/pool.js:439:17)
    at bindCallback (/home/random/dev/adfoo/node_modules/ldapjs/lib/client/pool.js:71:18)

So the general problem is that user-sourced parameter errors are fatal.
I haven't tried this yet, but as a workaround I guess we could pre-validate it with parseFilter(), although that would mean parsing it twice in all, and the question remains what other errors may not be thrown until then.

Pre-validation wouldn't be a bad idea if you're allowing users to influence the contents of the filter.  The API should allow you to pass the already-parsed filter object straight into client.search (removing the need to parse it a second time).

Awesome, yep parsing first and then passing the Filter tree to search() works a treat.
One non-urgent niggle for next time your in there: the errors doc says:

All errors in the ldapjs framework extend from an abstract error type called LDAPError.

but parseFilter() just throws a basic Error.  I've wrapped that in your LDAPError for now so I can handle it appropriately downstream.

⚠ This issue has been locked due to age. If you have encountered a recent
problem that seems to be covered by this issue, please open a new issue.
Please include a minimal reproducible example
when opening a new issue.


chore: import common variables from design system

Description
Import variables that are commonly used both in the design system and in the core repository from the design-system in order to prevent duplication of code and maintain a single source of truth.
Closes https://github.com/appsmithorg/appsmith/issues/17599
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Builds pass locally. Regression across app on DP.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

/ok-to-test sha=5fafeb1

/ok-to-test sha=6c09028792dc5eab079fc0e57ce7731c1de6f031

/ok-to-test sha=6c09028792dc5eab079fc0e57ce7731c1de6f031

This PR has been tested. No issues found.

/ok-to-test sha=6c09028792dc5eab079fc0e57ce7731c1de6f031

/ok-to-test sha=aed2ee63b7a2e1957d1dfa5e4f0ebe52c9151feb

/ok-to-test sha=aed2ee63b7a2e1957d1dfa5e4f0ebe52c9151feb

/ok-to-test sha=8d2e07bd0f8f88bda290d479fbb7a387bafb8b2d


[Bug] Effects types are all typed as "any"

Bug Report
Describe the bug
All of the effects are available by name, but all of them currently are typed as any, which allows them to work and become discoverable, but doesn't help in determining what type of value can be used or restricting it for type safety.

Is this a regression?
Not a regression, as effects previously didn't have any types.
The work for this was completed in: https://github.com/colbyfayock/cloudinary-util/pull/121
The idea was to create an easy to manage way to define effects centrally, but in the process by spreading the definitions, the type information appears to be lost.

Resolved via https://github.com/cloudinary-community/cloudinary-util/pull/162


Demo SAX parsing

Is there a demo showing how to use the SAX parsing capability of rapidjson?

I searched through the examples but can't find a thing and I can't understand
how to do it just by reading the rapidjson source code.

If someone is willing please add an example of how to do SAX parsing with
rapidjson.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 29 Aug 2012 at 8:40

Original comment by<EMAIL_ADDRESS>on 12 Nov 2012 at 2:15

Added labels: Type-Task
Removed labels: Type-Defect

[deleted comment]

Awesome! Thanks!

Original comment by<EMAIL_ADDRESS>on 13 Jul 2014 at 9:16

Documentation on SAX-style API
https://github.com/miloyip/rapidjson/blob/master/doc/sax.md

SAX-style API related examples:
https://github.com/miloyip/rapidjson/tree/master/example/simplereader
https://github.com/miloyip/rapidjson/tree/master/example/simplewriter
https://github.com/miloyip/rapidjson/tree/master/example/messagereader
https://github.com/miloyip/rapidjson/tree/master/example/capitalize

Original comment by<EMAIL_ADDRESS>on 13 Jul 2014 at 10:10

Changed state: Fixed

Example attached. Sample output:

Original JSON:
  { "hello" : "world", "t" : true , "f" : false, "n": null, "i":123, "pi": 3.1416, "a":[1, 2, 3, 4] }
hello = world
t = true
f = false
n = null
i = 123
pi = 3.141600
array a [
1
2
3
4
]

Original comment by<EMAIL_ADDRESS>on 4 Apr 2013 at 11:01
Attachments:

sax.cpp

Original comment by<EMAIL_ADDRESS>on 24 Jun 2014 at 2:07

Changed state: Accepted


provide WireGuard as an option for the vpn layer to connect clusters

see https://gravitational.com/blog/announcing_wormhole/

@nicolasochem posted this on slack recently: https://kilo.squat.ai/docs/introduction/

Kilo is a multi-cloud network overlay built on WireGuard and designed for Kubernetes.


Where is "llama-7b-hf"?

Could you please provide the link for the llama model you use in this project?

I also encountered this problem, may I ask you to solve this problem？

The original decapoda-research/llama-7b-hf model is no longer accessible on Hugging Face. You can try to use  the mirror at baffo32/decapoda-research-llama-7B-hf or the alternative at luodian/llama-7b-hf. #https://github.com/tloen/alpaca-lora/issues/598

Thank you very much. I have solved the problem😁
---Original---
From: "Xiaoman @.>
Date: Wed, Dec 11, 2024 05:47 AM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [xiaoman-zhang/PMC-VQA] Where is "llama-7b-hf"? (Issue #19)
The original decapoda-research/llama-7b-hf model is no longer accessible on Hugging Face. You can try to use  the mirror at baffo32/decapoda-research-llama-7B-hf or the alternative at luodian/llama-7b-hf. #tloen/alpaca-lora#598
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>


Icon Drawing Fuzzy

Hi,
I noticed that the icon drawing seems to be kind of fuzzy. I was able to improve the quality of the icon drawing on the tabs/windows/etc by switching it from DrawIcon to DrawImage and using the Icon.ToBitmap() method. If the icons are set to 32x32 they seem to draw well but 16x16 came out fuzzy.
I will note I haven't really checked to see if there are any performance implications to this and I also haven't tested it using Windows 8/etc. As of right now I have only seen it on windows 7 but I figured it was worth a note.

I think more information (such as screen shots) is required, as below

About the icon file, what sizes of images does it contain? That heavily influences which size is chosen at runtime for rendering.
When you describe the runtime effect is fuzzy, what exactly is the pattern? That often can lead us to the cause.

Thanks. I will do some further analysis on this issue. By enlarging them to 800% I can see the actual pixels being rendered are significantly different, meaning there must be some processing in the background, which were not fully documented by Microsoft in the obvious MSDN links.

I have done a few experiments, and it seems to be an issue of System.Drawing.

When an icon with multiple image types (16x16, 32x32, and so on), Graphics.DrawIcon does not seem to pick up the 16x16 size. Thus, the chosen size (32x32 in my test) is scaled down to 16x16 and lead to not only the fuzzy result but also some further detail loss. The detail loss can be observed by setting the same icon as main form icon. Then the icon in window title bar looks different from the document tab icon, though they come from the same icon file.

When an icon with only 16x16 image type, Graphics.DrawIcon seems to give the same look of the window title bar (still fuzzy, but no further loss). I think that's already the best we can achieve.

Graphics.DrawImage with Icon.ToBitmap as you suggested does not give a better result than the simple workaround above, and it also requires code changes (which I personally try to avoid).

Thus, my conclusion is that instead of using an icon with multiple image types, we should use an icon with only 16x16 image type. In this way, no code change to DPS is required.

While I agree using a 16x16 icon does achieve the desired result the app in question is grabbing the icon from the filename so the icon associated with the extension of the file it is loading. As such I have no control over the icon format available and it appears that the ToBitmap does get the desired result of forcing it into drawing the properly sized icon instead of a set 32x32 icon.

As this is more of a System.Drawing and GDI+ issue, it would be less relevant for DPS to fix it.
Meanwhile, for any apps built upon DPS, the control over icon format should be required. If the icon is provided by end users who customize the look and feel, a message should be delivered to such users that only icons follow the mandate format are supported.


Calico without mesos-DNS / kuberentes like cluster IP in Calico.

Is there a way to do service isolation using calico in mesos without using mesos-DNS (DNS based LB will probably not yield good load-balancing distribution of backend containers)?
e.g. iptables based kube-proxy in kubernetes maintains source IP of client pod. And thus calico can do service isolation based on 4-tuple in the packet before forwarding packet to destination pod.
But if we use a user space load balancing solution to do LB in mesos, then user-space LB will change the source IP to either docker host IP or Calico assigned IP (if LB is integrated with Calico). and thus doing service isolation will be difficult as source IP of client container has changed.
One solution to this problem is to have an concept similar to cluster IP but implemented at Calico layer itself. To explain it further say a service 'app-1' is created, Calico assigns a cluster IP 'X' from same calico profile as is assigned to backend containers of 'app-1'. This IP 'X' is then given to each load-balancing container (LB container is present in all the docker host machines). An DNS solution meanwhile can create an A-record (to map 'app-1' name to IP 'X').
And thus request can be trapped by calico even before forwarding the packet to LB (IP 'X' which is also part of same profile as 'app-1' backend containers). LB will then forward the packet to backend container using source IP 'X' itself.
I feel this will lead to better performance.

@dp-farm I believe the new minuteman load balancer does what you are suggesting.
To reiterate, the problem with Marathon-lb, as you said, is that containers must forward requests to the LB-in-the-middle, which will rewrite the packet in userspace before forwarding on to the final destination agent/container. What's worse, this LB is usually running on a different host, so most requests will jump across 3 hosts to go from container to container.
Minuteman solves this by running on each agent, and Dest-NAT'ing directly in kernelspace (using IP-tables nat'ing).
At this time, Minuteman can only rewrite a dest-IP to be an agent-IP, as it assumes containers will be running in host or bridge-networking. Basically, it never assumes that a container-IP is routable, which is true in cases like Calico. In order to make Minuteman compatible with networking plugins which assign cluster-addressable IPs (such as Calico), Minuteman will need to believe that container-ips are routable, and NAT to them instead of the host-ip.
If you're interested in Minuteman, and would like to see it support custom networking plugins such as Calico, please do raise your interest with the DC/OS maintainers to show your support.

Thanks @djosborne . Yes seems like minuteman will work in such use-cases.
Though still I want to explore whether in Calico we can implement ClusterIP behaviour? i.e. assign same host-local IP 'X' from some calico profile in each node to LB-in-the-middle. And then Calico can do policy enforcement even before forwarding packets to LB-in-the-middle.
Is that possible by any way to assign same IP (say 'X') to multiple workloads (in different host) and route only to container with IP 'X' running in same host?

Is that possible by any way to assign same IP (say 'X') to multiple workloads

Assigning the same IP to multiple workloads is currently unsupported. Calico's IP-per-container model assumes that each container is uniquely routable by its IP.

assign same host-local IP 'X' from some calico profile in each node to LB-in-the-middle

@dp-farm I'm confused by this, can you elaborate some more?

IP 'X' is similar to kubernetes cluster IP.  So when a container (running on host 'H1') tries to connect to 'X', Calico routes it to a container which owns IP 'X' in this host (H1).
Only difference is that instead of using Iptables to forward packets to Cluster IP ('X'), Calico itself forward the packets. That way policy enforcement can be done before LB itself. And this mode will work for user-space LB as well.

Ah ok. So I believe minuteman covers this with Virtual IPs. Our goal is to integrate Calico with Minuteman so that you can use Minuteman VIPs and its distributed, smart load balancing, while still using Calico policy for security. In that scenario, each container in a particular service would have both its own Calico IP and a shared Minuteman VIP. Traffic sent to the VIP will be NAT'd to the Calico addresses. Still some work to be done there today, but we've done the initial testing to ensure that this is feasible.
Though Calico doesn't implement anything like this at the present time, it could reasonably fit in the existing data model. Would be a pretty neat feature.

@dp-farm I'd like to get a better understanding of your requirements.

Only difference is that instead of using Iptables to forward packets to Cluster IP ('X'), Calico itself forward the packets.

When using the kube-proxy in iptables mode, Calico is indeed doing the forwarding of traffic.  The kube-proxy iptables rules are simply decoding the service IP to a real container IP address.  Calico can still enforce network policy on top of this just fine.
With solutions like iptables-kube-proxy / minuteman, there is no "man in the middle" - the load-balancing occurs as part of the network fabric itself and the source IP should be maintained.

@caseydavenport That's right. What I am suggesting only makes sense if there is a user space proxy in between which can't maintain source IP of client container.

@dp-farm  This completely slipped my mind -  Marathon-LB is for N/S traffic. If you're doing E/W traffic (i.e. container to container), you should not hit the Marathon-LB entry at all.
Instead, both Mesos-DNS and Navstar can provide a DNS record for your scaled task, which, when resolved, will point to one of the Calico IPs of that task. Container A can then route directly to Container B, without having to jump to multiple nodes. Those DNS solutions are smart enough to balance to a different Container B address each time you resolve it.

I think the resolution here is to use a distributed load balancer like the kube-proxy, which doesn't obscure the source address of traffic.
The problem with enforcing policy before a man-in-the-middle load balancer is that you don't actually know which ultimate destination the traffic will be load-balanced to because that decision is up to the load balancer, not the network fabric.
Will re-visit the discussion here if / when we look into a more integrated solution with man-in-the-middle load-balancers, but closing for now.


Burundi observed holidays performance optimization

Performance tests:
def calc_hol1():
    for year in range(1962, 2100):
        hols = Burundi(years=year)

def calc_hol2():
    hols = Burundi(years=range(1962, 2100))

t1 = timeit.timeit(calc_hol1, number=100)
t2 = timeit.timeit(calc_hol2, number=100)

Test
Current beta
PR

t1
3.114
3.117

t2
6.797
2.920

Coverage: ?%. Remained the same when pulling c78afe173e298bdb04345d58e918c60f447cc9b0 on KJhellico:upd-burundi-observed into 719c2677d48e5369ab4c53571ff64a8ba079014d on dr-prodigy:beta.

Coverage: 100.0%. Remained the same when pulling c78afe173e298bdb04345d58e918c60f447cc9b0 on KJhellico:upd-burundi-observed into 719c2677d48e5369ab4c53571ff64a8ba079014d on dr-prodigy:beta.


ReactEditText extends AppCompatEditText

Summary
Google recommends to extend AppCompat widgets, and this PR changes ReactEditText to extend AppCompatEditText.
Changelog
[Android] [Changed] - ReactEditText extends AppCompatEditText
Test Plan
CI is green, and everything works as before.

@cpojer is there anything I can help with?

You may want to test this with old Android OS like API 19.
Earlier I found using AppCompat widgets wrap the original context, making any (ReactContext) getContext() throw java.lang.ClassCastException: android.support.v7.widget.TintContextWrapper cannot be cast to com.facebook.react.bridge.ReactContext.
I see couple dangerous getContext usages that way in ReactEditText class.
See https://github.com/facebook/react-native/issues/22885#issuecomment-458435675

@hey99xx We cannot stick to platform widgets forever. What would be a generic solution for this?

@hey99xx quick google search reveals that it can be solved if we extend AppCompatActivity. So I think it'll gone once 0.59 released with ReactActivity extending AppCompatActivity.

I dont know why activity class matters for casting context. In support library code that wraps the context with TintContextWrapper only api version is checked, not activity type. I have two suggestion for you:

(1) We can either have a generic method that does the context unwrapping done in https://github.com/facebook/react-native/commit/58437cd10a667bbcbc16781df855fd7c3d73bf49 like
public static ReactContext getReactContext(View view) { ... }

then when we need to get the context
@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
-  ReactContext reactContext = (ReactContext) getContext();
+  ReactContext reactContext = ReactContextHelper.getReactContext(this);

(2) or we save the ReactContext as variable when we know it'll be used again:
+final ReactContext mReactContext;

-public ReactEditText(Context context) {
-  super(context);
+public ReactEditText(ReactContext context) {
+  super(context);
+  mReactContext = context;

@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
- ReactContext reactContext = (ReactContext) getContext();
  InputConnection inputConnection = super.onCreateInputConnection(outAttrs);
  if (inputConnection != null && mOnKeyPress) {
-   inputConnection = new ReactEditTextInputConnectionWrapper(inputConnection, reactContext, this);
+   inputConnection = new ReactEditTextInputConnectionWrapper(inputConnection, mReactContext, this);
  }

I prefer 2nd as it's cleaner, and you don't need to worry about which context class wraps which in the future.

Btw platform widgets like EditText is not getting deprecated. AppCompatEditText is a subclass of EditText that's documented as

A EditText which supports compatible features on older versions of the platform, ...

As I understand, AppCompat widgets only add value for old Android versions to make app look consistent with modern Android versions, as also mentioned in original checkbox PR https://github.com/facebook/react-native/pull/18318. So I support your PRs like this, just make sure you test it :)

@hey99xx I target M for my current project, because we've been experiencing many issues/inconsistencies on Android versions below. Recently, I found that RN use many APIs that are not available in Android 4.x, and probable solution to it is to use more from Support Library. Thank you.

@cpojer @mdvacca please review and merge 👍

Aren't setIntrinsicContentSize and onCreateInputConnection crash on lower API versions after this?


Add lab 10 - Puppy REST

Fixes #668
Review of colleague's PR #soon
Changes proposed in this PR:
- Add Lab 10 - REST Puppy

Woops.

The go-course is now closed. Thank you very much for participating.


Boolean default is wrong in ElasticsearchRESTResource

I've been looking at the code in lib/puppet_x/elastic/elasticsearch_rest_resource.rb as a working example for a REST provider I've been writing for a different product, and have notice that validate_tls doesn't seem to have a valid default.
   extender.newparam(
      :validate_tls,
      :boolean => true,
      :parent => Puppet::Parameter::Boolean
    ) do
      desc 'Whether to verify TLS/SSL certificates.'
      defaultto true
end

The default value should be a symbol, I think. ie  defaultto :true, otherwise p[:validate_tls].value in the prefetch method in the provider returns an undefined method 'value' for nil:NilClass error.
It seems to be masked by the Puppet defined types always setting validate_tls when the type is called.

Thanks for running through the code quality of the REST types and providers; I thought I was the only one who would ever look at that low-lever provider code 😂  Bear with me on the way that stuff is laid out, I didn't find any existing REST examples to go off of.
I based the boolean parameters off of existing core Puppet type parameters with boolean values - see this user type parameter as an example. Based upon how upstream Puppet does it, native ruby boolean types rather than symbols seem to be the correct approach, would you agree? If it breaks somewhere, we should definitely fix it.
Out of curiosity, I tried to manage a REST-based type with a manifest without wrapping it in a Puppet defined type, and things worked as expected without any errors. Here's the example manifest that worked for me:
class { 'elasticsearch':
	java_install => true,
	manage_repo => true,
	repo_version => '5.x',
}
elasticsearch::instance { 'es-01': }
elasticsearch_index { 'foo':
	settings => {
		'index' => {
			'number_of_replicas' => 1,
		}
	},
}

So leaving those parameters at their type-defined defaults didn't throw any problems. Do you have any failing examples that I could try and reproduce from?

Hi Tyler!
Ah, I see what you mean about the upstream user type. I've gone back and re-examined my assumptions.
So, assumption one: that my code was close enough to your code, to make no difference.
elasticsearch_index { 'foo':
	settings => {
		'index' => {
			'number_of_replicas' => 1,
		}
	},
}

This works as expected, no errors, as you found.
My second assumption was that the boolean state made no difference. However, changing defaultto true to  defaultto false for validate_tls (as it is in the code I'm developing) caused this in the puppet run:
Error: Could not prefetch elasticsearch_index provider 'ruby': undefined method `value' for nil:NilClass
Notice: /Stage[main]/Elasticstack::Elasticsearch/Elasticsearch_index[foo]/ensure: created
Error: /Stage[main]/Elasticstack::Elasticsearch/Elasticsearch_index[foo]: Could not evaluate: Elasticsearch API responded with: index [foo/DYjzzF2NQhS-3jIXWPnsTw] already exists

So, looks like having a boolean parameter in Puppet (maybe just 3.8.7 and earlier?) with a default of false stops it from existing in the resources hash passed to self.prefetch. defaultto :false works. No idea why, but seems that's it not an issue in your code, but somewhere in Puppet.
As for the low-level provider code - I've no issues with it at all! ^_^

That is interesting - I tried passing false via the bare type and it works, so there's probably some Puppet bug in the 3.x series related to defaultto :false as you mentioned. Very weird.
Given that's an odd bug on the dead version of Puppet, feel free to close this issue (unless you feel like there's a latent bug here somewhere that should be fixed).

No, nothing to be fixed here! Closing.


Reshape data for process tomo

Let me check whether this is even necessary.  I thought @matthewware and I did QPT a couple weeks ago with a single experiment.

Closed by https://github.com/BBN-Q/Qlab/commit/41574704171a7a6bce3523cb72c5521eda329425


protoc-gen-go should be able to compile multiple packages per run

Passing multiple packages' worth of *.proto files currently fails when using (protoc-gen-go)[https://github.com/golang/protobuf/blob/master/protoc-gen-go/generator/generator.go#L612:L614].
The same functionality is supported by other generators (at least the C++ generator shipped with protoc). protoc-gen-go should support this as well.

The standard way for Go packages to be distinguished is to be in separate directories. The package declaration in a Go file is not the way that package boundaries are defined; the go tool demands the package names to match, but it otherwise doesn't use it to determine what constitutes a package. The other languages that ship with protoc don't care about package boundaries in the same way as Go (the mapping to C++ is simply a namespace), and so Go requires you to pass a package-worth of .proto files to protoc at a time. That is sometimes trivial (if your .proto files are already grouped into the relevant directories), but will sometimes require a bit of manual work.

The standard way for Go packages to be distinguished is to be in separate directories. The package declaration in a Go file is not the way that package boundaries are defined; the go tool demands the package names to match, but it otherwise doesn't use it to determine what constitutes a package. The other languages that ship with protoc don't care about package boundaries in the same way as Go (the mapping to C++ is simply a namespace),

With you so far.

and so Go requires you to pass a package-worth of .proto files to protoc at a time.

This is where you lost me. That Go demands that a package is made up of files in the same directory is not the same as compiling a single package at a time. Rather, it seems that there's a requirement that for each collection of files that belongs to a single package must be located in the same directory.
For these files which each belong to a different package:
        ├── extension_base
        │   └── extension_base.proto
        ├── extension_extra
        │   └── extension_extra.proto
        ├── extension_user
        │   └── extension_user.proto

It should be legal to invoke protoc --go_out=. and have the generated Go files mirror the layout of the proto files (both in packages and on disk).

I'm not saying that .proto files need to be grouped into directories, one package per dir. I'm saying that a single invocation of protoc should be given a single package's worth of .proto files when generating Go code. That might involve multiple invocations or some trivial shell scripting, but that's easy. I am not keen on adding more complexity to protoc-gen-go to support that use case.

I understand what you are saying, but you are just describing the status quo. Why is this not a valid use case for protoc-gen-go to support? The exact same use case is supported by the Java code generator.

See my comment in the pull request.

so, how to solve the question? now every time I generate code for golang, I need do lots of manual work to fix generated code.

We use https://github.com/square/goprotowrap - a wrapper that collects things into packages. Pull requests welcome :-)
The sad part is that it would be pretty straightforward to make Go protos work like other languages :-(

@tamird So, has this been fixed or not? I cannot get it work, I have some structures like this:
module-proto/
  |
  |--lib/
  |    |--bool_res.protp
  |    |--empty.proto
  |    |--mobile_phone.proto
  |    |
  |--microservices/
  |    |--auth/
  |    |    |--v1/
  |    |    |   |--auth.proto
  |    |    |--apis.proto
  |    |--sync
  |    |    |--v1/
  |    |    |   |--sync.proto
  |    |    |--apis.proto

And under the path module-proto/, tried to run protoc -I=. --go_out=plugins=grpc:. **/*.proto, keep getting error:
protoc-gen-go: error:inconsistent package names: microservice lib

Where am I doing wrong?

It has not been fixed.
On Mar 27, 2017 06:54, "Leonard Shi"<EMAIL_ADDRESS>wrote:
@tamird https://github.com/tamird So, has this been fixed or not? I
cannot get it work, I have some structures like this:
module-proto/
|
|--lib/
|    |--bool_res.protp
|    |--empty.proto
|    |--mobile_phone.proto
|    |
|--microservices/
|    |--auth/
|    |    |--v1/
|    |    |   |--auth.proto
|    |    |--apis.proto
|    |--sync
|    |    |--v1/
|    |    |   |--sync.proto
|    |    |--apis.proto
And under the path module-proto/, tried to run protoc -I=.
--go_out=plugins=grpc:. **/*.proto, keep getting error:
protoc-gen-go: error:inconsistent package names: microservice lib
Where am I doing wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/protobuf/issues/39#issuecomment-289419966, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdsPGqr60QjtTMjhgzwWkuKcvvdA2JYks5rp5VngaJpZM4FAJ1h
.

What's the status of this bug? Why is this and https://github.com/golang/protobuf/issues/67 both closed?
I have a number of protos which all depend on one proto declaring a few custom options declared in its own package. If I compile all the protos separately, I run into https://github.com/golang/protobuf/issues/67 and running them together I run into this issue. It seems like packaging protos in go is broken then?

Google doesn't want to fix this, too complicated apparently.  thanks to Square for providing a practical solution to a real issue.  shame on golang protobuf maintainers.

I'm going through the issue tracker and figuring what needs to be done. Re-opening this so this doesn't get forgotten. This does not necessarily imply it will be implemented as every feature needs to be carefully thought through.

Pinging this thread for subscribers to see #515.

I wanted to play with golang and implement one of grpc services in it. Got this error, saw this thread.. This is the fastest turn around that language can provide.

As a workaround I made simple interation other each proto file and called protoc compiler on that file
for filename in ${PROTO_DIR}/*.proto; do
    filename=${filename##*/} # remove path
    filename=${filename%.*} # remove extension

    rm -rf ${GO_OUTDIR}/${filename}
    mkdir ${GO_OUTDIR}/${filename}

    ${PROTOC} \
    --go_out=plugins=grpc:${GO_OUTDIR}/${filename} \
    -I ${PROTO_DIR} ${filename}.proto
done

Because of this bug, Google's own Gradle's plugin for protobuf https://github.com/google/protobuf-gradle-plugin makes it impossible to build Go sources unless they are all in the same folder/package, forcing us to have all services and unrelated 'messages' under same package
Invocation of protoc from this plugin is ONE HUGE invocation with all the files, include dirs, and all the language plugins. So far C# and Java are producing something nice and usable (packages etc), but protoc-gen-go can only build one package from one directory.

New year's update:

The v2 proto implementation (currently on track to release later this year) will completely fix this issue. It includes a rewritten protoc-gen-go which has no restrictions on what .proto source files can be simultaneously compiled. (You can find this version of protoc-gen-go on the api-v1 and api-v2 branches of this repository. Note that these branches are unreleased and subject to change without notice.)
While the currently released protoc-gen-go doesn't let you do protoc --go_out=. **/*.proto, you can get the (probable) desired effect with for x in **/*.proto; do protoc --go_out=paths=source_relative:. $x; done. If you have cases where this doesn't produce the desired results, I'd very much like to hear about them.
While not specifically about this issue, as a general rule I strongly recommend always passing the paths=source_relative option to the compiler (e.g., protoc --go_out=paths=source_relative:. foo.proto) and setting option go_package = "full/import/path/of/package"; in every .proto source file. Following these rules resolve most problems with generation that I've seen.

How do I add the plugins=grpc to protoc --go_out=paths=source_relative:. foo.proto

How do I add the plugins=grpc to protoc --go_out=paths=source_relative:. foo.proto

Everything before the : is a comma-separated list of options, so:
--go_out=plugins=grpc,paths=source_relative:.

How do I add the plugins=grpc to protoc --go_out=paths=source_relative:. foo.proto

Everything before the : is a comma-separated list of options, so:
--go_out=plugins=grpc,paths=source_relative:.

Thanks alot, works like a charm

Any updates on this?

This should be fixed in the v1.20.0 release.

This should be fixed in the v1.20.0 release.

When will  go get -u github.com/golang/protobuf/protoc-gen-go support using this latest v1.20 release of protoc-gen-go?


GravityTypes referred to as Integer

Reported by sjoelund.se on 7 Sep 2012 08:26 UTC
GravityTypes in the World object is defined as an enumeration but it is used or referred to as an Integer:
$ grep -nR "gravityType=[0-9]" libraries/ | grep -v svn | grep -v "Modelica 3.1"
libraries/ModelicaTest 1.1/MultiBody.mo:3523:                                  animateWorld=false, gravityType=0)
libraries/ModelicaTest 1.1/MultiBody.mo:6028:                                  animateWorld=false, gravityType=0)
libraries/Modelica 3.2.1/Mechanics/MultiBody/package.mo:1273:      "Constant gravity acceleration, resolved in world frame, if gravityType=1";
libraries/Modelica 3.2.1/Mechanics/MultiBody/package.mo:1275:      "Field constant of point gravity field, if gravityType=2";

ModelicaTest needs to be updated to be legal Modelica. And the documentation strings should be updated.
I did not update any code because 0 is not a valid enumeration index.

Migrated-From: https://trac.modelica.org/Modelica/ticket/803

Comment by hansolsson on 5 Dec 2012 16:40 UTC
Fixed in MSL; ticket was not updated.


buildPlugin error

`
10:35:31: Executing task 'buildPlugin'...
:compileJava
Malformed jar [sa-jdwp-1.12.jar] found on classpath. Gradle 5.0 will no longer allow malformed jars on a classpath.
...
:patchPluginXml
:processResources
:classes
:instrumentCode FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':instrumentCode'.

taskdef A class needed by class com.intellij.ant.InstrumentIdeaExtensions cannot be found: org/jetbrains/org/objectweb/asm/ClassReader
using the classloader AntClassLoader[/Users/zhenjun/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/2019.1.2/7999543c914a11e4d9b4039ed77338c4f36a86dd/ideaIC-2019.1.2/lib/javac2.jar:/Users/zhenjun/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/2019.1.2/7999543c914a11e4d9b4039ed77338c4f36a86dd/ideaIC-2019.1.2/lib/jdom.jar]

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Get more help at https://help.gradle.org

BUILD FAILED in 12s
4 actionable tasks: 4 executed
Unable to load class 'org.jetbrains.org.objectweb.asm.ClassReader'.
This is an unexpected error. Please file a bug containing the idea.log file.
10:35:44: Task execution finished 'buildPlugin'.
`

I cannot reproduce. Can you try running with the checked-in gradlew? (i.e. $ ./gradlew buildPlugin)


Add support for 64-bit Windows-based browsers.

This should fix #30.  @mramato can you test?

I can confirm this fixes the issue.  It's interesting that Chrome reports Win32 for platform even in 64 bit.  Probably for compatibility reasons.

Thanks!

This is deployed now.


PR: Move all tests to be pytest's

Fixes #3195

Please remove all commits related to formlayout. I think we don't use it anywhere in our code, and we probably should remove it (in 3.2, I think).

@dalthviz, is this ready?

@ccordoba12 I think that there are some more tests to be moved in utils and app directories.

@dalthviz, please remove all real tests (i.e. the ones that contain assert statements) in files that are not widgets.
That would be the last thing to do before merging this one. Great work, as always!!

@dalthviz, is this one ready?

@ccordoba12 yes I think so 👍

The failure in CircleCI is caused by me. Don't worry about it :-)

Please merge with 3.1.x and solve the little error I mentioned above.


Cant use on pytorch 1.5/cuda 10.2 ImportError: libcudart.so.10.0: cannot open shared object file: No such file or directory

Google says this error cased by different versions of pytorch compiled and system cuda version.
But it should be same
https://i.imgur.com/u3GTFgv.png

Did you by any chance use e..g NVIDIA APEX for float16 training, and compiled this in the past with an older CUDA lib installed? I had the same import error with PyTorch 1.5 and CUDA 10.2 installed. Recompiling APEX with CUDA 10.2 resolved the issue.

Now I having the same problem on the new machine.
I have cuda 10.2 and pytorch 1.6 which also use cuda 10.2.
Also i wonder why it want libcudart.so.10.0 while it should be 10.2.
And i wonder why it work on colab.

Whole traceback
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/sru/sru_functional.py", line 613, in forward
    h, c = rnn(prevx, c0[i], mask_pad=mask_pad)
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/sru/sru_functional.py", line 409, in forward
    SRU_Compute = _lazy_load_cuda_kernel() if input.is_cuda else SRU_Compute_CPU
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/sru/sru_functional.py", line 35, in _lazy_load_cuda_kernel
    from .cuda_functional import SRU_Compute_GPU
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/sru/cuda_functional.py", line 14, in <module>
    verbose=False
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 974, in load
    keep_intermediates=keep_intermediates)
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1190, in _jit_compile
    return _import_module_from_library(name, build_directory, is_python_module)
  File "/home/ubuntu/anaconda3/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1538, in _import_module_from_library
    return imp.load_module(module_name, file, path, description)
  File "/home/ubuntu/anaconda3/lib/python3.7/imp.py", line 242, in load_module
    return load_dynamic(name, filename, file)
  File "/home/ubuntu/anaconda3/lib/python3.7/imp.py", line 342, in load_dynamic
    return _load(spec)
ImportError: libcudart.so.10.0: cannot open shared object file: No such file or directory

同样遇到这个问题，自己的解决过程如下：https://blog.csdn.net/qq_32239767/article/details/109626626


[a11y walker] highlighting wrong fence

From https://github.com/zorkow/speech-rule-engine/issues/24
On WebKit, in the CS equation, if I navigate to one of the closing paranthesis, it gets the background highlighting but its opening counterpart gets the foreground highlighting.

This bug is not specific to WebKit, correct?

I also see this on Chrome 45 but not on Chrome 47.

It looks like this is this bug, fixed in blink but not WebKit itself.  It looks like it is specific to <use> elements, so it may be possible to work around it by enclosing the <use> in a <g>, at least temporarily while taking the measurement.

The issue29 branch of my fork of SRE includes a proposed work-around for this issue.


Running chains in parallel

Issue Description
I would like to be able to run multiple chains in parallel. My understanding is chains are independent of each other, so the task of sampling using multiple chains should be straightforward to parallelise, as other frameworks allow.
I'm surprised this wouldn't be a possibility in beanmachine, but I haven't found a parameter that allows this on the constructors of the inference classes, nor on the infer method of the BaseInference class. Also, I haven't found a reference to this anywhere in the documentation, not even as a limitation. Apologies if this is described somewhere and I'm just not seeing it.

Thanks for the feature request @javiermas! You are right in that chains are perfectly parallel, and so they should be parallelizable across cores. Unfortunately, the serialization that occurs in Python's multiprocessing module to communicate across processes breaks some PyTorch and unit testing functionality, which we are working on fixing, and we hope to support parallelization with Dask in an upcoming release. Thanks for your patience!

Hi @javiermas, with #1369 we have added an run_in_parallel arguments to infer that can be used to control whether chains should be run in subprocess or not. This will be available in our next release, which is expected to come in April. You can follow our instruction to install BM from source if you'd like to try this out sooner :).


Where do i put this code, i tried to put it into custom.js and added additional js in the config, but failed

$('.panel-collapse').on('hide.bs.collapse', function(e) {
    var target = $(event.target);
    if (!target.is('a')) {
        target = target.parent();
    }
    if (!target.hasClass('collapsed')) {
        return;
    }
    e.stopPropagation();
    e.preventDefault();
});

Originally posted by @ta-tikoma in https://github.com/the-control-group/voyager/issues/2125#issuecomment-424636311

Please use the issue templates.

where do i put this code?


basename

fixes #107

You should pull this branch.  There is a part in the test that needs to be fixed.


[packager] support browser exclude ("node-module": false)

{
  "browser": {
    "node-module": false
  }
}

require('node-module') should return an empty object

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out it's new home: https://productpains.com/post/react-native/packager-support-browser-exclude-node-module-false


Additional resource should be added to 03.1-platform.adoc

It seems that the HostedZone resource needs to be created ahead of time as well in order to use the DNSPolicy. I'm just suggesting that this is addressed here since I imagine that would be a CRD defined by a Platform Engineer.

ManagedZone resource becomes redundant with the new version of Kuadrant. So for the moment this is being created by the ansible scripts.


Fixed ActionRule's polymorphism via discriminator

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
[ ] I have reviewed the documentation for the workflow.
[ ] 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

[ ] 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

Note to reviewers: This PR is a do-over of https://github.com/Azure/azure-rest-api-specs/pull/10028
The original change was overrun because of another change that was introduced at the same time

hi @EranGon  does that mean this PR is fixing of Swagger: to fix previous merging conflict issue? Otherwise this is a breaking change to end users.

@yungezz you are correct - this PR is fixing of merge problems that cause change #10028 to over overrun. This is not a breaking change as it's documenting the current state

@yungezz Thanks for approving! What's the process of merging this PR? Who's authorized to do it?

@yungezz Thanks for approving! What's the process of merging this PR? Who's authorized to do it?

hi @EranGon  for bug fixing, still need to understand customer impact. Is there existing usage on the wrong API version, does it work now?

@yungezz as I've mentioned - this is a do-over of another PR that was already approved and merged, but was overrun by a later change. The original PR is here: https://github.com/Azure/azure-rest-api-specs/pull/10028 and it was approved by @akning-ms
To copy the main comment:
"I've reviewed the Breaking Change policy, wiki and form. I don't believe this commit is rightly considered a breaking change. Currently, there are missing fields in the responses due to a wrongly structured definition of inheritance by use of a discriminator. This PR fixes this: the only effect of this change is the returning in the response of expected fields which are currently missing. This change is aligning the behavior with the customer's current expectation."


Image component: 2/3rds with on larger screens

Discussion from https://github.com/nhsuk/nhsuk-frontend/issues/171
Original question: by @Demotive
Out of interest, why is the width set at 2/3 for larger screens? One could forsee uses where this wasn't the case?
Original response: by @bencullimore
Here are some notes as to why images are set to 2/3 on large screens:
Content team's needs
Upon investigating our content teams needs for using images they suggested that the images should flow with the text content; not appear too prominent or separate (isolated). They also recommended that captions are as important as the images themselves, so must reflect this in their importance on the page.
How to present images
We found gallery views (images side by side) confusing to users - this also jarred with the content teams needs for the images to appear as part of the content. With gallery views, users either missed the images in the right-hand column or they didn't know how to interpret the sequence. To simplify this we recommend stacking images (if part of the content).
We also found users clicking images in gallery views - expecting them to appear larger in a pop-up modal. By increasing the size of the images, and having them stacked in one column (not in two) we didn't see anyone clicking on them to expand in testing.
Hypothesis
If the images are three quarters the reading space
Then users will understand their place within the page (read as part of the text), and if multiple images are used, where the image sits in sequence
Because the images flow with the content
Research findings
Images tested well with all users, stating that they helped them understand how symptoms might appear and support written content
(usability lab, Leeds, 20th June 2018)

Does this need putting on the NHS digital service manual @bencullimore?

This is probably more suited for the NHS digital service manual backlog: https://github.com/nhsuk/nhsuk-service-manual-backlog/issues/110


Bugfix: OpenCV can't read files with unicode chars

Fixes #5

@xsatria can you test these changes and confirm if it solves your problem?


New template of Version.new breaking nanoFramework build

Hi,
We at nanoFramework are using Nerdbank.GitVersioning in our class libs. It uses it's project system and mscorlib.
Starting with v3.0.13-beta the builds start failing because of a change in the version.new file:
[assembly: System.Reflection.AssemblyVersionAttribute("<IP_ADDRESS>")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.6")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.6-preview.3+192e6bb6bf")]
[System.CodeDom.Compiler.GeneratedCode("Nerdbank.GitVersioning.Tasks","<IP_ADDRESS>440")]
internal static partial class ThisAssembly {
    internal const string AssemblyVersion = "<IP_ADDRESS>";
    internal const string AssemblyFileVersion = "1.0.6";
    internal const string AssemblyInformationalVersion = "1.0.6-preview.3+192e6bb6bf";
    internal const string AssemblyName = "System.Net.Http";
    internal const string AssemblyConfiguration = "Debug";
    internal const string GitCommitId = "192e6bb6bf0549deb83888e4654d24bdca5733e9";
    internal const string PublicKey = "00240000048000009400000006020000002400005253413100040000010001001120aa3e809b3da4f65e1b1f65c0a3a1bf6335c39860ca41acb3c48de278c6b63c5df38239ec1f2e32d58cb897c8c174a5f8e78a9c0b6087d3aef373d7d0f3d9be67700fc2a5a38de1fb71b5b6f6046d841ff35abee2e0b0840a6291a312be184eb311baff5fef0ff6895b9a5f2253aed32fb06b819134f6bb9d531488a87ea2";
    internal const string PublicKeyToken = "c07d481e9758c731";
    internal static readonly System.DateTimeOffset GitCommitDate = new System.DateTimeOffset(636949220730000000, System.TimeSpan.Zero);
    internal const string RootNamespace = "System.Net.Http";
}

the build exception is:
  obj\Release\System.Net.Http.Version.cs(14,9): error CS0234: The type or namespace name 'CodeDom' does not exist in the namespace 'System' (are you missing an assembly reference?) [d:\a\1\s\source\nanoFramework.System.Net.Http\System.Net.Http.nfproj]
  obj\Release\System.Net.Http.Version.cs(24,37): error CS0234: The type or namespace name 'DateTimeOffset' does not exist in the namespace 'System' (are you missing an assembly reference?) [d:\a\1\s\source\nanoFramework.System.Net.Http\System.Net.Http.nfproj]

That's because we don't have 'CodeDom' nor 'DateTimeOffset'.
Not sure how impacting this is but any chance couldn't could review if these are really necessary or suggest a workaround it? Thanks!

Thanks for the report, and I'm glad you're trying out the v3.0 beta!
I don't know anything about the nano framework. Is the idea that you have a subset of .NET types that doesn't include DateTimeOffset? The apisof.net report on that type is that basically everyone supports it, since .NET 2.0. But nanoframework isn't represented on that site.
Anyway, we could change DateTimeOffset to DateTime. I'm guessing you have that type in nanoframework, right?
Regarding CodeDom, I wasn't aware we had introduced that attribute recently. No reason to keep it though AFAIK, so we can remove it.

Alternatively, the incompatible attributes/members could be left out when generating code for this framework. Perhaps a MSBuild property to switch it off or using #ifdef

Always on the edge! 🙂
In a nutshell: .NET nanoFramework allows writing C# apps for small, resource constrained micro-controllers. It picked up where .NETMF left.
Because of those constrains our mscorlib has only a subset of the “full” frameworks. DateTimeOffset is one that's not there…
Thanks for considering removing the CodeDom attribute!

De: Andrew Arnott<EMAIL_ADDRESS>Enviado: Friday, May 31, 2019 8:56:21 PM
Para: AArnott/Nerdbank.GitVersioning
Cc: José Simões; Author
Assunto: Re: [AArnott/Nerdbank.GitVersioning] New template of Version.new breaking nanoFramework build (#346)
Thanks for the report, and I'm glad you're trying out the v3.0 beta!
I don't know anything about the nano framework. Is the idea that you have a subset of .NET types that doesn't include DateTimeOffset? The apisof.nethttps://apisof.net/catalog/System.DateTimeOffset report on that type is that basically everyone supports it, since .NET 2.0. But nanoframework isn't represented on that site.
Anyway, we could change DateTimeOffset to DateTime. I'm guessing you have that type in nanoframework, right?
Regarding CodeDom, I wasn't aware we had introduced that attribute recently. No reason to keep it though AFAIK, so we can remove it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/AArnott/Nerdbank.GitVersioning/issues/346?email_source=notifications&email_token=AAOLLMBR3VEQDUHEOPDUYWDPYF7GLA5CNFSM4HR4VEY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWWHGBA#issuecomment-497840900, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOLLMACYUFEROGTFR2AWXLPYF7GLANCNFSM4HR4VEYQ.

That could work too.

De: Andreas Grünwald<EMAIL_ADDRESS>Enviado: Saturday, June 1, 2019 11:15:09 AM
Para: AArnott/Nerdbank.GitVersioning
Cc: José Simões; Author
Assunto: Re: [AArnott/Nerdbank.GitVersioning] New template of Version.new breaking nanoFramework build (#346)
Alternatively, the incompatible attributes/members could be left out when generating code for this framework. Perhaps a MSBuild property to switch it off or using #ifdef
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/AArnott/Nerdbank.GitVersioning/issues/346?email_source=notifications&email_token=AAOLLMHLBUUYXQ3EBXZF7WTPYJD23A5CNFSM4HR4VEY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWW5OGI#issuecomment-497932057, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOLLMFBHLJKFYFB5W4CIKLPYJD23ANCNFSM4HR4VEYQ.

I don't think CodeDOM lets us emit #if.
What msbuild properties or preprocessor define symbols are unique to targeting NanoFramework?

Please take a look at this PropertyGroup on one of the targets file of our project system.
Define symbol NANOFRAMEWORK_V1_0 is an option along with any of the TargetFramework(...) msbuild properties.

Thanks.
FWIW the pattern for define symbols for all other framework types would suggest you define NANOFRAMEWORK, NANOFRAMEWORK_1_0 (no V).

Nice catch! Thanks. 🙂
I'll fix that for coherence. Consider it without the V.

De: Andrew Arnott<EMAIL_ADDRESS>Enviado: Sunday, June 2, 2019 2:46:36 PM
Para: AArnott/Nerdbank.GitVersioning
Cc: José Simões; Author
Assunto: Re: [AArnott/Nerdbank.GitVersioning] New template of Version.new breaking nanoFramework build (#346)
Thanks.
FWIW the pattern for define symbols for all other framework types would suggest you define NANOFRAMEWORK, NANOFRAMEWORK_1_0 (no V).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/AArnott/Nerdbank.GitVersioning/issues/346?email_source=notifications&email_token=AAOLLMDVI4EUL32AZLOH5U3PYPFLZA5CNFSM4HR4VEY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXWBRA#issuecomment-498032836, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOLLMBGLUSIMYGXY6LWNATPYPFLZANCNFSM4HR4VEYQ.

Since I suppose you aren't defining NETSTANDARD or NETFRAMEWORK, I might check for those instead of checking for NANOFRAMEWORK explicitly. Not sure yet.
But honestly I might just drop the attribute and change to DateTime to avoid the conditional compilation.

Got you! Whatever works best for you.
I really appreciate you are looking into this and accommodate the changes to make this work with nanoFramework. 👍🙂

De: Andrew Arnott<EMAIL_ADDRESS>Enviado: Sunday, June 2, 2019 6:48:36 PM
Para: AArnott/Nerdbank.GitVersioning
Cc: José Simões; Author
Assunto: Re: [AArnott/Nerdbank.GitVersioning] New template of Version.new breaking nanoFramework build (#346)
Since I suppose you aren't defining NETSTANDARD or NETFRAMEWORK, I might check for those instead of checking for NANOFRAMEWORK explicitly. Not sure yet.
But honestly I might just drop the attribute and change to DateTime to avoid the conditional compilation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/AArnott/Nerdbank.GitVersioning/issues/346?email_source=notifications&email_token=AAOLLMHFXWLYO5FWQ2AJ6ILPYQBXJA5CNFSM4HR4VEY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX2SHI#issuecomment-498051357, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOLLMDF44HEPATCLNQVENLPYQBXJANCNFSM4HR4VEYQ.

We're also seeing the same issue with SQL Server database projects (.sqlproj)

Is all this unique to 3.0 or are you seeing this on earlier versions?

I'm seeing this on 2.3.138

Turns out the .sqlproj problem was only an issue with net452 - updgrading to net461 brings in the required CodeDom reference


[2051] Funding - send bursary details to DTTP

Context
https://trello.com/c/wffvfcGh/2051-m-funding-send-bursaries-to-dttp
Changes proposed in this pull request
Sends the relevant bursary-related parameters to DTTP.
Guidance to review

 [M] Funding - send Bursaries to DTTP