Post-deploy false by default?

Is there a reason why post-deploy scripts are disabled by default?

Mind if we turn it on by default now?
On Fri, Oct 21, 2016 at 1:51 PM Dmitriy Kalinin
<
mailto:Dmitriy Kalinin<EMAIL_ADDRESS>
wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }
https://github.com/lnguyen
most of the larger features are not enabled by default as they get rolled out. this fell into that category.
—
You are receiving this because you were mentioned.
Reply to this email directly,
https://github.com/cloudfoundry/bosh/issues/1486#issuecomment-255433233
, or
https://github.com/notifications/unsubscribe-auth/AA4rDIrraWZ8paTnG9RDRTwNCwWpb4M5ks5q2PubgaJpZM4KcxNz
.

@lnguyen we could switch it on in the next few releases.

@lnguyen could you provide more context on your use case for having it on by default? Could you share which releases you're relying on for this functionality?

I think this should be enabled by default @mfine30 since there isn't a reason for it not to be.
To opt into this lifecycle event you must do two things: script and enable the flag. If it were on by default, omitting the script would be the same as the default being disabled.
Additionally, bosh-deployment ships with enable_post_deploy: true.

It defaults to true now. https://www.pivotaltracker.com/story/show/161970878


Official Dev Kit

Could this help us develop further?
https://www.appleworld.today/blog/2017/6/7/apple-opens-homekit-protocol-specification-to-all-developers

Link to official spec: https://developer.apple.com/homekit/specification/

never expected this to happen :)
there is a Color Temperature characteristic documented that is not included in HomeKitTypes.js from HAP-NodeJS. unfortunately it is not useable if a light also supports Hue and Saturation :(
the new services and characteristics that should appear in iOS 11 are not yet included in the document.

Could this help us develop further?
https://www.appleworld.today/blog/2017/6/7/apple-opens-homekit-protocol-specification-to-all-developers
Maybe I'm wrong but I think this makes homebridge useless.

@ooii only for those who can understand how to build it from the ground up.  For the rest of us, we can help contribute by troubleshooting but depend on developers to create necessary plugins for items like wemo devices, nest integration, existing security systems, people occupation via pings, etc.  :) I think this just helps build homebridge in a stronger and more understood way with help from Apple Documentation :D

You're probably right. Maybe it will make homebridge better.

I think it will make Homebridge better for the most part or B) totally remove the need of Homebridge since more Companies would be willing to adopt HomeKit protocols.
On Jun 7, 2017, 12:47 PM -0700, ooii<EMAIL_ADDRESS>wrote:

You're probably right. Maybe it will make homebridge better.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Now if only they'd release the airplay/airplay2 spec!
Cheers,
Anthony
On 8 June 2017 at 06:29, AppleTechy<EMAIL_ADDRESS>wrote:

I think it will make Homebridge better for the most part or B) totally
remove the need of Homebridge since more Companies would be willing to
adopt HomeKit protocols.
On Jun 7, 2017, 12:47 PM -0700, ooii<EMAIL_ADDRESS>wrote:

You're probably right. Maybe it will make homebridge better.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nfarina/homebridge/issues/1328#issuecomment-306915242,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABaYCwQXxYCMr5NufM2YB9TKQPD95rDEks5sBwgygaJpZM4NzDIM
.

It's important to note that this spec is for non-commercial use, so the fact that it's released doesn't necessarily fix all the issues that device manufacturers have with HomeKit.
It does seem to be designed to allow tinkerers (i.e., us) to build things that properly work with HomeKit without relying on reversed engineered hacks, or having to go through the commercial licensing steps.
Either way, seems to be a step in the right direction toward making community projects like Homebridge more feature-complete :)

@RXM307 Apple have published AirPlay 2 API to make the client-side available for third parties
https://developer.apple.com/airplay/
Server-side of AirPlay is of course still fully closed and its encryption not been reverse engineered since iOS9.

@nfarina - may i request that this issue be closed and that people are asked to continue the discussion at https://github.com/KhaosT/HAP-NodeJS/issues/457 ??? thanks!

Please continue discussion at KhaosT/HAP-Nodejs#457 as this is not an issue specific to Homebridge rather the underlying protocol system,HAP

@justme-1968 that's not true about ColorTemperatute. I've implemented it for my LIFX platform and it works perfectly if Hue and Saturation are also defined.

@devbobo that is good to hear. but the documentation clearly says otherwise. where did you get the uuid from? as far as i can see it is currently not included in HAP-Nodejs HomeKitTypes.js.

@justme-1968 I generated a new HoneKtTypes.js myself after downloading the latest HomeKit simulator

https://www.theverge.com/2017/6/8/15761800/apple-homekit-updates-ios-11-easier-build-requirements-wwdc-2017
"On top of these updates to make building HomeKit devices easier, Apple is also expanding what HomeKit can do in ways that consumers will notice. It's adding two new categories of supported products, sprinklers and faucets, and it's adding a bunch of new ways to trigger actions at home.
One of the simpler updates, but a favorite of mine, is an enhancement to the sunrise and sunset triggers. Those can now be offset by some amount of time, so you could, for instance, have the lamps in your home turn on shortly before the sun goes down at night.
Apple is adding temperature triggers, too, so that events can be kicked off when the temperature goes above or below a certain point. And it's getting better at tracking when people are in the house. It'll now track specific people, instead of individual devices, and use that to better tell you when someone leaves or arrives home. In iOS 11, that'll allow HomeKit users to set things to happen when the last person leaves the house or when someone's arriving home to an empty house.
There will also be a way to temporarily turn on certain devices. Apple gave the example of opening a door at night and having outside lights turn on for just a few minutes, instead of turning on and staying on as they’d have to currently."
Nice!

FYI; @pdlove  updated the HomeKitTypes.js on his fork last night: https://github.com/pdlove/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js
That look to have everything that is new from Apple's Homekit Accessory Simulator. What the values actually mean are in their public documentation. Color temperature is in Mires and not Kelvin. The conversion is in their doc.


Memory leak caused by not having a collecting stage for handles.

TFTensor leave behind a pinned object that cannot be garbage collected.
Initialize a tensor from an array and let the garbage collector collect it. Data array is still pinned afterwards.
The error is in TFDisposable.Dispose. The line
if (disposing)
should be removed.
See https://stackoverflow.com/questions/898828/finalize-dispose-pattern-in-c-sharp how to correctly implement the dispose pattern.

The problem is that fundamentally, this assumes that releasing objects is a thead-safe operation, and it is not clear to me that they are.
The reason for the guard on dispose is that it prevents objects from being released on the Finalizer thread, now I think that you have a solid claim that this is a problem.    Applications with a mainloop are able to come up with a proper solution by "queuing" operations on the main thread.
The issue with TensorFlowSharp is that it is rarely used in a form that uses a mainloop, so we can not rely on this.
What I think the proper fix is, is that if Dispose=false, we should queue the handle for proper disposal on the thread running the code.   Something like:
if (!disposing)
    handles_to_dispose.Add (handle);

Then provide a method that is called in assorted places:
void DisposePendingObjects ()
{
   if (handles_to_dispose.Count > 0){
      foreach (var h in handles_to_dispose) h.TF_Release (h);
     handles_to_dispose.Clear ();
   }
}

And then call this from various places.

Well, my bad, I forgot I had done the research on this before.
TFTensors are disposable from a background thread, so they subclass TFDisposableThreadSafe, which does not have the "if (disposing)" pattern in place.
Generally, the "Dispose" pattern with unmanaged resources guidance is only valid when the unmanaged resource can be safely disposed from a thread.   This is not always the case, I will suggest that we fix this in our documentation.

Ok suggested a fix for our documentation:
https://github.com/dotnet/docs/pull/9416
That said, the issue that you are experiencing must be different, perhaps not draining the finalizer queue fast enough, because the finalizer already has the call there.
So my suggestion to drain the queue as described still applies.

Reopening becasue this optimization is still worth doing, and would solve some surprises that happen when loading a lot of data in a tight loop and the GC has not executed.

Actually, without the GC running the optimization is worthless.
I am at a loss as to how we could solve this (and there is a similar issue filed, which is why this raised on my radar)


Add Windows MKLDNN Building Instruction

Description
This is a raw instruction for windows users to build mxnet with mkldnn from source. The process is quite tedious and still needs some optimization.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@pengzhao-intel @zheng-da

yes you are right. I will optimize this instruction and test locally first. Thanks for suggestion：）

i am fixed it https://github.com/apache/incubator-mxnet/pull/10629

@yajiedesign Good J:) I think it is very helpful to simplify my workflow!

@zheng-da @marcoabreu I've modify the install readme according to @yajiedesign 's PR #10629 .

@marcoabreu hi, please help review this pr. Thanks!

It looks good to me. @marcoabreu do you have more comments for this PR? If not, could you please merge it?


Generate index?

This works nicely, thanks!
Any ideas on how to generate and append an index with links to all titles/headers from the content?

Do you mean automatically generate PDF outlines/bookmarks?
This can be done by adding pdfOutlines to the configuration file, which defaults to true.
I hope I understand you correctly.

