Fix syntax error with C compiler in mxnet/c_api.h.

Declarations and definitions in mxnet/c_api.h should be available for C compiler without C++ features. This patch fixes some errors about the compatibility with C compiler. Include:

Incomplete MXNET_EXTERN_C macro.
<stddef.h> should be included for size_t.
bool is not a valid C data type.
In C language, default arguments would be syntax error.

Currently custom ops are not tested. I'm worried this might break it. Have you tested examples/numpy-ops/custom_softmax.py?

This PR only includes some syntax changes in include/c_api.h for compatibility reason. I am working on Haskell interface of MXNet via CFFI and these flaws are treated as syntax error by C compiler.
I also think test cases for custom ops are necessary but this problem should be solved by another separated patch. This PR only intends to make C API header files available for pure C compiler. This patch doesn't affect the semantics of original code, as well as the structures of struct CustomOpInfo and struct CustomOpPropInfo.

Besides, I have noticed that there are active changes related to C API in the nnvm branch, is there any roadmap about merging nnvm to main branch?

My point is these changes will break customops. Have you verified that they won't?
nnvm will be merged in a few weeks. If you are sensitive to api change I recommend you use NNVM branch

examples/numpy-ops/custom_softmax.py works well after these changes (under cpu_only mode and python 3.5). Log of last epoch is as follow:
INFO:root:Epoch[19] Batch [100] Speed: 16290.70 samples/sec     Train-accuracy=0.993600
INFO:root:Epoch[19] Batch [200] Speed: 17254.55 samples/sec     Train-accuracy=0.993300
INFO:root:Epoch[19] Batch [300] Speed: 14289.14 samples/sec     Train-accuracy=0.994800
INFO:root:Epoch[19] Batch [400] Speed: 14979.27 samples/sec     Train-accuracy=0.994900
INFO:root:Epoch[19] Batch [500] Speed: 13735.33 samples/sec     Train-accuracy=0.993900
INFO:root:Epoch[19] Batch [600] Speed: 14553.61 samples/sec     Train-accuracy=0.993000
INFO:root:Epoch[19] Resetting Data Iterator
INFO:root:Epoch[19] Time cost=3.987
INFO:root:Epoch[19] Validation-accuracy=0.976300

@tqchen @javelinjs @Ldpe2G Please have a look.
I think this looks fine but the interface change makes me a little nervous

This looks good to me.

Should we fix the prototypes for custom ops in python side?

Yes, we'd better do that. In most conventions, it won't hurt anyway, because bool is passed via integer in C ABI.

As long we do not have array of bools it is fine, and the ABI should remain compatible. but a better practice would be use int instead of bool

Seems fine. @sighingnow have you run a scala example to make sure no breaking anything?

@Ldpe2G Sorry for the delayed response. I have run the mnist example of scala package just now and it worked well. My local environment: Ubuntu 16.04 64bit, java-8-openjdk-amd64 and scala 2.11.6 (under cpu_only mode). The end of log is as follow:
2016-11-27 20:06:11,716 [main] [ml.dmlc.mxnet.Model] [INFO] - Epoch[9] Train-accuracy=0.9935397
2016-11-27 20:06:11,717 [main] [ml.dmlc.mxnet.Model] [INFO] - Epoch[9] Time cost=2332
2016-11-27 20:06:11,870 [main] [ml.dmlc.mxnet.Model] [INFO] - Epoch[9] Validation-accuracy=0.9714543
2016-11-27 20:06:11,881 [main] [ml.dmlc.mxnet.examples.imclassification.TrainMnist] [INFO] - Finish fit ...

So, these changes don't affect original code related to FFI.

Could you also change the c_bool to c_int in python/mxnet/operator.py?
I think we can merge after that

Done. The example numpy-ops/custom_softmax.py still works well.

Ping @piiswrong Any more comment on this pull request ?

bool is defined in C99.
#include <stdbool.h>
int main(void){
bool b = false;
}

We don't want to lose default value in C++. please define the following macro to keep it compatibale:
#ifdef __cplusplus
#define DEFAULT(x) = x
#else
#define DEFAULT(x)
#endif
int Func(int X DEFAULT(5))
{
printf("%d", X);
}

Thanks very much for your suggestions @howard0su . I have make a pull request in #4476 .


Fix/32635: Clear search input once invite user

Details

WS - Email of the newly added user appears in the find member field+all other members disappear

Fixed Issues

$ https://github.com/Expensify/App/issues/32635
PROPOSAL:
Tests

Login with any account
Go to Settings -> Workspaces -> Open any WS -> Members -> Invite
Using the paste option or CTRL-V paste the user email you just saved (can change it) -> Choose this user -> tap Next -> Invite
Vefrify that the member search field remains empty and members do not disappear from the WS list.

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Login with any account
Go to Settings -> Workspaces -> Open any WS -> Members -> Invite
Using the paste option or CTRL-V paste the user email you just saved (can change it) -> Choose this user -> tap Next -> Invite
Vefrify that the member search field remains empty and members do not disappear from the WS list.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Screencast from 07-12-2023 16:51:22.webm

MacOS: Desktop

This is not forwarding the search to the next page for me anymore 🤔

@rlinoz Can you share the screenshot?

Oh I am sorry, I was testing for rooms, and this is only for workspace. Which makes me think we should have this behavior for rooms and group chats as well.
But yeah, it is working, sorry.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Cherry-picked to staging by https://github.com/yuwenmemon in version: 1.4.9-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.


Port to Python 3

Hi,
anyone willing to port jpype to python 3? I know there is the @tcalmant port. But it is not up to date.
I could help out porting the Python part but probably won't be a big help porting the C code ;)
Nice infos can be found here:
http://python3porting.com/
https://docs.python.org/3/howto/pyporting.html

Hi,
When I started porting the project, I made a very small documentation (in French, sorry :p).
Here are the links, maybe Google translate can help for now. I'll translate them ASAP.
https://github.com/isandlaTech/cohorte-runtime/blob/master/documents/doc-jpype-py3/source/jpype-py.rst
https://github.com/isandlaTech/cohorte-runtime/blob/master/documents/doc-jpype-py3/source/jpype-c.rst
https://github.com/isandlaTech/cohorte-runtime/blob/master/documents/doc-jpype-py3/source/liens.rst
FYI, the most "painful" parts for the conversion are:

the conversion of string/unicode to bytes/string in Python 3
the replacement of PyObject by PyCapsule to let Python keep track of our C objects

Finally, the setup.py file of jpype-py3 adds support for Cygwin, if you're interested.

@baztian porting the c-part is also the hardest part. I've tried once, but especially the string conversion is really painful.

Here is a translated version of the C++ part of my previous links:
https://github.com/tcalmant/jpype-py3/wiki/py3_cpp
Another solution could be to update the jpype-py3 fork project, and to merge them once they'll have equivalent features :)

Hi @tcalmant, your documentation looks really promising. Maybe it convices @marscher to give it another try on the c/c++ part :)

a nice starting point would be to have equal test suites for py2/3, so
progress can be tracked during development.

That's definitely something where I can help / what I can do.
"Martin K. Scherer"<EMAIL_ADDRESS>schrieb:

a nice starting point would be to have equal test suites for py2/3, so
progress can be tracked during development.

Reply to this email directly or view it on GitHub:
https://github.com/originell/jpype/issues/119#issuecomment-73742639

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

@tcalmant, do you think its reasonable to wrap PyObject/PyEncapsulate in
our own wrapper class for compatibility or might it be enough to define
some "clever" macros?

Well, PyCapsule has a backport for Python 2.7 and 3.1+, so it could be used directly if you don't target Python 2.6.
BUT, I think that wrapping this kind of class is a better option: the Python C API has proved it is no fully stable on this kind of subject, so having a custom wrapping would simplify the maintainance of the library.
Also, +1 for test suites :)

I thought we have already dropped out support for Python 2.6, so we
could use PyCapsulate. A wrapper would also be nice, but it also add
additional overhead.

Python 2.6 is still in the travis build matrix

OK, tests and python code should now be python 3 compatible. Anyone willing to port the cpp part?

Please merge tcalmant's tests. Current tests do not work because of old print syntax (for Python2 only).

What kind of tests do you mean? We have a working testsuite. Please find the tests at https://github.com/originell/jpype/tree/master/test/jpypetest and the results at https://travis-ci.org/originell/jpype.
Print statements in unit tests are generally a bead idea. We don't have print statements in our tests.

I am talking about the parent folder: https://github.com/originell/jpype/tree/master/test
The files there include print statements. You should fix for Python3 usage, as so tcalmant has obviously done. Thanks.

Bytecompiling .py files below /home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4 using /usr/bin/python3.4
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/buf_leak_test.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/buf_leak_test.py", line 19
print 'string got deleted'
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/buf_leak_test3.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/buf_leak_test3.py", line 27
print 'created string', cnt
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/convtest.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/convtest.py", line 31
print 'Running baseline test : converting a python string->array.array->JArray(JByte). size = ', len(data)/1024.0, 'kb'
^
SyntaxError: invalid syntax
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/findjvm.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/findjvm.py", line 20
print os.path.dirname(os.path.dirname(jvmlib))
^
SyntaxError: invalid syntax
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/java_dom.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/java_dom.py", line 55
print count, "iterations in", t2-t, "seconds"
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/java_sax.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/java_sax.py", line 72
print count, "iterations in", t2-t, "seconds"
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/lists_and_maps.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/lists_and_maps.py", line 13
print arr
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/python_dom.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/python_dom.py", line 49
print count, "iterations in", t2-t, "seconds"
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/stub.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/stub.py", line 22
print s
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/test_awt.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/test_awt.py", line 5
print 'Thread started'
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/test_jarray_fixes.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/test_jarray_fixes.py", line 45
print 'iteration:', i
^
SyntaxError: Missing parentheses in call to 'print'
*** Error compiling '/home/builder/rpmbuild/BUILDROOT/jpype-0.6.1-1.x86_64/usr/lib64/python3.4/site-packages/jpype/test/testlucene.py'...
File "/usr/lib64/python3.4/site-packages/jpype/test/testlucene.py", line 8
raise IOError, "Please provide %s" % path.abspath(lucene_jar)
^
SyntaxError: invalid syntax

