Fix the admin panel url

Going to localhost:8000/admin doesn't redirect to admin site but localhost:8000/admin/ does . This should be corrected.

@rapperdinesh Adding two lines one with only admin and other with admin/ will throw warnings ! So i think removing / is ok for now


Fix error 111

Fixes error 111

Not sure what happened here...
isKindOfClass: should continue to work, since when converted to Swift - BFTask might become a subclass of BFTask aka SwiftBFTask. Which is valid for isKindOfClass:

I've created another PR that properly leverage NSStringFromClass and NSClassFrom String.
The error is not constant, not consistant. Mostly occur with BFTaskCompletionSource
I can create a little repo if you like to demonstrate the problem ok?


[Question] Are there any providers implemented in go?

Describe the Question
Are there any examples or tutorials for implementing a provider in go?
I noticed that wasmcloud supports go, and there are tinygo SDKs in the https://github.com/wasmCloud/interfaces. For rust it uses wasmbus-rpc, is there a similar library for go?
Any help will be appreciated.

Hey @Taction , @jordan-rash has been pioneering the Go SDK for writing capability providers in Go 😄 The litestream provider is an example of this, and he's currently touching up a lot of the wasmcloud-go libraries.
Jordan can comment on if it's ready or not to experiment with!

Hi @Taction ..... there are some experimental Go providers out there right now.  The current status is that @stevelr and I are in the process of finalizing the first pass of the SDKs.  There are quiet a few PRs out there for the work, but here is the best tracker.  As soon as we get the code generation caught up, this should be ready to test.  I would suspect by this time next week.

Awesome! Thanks for all your replies, and looking forward to that feature.

No worries!  I will ping you here once the code gen and SDKs are in sync...give me until the end of next week :-)

Closing this since we do have a few and there's not too much more to be said here 😄


I‘m sorry to say that didnot work on win7-63.0.3 (64 bit)

I install the addon by WebExtensions markets.  and more the corsE button changes to green .
finally I get info:已拦截跨源请求：同源策略禁止读取位于 https://<IP_ADDRESS>:28001/api/sta-subscriber/v1/event/region?traceType=CELL&language=zh-CN&csrftoken=null 的远程资源。（原因：CORS 预检通道未成功）(it means cors Preview channel falid)

A preflight request can fail for many reasons even when the addon is enabled. And without any code, it will be pretty much impossible to investigate.
First, make sure that the resource returns a 2xx http code. Other codes will fail the preflight as per the spec:

7.1.5 Cross-Origin Request with Preflight
...
If the response has an HTTP status code that is not in the 2xx range:
Apply the network error steps.

Cross-Origin Resource Sharing - W3C Recommendation 16 January 2014


[BACKLOG-40846] Unit test fixes for JDK17

 Note:

Frogbot also supports Contextual Analysis, Secret Detection, IaC and SAST Vulnerabilities Scanning. This features are included as part of the JFrog Advanced Security package, which isn't enabled on your system.

🐸 JFrog Frogbot

:white_check_mark: Build finished in 18m 3s
Build command:
mvn clean verify -B -e -Daudit -Djs.no.sandbox -pl plugins/rest/core

:ok_hand: All tests passed!
Tests run: 32, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


Fix .sol reader logic to match AMPL's implementation

@kibaekkim, could you check if this works for you with minotaur? It reads in the .sol file you linked, but just want to make sure.
Fixes #33

@JackDunnNZ  Thanks. It works.

Thanks again for reporting it


Command line mode in command palette behaves different from what doc describes.

Windows Terminal version: 1.4.3243.0
Related doc: https://docs.microsoft.com/en-us/windows/terminal/command-palette#command-line-mode
Doc states that

If you'd like to enter a wt command into the command palette, you can do so by deleting the > character in the text box.

But in practice, if you invoke the command palette and want to enter a wt command, there is no > character to be deleted.
On the other side, you have to add > character to enter a wt command.

We changed this recently -- it looks like the documentation update was released before the terminal update. Sorry.
/dup #7935

We changed this recently -- it looks like the documentation update was released before the terminal update. Sorry.
/dup #7935


[Select][joy] Add required prop

closes #38070
Chrome
https://github.com/mui/material-ui/assets/18292247/7c3bdad2-0666-4fa2-901c-0c94461562d3
Safari
https://github.com/mui/material-ui/assets/18292247/5e7c0da2-ae1c-48ec-b658-ff2574ad8e59
Firefox
https://github.com/mui/material-ui/assets/18292247/662b82fc-83b9-4f0d-9f59-162aa4dd51ce

[ ] I have followed (at least) the PR section of the contributing guide.

@michaldudak I added getHiddenInputProps to useSelect for the <input {…getHiddenInputProps()} />.
Please see the new tests added in useSelect.test.tsx.


Ability to run on PyTorch model?

I see the input to VTAB is a model hosted at https://www.tensorflow.org/hub. Are there any plans to support PyTorch pre-trained models as input? This benchmarking suite seems extremely well built and designed, and I'd love to take advantage of it with some of our PyTorch models.

At the moment, the task adaptation team does not have the capacity to work on the pytorch variant of the VTAB benchmark. In general, replicating the VTAB in pytorch should not be too hard, as the data input pipeline can be reused and the remaining parts (model loading and the standard SGD optimization loop) should be relatively straightforward to implement.
Unless there will be an open source contribution of the pytorch version of VTAB, we plan to have a look at this issue in the beginning of the next year.

Hi, I was wondering if there was any change to the above - either if you're aware of an open-source PyTorch implementation, or if anyone on your team had a chance to look at this sometime this year. I agree with the earlier poster that this seems like a really well-designed benchmark that would be great to see more widely adopted.
(BTW, congrats on the cool work at ECCV on Big Transfer!)


Cannot use with rxjs 5.0.0-beta.2

I tried updating today to the latest version of ng2-translate but my app fails when ng2-translate tries to load /rxjs/add/observable/of. This module was properly added only in rxjs 5.0.0-beta3.
You can compare the main Rx files:

https://github.com/ReactiveX/rxjs/blob/5.0.0-beta.2/src/Rx.ts
https://github.com/ReactiveX/rxjs/blob/5.0.0-beta.3/src/Rx.ts

The issue was introduced in https://github.com/ocombe/ng2-translate/commit/4b78732e. I'm using rxjs 5.0.0-beta.2 as angular2.0.0-beta13 uses this exact same version.

Thanks, someone reported a problem yesterday but he was using RxJS beta 4 and it worked after he downgraded to beta 2, that's weird that you have this problem on beta 2, I'll check asap.

I've had similar trouble, I think the package needs to reference ^5.0.0-beta.2 or ~5.0.0? Otherwise it has a hard dependency on the older beta version.

I have the same issue. Are there any temporary hot fixes?

Hi, we've encountered the same problem. In my case my app still boots and the translation are done, but I get an error on runtime: Uncaught ReferenceError: require is not defined.
As requested by others, I would also like to know if there is a planned fix until angular upgrade RxJS version? Even though it is functionnal, an error is a blocker for prod. Thank you! And thanks for this great library.

Observable.of is added to Observable by calling import 'rxjs/add/observable/of';.
I just released a new version that removed most peer dependencies, included the dependency to RxJS. It's still a dependency but since I use the same as Angular 2, I don't need to specify it (I think).
Let me know if it fixes some of your problems ?

As said it the first comment, observable.of is not imported in 5.0.0-beta.2
I tried removing my ugly patch and fails again on the same error.
Note that I use Observable.of in my app and it works fine, even with me registering the dummy, so the import must not be the way it is used in beta2.

Well I don't know what to tell you, but RxJS 5.0.0-beta.2 has rxjs/add/observable/of on npm, just check on npmcdn<EMAIL_ADDRESS>And I reinstalled it locally after doing npm cache clean just to be sure.

It has the functionnality, but is not used. The Observable 'class' already have a static method of. It was changed in beta3. The only thing it means is that you simply don't need to import it, or in your case, require it.
And a quick search in the minimed rxjs beta2 file shows that it is not there. Perhaps they fixed it, without fixing the minified file. I'll do some tests today.

Okay, then can you make a PR to fix it? if it passes the tests I'll merge it :)

By the way, I think that just adding this line should make it work for systemjs: https://github.com/ocombe/ng2-play/blob/ng2-translate/index.html#L27

I did, but I'm not using /node_modules/rxjs/bundles/Rx.js. I'm using /node_modules/rxjs/bundles/Rx.min.js

Ok, it makes sense then. That's why I like webpack much better, it bundles just what it needs :-)

I created a pull request. I did test it on my own, and did automated test on my project, but running npm test on the fork of ng2-translate resulted in error TS6053: File 'typings/main.d.ts' not found.
Not sure what I'm missing, and the checks do not pass...

I have the same issue.
For the moment, the work around of @KevensPronovost works :
System.register('rxjs/add/observable/of', [], function(dummy) { return { setters: [], execute: function() {dummy('default', null); }}});

i added patch: System.register('rxjs/add/observable/of', [], function(dummy) { return { setters: [], execute: function() {dummy('default', null); }}}); in index.html
It work . But when i change language two time i get error : EXCEPTION: TypeError: Observable_1.Observable.of is not a function
Anyone help me to fix this issue, please ?

It seems my patch works only because we are not using the part of the code that makes uses of rxjs/add/observable/of. The problem is it is not in the rxjs minified version, so the require fails without the patch. Hopefully, angular will upgrade rxjs version soon enough, so that we can move on to the corrected version too.

Angular beta 17 now uses RxJS beta 6 ! Does this fixes your problems ?

It should, we'll upgrade today or next monday and tell you the verdict

The issues seems to be solved. Patch removed and everything works perfectly. Still need to port the rest of our app to angular, so not in prod yet, but I'd say the issue is fixed.

I confirm the issue is solved. I just tested. You can close this issue.

Cool thanks!

in my case I was importing JUST Observable
import { Observable } from 'rxjs/Observable';
so I needed to add "of"
import 'rxjs/add/observable/of';


[Feature Request] Add More Statistics

Hi! I believe that the current goals statistic is awesome! it can be a great motivation to keep the streak. In addition, it would be very helpful to see some more, examples I would like to:

Reading speed graph - average reading speed over days
Number of lookups with Yomichan - number of lookups speed over days (is it possible?)
Books difficulty - average difficulty (to be calculated) of reading books over days (is it possible?)
(to calculate the book's difficulty and other stats services with API like voyant-tools.org can be used.)

Hi,
ty for your suggestions.

Will be added by #270 which should contain graphs for the configured date range and existing data like characters,time and speed

Probably not possible to do it reliable. Only thing the reader could hook into would be highlighted words but this would generate a lot of noise with other functionality like selection to bookmark (and for sure if #21 will ever land) and also not have access of dictionary forms etc. Better to ask the yomitan team directly to integrate it inside the extension

Don't think there is any service available which is not just a simple short unit tokenizer / free for the amount of data required for complete epubs. While it would maybe be possible to add an scoring to books i am not really convinced that it makes sense as part of the statistics. Most people will read the same book for a longer period of time and the number will not change.. also the score would be kind of arbitrary.. without any connection to user knowledge (which is not planned to be added in the scope of this project for the time being) / known words i think the benefit is probably low. Therefore i see it as not planned right now

As only 1 as duplicate remains i will close this issue while keeping a general scoring for 3 in mind for the (not defined) future


wip: fix: avoid export * in magic files for shaking

fix: add mainFields to client build to resolve ESM
fix: force sideEffects false for browser route modules

Fixes https://github.com/remix-run/remix/issues/1618


feat(react-query): useSuspenseQuery

@manudeli FYI

@TkDodo
I made https://github.com/TanStack/query/pull/5755 to add and update types for useSuspenseQuery. Review it please

UseSuspenseQueryOptions
UseSuspenseQueryResult

Codecov Report
Patch coverage has no change and project coverage change: +0.75 :tada:

Comparison is base (77bd2c3) 88.87% compared to head (bd7126e) 89.62%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##            alpha    #5739      +/-   ##
==========================================
+ Coverage   88.87%   89.62%   +0.75%
==========================================
  Files          71       65       -6
  Lines        2390     2131     -259
  Branches      620      526      -94
==========================================
- Hits         2124     1910     -214
+ Misses        218      189      -29
+ Partials       48       32      -16

Impacted Files
Coverage Δ

packages/react-query/src/infiniteQueryOptions.ts
0.00% <0.00%> (ø)

packages/react-query/src/useInfiniteQuery.ts
100.00% <ø> (ø)

packages/react-query/src/useQuery.ts
100.00% <ø> (ø)

...ckages/react-query/src/useSuspenseInfiniteQuery.ts
0.00% <0.00%> (ø)

packages/react-query/src/useSuspenseQuery.ts
0.00% <0.00%> (ø)

... and 9 files with indirect coverage changes

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

@TkDodo I made #5755 to add and update types for useSuspenseQuery. Review it please

UseSuspenseQueryOptions
UseSuspenseQueryResult

If you accept this change I also want to add UseSuspenseInfiniteQueryOptions, UseSuspenseInfniteQueryResult

I checked these types is merged, I'll add UseSuspenseInfiniteQueryOptions, UseSuspenseInfniteQueryResult right now.

@TkDodo
I made https://github.com/TanStack/query/pull/5766 to add and update types for useSuspenseInfiniteQuery. Review it please

UseSuspenseInfiniteQueryOptions
UseSuspenseInfiniteQueryResult

@ChanhyukPark-Tech (one member of @suspensive/react-query team, same as me)
I'd like to request that you help us(me and tkdodo) making official interfaces of @tanstack/react-query about suspense, by Review, Pull Request, etc. your participation will be of great help in making this to a reality.


Added building/leaderboard tests, modified readme, added tests to github action

Need to fix line adding tests to github action


small GUI with the ConsoleMeter from Tukan

First of all, thanks a lot for your work on this. It's amazing!
When opening the ConsoleMeter plugin from https://github.com/TukanStudios/TUKAN_STUDIOS_PLUGINS in ysfx, the display is very small, see below

Changing the windows size does not influence the size.
Within Reaper, making the window bigger scales the displayed part

This is with the current master on linux (Gentoo).

Hi,
indeed, the resized editor window does not currently modify the size of the jsfx graphics area.
Reaper would modify the values of gfx_w, gfx_h to match the view size.
Ysfx would assume a graphics area to be fixed size or programmatically-sized; and on resize, just recenters the gfx view into the editor. This behavior is implemented in YsfxEditor::Impl::relayoutUI.
Will fix when I have a bit of time.

Thanks for your quick reply. I tried to scale it by having gfx_{h,w} set to better value, but it's more involved than that and hence above my limited understanding of jsfx. Looking forward to your changes.

If you would like to edit the script, check near @gfx where default width and height are defined
@gfx 190 88

Thanks, setting it to @gfx 800 200 provides a good workaround


remove online status from state

Remove online status from device state. Instead, create a REST endpoint to check online status, since it has the potential to take such a long time when the host is down.
Create a new Button component that will check online status of a configured host and update its disabled status according to a configuration. Use a property like disabledWhileOnline or something similar.

Bonus points for adding a little embedded loading icon while it checks for online status.


MAINT: Increase minimum required LAPACK version to 3.3.1

This needs some discussion on the mailing list.
It increases the minimum required LAPACK version to 3.3.1 (it's currently 3.1.0). The version of LAPACK available by default on Travis CI is 3.3.1, so I don't expect this to cause trouble with the CI systems. Since 3.3.1 isn't quite as old as 3.1.0, I still need to mention the requirement in various places in the docs. Other than some extra documentation, this should all be working now though.
There are a few advantages. One is that explicitly requiring more recent versions lets us avoid errors like https://github.com/scipy/scipy/issues/5039. Another is that this lets us provide a more complete Cython LAPACK API. The functions exported to Cython currently include only the routines common to every LAPACK version from 3.1.0 to 3.6.0. Increasing the minimum requirement lets us export another 169 routines through that interface.  Updated on successful CI builds.

What does OSX Accelerate provide?

Hmm. It appears that, as of OSX 10.10, it still only provides 3.2.1. Since that was the last LAPACK version to support CLAPACK, I don't know if they have any plans to update.
There's some inherent tension between using an up-to-date LAPACK and supporting the CBLAS interface. I'm not sure what the best resolution is though.

The only option for Accelerate would be to ship and build LAPACK 3.3.1 against the BLAS in Accelerate.

Yep. In general, I see three ways forward here:

Leave the minimum at 3.2.1 indefinitely
Drop support for Accelerate
Build a more recent LAPACK from source with our CBLAS ABI wrappers.

None of these options are at all good. Dropping support for Accelerate seems like the "least bad" option to me personally, but others are very likely to disagree.

Accelerate makes it very easy to build SciPy on OSX. Dropping it seems like a bad idea, at least I would object. If I have to mess with ATLAS again, chances are I would not bother to contribute. It would also set back the performance of free SciPy builds tremendously.
The part of Accelerate we really need is BLAS. If we do a real house cleaning, we could build something like libVecFort, which would overshadow most of BLAS and (in our case) all of LAPACK, and we could even do away with the ABI wrappers.

My suggestion would then be a forth option, not on your list.

On Accelerate, overshadow some of BLAS like libVecFort and our sgemv fix, overshadow all of LAPACK.

It would be a shame to make it difficult to compile scipy with Accelerate.
First - that is by far the easiest way to get BLAS / LAPACK on Mac.
Second - some people want Accelerate specifically - see : http://vtk.1045678.n5.nabble.com/VTK-and-Python-on-OS-X-El-Capitan-tp5734265p5734280.html

Dropping support for Accelerate would be quite painful, doesn't seem worth it. Here's another suggestion:

require 3.3.1 except when Accelerate is used
ship the sources from refernece LAPACK for the added routines between 3.2.1 and 3.3.1
if Accelerate is detected, then build just the missing routines separately

@sturlamolden this seems a bit different from what you suggest, although I don't completely understand your libVecFort idea.

@rgommers Your auggestion would work too, but it might require a BLAS with gfortran ABI (depending on which BLAS function the added routines will call). Your suggestion certainly means shipping less code than mine.
What I suggested is when Accelerate is present:

Use Accelerate to build a BLAS with gfortran ABI
Build LAPACK on top of this
Drop the g77 ABI wrappers from SciPy

This requires us to use a feature in OSX called DLL overshadowing. This is what we use to correct SGEMV and what libVecFort use to create a BLAS with gfortran ABI on top of Accelerate.
I would also like to point out that libVecFort already does most of this. So if their license allows it we could just use their code.

@rgommers If we are going to use your suggestion, we have to be careful to compile the missing parts of LAPACK with g77 ABI, and then make sure they are exposed to SciPy with gfortran ABI.

I would also like to point out that libVecFort already does most of this. So if their license allows it we could just use their code.

vecLibFort (https://github.com/mcg1969/vecLibFort) not libVecFort - took a bit of effort to find:) It uses the Boost license, which is BSD-compatible.

I think we can fairly easily bundle the missing routines, for use with Accelerate.

I'm not sure if we need vecLibFort --- afaics, it is similar to what we currently do, with the difference that it shadows the symbols rather than renaming them. Namely, remember that we have patched our fortran source codes with replaced names for the functions.
Since MKL also appears to need g77 abi wrappers, if we switch to shadowing (and revert the replaced names in the fortran sources), we need to verify that the way we shadow works on all supported platforms, not only osx.

However, since the deprecated/new lapack routines afaics are just subroutines, they are abi compatible as-is. So afaics, the discussion about abi wrappers is not directly relevant for including the missing lapack routines.

Ok, but we need to compile the missing routines with -ff2c in case they happen to call functions like SDOT in Accelerate.

Sorry, we can of course patch the lapack sources.

Yes, we are currently using the patching approach everywhere, so we'd need to do that also to the new LAPACK sources.
We can of course change the way we deal with the abi issue, but that's probably more work.

For ARPACK, the necessary patching incantation is here: https://github.com/scipy/scipy/blob/master/scipy/sparse/linalg/eigen/arpack/ARPACK/README.scipy#L14

I was not aware that we are currently patching all our Fortran sources. Let's just continue with that, although it is more tedious in the long run.

Thanks for reviving this. I'll go ahead and start updating it to include the missing routines.
Is mixing newer LAPACK sources with functions built as a part of an older LAPACK library generally a safe approach? Some of the newer routines may rely on stability fixes in their dependencies. That said, it seems like most new things in LAPACK come packaged as entirely new routines, so that may not be a concern.

As linked above, I've recently implemented the LDLt decomposition, but I found out that some of the LAPACK routines are absent due to the minimum required version.
LAPACK 3.5.0 came out in November 2013 and that's already 3 years ago. I think shifting the current SciPy requirement to a version like 3.3 (from 2011!) would make this discussion repeat every couple years.
I don't have much knowledge about OSX environment but including newer versions of LAPACK shouldn't break the old code since LAPACK maintainers also worry constantly about such issues. In fact, I don't see why Accelerate is not kept up-to-date with latest BLAS/LAPACK.
May I suggest contacting ACCELERATE maintainers and pushing the version to something more recent probably the latest anyways while we are at it?

Note that the Accelerate maintainer is Apple, and I think they have
little incentive to listen.

Certainly true but sometimes they just forget instead of the usual resistance to change. It might be worth giving a shot in my opinion.

Apple is not going to listen. They will uppdate Accelerate as they see fit. Also, Apple is not going to push updates to Accelerate's LAPACK version into previous versions of OSX or iOS. SciPy should not require a specific version of OSX. Contacting Apple is not going to solve this problem.
If we are going to bump the minimum LAPACK version into something more recent, we have to build our own LAPACK on top of Accelerate's BLAS and overshadow the Accelerate framework. This is quite easy though. BLAS has a fixed API since forever so it should not pose any major problems, apart from having to ship LAPACK sources with SciPy (or download on demand). It will increase the time to build SciPy on OSX though. Some of us developers are not going to be too happy about that (me for instance).

On the other hand getting stuck with old code on Linux and Windows outweighs all this risk that is only valid for mac users. I would also be unhappy if I can't compute certain things because somebody else's Mac. I think this type of argument won't do us any good.
Given my limited knowledge, I would certainly be willing to contribute if we can just free ourselves from such version dependent problems. I have already written a lot of flapack signatures. And if need be I can dedicate some time just for this purpose.
We are talking about code that is a decade old here.

Options:
.
(i) Bundle the new lapack parts.
(ii) Reconsider dropping Accelerate, at least for LAPACK.
.
I would perhaps suggest (ii). Getting Fortran compilers on OSX is IIRC a
PITA, except if you are using macports/homebrew etc., so I think most
people are using those in practice. If those package managers do ship
also LAPACK, then I guess it's not such a big deal to drop Accelerate.

Ok, there is nothing that prevents you from computing anything because of someone else's Mac. LAPACK is free and available to anyone, even us Mac users. The questions is do we want to include this in SciPy? If we do, there is enough Mac users to warrant a patch for providing the missing functions in Accelerate.

Getting a Fortran compiler on OSX is not a PITA. We can just download the binary installer from the gfortran wiki. (Which incidentally is what i do for Windows as well.)

https://gcc.gnu.org/wiki/GFortranBinaries

Perhaps, I should restate what might have come as a snarky comment. What I mean is that there will always be some stakeholders that would get affected and object. Hence it is not the optimal way to judge based on whose disadvantage is worse.
So maybe it is better to go for a solution for all users and consider what the most encapsulating option given its disadvantages is. For me build time increase is a viable downside to have the freedom of whichever version of LAPACK lives under the hood of SciPy.

But I still want to be optimistic (or stupid : -D ) about trying our chance to contact Apple about this issue.

It should also be noted that having a Fortran compiler is a requirement for building SciPy, so this should not be an argument against including more Fortran sources.

We already have the incantation for framework overshadowment conditional on Accelerate (due to am SGEMV patch by yours truly), so it is basically a matter of adding the missing Fortran sources. The build script and DLL magic is already in place.

Sturla - would you consider making a PR for this?  That would be very helpful, if so.

@matthew-brett Sure, I just need to know which Fortran routines to include.

Great!  I am happy to help review.   @insertinterestingnamehere @ilayn @pv - what extra routines do we need for 3.3.0 compatibility and Accelerate?

Maybe I'm missing the whole picture but if there are no restrictions on the extras why don't we jump to the latest version 3.6.1? They are in the order tens to be added over 3.1.
I can make a list this evening. Also, there are bug fixes over the years that made it better such as ?gebal for instance.
Is my understanding OK with reality?

@ilayn One restriction would be what MKL provides. So which minimum MKL version should we require and what LAPACK version does it have?

In 3.4.0 lapacke is integrated which might help on the C front. And it is contributed by the MKL team.
See here all the changes http://www.netlib.org/lapack/
So I guess at least 3.4.1. I'll have a look.

On their website, they mention 3.4.1 under Linear Algebra section. https://software.intel.com/en-us/intel-mkl/details

That is the latest MKL, but I think older MKLs are in use. Enthought used to provide version 10 in Canopy, IIRC, not sure what they do now.
@rkern What is the maximum LAPACK and MKL versions Enthought can accept without a lot of extra trouble?
And we should probably also ask ContinuumIO the same for Anaconda (not sure which user to ping).

It can go up to 3.6 according to MKL version 11.3 https://software.intel.com/en-us/articles/intel-mkl-113-release-notes and the latest version https://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-2017-release-notes

But that is assuming MKL users have the latest, which many of them do not. Doing the same for MKL as we do for Accelerate means we need incantations for all platforms, since the DLL magic is OS dependent. That would be too much of a PITA. I would not know how to do it on Linux. On Windows it would probably take some serious Windows API coding.

Indeed that might be the case. For the particular case of Windows, almost all Windows users are using @cgohlke 's binaries anyhow. So maybe he can also chime in.

No, they do not. Canopy and Anaconda are quite widespread in the academic world.

Ah yes sorry, I mean users who are not using a distribution.

Yes, and breaking SciPy for one of the major distributions by bumping the LAPACK version too much is not a good thing.

@sturlamolden It looks like we're on MKL 2017 Update 1 at this time. That gets us up through LAPACK 3.6, I think: https://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-2017-release-notes

The reason I opted to go for version 3.3.1 is because, at least when this PR was made, that was the most recent version available on the Travis CI Ubuntu trusty images. I'm not opposed to increasing the version beyond 3.3.1, starting there just seemed like a move in the right direction.
Support for 3.6.1 would be great, but adding that by mixing newer source files is the kind of thing that could cause terrible bugs. It leaves us open to whatever bugs that may arise when mixing source files from across multiple releases rather than giving us a single coherent release to work with. The LAPACK developers don't usually make a ton of changes to algorithms after they are published, but having to work around existing bugs in an older release so that newer routines can work properly is not an attractive prospect. Including extra source files is the best approach for now, but it's not necessarily something we want to continue long term. Optionally vendoring all of LAPACK is a possible (though painful) solution with its own troubles.
Overall, I favor dropping support for Accelerate instead of continuing with the patching and extending. The disparity between what SciPy requires and what Accelerate provides is getting very big. It'd make more sense for interested parties make a separate C library that provides a modern LAPACK interface on top of Accelerate. The situation is pretty bizarre as things stand. For example, all of the following are true of SciPy, except when someone is using Accelerate:

CLAPACK is not supported
Vendor specific BLAS/LAPACK bugs are the vendor's responsibility to fix
SciPy is safe to use with multiprocessing

I'm not anxious to add the disclaimer "LAPACK 3.3.1 is required except..." as well. The interfaces provided by Accelerate and LAPACK will continue to diverge so long as LAPACK continues to progress, so dropping support for Accelerate looks like a very necessary change. Apple is providing no updates and only minimal bugfixes for Accelerate. At this point, shipping or requiring an additional shared library with an updated interface seems like a much more robust approach.
As to the specific roadblocks in this PR, I don't have current easy access to an OSX machine, so it's much harder for me to test at least for now. I remember that there were a few remaining issues involving my additions to the ABI wrappers. Also, this PR, as it stands, doesn't add any of the routines that are available in 3.3.1 and not in 3.2.1. I'm not aware of any issues beyond that.

I continue to think we should keep supporting Accelerate because:

there are people who specifically want to link numpy and scipy to Accelerate, believing (right or wrong) that it is the fastest implementation on OSX, and
it is the easiest version to build against.

A compromise would be to drop Accelerate's LAPACK but still use it for BLAS. BLAS can be considered a frosen API. We would need to ship all of LAPACK with SciPy though, but it is a small dependency. We will also avoid bugs from mixing new and old source files. Dropping Accelerate's LAPACK will have minimal consequences for performance BTW, this is what we do for OpenBLAS too. Building LAPACK is also very quick and requires no special build process beyond gfortran -c *.f.

It is a misunderstanding that Accerates conflicts with multiprocessing. With Python 3.4 it does not. Also, Accerate is not the only API which is unsafe to use between fork() and exec(). This more or less applies to any Apple-specific framework.

A compromise would be to drop Accelerate's LAPACK but still use it for BLAS. BLAS can be considered a frosen API

That sounds like a good plan.

It means adding about 55 MB of Fortran sources (uncompressed) or 6 MB compressed. Would it be ok to uncompress a zipped tarball as a part of the build process when using Accelerate on Mac?

Sorry, if I strip out all the unneccessary parts (BLAS, CBLAS, LAPACKE, docs, tests) it is about 27 MB uncompressed.

Don't forget that git compresses files when staging, so you won't save much
space in the repo by committing the compressed version.  I don't think the
extra MB matter much in the working tree.

Ok. A stripped down lapack tarball is about 3.4 MB gzipped and 2.2 with bzip2.

Or, download it from the web during build and check the sha256 checksum, and maybe add an option to the setup to turn this off.

Or maybe someone makes a wheel and scipy links to it like OpenBLAS via setup.cfg or some such.

And what do we do with the XBLAS dependency of later LAPACK versions?

afaik, xblas is an optional dependency.

Only using BLAS from Accelerate seems like a good way forward. Especially since the multiprocessing issues are supposedly fixed with later versions of Python.
WRT XBLAS, last I checked, that isn't enabled by default. It doesn't look like anything depends on it, so we should be fine ignoring it entirely.
Directly including the sources or providing wheels and conda packages for the library will both work well. Downloading at build time seems a bit more fragile, but that'll work fine too.

XBLAS might not be enabled by default, but we have to build this with our build processes (distutils and bento), not with Lapack's CMAKE stuff. Manual deletion worked fine.

This is what you need to do to build this thing: Download http://www.netlib.org/lapack/lapack-3.6.1.tgz uncompress and cd to folder SRC.
$ rm *fsx.f
$ rm *svxx.f
$ gfortran -O3 -c -ff2c *.f
$ gfortran -shared -o lapack.so -ff2c *.o -framework Accelerate

It looks like there is a quasi-consensus on @sturlamolden's suggestion. Can I be of any use?

I have encountered some minor problems related to how we should do this. Unfortunately a lot of the build process seem to be upstream in NumPy, so I cannot fix it in a PR to SciPy. Either I have to dump LAPACK sources in SciPy, and provide it together with the wrapper files, in which case building with Accelerate will take for ever to compete. Or, alternatively, we build this as a library separate of SciPy, in which case we loose the simplicity of building with Accelerate. I am not sure which is worse.

I think dumping LAPACK into scipy is a no-go.
.
Since monkeypatching numpy.distutils is probably no-go also, you'll need
to dig up all get_info('lapack') calls in the setup.py files, and
replace them with our own scipy._build_utils._lapack.get_lapack_info()
that does the equivalent thing.
.
If you want to ship a "scipy_accelerate_lapack" wheel on Pypi, a check
for OSX+Accelerate needs to be added in the main setup.py, and if this
situation is detected, the package can be added as a setup_requires +
install_requires dependency.
.
Other alternatives are also possible (eg download, check checksum, and
build from internet).

LAPACK 3.7.0 is announced recently. http://www.netlib.org/lapack/lapack-3.7.0.html

I like the direction this is going in.

Or, alternatively, we build this as a library separate of SciPy, in which case we loose the simplicity of building with Accelerate.

A separate library is probably still very simple for the user. The conda-forge SciPy is built against OpenBLAS, so we only need to make this work with wheels. With the right *_requires incantation in setup.py that's completely transparent for a user.

Since monkeypatching numpy.distutils is probably no-go also

agreed
A few more comments:

downloading sources during build is not a good idea, too fragile. The scipy_accelerate_lapack wheel solution is better.
don't worry about the Bento build for any PR, I'll fix that afterwards.
I can help with packaging the new lib if needed.

From what I read, a wheel will be binary. But then we need different wheels for various Fortran compilers on Mac? Could we use a source distribution on PyPI instead?

Another question I have is that suppose we took the separate package route and created it, let's call it, scipy-lapack. Then also let's suppose that Accelerate users installed it to use the latest, greatest version of SciPy.
Would it be a possible scenario that LAPACK versions collide system-wise or Accelerate won't let go of the default search path?  (I'm really not into Mac so I expect anything from a closed system. Hence apologies if this doesn't make sense).

@ilayn We build a library that overshadows parts of Accalerate (LAPACK, parts of BLAS with g77 ABI) and re-export the rest of the framework. The result will be a framework identical to Accelerate, except with gfortran ABI and up to date LAPACK. We are not going to make collisions with system libraries.

It's correct that the scipy_accelerate_lapack package needs to have a well-defined ABI. I think this will be possible to guarantee. It may also be useful to not use numpy.distutils here, but instead eg. require gfortran for the compilation. Since the ABI is fixed, the compiler used don't matter, and since the package doesn't need to be portable anyway, we can just pick the easiest one and trust that people compiling from source have some minimal knowledge of setting these things up.

But then we need different wheels for various Fortran compilers on Mac? Could we use a source distribution on PyPI instead?

We can build the wheel just with gfortran. It's a standalone shared lib, so even if a user wants to build the rest of SciPy with OS X with ifort, that should work.

Could we use a source distribution on PyPI instead?

That would work too. Potentially more fiddly and longer compiles for each build then though, so spending a bit of effort once per update (which presumable is less often than the SciPy release frequency) may be justified.

 Or should I build it as a Python extension module? Presumably we do not want to create DLL Hell.

How about installing it as a Python package and getting the include path via a function ala np.get_include?

How about installing it as a Python package and getting the include path via a function ala np.get_include?

If we put it in a non-standard location, we have to set the LD_LIBRARY_PATH environment variable or else the dynamic linker will not find it.
For standard locations we have /usr/local/lib which is accessible for all users but requires sudo. ~/lib is local to the user and do not require sudo. We should not require sudo, but we should not limit ourselves to local install either.
The normal way of doing this on a Mac is of course to put the .dylib inside a Frameworks folder in an app bundle. But we are not distributing Python and SciPy as an app bundle.
Python extension modules have their own loader, so this does not apply. However it will not load all the required symbols if we just dump LAPACK into it. We can however use a static scipy-accelerate-lapack.a library and link it into each Python extension which requires BLAS or LAPACK. This will create bloatware though, but is perhaps the less fragile solution.
😒

But if we use a static library it becomes compiler dependent, because of things like libgfortran
😒

How about installing it as a Python package and getting the include path via a function ala np.get_include?

If we put it in a non-standard location, we have to set the LD_LIBRARY_PATH environment variable or else the dynamic linker will not find it.

Right, that wasn't a great suggestion. Summary of your summary: there is no ideal solution.....

If we put it in a non-standard location, we have to set the LD_LIBRARY_PATH environment variable or else the dynamic linker will not find it.

Actually, I'm pretty sure there's a way to avoid that. When you link to OpenBLAS for example via a nonstandard path in site.cfg, then you don't need LD_LIBRARY_PATH. There's a "redirect .so" (I'm sure there's a proper name for that) generated. Example from https://leemendelowitz.github.io/blog/installing-numpy-with-openblas.html
ldd home/venv/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
(venv)bash-3.2$ ldd lapack_lite.so
        linux-vdso.so.1 =>  (0x00007ffff40b9000)
        libopenblas.so.0 => ../lib/libopenblas.so.0 (0x00002b098e0a1000)

The same is true for conda - you can switch from MKL to OpenBLAS without messing with LD_LIBRARY_PATH - this is taken care of in a similar way I think.

I hope someone who understands this better than ne can explain it. Meanwhile I am reading  Apple's DLL programming documentation and trying to make sence of it...

@sturlamolden here's a clear explanation of what conda does: http://conda.pydata.org/docs/building/shared-libraries.html#shared-libraries-in-linux-and-os-x.
Note that with wheels the @loader_path, i.e. a relative link from within scipy, won't work (too many places to install to, with --user for example). @rpath seems more appropriate. With that it's still unclear to me though how you could ever support a path that has a username in it (like you'd get with pip install scipy-accelerate-lapack --user).
@matthew-brett you seem to have been digging into this in the past (http://matthew-brett.github.io/docosx/mac_runtime_link.html). Any suggestions?

Back in the good ol' days we would just do
$ make
$ sudo make install

and it would work.
The annoying thing is, it still would.
Sometimes technology gets too smart.

Should we take some action regarding this to make it to v0.19 or is it too ambitious?

That'll likely be too ambitious. Making this happen for 1.0, i.e. within 4 months or so, would be really good.

Since LDLt issue popped recently a few more times, I'd like to draw your annoyance at me one more time for a gentle ping.

It is not a problem to build the library. The question is how to integrate this with the SciPy build process. Also, the recent suggestion to drop 32-bit support will help to make this easier.

I would like to work on this but I have no idea what the actual blocking issue is. The discussion above came close to a conclusion a few times but then diverged to other issues. Would it help to detach the discussion from this PR?

The blocking issue is this: We want to preserve the simplicity of building SciPy on Mac, which is
$ python setup.py install
If we have to fiddle with building a library, installing it and setting up configuration files, we can just as well use OpenBLAS.

Build and link the library (the easy part)
How do we distribute a binary library using a binary wheel?
In which location do we install the library?
How do we modify the build process to use this library, given that all incantations for linking with Accelerate is upstream in NumPy?

The technical issue is not how we can build an up to date LAPACK against Accelerate BLAS. That part is easy.

@ilayn - replying to https://github.com/scipy/scipy/issues/7262#issuecomment-291780885 - can you say what kind of comment you'd like from me?   I still think (for the same reasons that I gave before) that we should keep the option to build with Accelerate, but I don't feel strongly whether it should be the default.

In the previous comment sturlamolden gave a summary and I thought you might chime on the last point (or all of them of you wish).
But actually, given that I'm the only one, (seemingly), in need of recent version of LAPACK, I think this is indeed pointless to discuss anymore here. It boils down to a decision to be made so I'll stop pinging this item. I'll wrap the newer items in a separate library for now.

I don't think you're the only one who wants/needs it. It'd be more accurate to say that apparently you've got the most favorable ratio of motivation/time to make it happen :-).

For Sturla's comments:

distributing the library, once it is linked, is done automatically with the delocate and auditwheel tools (the libraries get copied into the wheel) - so this shouldn't be a problem;
because of the above, it doesn't much matter where we install the library, for the wheels, because it will get moved anyway;
I defer to Ralf on details of linking to extra libraries - but I guess this isn't too hard either.

I still think the advantages of having an Accelerate build are great enough that we should put in the (I think, moderate) extra effort to support it, with the higher version of Lapack.
@sturlamolden - if we can solve your problems above - how much work is needed to get this done?

I'd love to see this happen just from a maintenance point of view.
It seems pretty important that we don't get tied to a fixed LAPACK version because one of our LAPACK vendors has stopped following newer releases.
Currently the interfaces we can support across all LAPACK versions shrink every time a new LAPACK release comes along (thankfully it's not terribly often) and we can't currently compensate for that at all by increasing the minimum version required.
Fixing this would also provide a clearer answer for things like https://github.com/scipy/scipy/issues/5266.

Upon the recent discussions under #7131, I have bundled a summary draft at https://github.com/scipy/scipy/wiki/Dropping-support-for-Accelerate it would be great if you can populate/edit/clarify the options further there for a more focused discussion.

Sad as it is, it is time to drop Accelerate. Integer overflow is even present in fundamental BLAS functions like *GEMM. This means that even the proposed solutions will never work properly. Even if we build LAPACK on top of Accelerate's CBLAS it will still be unstable. There is no chance of Apple of Apple ever updating Accelerate or fixing the known bugs. Dropping Accelerate support is the only sane solution, even for NumPy. We need to focus on supporting MKL, OpenBLAS, and ATLAS.

Also note that ATLAS has this problem, it is not Accelerate specific. It is due to the helper functions catlas_dset et al.

Excellent summary. Thanks for writing that up. We will probably be able to move to a LAPACK even more recent than 3.3.1 depending on when we do this since Ubuntu precise and the corresponding Travis images are hitting end of life right now. See https://blog.travis-ci.com/2017-04-17-precise-EOL. The new Ubuntu Trusty images should have LAPACK 3.5.0 and they should be the default very soon. Moving to 3.5.0 would be nice if there aren't other major constraints.

We seem to roughly agree on dropping Accelerate. Also on the mailing list thread (https://mail.python.org/pipermail/numpy-discussion/2017-July/077069.html) no one disagreed.
It's a bit late for code changes to go into 1.0, but we could make the decision now and add some comments on that in the release notes. So I'll leave the 1.0 milestone for now.

Just to say, I'm kind of +0 on dropping Accelerate (I mention it because I was advocating for keeping it earlier).

If I could I would have done it by now but unfortunately this task way above my build-fu. Maybe should we ask for volunteers first so that the discussion doesn't start from scratch ? And those, if anyone steps up, can have a more specialized discussion.

The same problem is present i ATLAS, so should we drop ATLAS too?

Sorry, this was about the LAPACK version. I was thinking about the integer overflows, which was also an argument against Accelerate.

@sturlamolden I don't think so, one bug is not enough. The situation with ATLAS is fundamentally different, it's open source and still actively developed. This is the last message on the ATLAS mailing list, from a month ago:
Guys,

I am now at Indiana University, having just completed my move, and am
presently preparing to teach next week.  This is a reason for the delay
in responding to the several 3.10 patches/questions just recently.  I am
keeping your e-mails, and will respond as soon as I get on top of the
new place and its processes.

The recent delay in developer releases is because I rewrote my
microkernel handling for greater efficiency, and it has taken a *long*
time to get it working again.  We are presently working on greatly
improving our non-GEMM small-case performance, which I think is going to
be worth the wait when I get it out.

Anyway, I'm still working on both stable & developer, and will respond
as soon as I can.

Cheers,
Clint
--
******************************************
** R. Clint Whaley, PhD, Assoc Prof, IU
** http://homes.soic.indiana.edu/rcwhaley/
******************************************

If I could I would have done it by now but unfortunately this task way above my build-fu.

@ilayn you're talking about the build issues involved in shadowing right? Or in packaging an OpenBLAS wheel?
It seems like we're not 100% decided between completely dropping and shadowing. Dropping is way easier. I would be okay with just dropping first, and updating to a recent LAPACK (probably 3.5.0, to be checked - see https://github.com/scipy/scipy/pull/6051#issuecomment-317155562). Then shadowing can be attempted later, if there's strong feelings about still wanting to use Accelerate.

@ilayn you're talking about the build issues involved in shadowing right? Or in packaging an OpenBLAS wheel?

Yes indeed. But if only the bottleneck is Travis images, can't we just update to new libraries on the fly via apt-get during the build ? (I don't know how Win machines define the version though) So that we can always keep up with latest version?

But if only the bottleneck is Travis images,

It's not. I'll try to write a summary.

Here's the considerations for minimum LAPACK version to support: https://github.com/scipy/scipy/wiki/Dropping-support-for-Accelerate#which-minimum-lapack-version-to-support.
I'd suggest we should start not too aggressively, and go for 3.4.1 for now.

I can see the rationale of some items and I can relate to them. But many of these concerns can be eliminated if those users stick to their SciPy versions. If they can build their SciPy in those machines then they can still build the old versions. Because then new version would only mean fixing bugs and adding features that won't rely on Fortran routines. This also related to other C/FORTRAN libraries we include.
Without new LAPACK versions they won't be using the new features that depend on newer BLAS/LAPACK libs in SciPy anyway. Hence they can stick to whatever SciPy they were using. I have the impression that backwards compatibility is assured by keeping the maintenance branches alive (which we do).
So I have the feeling that we are protecting users that don't exist. Obviously, I might be misjudging the situation.

Please consider LAPACK <= 3.4.0 as long as building Scipy for Python 2.7 on Windows with Visual Studio 2008, Intel Fortran compilers, and Intel MKL is supported.
The last version of the Intel compiler suite which is compatible with Visual Studio 2008 is "Composer XE 2013 SP1". It includes MKL 11.1.4 and LAPACK 3.4.0 according to the header files on my system.

Thanks @cgohlke, I didn't think about that! 3.4.0 it is then, for a couple more years.

@GaelVaroquaux lectures us regularly on users in labs he's worked in that are stuck on clusters with old Linux distros though, so they do exist:)

I'm not saying that people stuck in legacy machines don't exist. I'm just saying that they won't be able to upgrade in any case. Hence my argument.
@cgohlke Does it help to use CMAKE system  introduced in 3.4.0 for your wheels? Because 3.4.1 and 3.4.2 are bug fix releases. You can find additional details here

IIUC, the build system of LAPACK is irrelevant for MKL --- Intel ships
prebuilt binaries which bundle some fixed LAPACK version.

Yah, as I understand it the issue with newer versions of MKL is having to use a different C standard library than the one linked to the Python 2.7 binaries. It's probably possible to get the older versions of the Intel compilers to build against a newer MKL and then rely on the fact that BLAS/LAPACK don't let resources cross their interface boundaries, but I'm not sure how much of a pain that'd be to set up.

I'm just saying that they won't be able to upgrade in any case

Still part of a commonly heard argument, and not really the case. It's fairly straightforward to compile SciPy on Linux, and that doesn't need admin rights.

@rgommers If we build LAPACK on top of Accelerate (i.e. overshadow) we are left with that one bug which is also present in ATLAS.

Personally I am in favor of dropping support for anything but MKL and OpenBLAS.

Still part of a commonly heard argument, and not really the case.

Well there must be a reason for it to be common. I don't see the point of trying to be up-to-date on a legacy system.  Out of our own clusters in Eindhoven we are not even allowed to adjust the time let alone building something.

I've added this in the 1.0.0 release notes:
This is also the last release to support LAPACK 3.1.x - 3.3.x.  Moving the
lowest supported LAPACK version to >3.2.x was long blocked by Apple Accelerate
providing the LAPACK 3.2.1 API.  We have decided that it's time to either drop
Accelerate or, if there is enough interest, provide shims for functions added
in more recent LAPACK versions so it can still be used.

Will now move this issue to the 1.1.0 milestone.

This PR needs an update, but can now be merged in principle. Could be extended as well, to LAPACK 3.4.0 (not higher, due to MKL + py27, see comments higher up). We're going to branch 1.1.x in the near future, can be either before or after that. @insertinterestingnamehere are you still interested in updating this PR?

Definitely still interested. I'll see if I can get the ball rolling on this again.

Great!

@insertinterestingnamehere If you need an extra hand for wrapping LAPACK routines let me know please :)

@ilayn the wrappers should be autogenerated once I update the script. That's not so bad. I could really use help getting the ci tests updated for osx and removing the accelerate specific code though. I can do a lot of that, but I don't have an osx machine to test with locally so it'll be a slow process waiting for builds to finish. I'm planning on improving the wrapper updates here in a separate PR, but things like removing the osx ci fixes could probably be done separately anyway.

@insertinterestingnamehere - I am sure we can find you an OSX machine to log into, if that would help?  Let me know via email?

@matthew-brett sent. Do you have a current download link for OpenBLAS on OSX as well?

@insertinterestingnamehere - I'm just asking round now, but we'll find you a machine soon.
Latest OpenBLAS at https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com/openblas-0.2.20-345-g6a6ffaff-Darwin-x86_64-1becaaa.tar.gz


Enable WPF, Windows Forms, UAP/UWP and Xamarin conversion

Detect WPF, Windows Forms, UWP and Xamarin (last 2 are disabled until simplification PR is merged)
Remove newly detected project types from list of unsupported ones
Add XamlPagesTransformation to prevent duplicated item inclusion (Page & ApplicationDefinition, handled by MSBuild.Sdk.Extras)
Add MSBuild.Sdk.Extras SDK usage to ProjectWriter
Add IsWindowsFormsProject & IsWindowsPresentationFoundationProject to Project model

XamlTransformationTest.cs was originally part of this commit, removed due to dependency on simplification PR. Will be pushed as soon as simplification PR is merged, either in this or separate PR.

Progress for #126.

Nice work!


Need option to switch between JS-Concat or Webpack

I don't know why, but webpack doesn't seem to work for me. How can I use gulp-concat and gulp-uglify, instead of webpack.
Instead, I want to just concat and uglify JS.
Also, please add an option for UnCSS and UnJS.

@boxdox Released v1.0.0 and removed gulp. Now Frasco uses npm-scripts to run tasks. Please have a try.


Update platformdirs version requirement to > 3.8.1

Issue
We have several packages that need greater than this version. For example, virtualenv requires >= 3.9.1, so that's automatically a conflict.
Looking at the platformdirs changelog, I can't see why Robocop needs to be locked within these versions.
This would be helpful to reduce conflicts, and in fact is our only Pip conflict in a complex repo.

The only reason is that I've just picked most recent version when I was adding this dependency. And this dependency is only needed if you are comparing past results. I believe it should be autoupdate by DependencyBot but maybe something didn't go well.. I will bump the version.


updating master

Codecov Report

Merging #153 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #153   +/-   ##
=======================================
  Coverage   99.33%   99.33%
=======================================
  Files          43       43
  Lines        1208     1208
  Branches      138      138
=======================================
  Hits         1200     1200
  Misses          8        8

Impacted Files
Coverage Δ

src/redux/reducers/datatableReducer.js
99.42% <ø> (ø)
:arrow_up:

src/components/DatatableHeader/Widgets/Add.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Add openLedStripReversed() to Rainbow HAT driver factory

Apa102.Direction.REVERSED flag for overloaded Apa102 constructor allows use of leds in reverse, left-to-right order, using the same indexes, which can be convenient for certain use cases.

Fixed in #34


Add git hash to version.

Codecov Report
Base: 96.66% // Head: 96.65% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (a656720) compared to base (8c861d5).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #195      +/-   ##
==========================================
- Coverage   96.66%   96.65%   -0.01%
==========================================
  Files          19       19
  Lines        4612     4599      -13
==========================================
- Hits         4458     4445      -13
  Misses        154      154

Impacted Files
Coverage Δ

src/dirgraphsvg/graph.rs
88.16% <100.00%> (-0.03%)
:arrow_down:

src/dirgraphsvg/util/font.rs
100.00% <100.00%> (ø)

src/dirgraphsvg/util/mod.rs
100.00% <100.00%> (ø)

src/gsn/mod.rs
97.77% <100.00%> (-0.03%)
:arrow_down:

src/main.rs
96.96% <100.00%> (ø)

src/render.rs
93.50% <0.00%> (-0.02%)
:arrow_down:

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

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


Remove tink backend

See https://github.com/tinkerbell/proposals/tree/main/proposals/0029.

During the integration of the frontend and backend work, we didn't write a backend for Tink server. #155 saw integration with Tink server dropped.


Audit & Logging

Hello!
I have installed the example that writes LOG to DB2 database successfully. Thank you very much.
Is it possible to use another database other than DB2? remote access is extremely complicated and our client requires a visualization tool for the information security department.
I will appreciate any advice!
(ANALYZE V4.3.5)

Hi Jormangonse
The auditing example that logs to database only uses DB2 as, in a lot of cases, that was the database type that customers would already be using for their information Store so it  removed the need to set up a separate database server.
There is nothing stopping you setting your auditing code up to connect to and store the data in a different database system and writing to that instead  or alternatively using  one of the non database examples to record the auditing data.
What is being logged in the example, where it is being logged, the table structures used for the logging, and other aspects  are all just  examples and we would expect that when you come to write a production version you would write whatever you needed for your specific requirements.
Cheers

As there has been no activity on this for over a month now I am closing this issue.

My apologies, I have successfully built the sample with DB2 and leveraged
the audit logs from another tool. Thank you!
El lun, 22 ago 2022 a la(s) 04:10, Tony Johnson @.***)
escribió:

Closed #65 https://github.com/i2group/analyze/issues/65 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/i2group/analyze/issues/65#event-7230410573, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXRNEKJTZJFLMTANCBKDVN3V2MYXRANCNFSM53S3M3FQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Jorge "Murray" González


[FEATURE] Get Workflow API

Is your feature request related to a problem?
We should have a get workflow API for a specific workflow to complement the search workflows API we currently have
What solution would you like?
The API path should be /_plugins/_flow_framework/workflow/yfRsposBMbAFAhZEJ1qE/ and should return the entire template object stored in the global context index. The response should be similar to the original template given:
{
  "name": "create-connector-register-deploy-model",
  "description": "test case",
  "use_case": "TEST_CASE",
  "version": {
    "template": "1.0.0",
    "compatibility": [
      "2.12.0",
      "3.0.0"
    ]
  },
  "workflows": {
    "provision": {
      "nodes": [
        {
          "id": "workflow_step_1",
          "type": "create_connector",
          "user_inputs": {
            "name": "OpenAI Chat Connector",
            "description": "The connector to public OpenAI model service for GPT 3.5",
            "version": "1",
            "protocol": "http",
            "parameters": {
              "endpoint": "api.openai.com",
              "model": "gpt-3.5-turbo"
            },
            "credential": {
              "openAI_key": "123"
            },
            "actions": [
              {
                "action_type": "predict",
                "method": "POST",
                "url": "https://${parameters.endpoint}/v1/chat/completions"
              }
            ]
          }
        },
        {
          "id": "workflow_step_2",
          "type": "register_model",
          "previous_node_inputs": {
            "workflow_step_1": "connector_id"
          },
          "user_inputs": {
            "name": "openAI-gpt-3.5-turbo",
            "function_name": "remote",
            "description": "test model"
          }
        }
      ],
      "edges": [
        {
          "source": "workflow_step_1",
          "dest": "workflow_step_2"
        }
      ]
    }
  }
}

Closed by #273


redirect to your repo

Hi!
In short...
Is alright to redirect people to you repo from mine?
I'd like to archive the github-pullrequest-resource in favor of yours. As it used the GraphQL, which solves a lot of issues.
We are fully feature complete, but I recognize that my resource started trying to do too much.
I'd also request that we update the concourse docs to reference your implementation rather than mine.
Cheers,
JT

No problem at all, we are just happy to contribute what we can back to the Concourse community 🙌
Given that this resource is not a drop-in replacement for github-pullrequest-resource (e.g. parameters differ), perhaps we should provide a migration document to ease the transition?

I fully support this too. Its one of the main reasons I haven't really added in new features to the github-pullrequest-resource or taken the time to make the necessary tweaks to that resources CI and honestly even have started using this resource more. Using GraphQL is the better way to go.
FWIW, a few colleagues and I at my office have talked about the problems that the original PR resource has, and what to do about them. I have some learnings (of personal growth on this) that it's hard to become the core maintainer of a project on its way to archival, because I didn't fully understand some of the decisions that JT made early on.
Bottom line, I agree with JT on this. @jtarchie if you want me to, I can make the necessary changes on the original resource with deprecation warnings, etc.

@crstamps2, make it happen! Happy to help in any way I can, too.
There are no worries/concerns about ego, emotional attachment, etc. Our resource solved a problem at one point, but it no longer solves that issue effectively.
Better things are better. 👍 If something solves a problem better, use that thing.
🎉

Sorry, I forgot to update this link.
Once he merge of the docs happened on concourse-ci.org, we waited a month, and then closed down the resource.


Timestamps count differ from datapoints count.

Hi,
Using version 1.1.0-dev I encounter an issue in a call to the aggregate function, and a successive call to summarize(in this case is then _summarizeValues).
The test case involve two TimeSeries, for instance:
(a) 'start':<PHONE_NUMBER>, 'end':<PHONE_NUMBER>, 'valuesPerPoint': 1, 'step': 120
(b) 'start':<PHONE_NUMBER>, 'end':<PHONE_NUMBER>, 'valuesPerPoint': 1, 'step': 30
In aggregate, before the call to normalize, the number of datapoints(i.e. len(list(series))) ) for the series is:
(a) 31
(b) 120
After the call to normalize, the datapoint count for the series is now:
(a) 31 (valuesPerPoint=1)
(b) 30 (valuesPerPoint=4)
and the (start, end, step) output from normalize is:<PHONE_NUMBER>,<PHONE_NUMBER>, 120)
At this point, the len(values) generated by the aggregate function is 30.
Considering the way that is used in _summarizeValues to calculate timestamps and datapoints, i.e.:
  timestamps = range( int(series.start), int(series.end), int(series.step) )
  datapoints = list(series)

The TimeSeries output of aggregate has:
len(timestamps) = 31
len(datapoints) = 30

And eventually, when trying to access  in _summarizeValues the 31st element in datapoints is leading to:
  File "/opt/graphite/webapp/graphite/render/functions.py", line 3998, in _summarizeValues
    if timestamps[i] >= timestamp_ and datapoints[i] is not None:
IndexError: list index out of range

The exception has the effect to have the WSGI thread to spin and allocate increasing amount of memory, until is killed.
I run the same test case on version 0.9.12, and what I get is that the datapoints count after the normalize is for both series as 31, so no exception triggered in this case.
Can you pinpoint the culprit? My guess is normalize.
Thanks

That is interesting, I'll have to see if anything has changed in normalize between the versions.  Not sure what would be causing the memory allocation, possibly the backtrace.

Just to clarify, my guess it that normalize should output a (start, end, step) range that guarantee same amount of timestamps and datapoints between the series involved.
And I guess instead that in version 0.9.12 there was a bug with the __consolidatingGenerator in TimeSeries, that was returning an extra None.
I think, probably not correctly, that normalize should actually produce in output series that are aligned in terms of timestamp; if can somebody provide some documentation or a comment about the expected behaviour for normalize would be great.

Good point, it does seem like that trailing None may have been there to avoid this kind of issue by providing a bogus value if you iterated past the end in a scenario like this.  I'm digging deeper to try and figure out a reasonable solution.

@xtus can you try out that PR and verify that it fixes the issue?

@DanCech yep, my quick fix was indeed the numPoints = min(len(timestamps), len(datapoints)) in _summarizeValues.
PR #2114 fix the issue.
Thanks


Specific Time does not work

(Martin Leppen - Mendix Community Slack)

Added this to the marketplace release v1.1.0


Possible to cause segmentation fault with a popup window and win_splitmove()

Describe the bug
Calling win_splitmove(popup_winid, other_winid) where the first argument is a popup window's window id causes a segmentation fault.
To Reproduce

Do vim --clean
Do :vs
Do :let popup_winid = popup_dialog('hello', {})
Do :call win_splitmove(popup_winid, 1001)
See a segmentation fault

Oddly, skipping step two and replacing step four's 1001 with 1000 does not cause a seg fault, but does cause bad behavior.
Expected behavior
The function fails and an error is thrown.
Screenshots
None unless requested.
Environment

Vim version 8.2 Included patches: 1-416
OS: Ubuntu 18.04
Terminal: Alacritty 0.4.1

I can reproduce the crash (vim-8.2.0416 huge), but I had to change step 3 into:
:let popup_winid = popup_dialog('hello', {})

And valgrind --num-callers=50 --track-origins=yes ./vim --clean 2> log  reports:
==5333== Memcheck, a memory error detector
==5333== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5333== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==5333== Command: ./vim --clean
==5333==
==5333== Invalid read of size 8
==5333==    at 0x3214FF: frame2win (window.c:3018)
==5333==    by 0x3214FF: winframe_remove (window.c:2806)
==5333==    by 0x1A65AE: win_move_into_split (evalwindow.c:773)
==5333==    by 0x1A65AE: f_win_splitmove (evalwindow.c:839)
==5333==    by 0x19DAB7: call_internal_func (evalfunc.c:1104)
==5333==    by 0x307B26: call_func (userfunc.c:1863)
==5333==    by 0x307DC2: get_func_tv (userfunc.c:557)
==5333==    by 0x30B13F: ex_call (userfunc.c:3545)
==5333==    by 0x1BEF74: do_one_cmd (ex_docmd.c:2509)
==5333==    by 0x1BEF74: do_cmdline (ex_docmd.c:978)
==5333==    by 0x2339A6: nv_colon (normal.c:3323)
==5333==    by 0x2393AE: normal_cmd (normal.c:1071)
==5333==    by 0x370FDE: main_loop (main.c:1515)
==5333==    by 0x372720: vim_main2 (main.c:905)
==5333==    by 0x149388: main (main.c:444)
==5333==  Address 0x38 is not stack'd, malloc'd or (recently) free'd
==5333==
==5333==
==5333== Process terminating with default action of signal 11 (SIGSEGV)
==5333==    at 0x8DAE187: kill (syscall-template.S:78)
==5333==    by 0x2575E2: may_core_dump (os_unix.c:3339)
==5333==    by 0x2575E2: mch_exit (os_unix.c:3336)
==5333==    by 0x3714FD: getout (main.c:1712)
==5333==    by 0x8B6288F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==5333==    by 0x3214FE: winframe_remove (window.c:2805)
==5333==    by 0x1A65AE: win_move_into_split (evalwindow.c:773)
==5333==    by 0x1A65AE: f_win_splitmove (evalwindow.c:839)
==5333==    by 0x19DAB7: call_internal_func (evalfunc.c:1104)
==5333==    by 0x307B26: call_func (userfunc.c:1863)
==5333==    by 0x307DC2: get_func_tv (userfunc.c:557)
==5333==    by 0x30B13F: ex_call (userfunc.c:3545)
==5333==    by 0x1BEF74: do_one_cmd (ex_docmd.c:2509)
==5333==    by 0x1BEF74: do_cmdline (ex_docmd.c:978)
==5333==    by 0x2339A6: nv_colon (normal.c:3323)
==5333==    by 0x2393AE: normal_cmd (normal.c:1071)
==5333==    by 0x370FDE: main_loop (main.c:1515)
==5333==    by 0x372720: vim_main2 (main.c:905)
==5333==    by 0x149388: main (main.c:444)

And without step 2 and with1000 in step 4 i.e.
:let popup_winid = popup_dialog('hello', {})
:call win_splitmove(popup_winid, 1000)

... there is no crash but valgrind reports:
==5455== Memcheck, a memory error detector
==5455== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5455== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==5455== Command: ./vim --clean
==5455==
==5455== Conditional jump or move depends on uninitialised value(s)
==5455==    at 0x325AFA: win_split_ins (window.c:1291)
==5455==    by 0x1A65D4: win_move_into_split (evalwindow.c:779)
==5455==    by 0x1A65D4: f_win_splitmove (evalwindow.c:839)
==5455==    by 0x19DAB7: call_internal_func (evalfunc.c:1104)
==5455==    by 0x307B26: call_func (userfunc.c:1863)
==5455==    by 0x307DC2: get_func_tv (userfunc.c:557)
==5455==    by 0x30B13F: ex_call (userfunc.c:3545)
==5455==    by 0x1BEF74: do_one_cmd (ex_docmd.c:2509)
==5455==    by 0x1BEF74: do_cmdline (ex_docmd.c:978)
==5455==    by 0x2339A6: nv_colon (normal.c:3323)
==5455==    by 0x2393AE: normal_cmd (normal.c:1071)
==5455==    by 0x370FDE: main_loop (main.c:1515)
==5455==    by 0x372720: vim_main2 (main.c:905)
==5455==    by 0x149388: main (main.c:444)
==5455==  Uninitialised value was created by a stack allocation
==5455==    at 0x1A63B0: f_win_splitmove (evalwindow.c:804)

Whoops thanks. Fixed step 3.


External API usage

Hi @jdejaegh,
Thanks for this project, it has been made by reverse engineering the mobile app right ?
I would like to know if it's possible to implement that API in other FOSS weather apps.
If so, how could I inform the devs, any API usage docs outside Home Assistant ?
Describe the solution you'd like
Some documentation on how to use the API to add weather data on other weather apps (like Breezy Weather or FluentWeather).

Hi,

Thanks for this project, it has been made by reverse engineering the mobile app right ?

Exactly!
I could indeed describe the API in more details on a wiki page.

Great, thanks for this project.
I suppose there is no official API for IRM/KMI right ? Or maybe it's paid. I don't see any API docs on their website either. Only a link to download data chunks via Open Data.

I did not find any API documentation either. That's why I ended up reverse engineering the Android application.
The open data contains raw measures and outputs from their models, it is not really usable unless you are a meteorologist... Interesting datasets (forecast by municipalities and similar) are not public. That's what I found last time I checked.

Yeah, I came to the same conclusion. I'll try contacting them after the holidays maybe they're working on it or will allow API access for FOSS non-profit projects.
Do you think your reverse engineered API is stable and will be future proof or can it break at any time and will need to be re-engineered if they change something on the app/server side ?

I made this integration such that it uses github.com/jdejaegh/irm-kmi-ha as User-Agent header so they can see that not only their app is using the API endpoint.  I don't know if they monitor that.
Regarding stability, I can only tell from observation: the integration has been there since one year, and there have been no breaking changes since then.  If they add fields to the JSON responses in the future, it should not break the integration.  If they modify or remove fields, it will break for sure.
At the moment, I don't have tests to verify that their API is still returning consistent values.  All the tests assume that the responses fall within the range of responses I observed in the past.

A first version is available in the wiki: https://github.com/jdejaegh/irm-kmi-ha/wiki/API-documentation
It is not yet complete but already provides an overview of how the API works.  I plan to describe each method when I have time.  The biggest is getForecasts as it returns the full weather data.
I'll close this issue once the page is done.


Refactor owner and name into project property

To less clutter all properties, collapse owner and name into project.

Reviewed in real life. Looks good!


minZoom level for map?

This is a question about zoom levels on the map.  I know how to set the minzoom level on an open layers map by passing in minZoom and maxZoom to the view but its not immediatly obvious to me how to set it with boundless sdk.  I tried using the updateView and passing it in that way, as it is done in one of the examples, but it doesn't seem to stop the map from being able to zoom out.  Basically what it happening, when i zoom out, the map zooms so far out that the map gets really small and only takes up about 1/2 the webpage, and the world is shown three times.
Is there a way to stop the zoom out from happening past a certain zoom level?
Thanks!

Does this still work in 2.3.3?  I'm setting the metadata when the map component mounts, and verifying it's in the redux store, but it doesn't affect the overall map zoom level constraints.
   this.props.updateMetadata({       'bnd:minzoom': 4,       'bnd:maxzoom': 18     });
Notice in image below how the map zoom level is 0 even though metadata is set for 4 to be the minzoom.

calling updateMetadata in componentWillMount instead of componentDidMount seems to fix my problem.

Right since this is the React lifecycle, and we configure the map here:
  componentDidMount() {
    // put the map into the DOM
    this.configureMap();
  }

that makes sense. You can also use the constructor.

Yes, but what I'm pointing out is that calling updateMetadata to set map zoom constraints has no effect if done in componentDidMount.  It sets the redux store but has no effect on the actual zoom levels.  It only works in constructor or componentWillMount.
All my other map actions like setView, addLayer etc work in componentDidMount like you mention.

it's because we only set minZoom maxZoom on the view etc. when it's created https://github.com/boundlessgeo/sdk/blob/master/src/components/map.js#L1457
There is no code to dynamically change the view if someone dispatches that metadata change after the map has been created

that code could be added though theoretically

Thanks.  It's not an issue.  I was really just pointing this out in case other people experienced the same behavior and wondered what was happening.  As always, this project is great.


Rectified spelling mistake in README.md file

Close #383

Good catch. Thanks for reporting the issue + fixing it 👍🏻

Always a pleasure, Kevin !! :)

Hi Kevin, there are 7 workflows which needs maintainer's approval to merge the pull request successfully. Do let me know if I need to do anything from my end.

Hi Kevin, there are 7 workflows which needs maintainer's approval to merge the pull request successfully. Do let me know if I need to do anything from my end.

Good catch. I missed clicking "approve and run" on the pipeline. This should auto merge now.

Hi Kevin, there are 7 workflows which needs maintainer's approval to merge the pull request successfully. Do let me know if I need to do anything from my end.

Good catch. I missed clicking "approve and run" on the pipeline. This should auto merge now.

Thank you so much !!

Thank you for your contribution to the Kaskada open source project. We appreciate your effort in finding the problem and providing a fix, however we cannot accept outside contributions at this time due to the absence of an Individual Contributor License Agreement (ICLA) for the project. Therefore we will have to close the PR.
We expect to have an ICLA available soon, and we look forward to collaborating with you in the future.

Thank you for your contribution to the Kaskada open source project. We appreciate your effort in finding the problem and providing a fix, however we cannot accept outside contributions at this time due to the absence of an Individual Contributor License Agreement (ICLA) for the project. Therefore we will have to close the PR.
We expect to have an ICLA available soon, and we look forward to collaborating with you in the future.

Thank you for letting me know, Eric. Have a good day !!


Live preview freezes after stream starts

Describe the bug
Video starts fine then freezes after about 15 seconds
rtmpCamera1 = new RtmpCamera1(lightOpenGlView, MainActivity.this);
To Reproduce
Steps to reproduce the behavior:

Use 2.2.7

Expected behavior
Normal video streaming
Additional context
If I use 2.2.6 it works fine

Hello,
I fixed it here:
https://github.com/pedroSG94/RootEncoder/commit/96c69c05e4be90678703c90841b0abd8e2270544
You can use this gradle to test:
implementation 'com.github.pedroSG94.RootEncoder:library:96c69c05e4'

Let me know if it is working for you

Tested again on 2.2.8 and it works perfect, thanks @pedroSG94


stats error

function updated_stats in DaisyXMusic/modules/play.py returns object None/
problem in if condition.
if condition is False,
chat_id in callsmusic.pytgcalls.active_calls >> False
i can't fix it/

Can you send me logs of what u face error

Can you send me logs of what u face error

File "/app/DaisyXMusic/main.py", line 22, in
2021-08-24T19:45:46.645319+00:00 app[worker.1]:     from DaisyXMusic.services.callsmusic import run
2021-08-24T19:45:46.645333+00:00 app[worker.1]:   File "/app/DaisyXMusic/services/callsmusic/init.py", line 2, in
2021-08-24T19:45:46.646037+00:00 app[worker.1]:     from DaisyXMusic.services.callsmusic.callsmusic import pytgcalls, run
2021-08-24T19:45:46.646063+00:00 app[worker.1]:   File "/app/DaisyXMusic/services/callsmusic/callsmusic.py", line 38, in
2021-08-24T19:45:46.646283+00:00 app[worker.1]:     run = pytgcalls.run
2021-08-24T19:45:46.646311+00:00 app[worker.1]: AttributeError: 'PyTgCalls' object has no attribute 'run'
2021-08-24T19:45:46.876236+00:00 heroku[worker.1]: Process exited with status 1
2021-08-24T19:45:46.953759+00:00 heroku[worker.1]: State changed from up to crashed

why not try this method? :
client = Client(config.SESSION_NAME, config.API_ID, config.API_HASH)
run = client.run

Can you send me logs of what u face error

* File "/app/DaisyXMusic/**main**.py", line 22, in
  2021-08-24T19:45:46.645319+00:00 app[worker.1]:     from DaisyXMusic.services.callsmusic import run
  2021-08-24T19:45:46.645333+00:00 app[worker.1]:   File "/app/DaisyXMusic/services/callsmusic/**init**.py", line 2, in
  2021-08-24T19:45:46.646037+00:00 app[worker.1]:     from DaisyXMusic.services.callsmusic.callsmusic import pytgcalls, run
  2021-08-24T19:45:46.646063+00:00 app[worker.1]:   File "/app/DaisyXMusic/services/callsmusic/callsmusic.py", line 38, in
  2021-08-24T19:45:46.646283+00:00 app[worker.1]:     run = pytgcalls.run
  2021-08-24T19:45:46.646311+00:00 app[worker.1]: AttributeError: 'PyTgCalls' object has no attribute 'run'
  2021-08-24T19:45:46.876236+00:00 heroku[worker.1]: Process exited with status 1
  2021-08-24T19:45:46.953759+00:00 heroku[worker.1]: State changed from up to crashed

Merge pull request from latest source code

why not try this method? :
client = Client(config.SESSION_NAME, config.API_ID, config.API_HASH)
run = client.run

pytgcalls = PyTgCalls(client)
this will start client through pytgcalls
so no need for this

try marshal lib branch there some bugs in PyTgCalls Lib


Store user data

I am trying to store some user data for a bot but I cannot find the right way. I used a .txt file and this method works but when I upload the project all the users that will use the bot, will share the same file and I don't want to do that. I want to store some settings for every different user that will use the bot and keep these settings for ever.
I tried Stateclient and GetUserData but the stored values are disappearing. I am doing something wrong ?
How can I implement this?

If you still have questions, please open a new issue, and specify if you are using .NET or Node SDK, on BotBuilder repo here: https://github.com/Microsoft/BotBuilder


RELOAD-MODULES-SMP - remove hv_utils from MODULES_NOT_TO_RELOAD.

Confirmed with Dexuan, that hv_utils can be removed, I found the system will reload it automatically if we remove it from code by modprobe -r hv_utils
[ 1935.697905] hv_vmbus: unregistering driver hv_util
[ 1988.440335] pps_core: LinuxPPS API ver. 1 registered
[ 1988.446042] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti<EMAIL_ADDRESS>[ 1988.458421] PTP clock support registered
[ 1988.466500] hv_utils: Registering HyperV Utility Driver
[ 1988.471033] hv_vmbus: registering driver hv_util
[ 1988.476275] hv_utils: Heartbeat IC version 3.0
[ 1988.481875] hv_utils: Shutdown IC version 3.0
[ 1988.487179] hv_utils: TimeSync IC version 4.0
[ 1988.492441] hv_utils: VSS IC version 5.0

Before fix -
[LISAv2 Test Results Summary]
Test Run On           : 06/22/2019 02:00:03
ARM Image Under Test  : RedHat : RHEL : 7-RAW : 7.6.2019062020
    5 CORE                 RELOAD-MODULES-SMP                                                                FAIL                 1.54

After fix -
[LISAv2 Test Results Summary]
Test Run On           : 06/24/2019 02:57:30
ARM Image Under Test  : RedHat : RHEL : 7-RAW : 7.6.2019062020
Total Test Cases      : 1 (1 Passed, 0 Failed, 0 Aborted, 0 Skipped)
Total Time (dd:hh:mm) : 0:0:12

   ID TestArea             TestCaseName                                                                TestResult TestDuration(in minutes)
-------------------------------------------------------------------------------------------------------------------------------------------
    1 CORE                 RELOAD-MODULES-SMP                                                                PASS                 6.44

SRIOV-INTERRUPTS-CHANGE Run-LinuxCmd will timeout in 5 mins, extend it to 10 mins in case SRIOV-INTERRUPTS-CHANGE
By default,
[LISAv2 Test Results Summary]
Test Run On           : 06/24/2019 05:27:42
ARM Image Under Test  : RedHat : RHEL : 7-RAW : 7.6.2019062020
Total Test Cases      : 1 (1 Passed, 0 Failed, 0 Aborted, 0 Skipped)
Total Time (dd:hh:mm) : 0:0:36

   ID TestArea             TestCaseName                                                                TestResult TestDuration(in minutes)
-------------------------------------------------------------------------------------------------------------------------------------------
    1 SRIOV                SRIOV-INTERRUPTS-CHANGE                                                           PASS                30.02

reloading hv_utils depends on the distro/kernel. We have seen places where it cannot be unloaded.
Let's remove it from the reload entirely?

In test case, it expected it can't be removed, if it is removed, test case failed.
I confirmed it with Dexuan, he said it can be removed, any suggestion?

In test case, it expected it can't be removed, if it is removed, test case failed.
I confirmed it with Dexuan, he said it can be removed, any suggestion?

Ok, let's merge this and be on a look-out for failures.
We can them all discuss internally.


Branch view lists branches twice (sometimes)

Component
server
Describe the bug
I don't even know how to describe this bug properly 😅 but the screen-recoding should help:
branches.webm
System Info
{"source":"https://github.com/woodpecker-ci/woodpecker","version":"next-6de5922408"}

Additional context
No response
Validations

[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
[X] Check that this is a concrete bug. For Q&A join our Discord Chat Server or the Matrix room.

Not only affects the default branch:

When using the same version on a local dev setup I'm not able to reproduce it :thinking: but both of my other instances (one for Gitea one for GitHub) show the same behavior described above. Any idea on this?

Sure, that's how it looks like:

But it looks the same in case where only the correct branches are listed.

The responses of the page=1 requests are also the same for both cases, ["docs","main"].

How? As I'm not able to reproduce it in a local dev stack, I would have to add console logging to the frontend and deploy it?

Ok will try to find some time to do so.

On the other side, the first page is queried 3 times in the screenshot you posted. Is this issue new?

Cant say for sure.


networkInterface return an object rather than string for GraphQLRequest.query

As https://github.com/apollostack/apollo-client/issues/379 ,
The query receive from ApolloClient is mismatching the second argument of graphql( ) , because query is now an Object {kind: "Document", definitions: Array[1]} .
But as document read query is just a string.
I tried to remove addQueryMerging( ) and
queryTransformer: addTypename,
shouldBatch: true,

from new ApolloClient({ })
but query still being an object.

https://github.com/apollostack/apollo-client/blob/a92631da86b2ae493625973447a02b1204a3059f/src/networkInterface.ts#L35
interface Request {
  debugName?: string;
  query?: Document;  // this mismatch with graphql( ) from graphql package @stubailo
  variables?: Object;
  operationName?: string;
  [additionalKey: string]: any;
}

Well, I think printRequest is of good use, but it's not exported properly.

import { print } from 'graphql/language/printer';
print(request.query)


Can't refresh Clippy's speech balloon

Error:
Error loading questions in staticAIData from JSON: Could not find file 'C:\Windows\system32\app\staticAIData.json'.

I had already written it [here(https://github.com/builtbybel/Winpilot/issues/184). You might want to consider downloading the app again and unpacking everything onto the desktop to check if the said JSON file is present in the app directory.

Fixed in 3.5.0.


Can not open any folder

Type: Bug
i can't open any folder in my vs code. I tried a lot of troubleshooting but still its not working.
 Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Host routes break connectivity to far gateways after upgrading from 23.7.3 to 23.7.6

Describe the bug
After upgrading my secondary firewall host routes to far gateways got added:
before:
root@gate2:~ # netstat -rn | grep ^172.23.43
<IP_ADDRESS>/24     <IP_ADDRESS>       UGS        ixl0
<IP_ADDRESS>/29    link#3             U          ixl0
<IP_ADDRESS>       link#3             UHS         lo0

after:
root@gate2:~ # netstat -rn | grep ^172.23.43
<IP_ADDRESS>/24     <IP_ADDRESS>       UGS        ixl0
<IP_ADDRESS>        link#3             UHS        ixl0
<IP_ADDRESS>        link#3             UHS        ixl0
<IP_ADDRESS>       link#3             UHS        ixl0
<IP_ADDRESS>/29    link#3             U          ixl0
<IP_ADDRESS>       link#3             UHS         lo0
<IP_ADDRESS>       link#3             UHS        ixl0

Since <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS> are far gateways, they cant be reached anymore because the host tries to reach them directly on the interface ilx0 and not via the gateway (<IP_ADDRESS>) configured for <IP_ADDRESS>/24.
I used opnsense-revert to go back to version 23.7.3 and the host routes disappeared again.
Expected behavior
The host should use the configured gateway (<IP_ADDRESS>) for <IP_ADDRESS>/24 to connect to the far gateways.
No host routes should be added for far gateways.
Describe alternatives you considered
I entered "Monitor IP" with ips behind the far gateway, which gets the gateway online again.
However the far gateway itself remains unreachable.
Environment
Software version used and hardware type:
Manufacturer: Supermicro
Product Name: X11SRM-F
Intel(R) Xeon(R) W-2245 CPU @ 3.90GHz (8 cores, 16 threads)
32G Ram
OPNsense 23.7.6-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1w 11 Sep 2023

The far gateway settings pins the gateway to the interface and this is now consistent. Before it would only do it when a default route was added (probably those gateways are not marked default). But this is exactly what it's supposed to do.
A far gateway is not a far gateway if you have a route for it...
Cheers,
Franco

Hi Franco,
thanks for the quick reply and yes the gateways are not marked default.
However if I try to uncheck "Far Gateway" i cannot save the gateway anymore:
The following input errors were detected:

The gateway address "<IP_ADDRESS>" does not lie within one of the chosen interface's IPv4 subnets.

Why can’t you add a VIP to the interface in the target range? Then it works.

Hi Franco,
I think that will not work in my setup. I realized that I added the four remote gateways only for monitoring the performance of the private WAN connecting them. All routing to them is done by <IP_ADDRESS>.
I will remove them now and will setup telegraf to collect the data.
Thanks again for your quick replies!
Cheers,
André

Hi André,
ok, sounds like a plan. Close this issue?
Cheers,
Franco

Hi Franco,
yes please, and thank you for your support!
Cheers,
André


No package.json?

Hi,
Missing package.json? :
npm WARN saveError ENOENT: no such file or directory, open '...\yakyak-1.5.1-win32-x64\yakyak-win32-x64\package.json'
npm WARN enoent ENOENT: no such file or directory, open '...\yakyak-1.5.1-win32-x64\yakyak-win32-x64\package.json'
npm WARN yakyak-win32-x64 No description
npm WARN yakyak-win32-x64 No repository field.
npm WARN yakyak-win32-x64 No README data
npm WARN yakyak-win32-x64 No license field.
YakYak version: latest.
Node version: 10.10.0
OS Version: Windows 10 Pro
NPM Version: 6.4.1
Best regards.

Anybody there?

are you running from source? as in npm start ?
or just the release tarball?


Allow entry submission via issue template

Idea: allow submission of entries via GitHub Issue template
Pros:

low entry barrier for data submission
infrastructure exists

Cons:

Would need a separate parser to read markdown
Data submission could be overly complicated (list of reactions)
May not be widely used

Dismissed, too complicated to implement


Peer to peer code review 18/10/2022

Great work @kennyegun24 , your work is great and easy to read.

Hello @kennyegun24, create work implementing this project
Your codes are DRY and you follow the best code practices


Fix eth_getLogs call

@pgebal thank you! Can you bump version and add your changes to Changelog.md?

Sure, I'll do it this weekend.


[Enhancement] Preventing highchart brand link to open within webview.

I have added navigationDelegate property to webview which will be preventing any link to be opened within webview container and will use url_launcher to prompt user to that particular url from device browser.
Changed Code Preview
// lib/src/mobile/high_chart.dart
...
navigationDelegate: (NavigationRequest request) async {
    if (await canLaunch(request.url)) {
        launch(request.url);
    }

    return NavigationDecision.prevent;
},
...

Thank you @ayyshim


Revert "Update MeAutherizedAppsScopeTest.java testcases"

This reverts commit 3f710a27f527bb6b087d1ced95d92637bc6233eb.

Closing since the updated test cases passed successfully.