How to route a C# controller method?

Hi,
I am using HttpClient for my server side requests.  If I define the route attribute over C# controller method then requests are not bring served.  Why?
Can any suggest me?
I am using preview 9 latest update.
Thank you for your assistance.

Show your controller code pls

Hello! Thanks for contacting us. This sounds like a general question about using ASP.NET Core. While we try to look at and respond to all issues, for questions like this we recommend posting to a community support group like Stack Overflow with the asp.net-core tag.


Unhandled std::out_of_range exception in assertpmux pass

Steps to reproduce the issue
I wasn't able to reproduce this in a smaller example than this:
test.zip
unzip test.zip
yosys test.ys

Expected behavior
No abnormal termination.
Actual behavior
Yosys terminates due to an exception:
...
3. Executing ASSERTPMUX pass (add asserts for $pmux cells).
Adding assert for $pmux cell sm83_dbg_ifc.$procmux$106.
Adding assert for $pmux cell sm83_dbg_ifc.$procmux$497.
Adding assert for $pmux cell sm83_dbg_ifc.$procmux$512.
Adding assert for $pmux cell sm83_dbg_ifc.$procmux$668.
terminate called after throwing an instance of 'std::out_of_range'
  what():  dict::at()
Aborted

Simplified testcase:
module \top
  wire input 3 \A
  wire width 2 input 2 \B
  wire width 2 input 1 \S
  wire \Y
  cell $pmux \my_pmux
    parameter signed \S_WIDTH 2
    parameter signed \WIDTH 1
    connect \A \A
    connect \B \B
    connect \S \S
    connect \Y \Y
  end
end


First element values disappear on existing list

Hey,
I have existing list but all text for first element (that I use in valueNames) disappear.
JS
var options = {
            valueNames: [ 'name', 'price'],
            item: 'itemBlock'
        };

var list = new List('test', options);

HTML

Name 1

3.33

Name 2

6.66

Name 3

9.99

(I'm familiar that multiple id's are bad practice but this is how plugin require, right?)
And now, Name 1 and 3.33 would disappear while others will work fine.
What am I doing wrong here? If I c/p some example from the page, it works perfectly. Can you use div's for this or just ul/li or table?
Thanks

Ah, no, you're combining two initiation methods at the same time. Id's and the item option is not needed if you have items in the list on initiation. Just remove the id's  and item.


Per columns headers

Hi, for my needs I needed to create extra headers only for some columns. So I created this new feature.
'perColumnsHeaders' is the new property:
Name: perColumnsHeaders,
Type: Array
Description: Title(s) for single column data (ex: ['titleCol0',,TitleCol2,,TitleCol4])
Default: null

@alessandrofuda hi ! is it a feature to display data as a matrix ?

Hi team!
I don't remember very well, but it was something like this:
over header1
over header3
over header6

Field1 Field2 Field3 Field4 Field5 Field6 Field7
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
value 	value 	value 	value 	value 	value 	value
It generates the "over headers" for one or more (or all) Fields.
I'm available for further informations,
Good day, bye
Alessandro
Il 05/07/21 12:27, flrnt ha scritto:

@alessandrofuda https://github.com/alessandrofuda hi ! is it a
feature to display data as a matrix ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jecovier/vue-json-excel/pull/141#issuecomment-874000628,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFP43KMQE7PZW5UTP3BRZUTTWGCITANCNFSM4U2ZF2VQ.

--
Alessandro Fuda
via priv. Stefanardo da Vimercate, 28
20128 Milano
mob. (+39)<PHONE_NUMBER>
p.iva<PHONE_NUMBER>7


CA Electric Balancing Authority Areas addition

Ready for review now. The PR adds the CA Electric Balancing Authority Areas as a spatial subsetting option (this includes the CALISO polygon).
Marked as a draft for now until the geoparquet file is added to the catalog, but the code base is all here. Tests are failing now I believe because I load the file using gpd.read_parquet and there's some additional dependencies required to do this? Hopefully once the file is read from the catalog this will go away.
There's some strangeness with the shapefile because there are two polygons for CALISO, one being really really small. I just removed the tiny one but will discuss with others before merging this. I have a notebook that demonstrates this well.
Related links:
Trello: https://trello.com/c/xgslLlS2/307-add-caliso-polygon-to-location-subsetting-options
Shapefile: https://cecgis-caenergy.opendata.arcgis.com/datasets/147c83114a3f4ff8a82225e3d6c24857_0/explore?location=35.740616%2C-117.279254%2C5.00

The CALISO map and data didn't show up with all other options set to the default. Other areas look great to me.

Great catch, thanks! I just fixed this.


AMD webpack sample deprecation notice.

This adds a deprecation notice to the 4.x/webpack/README. We now recommend using ES modules.

Good catch, it's removed.


Backport of gradle build to zk3.3.x

This all still needs to be tested against a real push to sonatype, e.g. ./gradlew uploadMavenCentral -Prelease=true

Did you see my other comment? I'm still getting an error doing a build due to the signing


Provider produced inconsistent result after apply

Getting the following errors when applying Terraform
╷ │ Error: Provider produced inconsistent result after apply │  │ When applying changes to uptime_check_http.http_example.com_8443, provider │ "provider[\"registry.terraform.io/uptime-com/uptime\"]" produced an unexpected new value: .port: was cty.NumberIntVal(8443), but now cty.NumberIntVal(0). │  │ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╷ │ Error: Provider produced inconsistent result after apply │  │ When applying changes to uptime_check_http.http_example.com, provider "provider[\"registry.terraform.io/uptime-com/uptime\"]" produced an unexpected │ new value: .headers: element "api-key" has vanished. │  │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Hi @karlo-hiq, thank you.
We'll try to reproduce it and fix it in the nearest releases.

@karlo-hiq, the first problem is that when we create an HTTP check with a custom port, we also need to set the port value in the port property. The latest version of the provider now checks for this.
The second issue is on the API side. Unfortunately, you need to use capital letters for the headers. Please use Api-Key instead of api-key.
I’m closing this issue for now unless there’s something else related to these cases.
Sorry for the delay.
Let me know if you need any more changes!


Impossible to ban member on Elkarte 2.0

I tried to apply a ban, but I get an error:
preg_match() expects parameter 2 to be string, array given
The member to ban is https://www.elkarte.net/community/index.php?action=profile;u=1337 (for spam)

Should be fixed now

There is something wrong in the ACP interface

Looks like a side menu issue ... todo

The layout issues should now be sorted.

Yep, it is solved now, I was able to ban the member and also access correctly the admin area. That layout issue was present in other areas of ACP, now everything seems to work fine.

Yeah for the ban 🔨


Introduce the use of function attribute (attribute)

Begin using it to mark functions that have a better version such as read_line() which has a better version: readLine() that uses a byte buffer.
Through out the code base, if we see functions that have a better version of itself, we should definitely mark it as deprecated with a meaningful deprecation message.
In effect, the GCC compiler will through a warning level message on the console at compile time reporting these deprecated functions.

@ThakeeNathees, what do you think about this? I think we should encourage it as we don't want to leave out the different versions of a function doing the same thing for a long time in the code base right?

Also, we can learn more about function attributes here: https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Attributes.html

@xSavitar the attribute (__attribute__)  isn't portable, for MSVC it should be __declspec(deprecated), this should fix the build status.
But the function read_line is just there for temporary, (that's why it's snake_case) and I'll fix it soon. And even if it's a function we're deprecating, it's something used internally, and no point in deprecating it.
Also even if it's a public function, we haven't made a release yet, and currently, no one is using it.
The depreciation is unnecessary here.

Fixed the Windows build failures. You can land this @ThakeeNathees if it looks good to you. As we identify more functions and their better versions, we can deprecate the former. :)


Sample Altenburg_concerto_C_major.mei: Grace notes aren't under beam

Judging from the PDF, this should be corrected. The changes validate against the 3.0.0 schema.

Thanks!


Auto imports including full path