https://github.com/originell/jpype/issues/153


refactor(block): mode variant classes consistent with other components

Describe pull-request
Changing mode variant classes to be consistent with other components
Solving issue
Fixes: AB#3187
Suggested test steps

[ ] Browser testing (Chrome, Safari, Firefox)
[ ] Keyboard operability
[ ] Interactive elements have labels.
[ ] Storybook controls
[ ] Design/controls/props is aligned with other components
[ ] Dark/light mode and variants
[ ] Input fields – values should be displayed properly
[ ] Events

Screenshots
If applicable, add screenshots to help explain
Additional context
Add any other context about the pull-request here.

I guess we should align this one with: https://github.com/scania-digital-design-system/sdds/pull/800

All the block stuff look good to me. Im guessing the textarea/textfield/icon stuff shouldn't really be part of the PR. But maybe they got in there by accident?

Visually I would suggest to perhaps remove one level of the nested blocks so that it aligns with the documentation on the site. I'd also shorten the length of the text in the block so that it appears easier to read even though it is a placeholder :)

Visually I would suggest to perhaps remove one level of the nested blocks so that it aligns with the documentation on the site. I'd also shorten the length of the text in the block so that it appears easier to read even though it is a placeholder :)

GREAT feedback Charlotte! Thank you!


Auto replies should automatically reply to a custom entry

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=147273&view=logs&j=4d2898ab-dfbe-557e-92e7-aaac158fdd2f&t=500500fc-d3cc-5138-3a2a-6935e05fea33&l=97
1) VSCode Smoke Tests (Web)
       Terminal
         Terminal Input
           Auto replies
             should automatically reply to a custom entry:
     Error: Timeout: get terminal buffer '#terminal .terminal-wrapper' after 20 seconds.
      at poll (/__w/1/s/test/automation/out/code.js:65:19)
      at async Code.waitForTerminalBuffer (/__w/1/s/test/automation/out/code.js:200:9)
      at async Terminal.waitForTerminalText (/__w/1/s/test/automation/out/terminal.js:192:13)
      at async Context.<anonymous> (out/areas/terminal/terminal-input.test.js:33:17)

I have set it back to itSkipOnFail

Thanks 👍

Tracking in https://github.com/microsoft/vscode/issues/139083


workflow.Go cubic performance degradation

Hi all, we encountered this issue when trying to spin up 256 "goroutines" in a workflow and saw significant performance degradation in our unit test.
Recreate
Using go-workflows version v0.19.0, create the following test file:
package foo

import (
	"context"
	"fmt"
	"testing"

	"github.com/cschleiden/go-workflows/tester"
	"github.com/cschleiden/go-workflows/workflow"
	"github.com/stretchr/testify/mock"
	"github.com/stretchr/testify/require"
)

func WF(ctx workflow.Context, n int) error {
	wg := workflow.NewWaitGroup()
	for range n {
		wg.Add(1)
		workflow.Go(ctx, func(ctx workflow.Context) {
			defer wg.Done()
			workflow.ExecuteActivity[any](ctx, workflow.DefaultActivityOptions, Act).Get(ctx)
		})
	}
	wg.Wait(ctx)
	return nil
}

func Act(ctx context.Context) error {
	return nil
}

func BenchmarkWorkflowGo(b *testing.B) {
	run := func(b *testing.B, n int) {
		b.Run("n="+fmt.Sprint(n), func(b *testing.B) {
			for i := 0; i < b.N; i++ {
				wft := tester.NewWorkflowTester[any](WF)
				wft.OnActivity(Act, mock.Anything).Return(nil)
				wft.Execute(context.Background(), n)
				require.True(b, wft.WorkflowFinished())
				_, err := wft.WorkflowResult()
				require.NoError(b, err)
			}
		})
	}
	run(b, 1)
	run(b, 31)
	run(b, 51)
	run(b, 71)
	run(b, 91)
	run(b, 111)
	run(b, 131)
	run(b, 151)
	run(b, 171)
	run(b, 191)
	run(b, 211)
}

Issue
I observe that the performance of this simple unit test degrades significantly as the number of workflow.Go calls get made, as the graph below shows:

Out of curiosity, I took the log/log of the data and found it formed a linear function of slope close to 3, indicating a runtime performance of O(n^3).

Is this expected? With this type of degradation, the workflow.Go functionality has limited use cases for us. Thank you!

@jacobnowakowski1 Did you use a single worker or multiple? Thanks!

I tested with a local backend using the following code:
func BenchmarkWorkflowsGo(b *testing.B) {
	run := func(b *testing.B, n int) {
		b.Run("n="+fmt.Sprint(n), func(b *testing.B) {
			ctx, cancel := context.WithCancel(context.Background())

			be := sqlite.NewInMemoryBackend()
			var wg sync.WaitGroup
			b.Cleanup(func() {
				cancel()
				wg.Wait()
				require.NoError(b, be.Close())
			})
			wo := worker.DefaultOptions
			wo.MaxParallelActivityTasks = 256
			wo.MaxParallelWorkflowTasks = 256
			wo.ActivityWorkerOptions.MaxParallelActivityTasks = 256
			wo.WorkflowWorkerOptions.MaxParallelWorkflowTasks = 256
			wo.WorkflowExecutorCacheSize = int(math.Pow(2, float64(n+4)))
			wo.WorkflowExecutorCacheTTL = 10 * time.Minute
			numWorkers := 1
			for range numWorkers {
				wg.Add(1)
				go func() {
					defer wg.Done()
					w := worker.New(be, &wo)
					require.NoError(b, w.RegisterWorkflow(WF))
					require.NoError(b, w.RegisterActivity(Act))
					require.NoError(b, w.Start(ctx))
				}()
			}

			c := client.New(be)
			b.ResetTimer()
			for i := 0; i < b.N; i++ {
				wf, err := c.CreateWorkflowInstance(ctx, client.WorkflowInstanceOptions{
					InstanceID: "my-workflow",
				}, WF, n)
				require.NoError(b, err)
				require.NoError(b, c.WaitForWorkflowInstance(ctx, wf, 10*time.Minute))
				b.StopTimer()
				_, err = client.GetWorkflowResult[any](ctx, c, wf, 10*time.Minute)
				require.NoError(b, err)
				b.StartTimer()
			}
		})
	}

	for i := range 15 {
		run(b, int(math.Pow(2, float64(i))))
	}
}

The numWorkers var can be tweaked in the code. The results here are more aligned with expectation: The performance stays about constant till about 2000 goroutines. At this point we are getting close to our order of magnitude for maximum number of events per workflow of 50,000 anyway, so I'm not concerned about performance degradation past that. The degradation is likely due to the backend in any case, not due to the Workflow code using workflow.Go. Since I was running this locally, changing the number of workers didn't actually change the amount of compute, so adding more just added more overhead.

With these findings, I'm going to change the title of this issue to indicate that this is an issue when using the tester package. It took longer for the tester package to test a WF with 256 goroutines than a WF with a real backend!

Thanks for the great report and the analysis! I'll take a look


Bumped gradle version to 4.9

This allows jitpack to resolve dependencies

Codecov Report

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

@@             Coverage Diff              @@
##             master       #3      +/-   ##
============================================
+ Coverage     90.06%   90.35%   +0.29%
- Complexity      268      269       +1
============================================
  Files            22       22
  Lines          1490     1483       -7
  Branches        254      254
============================================
- Hits           1342     1340       -2
+ Misses           74       71       -3
+ Partials         74       72       -2

Impacted Files
Coverage Δ
Complexity Δ

...a/com/github/mproberts/rxtools/map/SubjectMap.java
90.08% <0%> (-1.12%)
22% <0%> (ø)

...ub/mproberts/rxtools/list/IndexedFlowableList.java
92.26% <0%> (+0.59%)
11% <0%> (ø)
:arrow_down:

...hub/mproberts/rxtools/list/SimpleFlowableList.java
97.05% <0%> (+1.4%)
11% <0%> (ø)
:arrow_down:

...ithub/mproberts/rxtools/list/BaseFlowableList.java
87.5% <0%> (+2.77%)
8% <0%> (+1%)
:arrow_up:

...thub/mproberts/rxtools/tools/BooleanFlowables.java
100% <0%> (+6.25%)
8% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


just check automatically project in English.

I work with projects in Portuguese (only) even I choosing the language to "Portuguese Pt-BR" the app only check automatically project in English.

Hey @celibertojr
Strange... Because when you choose in select multiple just Pt-BR, the extension will only get reviews in Portuguese.
Example:

hey @celibertojr  you have some news? it is working for you?

Without changes. But this kind of problem only happens when having a lot of review waiting (english)  in the queue.

okay @celibertojr. i'll do some tests.

Closed... because I don't see a problem. Thanks for your report :+1:


Handle negative and zero sizes.