Hm yes, it's actually already there, I see.
I should maybe do some searching to find a library which can insert the outline as a complete table of contents directly on the first / second page, or something like that (for PDF noobs like me, who didn't really realize the outline already was here). I'm aware of VitePress' [[toc]] tag, but that only generates a per-file index.

I see, yes, that was what I was looking for.
However, as the outline is already there and follows PDF standards, that's probably a minor issue. What's more useful is probably a way of generating some form of index / list of terms at the very end. But that's another issue, and probably a hard/impossible thing to do, requiring some way of indicating which terms to actually list in the Markdown source.
Thank you for your help and for replying so quickly.

One of the best pieces of advice I have heard in a long time 👍🏻😁


add manually triggered workflow for acceptance tests

Description:

Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report
Patch and project coverage have no change.

Comparison is base (e79b993) 75.70% compared to head (ac0bcf2) 75.70%.

:exclamation: Current head ac0bcf2 differs from pull request most recent head 2633d8b. Consider uploading reports for the commit 2633d8b to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1306   +/-   ##
=======================================
  Coverage   75.70%   75.70%
=======================================
  Files          32       32
  Lines        2412     2412
  Branches      480      480
=======================================
  Hits         1826     1826
  Misses        439      439
  Partials      147      147

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@Ivo-Yankov should be able to resolve items and check in what you've achieved so far. We can follow up with PRs since it won't run automatically


Include an ID in service message requests to wallets

Problem
Currently when calling a service multiple times there is no way to know which message responds to which thread.
Solution
Add and populate an ID field to the message that will also be in the response body of the message returned from the wallet. This would correlated the location of a request in our code to said response. This will be a unique ID (a guid is fine).
This will require a modification to the wallet providers spec.

Hi, any updates here?


Dependent extension is not activated if the depending extension gets activated after getting updated

Steps to Reproduce:

Have extension A depending on extension B
Have extension B current version is incompatible with VS Code and newer version is compatible
Opening VS Code with such version does not activate B therefore extension A throws an error that extension B is not activated
In the same session, extension B gets auto updated and newer version of extension B gets activated, but the extension A still does not get activated.

What are some extensions I could verify this issue with?
I can get GitHub Copilot Chat to emit the error in step 2, but GitHub Copilot doesn't depend on it afaik, and I don't know any other extensions depending on it.

To verify:

Install hbenl.vscode-mocha-test-adapter extension. It has a dependency on hbenl.vscode-test-explorer which gets installed too
From hbenl.vscode-test-explorer extension - Install one version older using Install Specific Version... action in the context menu. This is to show Update action on this extension.
Open Extension Folder (F1 > Open Extensions Folder), open the package.json of the hbenl.vscode-test-explorer extension that you just installed (Make sure this is the same version as you installed from Install Specific Version... action. Remove the engines property and save it.
Reload the window. You should see both  hbenl.vscode-test-explorer and hbenl.vscode-mocha-test-adapter extensions disabled in the view
Click Update action on  hbenl.vscode-test-explorer
Verify that both extensions are enabled after update is finished.


[Feature Request] Group and Filter like VisualStudio wrt Namespace, Class

It would be great to be able to Group and Filter like it is done in Visual Studio on in the TestExplorer
https://docs.microsoft.com/en-us/visualstudio/test/run-unit-tests-with-test-explorer?view=vs-2019#group-and-filter-the-test-list
If I name my tests ns.class.testname or just class.testname I could get them in a nice hierarchy.
It seems like it is doable in using the testMate.cpp.test.advancedExecutables and groupByRegEx but it would be great to select different groupings and filters from the UI.

+1 to this!


Lerna modularisation

There are discussions about modularising this code, and the more obvious ways are to

Move to opencomponents organisation the various repos
Create a mono-repo, possibly orchestrated by Lerna.

Benefits of 1, possibly facilitating external contributions (finding new owners for small parts of the code), and also using greenkeeper.
Benefits of 2, simplicity (test runner can test integrations between modules etc) + lerna handles all the publishing and all the sub-deps stuff.
Candidates, at least initially:

oc-client (node)
oc-client (browser)
cli
registry
utils

The only open issue atm with monorepo+greenkeeper is due to greenkeeper not handling nested package.json yet, but it has been flagged as "will be implemented" - https://github.com/greenkeeperio/greenkeeper/issues/139

this is a really interesting discussion. As an Italian, my philosophy is always "Divide et impera" so in theory, I would always prefer to decouple and move a specific part/component into a specific repository. In doing so we will be forced to understand what kind of dependencies (in terms of code coupling) different parts have and see if we can simplify the contract that binds them together. On the other hand, I see great benefit in going monorepo especially given the fact that other (big) companies are implementing it w/ proficiency. I'd love to experiment myself a little bit more as I don't know this subject very well. Any resource you would recommend to read/watch?
// cc @nickbalestra @matteofigus

Resources

[ ] https://danluu.com/monorepo/

Hey Mattia, the "Divide at impera" approach still totally apply with a monorepo (fancy name for multi-package repositories), as each "divided" piece is nothing more then a package, a module to be published. The only difference is that instead of having a separate repository for each package, they sit within the same project. You can for example think of oc-hub repos as monorepo. You could handle such repos manually and orchestrate publishing/etc with some scripts, or use some libraries to help with that, i.e: lerna, or northbrook.
Hope that helps

Another resource I would add, is the templates we are working on now:
https://github.com/opencomponents/oc-template-jade
Still a wip but good to see how the structure is evolving (packages folder, the lerna.json, and the root's package)

I find is also super good when you are doing "divide at impera". In the jade-template repo that Matteo mentioned you can see that I've started creating a folder "to-be-published" those are soon-to-become-packages, and I will simply move them up in packages init a package.json for them and that's it, learna will help me publish/work with much easier as if they were each in is own repo.

thanks for sharing this @matteofigus and @nickbalestra I think we should give lerna a go w/ the oc repo and see how we can create separate packages for core, client, cli and registry

As discussed with @nickbalestra, it could make sense to keep some modules here as monorepo, and move some others in separate repos anyways. For instance, oc-client (node) could be in its own so that we keep support for old versions of node (4, 5...) and oc-client (browser) could be in its own so that we have all the sauce labs slow tests in another repo. Things like cli and registry, instead, could stay here as lerna subrepos as it makes sense for making the code cleaner and simpler

Yes.
I do still feel that down the road, as we optimize some repos, drop support for older versions of node also on the client, and unify/optimize test suites/CIs then we could probably converge some of those back into a monorepo, especially for interdependencies packages (ie registry-cli-node/browser-client)

I am closing this, as we opted for partial lerna modularisation as test in the opencomponents organisations and we are very happy with that.
Examples: https://github.com/opencomponents/base-templates https://github.com/opencomponents/oc-template-react https://github.com/opencomponents/storage-adapters


[Fix] Group Task still has error status when Group Retry succeed

Hello.
We found and fixed the bug of Group Retry. (after merged https://github.com/treasure-data/digdag/pull/738.)
https://github.com/treasure-data/digdag/issues/728  issue is also caused by this bug.
The following are the details.
Thanks.
issue
Workflow Definition
group_retry.dig
+wf:
  _retry: 3

  +t1:
    echo>: foo

  +t2:
    # first failure, second success
    sh>: ./second_success.sh

  +t3:
    echo>: bar

second_success.sh
#!/usr/bin/env bash

if [ -e /tmp/executed ]; then
    echo "Success."
else
    echo "Failed." > /tmp/executed
    exit 1
fi

Result

Log
018-04-16 15:25:21.216 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:25:23.454 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
2018-04-16 15:25:23.499 +0900 [ERROR] (0050@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: Task failed with unexpected error: Command failed with code 1
java.lang.RuntimeException: Command failed with code 1
	at io.digdag.standards.operator.ShOperatorFactory$ShOperator.runTask(ShOperatorFactory.java:143)
	at io.digdag.util.BaseOperator.run(BaseOperator.java:35)
	at io.digdag.core.agent.OperatorManager.callExecutor(OperatorManager.java:312)
	at io.digdag.core.agent.OperatorManager.runWithWorkspace(OperatorManager.java:254)
	at io.digdag.core.agent.OperatorManager.lambda$runWithHeartbeat$2(OperatorManager.java:137)
	at io.digdag.core.agent.ExtractArchiveWorkspaceManager.withExtractedArchive(ExtractArchiveWorkspaceManager.java:77)
	at io.digdag.core.agent.OperatorManager.runWithHeartbeat(OperatorManager.java:135)
	at io.digdag.core.agent.OperatorManager.run(OperatorManager.java:119)
	at io.digdag.core.agent.MultiThreadAgent.lambda$null$0(MultiThreadAgent.java:127)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
2018-04-16 15:25:25.551 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:25:28.549 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
Success.
2018-04-16 15:25:30.547 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t3) io.digdag.core.agent.OperatorManager: echo>: bar
2018-04-16 15:25:32.731 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:25:34.707 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
Success.
2018-04-16 15:25:36.596 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t3) io.digdag.core.agent.OperatorManager: echo>: bar
2018-04-16 15:25:38.869 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:25:40.732 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
Success.
2018-04-16 15:25:42.516 +0900 [INFO] (0050@[0:retry_check]+group_retry+wf+t3) io.digdag.core.agent.OperatorManager: echo>: bar
2018-04-16 15:25:44.832 +0900 [INFO] (0050@[0:retry_check]+group_retry^failure-alert) io.digdag.core.agent.OperatorManager: type: notify

We expected Group Retry finished in the status of Success when all child tasks were Success.  However, it continued to retry and the workflow execution finished in the status of Failed.
It might be caused by the method "isAnyErrorChild".
The method checks every status of child tasks including one already failed before retrying,
So it bounds to return isError although retrying task is Success.
Fix
The query implemented in isAnyErrorChild makes a change to select “latest” error child task.
Result (after fixed):

Log:
2018-04-16 15:30:48.932 +0900 [INFO] (0042@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:30:51.411 +0900 [INFO] (0042@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
2018-04-16 15:30:51.441 +0900 [ERROR] (0042@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: Task failed with unexpected error: Command failed with code 1
java.lang.RuntimeException: Command failed with code 1
	at io.digdag.standards.operator.ShOperatorFactory$ShOperator.runTask(ShOperatorFactory.java:143)
	at io.digdag.util.BaseOperator.run(BaseOperator.java:35)
	at io.digdag.core.agent.OperatorManager.callExecutor(OperatorManager.java:312)
	at io.digdag.core.agent.OperatorManager.runWithWorkspace(OperatorManager.java:254)
	at io.digdag.core.agent.OperatorManager.lambda$runWithHeartbeat$2(OperatorManager.java:137)
	at io.digdag.core.agent.ExtractArchiveWorkspaceManager.withExtractedArchive(ExtractArchiveWorkspaceManager.java:36)
	at io.digdag.core.agent.OperatorManager.runWithHeartbeat(OperatorManager.java:135)
	at io.digdag.core.agent.OperatorManager.run(OperatorManager.java:119)
	at io.digdag.core.agent.MultiThreadAgent.lambda$null$0(MultiThreadAgent.java:127)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
2018-04-16 15:30:53.653 +0900 [INFO] (0042@[0:retry_check]+group_retry+wf+t1) io.digdag.core.agent.OperatorManager: echo>: foo
2018-04-16 15:30:55.789 +0900 [INFO] (0042@[0:retry_check]+group_retry+wf+t2) io.digdag.core.agent.OperatorManager: sh>: ./second_success.sh
Success.
2018-04-16 15:30:57.915 +0900 [INFO] (0042@[0:retry_check]+group_retry+wf+t3) io.digdag.core.agent.OperatorManager: echo>: bar

@hiroyuki-sato Thank you for your advice! I fixed my commit.

Sorry, I need more time to take a look this PR carefully but, I will response within this week.

@nak-tera sorry to be late but, thank you for suggesting and fixing. Basically it looks good to me but, I'm worry about the degradation of the query response time. If you get a chance, could you share us the diff of query plans before/after your change?

@muga Thank you for your review!  I was also concerned about the response time.
But I don't think the query response time can be so long because tasks and task_details table size can't be that big. These tables only have data of executing workflows.
The result of query plans and query response times in my environment is as follow.
If you consider that it has a problem of the degradation of the query response time, I'll find another way.
Query plans
・Before Change
explain select parent_id from tasks where parent_id=7573 and (state=6 or state=8) limit 1;
                          QUERY PLAN

Limit  (cost=0.00..0.32 rows=1 width=8)
->  Seq Scan on tasks  (cost=0.00..1.28 rows=4 width=8)
Filter: ((parent_id = 7573) AND ((state = 6) OR (state = 8)))
(3 rows)
・After Change
explain select parent_id from tasks where id in (select max(t.id) from tasks t join task_details td on t.id=td.id where t.parent_id = 7573 group by td.full_name) and (state=6 or state=8) limit 1;
                                            QUERY PLAN

Limit  (cost=2.30..3.56 rows=1 width=8)
->  Hash Semi Join  (cost=2.30..3.56 rows=1 width=8)
Hash Cond: (tasks.id = "ANY_subquery".max)
->  Seq Scan on tasks  (cost=0.00..1.24 rows=5 width=16)
Filter: ((state = 6) OR (state = 8))
->  Hash  (cost=2.29..2.29 rows=1 width=8)
->  Subquery Scan on "ANY_subquery"  (cost=2.27..2.29 rows=1 width=8)
->  HashAggregate  (cost=2.27..2.28 rows=1 width=25)
Group Key: td.full_name
->  Hash Join  (cost=1.01..2.27 rows=1 width=25)
Hash Cond: (t.id = td.id)
->  Seq Scan on tasks t  (cost=0.00..1.20 rows=12 width=8)
Filter: (parent_id = 7573)
->  Hash  (cost=1.00..1.00 rows=1 width=25)
->  Seq Scan on task_details td  (cost=0.00..1.00 rows=1 width=25)
(15 rows)
Query response times
tasks table size 16
Before: 1.146 ms
After: 2.181 ms
tasks table size 80
Before: 0.964 ms
After: 2.202 ms
tasks table size 3000
Before: 1.644 ms
After: 7.263 ms
tasks table size 15000
Before: 1.458 ms
After: 30.932 ms

Totally LGTM as well although left some minor comments.
@muga We'd better compare the performance with other ways (e.g. EXISTS clause, window functions) later

@nak-tera @komamitsu Thank you. Just in case, I will compare the query performance before/after on our environment.

@nak-tera @komamitsu Very sorry to be late. I did take a measurement of the performance comparison between before and after by using my application. The response times with before and after almost was same. Because a client and database are running on different nodes and network latency might impact total response time. It looks like the CPU utilization was not changed as well. This change may be reasonable and acceptable.

@nak-tera v0.9.27 out. thank you for your contribution! http://docs.digdag.io/releases/release-0.9.27.html


obsidian: 0.14.15 -> 0.15.9

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for obsidian is: "A powerful knowledge base that works on top of a local folder of plain text Markdown files"
meta.homepage for obsidian is: "https://obsidian.md"
meta.changelog for obsidian is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.15.9 with grep in /nix/store/i2f56fv6y2cwybb3bybfdvadlf8zw1gi-obsidian-0.15.9
found 0.15.9 in filename of file in /nix/store/i2f56fv6y2cwybb3bybfdvadlf8zw1gi-obsidian-0.15.9

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
obsidian

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/i2f56fv6y2cwybb3bybfdvadlf8zw1gi-obsidian-0.15.9 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A obsidian https://github.com/r-ryantm/nixpkgs/archive/57e611b1b0437fbf2e2fd2935d12d43761adc7dd.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/i2f56fv6y2cwybb3bybfdvadlf8zw1gi-obsidian-0.15.9
ls -la /nix/store/i2f56fv6y2cwybb3bybfdvadlf8zw1gi-obsidian-0.15.9/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

obsidian

Maintainer pings
cc @AtilaSaraiva @ConradMearns @zaninime @opeik for testing.

The update script does not update the darwin hash.

https://nvd.nist.gov/vuln/detail/CVE-2022-36450

It would actually be nice to fix the update script


v0.25.0 RC: Rename indexes.add into indexes.create in the actions list

Following https://github.com/meilisearch/specifications/pull/99
We want to rename indexes.add into indexes.create in the actions list.
@meilisearch/docs-team

Fixed by #1989


token-2022: add extension realloc helper

In working on the MemoTransfer extension, I found I needed an api to determine if reallocation was needed. Might be useful for confidental transfers as well.
Thoughts?

What if we draw a line between pre-init and post-init extensions, and pre-init extensions always require preallocation, and post-init extensions always realloc? Then we can also separate init_extension and init_extension_with_realloc which would also accept the payer AccountInfo.

Seems like that should work fine.

As for the implementation on StateWithExtensionsMut, we could always just do the unsafe byte manipulation ourselves and get around requiring Accountinfo, ie copy this https://github.com/solana-labs/solana/blob/aab70b3aee2d39ce54842bc5011ffc44c8375cfd/sdk/program/src/account_info.rs#L128

Veto!

Veto!

Deep down, I think I was unconsciously trolling :smiling_imp:


Enable Secure Boot csum err:0xfa!=0x72(windows) (IDFGH-2639)

Environment

Development Kit:none
Module or chip used:  [ESP32-WROOM-32D|ESP32-WROOM-32U
IDF version : v3.3.1
Build System:         idf.py
Compiler version :
xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Operating System:     Windows
(Windows only) environment type: Plain Command Prompt
Using an IDE: No
Power Supply:         USB

Problem Description
I follow the https://docs.espressif.com/projects/esp-idf/en/latest/security/secure-boot.html#secure-boot-reflashable.
When I open the monitor it keep showing the

Expected Behavior
Secure enable and led will blink.
Actual Behavior

Steps to reproduce
1.idf.py menuconfig

2.idf.py build

Python espefuse.py -p com18 burn_key secure_boot D:/ESP32/esp-idf-v3.3.1/blink/build/bootloader/secure-bootloader-key-256.bin

Python esptool.py --chip esp32 -p com18 --baud 460800 --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB  -u 0x1000 D:/ESP32/esp-idf-v3.3.1/blink/build/bootloader/bootloader.bin

Python esptool.py --chip esp32 -p com18 --baud 460800  --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB  -u 0x0 D:/ESP32/esp-idf-v3.3.1/blink/build/bootloader/bootloader-reflash-digest.bin

6.idf.py flash

7.idf.py monitor

PS:python espefuse.py -p com18 summary

Code to reproduce this issue

Please tell me which step I miss or wrong.
I also want to enable the flash encryption ,so what should I do next.
Sorry for bother

https://docs.espressif.com/projects/esp-idf/en/v3.3.1/security/secure-boot.html#bootloader-size

hi @negativekelvin  thank you ,I follow the docs and change like this

And

Then ,It's work!!
Thank you so much.
But now I want to enable the flash encryption too,Below it's my action.
I follow the https://docs.espressif.com/projects/esp-idf/en/v3.3.1/security/flash-encryption.html
1.python espefuse.py -p com18 summary

Secure boot is enable.
And I change code like this

docs said:

My action:

3.
idf.py build

4.re-flash bootloader
Python esptool.py --chip esp32 -p com18 --baud 460800 --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB -u 0x0 D:/ESP32/esp-idf-v3.3.1/blink/build/bootloader/bootloader-reflash-digest.bin

5.idf.py flash monitor

And the first time restart the esp32 will take about 30 second to 1 minutes.
Thank you @negativekelvin .

hi @negativekelvin  sorry for bother again.
I sudden run idf.py flash again.
Then the monitor print

And my summary

I saw the

It's mean Flash encryption mode counter Read Only Right?
So this esp32 was broken Am I right?

Yes

Hi @CJ0104
Did you found any fix for the flash read err, 1000.
I have the same issue. It worked once and I reflashed it and same error and ever since it won't accept even the signed&flash encrypted binary.

Hi @arunmagesh .
If your esp32 have been encrypted,you can't flash any firmware into that esp32.
If your did the esp32 will broken and keep showing "flash read err, 1000".
And if you didn't flash any encrypted firmware into esp32,please check other issue .
There are a lot of issue about "flash read err, 1000" in this github.
Thank you and sorry about my poor english.
Best regard


Add Bernardi-Raugel element

C. Bernardi and G. Raugel, Analysis of Some Finite Elements for the Stokes Problem, Math. Comp., 44(169):71–79, 1985

Presumably closable due to #79.

I've closed this and opened #100, as there were multiple elements in that paper that I want to check if we have


Add CircleCI config

Is your feature request related to a problem? Please describe.
CircleCI configuration is needed.
Describe the solution you'd like
Add CircleCI config.yml to project.
Describe alternatives you've considered
N/A
Additional context
This tests and linting configurations are needed before this can be useful.

I see the CircleCi config has been added. I think this should be closed.


Can we use client events like whisper?

Hello @happones  may I ask if client events like whisper is included to your package? This is the  link  about client events using whisper on laravel Echo.
This is the code from the laravel documentations.

I tried it on my web version and then listen using my nativescript vue app and it works the problem was on my code sending the client event from my nativescript-vue app


[ICE] reached unreachable: bug in const_fold or parser

Expected behavior

Possibly an error? Not sure.
Actual Behavior

The application panicked (crashed).
Message:  internal error: entered unreachable code: bug in const_fold or parser: cpp cond should be boolean
Location: src/lex/cpp.rs:605

Code

#if!F?"":!a

Backtrace

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                          (5 post panic frames hidden)
 5: rcc::lex::cpp::PreProcessor::boolean_expr::hb14924dc1e2aa075
    at src/lex/cpp.rs:605
 6: rcc::lex::cpp::PreProcessor::directive::h1d36c2bd1020b8e4
    at src/lex/cpp.rs:395
 7: <rcc::lex::cpp::PreProcessor as core::iter::traits::iterator::Iterator>::next::hfca8c81831b50c63
    at src/lex/cpp.rs:136
 8: rcc::compile::h53a76de88b04a7fa
    at src/lib.rs:156
 9: rcc::real_main::hae5b7d98d318c138
    at src/main.rs:109
10: rcc::main::h4220d37df2ab27ea
    at src/main.rs:176

File, fresh from the fuzzer:
SIGABRT.PC.7ffff7dee7bb.STACK.b8fd143c.CODE.-6.ADDR.(nil).INSTR.mov____0x108(%rsp),%rcx.tar.gz

This should be an error, string literals are not allowed in preprocessing expressions.
$ run_clang
#if!F?"":!a
#endif
int main() {}
<stdin>:1:7: error: invalid token at start of a preprocessor expression
#if!F?"":!a
      ^

Whoops, linked the wrong issue.

Hmm, this is actually a bug in the constant folder, it's returning (Str([0]), Bool), but it should always return an Int if it returns a boolean type.

Actually I think the issue is in truthy, which really mangles this expression:
expr is (((0) != ((long)(0))) == ((_Bool)(0))) ? ("") : (((0) != ((long)(0))) == ((_Bool)(0)))
truthy expr is (((0) != ((long)(0))) == ((_Bool)(0))) ? ("") : (((0) != ((long)(0))) == ((_Bool)(0)))


Reconciling Differences Between Facade and our Git Analysis

Hi All,
Had a great conversation with a few folks who want to use our git repo stuff, and we noticed some differences in the counts of commits of lines of code by our git analysis and Facade. I am sure some of this is part of the initial prototyping, but I want to be able to share the details with a facade user and also know if we are explicitly counting differently, or calculating something in error.
Here's an example for http://git.enlightenment.org/core/efl.git
Facade data https://osg.facade-oss.org/repositories?repo=119
Augur data http://pose.augurlabs.io/?git=aHR0cDovL2dpdC5lbmxpZ2h0ZW5tZW50Lm9yZy9jb3JlL2VmbC5naXQ=
I am not labeling it a "bug" yet. It could be our implementation is different or incomplete. At this point I only want to understand. :)

@howderek : This is probably the most important thing to focus on when you have time.

@brianwarner : We have added a facade instance as an option for deployment of Augur so that Facade statistics are calculatable and presentable.
Good to go on dev branch.  Pushing to master before CHAOSSCON on August 28, 2018 in Vancouver.


AWS reports volume doesn't exist, but it does, and it's mounted

I only see this error in the chef-client logs.  Running manually via "chef-client" does not reproduce this error.  However, firing off a run via /etc/init.d/chef-client run does produce the error, visible in the logs.
[2014-10-03T20:45:22+00:00] ERROR: Running exception handlers
[2014-10-03T20:45:22+00:00] ERROR: Creating JSON exception report
[2014-10-03T20:45:23+00:00] ERROR: Exception handlers complete
[2014-10-03T20:45:23+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-10-03T20:45:23+00:00] ERROR: aws_ebs_volume[data_volume](drbd-ebs::ha line 36) had an error: RuntimeError: Volume with id vol-a8fda8ed is registered with the node but does not exist in EC2. To clear this error, remove the ['aws']['ebs_volume']['data_volume']['volume_id'] entry from this node's data.
[2014-10-03T20:45:23+00:00] ERROR: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
chef-client -v
Chef: 11.14.0.alpha.4
root@use1d-admin101a:/var/log/chef# curl http://<IP_ADDRESS>/latest/meta-data/block-device-mapping/ebs19/ && echo
xvdb
root@use1d-admin101a:/var/log/chef# mount
/dev/xvda on / type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/drbd0 on /data type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
root@use1d-admin101a:/var/log/chef# cat /etc/drbd.d/pair.res
resource pair {
device    /dev/drbd0;
disk      /dev/xvdb;
}
root@use1d-admin101a:/var/log/chef# cat /proc/drbd
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:688215440 nr:0 dw:744654652 dr:2126176838 al:15406293 bm:141869 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

@someara as chatted about in the #chef irc room, this is caused by 1.9.3 in the chef-11 omnibus packages and the semantic difference between exist? and exists? in 1.9.3 vs 2.0+
In this particular case, https://github.com/opscode-cookbooks/aws/blob/v2.6.4/providers/ebs_raid.rb#L55 is using file.exist, which will not return true on 1.9.3 for a block device.

I believe some of our refactoring may have worked around the API lying about availability here. Try the latest release


Added or updated to work on ubuntu 16.04

tasks/debian.yml - Populating openLDAP task was failing due to permissions against the nodomain org. Added  slapd/domain and shared/organization to debconf to correct this
tasks/debian.yml - with_items clause needed {{}} to not error
tasks/config_openldap.yml - Added task to set admin password
tasls/config_openldap.yml - Added task to restart slapd

@bunchc Merged! Thanks dude!


"Guidelines for Naming Projects, Tools, or Organizations" section in the readme

With commit OAI/OpenAPI-Style-Guide@7687728 a new section "Guidelines for Naming Projects, Tools, or Organizations" was introduced in the README. This issue is about understanding the consequences.

Found on GitHub:
GitHub Organization:
Several GitHub Organizations are already using OpenAPI as prefix:
https://github.com/OpenAPI
https://github.com/OpenApiFactory
https://github.com/OpenAPITools
https://github.com/OpenAPI-Tools-Automation
https://github.com/openapi-test
https://github.com/openapi-ro
Project name:
Several GitHub projects are already OpenAPI or openapi in their project name:
https://github.com/contentjet/openapi-ui
https://github.com/getkin/kin-openapi
https://github.com/oasis-tcs/odata-openapi
https://github.com/Mermade/openapi-codegen
https://github.com/Mermade/openapi-filter
https://github.com/Mermade/swagger2openapi
https://github.com/Microsoft/OpenAPI.NET
https://github.com/openapitools/openapi-generator
https://github.com/p1c2u/openapi-spec-validator
https://github.com/quen2404/openapi-diff
https://github.com/RepreZen/KaiZen-OpenAPI-Editor
https://github.com/RepreZen/KaiZen-OpenApi-Parser
https://github.com/xuzhg/OData.OpenAPI
Is the usage of open-api in the project URL better?
https://github.com/eclipse/microprofile-open-api (Project title in the readme: "Eclipse MicroProfile OpenAPI")
https://github.com/janephp/open-api (Project title in the readme: "Jane OpenAPI"
And some projects are using openapi3:
https://github.com/metadevpro/openapi3-ts
https://github.com/adwhit/openapi3-rust

While I understand the concern about the usage of the OpenAPI brand in third-party projects, I think that the rule as formulated in the readme is really hard to implement. There are a lot of projects out there (small one, big corporation one, foundation-backed one). I think that the having a lot of projects having adopted "OpenAPI" in their project names demonstrate the strength of the ecosystem.
Thank you in advance for your advises on how to read the section.

@jmini Thanks for your feedback on this issue.  I'm not sure I agree that the guidance provided is hard to implement.  It is true there may be edge cases, but in general, ask the question, is the name of my tooling likely to be misconstrued by someone as an official reference implementation by the OpenAPI Initiative.
If a project is under a personal or company repo, then I don't think anyone is going to be confused about the authority of the project.  If the organization is completely empty like https://github.com/OpenAPI
and https://github.com/OpenApiFactory then there is not much to be confused about.
However, from the list of repos above, the only one that does not clarify that the project belongs to a secondary identity, is openapitools/openapi-generator.  I do appreciate the fact that on the organization page there is a note that clarifies that OpenApiTools is not affiliated with the OpenAPI Initiative.  However, most folks are going to link directly into the repo and never see that caveat.
There is fairly strong user demand for reference implementations, but the OAI neither has the charter nor the resources to create those, and to do so would be unfair to community efforts.  What I personally do not want, is people assuming that the OAI does have reference implementations because of unclear naming.

@darrelmiller, thank you for this message. Here some more questions we have with the @OpenAPITools/generator-core-team.

@jmini Thanks for your feedback on this issue. I'm not sure I agree that the guidance provided is hard to implement. It is true there may be edge cases, but in general, ask the question, is the name of my tooling likely to be misconstrued by someone as an official reference implementation by the OpenAPI Initiative.

We can always ask that simple question but who's going to decide the "correct" answer. Let's start with the question "Do you think X is affiliated with OpenAPI Initiative?" where X is OpenAPITools.org in this case and depending on who you ask the question, you may get different answers: Yes, No, maybe, or other possible answers.
We think the important point is who's going to make the call to decide whether a particular name will cause potential confusion with OpenAPI Initiative. Is that done by a single person at OpenAPI Initiative? or the OpenAPI Initiative TSC going to vote?
Let's look at https://openapi.tools as an example. Arguably one may consider http://openapi.tools to be affiliated with the OpenAPI Initiative. From OpenAPI Initiative, should https://openapi.tools be renamed to something else to avoid potential confusion?
Disclosure: the OpenAPI Generator core team does not own https://openapi.tools. but we did submit pull requests (merged) to include "OpenAPI Generator" in the list.

If a project is under a personal or company repo, then I don't think anyone is going to be confused about the authority of the project. If the organization is completely empty like https://github.com/OpenAPI
and https://github.com/OpenApiFactory then there is not much to be confused about.

Thanks for elaborating a bit more on this. If "OpenApiFactory" publicly forks AutoRest (a code generator owned by Microsoft) to create https://github.com/OpenAPIFactory/AutoRest, will "OpenAPIFactory" need to be renamed to something else to avoid confusion?
What about https://github.com/regga-ws, which has several repositories and uses OpenAPI Initiative's logo but states clearly it's unofficial?
What if "OpenAPIFactory" leaves a very negative comment in a Github issue about open-source projects in general? Following what you said earlier

However, most folks are going to link directly into the repo and never see that caveat.

Your logic above implies "most" users reading the negative comment will not click on the Github account to uncover the fact that the account does not host any repository and therefore has nothing to do with "OpenAPI Initiative".
In this case, do you agree people cannot clearly tell the negative comment or the "OpenAPIFactory" account itself has nothing to do with "OpenAPI Initiative"?
(this is not to say we agree with the statement "However, most folks are going to link directly into the repo and never see that caveat")

There is fairly strong user demand for reference implementations, but the OAI neither has the charter nor the resources to create those, and to do so would be unfair to community efforts. What I personally do not want, is people assuming that the OAI does have reference implementations because of unclear naming.

We do not want people to be confused either as mentioned in our first email reply to Marsh. Do you mind sharing with us how many people you've spoken with to arrive at the conclusion "most" people are confused about OpenAPITools.org being affiliated with OAI? Would you consider a more objective approach by doing a vote on the Twitter account "OpenApiSpec" with the following question?
Do you think OpenAPITools.org (the parent organization of OpenAPI Generator) is affiliated with OpenAPI Initiatives?
Choice 1: Yes
Choice 2: No
Choice 3: Maybe
Poll length: 10 days
Here are two follow-up questions we've after reading your reply:

Does it mean "OpenAPI-Generator" (Github repo name) and "OpenAPI Generator" (product name) need not be renamed, which means these names conform to the updated guidelines?

In your opinion, do you think the OpenAPI Generator logo (https://github.com/OpenAPITools/openapi-generator/issues/23#issuecomment-389382860) also violates the updated guideline and will certainly cause confusion to the community?

Thanks for the discussion. Branding is an interesting exercise, especially when it relates to open source.
Organization Name and Project Names

If a project is under a personal or company repo, then I don't think anyone is going to be confused about the authority of the project. If the organization is completely empty like https://github.com/OpenAPI
and https://github.com/OpenApiFactory then there is not much to be confused about.
However, from the list of repos above, the only one that does not clarify that the project belongs to a secondary identity, is openapitools/openapi-generator. I do appreciate the fact that on the organization page there is a note that clarifies that OpenApiTools is not affiliated with the OpenAPI Initiative. However, most folks are going to link directly into the repo and never see that caveat.

It seems like most of the concern is about the use of the organization name and the project name together. Here are some additional questions:
Some questions:

What are OAI's thoughts on the go-openapi organization at https://github.com/go-openapi? The organization description is currently "OpenAPI Initiative golang toolkit" and they have several projects, unlike the ones mentioned. Should they change their organization name and / or description?
It seems the OpenAPI Generator project name by itself is not an issue, but there is concern when associated with the organization name. Also, the organization name seems to be acceptable by itself since it has a disclaimer at the top of the page. On the project page, there is an existing disclaimer that says the following in the README.md. Would putting such a disclaimer in the GitHub repo description at the top of the page alleviate these concerns?

:bangbang: Both "OpenAPI Tools" (https://OpenAPITools.org - the parent organization of OpenAPI Generator) and "OpenAPI Generator" are not affiliated with OpenAPI Initiative (OAI) :bangbang:

Organization and Project Logos
In the commercial sector, protection of logos is very important, however in the open source communities, there has been a tradition of modifying logos for related projects. This gives a sense of community and association. For example, several organizations / projects that have their logos modified on a regular basis include Linux (penguin), Android, Go (gopher) and Python. Given the 2000+ GitHub repos that mention "openapi" in the name there is community effort around OpenAPI. Would OAI be supportive of projects making derivative logos like the one mentioned.

So, @jimschubert you are suggesting that other than the colours, the layout of these two logos is co-incidental and there was no intent to create something that was similar?

@jmini We would like the person creating the project to make the decision as to whether there may be confusion.  I believe I can safely speak for the TSC in saying that we have absolutely zero interest in being intellectual property police.  We have absolutely no interest in doing anything that would discourage community involvement.
What I am asking is for the project owners to review the naming decisions they have made and ask themselves the question, could this cause confusion in the community.  Could someone mistake this project for a reference implementation?  Could someone mistakenly interpret the naming as being an indication that the Swagger-codegen project is no longer a maintained effort and that this project is a replacement.  The specification has been renamed from Swagger to OpenAPI and the OAI members have spent a significant amount of marketing effort explaining this transition.  What is to stop someone from assuming that Swagger-CodeGen has just been renamed to OpenApi-Generator?  It's forked from the same code-base, right?  It has many of the same contributors.  Do you believe my concern for these confusions are unfounded?
If the openapi-generator project team feel these concerns of mine are unfounded, that's their choice.  I've given my opinion.  The document we are discussing are guidelines that are intended to encourage constructive community behavior, nothing more.

@jimschubert I would appreciate it if you didn't put words into my mouth.  If you re-read what I wrote, I made zero comments about the logo other than asking you to clarify your statement.  I certainly made no statement about what OAI considers a no-no.
I am only concerned about the potential for confusion.  As someone who has spent the last two years incessantly explaining to people the difference between OpenAPI and Swagger, I am hyper-sensitive to this issue.
@grokify It is great that you have a process of due diligence when working with OSS projects.  If only everyone was a diligent as you.
It appears to me that the members of the OpenApiTools org feel that their actions will have no negative impacts on the community and are enthusiastic about defending that position.  I have more constructive things that I could be doing than debating this.  I'm prepared to leave it at agreeing to disagree.

@darrelmiller if you weren't suggesting that a logo which looks similar with the design elements we've discussed in this thread is against the guidelines, then please explicitly state what you're asking me about.
I think the 3 clarification points I've asked for are reasonable questions, and I'll await responses.

@jimschubert You already answered my question. I asked " there was no intent to create something that was similar?" and you replied "I used certain design elements to allow the community to associate our project as a tool specific to OpenAPI specifications. "
Regarding your questions, I believe I made my position clear.
As for your questions:

I made no statement about what a community project can and can't do. I don't have any such authority. And you know that.
You don't appear to believe there is a possibility for confusion, so it would seem pointless me suggesting changes.
I didn't suggest it could be could be confused for the OAI logo.  I suggested that it is similar

@jimschubert You already answered my question. I asked " there was no intent to create something that was similar?" and you replied "I used certain design elements to allow the community to associate our project as a tool specific to OpenAPI specifications. "
Regarding your questions, I believe I made my position clear.

@darrelmiller I appreciate that you edited your original response. My questions in this thread aren't meant to get under your skin, I'm just asking for clarifications which I don't feel like I've yet fully received.
To explain why I have questions, openapitools/openapi-generator was released on June 1 2018. On June 8 2018, this repository was updated via a597520dcf784fdd3704d7216b5567025e1d7aaa to include the following guidelines about the logo:

For example, if you're considering using the barbell element or the segmented circle, you may want to reach out to the OAI proactively to avoid a rebranding exercise later.

Being that I can't reach out "proactively" weeks after I created the logo, I'm asking my questions here and seeking further clarifications on these guidelines.
Also, I have a few additional questions based on a comment removed by your edit. I thought you were on the TSC, is this incorrect? If incorrect, what's your role? And is there an org chart or something which may clarify my confusion?
Thanks

Disclaimer: I was a contributor to swagger-codegen for almost a year before becoming a Java Technical Committee member and then becoming a Core Member. Then, the fork happened and I became a core member of openapi-generator. This reply is MY own opinion and I'm NOT talking for the rest of the team or any member of its community.
First of all, let's look at this "problematic" in another angle. The OAI's goal as described here is to "create, evolve and promote" the OpenAPI Specification. You guys should be VERY happy each time a new project implementing your specification pops on the Internet. Your goal is that when someone search for "OpenAPI " on Google, he found a tons of tools and utilities to do whatever he want with its API. He want to see that the specification is alive. You don't want the user to found "RAML" or "API Blueprint". These are the real enemies.
You should not care about how people hear about "OpenAPI ". Did they find with OpenApiTools ? Did they find it with Swagger? Swagger Hub? Nobody cares. The end goal is the same for us all: Have people using OpenAPI with the tools of their choice.
I thinks it's pretty normal for a tools using a specification to have the name of the specification in its name. Imagine if the MP3 was forbidden in project name. How do you call a WavToMP3 converter? (That may not be a perfect example, but I'm pretty sure you understand what I meant)
Again, we, as much as you, want people to find tools when they are searching for tools to work with OpenAPI. If it's clearly said on all our important pages that we are not affiliated with OAI, then I don't see the problem at all. It's a win-win situation where we provide tooling for your specification and more and more people start using your specification all over the world.
As for the logo, I'm no artist but I can say that beside looking a bit similar, it is clearly not a "copy paste".
As for this:

What I am asking is for the project owners to review the naming decisions they have made and ask themselves the question, could this cause confusion in the community.

In most open source project, there are no "project owners". The project is run by the community and that was one of the main reason core members moved from swagger-codegen who was run by a company in the background (plus super bad decision related to breaking changes). We are 100% transparent and public and most decisions are made as a team. The name decision was made via multiple discussion by many many people.
I hope you and other OAI will answer the recurring question asked by our team members in this thread. They are simple and will help a lot to understand the problem. Again, I think there is not problem at all and that our project should work with you guys because we are on the same boat.
Have a good day!

@jimschubert Yes I am a member of the TSC (members are shown here).  If I am making statements that convey the policy/decisions of the TSC I will try to be very clear about that.  This thread has been about expressing my feelings on the situation as a community member.
It is true that the guidelines were created as a reaction to the perceived issue with the naming of the OpenApiTools/OpenAPI-Generator, so the guidance about proactively reaching out obviously isn't helpful for you. The goal was to prevent us from getting into this situation again.
It is also true that we had no idea how to write these guidelines in an effective way.  We are devs and PMs, most likely much like yourselves.  We are not lawyers.  We perceived a problem and we attempted to provide guidelines to prevent that from happening in the future.
We don't want to ask you to change the name of your project, or change your logo, we would rather be working on features that go into OpenAPI 3.1.  But sadly as TSC members we also must deal with other issues.  We (the TSC) are concerned about the naming.  However, there are varying degrees of concern amongst members.  There isn't concensus on what, if any, action should be taken.
Our hope was that by reaching out to you, we could explain our concerns and we could resolve the issue.  Secondarily we decided to update our guidelines to reduce the chance that this would happen again.  Sadly we have descended into analyzing the words of the guidelines.
I have tried to convey the intent of the guidelines rather than answering direct questions about what the guidelines do and do not allow.  Much like debating a Code of Conduct, if we have to define precisely what is and isn't allowed, we are going to have a world of pain.
If you have suggestions on how to re-phrase the guidelines in a way that clearly expresses the intent, we are open to suggestions.

@jimschubert Ok let me clarify something that I have confused because I wear too many hats in this effort.  This isn't a TSC issue at all.  The TSC only deals with the technical aspects of the specification.  This is an OAI issue.  I also am a member of the OAI marketing group and a representative on the OAI governing board.  So, when I said the TSC have concerns, I misspoke.  The TSC have not discussed this issue officially, and it is not their responsibility.  There are members of the OAI marketing group that have concerns.  My statement about there not being consensus on the issue is accurate.

@JFCote The suggested change to the guidelines currently reads:

Ask yourself, "Might someone think this was an official tool/project/group of the OAI?" If the answer is, "Maybe," then consider adding a modifier.

Nowhere do we say that you can't use OpenAPI in the project name.
What we are trying to do is create a level playing field for the community.  Having one community project benefit more than others from the marketing efforts of the OAI because they appear to be an "official" implementation is what we are trying to discourage.
No-one suggested the logo was a copy-paste. I certainly didn't.
Let's not conflate the conversation about why the fork occurred and this particular issue.  It's great that many people contributed to the naming conversation and that you are transparent about these things.  Can you point me to the GitHub issue where the conversation happened so I can see the thought process?

@darrelmiller I can't because that was done when the fork was "private" and in the process of becoming official. By becoming official and public, we had to create an organization and have a project name so these things had to be decided before going public. But I can assure you it was not decided by one person. It was discussed and we were pretty happy with the final name of the org and the project. We had no bad intention and there were no guidelines from OAI at the time to follow.
I hope that answers your question. I'm leaving for 2 weeks on vacation so I won't be able to answer for a while. Have a good day.

I wasn't part of the naming or logo discussion, but the logo progression is online in the link posted by @jmini above. The logo was originally horizontal but there was a request to make it more squarish and suitable for an icon. My guess is that "up and to the right" is the best angle / corner if one had to choose. Here are the two posts that cover this:
https://github.com/OpenAPITools/openapi-generator/issues/23#issuecomment-389382860

What we are trying to do is create a level playing field for the community. Having one community project benefit more than others from the marketing efforts of the OAI because they appear to be an "official" implementation is what we are trying to discourage.

As a user of both Swagger Codegen and OpenAPI Generator as well as an evaluator of APIMATIC, AutoRest, and go-swagger, I would suggest that the naming of an OSS project does not necessarily help or hinder the project from a marketing effort perspective for actual adoption. This is because open source projects can be named anything. My considerations include:

capability and maturity of the tool
availability of support for the tool

Regarding support for the tool there are two types of OSS projects:

Community-backed - often best-efforts, non-funded
Commercially-backed - funded with dedicated resources

From this perspective, a tool with a brand name that indicates it is commercially backed by a company can get more adoption (see React vs. Vue). A tool like Swagger Codegen is known to have commercial support and that is a worthwhile consideration when comparing tools.
So if naming is less important, what is more important?
I will now post my understanding of the Swagger Codegen situation because I think it's germane to the level playing field question, primarily if the name doesn't matter, what does?
I had previously created issues for Swagger Codegen and when I got around to to submitting my first PR did I realize OpenAPI Generator had been created. Swagger Codegen still has an active issues list, more Stack Overflow questions, etc., so why consider OpenAPI Generator?

The first is that community had moved. To adjust to this, Swagger Codegen should recreate a Core Team (the list is currently empty) or remove the Core Team section, and get more template generators on their list.
It appears problematic to submit for Swagger Codegen, which also appears to be the reason some community members left. As a user of Swagger Codegen, I'd want to submit PRs for it, but it seems like version 2.x is essentially deprecated already. Version 3.x will be different and require rewriting of the templates (few languages supported, tests commented out, etc.). So if I submit a PR for 2.x for my requirement now, it won't get fixed on 3.x and my work will essentially disappear with 3.x. In this scenario, it seems understandable for there to be reluctance to put effort into Swagger Codegen 2.x and wait for Swagger Codegen 3.x.

Right now, it seems reasonable to consider moving to OpenAPI Generator now because OAS 3.0 is supported, and then reconsider Swagger Codegen when 3.x is released with languages of interest, given the backcompat break.
This evaluation has nothing to do with the name of the projects and everything to do with the technical choices made by the projects.

I am the feeling that this discussion is going everywhere but not about debating the guideline (which was my initial intention).
My personal opinion about this topic is simple:
Having a guideline that tells 'Asking yourself' is not a good guideline.
Examples:

http://openapi.tools/
https://github.com/go-openapi
https://github.com/OpenAPITools/openapi-generator.

Those 3 projects (created before the update of the README discussed in this issue) can ask them-self if they are not going against the guideline by using the term "OpenAPI" or "OpenAPI Initiative". They could come from OAI.
And because the rules are not clear, there is no definitive answer and it creates an infinite debate like this issue.

@jmini - @darrelmiller has already written:

It is also true that we had no idea how to write these guidelines in an effective way. We are devs and PMs, most likely much like yourselves. We are not lawyers.

This indicates that the guidelines are not perfect so there is recognition that there may be questions. Not being a lawyer myself, I prefer simple to understand guidelines like the MIT license vs. ones designed by lawyers like the Apache 2.0 license.

It appears to me that the members of the OpenApiTools org feel that their actions will have no negative impacts on the community and are enthusiastic about defending that position. I have more constructive things that I could be doing than debating this. I'm prepared to leave it at agreeing to disagree.

I'm interpreting this to mean that he's "ok" if the OpenApiTools team: (a) look at the guidelines, (b) feel there is no negative impacts, and (c) stays with existing name choices. I'm not on the core team so that is up to you to decide.
Further discussion is just for clarification. I continued to post in an effort to alleviate any remaining concerns that may exist.
@darrelmiller Please correct me if any of the above is incorrect.

What is to stop someone from assuming that Swagger-CodeGen has just been renamed to OpenApi-Generator?

The existence of a fork of Swagger-Codegen is not a branding question. One of the reasons is because of disagreements with some fundamental choices made by Swagger-Codegen-v3 and with the governance of the project in general. For more information, please refer to the Q&A in the OpenAPI Generator project page.
Even if the OpenAPI-Generator project was called Codegen-for-OpenAPI (as suggested to be better by the guideline section discussed in this issue) or API-Code-Generator, the users still need to ask themselves the exact same questions:

Was the project just renamed?
Is Swagger-Codegen still maintained?
What is better for me?

In other words, someone can still mistakenly assume that Swagger-CodeGen has been renamed to X where X can be Codegen-for-OpenAPI, API-Code-Generator or something else.

What I am asking is for the project owners to review the naming decisions they have made and ask themselves the question, could this cause confusion in the community. Could someone mistake this project for a reference implementation?

As @grokify has pointed out he didn't mistake this project for a reference implementation nor did he get confused by OpenAPI Generator. This is not to say he represents everyone in the API community. Our point is this goes back to the answer we provided last time:
depending on who you ask the question, you may get different answers: Yes, No, maybe, or other possible answers.

We still think it's important to understand the process in OAI to determine if a particular name will cause confusion to the API community. The question "Asking yourself if the name could imply that the project is an official tool/project/group of the OAI" is not going help as the answer can be very subjective.

Could someone mistakenly interpret the naming as being an indication that the Swagger-codegen project is no longer a maintained effort and that this project is a replacement?

Here are some questions we would like to ask for clarifications:

From what we know Swagger-Codegen is owned by SmartBear but not by the OpenAPI Initiative (OAI). The discussion starts with whether people may confuse OpenAPITools.org being affiliated with OAI and/or "OpenAPI Generator" being misinterpreted as a reference implementation by the OAI. How is Swagger Codegen (a tool not owned by OAI) relevant to the discussion?
Are other Swagger-related products/projects such as swagger-ui, swagger-js-codegen also covered by the updated guideline, which means openapi-ui is not allowed for example?  (swagger-js-codegen is not owned by SmartBear based on our understanding)
Does the updated guideline also apply to other OpenAPI tools such as AutoRest (a code generator owned by Microsoft)? In other words, AutoOpenAPI may not be allowed as people may confuse it with AutoRest.
Does "openapi-generator" conform to the updated guideline if it's a fork of AutoRest but not Swagger Codegen?

It's forked from the same code-base, right? It has many of the same contributors. Do you believe my concern for these confusions are unfounded?

That's the nature of open-source software, especially those licensed with Apache license 2.0. In other words, what you observed - same code-base, same contributors - are common to all forks of projects with Apache 2 license and not just OpenAPI Generator. In Swagger Codegen Github page, you will find that the project has been forked more than 3700 times and some forks are hosted on Gitlab (example) too.
Is it correct to say that one can use https://github.com/openapitools/openapi-generator if it's written from scratch without violating the updated guidelines as the code-base is no longer the same and "many" of the contributors are not the same?
We also think this conversation got sidetracked a little bit to Swagger Codegen in particular. Back to the original concern Marsh shared with OpenAPI Generator core team via email quoted below (which does not mention "Swagger Codegen" at all in the whole email):

To that end, we are concerned that the new organization you've created, OpenAPI Tools, has chosen a name that might easily be confused for an official project of the OAI.

We would appreciate if you, other TSC or OAI marketing group members can answer the following questions:

From OpenAPI Initiative, should https://openapi.tools be renamed to something else to avoid potential confusion?

If "OpenApiFactory" publicly forks AutoRest (a code generator owned by Microsoft) to create https://github.com/OpenAPIFactory/AutoRest, will "OpenAPIFactory" need to be renamed to something else to avoid confusion?

What about https://github.com/regga-ws, which has several repositories and uses OpenAPI Initiative's logo but states clearly it's unofficial?

What are OAI's thoughts on the go-openapi organization at https://github.com/go-openapi? The organization description is currently "OpenAPI Initiative golang toolkit" and they have several projects, unlike the ones mentioned. Should they change their organization name and / or description? (these questions are from @grokify)

We believe answers to these questions will help the community to understand more about what conforms or does not conform to the updated guidelines and we would recommend including some of these questions and answers in the guidelines.
From Darrel's reply, we feel that he's frustrated with our answers but just so everyone is on the same page, none of the core team members ever works with Darrel. Assuming OpenAPI Generator core team members are bad guys to start with is not good for this discussion even we present different opinions on this matter. We are just open-source project contributors who voluntarily contribute to open-source projects such as Swagger Codegen, Swagger Parser, OpenAPI Generator and more.
Thanks and regards,
OpenAPI Generator Core Team

@grokify Your interpretation is consistent with my intent.  Just to clarify again, I have made the mistake in previous comments that the OAI TSC somehow has an opinion on this, and that was an incorrect statement.  This is an issue for the OAI marketing group and the business governing board which has representatives from all the member companies.  That is a number in the 40-50 people range.  My opinion only counts for so much.

This issue has been in a "cooling off" period, and we're not due to reconvene any OAI meetings until September.
I'm not anxious to restart conversation here until the OAI Marketing and Business Governance Board have had a chance to review the recent changes to the guidelines, the Linux Foundation guidelines, and the concerns raised by the OpenAPITools team.
But I have had a number of good conversations with William and with various OAI members, and would like to say just a couple of things for the record, hopefully none of which will be controversial:

There is no question that the OpenAPITools contributors have added a great deal of value to the OpenAPI ecosystem. No other API description language comes close to OpenAPI in its support for popular programming languages and frameworks, both client and server. This is true in large part because of the work that this team has done over the past several years in Swagger-Codegen, and now in OpenAPI-Generator. No one in the OAI is trying to exclude the OpenAPITools group, or single them out for extra scrutiny.
What we're discussing here is a new community guideline, and an experiment in self-assessment and self-enforcement. We are going to look at this carefully to make sure it's realistic, fair, aligned with Linux Foundation policies, and informed by best practices from other open source ecosystems. Wherever this lands, the guidelines will apply to everyone. If we're asking OpenAPITools to abide by these guidelines, we will also, in due course, ask other project owners to do the same, starting with the OAI members.

The discussion here seemed to have hit a wall, harder and faster than we anticipated. Maybe the circumstances leading up to the issue made it difficult.
We'll get back to the specific questions and concerns soon enough. In the meantime, I didn't want to leave this unresolved without stating the above points explicitly. I hope it helps.

There is no question that the OpenAPITools contributors have added a great deal of value to the OpenAPI ecosystem. No other API description language comes close to OpenAPI in its support for popular programming languages and frameworks, both client and server. This is true in large part because of the work that this team has done over the past several years in Swagger-Codegen, and now in OpenAPI-Generator. No one in the OAI is trying to exclude the OpenAPITools group, or single them out for extra scrutiny.

We appreciate the recognition of our voluntary contributions to the OpenAPI community.

What we're discussing here is a new community guideline, and an experiment in self-assessment and self-enforcement. We are going to look at this carefully to make sure it's realistic, fair, aligned with Linux Foundation policies, and informed by best practices from other open source ecosystems. Wherever this lands, the guidelines will apply to everyone. If we're asking OpenAPITools to abide by these guidelines, we will also, in due course, ask other project owners to do the same, starting with the OAI members.

Thanks for listening to our feedbacks and ensuring the same guidelines apply to everyone fairly.

The discussion here seemed to have hit a wall, harder and faster than we anticipated. Maybe the circumstances leading up to the issue made it difficult.

We'd no intention to make the conversation difficult. We definitely want to help make the guideline better for everyone in the OpenAPI community with our feedbacks and questions.
Thanks and regards,
OpenAPI Generator Core Team


feat(eslint-plugin): implemented fixer for no-export-all

Description
Implemented a fixer for the no-export-all rule. It only resolves one level, but ESLint applies fixes up to 10 times (source), so it should be fine.
Test plan
Tests were added.

This seems like a good candidate for the public distro of eslint. What do you think?

Yeah, I think that's what the TypeScript ESLint folks suggested to @dzearing as well. I think it makes sense, and I will try to upstream it, but I want to apply this in FURN first to weed out any issues.

nice work! I will give it a go later today and see it in action.

nice work! I will give it a go later today and see it in action.

I've added support for nested export *. Here's a sample diff from fluentui-react-native:
diff --git a/packages/theming/win32-theme/src/NativeModule/index.ts b/packages/theming/win32-theme/src/NativeModule/index.ts
index 6f8de92f..cf05c96a 100644
--- a/packages/theming/win32-theme/src/NativeModule/index.ts
+++ b/packages/theming/win32-theme/src/NativeModule/index.ts
@@ -1,3 +1,3 @@
-export * from './fallbackOfficeModule';
-export * from './getThemingModule';
-export * from './officeThemingModule';
+export { fallbackGetPalette, fallbackOfficeModule } from './fallbackOfficeModule';
+export { getThemingModule } from './getThemingModule';
+export type { CxxException, IEventEmitter, NativeColorNames, NativeColorRamps, OfficeThemingModule, PlatformDefaultsChangedArgs, PlatformDefaultsChangedCallback } from './officeThemingModule';
diff --git a/packages/theming/win32-theme/src/index.ts b/packages/theming/win32-theme/src/index.ts
index bde5e196..458283f4 100644
--- a/packages/theming/win32-theme/src/index.ts
+++ b/packages/theming/win32-theme/src/index.ts
@@ -1,6 +1,7 @@
-export * from './createOfficeTheme';
-export * from './createPartialOfficeTheme';
-export * from './NativeModule/index';
-export * from './paletteFromOfficeColors';
-export * from './createOfficeAliasTokens';
-export * from './createBrandedThemeWithAlias';
+export { createOfficeTheme } from './createOfficeTheme';
+export { createPartialOfficeTheme } from './createPartialOfficeTheme';
+export { fallbackGetPalette, fallbackOfficeModule, getThemingModule } from './NativeModule/index';
+export type { CxxException, IEventEmitter, NativeColorNames, NativeColorRamps, OfficeThemingModule, PlatformDefaultsChangedArgs, PlatformDefaultsChangedCallback } from './NativeModule/index';
+export { paletteFromOfficeColors } from './paletteFromOfficeColors';
+export { createOfficeAliasTokens } from './createOfficeAliasTokens';
+export { createBrandedThemeWithAlias, getCurrentBrandAliasTokens } from './createBrandedThemeWithAlias';


BUG: write_surface doesn't write in same reference frame as read_surface

write_surface doesn't seem to write in the correct coordinates system. However, this is visible in freeviewer not in the mne viz functions.
To reproduce the error (you have to copy/paste subjects/sample into subjects/sample_test since it modifies the file in a bad way.)
import os.path as op
from mne.viz import plot_bem
from mne.datasets import sample
from mne.surface import read_surface, write_surface
data_path = sample.data_path()

# the raw file containing the channel location + types
raw_fname = data_path + '/MEG/sample/sample_audvis_raw.fif'
# The paths to freesurfer reconstructions
subjects_dir = data_path + '/subjects'
subject = 'sample_test'

fname = op.join(subjects_dir, subject, 'bem', 'inner_skull.surf')
coord, faces = read_surface(fname)
write_surface(fname, coord, faces)

plot_bem(subject=subject, subjects_dir=subjects_dir, orientation='coronal')

plot_bem plots as expected:

but in freeview, we now see a misalignment:

Can you try using nibabel to read and write the surfaces to see if they
have the same problem?

What is the nibabel function to read surfaces?

From Googling "nibabel read freesurfer surface":
http://nipy.org/nibabel/reference/nibabel.freesurfer.html#nibabel.freesurfer.io.read_geometry

From Googling "nibabel read freesurfer surface":

ouch.
Yes same error, I'll open an issue there.

We might have contributed the code there actually, not sure :) I'll try to
take a look Monday. I've seen something like this before, but assumed it
was a Freeview problem. I'm not aware of any coordinate frame information
on the file, and we just do simple read and write with no transformations,
so I'm not sure why it would happen.
The original (not yet overwritten) surface looks okay though, right?

yes they look fine.
On 4 June 2016 at 16:43, Eric Larson<EMAIL_ADDRESS>wrote:

We might have contributed the code there actually, not sure :) I'll try to
take a look Monday. I've seen something like this before, but assumed it
was a Freeview problem. I'm not aware of any coordinate frame information
on the file, and we just do simple read and write with no transformations,
so I'm not sure why it would happen.
The original (not yet overwritten) surface looks okay though, right?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/3281#issuecomment-223777265,
or mute the thread
https://github.com/notifications/unsubscribe/AEp7DHZ4HQc4qK1MpRXVYx-V34US1RQ_ks5qIeN2gaJpZM4IuKG-
.


Publish 5/27/2021 3:30 PM PT

Docs Build status updates of commit 88a8ce1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

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

skype/skype-ps/skype/Grant-CsTeamsFeedbackPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

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

teams/teams-ps/teams/Connect-MicrosoftTeams.md
:white_check_mark:Succeeded
View (teams-ps)

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


Gyro implementation for Android

This is a continuation of a former pull request, https://github.com/libgdx/libgdx/pull/3361.  I've been procrastinating on finishing this up as I'm unfamiliar with the rebase command and needed some schooling, which I acquired here, http://stackoverflow.com/questions/33829117/git-squash-rebase-master-history-concerns

If I got it right this PR replaces #3361. If so, please close it.

@davebaol Okay, I've closed https://github.com/libgdx/libgdx/pull/3361 .

Looks good, merged!

@badlogic , Awesome!

@snovak Would be nice if you could update the wiki page I created: https://github.com/libgdx/libgdx/wiki/Gyroscope

@intrigus I am gunning for this.  I just have to get a few more things out of the way until I can get to it.  Thanks for putting that together!


store: Remove extra panics

These type assertions check for failure, and panic in the failure case. A simple type assertion that doesn't check for failure would accomplish the same thing. Use these instead to simplify the code and avoid confusion.
cc @aluzzardi @cyli

LGTM


specification: status_code definitions are missing

Insert status check section says:

For status code definitions, please refer to Check.

Check page does not have a status code definition table.

404 No such this insertion is in progress

How could this happen? If the repo does not know about an insertion, it would not be publishing check messages.

404 No such this insertion is in progress

How could this happen? If the repo does not know about an insertion, it would not be publishing check messages.

Ah yes, you're right. Will address it in next commit.

Then, the definitions need to cover both insertion and deletion.


Display messages of unhandled c++ exceptions on Windows

When a C++ exception was thrown from a mod or from Geometry Dash itself, rather than displaying the error code 0xE06D7363, attempt to also display the error message of the exception.

idk it probably works its windows only anyway


IF not coloured

ISO 2002 conditionals are not coloured like $if directives.
       procedure division.
           >>IF 1 = 1
               display 'test'
           >>END-IF
           goback.

Fixed, so close the issue


Production Fixes for V1

This epic is for bugs and fixes identified in the production system.

Competed v1 work. We've now moved to v2 with the new Corporate and Project console. Closing ticket.


Add NodeAffinity in sidecar and driver pods

Pull request checklist

This pull request fixes the following issue:

https://github.com/IBM/ibm-spectrum-scale-csi/issues/626

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature Enhancement
[ ] Test Automation
[ ] Code Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Community Operator listing
[x] Other (please describe):

What is the current behavior?

CSI driver and sidecar pods were not having architecture based node affinity.
What is the new behavior?

Sidecar pods(attacher, snapshotter, provisioner, resizer) includes arch based affinity.
Driver pods includes arch based affinity.
Affinity:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
            - ppc64le
            - s390x

How risky is this change?

[x] Small, isolated change
[ ] Medium, requires regression testing
[ ] Large, requires functional and regression testing

Affinity
Attacher pods
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
            - ppc64le
            - s390x
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - ibm-spectrum-scale-csi-attacher
        topologyKey: kubernetes.io/hostname

Provisioner pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
            - ppc64le
            - s390x

Snapshotter pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
            - ppc64le
            - s390x

Resizer pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
            - ppc64le
            - s390x

Driver pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - moni-csi-worker-2.fyre.ibm.com

In case of driver pods, arch based affinity is not visible in the pods, however affinity is present in the Daemonset resource.
This seems to expected behavior as per this documentation: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled

In case of driver pods, arch based affinity is not visible in the pods, however affinity is present in the Daemonset resource.
This seems to expected behavior as per this documentation: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled
Private build: quay.io/nitish3356/csi:operator-affinity


Turn on television_modern.tscn

The sprites for the Cogito Logo were deactivated and that made me sad, so I had to change it :)

Since this is now getting 2 weeks old, I dare to add some screenshots.
Without current master from like 10 min ago:

With this PR:

Hey, sorry for the delay looking at this. Since this is purely cosmetic, I prioritized some of the other PRs and issues first.
I'm travelling today/tomorrow, but will see if I can take a look at the end of the week.


RA causes regular unnecessary rebuilds

Some time recently, I started getting a lot of unnecessary rebuilds : ./miri run and ./miri test would start by building libc, even though I had just recently completed a full build so there is no need to re-build all the dependencies.
Here is a reproducer:

Close vscode, rm -rf target
./miri build
./miri check
./miri build does nothing, finishes immediately (as it should)
start vscode, wait until RA is done with all its indexing etc
close vscode
./miri build now does a rebuild!

It's not a full rebuild, but some crates to get rebuilt:
$ ./miri build
   Compiling libc v0.2.112
   Compiling memchr v2.4.1
   Compiling log v0.4.14
   Compiling aho-corasick v0.7.18
   Compiling getrandom v0.2.3
   Compiling parking_lot_core v0.8.5
   Compiling atty v0.2.14
   Compiling memmap2 v0.2.3
   Compiling perf-event-open-sys v1.0.1
   Compiling rand_core v0.6.3
   Compiling parking_lot v0.11.2
   Compiling rand_chacha v0.3.1
   Compiling measureme v10.1.0
   Compiling regex v1.5.5
   Compiling rand v0.8.4
   Compiling env_logger v0.9.0
   Compiling miri v0.1.0 (/home/r/src/rust/miri)
    Finished dev [optimized + debuginfo] target(s) in 25.60s
   Compiling dirs-sys v0.3.6
   Compiling directories v3.0.2
   Compiling cargo-miri v0.1.0 (/home/r/src/rust/miri/cargo-miri)
    Finished dev [optimized + debuginfo] target(s) in 2.05s

This is rather annoying. Something RA does (potentially in combination with the somewhat special setup in the Miri repo) seems to destroy the build cache. This also never stops, each time I restart vscode, the next ./miri build does a bunch of work it should not have to do.
Here are my vscode settings:
{
    "rust-analyzer.rustc.source": "discover",
    "rust-analyzer.linkedProjects": [
        "./Cargo.toml",
        "./cargo-miri/Cargo.toml"
    ],
    "rust-analyzer.checkOnSave.overrideCommand": [
        "./miri",
        "check",
        "--message-format=json"
    ],
    "rust-analyzer.buildScripts.overrideCommand": [
        "./miri",
        "check",
        "--message-format=json",
    ],
    "rust-analyzer.rustfmt.extraArgs": [
        "+nightly"
    ],
}

Adding this to my workspace config fixes the issue:
    "rust-analyzer.cargo.buildScripts.enable": false,
    "rust-analyzer.procMacro.enable": false,

So it seems to have something to do with the build script / proc macro support of RA. @fee1-dead any idea what might be happening here?

I think the proc macro support is broken on nightly right now

I think it might have to do with this hack where RA sets RUSTC_WRAPPER or RUSTC or so to speed up the build -- which however means that some build scripts, like that of libc, are being re-run, since they depend on those env vars.

Try setting cargo.buildScripts.useRustcWrapper to false.

I can't find such a setting in the UI; is this the right JSON snippet?
    "rust-analyzer.cargo.buildScripts.useRustcWrapper": false,

I think so. Does that help?

No, it still rebuilds libc when I start vscode, wait until RA is fully loaded (which takes forever with proc macro support turned on), and then do ./miri build again.

Closing in favor of https://github.com/rust-lang/rust-analyzer/issues/13011.


Intermittent: java.net.SocketException: Unexpected end of file from server

Hi,
In this tutorial
https://www.baeldung.com/docker-test-containers, or more specific
https://github.com/eugenp/tutorials/blob/master/testing-modules/test-containers/src/test/java/com/baeldung/testconainers/GenericContainerLiveTest.java

I got this error intermittently:
java.net.SocketException: Unexpected end of file from server

Seems like the container is shutdown before the request has been served completely. Is there away to avoid this ? Add buffer time between test finish time and the time the container is shutdown and removed ?
Thanks,
Tuan

@tvdinh We have an internal ticket logged about this issue. I will keep this ticket updated with our progress.

@eric-martin: Any progress on this ?

No progress yet. The ticket is still in our queue.

Jumping in here with an update, as it's been quite a while.
Unfortunately, we can't reproduce it (the team tried to do that on several platforms). So, it either got fixed in the meantime, which is the one advantage of being late :) - or it wasn't there.
Hope that helps, @tvdinh
Closing this one.
Cheers,
Eugen.


Make "Publish Nargo" workflow automatically release as a pre-release

Problem
Currently when we manually publish using a workflow dispatch, it sets that release to be the official release whereas we want it to be a pre-release
Happy Case
When we fill in the below workflow dispatch

It should release as a pre-release
Alternatives Considered
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

This is now fixed


V4-- OrderedMap.concat is not a function.

What happened
In V4 RC9, using an OrderedMap.concat fails. I'm looking into #1373 as a potential bad merge, where .concat was supposed to alias .merge but something didn't go as planned.
How to reproduce
Given a package.json:
{
  "name": "immmutable-bug-simple",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "immutable": "^4.0.0-rc.9"
  }
}

and an index.js of
const immutable = require('immutable');

const orderedMap = immutable.OrderedMap();
const orderedMap2 = immutable.OrderedMap();
orderedMap.concat(orderedMap2)

I get:
TypeError: orderedMap.concat is not a function
    at Object.<anonymous> (/Users/rb/code/experiment/immmutable-bug-simple/index.js:5:12)

I just verified the same behavior on .map.
const map = immutable.Map();
const map2 = immutable.Map();

map.concat(map2)

TypeError: map.concat is not a function
    at Object.<anonymous> (/Users/rb/code/experiment/immmutable-bug-simple/index.js:9:5)

Hi @randallb - We already have a fix for that in the master branch, it will be out with the next release :)
https://github.com/facebook/immutable-js/pull/1402


Update profile-mssql.md

The content for dbt-sqlserver is very old. I have updated it.
Description & motivation

To-do before merge

awesome, thanks @mikaelene! Merging this :)


add link to Slack to docs

no matter where you are on the docs...
in the top right it will link to the Slack:

as well as the in the footer:

this works for me @TyDunn