Issue Type: Bug
Not sure whose the cause, VSC or TS, but with VSC 1.25 and TS 2.9.2 the auto-add import process is broken and I end up with something like import { FormGroup } from '../../../../node_modules/@angular/forms'; where previously it would do import { FormGroup } from '@angular/forms';
Nothing changed in any configs
VS Code version: Code 1.25.0 (0f080e5267e829de46638128001aeb7ca2d6d50e, 2018-07-05T13:11:58.697Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4930MX CPU @ 3.00GHz (8 x 3193)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
31.93GB (19.04GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe C:\Users\cs\source\repos\3SS\Cheetah\FrontEnd\hydra

Screen Reader
no

VM
0%

Extensions (15)

Extension
Author (truncated)
Version

bracket-pair-colorizer
Coe
1.0.59

jshint
dba
0.10.19

vscode-eslint
dba
1.4.12

EditorConfig
Edi
0.12.4

tslint
eg2
1.0.33

auto-rename-tag
for
0.0.15

dotnet-test-explorer
for
0.3.1

csharpextensions
jch
1.3.0

python
ms-
2018.6.0

csharp
ms-
1.15.2

debugger-for-chrome
msj
4.7.0

vscode-coverage-gutters
rya
2.0.1

code-settings-sync
Sha
2.9.2

rewrap
stk
1.9.1

html-css-class-completion
Zig
1.17.1

Had to rollback to 1.24 because of this bug. Renders entire IDE useless for Angular development so far.

Same issue here. Re-installed 1.24 on Mac.

Same issue on Windows 10

Duplicate of #53597
Either upgrade to VS Code insiders or upgrading your workspace to use typescript@next by following these instructions


Relax generic requirement on ClusterItem on clustering related interfaces

Thanks for stopping by to let us know something could be better!

PLEASE READ
If you have a support contract with Google, please create an issue in the support console. This will ensure a timely response.
Discover additional support services for the Google Maps Platform, including developer communities, technical guidance, and expert support at the Google Maps Platform support resources page.
If your bug or feature request is not related to this particular library, please visit the Google Maps Platform issue trackers.
Check for answers on StackOverflow with the google-maps tag.

Is your feature request related to a problem? Please describe.
Currently the library requires you to implement ClusterItem on your data classes. This can be problematic when you don't own those classes and/or producers of the data (or just don't wan't your model to depend on this particular library).
Describe alternatives you've considered
Creating wrapper implementing ClusterItem. This solution gets slow with large datasets/fast changing data. Additionaly it's just plain waste of memory.
Describe the solution you'd like
Remove the extends ClusterItem from interfaces like ClusterRenderer and Algorithm and thus in unopinionated manner enable other techniques of handling this problem.

ClusterManager is constrained to ClusterItem as well. But it seems it's only transitive dependency.

Relaxing the APIs for clustering to accept any object, rather than an object conforming to an interface defined in the library (like ClusterItem), presents issues that changes the API in a drastic way. Specifically, the APIs could be used in ways that were not designed to and these issues would manifest as run-time errors. We can change the signatures to throw but I don't agree that this is a preferable interface.

Thanks for taking your time and considering my proposition.

We can change the signatures to throw but I don't agree that this is a preferable interface.

Totally agree. Runtime error solution would be detrimental to quality of the library.

e.g. you can pass an object that contains no LatLng

This is manageable even without runtime errors though. My proposition would be to enforce LatLng, Title, Snippet by passing functions (or SAM interfaces) to ClusterManager's constructor, that would Accept T and return LatLng (and T  -> Title, T -> Snippet respectively). There can be additional factory function with constraint to T extends ClusterItem. Functions from ClusterItem to LatLng are trivial. There would be only changes to the API of the constructor. You could easily migrate those by just using the above mentioned factory function.
This solution hides this new implementation detail behind the factory and thus should not have any negative effect on ease-of-use, safety or familiarity. It just optionally shifts the function implementation from the model.
Is this something you would be interested in? If you think this could be beneficial, or need some POC I can submit PR (or we can continue the debate here). If you are still convinced this isn't something the library would benefit from, please feel free to close this issue.

Can you comment here what the API changes would look like so we can get a picture of what you intend? Doesn't need to be a full PR with implementation, just what the interface changes would look like.

Here is a gist with proposed changes.
The only changes in API were:

removing the ClusterItem generic constraint from all interfaces
adding getters to constructors
providing a factory for T extends ClusterItem that has the same shape as current constructors.

Here is a example of using a getter instead of a function provided from an interface.
Basically the idea is to provide a proof of existence of T -> LagLng relationship by passing it as a value instead of forcing it to be implemented in the model.

Thanks for the detailed gist you shared, I definitely have a clearer picture of what you mean now. To summarize, this API proposal enables clustering models that do not implement ClusterItem which is desirable when you don't own the model or when implementing the interface is undesirable for whatever reason. Creating a wrapper object is currently the workaround which has memory implications specially if you have lots of objects.
I'm certainly not against this change but my hesitation is that this is a breaking change and several implications (need to update our docs here on GitHub and on https://developers.google.com/maps/documentation/android-sdk/utility). Given that we just had a major version bump, this is something we can consider for the next major version change. If more people in the community feel strongly about this, we can reprioritize.

 Currently using wrapper

@barbeau @arriolac This feature request is slowly getting to be 2 years old. It'd be nice to have it either implemented or refused. I can provide a full PR if that'd help.

Still valid.

@arriolac  @barbeau There seems to be a new major release of the library without any activity on this issue. Is there anything I can do to help this situation?

There is currently a PR adding clustering capability to android-maps-compose . Under the hood, this library is used as the implementation.
It would be a good time to resolve this tech debt so that it does not affect other projects.
I can submit the proposed changes as a PR, if the change are deemed as benefitial for this library.

I'm curious to know more about these concerns:

Creating wrapper implementing ClusterItem. This solution gets slow with large datasets/fast changing data. Additionaly it's just plain waste of memory.

Have you seen evidence that this is actually slow? A wrapper object should be very lightweight, essentially just holding a reference to an object already on the heap. Fast to instantiate and takes very little memory.
I think that's worth verifying with data before making a change like that. For both Java and Kotlin, it's idiomatic to pass objects that fit an interface that provides necessary info. It's less common to pass an arbitrary object and separately pass a function for looking up that info. I personally would argue it's more surprising.

As a personal anecdote I've had a map with roughly 35000 markers. The app state was kept in a purely Kotlin module (multiplatform app), so it was not possible to persist the objects in the app state. We either had to recreate 35k of cluster items for each re-render, that was of course a huge performance hit, or keep a local state and synchronize it, making the whole process more complex and harder to maintain. It really felt like unnecessary complexity.
If needed we can of course profile both solutions. But I'd argue that performance is not the only factor here.

For both Java and Kotlin, it's idiomatic to pass objects that fit an interface that provides necessary info

For Java I agree.

It's less common to pass an arbitrary object and separately pass a function for looking up that info

For Kotlin I find this very common. As an example from stdlib you can see there are extension functions on Iterable sorted and sortedBy where sorted requires you to implement Comparable and sortedBy finds the behavior via provided lambda (additionally there is sortedWith that receives comparator). This pattern is very common in stdlib and from personal experience in Kotlin codebases overall.

I personally would argue it's more surprising.

I'm not arguing for removal of ClusterItem, or any functionality based on it. Only to enable developers not to implement a specific interface. In the gist I provided, you can see, the current behavior is kept via provided factory function, so there should be no surprise for developers.

not stale

@wangela This issue is now more than 3 years old. Is there anything I can do to help this get moving?

We'll take a look and re-evaluate in the coming weeks.


Compatibility and Test Upgrades from Takbal

@takbal I really appreciate all the effort you put into #79. I'm using this pull request to track my progress as I work through understanding the changes you made.

The compatibility changes in this commit from @takbal allowed the tests to pass for me on both OS X El Capitan and Ubuntu 14.04.
Like @takbal mentioned, I also saw that the plots.jl tests took significantly longer with Julia 0.4.2 than they ever did previously, probably because it has over 3.8 GB of memory allocations for some reason. My guess is that this is internal to Winston.jl rather than this package, which is unfortunate but something we'll probably just have to deal with.
I'm pretty sure that the test failures on Travis are due to LibExpat.jl issues rather than related to this package. I still don't know what to do about this, but no machine I've ever tested on has ever reproduced this problem with LibExpat.jl, so I believe it to be Travis-specific.

The compatibility changes in this commit from @takbal allowed the tests to pass for me on both OS X El Capitan and Ubuntu 14.04.
Like @takbal mentioned, I also saw that the plots.jl tests took significantly longer with Julia 0.4.2 than they ever did previously, probably because it has over 3.8 GB of memory allocations for some reason. My guess is that this is internal to Winston.jl rather than this package, which is unfortunate but something we'll probably just have to deal with.
I'm pretty sure that the test failures on Travis are due to LibExpat.jl issues rather than related to this package. I still don't know what to do about this, but no machine I've ever tested on has ever reproduced this problem with LibExpat.jl, so I believe it to be Travis-specific.


Grid col-0

At the moment, all of the grid classes for col-0 make the width 0 in the RFC. Wouldn’t you prefer for it to display none? That seems like the accessible answer.

Would make sense to me! Mind leaving this comment on the RFC? Just helps to keep track of everything related to it there since the issues would correspond to code in the repo 👍


Restrictions on Web Crawling

Hi all,
I was wondering if there were specific restrictions on web crawling certain sites?
For example if one tried to web crawl Medscape:
from trafilatura.spider import focused_crawler
from trafilatura.spider import is_still_navigation

homepage = 'https://www.medscape.com/'
# starting a crawl
to_visit, known_urls = focused_crawler(homepage, max_seen_urls=1000000, max_known_urls=1000000)
print(known_urls)
is_still_navigation(to_visit)

This returns only a single link: {'https://www.medscape.com/'}
Any input would be greatly appreciated.
Thank you,
Enrico

Hi @conceptofmind, thanks for your feedback! There is a bug somewhere in the link analysis and relative links are not being handled as they should.

It turns out the issue also involves an issue with robots.txt parsing of https://www.medscape.com/robots.txt.


[RFC] MXNet: Improve the build with DNNL, MKL, and OpenMP.

[Author of the RFC: @TaoLv ]
Problem statement
This RFC targets discussing the strategies for building MXNet with Intel DNNL, MKL, and different OpenMP runtimes for different platforms. It will help to address (or mitigate if not fully addressed) the issues [1][2][3][4][5][6] and pave the way towards the CMake build system for the project. After all of these are in place, we can expect a better build experience across different platforms and keeping the promising performance on Linux.
The content can be divided into the following parts:

Clear the build flags for DNNL, MKL BLAS, OpenMP;
The build logic and decisions for DNNL;
The build logic and decisions for MKL BLAS;
Other considerations, eg. performance and interoperability.

Proposed solutions
Build Flags
We propose to keep/promote the flags below in the future CMake build system:

Flags
Options
Description

USE_MKLDNN   (or USE_DNNL)
ON, OFF
Whether to build MXNet with DNNL library to accelerate   some operators.

USE_BLAS
openblas, mkl,   apple, atlas
Choose BLAS library.

USE_OPENMP
ON, OFF
Whether to use OpenMP threading model.

MKL_USE_STATIC_LIBS
ON, OFF
Whether to link static libraries of MKL.

MKL_USE_ILP64
ON, OFF
Turn it ON when INT64 tensor is enabled.

And deprecate the flags as follows:

Flags
Justifications

USE_MKLML
MKLML library has been EOL and removed since MKL-DNN v1.0.

USE_MKL2017
MKL2017 integration has been removed from MXNet since   MKL-DNN integrated.

USE_STATIC_MKL
Replaced by MKL_USE_STATIC_LIBS

USE_MKL_IF_AVAILABLE
Duplicate with USE_BLAS. Confusing when both of them are   set.

MKL_USE_SINGLE_DYNAMIC_LIBRARY
We don’t want users to link libmkl_rt.so which depends on   more explicit control during runtime. Removing it can make the code behavior   and library linkage more deterministic.

Build with OpenMP
As we all know, linking multiple OpenMP runtimes in a single application is error prone. To mitigate the long standing issue of OpenMP conflicts in MXNet, we suggest to adopt the same default linking behavior from DNNL library. That is to dynamically link the OpenMP runtime library which is provided by the compiler/system. It will help us on:

Easing the build logic for choosing different OpenMP runtimes;
Mitigating the interoperability of different OpenMP runtimes in different compiler ecosystems.

Users can decide whether to enable OpenMP threading by the USE_OPENMP flag. Once it’s set to OFF, the backend libraries like DNNL or MKL BLAS should also disable OpenMP threading and run in a sequential mode.
With that being said, there is no need to distribute the source code of LLVM OpenMP or build it from scratch. We can rely on compilers to pull in different OpenMP runtimes.
Please refer to the OpenMP.cmake module of DNNL for more implementation details.
(A more radical approach is to provide an option for users to choose a different OpenMP runtime. That can lead to better performance, eg. link Intel OpenMP explicitly, but is more risky.)
Build with MKL-DNN (or DNNL)
Intel MKL-DNN was renamed with DNNL in its v1.1 release. Since then, the MXNet community has been working on the transition to DNNL to leverage the latest features and optimizations from the library. That includes using the string “DNNL” or “dnnl” for future development and communication. We propose to promote the flag “USE_DNNL” since MXNet 2.0 and start deprecating “USE_MKLDNN” at the same time.
DNNL source code resides in the 3rdparty/mkldnn folder of the MXNet repository and is released and distributed along with MXNet source code. If one wants to build MXNet with DNNL to accelerate the execution on Intel CPU, she/he needs to enable -DUSE_DNNL=ON in CMake. However, this flag has been set to ON by default for all platforms except edge devices. On the contrary, to disable the DNNL acceleration, one needs to set -DUSE_DNNL=OFF explicitly in the CMake command line or the CMake configuration file.
As both MXNet and DNNL are under quick development with different release cadence, we decide to link the DNNL library into MXNet statically to avoid mis-linking in the user's environment. Given this, we need to set DNNL_LIBRARY_TYPE to STATIC when building DNNL.
Some additional flags to build DNNL:

DNNl_CPU_RUNTIME: Need set it to SEQ explicitly when USE_OPENMP=OFF;
DNNL_ARCH_OPT_FLAGS: Need pass compiler options to this build flag in string. Eg. -march or -mtune for GCC.
MKLDNN_BUILD_TESTS and MKLDNN_BUILD_EXAMPLES: We set these two flags to OFF to speed up the compilation.

One thing that needs to be taken care of is that the header dnnl_config.h and dnnl_version.h will be generated dynamically during compilation and will be copied to the installation destination when calling make install. That means these two headers are not distributed with DNNL source code. For downstream projects which are including these headers need to find them in the installation path rather than the source code path.
Build with MKL BLAS
MXNet users can choose a BLAS library through the flag USE_BLAS which supports openblas, mkl, atlas, and apple for MacOS. To use Intel MKL BLAS, one can install it through apt or yum following the instructions from Intel: Installing Intel® Performance Libraries and Intel® Distribution for Python* Using APT Repository. MXNet also provides a tool script for Ubuntu, please refer to the ubuntu_mkl.sh under ci/docker/install.
For linking MKL BLAS to MXNet, we suggest following the advice from Intel® Math Kernel Library Link Line Advisor.
 As we can see from the advisor tool, we need note that:

Clang is not supported on Linux;
LLVM OpenMP runtime is not supported (thus the following configuration: MXNet + clang + MKL + linux should not be supported);
When using GCC on Linux, it’s suggested to link the GNU counterpart libraries and OpenMP runtime, eg. libmkl_gnu_thread.a/so and libgomp.so;
On Windows/MacOS, MKL BLAS can only be used with Intel OpenMP; (???)
When OpenMP is disabled, we need to link libmkl_sequential.a/so instead of libmkl_gnu/intel_thread.a/so;
For large tensors with one dimension size > INT32_MAX, to make MKL BLAS work, we need to link libmkl_intel_ilp64.a/so rather than libmkl_intel_lp64.a/so.

Given the constraints above, a typical CMake logic for MKL should look as follows. We still need to add more fine-grained checks for different platform and compiler combinations. In this proposal, we suggest linking MKL BLAS libraries dynamically. The are mainly two reasons to do so:

Statically linking MKL libraries will considerably increase the size of MXNet binary.
Statically linking MKL libraries needs recompilation in case of any changes in the MKL libraries.

Same as other third party dependencies, static linking will help us to better distribute MXNet to different systems and environments, without any unexpected functionality or performance issues. We provide the flag MKL_USE_STATIC_LIBS to enable static linking when it’s needed.
Anyway, disabling static linking is also supported by setting MKL_USE_STATIC_LIBS to OFF.

Performance and Interoperability

Performance

Although DNNL has provided many performance primitives to accelerate those NN related operators in MXNet, we still depend on MKL to improve the performance of other linear algebra, random number generation, and vector operations through it’s BLAS, VML, VSL libraries. We strongly encourage users to build MXNet with MKL BLAS and the community to release convenient binaries with MKL enabled.
It's common sense that Intel OpenMP outperforms other OpenMP runtimes on Intel CPUs. We also hope users will link to Intel OpenMP for better performance. But because we are suggesting to link the OpenMP runtime provided by the compiler in the above section, now the problem is that we need to enable the Intel compiler build process which seems to be broken at this moment [6].
Given this, the recommended build on Linux so far should be: GCC + MKL BLAS + DNNL + GNU OpenMP.

Interoperability of OpenMP

Though we can address the dual linkage of OpenMP in MXNet and hence remove the conflicts reported in [1], we still need to be aware of the risks in downstream projects. One possible scenario is described in [7]. When MXNet is linking with one OpenMP runtime and the user assembles it with another tool which is linking with another OpenMP runtime (or another version of the same OpenMP runtime), it’s still problematic. That’s why we’re suggesting to link OpenMP according to compiler and link it in dynamical way:

We assume that the OpenMP runtime has better interoperability in its own compiler ecosystem. Eg. GNU OpenMP in the GCC community.
Dynamically linking makes it possible for users to create symbolic links to workaround the conflict issue or pre-load another runtime.

References
[1] #17641
[2] #17366
[3] #10856
[4] #9205
[5] #11417
[6] #14086
[7] #8532

CC: @leezu, @TaoLv, @anko-intel

Thank you @akarbown for opening this RFC. It LGTM overall. Some minor comments / questions below:
I think MKL_USE_ILP64 does not need to be exposed to the user and we may re-use the MXNet USE_INT64_TENSOR_SIZE flag. We should switch to USE_DNNL sooner rather than later.
If ILP64 is used, we may be forced to static link MKL, to avoid symbol conflicts
with LP64 Blas libraries that could be loaded into the same process if users
import MXNet and NumPy in the same Python process. cc @access2rohit @Zha0q1

To use Intel MKL BLAS, one can install it through apt or yum following the instructions from Intel: Installing Intel® Performance Libraries and Intel® Distribution for Python* Using APT Repository.

We also need to support the upstream Ubuntu MKL packages which are available from Ubuntu 20.04 https://packages.ubuntu.com/focal/intel-mkl In my preliminary trial, the following patch works to find Ubuntu intel-mkl package (and may allow us to delete MXNet's FindMKL.cmake):
modified   cmake/ChooseBlas.cmake
@@ -47,16 +47,15 @@ elseif(BLAS STREQUAL "Open" OR BLAS STREQUAL "open")
   add_definitions(-DMXNET_USE_BLAS_OPEN=1)
 elseif(BLAS STREQUAL "MKL" OR BLAS STREQUAL "mkl")
   if (USE_INT64_TENSOR_SIZE)
-    set(MKL_USE_ILP64 ON CACHE BOOL "enable using ILP64 in MKL" FORCE)
+    set(BLA_VENDOR Intel10_64ilp)
+    find_package(BLAS)
   else()
-    if(MKL_USE_ILP64)
-      message(FATAL_ERROR "MKL_USE_ILP64 cannot be set without USE_INT64_TENSOR_SIZE; "
-              "Please set USE_INT64_TENSOR_SIZE instead of MKL_USE_ILP64.")
-    endif()
+    set(BLA_VENDOR Intel10_64lp)
+    find_package(BLAS)
   endif()
-  find_package(MKL REQUIRED)
+  find_path(MKL_INCLUDE_DIR mkl.h PATHS ENV MKLROOT PATH_SUFFIXES include mkl REQUIRED)
   include_directories(SYSTEM ${MKL_INCLUDE_DIR})
-  list(APPEND mshadow_LINKER_LIBS ${MKL_LIBRARIES})
+  list(APPEND mshadow_LINKER_LIBS ${BLAS_LIBRARIES})
   add_definitions(-DMSHADOW_USE_CBLAS=0)
   add_definitions(-DMSHADOW_USE_MKL=1)
   add_definitions(-DMXNET_USE_BLAS_MKL=1)

need to enable the Intel compiler build process which seems to be broken at this moment [6].

Is there any update on the ICC upstream compiler fix?

After USE_INT64_TENSOR_SIZE controls lp64/ilp64 MKL and I think we are already defaulting MKL_USE_STATIC_LIBS to true

If ILP64 is used, we may be forced to static link MKL, to avoid symbol conflicts
with LP64 Blas libraries that could be loaded into the same process if users
import MXNet and NumPy in the same Python process. cc @access2rohit @Zha0q1

I think even we should force static link at all time because of the performance boost of mkl over say openblas. Some cblas functions are a few times faster and lapack functions haven been seen to have 25x boost

I think we should force static link at all time because of the performance boost of mkl over say openblas

Static link and performance differences between mkl and openblas are two separate topics. Could you elaborate your reasoning?

I think we should force static link at all time because of the performance boost of mkl over say openblas

Static link and performance differences between mkl and openblas are two separate topics. Could you elaborate your reasoning?

Yes, my point is that if numpy uses openblas and mxnet uses mkl then we certainly do not want openblas to mask mkl

@pengzhao-intel @ciyongch @yinghu5 Please help to review.

We should switch to USE_DNNL sooner rather than later.

The proposal was drafted quite a while ago. Since then, DNNL library has been renamed to oneDNN to be consistent with the rest of oneAPI libraries [1]. Maybe we need also consider to use flag USE_ONEDNN? @mgouicem
[1] https://github.com/oneapi-src/oneDNN#oneapi-deep-neural-network-library-onednn

Thank you @akarbown for opening this RFC. It LGTM overall. Some minor comments / questions below:
I think MKL_USE_ILP64 does not need to be exposed to the user and we may re-use the MXNet USE_INT64_TENSOR_SIZE flag. We should switch to USE_DNNL sooner rather than later.
If ILP64 is used, we may be forced to static link MKL, to avoid symbol conflicts
with LP64 Blas libraries that could be loaded into the same process if users
import MXNet and NumPy in the same Python process. cc @access2rohit @Zha0q1

To use Intel MKL BLAS, one can install it through apt or yum following the instructions from Intel: Installing Intel® Performance Libraries and Intel® Distribution for Python* Using APT Repository.

We also need to support the upstream Ubuntu MKL packages which are available from Ubuntu 20.04 https://packages.ubuntu.com/focal/intel-mkl In my preliminary trial, the following patch works to find Ubuntu intel-mkl package (and may allow us to delete MXNet's FindMKL.cmake):
modified   cmake/ChooseBlas.cmake
@@ -47,16 +47,15 @@ elseif(BLAS STREQUAL "Open" OR BLAS STREQUAL "open")
   add_definitions(-DMXNET_USE_BLAS_OPEN=1)
 elseif(BLAS STREQUAL "MKL" OR BLAS STREQUAL "mkl")
   if (USE_INT64_TENSOR_SIZE)
-    set(MKL_USE_ILP64 ON CACHE BOOL "enable using ILP64 in MKL" FORCE)
+    set(BLA_VENDOR Intel10_64ilp)
+    find_package(BLAS)
   else()
-    if(MKL_USE_ILP64)
-      message(FATAL_ERROR "MKL_USE_ILP64 cannot be set without USE_INT64_TENSOR_SIZE; "
-              "Please set USE_INT64_TENSOR_SIZE instead of MKL_USE_ILP64.")
-    endif()
+    set(BLA_VENDOR Intel10_64lp)
+    find_package(BLAS)
   endif()
-  find_package(MKL REQUIRED)
+  find_path(MKL_INCLUDE_DIR mkl.h PATHS ENV MKLROOT PATH_SUFFIXES include mkl REQUIRED)
   include_directories(SYSTEM ${MKL_INCLUDE_DIR})
-  list(APPEND mshadow_LINKER_LIBS ${MKL_LIBRARIES})
+  list(APPEND mshadow_LINKER_LIBS ${BLAS_LIBRARIES})
   add_definitions(-DMSHADOW_USE_CBLAS=0)
   add_definitions(-DMSHADOW_USE_MKL=1)
   add_definitions(-DMXNET_USE_BLAS_MKL=1)

I'll take a look into it.

need to enable the Intel compiler build process which seems to be broken at this moment [6].

Is there any update on the ICC upstream compiler fix?

I don't know yet. I'll keep you posted as I'll get more knowledge on this issue.

The proposal was drafted quite a while ago. Since then, DNNL library has been renamed to oneDNN to be consistent with the rest of oneAPI libraries [1]. Maybe we need also consider to use flag USE_ONEDNN? @mgouicem

Yes, the library was renamed to oneDNN. It makes sense to rename the flag to USE_ONEDNN since this is the latest official name for the library.

Just using the upstream BLA_STATIC should be fine.

I'd like to reignite the discussion connected with the following areas and give some update:
• Removing MKL_USE_SINGLE_DYNAMIC_LIBRARY (mentioned in the 'Build Flags' RFC part)
• Dynamically linking the OpenMP runtime library which is provided by the compiler/system (mentioned in the 'Build with OpenMP' & 'Interoperability OpenMP' part)
• Having two runtime OpenMPs in the same process what resulted in the hang ('Interoperability OpenMP' part).
I think that knowing the root-cause of the hang (described here: #18255) it's worth to reconsider leaving the MKL_USE_SINGLE_DYNAMIC_LIBRARY and using that SDL as the solution of the problem connected with local/global symbol lookup namespaces appeared (RTLD_GLOBAL/RTLD_LOCAL) that appeared in the runtime while linking all the dynamic libraries separately. Providing that the issue reported internally will be resolved.
I've removed LLVM OpenMP as the start of the process of enabling compiler based OpenMP. Thus, compiling with GCC resulted in linking libgomp (GNU OpenMP). However, it caused some performance drop that needs to be investigated. (#20092).

I'd like to reignite the discussion connected with the following areas and give some update:
• Removing MKL_USE_SINGLE_DYNAMIC_LIBRARY (mentioned in the 'Build Flags' RFC part)
• Dynamically linking the OpenMP runtime library which is provided by the compiler/system (mentioned in the 'Build with OpenMP' & 'Interoperability OpenMP' part)
• Having two runtime OpenMPs in the same process what resulted in the hang ('Interoperability OpenMP' part).
I think that knowing the root-cause of the hang (described here: #18255) it's worth to reconsider leaving the MKL_USE_SINGLE_DYNAMIC_LIBRARY and using that SDL as the solution of the problem connected with local/global symbol lookup namespaces appeared (RTLD_GLOBAL/RTLD_LOCAL) that appeared in the runtime while linking all the dynamic libraries separately. Providing that the issue reported internally will be resolved.
I've removed LLVM OpenMP as the start of the process of enabling compiler based OpenMP. Thus, compiling with GCC resulted in linking libgomp (GNU OpenMP). However, it caused some performance drop that needs to be investigated. (#20092).

The bug will be fixed in the next oneAPI release - 2021.3. Just after the release I'll open the PR addressing this problem.

@szha, @leezu - can we close that RFC? Or there is still something unresolved?

@akarbown thanks!


Stop reconciling a PipelineRun once it has completed

Check whether we're "done" before proceeding further into
reconciliation, so that we won't just keep reconciling forever and
potentially resuming if, for example, a TaskRun the PipelineRun
references is deleted.
Also, this is basically how Build's reconciler works, so...yeah, I derived heavily from there. =)
Fixes: #299

Note that this definitely needs some review - might be best to think of this as WIP, honestly. =)

Lucky number 300 :tada: !!

@bobcatfish - I'll try to start putting some notes together on the reconciler lifecycle, but considering I'm literally just now beginning to figure any of it out, I'm probably not the right person to write said docs, regrettably. =)

Added some more feedback, coming along! :tada:

Just realized we should do the same thing for TaskRun, so that's added now. =)

Looks great to me!!! Thanks @abayer :D
/approve
(Looks like you'll need a rebase tho!)
/meow space

Rebase done!

/retest

Thanks again @abayer !! 🎉

=)


PyJWT dependency upgrade, 635, 649 (partial), and 679 (VA Profile integration)

This is a merged branch that includes all the changes necessary to clear a dependency scan failure for PyJWT and the changes for #635 and #679.  It also includes a partial implementation of #649 (fully implemented via #692).  These branches have been outstanding for a while, and getting them all in at once addresses issues with migrations in the dev db and previous user-flow test failures.
I have successfully deployed this branch to dev:
https://github.com/department-of-veterans-affairs/notification-api/actions/runs/2435645834

Implemented a lambda function for VA Profile integration.
Updating dependencies to clear a dependency scan failure for PyJWT.
Include minor updates to other packages.
Updated the migrations Dockerfile to use the notification_api image. Not doing this was causing a build failure related to using Python 3.6, and using notification_api is more efficient.
Use latest pip version in Docker files. Not doing this was causing a build failure.
Make minor changes to README.md
Include boto3 and botocore as top level dependencies in requirements-app.txt. (This codifies their de-facto status.)
Various workflow updates and fixes

These changes do not address the Terraform/infra changes necessary for VA Profile integration (#634).  Those changes go into a different repo.

@@.***> Yes we did discuss this and we decided it should be True, I think because if we compare the SourceDate to NULL that means we received data and decided not to act on it
From: kalbfled @.>
Sent: Friday, June 3, 2022 1:02 PM
To: department-of-veterans-affairs/notification-api @.>
Cc: Maham Saleem @.>; Mention @.>
Subject: Re: [department-of-veterans-affairs/notification-api] PyJWT dependency upgrade, 635, 649 (partial), and 679 (VA Profile integration) (PR #703)
@kalbfled commented on this pull request.

In migrations/versions/0347_modify_table_and_function.pyhttps://github.com/department-of-veterans-affairs/notification-api/pull/703#discussion_r889166238:

   schema="public",

   signature="va_profile_opt_in(_mpi_icn character varying, _va_profile_id integer, _communication_item_id integer, _communication_channel_name character varying)",

   definition='returns void\n LANGUAGE sql\nAS $function$\n    INSERT INTO va_profile_local_cache (mpi_icn, va_profile_id, communication_item_id, communication_channel_name)\n    VALUES (_mpi_icn, _va_profile_id, _communication_item_id, _communication_channel_name)\n    ON CONFLICT DO NOTHING;\n$function$'

)

op.drop_entity(public_va_profile_opt_in)

public_va_profile_opt_out = PGFunction(

   schema="public",

   signature="va_profile_opt_out(_va_profile_id integer, _communication_item_id integer, _communication_channel_name character varying)",

   definition='returns void\n LANGUAGE sql\nAS $function$\n    DELETE FROM va_profile_local_cache\n    WHERE va_profile_id = _va_profile_id AND communication_item_id = _communication_item_id AND communication_channel_name = _communication_channel_name;\n$function$'

)

op.drop_entity(public_va_profile_opt_out)

op.add_column('va_profile_local_cache', sa.Column('allowed', sa.Boolean(), nullable=False))

op.add_column('va_profile_local_cache', sa.Column('communication_channel_id', sa.Integer(), nullable=False))

op.add_column('va_profile_local_cache', sa.Column('source_datetime', sa.DateTime(), nullable=True))

@maham360https://github.com/maham360 Did we discuss this? I want to say there was a reason.
—
Reply to this email directly, view it on GitHubhttps://github.com/department-of-veterans-affairs/notification-api/pull/703#discussion_r889166238, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYRZAZ6VXMLMU2X4UFSZHO3VNI3ARANCNFSM5XZPVKTQ.
You are receiving this because you were mentioned.Message ID: @.***>

UPDATED: source_datetime = db.Column(db.DateTime, nullable=True) to source_datetime = db.Column(db.DateTime, nullable=False) because we would rarely get a NULL value for SourceDate and if we do it would default to the current time.


tls-alpn-01 challenges fail due to "random" keyspec used for responses

md_acme_order_authz_respond in md_acme_orde.cr chooses the first key specification named in MDPrivateKeys to be used for signing the acme-tls/1 response certificate.
In theory, the validator should not require a signature, but according to the draft-ietf-acme-tls-alpn-07 section 4, MAY refuse to accept a reponse that is not properly signed.
The problem with the current mod_md implementation is that the use may pick a set of key types for his certificates where the first one is not known to the CA's validator.  The list of acceptable signature types for a CA doesn't appear in the directory, so mod_md has no sure way to choose.
For now, RSA is probably a safe bet, and it's probably listed first in most configurations...
mod_md should probably have (yet another) configuration directive that is the key type for acme-tls/1 response certificates.  It should be per-CA, and default to RSA 2048 - which is common.  There is no security implication as the contents of the response certificate are signed.  It just needs to be signed with something that a CA that requires a signature will accept.

And, I can now confirm that this is an actual operational issue.  After a lot of debugging (it took a day to rule everything else out):
If the first MDPrivateKeys specifier is RSA 4096, LE will reject tls-apln-01 validation certificate` with the error:
[Thu Mar 19 16:09:36.116000 2020] [md:error] [pid 599340:tid<PHONE_NUMBER>19008] (22)Invalid argument: AH10056: processing wikiworld.li
tts.net: Incorrect validation certificate for tls-alpn-01 challenge. Missing acmeValidationV1 extension.

Worse, it will keep retrying...as frequently as 2x/min.
Work-around:  Use a smaller key.  RSA 2048 works.
Fix:
I'll come up with a patch and add it to my pull request later today.
Detail:
[Thu Mar 19 16:09:36.104918 2020] [md:error] [pid 599340:tid<PHONE_NUMBER>19008] ACME server authz: challenge 'invalid' for wikiworld.l
itts.net at https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/44567922. Exact response was: {"identifier":{"type":"dns","va
lue":"wikiworld.litts.net"},"status":"invalid","expires":"2020-03-26T20:08:54Z","challenges":[{"type":"tls-alpn-01","status":"invali
d","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Incorrect validation certificate for tls-alpn-01 challenge. M
issing acmeValidationV1 extension.","status":403},"url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/44567922/UhYA6w"
,"token":"yC55HQ8n0mNFy1pdBKXBE-qOhqGrGBzVUQW-MOz4r5M","validationRecord":[{"hostname":"wikiworld.litts.net","port":"443","addresses
Resolved":["<IP_ADDRESS>","2001:470:8f95:941::81"],"addressUsed":"2001:470:8f95:941::81"}]}]}

Well, curiouser and curiouser.
The LE Boulder people looked in their logs, and they say we're sending the fallback certificate.
That was my first thought - but all the logging I added said that wasn't the case.
I'm continuing to investigate now that we know what their logs say we sent....

I am rather offline this week (as you might have noticed), but will have time again next week,

No problem.  It' been an interesting week.
I now have a network trace from our end showing mod_md sending the wrong cert, and a functional trace saying we did everything right, including writing the cert that we should to disk at the time we handed it to OpenSSL.  So I ought to be able to figure this one out... once I'm awake.  I stopped around 3AM local time...
It would be helpful if you could make a decision on the EnvVar situation.
Have a good weekend.

The problem is well understood, and iinvolves aspects of mod_md, mod_ssl, and OpenSSL..
The issue is that when mod_md was updated to support dual certificates (e.g. simulataneous RSA & EC), we thought it was OK for the validation certificate to stick with one key type.
When two certificates are configured and no certificate from the CA is available, mod_md creates and preloads two "fallback certificates".
These are replaced when the CA certificates issue.
When a tls-alpn-01 challenge comes in, a validation response certificate is created and loaded.
Unfortunately due to the way OpenSSL handles certificate replacement, it displaces only one of the fallback certificates.  It treats EC, RSA, and DSA certificates independently.  If told to replace certificate (and/or key), it looks at the type of the new cert, and replaces any currently loaded certificate of the same type.  It leaves any certificates of other types alone.
Thus, depending on how the TLS negotiation turns out, the CA receives either the validation response, or the remaining fallback certificate. That depends on configuration of cipher preferences on both sides.  It's that which made it appear that certificate size was involved - it isn't.
Due to the way interfaces are defined between mod_md, mod_ssl, and OpenSSL, while the fix is conceptually simple, it's tricky to implement so that all combinations of versions will do something reaasonable.  The sticking point is that while it's possible to pass a list of certificates & keys for fallback and regular operation, the interface for supplying a validation certificate can only pass one pair.
It looks like supporting tls-apln-01 with more than one certificate will require a patch for mod_ssl - I'm trying to arrange things so that the patched mod_ssl works with the "old" mod_md, and so the unpatched mod_ssl supports a single installed certificate (as today).

I am still chasing a case where md_store_fs is using the single cert filenames. Afraid fix will ripple upwards.
That, and some strange responses from LE-staging (perhaps quota?) have limited testing the above commit.  Testing with s_client and wireshark say it works.  We should synchronize efforts when you're back.
More later.

Ah, now I understand the issue with challenge certificates for all key types. Hmm, the term "can or worms" comes to mind.

To summarize what happens during an tls-alpn-01 challenge:

the SNI selects the vhost settings, e.g. ciphers and certificates
the ALPN switches protocol to acme-tls-1. At this point, the modules knows that the connection is an ACME challenge
mod_ssl needs to use the challenge certificates and override all certs loaded by SNI already.

Since, there seems to no way to get rid if certificats already installed in a SSL*, we need to load
as many pkey type challenge certificates as were already installed.
Urgs.

Exactly.  (What happens first is that we've installed the fallback certs for both ciphers,  That's why we have certs to override,)
I committed code that does exactly that.  The issue with mod_ssl is that the old interface doesn't allow supplying more than one validation cert.
You should be able to merge my current master.

Solution was merged.

Solution was merged.


tests: Add e2e tests for Grafana Dex logins

[!warning]
This is public repository, ensure not to disclose:

[x] personal data beyond what is necessary for interacting with this pull request
[x] business confidential information, such as customer names

What kind of PR is this?
Required: Mark one of the following that is applicable:

[ ] kind/feature
[x] kind/improvement
[ ] kind/deprecation
[ ] kind/documentation
[ ] kind/clean-up
[ ] kind/bug
[ ] kind/other

Optional: Mark one or more of the following that are applicable:

[!important]
Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

[ ] kind/admin-change
[ ] kind/dev-change
[ ] kind/security
[ ] kind/adr

What does this PR do / why do we need this PR?

Tests login to Grafana using Dex static user.

Fixes https://github.com/elastisys/ck8s-ops/issues/1841

Additional information to reviewers
Screenshots
Checklist

[x] Proper commit message prefix on all commits

Change checks:

[x] The change is transparent
[ ] The change is disruptive
[x] The change requires no migration steps
[ ] The change requires migration steps

Metrics checks:

[ ] The metrics are still exposed and present in Grafana after the change
[ ] The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
[ ] The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)

Logs checks:

[ ] The logs do not show any errors after the change

Network Policy checks:

[ ] Any changed pod is covered by Network Policies
[ ] The change does not cause any dropped packages in the NetworkPolicy Dashboard

Pod Security Policy checks:

[ ] Any changed pod is covered by Pod Security Admission
[ ] Any changed pod is covered by Gatekeeper Pod Security Policies
[ ] The change does not cause any pods to be blocked by Pod Security Admission or Policies

Falco checks:

[ ] The change does not cause any alerts to be generated by Falco

Audit checks:

[ ] The change does not cause any unnecessary Kubernetes audit events
[ ] The change requires changes to Kubernetes audit policy

To run this locally to see what is actually tested ensure you have bats, make and npm, then go to test/, run make dep, then npx cypress open and you should get the Cypress UI were you can click through to E2E, with your favourite browser, and then run trough the specs.


How can I restart the pipline after the specified step

Hello, I want restart the pipline after the specified step for there is some reasons interrupt my work, but I can't find any way to solve my problem, could you help me, please, here is my log data:
#$ tail bcbio-nextgen-commands.log
[2020-09-02T07:09Z] gffread -g /data/bcbio-nextgen/genomes/Homo_sapiens/GRCh38/seq/GRCh38.fa -w /data/bcbio-nextgen_test/seqc/work/bcbiotx/tmpu6v5g6ux/GRCh38.fa.tmp /data/bcbio-nextgen/genomes/Homo_sapiens/GRCh38/rnaseq/ref-transcripts.gtf
#$ tail bcbio-nextgen-debug.log
[2020-09-02T07:09Z] multiprocessing: run_salmon_index
[2020-09-02T07:09Z] Converting /data/bcbio-nextgen/genomes/Homo_sapiens/GRCh38/rnaseq/ref-transcripts.gtf to FASTA format.
#$ tail bcbio-nextgen.log
[2020-09-02T07:04Z] Timing: disambiguation
[2020-09-02T07:04Z] Timing: transcript assembly
[2020-09-02T07:04Z] Timing: estimate expression (threaded)
[2020-09-02T07:04Z] multiprocessing: generate_transcript_counts
[2020-09-02T07:09Z] multiprocessing: run_salmon_index
hope for your help, thanks!
Zhengwen CAI

Hi Zhengwen!
You can just re-kick it off the same way you ran it to begin with, bcbio is transactional, which means that it will not put partially completed data if the pipeline stops. It is also memoized, which means it will skip the steps that it already ran. Hope that helps. Thanks for using bcbio!

Ok, I get it, thanks very well!
------------------ 原始邮件 ------------------
发件人:                                                                                "bcbio/bcbio-nextgen"<EMAIL_ADDRESS>发送时间: 2020年9月2日(星期三) 晚上10:31
收件人<EMAIL_ADDRESS>抄送: "征文"<774780638<EMAIL_ADDRESS>主题: Re: [bcbio/bcbio-nextgen] How can I restart the pipline after the specified step (#3335)
Hi Zhengwen!
You can just re-kick it off the same way you ran it to begin with, bcbio is transactional, which means that it will not put partially completed data if the pipeline stops. It is also memoized, which means it will skip the steps that it already ran. Hope that helps. Thanks for using bcbio!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


add events on GuiObjects

I think this is how you had suggested we handle the events that every component shares coming from GUIObject. I had tried to place the events on a fragment, but that doesn't seem to be possible. I'm not thrilled with the fact that when I look at the DOM every element has a <div> wrapper, but I guess it doesn't matter.

If we don't want the extra DOM elements we have a few options:

A hook which returns a ref (we could then use native DOM events rather than synthetic React events)
A hook which returns event props which we could spread into the DOM node that we are already rendering.

If we don't want the extra DOM elements we have a few options:

A hook which returns a ref (we could then use native DOM events rather than synthetic React events)
A hook which returns event props which we could spread into the DOM node that we are already rendering.

I think I'll start with 2

Actually gonna punt on getting rid of the extra <div>s for now. It just got so much uglier including them individually in each component.  We can always revists once we have more components


Use of depreciated & insecure tempfile.mktemp()

Expected Behavior
_tempfilepager() in _termui_impl.py uses a depreciated function that is considered insecure by the core Python team. It is recommended to use mkstemp() instead.
import tempfile
filename = tempfile.mkstemp()  # Suggested replacement

Actual Behavior
Python's warning:

Use of this function may introduce a security hole in your program. By the time you get around to doing anything with the file name it returns, someone else may have beaten you to the punch.

import tempfile
filename = tempfile.mktemp()  # Depreciated and insecure

Environment

Python version: 3.8.5
Click version: 7.1.2

Please see our guidelines for responsibly reporting security issues: https://github.com/pallets/click/security/policy

Please see our guidelines for responsibly reporting security issues: https://github.com/pallets/click/security/policy


Release v0.6.1

Could you please release v0.6.1 with laster changes in master, because v0.6.0 doesn't work with latest chefdk. Thanks!

I just pushed 0.7.0.pre from master incase that helps.
Haven't run any of the integration tests so hopefully it works.


fix(console): resolve warnings due to dependency update

Depends on #4264

true.. changed it to chore 👍


Add option for number of context lines in the diff

Add option to set the number of context lines shown in the unified diff

Thank you, but I'm not sure how useful that is.
Diff is here to get some sense of the code that isn't correct, something more useful that just "this file is not properly formatted".
But when there is an issue, you should usually just reformat the file automatically (git clang-format, clang-format -i, ...), or open the code in your editor.
There is no point in implementing all the diff options: context line, unified/not-unified, diff style, diff algorithm, ...
Eventually, if 3 is not a good default, we can increase it, assuming there are convincing examples.

Closing due to inactivity.


access the container

I want to send a request to another server once the job is triggered
but it's seems impossible to access the container

@quantumass You should pass in a Client to the job on the initialization. For example:
struct MyJobContext: JobData { }

struct MyJob: Job {
    let client: Client
    // functions go here
}


Double-click anywhere in blank space of the elevation profile could be added as a shortcut to toggle the elevation profile

There is already a button AND a keyboard shortcut...

Sure but each time we can save mouse moves is great and increase the pleasure of the user experience


diga.apimisc.de times out

Problem
Library requests to diga.apimisc.de endpoint time out (both test and real requests)
Solution
?

#52 Real and test requests are working for us

That's great! Thanks for letting us know. Closing this!


Bcc recipients are visible on recipient side

Expected behavior
When a user receives an email from K9, they shouldn't see the list of bcc recipients
Actual behavior
The list of bcc recipients is actually visible
Steps to reproduce
IMPORTANT: The reproducibility of this bug depends on which email provider you're using. I reproduced it when using K9 with an icloud.com email sending a message to yahoo.com recipients.

Add an icloud.com account to K9
Send a message to yahoo.com recipients (one TO recipient, a CC recipient and a couple of BCC recipients)
When checking the message in the TO recipient mailbox, the list of BCC recipients is visible

Environment
K-9 Mail version: 5.109
Android version: 7.1
Account type (IMAP, POP3, WebDAV/Exchange): IMAP
I think this happens because SmtpTransport.sendMessage receives a LocalMessage as a parameter. When the method set the BCC recipients to null, the actual BCC header is not removed because the setRecipients method of LocalMessage doesn't update the headers (as opposed to MimeMessage)

Probably a duplicate of https://github.com/k9mail/k-9/issues/1938


Add support for W3C Verifiable Credentials

It would be nice if you'd add support for W3C VCs (since they are a global standard for attestations) to support offchain and onchain attestations. I guess it should be possible to create W3C VCs with EIP712 proofs. In W3C CCG, we are currently specifying an EIP712-based LD-Proof here: https://w3c-ccg.github.io/ethereum-eip712-signature-2021-spec/. Would be great if you could contribute if something would need to change.

Any updates on this?


strands_executive: 1.0.9-0 in 'indigo/lcas-dist.yaml' [bloom]

Increasing version of package(s) in repository strands_executive to 1.0.9-0:

upstream repository: https://github.com/strands-project/strands_executive.git
release repository: https://github.com/strands-project-releases/strands_executive.git
distro file: indigo/lcas-dist.yaml
bloom version: 0.5.26
previous version for package: null

gcal_routine
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

mdp_plan_exec
* Removed stray prism-robots dependency.
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

scheduler
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

scipoptsuite
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

sim_clock
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

strands_executive_msgs
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

task_executor
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

wait_action
* indigo-1.0.8
* Updated changelogs
* Contributors: Nick Hawes

@bfalacerda older indigo release


FlushAsync?

My scenario is that I'm running in an asynchronous context, producing a lot of messages, and waiting for them to be delivered. Of course I could produce them one at a time with ProduceAsync, but that seems unnecessarily slow. The readme shows this pattern:
        using (var p = new ProducerBuilder<Null, string>(conf).Build())
        {
            for (int i=0; i<100; ++i)
            {
                p.Produce("my-topic", new Message<Null, string> { Value = i.ToString() }, handler);
            }

            // wait for up to 10 seconds for any inflight messages to be delivered.
            p.Flush(TimeSpan.FromSeconds(10));
        }

which makes sense, but Flush blocks the thread, which is going to cause all sorts of other problems in my asynchronous methods. I'd like an asynchronous way to do know when my "batch" of messages have all been delivered.
My only current alternative is to keep a counter and increment it from all my callbacks, poll that counter until it matches my expected count (or a timeout), and wrap that all up in an async method. That's both cumbersome and doesn't actually whatever it is Flush actually does.
Does it make sense to add a FlushAsync to the lib?

the reason we don't have this is technical constraints imposed by librdkafka. generally, you should only need to call Flush on exit. in that context, it's fine to just use Task.Run(() => p.Flush(timeout)), and that is better than blocking a thread that is assumed to not block by the runtime. If you want to wait on a batch of messages, you don't need to await ProduceAsync, you can put multiple tasks into an array and await Task.WaitAll.

Thanks. If Flush is only for exit, I think the readme should clarify that. I agree that putting it in Task.Run is ok there, but it's not in the general case, since it still blocks a thread.
Re: await Task.WaitAll: I tried that first, and had some issues with it. If that's the recommended approach, I'll go back and give it another shot. Could have just been user error.
For reference, this is my current implementation:
    public class AsyncKafkaBatcher<T1, T2>
    {
        private int _errored, _delivered, _sent;
        private readonly IProducer<T1, T2> _producer;

        public AsyncKafkaBatcher(IProducer<T1, T2> producer)
        {
            _errored = 0;
            _delivered = 0;
            _sent = 0;
            _producer = producer;
        }

        public void Produce(string topic, Message<T1, T2> message, Action<DeliveryReport<T1, T2>> callback)
        {
            _producer.Produce(topic, message, WrapCallback(callback));
            Interlocked.Increment(ref _sent);
        }

        public async Task<BatchDeliveryReport> Flush(TimeSpan timeout)
        {
            var stopwatch = Stopwatch.StartNew();
            while (true)
            {
                var timedOut = stopwatch.Elapsed > timeout;
                if (timedOut || _sent == _delivered + _errored)
                {
                    stopwatch.Stop();
                    return new BatchDeliveryReport
                    {
                        TimedOut = timedOut,
                        Errored = _errored,
                        Delivered = _delivered
                    };
                }

                await Task.Delay(TimeSpan.FromMilliseconds(500));
            }
        }

        private Action<DeliveryReport<T1, T2>> WrapCallback(Action<DeliveryReport<T1, T2>> callback) =>
            dr =>
            {
                if (dr.Error.IsError)
                {
                    IncrementErrored();
                }
                else
                {
                    IncrementDelivered();
                }

                callback(dr);
            };

        private void IncrementDelivered() => Interlocked.Increment(ref _delivered);
        private void IncrementErrored() => Interlocked.Increment(ref _errored);

Thanks. If Flush is only for exit, I think the readme should clarify that. I agree that putting it in Task.Run is ok there, but it's not in the general case, since it still blocks a thread.

It does not block a thread that the scheduler assumes will not block though, so it's a valid solution.
When I said Flush is usually only used on exit, it's also the case that you don't generally need to wait for a batch of delivery reports. If you do want to do that Flush is fine (and you can await the run). Task.WaitAll is also fine. The above approach is unnecessarily complicated.


ldap don't save user in phpmyadmin

Laravel Version: 5.8.16
Adldap2-Laravel Version: 3.0.0
PHP Version: 7.3.4
LDAP Type: ActiveDirectory

Description:
Hi, I am just starting to use your package for my laravel project and I just notice that when I log an account into my website, an entry is log into my user table on phpmyadmin, but when I try to login with another account this entry with user_id 1 is remove and recreate with the new user profile and get the user_id 1. So, when i try to login with two user accounts in the same time, they all get the profile information of the lasted who login.

Hi @skyro682,
I just wanted to confirm before helping you debug, are you sure you are on version 3.0? It’s quite old at this point, just want to ensure this is the case.

Oh yeah, It's the version 3.0, It's what i see on the tutorial i've using, I gonna update to the version 6.0.5 and I come back in a few day to tell if it's work

Oh yeah, It's the version 3.0, It's what i see on the tutorial i've using, I gonna update to the version 6.0.5 and I come back in a few day to tell if it's work

Ok no problem! If you need anything just give me a shout and I can help you debug.

Hi, I'm back, I was in school last week, so I do nothing for my project.
I start from 0 this morning (french time) and I follow your Quick Start - From Scratch Page but when I put my login information I get an error "These credentials do not match our records."
Laravel Version: 5.8.18
Adldap2-Laravel Version: 6.0.6
PHP Version: 7.3.4
LDAP Type: ActiveDirectory

ldap_auth.php :
'connection' => env('LDAP_CONNECTION', 'default'),
'ldap' => [
'locate_users_by' => 'samaccountname',
'bind_users_by' => 'distinguishedname',
],
'username_column' => 'username',
'windows' => [
'locate_users_by' => 'samaccountname',
'server_key' => 'AUTH_USER',
],
'sync' => env('LDAP_PASSWORD_SYNC', false),
'column' => 'password',
'login_fallback' => env('LDAP_LOGIN_FALLBACK', false),
'sync_attributes' => [
'email' => 'userprincipalname',
'name' => 'cn',
],
ldap.php :
'logging' => env('LDAP_LOGGING', true),
'auto_connect' => env('LDAP_AUTO_CONNECT', true),
'use_ssl' => env('LDAP_USE_SSL', false),
'use_tls' => env('LDAP_USE_TLS', false),

Hey, now I can connect to the ldap and the user information are correctly saved into the db but, when I add a suffix in the conf file nothing work and when the connection information is false I don't get any error message on the connection page.


Add to library

This looks really great!
But how do you add to the library?

Hi, I don't know what's your  'library'  mean.

Go to Settings -> Media -> Sync or run Media.sync in the Rails console.


Fix application of branding, color and theme from settings

Summary
Fixes #6704
This PR  is for 2.6.8, master is https://github.com/rancher/dashboard/pull/6706
Occurred changes and/or fixed issues

mixins/brand.js handles the application of some settings via watchers on them
The watchers weren't triggering as they never changed from their initial value
Caused by https://github.com/rancher/dashboard/commit/771f168a5b33f970f47bcefb272cfa199b3d10be
Revert to the initial way. This may break epinio but that can be fixed later on

Areas or cases that should be tested
Global Settings / Banners (all features)
Global Settings / Branding (all features)
Burger Menu --> Support --> Add a Sub ID  (custom colours should be removed, suse green colours should then be used by UI)
Note - Importantly the settings should apply after refreshing the browser

@sallen-suse could you admin merge this for UI to get an RC for QA? Thanks!


Clarify supported features

I cannot understand - is x509 Authentication supported or not?
It seems to be presented in code
https://github.com/wmnsk/gopcua/blob/72c87ce6fabe6993089b948be572e56fe94670c5/datatypes/user-identity-token.go#L253
and even tested, but supported features do not mention it as supported.
So I'm confused - was it supported not fully or it's just not working code or it's just a documentation issue?
If it's the last one I think other features should be checked too (maybe more of them supported already).
Thanks!

Hi, thank you for having some interest in our project😀
The code you pointed out is just to decode the raw bytes into X509IdentityToken struct, which does not mean the certificate can be handled properly in the exchanges of packets.
So, with some(or even so much) effort you can use it, but as a library, we should tell you it has not been supported as an official feature yet, as the proper handling of certificates cannot be done only with deserializing what the endpoint received.

Thanks for answer! Now I see that documentation is correct and I just had a wishful thinking on my side =)

Hope you’ll come back when it’s ready. Thanks.


daemon: check error from d.init()

Commit a4f50323a7e0b437611d9567dfaa8f6d1a4a516b shuffled code around such that
the err variable from d.init() was masked by the invocation of
monitoragent.NewAgent(). As such, if d.init() failed, we would never know
that it had because its returned error was overwritten to nil if
monitoragent.NewAgent() subsequently succeed.
Fixes: a4f50323a7e0b437611d9567dfaa8f6d1a4a516b
Signed-off by: Ian Vernon<EMAIL_ADDRESS>

This change is

test-me-please

Coverage increased (+0.03%) to 44.312% when pulling acd612ad1f0e69ceb50577d7a75961326926c7b6 on pr/ianvernon/fix-init-error-check into 74b517bcc20fb71a0978cbe14824f3fdfe02793a on master.

test-me-please


Rerendering to trigger r-base 3.6.1 build

Checklist

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

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you, but it looks like there was nothing to do.

@conda-forge/r-kknn-feedstock please review/merge, thanks!

@conda-forge/r-kknn please review and merge. Thanks!

@conda-forge-admin please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you, but it looks like there was nothing to do.


Allow no caching with a null kv store

In some cases I don't need to cache the JWKS. It would be nice to be able to set the kvstore option to null.

@Soviut Did you give useKVStore an undefined? I believe it's optional.

I did not know that was possible. I was looking at the source but didn't think to look at the useKVStore() itself, only the getJwks()  which made it seem like a valid KV store was a requirement.
That should definitely be documented.

@Soviut Please let me know if it works. Your PR for documentation/tests is welcome!

@wataruoguchi I just tried and this works.
  const jwks = await getJwks(
    'https://<myurl>/.well-known/jwks.json',
    useKVStore() // no cache
  )

I'll see about doing a PR to add the documentation for this. The test I'm less sure about.
Something I'd suggest is making the requirement for a kvstore in getJwks() optional as well. I feel like a kvstore cache is something you'd want to explicitly configure. Thoughts?

@Soviut Great idea! I will approve that idea if you add it in the PR 👍

@wataruoguchi I've made a documentation PR. I'll see if I can do the other suggestion as a separate PR.

Hello @Soviut ! I hope you are doing well. I just published v.1.1.6 - including your request to make the second parameter optional. Now it simply be:
const jwks = await getJwks('https://<myurl>/.well-known/jwks.json')

Cheers 🍻


⚠ DesiTorrents has degraded performance

In 26a5a19, DesiTorrents ($DST) experienced degraded performance:

HTTP code: 200
Response time: 1531 ms

Resolved: DesiTorrents performance has improved in 15b3f7a after 6 minutes.


Autoloader.php not compatable with PHP version 5.2.1 or greater.

As stated in the requirements PHP version 5.2.1 or greater. The autoloader (in Google/autoloader.php) will not work.
Here is the fixed autoloader function.
function autoloader ($className) {
  $classPath = explode('_', $className);
  if ($classPath[0] != 'Google') {
    return;
  }
  // Drop 'Google', and maximum class file path depth in this project is 3.
  $classPath = array_slice($classPath, 1, 2);

  $filePath = dirname(__FILE__) . '/' . implode('/', $classPath) . '.php';
  if (file_exists($filePath)) {
    require_once($filePath);
  }
}

spl_autoload_register('autoloader');

I wanted to ask about this also, as I am using the SDK as part of a WordPress plugin - WordPress supports PHP 5.2.4 onwards. (I know: nobody sane should be using PHP 5.2 now... but sadly, it's still out there, and if you have a 500,000 install base on a WP plugin, there are plenty of people who'll complain if it breaks...)
David

Yup, I see what you are saying.  How I discovered this problem (and the fix) was via this PHP article on the spl_autoload_register function: http://php.net/manual/en/function.spl-autoload-register.php
Scroll down to the Example 1, and you'll see where it talks about this.

This file has been removed in favor of composer autoloading, so this issue is no longer relevant.


Swashbuckle.AspNetCore is being removed in .NET 9

Description
See  #32099
Page URL
https://learn.microsoft.com/en-us/aspnet/core/grpc/json-transcoding-openapi?view=aspnetcore-8.0
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/grpc/json-transcoding-openapi.md
Document ID
aeb8fe2e-a57e-74ff-f9d7-3591f24db367
Article author
@JamesNK

Associated WorkItem - 232965

completed


Fix Vercel URL

Change Summary
Fixes Vercel URL formatting via env var in the starter guide.
Merge Checklist

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

Fixed in #218


Create a simple European case study for testing

Create the esdl file and fill with data for the simple European case study.

Zhi is coming next week (15-11)

input_NLBE_22Nov2023.zip
@abelsiqueira @datejada
Hi, Can you have a try on this? I had large overhead time formulating the model with Tulipa.
Thanks,
Zhi

@gzclarence @datejada can you update the NLBE example for the current main?

@gzclarence, once you have the time to create the model using version 0.5, please let us know 😄 please also post the time for the case study that includes Germany to have an idea of how the model generation scales with larger cases. Thanks!

Related #426

Europe_ZhiLaura.zip
@datejada Can you access the files like this?
Best,
Laura

@LauraBrafine Thanks! I downloaded it 😄


memory leak

there seems to be memory leak, do you have any idea/insight?

below is the pprof dump:
pprof.zip

Hi @GingerMoon
I've checked your pprof dump and it actually looks pretty normal. The graph on your screenshot is for alloc_objects, which as far as I know is not really suitable for detecting memory leaks. This is nicely explained in an awesome article by Julia Evans here:

go tool pprof has the option to show you either allocation counts or in use memory. If you’re concerned with the amount of memory being used, you probably want the inuse metrics, but if you’re worried about time spent in garbage collection, look at allocations!
-inuse_space      Display in-use memory size
-inuse_objects    Display in-use object counts
-alloc_space      Display allocated memory size
-alloc_objects    Display allocated object counts

So, let's check out the inuse_space. I personally prefer flamegraph than the normal graph, so here is its screenshot:

From that graph, we can see your entire app uses 1.33 GB. Now, let's see how much go-trafilatura use in your application:

As you can see, go-trafilatura function only use 5.58 MB or only 0.4% of your entire app. So I believe there are no memory leak occurred.

 Fro Go's FAQ:

The Go memory allocator reserves a large region of virtual memory as an arena for allocations. This virtual memory is local to the specific Go process; the reservation does not deprive other processes of memory.


Anaplan connector project giving errors about missing artifact anaplan-connect-1.3.6.jar

When I was trying to deploy an application which has Anaplan connector from Bamboo, it gives an error:
[INFO] Downloading: file:///opt/bamboo-agent/bamboo-agent-home/xml-data/build-dir/FS-ANAPLAN-ALLTESTS/src/main/resources/repo/com/anaplan/client/anaplan-connect/1.3.6/anaplan-connect-1.3.6.jar
build	28-Jul-2017 21:36:32	[INFO] ------------------------------------------------------------------------
build	28-Jul-2017 21:36:32	[INFO] BUILD FAILURE
build	28-Jul-2017 21:36:32	[INFO] ------------------------------------------------------------------------
build	28-Jul-2017 21:36:32	[INFO] Total time: 15.344 s
build	28-Jul-2017 21:36:32	[INFO] Finished at: 2017-07-28T21:36:32+00:00
build	28-Jul-2017 21:36:32	[INFO] Final Memory: 22M/495M
build	28-Jul-2017 21:36:32	[INFO] ------------------------------------------------------------------------
build	28-Jul-2017 21:36:32	[ERROR] Failed to execute goal on project atl_anaplan_app: Could not resolve dependencies for project com.atlassian.finsys:atl_anaplan_app:mule:1.0.0-SNAPSHOT: Could not find artifact com.anaplan.client:anaplan-connect:jar:1.3.6 in maven-atlassian-com (https://packages.buildeng.atlassian.com/maven/repository/internal) -> [Help 1]
In the project .classpath,

I tried removing the line with anaplan-connect-1.3.6.jar, but Maven adds it back when it cleans the project.
In pom.xml, the following lines are added:

mulesoft-releases
MuleSoft Releases Repository
http://repository.mulesoft.org/releases/
default

mulesoft-release
mulesoft release repository
default
http://repository.mulesoft.org/releases/

false

This jar is not present in the Mule repository.

Could you share some more details how you're using this connector? Are you building and using the connector in Anypoint Studio? How are you using Bamboo to build the connector?
From a clean build of the connector project (mvn clean install -U), I see it downloads the anaplan-connect:1.3.6 dependency properly and builds the project just fine.

My local repository has the anaplan-connect-1.3.6.jar. When I am building the project in Anypoint Studio, it checks the local Maven repository and it is able to get the jar and build the project successfully.
When building in Bamboo, the project checks the company's internal repo, which proxies the Mule repository. The following lines are added in pom.xml to proxy Mule repo,

mulesoft-releases
MuleSoft Releases Repository
http://repository.mulesoft.org/releases/
default

mulesoft-release
mulesoft release repository
default
http://repository.mulesoft.org/releases/

false

In Mule repo, anaplan-connect-1.3.6.jar is not present, so it is not present in the company's internal repo. There the build fails.

I believe your problem is because of a missing repository definition in your pom.xml
        <repository>
            <id>anaplan-github-mvn-repo</id>
            <name>Anaplan Github MVN Repository</name>
            <url>https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac/</url>
            <layout>default</layout>
            <snapshots>
	            <enabled>true</enabled>
	            <updatePolicy>always</updatePolicy>
	        </snapshots>
        </repository>

Check this project's repositories in the pom.xml for details.
To test my theory:
If I remove my local Maven artifact for anaplan-connect from ~/.m2/repository/com/anaplan/client/anaplan-connect and build it again, the anaplan-connect jar is re-downloaded from anaplaninc.github.io, which is a publicly accessible Nexus.
Downloading: https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac/com/anaplan/client/anaplan-connect/1.3.6/anaplan-connect-1.3.6.jar
Downloaded: https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac/com/anaplan/client/anaplan-connect/1.3.6/anaplan-connect-1.3.6.jar (124 KB at 573.5 KB/sec)

So yes, Mulesoft is right, they don't control the dependencies for community connectors, as a result we hosted that dependency at anaplaninc.github.io.
In your case, you'd have to add the above repository definition to your pom to make it work.
Hope that helps!

I tried the same way you mentioned, but I do not see it downloading from raw.githubusercontent.com/anaplaninc/
The below are the changes I made with your suggestion:
I compared this repo's pom.xml with mine and I added the following in pom.xml:
in <dependencies>
<dependency>
    <groupId>com.anaplan.client</groupId>
    <artifactId>anaplan-connect</artifactId>
    <version>1.3.6</version>
</dependency>

<repositories>
		<repository>
			<id>in-project</id>
			<name>In Project Repo</name>
			<url>file://${project.basedir}/src/main/resources/repo</url>
		</repository>
        <repository>
            <id>Central</id>
            <name>Central</name>
            <url>http://repo1.maven.org/maven2/</url>
            <layout>default</layout>
        </repository>
        <repository>
            <id>mulesoft-releases</id>
            <name>MuleSoft Releases Repository</name>
            <url>http://repository.mulesoft.org/releases/</url>
            <layout>default</layout>
        </repository>
		<repository>
            <id>anaplan-github-mvn-repo</id>
            <name>Anaplan Github MVN Repository</name>
            <url>https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac/</url>
            <layout>default</layout>
            <snapshots>
	            <enabled>true</enabled>
	            <updatePolicy>always</updatePolicy>
	        </snapshots>
        </repository>
    </repositories>
<pluginRepositories>
        <pluginRepository>
            <id>mulesoft-release</id>
            <name>mulesoft release repository</name>
            <layout>default</layout>
            <url>http://repository.mulesoft.org/releases/</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </pluginRepository>
    </pluginRepositories>
    <distributionManagement>
        <repository>
            <id>atlassian-private</id>
            <name>Atlassian Private Repository</name>
            <url>https://maven.atlassian.com/private</url>
        </repository>
        <snapshotRepository>
            <id>atlassian-private-snapshot</id>
            <name>Atlassian Private Snapshot Repository</name>
            <url>https://maven.atlassian.com/private-snapshot</url>
        </snapshotRepository>
    </distributionManagement>

Then I removed Anaplan-connect folder from my local repo and I used mvn clean package in Terminal, but it gave errors:

I do not see the line about it downloading from Anaplan repo.
I tried adding the Anaplan repo under  also but that gave the same error.

In the pom.xml in this connector project, there's also a  field that seems to be required (https://github.com/anaplaninc/anaplan-mulesoft/blob/develop/pom.xml#L17). Try adding this to your pom.xml as well
<url>http://anaplaninc.github.io/mvn-repos</url>

There is also a  section, but I don't think you need to add that since its only for pushing anaplan-mulesoft artifacts. But it doesn't hurt to also include and see if that makes a difference.
My hunch is the missing  will do the trick

I had tried adding the repo in <distributionManagement>, but it gave an error because it already has the private repo there. I guess it can have only one <repository> tag.
I tried adding the , but it still gives the same error.
I noticed that
Downloading: https://packages.atlassian.com/maven/repository/internal/com/anaplan/client/anaplan-connect/1.3.6/anaplan-connect-1.3.6.pom
is occurring on the Terminal, the folder gets created, even though the link does not have that jar.
It does not go to the Anaplan Repo link at all.

This seems like a problem with your approach of building the connector in Bamboo, where its unable to reach out to the github repos. From your earlier post, you mentioned that "When building in Bamboo, the project checks the company's internal repo, which proxies the Mule repository.". So you might have to add some exclusion rule in Bamboo to also add the https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac repo URL.
The link you posted above is only part of the URL, that maven uses and adds the classpath URL to it to fetch the artifacts, so obviously that will give a 404. The correct link is https://raw.githubusercontent.com/anaplaninc/anaplaninc.github.io/mvn-repo-ac/com/anaplan/client/anaplan-connect/1.3.6/anaplan-connect-1.3.6.jar

Thanks... I will ask my Build team to help with that...
I will update this issue after that...

We were able to fix this issue by uploading the jar in our internal repository. Then the application was able to download the jar from that location and build sucessfully.
Thank you very much for your help @shuvozula

My pleasure. Glad u guys figured it out


Create new labels for BaseWeb issues

I really like this type of method of issue labels: https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63

Here's what I ended up creating for my personal site:
Type: Bug
Type: Maintenance
Type: Enhancement
Type: Idea

Priority: Low
Priority: Medium
Priority: High
Priority: Critical

Area: Content
Area: Build Scripts
Area: Front-end
Area: Backend

Here's what I think will work best for BaseWeb:
Type: Bug
Type: Maintenance
Type: Enhancement
Type: Idea

Priority: Low
Priority: Medium
Priority: High
Priority: Critical

Area: Blog
Area: Docs
Area: Build Scripts
Area: Styles
Area: JavaScript