Fixes https://github.com/flutter/flutter/issues/11733

Looks reasonable, but we need a test.

I think we should probably also audit the call sites. For example if we're trying to draw images at 0x0 we've probably messed up somewhere because it'd be much more efficient to not draw anything.

I agree that the call sites should be audited but I don't think I'm equipped with the knowledge what to do in each case (there are three).
https://github.com/flutter/flutter/search?utf8=✓&q=applyBoxFit&type=

And no, they don't handle zero size well but II'm sure they didn't handle Nan well either.

flutter_logo.dart: On the line after we establish canvasSize, we should early-out if canvasSize.isEmpty.
box_painter.dart: paintImage should early-out on the line before it declares outputSize, if rect.isEmpty. Also, update the documentation of the rect argument to mention that if it's empty, nothing is painted.
proxy_box.dart: RenderFittedBox.hitTest should have the same early-out as RenderFittedBox.paint. RenderFittedBox.applyPaintTransform should have two branches. If size.isEmpty, it should call transform.setZero. The else branch should be everything that's there now.

(Ideally you'd also have tests for the aforementioned changes, especially the changes to FittedBox.)


ERROR 이벤트

`
READY
events.js:292
throw er; // Unhandled 'error' event
^
Error: Error while processing packet#892660190 DECUNREAD: TypeError: Cannot read property 'Nickname' of null
at MainInterface.responseReceived (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/loco/loco-interface.js:85:19)
at LocoSecureSocket.dataReceived (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/loco-socket.js:76:27)
at LocoPacketResolver._write (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/stream/loco-packet-resolver.js:37:29)
at writeOrBuffer (internal/streams/writable.js:358:12)
at LocoPacketResolver.Writable.write (internal/streams/writable.js:303:10)
at LocoEncryptedTransformer.ondata (internal/streams/readable.js:719:22)
at LocoEncryptedTransformer.emit (events.js:315:20)
at addChunk (internal/streams/readable.js:309:12)
at readableAddChunk (internal/streams/readable.js:284:9)
at LocoEncryptedTransformer.Readable.push (internal/streams/readable.js:223:10)
Emitted 'error' event on TalkClient instance at:
at NetworkManager.onError (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/network-manager.js:160:21)
at MainInterface.onError (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/loco/loco-interface.js:107:70)
at LocoSecureSocket.onError (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/loco-socket.js:131:23)
at LocoSecureSocket.onError (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/loco-secure-socket.js:69:15)
at LocoSecureSocket.dataReceived (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/loco-socket.js:82:18)
at LocoPacketResolver._write (/storage/emulated/0/Download/sellloco/vad/node_modules/node-kakao/dist/network/stream/loco-packet-resolver.js:37:29)
[... lines matching original stack trace ...]
at LocoEncryptedTransformer.emit (events.js:315:20)
$
갑자기 잘쓰다가 이렇게 오류 생기고 다시 설치해도 안되는데
패치된건가요

v3은 지원되고있지 않습니다.
이슈에 업로드하는 사진의 엑세스 토큰을 가려 주세요.


Consolidate local and cloud envs

Initial attempt to get rid of the separate local development and cloud compose definitions.
I've personally made local changes and forgotten to propagate the changes to the cloud files several times. This change attempts to remove that possible mistake by making the local dev focused environment use the same base compose file as the cloud environments.

Get rid of the verbose local env file

Turns out there's only 2! env vars that differ between the local and cloud (demo) instances

Specify local-specific idp image

Testing
To try this out locally, there's a convenience script, demo.sh which will specify the various compose files in proper order.
./demo.sh pull
./demo.sh up -d
# Optionally
./demo.sh logs -f

TODO
Updates to README

Closing in favor of a different branch. It was easier to redo changes than to rebase this PR


Add a script to generate a draft feature per spec

One of the features, the Vibration API, is added to show what this will look like.

https://github.com/web-platform-dx/web-features/pull/1215 shows what the rest of the drafts would look like.

Scrolling through https://github.com/web-platform-dx/web-features/pull/1215 I think a clear improvement would be to list which existing features include some keys defined in the spec, to make it very easy to figure out where some keys should be added to an existing feature. Over time most of these files will just contain bits and bobs that should be part of other existing features.

There are two things I want to do here:

Group into directories by standards org / working group
Generate a comment about which features already include keys from the feature

I just discussed this with @tropicadri who is interested in the draft features generation. I'd now like to land this PR as-is and instead treat the following as follow-up work in separate PRs:

Generate a comment about which features already include keys from the feature. This makes it much easier to spot when most keys for a spec are already associated with a feature.
A GitHub Actions workflow to update spec drafts weekly. It would send a PR that a human would review and merge.

Regarding grouping into directories by standards org / working group, I took a look at that and think it will be too messy to do  in a general fashion. Working groups don't have nice names that can be used as directory names, and many specs belong to multiple working groups, and some no working group or defunct working groups. All specs in a single directory is OK I think.

@ddbeck can you review this?

I'd now like to land this PR as-is and instead treat the following as follow-up work in separate PRs:
Generate a comment about which features already include keys from the feature. This makes it much easier to spot when most keys for a spec are already associated with a feature.
A GitHub Actions workflow to update spec drafts weekly. It would send a PR that a human would review and merge.

@foolip are there issues filed for these? The generated comment bit would certainly speed the workflow up.

@autonome, yes, the generated comments were added by @tropicadri in https://github.com/web-platform-dx/web-features/pull/1303.
The GitHub Actions workflow hasn't been done yet. @tropicadri are you still interested in working on that?


Prevent CommunicationsHost from taking 100% of a core

As discussed in https://github.com/sammyfreg/UnrealNetImgui/issues/2

Fixed with 2f4737522b93733f063e8374f3262f8927e60b32
Thank you for finding the cause of the issue.


docker create-react-app without installing node, npm in local system.

Because we are using Docker, we should not install node, npm, create-react-app
in our development machine, not even for generating create-react-app scaffold.
For this purpose I am using 2-step docker configuration:

In first step, we will create a simple docker container, that does only one thing, install create-react-app
and we can use it to generate create-react-app scaffold.
And second docker configuration is project specific. It will handle nodemon, npm, development servers, etc.

Build docker image for create-react-app
Because we are not installing create-react-app locally in our development machine, Let's build new docker container for it.
Dockerfile
FROM node:8.2.1-alpine
RUN npm install -g create-react-app \
                   create-react-native-app \
                   react-native-cli
RUN mkdir /app
WORKDIR /app
ADD . /app

my failed attempt to solve this problem without docker-compose

NOTE: we need to fix this problem, please help me if anyone know the solution.

build the docker image that will handle just react cli part.

docker build . -t react-cli

Once that is done, let's generate new create-react-app scaffold using this image:

docker run react-cli create-react-app myApp

EXPECTED

it should generate react scaffold app myApp in my current directory.

RESULT
Got nothing 😄 . Looks like it is generating app inside docker container.
Working Solution: using docker-compose
Because I was unable to solve it by using just docker command, I am solving it using
docker-compose.
docker-compose.yml
version: '3'
services:
  web:
    build: .
    image: react-cli
    container_name: react-cli
    volumes:
      - .:/app

Usage
Now using docker-compose we can generate our react application:
docker-compose run web create-react-app myApp

Everthing should work this time. And you should get react generated application inside myApp
directory.
If anyone knows how to use react-cli image to generate create-react-app without using docker-compose.yml file, please let me know.
Thanks

https://github.com/facebookincubator/create-react-app/issues/982

I'm not sure what relevance this has to this repository, but Docker compose is unnecessary. This is a Docker support question.
On that note, your Dockerfile is incorrect. You need to specify a VOLUME if you'd like the files to appear on your host machine.

@Timer : Thanks a lot 😄 , So, I finally fixed it. No changes in Dockerfile all we gotta do is add -v volume flag to map current directory.
So, the complete solution is if anyone interested:
Add Dockerfile to build your own image
You can remove extra packages if you don't like, or add other packages too.
FROM node:8.2.1-alpine
RUN npm install -g create-react-app \
                   create-react-native-app \
                   react-native-cli
RUN mkdir /app
WORKDIR /app
ADD . /app

Build your react-cli image
docker build . -t react-cli

Use this image to generate your react scaffold
Now we can use react-cli image to generate our create-react-app, create-react-native-app or
react-native-cli application. The important thing is, don't forget to add -v flag that points to
your current directory with docker's /app directory.
** Linux/Mac User**
docker run -v ${PWD}:/app react-cli create-react-app myApp

# confirm myApp is generated in your current directory
ls # make sure it is successful

** Windows user**
docker run -v %cd%:/app react-cli create-react-app myApp
dir # make sure it is successful

Thanks

-v also works, glad you figured it out. 👍

Thank you for pointing me to volume. That really helped.

Great!


Xcode 15.1 and visionOS support

Description
From the Xcode 15.1 beta release notes:

Fixed: When building with the visionOS SDK, TargetConditionals.h incorrectly sets TARGET_OS_IOS to 1 instead of 0. (112716373)

Reproducing the issue
We need to evaluate all places in the code where TARGET_OS_IOS and determine the right path for visionOS.
Firebase SDK Version
10.16
Xcode Version
15.1
Installation Method
N/A
Firebase Product(s)
All
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Resolved in upcoming 10.17.0 release. See #11927, #11930, #11935, #11937, #11950 and #11938 for fixes.

Thanks for the feedback @paulb777. We now migrated to SPM which works great with visionOS.


Publish 7.5-rc-5

Publish 7.5-rc-5

@bot-gradle test and merge

OK, I've already triggered a build for you.


PUP-(8598, 8622, 8635, 8640, 8641, 8657, 8676) Add Feature Deferred Type and related functionality

This adds the Deferred data type and related functionality (needed or wanted when using Deferred values).

Makes it possible to call functions (in core puppet) on the agent
Makes it possible to use a Deferred data type that is resolved by making a function call on the agent side before catalog is used
Adds (missing ability) concatenation of two Binary values.
Makes it possible to resolve a Deferred by calling it (for debugging purposes and if used as a means to do late binding call
while compiling a manifest).
Handles Sensitive flag depending on outcome of Deferred resolution (agent side)
Adds a cache to the function API in anticipation that deferred functions typically do communication and want to cache
a connection or token of some kind.

Some tests are updated as (maint) commits - that may have been required because I ran on newer Ruby version, but the changes are not harmful and works on older Ruby's as well.
Also see #6899 (Encrypted data type) which contains the same commits as this PR.
Note that this is for 5.5.x as an experimental feature - when discussed earlier it was decided that work should be done against 5.5.x to make it possible to release in the 5 series if we wanted. That may no longer be true, and if so everything needs a rebase to 6.0.

CLA signed by all contributors.

Makes it possible to call functions (in core puppet) on the agent

Is there a reason why this is limited to only core functions? What would it take for this to call the autoloader to load in custom functions defined in modules?

Superseded by https://github.com/puppetlabs/puppet/pull/6951


Is there any way to download videos or copy the share link? This would be a nice feature

Sorry, this is my first comment, just suggesting a download/copy link option. Thanks!

Here's an example where you can get the share_url
// Login... setup api
api.getPost('<user_id>')
  .then(res => console.log(res.data.share_url))
  .catch(console.log);

Adding to the comment above, the download link is available at res.data.video.download_addr (ref)


Added getter function CurrPlatFood

If agent and platform are on the same floor return the amount of food on the platform, otherwise return 0 (since agents should not know how much food is on the platform if it's not on their floor).
Summary
This PR is aiming to solve the issue #32  (Add getter function CurrPlatFood() to tower).
Additional Information
Test Plan

Have tested it with the existing agents and it works :)

I've made changes accounting for everyone's comments, thank you!

Actually... shouldn't this belong in tower.go rather than baseagent.go?
Since the amount of food on the platform is a property belonging to the tower, the getter function for that should also belong to the tower. It shouldn't be the agent's responsibility

The custagent only has access to baseagent so it needs to be in baseagent.go I believe. I think we also need to know what floor the agent is on so thats why baseagent is needed


Added/fixed some docs

Could you see if the comments I added make sense?

I'm also thinking of removing the Jaeger stuff around ReactiveChannel.receive. It's misleading, since the receive is not really what's taking so long---it's the service waiting for a message from someone else. Thoughts?


usability minors

[ ] email address is actually only a private identifier to generate the same identicon again
[ ] blank identicon changes to identicon from IP address changes to identicon from mail address -> not really intuitive on first evaluation
[x] remove comment but still hovering the button reverts to original state after ~1 second
[x] when replied to a comment, scrollIntoView doesn't work as expected (scrolled half page after document end)
[ ] when you vote multiple times on a comment, you should get a appropriate error message

Error messages should be part of https://github.com/posativ/isso/issues/673
An explanation of email addresses and what fields get used/displayed on the client side are in need of an overhaul, probably also belong in #673


Logistic (sigmoid) activation (AIV-481)

Hi
Is it possible to have logistic (sigmoid) function activation in esp-dl?
Can't find it in layers or nn folders. It is quite popular activation function, so I guess you must have some recipe how to implement it.

Sure, We will add the related nonlinear functions recently

I want it too!  used to solve a multi-label image classification problem.

Hi All,
I need to convert a model which contains the following layers: Sigmoid, Resize, Pow in order to run it on esp32-s3-eye.
Those layers currently aren't supported on esp-dl.
How do one add new layer types so that the calibrator in the quantization tool will support the above layers? I've tried but got to this "calibrator.pyd" file which I can't edit. Any workarounds?
Thx in advance,
Jonathan


feat: minimum componentize changes

This is the bare minimum changes I need to get ComponentizeJS to work on top of StarlingMonkey.

cabi_realloc as a weak symbol so it can be overridden to support the bulk deallocation strategy we use
A new script_value() on the engine, allowing to get the value of the top-level script. For a script it would be the last statement value, and for a module it is defined to be the module namespace itself.
Allowing the console console_builtin_log to be overridable as a weak symbol
Supporting cycles in the script loader (since ComponentizeJS has a cycle with its bindings module)
Removing the full path in the debug logs for script errors, showing only the base-path-relative filename
Fixing relative resolution to be parent-relative always
Adding support for RelWithDebInfo build target

I kept it to the bare minimum to avoid too much design discussion and just get a prototype together.
Feedback welcome.

You're right I just checked and the namespace properties are giving a rooting error actually, let me debug this tomorrow and update the PR with any changes to merge then.

I've now been able to get all the bindgen tests for ComponentizeJS to pass with these changes. I ended up extending the scope to a couple more items here as well.
This is ready for merge.

@tschneidereit is signed commits a requirement going forward for all contributions to StarlingMonkey?

I've gone ahead and signed all the commits here. The contents of the PR remain identical to last week.


Update design

Adjusted header, button and input styles.
Updated to us the latest versions of dat-design and dat-icons.
Preview:

LGTM!

tested locally, looking good!


Effect of attributes on the feature level classifier

Similar to work on training size, we have questions on effect of number of attributes on model:

Does the model have enough attributes
What attributes contribute how much to model metrics
Can less attributes be better in the long term

Workflow

Get a list of all attributes available for training
Increase the training attributes appending one at a time from the attributes list
Train a model with these attributes from the training dataset
Get predictions from the model on this subset of attributes from the validation dataset
Store model metrics on the validation dataset and plot

Notes

There are interesting dips in metrics when the following attributes are added to the list of attributes:

user_changesets_with_discussions_count
old_user_name_special_characters_count
feature_version
feature_has_website_old
iD
Vespucci

The metrics somewhat reach their maximum around the 20 attributes mark except for the occasional dips
I am not sure what else to read out off of this graph.

cc: @anandthakker @batpad @geohacker

What would it look like when attributes are added in order of importance for prediction instead of in the order they appear in the csv dataset?
The GradientBoostingClassifier provides a method, model.feature_importances_ that gives out scores for feature importance, the higher the score the more important the feature for predictions.

Table with 10 attributes that have the highest importance scores
Now, using the same workflow as ^, we add one attribute at a time but starting with the most important attributes to get the graph below.

Because, we have the best attributes first, the metrics very quickly reach their max value. This is something we expect to happen.
We unusually get large dips even when we are well through 50+ attributes
The dips are now for the following attributes:

feature_name_translations_count_old
place
MAPS.ME
feature_area
sport_old
office
power
railway_old
barrier_old
railway
historic
changeset_comment_naughty_words_count
public_transport_old
route

There isn't any attribute common between the list ^ and the list ^^

After increasing the dataset size, still see the unusual dips. 🤔


python 3.6 support

Python 3.6.8 is planned to be the last bugfix release for 3.6.x. Following the release of 3.6.8, we plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release.

Python 3.6.8 was released 2018-12-24. Since then no bugfix releases were done, only security fixes are provided.
I would drop 3.6 support in the 0.11.x release of aMQTT. What does everyone else think? Objections?

Easy to overlook but there is a python version check in pub_script.py and broker_script.py. Just dropping this here a s reminder.

python3.6 dropped in #62


UI issue in cart page on phone view

#5650
Fixed issue There is a UI issue in cart page on phone view.

conflicts

working fine


Collection was of a fixed size. in Sqlite InMemory provider

I have query like below:
var exist = await _context.ProductGroups.AnyAsync(pg => pg.ProductGroupTypeId == groupTypeId && pg.Title == title);

and query throw exception:
Exception message:
System.NotSupportedException: Collection was of a fixed size.
   at System.ThrowHelper.ThrowNotSupportedException(ExceptionResource resource)
   at Microsoft.EntityFrameworkCore.Metadata.Internal.ClrICollectionAccessor`3.Add(Object instance, Object value)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.AddToCollection(InternalEntityEntry entry, INavigation navigation, IClrCollectionAccessor collectionAccessor, Object value)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.ToDependentFixup(InternalEntityEntry dependentEntry, InternalEntityEntry principalEntry, IForeignKey foreignKey)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.InitialFixup(InternalEntityEntry entry, ISet`1 handledForeignKeys, Boolean fromQuery)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.StateChanged(InternalEntityEntry entry, EntityState oldState, Boolean fromQuery)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntryNotifier.StateChanged(InternalEntityEntry entry, EntityState oldState, Boolean fromQuery)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.EntityGraphAttacher.PaintAction(EntityEntryGraphNode node)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.EntityEntryGraphIterator.TraverseGraph(EntityEntryGraphNode node, Func`2 handleNode)
   at Microsoft.EntityFrameworkCore.DbContext.SetEntityState[TEntity](TEntity entity, EntityState entityState)
   at ProductGroupRepository.AddProductGroup(ProductGroupEntity productGroup) in \ProductGroupRepository.cs:line 20
   at SociaSoft.Bss.Infrastructure.Products.ProductGroupService.<AddProductGroupAsync>d__3.MoveNext() in \ProductGroupService.cs:line 26
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Products.ProductGroupCommandHandler.<Handle>d__3.MoveNext() in \ProductGroupCommandHandler.cs:line 24
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Controllers.ProductGroupsController.<Post>d__5.MoveNext() in
 Controllers\ProductGroupsController.cs:line 50
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeActionMethodAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeNextActionFilterAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Rethrow(ActionExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeInnerFilterAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeNextResourceFilter>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeFilterPipelineAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

EF Core version: 2.0.0
Database Provider: Microsoft.Data.Sqlite 2.0.0
Operating system: Windows 10
IDE:  Visual Studio 2017

@mo-esmp What do your entity types look like? Do they have fixed-size collections for navigation properties?

Here is my entity
public class ProductGroupEntity : BaseEntity
{
    public string Title { get; set; }

    public bool IsActive { get; set; }

    public int? ParentId { get; set; }
    public ProductGroupEntity Parent { get; set; }

    public int ProductGroupTypeId { get; set; }
    public ProductGroupTypeEntity ProductGroupType { get; set; }

    public ICollection<ProductGroupProvinceEntity> ProductGroupProvinces { get; set; }

    public ICollection<ProductEntity> Products { get; set; }
}

I don't have fixed size collection and query works fine with SQL Server provider.

@ajcvickers I couldn't reproduce issue in a sample but still occurring in my solution and I didn't find any reason for that or what I'm doing wrong. here is my simplified solution repo url: SqliteDemo.
just run test in AdminProductGroupTests.cs  file and error will occur in
https://github.com/mo-esmp/SqliteDemo/blob/ebe0adde69c52e72ea38418b8df75ec719812218/src/Infrastructure/Products/ProductGroup/ProductGroupRepository.cs#L25

@mo-esmp In DataContextSeed the code is creating a new array of ProductGroupEntity:
ProductGroups = new[]
{
    new ProductGroupEntity
    ...

EF navigation properties cannot be fixed sized arrays. so this needs to be changed to something like:
ProductGroups = new List<ProductGroupEntity>
{
    new ProductGroupEntity
    ...

With this change the test passes for me.


VSCodeDebugProtocol returns lowercase breakpoint paths

VSCode 0.10.6 on Mac OSX 10.11.1
Using vscode-php-debug (XDebug adapter for PHP debugging)

VSCodeDebugProtocol.SetBreakpointsArguments() returns lowercase paths for breakpoints.
XDebug expects to see a path like /Developer/Project/file.php but we're setting a breakpoint for /developer/project/file.php. This has allegedly been resolved with an option in XDebug 2.3 but as per the nature of that release, developers working on PHP <= 5.3 projects do not benefit from that fix.
I made a proof of concept change that replaces the lowercase path returned by VSCodeDebugProtocol.SetBreakpointsArguments() with the actual cwd and it resolved the issue. Alas, if it's possible without having adverse effects elsewhere, it would make sense to return the correct path to begin with instead of needing each adapter to program around this.
Original report: https://github.com/felixfbecker/vscode-php-debug/issues/8

@AndrewNatoli I've just verified that VSCode passes file paths unmodified to the debug adapter trough the SetBreakpointsArguments.source.path. So the path that you see in the debug adapter should match the path of the file on disk (If this would not be the case, debug adapters would not work on case sensitive file systems e.g. linux).

Hi @weinand,
Thanks for checking. I'm still getting lowercase paths so I'll try digging further and trying out other debug adapters then get back to you on this.

@AndrewNatoli Are you saying that if you set a breakpoint in a file "/Developer/Project/File.php" VSCode sends you the path "/developer/project/file.php" in the SetBreakpointsRequest?

@weinand Yes, that's correct

@isidorn Is this possible?

I do not see that on the latest vscode on my mac

Are the breakpoints usually sent through any custom code before setBreakPointsRequest?
Here's my source.path immediately after setting into setBreakPointsRequest.

My first directory should be "Developer," not "developer."

@AndrewNatoli this doesn't look like an OS X path since it starts with two slashes. What is your VS Code setup? Is this some shared drive?

@weinand VS Code is installed on my primary (and only) drive at /Applications/Visual Studio Code.app

@AndrewNatoli and you've launched VS Code by double clicking the app in /Applications? And what is /Developer? This looks non-standard. I don't have such a root level folder. Could you try to use a php project that lives in your home directory? Does this makes a difference?

@AndrewNatoli your primary drive is not case-sensitive, right?

@weinand Right, my primary drive it not case-sensitive.
/Developer is a leftover artifact from before XCode 4.3. I moved in and made it my document root when I was starting off.
I moved the project to my home directory.
I'm running VS Code by opening the app in /Application then testing the adapter by running
[path to vscode.app]/Contents/MacOS/Electron /Users/andrew/vscode-php-debug/testproject --extensionDevelopmentPath=/Users/andrew/vscode-php-debug/
Where /testproject is a sample php application.
Here's an interesting development. When I add a breakpoint to the PHP project, setBreakPointsRequest is hit with the lowercase and double-slashed path (//users/andrew...).
Now, in Apache (I'm using MAMP in this scenario), if I make the default host's document root /Users/andrew/vscode-php-debug/ and run a script with a breakpoint in my testproject directory, setBreakPointsRequest is hit again but this time with the correct path.
NOW, if I use an Apache virtual host and instead of accessing my app via localhost I use something like test.mygreatapp.com, when I run the script I get the lowercase, double-slashed path.

This occurs both in my home directory and my /Developer directory.

@AndrewNatoli I've tried to reproduce your setup with VSCode 0.10.6 but I'm not seeing the lower case paths:

The only difference in my setup: I did not install anything php related (so I don't have xdebug) and I don't have Apache.
But I found this: http://stackoverflow.com/questions/7699412/case-inconsistency-of-php-file-paths-on-mac-mamp
Is the problem introduced by Apache/MAMP?

Hi @weinand,
It seems to be isolated to using a virtual host with Apache. By that I mean configuring Apache to route custom hostnames like mygreatsite.com/testproject/app.php instead of localhost/testproject/app.php. I'm not sure how this could possibly have an effect on what VSCode is seeing but the difference is there.
When using XDebug, XDebug sends an "init" message that includes the server-side path of the file you are running. So it will say, "Hey, Apache and I are serving up /Users/andrew/test.php."
The adapter will then say "Hey, that's cool XDebug. Listen, my guy set a breakpoint on /users/andrew/test.php. Could you stop there if you open that file?"
So in short, the Apache side of things seem fine while VSCode's output is incorrect.
I'll try testing with a remote host in a moment.

I checked the bug report linked on that Stack Overflow post. Running their sample code did not produce the same result; the proper case is presented in paths.

@AndrewNatoli How can Apache affect VSCode? I could only imagine that some URL conversion that VSCode uses internally is affected by something like the virtual host feature of Apache. If this is the case, it will affect all debug adapters. Could you try whether you see the same issue with vscode-mock-debug?

@isidorn what code are you using to convert VSCode's internal URLs to the absolute pathnames sent to the debug adapter? Could you please help @AndrewNatoli to debug the client side of this so that we understand where paths become broken.

I would not exclude the possibility of me screwing up the paths while converting them to URIs, so the XDebug logs are not 100% credible. But the screenshots @AndrewNatoli provided indicate that the arguments from VS Code (args.source.path) are indeed lowercased. @AndrewNatoli When you debug the adapter, all communications between Code and the adapter are logged to the console, are the paths lowercased there? That would be evidence for me.
And what file system are you using?

@AndrewNatoli can you please confirm that VSCode passes lower-cased paths to the php debug adapter even if XDebug is not running and Apache was not used to hit the code.

Hey @weinand, I'll review and get back to you when I have a moment to check.

@AndrewNatoli great, thanks a lot!

Hey @weinand,
args.source.path in setBreakPointsRequest comes in properly when setting a breakpoint.

Just some further insight: while I can't explain how in the adapter the breakpoint paths were being translated to lowercase, I have yet to be able to reproduce this issue since the VSCode-to-XDebug communication has been fixed in the adapter.
I'll update this if I run into an issue again while using the adapter during my usual weekday projects, otherwise I believe this is safe to close for now?

@AndrewNatoli Thanks for looking into this again and closing it.


Reduce watch scope for reconciler-manager

The backing informer will still watch at cluster scope, but the controller-manager will pre-filter the events and only trigger reconcile for events within the specified namespace. This should reduce the number of reconcile attempts, and thus API calls made by the reconciler-manager.
Add watches for all objects managed by the reconciler-manager for the RootSync. This should allow the reconciler-manager to revert any drift on the objects it manages, at least on fields it specifies.

Extracted:

https://github.com/GoogleContainerTools/kpt-config-sync/pull/617
https://github.com/GoogleContainerTools/kpt-config-sync/pull/618
https://github.com/GoogleContainerTools/kpt-config-sync/pull/622
https://github.com/GoogleContainerTools/kpt-config-sync/pull/623
https://github.com/GoogleContainerTools/kpt-config-sync/pull/624
https://github.com/GoogleContainerTools/kpt-config-sync/pull/625
https://github.com/GoogleContainerTools/kpt-config-sync/pull/628
https://github.com/GoogleContainerTools/kpt-config-sync/pull/629
https://github.com/GoogleContainerTools/kpt-config-sync/pull/633
https://github.com/GoogleContainerTools/kpt-config-sync/pull/634

/retest
Looks like the collector failed to start due to port in use. Mighta been after a restart. I have a feeling it doesn’t always shut down cleanly.


Rephrase the match logic for interfaces monitored for package drops

OVS bridge interfaces drop packets during normal operation, generating lots of spurious alerts.  Change the regex to filter out interfaces that don't matter for packet drops.

Backported to Xena: https://github.com/stackhpc/stackhpc-kayobe-config/pull/233


Support easier scratch builds off master

You can now give master as the RELEASE_BASE parameter to use binary packages from the last successful master build (probably a nightly).  It defines success as all kola tests passing on the base amd64 image.

Okay, I added a note.


Widgets support in non-python kernels

Verify it works

deno notebooks
go notebook (might not work, not using Jpyyter lab npm packages, https://github.com/janpfeifer/gonb/blob/main/docs/demo-widgets.gif)
Others

Works as expected


[#414] Add support for JavaScript and Python bot containers in the pipelines

Addresses # 414

Note: This PR depends on PR# XXX ([# 414] Add support for JavaScript and Python bots to run inside containers).

Important: Before merging this PR, make sure to run the Cleanup Resources Pipeline to delete current Shared Resources.
Variables
Create Shared Resources Pipeline

ContainerRegistryPricingTier: new (Optional, Pricing Tier for Container Registry, default Basic)
ResourceSuffix: updated (Optional, now it only accepts alphanumeric values due to the container registry)

Deploy Pipeline

ContainerRegistryName: new (Optional, name of the Container Registry)
SharedResourceGroup: new (Optional, name of the Shared Resource Group)
ResourceSuffix: updated (Optional, now it only accepts alphanumeric values due to the container registry)

CleanUp Pipeline

ResourceSuffix: updated (Optional, now it only accepts alphanumeric values due to the container registry)

Description
This PR adds Docker Container support to the FunctionalTests pipelines.
It introduces a new Container Registry resource that will store all the bot containers, this resource is created in the Shared Resources pipeline.
The Deploy pipeline have been adjusted to build and push containers for JavaScript and Python to, and connect the App Service with the new Container Registry.
An additional stage in the CleanUp Resources pipeline has been added to remove the Container Registry.
Specific Changes
Templates:

Updated build/templates/template-bot-resources.json to support the new sharedResourceGroup parameter.
Renamed build/templates/template-python-bot-resources.json to build/templates/template-container-linux-bot-resources.json.

Added new sharedResourcesGroup parameter.
Added new parameters for setting up a container in the App Service.
Updated the App Service resource to support containers by referring which container will use and its configuration.

New build/templates/template-container-registry-resources.json file introduced to create the Container Registry.

CleanUp Pipeline:

Updated build/yaml/cleanupResources/cleanupResources.yml introducing the Delete Container Registry stage.

Deploy Pipeline:

Updated build/yaml/deployBotResources/common/createAppService.yml to receive the container configuration as optional and improved the script to be easier and maintainable.
Updated build/yaml/deployBotResources/deployBotResources.yml to include the new optional variables ContainerRegistryName and SharedResourceGroup, and to add the necessary container configuration to JavaScript and Python bots.
Updated build/yaml/deployBotResources/dotnet/deploy.yml and build/yaml/deployBotResources/dotnet/deployComposer.yml to keep consistency with the changed and use the new sharedResourceGroup parameter.
Updated build/yaml/deployBotResources/js/deploy.yml and build/yaml/deployBotResources/python/deploy.yml

Prepare Bot, Install dependencies and Deploy Azure Web App were removed in favor of just Build and Push Container

Create Shared Resources Pipeline:

Added new ContainerRegistryPricingTier variable to let the user choose between Basic, Standard and Premium price tiers for the Container Registry.
Added Create Container Registry stage to create the Container Registry.
Updated Create App Service Plan (JS) to create a Linux App Service Plan instead.

Testing
The following images show a high level diagram of how the flow is made and the pipelines passing successfully.

@ceciliaavila thanks, I fixed the typos, also added the same description for Test Scenarios that I missed.

Branch containing the pipeline runs https://github.com/southworks/BotFramework-FunctionalTests/tree/joelmut/test/containers-main.

Promoted to MS in PR# 436


Should I use this in the "real world"/production yet?

Sorry for the big noob question here. I know turbopack is the new kid on the block, but if you're deploying on vercel anyways they ought to support that right? In what scenarios should I ignore turbo?
This question might be less about this template more so "how do I pick a technology thats good and will grow with me" sort of thing. Sorry if that's the case.
Thanks in advance.

Yep - I've been using it as my primary for 2 projects for nearly 2 months - so my projects are about 250 commits ahead of this. However I didn't use Next Auth and am yet to do much with Expo, I chose this base as a native app was going to be necessary down the line.
However, if you don't need that (suspect you won't) I'd go with the https://github.com/t3-oss/create-t3-app which is a bit less complex to get going as it's not split up as much.

I have it set up with supabase auth and eventually we are going to make a mobile app, so this template would be pretty clutch.


CIRIquant test fails since commit 72dd514, PR #104

Description of the bug
I'm running into a ciriquant error since #104, specifically after this commit 72dd514.
Reproducible by checking out that commit and running the test data
git checkout 72dd514cc90d19797bf3869b9427d879677582f6
nextflow run circrna -profile test,docker,arm --tool ciriquant
Error:
 Traceback (most recent call last):     File "/usr/local/bin/CIRIquant", line 10, in <module>       sys.exit(main())     File "/usr/local/lib/python2.7/site-packages/CIRIquant/main.py", line 89, in main       config = check_config(check_file(args.config_file))     File "/usr/local/lib/python2.7/site-packages/CIRIquant/utils.py", line 107, in check_config       raise ConfigError('Could not find hisat2 index with suffix: *.[1-8].ht2 or *.[1-8].ht2l, please check your configuration')   CIRIquant.utils.ConfigError: Could not find hisat2 index with suffix: *.[1-8].ht2 or *.[1-8].ht2l, please check your configuration
When reverting back to commit c4a3e8e (one commit earlier), this error does not occur, and the CIRCRNA_DISCOVERY:CIRIQUANT processes end successfully. (Another error occurs later in the pipeline but I think this is not important here.)
@nictru , tagging you as you might have a better understanding of the changes :)
Command used and terminal output
No response
Relevant files
No response
System information
No response

I tried to look a bit closer at this bug. It's a bit annoying to reproduce as there are multiple bugs (some of which are already resolved in the newer version of the pipeline). But I think it comes down to this:
Before commit 72dd514, the creation of the yaml file included this
in script:
hisat2_prefix = fasta.toString() - ~/.(fa|fasta)$/
and then further
printf "name: ciriquant\ntools:\n  bwa: \$BWA\n  hisat2: \$HISAT2\n  stringtie: \$STRINGTIE\n  samtools: \$SAMTOOLS\n\nreference:\n  fasta: ${fasta_path}\n  gtf: ${gtf_path}\n  bwa_index: ${bwa_path}/\$BWA_FILE\n  hisat_index: ${hisat2_path}/${hisat2_prefix}" >> travis.yml
when looking at the created file travis.yml:
hisat_index: /Users/marieke/Documents/ciriquant/work/e4/16de17aae2f6a3e21f4454b48a54bb/hisat2/chrI
However, with the commit commit 72dd514, line 22 in this script changed to
hisat2_prefix = meta2.id  taking form the input tuple val(meta2), path(fasta) where meta2 just contains the word fasta and therefore the travis.yml file then contains:
hisat_index: /Users/marieke/Documents/ciriquant/work/e8/aebdbd37ab6875b8dfa62c0e7e9d4b/hisat2/fasta
Which is I think the cause of the error mentioned above

Looks plausible, we should revert the change in line 22 in this case - thanks for pointing this out


Use InitializationOptions instead of flags to drive capabilities

At present there are 2 flags to the go-langserver that control features of the language server

gocodecompletion
func-snippet-enabled

One can easily imagine other configuration options we would want to have down the line that controls other features. One such is already being discussed in https://github.com/sourcegraph/go-langserver/issues/272#issuecomment-387347100 which is about the  tool to use for formatting i.e gofmt vs goimports
InitializationOptions is something sent to the server from the client which seems like a much better place than flags to control/configure features. Adding more flags to go-langserver itself doesnt scale.
cc @keegancsmith @slimsag

My another concern with flags is that when new flags get added, there is no clean way for the client to know if the user has the version of the language server that supports the said flag. The only way to do this would be to parse the output of go-langserver -h and look for all the supported flags


TypeError for plugin

<EMAIL_ADDRESS><EMAIL_ADDRESS>I get the following error, when calling the plugin method for my schema:
TypeError: fn is not a function
    at Schema.plugin (/node_modules/mongoose/lib/schema.js:1139:3)
    at Object.<anonymous> (/app/models/user.js:211:12)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)

Hello @timargra, sorry for the delay in answering your question. The tests successfully passed with Node.js 6.7.0 and mongoose 4.8.6 on my machine. I’m using MongoDB 3.4.6. Can you provide a minimal example of failing code, please?

I am going to close this. @timargra, if you still encounter the problem, please feel free to re-open the issue. Please consider adding more details to your issue so that we can reproduce the bug and help you.


Explain reasoning for duplicate content in the structure

The current suggested structure includes policy.json, policy.parameters.json, and policy.rules.json.
The policy file includes sections for parameters and rules; and the content of these in all examples I've seen typically duplicate exactly what's in the .parameters and .rules files.
To me it would make sense to only maintain these definitions in one place; then if a different format were needed use scripts to generate these other files; but to avoid including that generated content under source control (i.e. only include the single definition file and the scripts to perform the conversion).
I couldn't see anything in the document explaining why we may wish to have this duplication / if some of the content is expected to be generated, but included in the .gitignore file to prevent it from being tracked in the repo itself.  Please could something be added to clarify this?

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

ID: 50f6b34e-7ed0-5ecd-6cf4-192e7393663c
Version Independent ID: cb186c12-22a3-5ac4-667c-b1d07ab5f566
Content: Design Azure Policy as Code workflows - Azure Policy
Content Source: articles/governance/policy/concepts/policy-as-code.md
Service: azure-policy
GitHub Login: @DCtheGeek
Microsoft Alias: dacoulte

@JohnLBevan Thanks for the question! The structure is partially to help with some of the SDK functions that take those components as a standalone file. For example, in Azure CLI the command for creating a policy assignment, az policy assignment create, uses a params (or p) parameter that expects a JSON string or path of just the parameter node. While you could add extra steps in your pipeline to shard the "core" file that has this information, the team felt it was a cleaner path to have each file used as part of the source.  I'll ping one of the PMs to see if this approach still holds.
#assign:DCtheGeek
#label;"product-question"
#label:"triaged"
#label:"assigned-to-author"
#label:"in-progress"

#label:"product-question"

Confirmed that this approach still stands and is recommended.  I'm going to close this issue now.  Feel free to open a new Issue for any Docs issues you see.  Thanks!
#please-close


install new relic

anyone install newrelic on your server? how do you do it?

Also wondering...

Yes I have and I will explain in my next post as it will take me a little bit to write it :-)

Ok so to start the system monitoring tool needs to be installed on your base machine as this will monitor the docker instances as well so go ahead and follow the new relic docs for that one. Small note the new relic server monitoring tool is being removed soon so if you have a paid account go ahead an install the infrastructure stuff instead.
For APM you will want to first edit you php-fpm Dockerfile-{VERSION} file and insert the below code in just above the final touch section.
# install newrelic apm agent
ENV NEWRELIC_FILENAME=newrelic-php5-<IP_ADDRESS>-linux-musl.tar.gz
ENV ENVIRONMENT {APP NAME GOES HERE}
ENV NR_INSTALL_SILENT true
ENV NR_INSTALL_KEY {LICENCE KEY GOES HERE}

RUN cd /opt \
    && apt-get install -y wget --no-install-recommends \
	&& wget -O - https://download.newrelic.com/548C16BF.gpg | apt-key add - \
	&& sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-free" > /etc/apt/sources.list.d/newrelic.list' \
	&& apt-get update \
	&& apt-get install -y newrelic-php5 --no-install-recommends \
	&& newrelic-install install

Then rebuild you nginx container and new relic should be installed and monitoring.
If you have multiple site running then you will want to edit you nginx site config and add the code below into each of the location ~ .php$ sections for each site
fastcgi_param PHP_VALUE "newrelic.appname={SITE NAME}";

@Shadow2004 when I run your script in my php-fpm dockerfile I get this error:
Cannot write to '-' (Broken pipe). . Any Idea why?

@Shadow2004 when I run your script in my php-fpm dockerfile I get this error:
Cannot write to '-' (Broken pipe). . Any Idea why?

I've faced with same problem. Fixed by adding:
apt-get install -y apt-transport-https gnupg
  apt-get install -y wget --no-install-recommends \
   && apt-get install -y apt-transport-https gnupg \
   && sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-free" > /etc/apt/sources.list.d/newrelic.list' \
   && wget -O- https://download.newrelic.com/548C16BF.gpg | apt-key add - \
   && apt-get update \
   && apt-get install -y newrelic-php5 --no-install-recommends \
   && newrelic-install install \


fix typo

Thanks for this document, it was useful. Spotted a typo, thought I'd offer a small fix. Thanks!

Docs Build status updates of commit e726c40:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Odata-docs/webapi/skipToken-for-server-side-paging.md
:warning:Warning
View
Details

Odata-docs/webapi/skipToken-for-server-side-paging.md

Line 2, Column 1: [Warning-author-missing] Missing required attribute: 'author'. Add the current author's GitHub ID.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

(sorry about the close and reopen, just a slip of the keyboard)


Add README and LICENSE

I migrated HowToWriteTests into the README.md

There are some content changes I'd like to suggest -- should those go into a separate PR, though?

I think content changes should go into its own github issue and/or a PR. If you're satisfied with it otherwise, go ahead and approve the PR!

LGTM. GitHub is not giving me the option to approve the review, so I'll just merge it.

I don't see the license actually applied anywhere, just the LICENSE file.  I think at the bottom of the readme, you should have the actual license and copyright wording.

I don't think that's strictly necessary, GitHub automagically slurps LICENSE or LICENSE.md files:
https://help.github.com/articles/adding-a-license-to-a-repository/
HTCondor-CE does it this way

It is indeed best practice to add it to individual files - but I think that adding a license to the repository itself is a fine (sufficient?) first step.

Sure, but there is no copyright notice anywhere.  Isn't that part of the point of a license file?

Copyright and licensing are a bit orthogonal (unless the author signs over the copyright as part of the code submission).
It is indeed traditional to have a copyright statement in the LICENSE file, but that made a lot more sense in the case where there was a clear single owner of the copyright (i.e., "Board of Regent, University of California").  Makes less sense for distributed projects


feat: calls to non-existent contracts in the AVM simulator return failure

#10051  👈 (View in Graphite)
master

This stack of pull requests is managed by Graphite. Learn more about stacking.


Add rfft op

Description

FEATURE
Add rfft op. Please see https://github.com/tensorflow/tfjs/issues/782

For repository owners only:
Please remember to apply all applicable tags to your pull request.
Tags: FEATURE, BREAKING, BUG, PERF, DEV, DOC, SECURITY
For more info see: https://github.com/tensorflow/tfjs/blob/master/DEVELOPMENT.md

This change is

Sorry I meant this: https://www.tensorflow.org/api_docs/python/tf/spectral/irfft
The real-valued inverse FFT.

I see. Sure I can.


Update mdeasm_workbook_template.json

fixes invalid JSON structure in previous PR

@ajkallur FYI - previous commit had bad JSON

Ok will check and merge.

Regards,
Ajay
[Logo, icon  Description automatically generated]
Ajay Kallur (he/him)
Senior Product Manager
MDEASM & MDTI CxE
Unified Security Intelligence
<EMAIL_ADDRESS>From: Josh Randall @.>
Sent: Tuesday, May 9, 2023 5:15 PM
To: Azure/MDEASM-Solutions @.>
Cc: Ajay Kallur @.>; Mention @.>
Subject: Re: [Azure/MDEASM-Solutions] Update mdeasm_workbook_template.json (PR #12)
@ajkallurhttps://github.com/ajkallur FYI - previous commit had bad JSON

Reply to this email directly, view it on GitHubhttps://github.com/Azure/MDEASM-Solutions/pull/12#issuecomment-1540957158, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AX2GPXZF7TM5JE7ZUPBWTE3XFK6VVANCNFSM6AAAAAAX34TO7I.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


NonStop fails to build libcrypto.so for overlong CC argument list

This is essentially a similar root cause on NonStop as #12116 where the number of objects supplied in the construction of libcrypto.so exceeds the capacity of the platform.
I was able to MacGyver the Makefile (which is not sustainable) to create a libcrypto.so instance using:
        echo providers/libcrypto-shlib-baseprov.o >> libcrypto.in
        echo providers/libcrypto-shlib-defltprov.o >> libcrypto.in
        echo providers/libcrypto-shlib-nullprov.o >> libcrypto.in
        $(CC) $(LIB_CFLAGS) $(LIB_LDFLAGS) \
                -Wshared \
                -o libcrypto.so \
                -Weld_obey=libcrypto.in \
                providers/libimplementations.a providers/libcommon.a providers/libnonfips.a  $(LIB_EX_LIBS)

If the linker is used directly, as configured, we could just supply the libcrypto.a, presumably, instead of constructing the list of objects.

Darn.  I suspect this will also hit the same mingw builds that already had issues of this sort when building static libraries.
The only viable solution I can see is to go back to linking from static libraries, and work out the different options to tell the linker to grab everything from the static library.  We did this previous to OpenSSL 1.1.0, but I abandoned that method because keeping track of those options felt dodgy.

FYI, I've plans to work quite a lot on the build system as soon as we've released the first beta.  Right now, I'm much too busy with stuff that need to happen before we have a feature freeze.

FYI, I've plans to work quite a lot on the build system as soon as we've released the first beta. Right now, I'm much too busy with stuff that need to happen before we have a feature freeze.

That's cool. We just released 1.1.1g to our community. I think we have a little time before there's clamoring for 3.0.x. Besides, I need to work on a solution to enabling FIPS on the x86 platform variant. The Itanium variant won't have it for the foreseeable future.

Information only: Just tested this on commit 67ecd65cc4, which still has this problem.

I came to this today, and considering I haven't found the time to do the build system revamp that I want, I went with a kinda sorta hack.  Another config attribute, shared_argfileflag, will be good enough.  That will not only solve this problem for NonStop, but for Mingw as well.

Hmm, when looking into this, I discovered that you don't seem to encode version information into shared libraries.  How does it work on NonStop when you want to upgrade a library where the ABI differs (i.e. a "library bump")?

Hmm, when looking into this, I discovered that you don't seem to encode version information into shared libraries. How does it work on NonStop when you want to upgrade a library where the ABI has gone through incompatible changes (i.e. a "library bump")?

Do you mean from something like 1.0.2 to 1.1.1 or 1.1.1 to 3.0.0?

Do you mean from something like 1.0.2 to 1.1.1 or 1.1.1 to 3.0.0?

Yes.
The common way on most Unix systems is {libname}.so.{libversion}.  On Windows, there's no common standard, so we went for {libname}-{libversion}.dll (well, not just that, but close enough for the purpose of this discussion).

Do you mean from something like 1.0.2 to 1.1.1 or 1.1.1 to 3.0.0?

Yes.
The common way on most Unix systems is {libname}.so.{libversion}. On Windows, there's no common standard, so we went for {libname}-{libversion}.dll (well, not just that, but close enough for the purpose of this discussion). Something similar could be done for NonStop.

There is no standard mechanism for the NonStop loader. It looks for the DLL by exact name and does not accept a suffix version. We are currently using entirely different paths for OpenSSL because of the locations of engines and certificates. So something like /usr/local historically for 1.0.2, /usr/local-1.1 for 1.1.1, and this one will be /usr/local-3.0.

There is no standard mechanism for the NonStop loader. It looks for the DLL by exact name and does not accept a suffix version. We are currently using entirely different paths for OpenSSL because of the locations of engines and certificates. So something like /usr/local historically for 1.0.2, /usr/local-1.1 for 1.1.1, and this one will be /usr/local-3.0.

Okie, that's workable (and of our hands, then :wink:)

There is no standard mechanism for the NonStop loader. It looks for the DLL by exact name and does not accept a suffix version. We are currently using entirely different paths for OpenSSL because of the locations of engines and certificates. So something like /usr/local historically for 1.0.2, /usr/local-1.1 for 1.1.1, and this one will be /usr/local-3.0.

Okie, that's workable (and of our hands, then 😉)

I actually put together a whole webinar about this ;)

Not a good result here. The generated command was close, but there needs to be :
c99 -g -O0 -Wextensions -Wnowarn=203,220,272,734,770,1506 -Wbuild_neutral_library -Wverbose -Wtarget=tns/e -Wsystype=oss -Wilp32  -L. -Wshared -Weld="-export_all" -Weld="-set systype oss" -Weld="-set floattype neutral_float"  \
        -o libssl.so \
        -Weld_obey=libssl.so.args \
        -lcrypto  -lrld -lfloss
c99: error: No input file.
c99: Exiting with status 1; 1 error(s).

This is a c99 issue.

Can we discuss the PR in the actual PR?

Can we discuss the PR in the actual PR?

I keep doing that. Sorry.

There is no standard mechanism for the NonStop loader. It looks for the DLL by exact name and does not accept a suffix version. We are currently using entirely different paths for OpenSSL because of the locations of engines and certificates. So something like /usr/local historically for 1.0.2, /usr/local-1.1 for 1.1.1, and this one will be /usr/local-3.0.

Okie, that's workable (and of our hands, then 😉)

I actually put together a whole webinar about this ;)

As a side-bar, we find that there are still versioning issues even with version affinity in Linux. The memory and threading models do not get resolved correctly. On NonStop this is a huge issue, many different builds being needed. That further confuses "DLL Hell". My webinar is here. Understand that was done for the NonStop audience.

@levitte I'm not sure everything got merged yet on this one. If so, I think something got missed. I'm at commit 21e5be854d.

I'm not sure everything got merged yet on this one

No, #12960 and #12962 are still in the merge waiting queue.
Dunno if you're aware, but we implement a 24h grace period starting from the approval, so that everyone has a chance to see what's going on, and comment if they have anything to say.  Since we're spread around the globe, we can't in good conscience make it shorter.  So those two are going in tomorrow (in the morning for me).

I'm not sure everything got merged yet on this one

No, #12960 and #12962 are still in the merge waiting queue.
Dunno if you're aware, but we implement a 24h grace period starting from the approval, so that everyone has a chance to see what's going on, and comment if they have anything to say. Since we're spread around the globe, we can't in good conscience make it shorter. So those two are going in tomorrow (in the morning for me).

Great to know. I'm still trying to get my hardware randomizer through (PR #12923) but getting loads of push back.


TabMon per-host Counters.config

Hi,
Is it possible to configure TabMon to monitor Tableau hosts and generic Windows hosts at the same time without the resulting unavailable counter errors i.e. exclude MBean counters for select hosts or specify a different Counters.config file per host/cluster?
If not, could I make this a feature request please?
It would be handy to be able to collect host stats from our Tableau cluster and other ancillary hosts within the same tool. Thanks.

Currently it's not possible to load specific configuration files for different hosts/clusters. Pointing TabMon at different (Non-tableau) hosts will work. The only side affect you will see is an inability to load the MBean counters in the log files.
I'll mark this as a feature request.
-Dan


Fix mypy warnings

Summary
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 8 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 90.721%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
3373

Relevant Lines:
3718

💛  - Coveralls


Add chapter translate

If I'm not mistaken there is a translation at line 102 on translations/fr/03-everyday-git.md.

yep, i missed that one.
merging but leaving in a separate branch if anyone wants to push further.


The tests in test_visualization.TestLatexSourceGenerator test all the same (shallow) thing

The tests in TestLatexSourceGenerator (living in test/python/test_visualization.py) test that the visualizer creates the file when called with a filename. Nothing else, which is a very low bar. They all seem to test the same thing.
What is the expected enhancement?
It's okay if one test checks that the file is created. The rest should also check that the result is expected. Random generation of input in the test should also be avoided (see #205). In addition,  tearDown can be used to remove the generated file.

I would like to deal with this as with good first issue: I see that there are still no tear downs, tests are still random and test suite still checks only the existence of files.
@1ucian0, could you please give me brief instructions: is there is something to discuss or I can simply start working on issue?
Thanks!

@1ucian0 Sorry if I distract you, but I will make one more mention of you. Thanks in advance!

Thanks for the second ping! (I missed the first one). It seems you have a
good grasp on the problem here so fell free to start working on it and we
can polish it as a PR.
Thanks for your contribution and let me know if you have any questions
On Dec 14, 2018 12:39 AM, "Aleksei Malyshev"<EMAIL_ADDRESS>wrote:
@1ucian0 https://github.com/1ucian0 Sorry if I distract you, but I will
make one more mention of you. Thanks in advance!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Qiskit/qiskit-terra/issues/1186#issuecomment-447219943,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAuy5Tk8-jmLwXtoVnsAHhbTJ3L2fQeoks5u4zmmgaJpZM4YHAx4
.

@1ucian0 Okay, I start working on it. However, I have an instant question: in the test/python/tools/visualization/test_visualization_output.py I see that there is already test for latex_circuit_drawer which compares the output of drawer under the current version with the reference output which is exactly the test I wanted to start with.
Moreover, a latex_circuit_drawer is tested there whilst in the test_visualization.py a circuit_drawer with an output set to 'latex_source' and seems that it is quite messy.
Shall these two be merged into one? Or I do not understand something and it is okay?
Thanks!

latex_circuit_drawer is the deprecated function that will be removed. Moving forward the only function will be circuit_drawer with different outputs set via the output kwarg. We just haven't updated the tests yet because both paths call the same functions. If you want to make everything use circuit drawer as part of your improvements that'd be awesome.

If you want to make everything use circuit_drawer as part of your improvements that'd be awesome.

Thanks a lot, now it is clearer to me. Then, I start and I will use only circuit_drawer as you said and do my best)

@1ucian0 @mtreinish I have the following question: I see that in fact there are also tests on _text_circuit_drawer in the distinct file. Is the _text_circuit_drawer also deprecated? If so, shall I refactor all the circuit visualization test suite such that it will check all drawers (mpl, latex and text) as a part of _circuit_drawer with different inputs? Thanks!

Oh, and I see that #300 is also devoted to this problem. Are you still in touch with @youngchuleta? Won't we work simultaneously on the same part of code? Thanks once again!

This meta testing (same set of inputs to multiple "backends") is something that we have to do in many parts of Terra. It would be interesting to see you approach :)

@1ucian0 As far as I know, the Pytest library already deals with such things) But, am I right that only unittest shall be used?

Closed via #1617

Reopen, because #1617 was reverted by #1780.

TestLatexSourceGenerator should be tested against a reference source, like test.python.visualization.test_pass_manager_drawer.TestPassManagerDrawer


added logic to support nvim-possession if present

Add support for nvim-possession

The statusline will then look like the following:

P. S. I have added a stylua.toml because my formatting did not coincide with yours, to avoid a git diff of the entire file. You can remove such file if you have your own in place.

Looks good.


Rename Langchain4j property placeholder to follow the traditional syntax

Description

Target

[x] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[ ] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[x] I checked that each commit in the pull request has a meaningful subject line and body.

[x] I have run mvn clean install -DskipTests locally and I have committed all auto-generated changes

/component-test ai qadrant milvus pinecone

/component-test ai qdrant milvus pinecone


Request: Hidden on size xx

Hello,
Would it be possible to implement a new helper?
Hidden div on small, medium, large or, xl.
Or only visible div on small, medium, large or xl.
Thank you.

Hi Zanoshky,
have you tried the "s", "m" and "l" helper? They help with responsive design. An element, that has the "s" class, is only visible on small displays, e.g. smartphones, "m" on medium displays, e.g. tablets and small laptops, and "l" on large screens, e.g. desktop PCs. They can also be combine, so something is not visible on small screens, but on medium and large screens (give that element the "m" and "l" class).
Hope, I could help you with that 😊


Rebuild for gfortran 7 for OSX (fixed)

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Closes #6

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge/dioptas This PR is ready to merge!

bump here!

@conda-forge/bot Can one of you merge this?