gretl: 2021a -> 2021b

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gretl/versions.
meta.description for gretl is: "A software package for econometric analysis"
meta.homepage for gretl is: "http://gretl.sourceforge.net"
meta.changelog for gretl is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b/bin/gretlcli passed the binary check.

/nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b/bin/gretl_x11 passed the binary check.

/nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b/bin/gretl passed the binary check.

3 of 3 passed binary check by having a zero exit code.

2 of 3 passed binary check by having the new version present in output.

found 2021b with grep in /nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b

found 2021b in filename of file in /nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b

directory tree listing: https://gist.github.com/96b7ad711470dee86e649d080fdd9ad1

du listing: https://gist.github.com/ec00bbff8ec2fa3dbe3e4986ba7eefe0

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gretl

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b
ls -la /nix/store/85qva7ljvr1s5v6m1ma8mzm244rf6ivm-gretl-2021b/bin

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

1 package built:

gretl

Maintainer pings
cc @dmrauh for testing.

Result of nixpkgs-review pr 121801 at 78f1435a run on x86_64-linux 1

1 package built successfully:

gretl

1 suggestion:

warning: unclear-gpl
gpl3 is a deprecated license, please check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/applications/science/math/gretl/default.nix:39:5:
   |
39 |     license = licenses.gpl3;
   |     ^


Not all profiles work in the plugin

Check and verify that all profiles still work.

[ ] Check with @pietervdvn why the API is broken and both car.fast and car.fastest don't work anymore.

 Publish Impact QGIS plugin

 Publish Impact QGIS plugin


Unit Test: Ensure updateCMSFields() can only be called once per instance.

Unit Test: Ensure updateCMSFields() can only be called once per instance.

Not sure what I meant with this.


Error and problems

Keep getting this error after it decrypts the apps and it won't decrypt any media files. Password is correct. any help would be greatly appreciated.
ERROR:root:crypto_init: type_attch should be 3!
CRITICAL:root:decryption key is not good...
UPDATE:
I solved that problem but now getting error WARNING:root:UNK file not handled: VID-20190906-WA0012.mp4.enc
It decrypts everything except for image, video and sound files. Which is what I want to decrpyt mainly.

Hi @WelshKev1
could you please provide the KoBackupApp version used, and the modality (otg, hisuite)?
It should be nice to have a very small subset (non sensitive info) of the data you're trying to decrypt to check what it's going left: you could share by email it.

It was the latest version of hisuite. I will email a couple of files and
the password after work. Thank you for your time.
On Wed, 13 Nov 2019, 13:26 Francesco Picasso<EMAIL_ADDRESS>wrote:

Hi @WelshKev1 https://github.com/WelshKev1
could you please provide the KoBackupApp version used, and the modality
(otg, hisuite)?
It should be nice to have a very small subset (non sensitive info) of the
data you're trying to decrypt to check what it's going left: you could
share by email it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RealityNet/kobackupdec/issues/3?email_source=notifications&email_token=ANXXMIA3GP5XOBL376STKZLQTP6AXA5CNFSM4JLYSGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED6EIDI#issuecomment-553403405,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANXXMIEKBFZ4T2M3CUT2IX3QTP6AXANCNFSM4JLYSGGA
.

Awesome. Please remember to include xml files (eg: info.xml, document.xml) and any file you could get in the root of BACKUP\media\

Here are the files that I can find within the folder that might be of help.
I've also included one image file. The password for the backup is Contbach1
On Wed, Nov 13, 2019 at 2:31 PM Francesco Picasso<EMAIL_ADDRESS>wrote:

Awesome. Please remember to include xml files (eg: info.xml, document.xml)
and any file you could get in the root of BACKUP\media\
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RealityNet/kobackupdec/issues/3?email_source=notifications&email_token=ANXXMICTK6NB7ZBBXSZL73TQTQFT5A5CNFSM4JLYSGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED6KOWI#issuecomment-553428825,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANXXMIBGT3VGPQ5X4A436SLQTQFT5ANCNFSM4JLYSGGA
.

I met the same problem, with the latest version of Hisuite.

Not much I can do is there. Huawei are no help at all! Giving simple
instructiona like restart your computer, re install hisuite. Hit a brick
wall.
Thank you anyway
On Fri, 22 Nov 2019, 12:47 Fei Wen<EMAIL_ADDRESS>wrote:

I met the same problem, with the latest version of Hisuite.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RealityNet/kobackupdec/issues/3?email_source=notifications&email_token=ANXXMIB6ZBV5HBPQXEL4TVLQU7IGNA5CNFSM4JLYSGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE5RBLI#issuecomment-557519021,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANXXMIBGXK6ZWSR6NUN5SK3QU7IGNANCNFSM4JLYSGGA
.

Hi @WelshKev1
I didn't see any file...
Anyway I see that Huawei changed a bit how media are handled. No more .enc extension and a sqlite db in the root of the media folder... I have a sample to work with, so let's see if it's the same issue.

I have sample files, if you need samples please let me know.
On Mon, Nov 25, 2019 at 7:00 AM Francesco Picasso<EMAIL_ADDRESS>wrote:

Hi @WelshKev1 https://github.com/WelshKev1
I didn't see any file...
Anyway I see that Huawei changed a bit how media are handled. No more
.enc extension and a sqlite db in the root of the media folder... I
have a sample to work with, so let's see if it's the same issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RealityNet/kobackupdec/issues/3?email_source=notifications&email_token=AAJPRBGPW4SCXXRHZQY6HK3QVMBR3A5CNFSM4JLYSGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAXG7A#issuecomment-557937532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJPRBCZRJSPAHHHCTBNH43QVMBR3ANCNFSM4JLYSGGA
.

--
Best regards,
Fei Wen
Tel: (+1)<PHONE_NUMBER>

Keep getting this error after it decrypts the apps and it won't decrypt any media files. Password is correct. any help would be greatly appreciated.
ERROR:root:crypto_init: type_attch should be 3!
CRITICAL:root:decryption key is not good...
UPDATE:
I solved that problem but now getting error WARNING:root:UNK file not handled: VID-20190906-WA0012.mp4.enc
It decrypts everything except for image, video and sound files. Which is what I want to decrpyt mainly.

How did you solved this problem? because i am facing similar prob.

Yep I guess I know how to solve that issues, but I need to change a bit the script "design". Hope to do it soon... stay tuned.

@feistar @WelshKev1
could you please try the latest version?
I'm actually missing some samples so, in case of issues, I'd ask you to share with me a subset of the samples, thanks.

Currently on vacation. As soon as I'm home next week I will let you know
On Tue, 7 Jan 2020, 19:19 Francesco Picasso<EMAIL_ADDRESS>wrote:

@feistar https://github.com/feistar @WelshKev1
https://github.com/WelshKev1
could you please try the latest version?
I'm actually missing some samples so, in case of issues, I'd ask you to
share with me a subset of the samples, thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RealityNet/kobackupdec/issues/3?email_source=notifications&email_token=ANXXMIEAEVQ645ULK6JJHETQ4TIULA5CNFSM4JLYSGGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIJ6ZRA#issuecomment-571731140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANXXMIHPG3LI24YZ76LENBDQ4TIULANCNFSM4JLYSGGA
.

thanks @WelshKev1

I've tried but got this one.
I am using pycryptodome
Traceback (most recent call last):
File "kobackupdec.py", line 917, in
main(user_password, backup_path, dest_path)
File "kobackupdec.py", line 862, in main
decrypt_backup(password, files_folder, dest_path_out)
File "kobackupdec.py", line 790, in decrypt_backup
decrypt_info = parse_info_xml(path_in.joinpath('info.xml'), password)
File "kobackupdec.py", line 576, in parse_info_xml
dec_info.decryptor = decryptor
File "kobackupdec.py", line 395, in decryptor
new_decryptor.crypto_init()
File "kobackupdec.py", line 256, in crypto_init
self.__decrypt_bkey_v4()
File "kobackupdec.py", line 240, in __decrypt_bkey_v4
cipher = AES.new(key, mode=AES.MODE_GCM, nonce=nonce)
AttributeError: module 'Crypto.Cipher.AES' has no attribute 'MODE_GCM'

same issue, It decrypts everything except for image, video and sound files

This is weird @etimaudet...  Could you create a test backup so I can check what's going left?
@WelshKev1 sorry but I did not get the files!
You could reach me at dfirfpi at gmail. Ping me here if you're able and willingly to send such tests. I will shred them when done, just do not send to me personal / illecit data :)

Closing since no more input / news


Connecting to OpenAI

I was wondering where should I change the settings apart from adding the key in environment variables to connect to the OpenAI instead of HeyGen API
In the initialMessages parameter, you can replace the content of the 'system' message with whatever 'knowledge base' or context that you would like the GPT-4o model to reply to the user's input with.

we have taken a valid subscription form haygen, still are unable to receive any support from you people, we have tried through multiple channels , still no proper response!

There is no proper documentation on creating new knowledge bases also, this is preventing us from using heygen API for other uses even after taking subscription, please help !!!!


Chunked transfer encoding

Hi,
I use an express middleware that set to chunked the transfer-encoding headers
'transfer-encoding': 'chunked'

In that case, I get the following error :

The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.

To make my request works, in the forwardResponseToApiGateway function of the aws-serverless-express/index.js file I remove this header.
Do you think you could make chunked transfert encoding pass ?

Chunked transfer is something we are looking into; unfortunately, for now
you will need to disable it.
On Wed, 19 Oct 2016, 07:25 Anthony Denneulin<EMAIL_ADDRESS>wrote:

Hi,
I use an express middleware that set to chunked the transfer-encoding
headers
'transfer-encoding': 'chunked'
In that case, I get the following error :
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either
the attempt failed or the origin closed the connection.
To make my request works, in the forwardResponseToApiGateway function of
the aws-serverless-express/index.js file I remove this header.
Do you think you could make chunked transfert encoding pass ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/aws-serverless-express/issues/10, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABy6l2mkJhh8RIJXLdgJxYJNydLZImRBks5q1ihQgaJpZM4KbCVz
.

That's rally annoying but thanks for your answer ;)

Why is this closed? Is it solved?

This is a limitation with API Gateway, and not the library. However, I will reopen this issue for tracking and notification purposes.

Thanks brettstack.
for those seeking a temporary solution mentioned by @denneulin above. Add 'delete headers' as below in the forwardResponseToApiGateway function.
delete headers["transfer-encoding"]
const successResponse = {statusCode, body, headers}

This should be working now. You don't need to explicitly remove the  'transfer-encoding' header anymore.

@abhigna I think the transfer-encoding: chunked issue still exists. I've tried to use aws-serverless-express with graphql-server-express today and I run into the same issue as @denneulin

Chunked encoding still isn't working, but we are now deleting the header for you https://github.com/awslabs/aws-serverless-express/commit/4d54a81b831eca97524f15b72fa8be379c80aedb#diff-168726dbe96b3ce427e7fedce31bb0bcR54


Relative (mswin) path fix + minor refactoring

LGTM :+1:
@ennovum would you mind rebasing so that this changes can be merged?

@gronke I tried, but it's no use- the codebase changed too much. Some of my adjustments are already applied. Sorry about that.

Thanks anyway! Re-applied your refactoring to the current master and added one test for backslashes in file exclusions.
@ennovum :beers:

@gronke Thanks! I'm glad I could help a bit. :beers:


docs: add link to thumbnail component

I noticed that while the page existed there was not a link to it. Currently, the only way. to get to it is via searching.

Wow that was fast! Thanks so much 🙏

Thanks for your contribution to Foundation Emails. I will check and ensure that the deployed docs are accordingly updated.
Hav a nice day!

It's deployed at https://get.foundation/emails/docs/thumbnail.html but it looks like we have some markdown parsing problem in the whole documenttion and I do not exactly know why.

I will try to invest some time to find the cause and fix this. Probably caused by some upgrades done in the dependencies.

It's caused by https://github.com/foundation/foundation-emails/commit/adef9048082a8a676564131dc1c56559d5dc7f46, I will revert this change.
cc @joeworkman


Netatmo component failes to load if Netatmo module has no name

Home Assistant release with the issue: 0.87.1

Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.): Hassbian, rpi3+, fresh install + ikea trådfri & google cast setup

Component/platform: https://www.home-assistant.io/components/netatmo/

Description of problem: The netatmo component failed setup. This appears to be because my outdoor module for reasons unknown had no name. Netatmo notifications (from the mobile app) would  would report that "Low temprature at noname". Once i set a proper name on the module using the Netatmo web gui, the component completed setup successfully.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):
2019-02-10 19:09:53 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform netatmo
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform
    SLOW_SETUP_MAX_WAIT, loop=hass.loop)
  File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for
    return fut.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/sensor/netatmo.py", line 93, in setup_platform
    for module_name in data.get_module_names():
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/sensor/netatmo.py", line 323, in get_module_names
    self.update()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/sensor/netatmo.py", line 360, in update
    self.data = self.station_data.lastData(exclude=3600)
  File "/srv/homeassistant/lib/python3.5/site-packages/smart_home/WeatherStation.py", line 117, in lastData
    lastD[module['module_name']] = ds.copy()
KeyError: 'module_name'

Additional information:

Looking at the docs for this component the name is required it seems: https://www.home-assistant.io/components/sensor.netatmo/#module_name

I only added the base netatmo component, i assume this from whatever autoconfiguration it attempted to do based on my netatmo modules? I did not add any sensors manually.

You need a module name it is marked as required in the documentation so this issue will be closed

Seems the solution has been provided in this issue, please let me know if that assessment is incorrect and i'll reopen.


Enhance code folding functionality in SQL editor

Please enhance the "cold folding" functions.

Allow user to fold any section of an SQL query (e.g. a CASE...END clause, or a SELECT (many fields) clause, or a Join, etc.
Allow user to fold/expand within a fold (aka a "tree with branches" or "nodes and sub-nodes")
Bonus: Keep the collapsed/expanded state of each fold section "sticky" -- even when the query or the app is closed, if possible! (I get it that this is tricky.)

Currently, the Folding feature only lets me collapse an entire SQL statement.  Limited usefulness.

thanks for suggestion

thanks for suggestion

I'm going to subdivide this FR into two separate issues. The first two points will be covered in https://github.com/dbeaver/dbeaver/issues/11830. Here we will concentrate on sticky folding.

Implemented.

verified


ENH: add exact=False support for stirling2

adding preliminary support for exact=False support to stirling2 for now only adds inclusion-exclusion via Lanczos which works well up to around N=33 and then has overflow issues.

Reference issue
Adds preliminary exact=False  support for Stirling numbers of the second kind
#17890
What does this implement/fix?
adding preliminary support for exact=False support to stirling2
Additional information
@steppi  During review from prior PR we decided to include exact=False support.
This PR adds initial support for inclusion-exclusion via Lanczos approximation.
Still needs to add:

[x] support for Temme for n > 33 and other places where it is more accurate than Lanczos

Thanks @rlucas7! Some quick comments/suggestions

I think the exact=False case should be handled in a ufunc with the kernel written in C, C++, or Cython.
Depending on the parameters one should use either:

The inclusion/exclusion formula with Lanczos approximation like in this PR
The dynamic programming algorithm in C calculated with doubles instead of ints
Temme's asymptotic expansion. 2nd order for now since that's what we have, but ideally we'd work out higher order expansions.

The key bit of work here is finding out for which inputs one should use each of the above three methods, trading off on accuracy, time, and memory. Numerical experiments seems to be the way to go here.

Thanks @rlucas7! Some quick comments/suggestions
* I think the `exact=False` case should be handled in a ufunc with the kernel written in C, C++, or Cython.

* Depending on the parameters one should use either:

  ....
  * The dynamic programming algorithm in C calculated with doubles instead of ints

I don't think the DP approach really fits the workflow of a ufunc though, IIUC every value is computed in a parallel way. Is there some point I'm missing?

Thanks @rlucas7! Some quick comments/suggestions
* I think the `exact=False` case should be handled in a ufunc with the kernel written in C, C++, or Cython.

* Depending on the parameters one should use either:

  ....
  * The dynamic programming algorithm in C calculated with doubles instead of ints

I don't think the DP approach really fits the workflow of a ufunc though, IIUC every value is computed in a parallel way. Is there some point I'm missing?

NumPy ufuncs don't employ parallelization. They just loop through and calculate values in a compiled language without any Python overhead. At one point while working on stirling2 you had a ufunc which used the dynamic programming algorithm, but the computation was with 64 bit ints not doubles. For not too large values of n, the dp algorithm is so fast that any redundant computation will be negligible.

...  At one point while working on stirling2 you had a ufunc which used the dynamic programming algorithm, but the computation was with 64 bit ints not doubles. For not too large values of n, the dp algorithm is so fast that any redundant computation will be negligible.

@steppi  Looking into the DP in ufunc and I had a question
In the stirling2 PR there was also some concern about doing a memory allocation (specifically malloc) inside each ufunc call-we need one to store the solution to sub-problems.
Is there a different way to do that or are we ok with doing it that way?

This passes builds for me locally but seems like different math.h constants in the test-runners on gh don't have M_E as the symbol for the constant?
looks like I can use the e constant here which should fix all but one of the build issues.
Other one is a linter issue from the rebase I just did to get the action to run.

Ok, looks like the e part is fixed. There is still some doc build issue, I always get confused on which thing needs to go where here in special.
@steppi It looks like I need to add function names to some constituent part of __all__ but I don't think we want to expose the inexact dp, nor the lanczos c ufuncs. I think I need to modify the function names to prefix with an _stirling2_{inexact,lanczos} but not sure where. Do you know where I need to modify the function?

I think I need to modify the function names to prefix with an _stirling2_{inexact,lanczos} but not sure where. Do you know where I need to modify the function?

They need to be modified in functions.json (and correspondingly, in _add_newdocs.py.)

Just a few brief comments, I haven't looked at this closely yet.
Also just a reminder, before this goes in I'd like to see

At least the second order asymptotic expansion implemented.

Not clear to me how to get access to lambertw_scalar in the stirling2.c code

Some experiments showing how the regimes where the different implementations are used was decided.

Yes. I will do these once I have all 3 methods implemented at C level. I plan to use inexact and a dispatch table to call out to temme/lanczos/dp by (n,k). my plan is to first implement all 3 methods as separate functions at c level and expose to python level. Doing it this way makes it easier (for me) to run the experiments for switching between the 3 approaches based on different n, k values.
Let me know if you've got a better way.

Not clear to me how to get access to lambertw_scalar in the stirling2.c code

I’ll post a small example when I have time later today or tomorrow.

Doing it this way makes it easier (for me) to run the experiments for switching between the 3 approaches based on different n, k values.

Ok, yeah that makes sense, just mark your PR as draft until you think it’s ready to go in.

C/H files are up in top level of special and found there after build.

Not clear to me how to get access to lambertw_scalar in the stirling2.c code

I’ll post a small example when I have time later today or tomorrow.

Once you are able to post the code for this I can finish the Temme approximation code in stirling.c.
Then I'll do the experiments to determine when to switch between Lanczos/DP(doubles)/Temme and add the dispatch  to stirling_inexact().

Once you are able to post the code for this I can finish the Temme approximation code in stirling.c.

Sorry, it's trickier than I thought because of the complexity of SciPy's build system (or maybe just my lack of familiarity). I'm not sure what changes would need to be made here to make lambertw_scalar (and also binom from _orthogonal_eval.pxd) available in stirling.c. If we do figure that out, it would be as simple as adding
#include "_lambertw.h"
#include "_orthogonal_eval.h"

I've only done this in small projects with a setup.py build, in that case if you have an extension where the sources contain a .c and a .pxd, you can directly include from the .h generated from the .pxd.
I think the simplest thing to do is just to write stirling2 in Cython instead of C.

@rlucas7, long term, I think the best course of action will be to rewrite lambertw, binom, (and all other special functions in SciPy that are implemented in Cython) into C++. This will make it easier to call them from other functions, and also opens up the possibility of using them on the GPU in CuPy, and other array computing libraries.
@izaid has kindly offered to help review PRs to rewrite such functions in C++. I plan to submit PRs for these two first. At the moment I think your options are to either follow through implementing the expansion in Cython, and we can convert later, or to wait until the lambertw and binom have been rewritten.

@steppi thanks for letting me know. I’m not opposed to switching to c/c++ for Cython special functions but we should probably have a dev list discussion about that-unless we already have. Just to make sure everyone is on board, e.g. I think the docs still read to prefer cython for new stuff, which hasn’t really been followed strictly since I’ve been contributing.Do you have a time estimate on the lambertw and binom functions? (Just approximate timeline is all I’m asking) o/w it’s difficult for me to make the decision of cython or c. Alternately, we could keep the Temme in Python for now and move it down to c later once the cython -> c++ migrations are merged, Please let me know if you have opinions on proposed third way.Also, happy to be included in any reviews touching those functions. -Lucas Roberts On Oct 16, 2023, at 1:23 PM, Albert Steppi @.***> wrote:
@rlucas7, long term, I think the best course of action will be to rewrite lambertw, binom, (and all other special functions in SciPy that are implemented in Cython) into C++. This will make it easier to call them from other functions, and also opens up the possibility of using them on the GPU in CuPy, and other array computing libraries.
@izaid has kindly offered to help review PRs to rewrite such functions in C++. I plan to submit PRs for these two first. At the moment I think your options are to either follow through implementing the expansion in Cython, and we can convert later, or to wait until the lambertw and binom have been rewritten.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@rlucas7. I plan to have PRs submitted for binom and lambertw within the next two weeks and plan to make an RFC issue and dev list posting for the Cython->C++ proposal tomorrow. I'll ping you on the two PRs and the issue when I make them.

@rlucas7 while you’re blocked due to the current state of lambertw and binom I think the best thing to do would be to just use a Python implementation of the asymptotic expansion in your experiments to help determine how the choice of method should depend on n and k.

Also just a reminder, before this goes in I'd like to see

At least the second order asymptotic expansion implemented.
Some experiments showing how the regimes where the different implementations are used was decided.

Sure, here you go. My decision based on looking at these is to NOT USE either Lanczos or Temme (this was a bit of a surprise for me). The DP approach is pretty accurate up through the space of values that are covered by valid doubles. Neither Lanczos (applied to inclusion-exclusion formula) nor the Temme 2nd order approximation come close in terms of accuracy.
stirling2_approx_comparisons.txt
Let me know if you disagree.

@steppi unless you disagree w/findings in the previous post, I can delete all the other C stuff and leave only the DP approach. This may also impact the prioritization of the C++ migration of lambertw and binom from cython discussed in
https://github.com/scipy/scipy/issues/19404

@rlucas7, we need to take into account time and memory efficiency  for  exact=False’. The asymptotic expansion will be much faster for large parameters and not require large memory allocations.  Inclusion exclusion should only work well for small k, I’m not sure if we’d want to use it anywhere. The 2nd order expansion from Temme is pretty inaccurate. Eventually we should try higher order.

@rlucas7, we need to take into account time and memory efficiency for exact=False’. The asymptotic expansion will be much faster for large parameters and not require large memory allocations. Inclusion exclusion should only work well for small k, I’m not sure if we’d want to use it anywhere. The 2nd order expansion from Temme is pretty inaccurate in the regimes we’re looking at.  Eventually we should try higher order.

@rlucas7, we need to take into account time and memory efficiency for exact=False. The asymptotic expansion will be much faster for large parameters and not require large memory allocations.

I can run timeit timings sometime this upcoming week and add them here.

Inclusion exclusion should only work well for small k, I’m not sure if we’d want to use it anywhere.

Yes that's my takeaway too, IE + Lanczos works well for small (n,k) but degrades quickly and becomes useless for n>20 (or 30).

The 2nd order expansion from Temme is pretty inaccurate in the regimes we’re looking at. Eventually we should try higher order.

Generally I agree but I'm going to say a higher order expansion is not in scope for this PR.

Generally I agree but I'm going to say a higher order expansion is not in scope for this PR.

Yeah, definitely not. I was thinking on the order of 1 year down the line.

... not require large memory allocations

I'm not sure if you meant this as an alternative to DP and large memory allocations so providing for context...
The fundamental problem here (as I see it) is that the ufunc setup isn't aligned with DP style problems b/c there is no sharing between function calls across values in ndarrays, even when two calls (n,k) and (m,l) share common subproblems.
We dealt with this was via a map and a heap in the exact=True case for DP-it was outside of ufuncs though.
Note that in the PR here we are using a slightly different DP code approach where we allocate an array for each and every (n,k) 2-tuple whereas in exact=True case we used 1 (dynamically sized) array for the whole broadcasted ndarray of (n,k) arguments.
Here we could do something similar to exact=True (I guess it would need to be outside of ufunc setup though) using C++ heaps. If we did that then it's a bit weird to put parts of it into a ufunc.  Also, I'm not sure if stl heaps are fair game for SciPy.  (I have some heap code in C lying around but I don't think we'd prefer that route, it's a fair bit of code).
I'm guessing the preferred approach will be more clear once I put together timings this weekend.

Here we could do something similar to exact=True (I guess it would need to be outside of ufunc setup though) using C++ heaps. If we did that then it's a bit weird to put parts of it into a ufunc. Also, I'm not sure if stl heaps are fair game for SciPy. (I have some heap code in C lying around but I don't think we'd prefer that route, it's a fair bit of code).

I think this is too complicated.

I'm guessing the preferred approach will be more clear once I put together timings this weekend.

Cool. I’ll try to have lambertw and binom rewritten by then so we can have the right comparison.

Yeah, we don't want to use STL heaps or anything like that.
@rlucas7 I don't know if this is useful to you, but it is possible to actually use gufuncs to compute a sequence of values at once, which will allow for that shared state you are describing. I have done this for functions computed with a recurrence relation, but it might require passing in an uninitialised output array of the right shape (not super hard, but could be better).

... I don't know if this is useful to you, but it is possible to actually use gufuncs to compute a sequence of values at once, which will allow for that shared state you are describing. I have done this for functions computed with a recurrence relation, but it might require passing in an uninitialised output array of the right shape (not super hard, but could be better).

This is useful to know, is there some code you could link to, or o/w share?
AFAIK the scipy mechanism supports ufuncs so I'm not sure what would need to be changed in the autobuild process-it seems like maybe nothing. I may investigate switching to that setup on a follow up PR-it seems like a better fit and some approach I'd want to reuse for the first kind stirling too (and plenty of other examples of numbers in recurrence relations).

@rlucas7 Yes, so what you want is PyUFunc_FromFuncAndDataAndSignature from the NumPy C API. You can also access this using Cython or whatever. See more at Generalized Universal Functions. What you can do is define a signature for the function with appropriate dimension parameters for the return type, which can be variable. For instance, suppose I want to compute some function P(n, m, x) where n and m are interrelated for the same x. You can use this to still run elementwise over x, but get an inner loop that does the n and m all together so you can do custom work for each x.
I'm not saying this is perfect, but it does work pretty well. You will need to allocate the output array to be of the right shape and pass it in to the ufunc. This is not so hard, just calculate the shape and call np.empty. You can hide the ufunc and have a Python function that does this all together as your public facing version.
I have code that does this, but not in a public repository. Happy to chat more and work towards an example if this is of use to you.

Yes, so what you want is PyUFunc_FromFuncAndDataAndSignature from the NumPy C API

Right. special doesn't have the infrastructure to create gufuncs from a kernel like it does for ufuncs but the prospect of adding this has come up before. @WarrenWeckesser, mentioned here https://github.com/scipy/scipy/pull/19144#issuecomment-1694732991, that he's developed infrastructure for this in his ufunclab package.
Here's his script to generate the boilerplate https://github.com/WarrenWeckesser/ufunclab/blob/main/tools/cxxgen/generate_ufunc_extmod.py,
and here's an example of a kernel for the multivariate_log_beta function https://github.com/WarrenWeckesser/ufunclab/blob/main/src/multivariate_logbeta/multivariate_logbeta_gufunc.h.
I'd be supportive and adding this or something based on it to special.
For stirling2, my preference would be for exact=False to use an asymptotic expansion for larger cases, and use the recurrence for ones small enough that the function is still fast even when doing duplicate work. I know the 2nd order expansion has pretty large relative error (e.g. max rel_error: 5.594615855771742e-05) for n=30). For this release cycle, I think adding exact=False is mainly about API consistency. Next release cycle one of us can crack open Temme's Asymptotic Methods for Integrals and iwork out the expansion to 4th order, which should give us acceptable results.
I'll make a PR  for lambertw in C++ later today and have one ready for binom.

@rlucas7, I've made a PR for lambertw here https://github.com/scipy/scipy/pull/19435. In order to use this, you'll need to compile your implementation as C++. I'm pretty sure you can just do this in functions.json
    "stirling2_dp": {
        "stirling2.h++": {
            "stirling2_dp": "ii->d"
        }
    },

Here is a figure using the existing python implementation and also the pure python on the main branch which starts to slow down a lot around n=80. These calculations are using the python version of Temme and the Lanczos version should not be used b/c it isn't nunerically stable for n>33-at least not as implemented.

@steppi  I'll redo without the pure python stuff once binom C++ version is up.

@rlucas7, I've made a PR for lambertw here #19435. In order to use this, you'll need to compile your implementation as C++. I'm pretty sure you can just do this in functions.json
    "stirling2_dp": {
        "stirling2.h++": {
            "stirling2_dp": "ii->d"
        }
    },

I'll try to get a PR in for binom this week too and will create a branch that has both of them that you can work off of for now.

Maybe I missed something but if I do this (and basically only this as a change) I now get
(scipy-dev) Lucass-MacBook:scipy rlucas$ python dev.py python
💻  ninja -C /Users/rlucas/scipy/build -j2
ninja: Entering directory `/Users/rlucas/scipy/build'
[10/39] Generating scipy/stats/_dummy_stats_gen_pyx with a custom command
[12/12] Linking target scipy/special/cython_special.cpython-310-darwin.so
Build OK
💻  meson install -C build --only-changed
Installing, see meson-install.log...
Installation OK
Python 3.10.13 (main, Aug 24 2023, 22:46:19) [Clang 13.0.0 (clang-13<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>
>>> from scipy.special import stirling2, stirling2_dp, stirling2_temme
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/rlucas/scipy/build-install/lib/python3.10/site-packages/scipy/special/__init__.py", line 777, in <module>
    from . import _ufuncs
  File "scipy/special/_ufuncs.pyx", line 1, in init scipy.special._ufuncs
ImportError: dlopen(/Users/rlucas/scipy/build-install/lib/python3.10/site-packages/scipy/special/_ufuncs_cxx.cpython-310-darwin.so, 2): Symbol not found: __Z12stirling2_dpii
  Referenced from: /Users/rlucas/scipy/build-install/lib/python3.10/site-packages/scipy/special/_ufuncs_cxx.cpython-310-darwin.so
  Expected in: flat namespace
 in /Users/rlucas/scipy/build-install/lib/python3.10/site-packages/scipy/special/_ufuncs_cxx.cpython-310-darwin.so
>>>

I'm pushing my changes if it helps. I'll take a look again this week.

Maybe I missed something but if I do this (and basically only this as a change) I now get

Sorry, that makes sense. It’ll work if you put the entire implementation in the header file and get rid of the .c file. You won’t have to add anything to meson.build in that case.

Maybe I missed something but if I do this (and basically only this as a change) I now get

Sorry, that makes sense. It’ll work if you put the entire implementation in the header file and get rid of the .c file. You won’t have to add anything to meson.build in that case.

yup, that works. The 841f07d commit  contains the changes to get that to build and pass the test harness. I'll rebase this off master/main locally tomorrow and incorporate the lambertw PR changes to Temme.
Getting closer. :)

I updated the commit message on the force push rebase to reflect the fact that we now are not using Lanczos b/c it is too numerically unstable for N>32. I'm working to include the lambertw #19435 and any obvious changes from failing tests here in latest test harness execution

@rlucas7, feel free to look at and merge the binom PR if you’re comfortable with that and want to unblock this.
@izaid  , do you think this stirling2_approx implementation should go in the scipy::special namespace and follow the C++ conventions we’re using there? In any case, I don’t think that should block this PR and it could always be left for a follow up.

@rlucas7 Yes, so what you want is PyUFunc_FromFuncAndDataAndSignature from the NumPy C API. You can also access this using Cython or whatever. See more at Generalized Universal Functions. What you can do is define a signature for the function with appropriate dimension parameters for the return type, which can be variable. For instance, suppose I want to compute some function P(n, m, x) where n and m are interrelated for the same x. You can use this to still run elementwise over x, but get an inner loop that does the n and m all together so you can do custom work for each x.
I'm not saying this is perfect, but it does work pretty well. You will need to allocate the output array to be of the right shape and pass it in to the ufunc. This is not so hard, just calculate the shape and call np.empty. You can hide the ufunc and have a Python function that does this all together as your public facing version.
I have code that does this, but not in a public repository. Happy to chat more and work towards an example if this is of use to you.

@izaid  something like this?
https://gist.github.com/rlucas7/8c9e9ec32bb00aaff1713c468d7e7bdc
(for the gufunc)
This is interesting and if it is faster we can do something along the same lines if we decide to add a gufunc support to special-or scipy more broadly. Going to call it out of scope for this PR though but thank you for mentioning it's definitely a candidate approach.

@rlucas7 Yes, so what you want is PyUFunc_FromFuncAndDataAndSignature from the NumPy C API. You can also access this using Cython or whatever. See more at Generalized Universal Functions. What you can do is define a signature for the function with appropriate dimension parameters for the return type, which can be variable. For instance, suppose I want to compute some function P(n, m, x) where n and m are interrelated for the same x. You can use this to still run elementwise over x, but get an inner loop that does the n and m all together so you can do custom work for each x.
I'm not saying this is perfect, but it does work pretty well. You will need to allocate the output array to be of the right shape and pass it in to the ufunc. This is not so hard, just calculate the shape and call np.empty. You can hide the ufunc and have a Python function that does this all together as your public facing version.
I have code that does this, but not in a public repository. Happy to chat more and work towards an example if this is of use to you.

@izaid something like this?
https://gist.github.com/rlucas7/8c9e9ec32bb00aaff1713c468d7e7bdc
(for the gufunc)
This is interesting and if it is faster we can do something along the same lines if we decide to add a gufunc support to special-or scipy more broadly. Going to call it out of scope for this PR though but thank you for mentioning it's definitely a candidate approach.

Yes, but you used Numba in the gist? If the intention is to demonstrate the signature, then yes that's an analogous example! But you can do it with NumPy alone, no need for any other library - but needs to be in C or Cython.
There are certain special functions where I do intend to advocate for something like this, but not the immediate ones.

@rlucas7, feel free to look at and merge the binom PR if you’re comfortable with that and want to unblock this.
@izaid , do you think this stirling2_approx implementation should go in the scipy::special namespace and follow the C++ conventions we’re using there? In any case, I don’t think that should block this PR and it could always be left for a follow up.

Yes, for stirling2_approx, why not! But it's not something we need to advertise, but no reason to not use best practice.

Yes, for stirling2_approx, why not! But it's not something we need to advertise, but no reason to not use best practice.

I guess just because with the dynamic memory allocations here; I don’t think this will benefit from gpu speedup.

Yes, for stirling2_approx, why not! But it's not something we need to advertise, but no reason to not use best practice.

I guess just because with the dynamic memory allocations here; I don’t think this will benefit from gpu speedup; but yeah, no real reason why not at least in a follow up.

My attitude generally is we're setting a style and convention for how special functions we write should look, and we should try to follow that where possible.
That said, the only dynamic allocation I saw was a malloc. I'm certainly not saying we should do so without caution, but even so CUDA kernels can malloc now for some time. But I'd still try to use static allocation where possible (GPU or not).

How’s this coming along @rlucas7? I’m willing to merge as soon as I verify you have it working regardless of C++ style considerations.

How’s this coming along @rlucas7? I’m willing to merge as soon as I verify you have it working regardless of C++ style considerations.

I've been working on timings as a follow up to this comment. When we compare only the approximate versions of DP and temme, the runtime of the approximate versions do start to scale linearly with n once we get above n=45 or so.

so for the dispatch I'll use n>50 to cut over to Temme.
from scipy.special import stirling2_dp, stirling2_temme, stirling2
import matplotlib.pyplot as plt
import timeit

y_temme = []
y_dp = []
x = list(range(10, 105, 5))
for n in x:
    s_temme = f"""n={n}; stirling2_temme([{n}], list(range(1,{n})))"""
    y_temme.append(timeit.timeit(stmt=s_temme, number=10000, setup="from scipy.special import stirling2_temme"))
    s_dp = f"""n={n}; stirling2_dp([{n}], list(range(1,{n})))"""
    y_dp.append(timeit.timeit(stmt=s_dp, number=10000, setup="from scipy.special import stirling2_dp"))

fig, ax = plt.subplots()
line1, = ax.plot(x, y_temme, linewidth=2.0, label="Temme")
line2, = ax.plot(x, y_dp, linewidth=2.0, label="DP")
ax.legend(handles=[line1, line2])
plt.title(label="Runtimes")
plt.show()

^ code used to generate the figure

Looks like the _lambertw.h code isn't getting picked up in the build process on github, this works for me locally, @steppi is there something that looks incorrect here to you?

I'm seeing
FAILED special/tests/test_basic.py::TestStirling2::test_numpy_array_unsigned_int_dtype - TypeError: ufunc '_stirling2_inexact' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

both locally and in the test harness, I'm not sure how we handle this with the c++ setup here in special, @steppi have you seen this before? (any ideas?)

I'm seeing
FAILED special/tests/test_basic.py::TestStirling2::test_numpy_array_unsigned_int_dtype -
 TypeError: ufunc '_stirling2_inexact' not supported for the input types, and the
inputs could not be safely coerced to any supported types according to the
casting rule ''safe''

both locally and in the test harness, I'm not sure how we handle this with the c++ setup here in special, @steppi have you seen this before? (any ideas?)

unsigned int dtype isn't supported in the ufunc infrastructure. These are the allowed typecodes in functions.json
The input parameter types are denoted by single character type
codes, according to

   'f': 'float'
   'd': 'double'
   'g': 'long double'
   'F': 'float complex'
   'D': 'double complex'
   'G': 'long double complex'
   'i': 'int'
   'l': 'long'
   'v': 'void'

I think just get rid of that test for exact=False and clearly document which input types work for exact=True and exact=False.

Or I think it might just work if you replace "ii->d" in functions.json with "ll->d" since a 32 bit unsigned int can be safely cast to a 64 bit int.

~Or I think it might just work if you replace "ii->d" in functions.json with "ll->d" since a 32 bit unsigned int can be safely cast to a 64 bit int.~
Nevermind that, the test has 64 bit unsigned longs. I think the "ii" should be replaced by "ll" anyway though because I know stirling2(n, n-1) at least will fit in a double for n pretty large.

The build fails for me locally if I swap "ll" for "ii", so I don't think that type is currently supported here. I seem to recall this issue was surfaced a few years back when I was doing other special changes but I don't recall the details.

... unsigned int dtype isn't supported in the ufunc infrastructure.
...
I think just get rid of that test for exact=False and clearly document which input types work for exact=True and exact=False.

Should we add an input validation and raise a TypeError for this?
(inside the python portion of stirling2())

Should we add an input validation and raise a TypeError for this?
(inside the python portion of stirling2())

Yeah. And if we do that we can make the ufunc takes doubles and do input validation and convert to double before passing. I think the overhead should be negligible.

Should we add an input validation and raise a TypeError for this?
(inside the python portion of stirling2())

Yeah. And if we do that we can make the ufunc take doubles and do input validation and convert to double before passing. I think the overhead should be negligible.

Ok I think I understand, with this way we can handle the uint cases too. This means that there is no need to remove the uint dtypes test case for the exact=False case. Instead we typecast the uint arguments (n,k) to doubles and pass them into the dispatcher for routing. This seems to work fine so I left it all in with a note to describe what's going on in this scenario in case it surfaces in future maintenance work.
If no major issues from test harness-I'll change from draft status tomorrow.

...
If no major issues from test harness-I'll change from draft status tomorrow.

I'm a few minutes before tomorrow (20 or son) but everything is green in the test harness. @steppi I think this is ready for a closer scrutiny.

Nice work @rlucas7! Thanks for all your patience here.


Field serialization rework

Fixes #5.
Probably will be a draft for a long time.

This feature has been cancelled due to a lack of resources and the amount of breaking changes (enforced v4 release) it will bring.


[CWS] skip activity dumps on windows

What does this PR do?
Activity dumps are not supported by windows yet. No need for the security agent to listen for them

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Support for spread attributes

JSCS is having a lot of issues with spread attributes. Obviously, they can't be parsed with regular settings. I then tried enabling "esnext": true, but that didn't help either.
Unexpected token ... at components/js/layout/Test.js :
    36 | render () {
    37 |  var { className, fixedHeight, fixedWidth, height, width, ...other } = this.props;
--------------------------------------------------------------------^

Even wrapping it in a  //jscs:disable didn't seem to help.
Unexpected token ... at components/js/layout/Test.js :
    36 | render () {
    37 |  //jscs:disable
    38 |  var { className, fixedHeight, fixedWidth, height, width, ...other } = this.props;
--------------------------------------------------------------------^
    39 |  //jscs:enable

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/10231986-support-for-spread-attributes?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

Unexpected token usually means that esprima doesn't currently support spread or destructuring in that way yet. Yeah esnext would be required as well.
You can try esprima-fb maybe? npm install it and either do --esprima=esprima-fb_path or add it to your .jscsrc with "esprima": "path_to_esprima-fb"

@globexdesigns using esprima-fb for the time being is your best option. Going to close this for now, as it can only be fixed by Esprima.


[2.8] chore(deps): update module github.com/docker/docker

Update docker/docker to:

github.com/docker/docker v23.0.6+incompatible
github.com/docker/docker => github.com/docker/docker v20.10.25+incompatible

Fix CVE-2023-28840, CVE-2023-28841 and CVE-2023-28842 and removes false positives being flagged due to Docker's version being replaced.

CC @deniseschannon

@snasovich yes, you are right. We are bumping github.com/docker/docker to remove the noise from some tools that can't reliably identify the replace ( github.com/docker/docker => github.com/docker/docker v20.10.25+incompatible  ). Our tools can identify this, but Dependabot sometimes triggers them, as well as customers' reports. Anyway, it's a harmless bump after all.


[BUG] CompileError with const fused_t[:, ::1] argument

Describe the bug
Addition of a const identifier to the fused type declaration crashes the compiler. This is already reported in #3222 but marked as solved. Hence I am not sure whether this is related. Without the const it compiles fine.
To Reproduce
Code to reproduce the behaviour:
%%cython -3 -a
import cython
cimport numpy as cnp
from libc.math cimport isfinite

ctypedef fused lapack_t:
    float
    double
    float complex
    double complex
ctypedef float complex float_complex
ctypedef fused lapack_cz_t:
    float complex
    double complex
ctypedef fused lapack_sd_t:
    float
    double

@cython.boundscheck(False)
@cython.wraparound(False)
cpdef inline bint array_chkfinite(const lapack_t[:, ::1]A):
    """

    """
    cdef size_t n = A.shape[0]
    cdef int r, c
    cdef lapack_t entry
    if lapack_t in lapack_cz_t:
        for r in xrange(n):
            for c in xrange(n):
                entry = A[r, c]
                if not(isfinite(entry.real) and isfinite(entry.imag)):
                    return False
    else:
        for r in xrange(n):
            for c in xrange(n):
                if isfinite(A[r, c]):
                    return False
    return True

This throws the following error

Error compiling Cython file:
------------------------------------------------------------
...
    float
    double

@cython.boundscheck(False)
@cython.wraparound(False)
cpdef inline bint array_chkfinite(const lapack_t[:, ::1]A):
                                                ^
------------------------------------------------------------

C:\Users\Ilhan Polat\.ipython\cython\_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:49: Compiler crash in AnalyseDeclarationsTransform

File 'ModuleNode.py', line 124, in analyse_declarations: ModuleNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:1:0,
    full_module_name = '_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286')
File 'Nodes.py', line 431, in analyse_declarations: StatListNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:1:0)
File 'Nodes.py', line 431, in analyse_declarations: StatListNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:6)
File 'Nodes.py', line 375, in analyse_declarations: CompilerDirectivesNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:6)
File 'Nodes.py', line 431, in analyse_declarations: StatListNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:6)
File 'Nodes.py', line 2354, in analyse_declarations: CFuncDefNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:6,
    decorators = [...]/0,
    doc = '\n\n    ',
    modifiers = [...]/1,
    overridable = 1,
    visibility = 'private')
File 'Nodes.py', line 681, in analyse: CFuncDeclaratorNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:33,
    calling_convention = '',
    overridable = 1)
File 'Nodes.py', line 891, in analyse: CArgDeclNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:34,
    is_generic = 1,
    outer_attrs = [...]/2)
File 'Nodes.py', line 1091, in analyse: MemoryViewSliceTypeNode(_cython_magic_d06ba7f2fb4592a1e2bcd75d12e69286.pyx:21:49,
    is_arg = True,
    name = 'memoryview')

Compiler crash traceback from this point on:
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\Nodes.py", line 1091, in analyse
    self.type = PyrexTypes.MemoryViewSliceType(base_type, axes_specs)
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\PyrexTypes.py", line 625, in __init__
    self.dtype_name = Buffer.mangle_dtype_name(self.dtype)
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\Buffer.py", line 631, in mangle_dtype_name
    return prefix + dtype.specialization_name()
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\PyrexTypes.py", line 57, in specialization_name
    common_subs = (self.empty_declaration_code()
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\PyrexTypes.py", line 51, in empty_declaration_code
    self._empty_declaration = self.declaration_code('')
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\PyrexTypes.py", line 1582, in declaration_code
    return self.const_base_type.declaration_code("const %s" % entity_code, for_display, dll_linkage, pyrex)
  File "c:\users\ilhan polat\appdata\local\programs\python\python38\lib\site-packages\Cython\Compiler\PyrexTypes.py", line 1649, in declaration_code
    raise Exception("This may never happen, please report a bug")
Exception: This may never happen, please report a bug

Environment (please complete the following information):

OS:  Windows 10.1904
Python version 3.8.0
Cython version 0.29.21

It probably is the same thing. https://github.com/cython/cython/issues/3222 was only fixed in Cython 3(alpha) and wasn't back-ported. Possibly because it was fixed "by accident" while adding a different feature.

Is there any chance the fix will be backported?  This affects a couple modules in SciPy that use arrays with fused types.

@WarrenWeckesser The supposed fix cherry-picks cleanly (apart from a small conflict in one of the test files). However it doesn't actually fix the bug on its own. So right now I don't know what this fix is!
I think the question of "will it be backported" depends on how complex it is.... Last time we tried to backport a change to 0.29.x it broke the world, so I've been put off a little.

@da-woods, OK, thanks for checking.

Right I've investigated a bit further. The actual commit is
https://github.com/cython/cython/commit/ff8e254e0d3ec7b9b8ead5b01937976092a4811d
It's essentially a 1-line change in Cython and the rest is tests. It doesn't quite backport cleanly, but it's pretty trivial to mix up.
I'd be comfortable back-porting this, so I'll make a PR for it. I'll leave it up to @scoder to decide whether to accept it though.

Fixed in https://github.com/cython/cython/pull/5076


Issue with sending data payloads along with notification

My data payload is showing in the android app's logcat when the app is in foreground, but showing null when the app is in background. Also, I'm unclear with how to send the data payload appropriately of this form:
{
"id": 1,
"topic": "Health",
"question": "abc",
"image": "fe6aeea9b7a94575c56a63c05ed12d87.png",
"type": "Yes/No",
"yes": "error",
"no": "No",
"A": null,
"B": null,
"C": null,
"D": null,
"created_at": "2017-07-29 02:20:47",
"updated_at": "2017-07-29 03:25:19"
}
Please someone post an example code which can send the array like this in data payload. All I want is when the user taps on notification, it should take them directly to a activity showing this poll on which they can respond.
Thanks

Hello,
Sorry for the late answer
On Android notification can created from 3 deferents ways who have a different behaviour on the device.

Notification Payload Only
Data Payload Only
Notification Payload and Data Payload together.

App State
Notification
Data
Notification & Data

Foreground
onMessageReceived
onMessageReceived
onMessageReceived

Background
System tray
onMessageReceived
Notification: system tray  Data: in extras of the intent.

More information here
In the case that you are sending  Notification & Data together, onMessageReceived is not called and the notification is displayed by the system tray. If you want to get data from this notification, you can find them in the intent of your activity when the application is opened by a click on the notification.
Here a dummy Android sample code that are doing that:
protected void onCreate(Bundle savedInstanceState) {
    Intent intent = getIntent();
    this.displayIntentContent(intent.getExtras());
}

private void displayIntentContent(Bundle bundle) {

        if (bundle == null) {
            return;
        }

        String data = "";

        for (String key : bundle.keySet()) {
            Object value = bundle.get(key);
            data += key + " : " + value.toString() +"\n";
        }

        AlertDialog.Builder builder = new AlertDialog.Builder(this);
        builder.setMessage(data).setTitle(R.string.notification_content_title);
        builder.setPositiveButton(R.string.close, null);

        AlertDialog dialog = builder.create();
        dialog.show();
}

Let me know if this explanation  is helping you
Best Regards
Nicolas

@mechtech5 how did you solved your problem with this library ?


Cmdline - get app analysis call doesnt allow multiple hostnames

right now AntaresCmd  GetAppAnalysis call doesnt allow multiple hostnames.

Command line tool does do multiple hostnames. Hostname is delimited by space to allow multiple hostnames.


Dask Dataframe cannot handle the lazy evaluation of dd.Scalar object in fillna

This issue is somewhat related to #1701
#1701 reveals the issue when fillna with a dask dataframe ops. In some cases, we have to fill each column using the columnwise ops like .mean:
Minimal reproducible example:
from pandas.util.testing import makeMissingDataframe
import dask.dataframe as dd

df_t = makeMissingDataframe(0.8, 1000)

ddf_t = dd.from_pandas(df_t, npartitions=5)

ddf_t.fillna(ddf_t.mean()).compute() # Works
ddf_t["A"].fillna(ddf_t["A"].mean().compute()).compute() # Works

ddf_t["A"].fillna(ddf_t["A"].mean()).compute() # Does not work.

@DigitalPig Thank you for the report.  The does not work line is a duplicate of the line above.

ddf_t["A"].fillna(ddf_t["A"].mean().compute()).compute() # Works
ddf_t["A"].fillna(ddf_t["A"].mean()).compute() # Does not work.

Can you post with the problematic line ?

He's saying that passing a dask.dataframe.Scalar object into fillna doesn't work, but that passing a concrete value, like a float, does.

Fixed by https://github.com/dask/dask/pull/5463


Add implementation for dbt_utils.deduplicate

This change was prompted by: https://github.com/dbt-labs/dbt-utils/pull/550

Thanks!


Bug report — Rewriting a WebSocket response throws exception due to unsupported status code 101.

If I try to instantiate a response based on another response, with status code 101, returned by a DurableObject, I get this error:
Responses may only be constructed with status codes in the range 200 to 599, inclusive.
This is causing an issue in next-on-pages as reported here
I don't know if it should be addressed here, or next-on-pages should put an exception for this case to directly return the response coming from the DurableObject and return it without re-instantiation.

As a work-around, you can change the status to 200 -- because it has a webSocket property, the system will change it back to 101.

@kentonv Thanks for the quick response! I will try that, for now I'm using this minor patch on next-on-pages
Do you know if it should be taken care in workerd by allowing status code 101, or by providing an api for handling special cases when response is being forwarded from other services like durable objects, or it should be taken care in next-on-pages and it is not going to be supported to instantiate a response with status code 101 in workerd?

Supporting 1xx interim responses in workers is something we've discussed but is not trivial as it is something that would need to be implemented deep throughout our stack. I do want to make this happen but we'll need to discuss internally around priority and feasibility. I'm going to change this issue to a feature request as it's not really a bug as much as a limitation of the current design/implementation.

I've changed the title of this bug to better reflect the specific bug here.
@jasnell the ask is NOT to support 1xx in general. The problem here is that fetch() itself returns a Response with status 101 when the response is a WebSocket response, and attempts to rewrite that response (e.g. change a header) fail because we throw an exception about not supporting 1xx status codes.
This is a bug which we should fix. We should simply say that if the Response is specifically a WebSocket response (its webSocket property is non-null), then we allow it to have status 101.

This is a bug which we should fix. We should simply say that if the Response is specifically a WebSocket response (its webSocket property is non-null), then we allow it to have status 101.

SGTM

Thanks!
This might help others with similar issues:
My original challenge was serving the WebSocket endpoint on the same subdomain as my web application, which led me to try proxying responses. Even with a workaround to deal with the issue reported here, I ran into the issue of the connection closing after 100 seconds of inactivity due to hibernation (noted in the docs but a little easy to miss).
Then, I discovered the routes feature, a handy tool that allows serving different workerd instances on different paths without needing to proxy WebSocket responses.

I am hitting this issue on deployed cf worker
I have a code liek this in my Durable Object
const webSocketPair = new WebSocketPair();
const [client, server] = Object.values(webSocketPair);
this.state.acceptWebSocket(server);
return new Response(null, {
	status: 101,
	webSocket: client,
});

and the worker forward that back to the client
With that I get
RangeError: Responses may only be constructed with status codes in the range 200 to 599, inclusive.

Hmm now I'm confused, the code actually looks correct.
https://github.com/cloudflare/workerd/blob/e07508ec78498ec46db2f1eda16ec00b2f2b08b2/src/workerd/api/http.c%2B%2B#L1402-L1408
So my work-around suggestion earlier is actually wrong. But AFAICT it shouldn't be needed, the runtime code does the right thing, and will allow (in fact, require) a status code of 101 whenever a WebSocket is present.
Can someone please provide a complete, self-contained reproduction of the issue?


Control Panel, Full Text Search Not Working

My Full Text search page isn't loading in the Control Panel.

When I looked at /var/log/onlyoffice/web.api.log I saw this:
2021-02-03 20:10:47,147 ERROR [388] ASC.Api - method error: https://<IP_ADDRESS>/api/2.0/portal/search/state.json - Server error Elasticsearch.Net.ElasticsearchClientException: Error: ConnectFailure (Connection refused). Call: Status code unknown from: GET /_cat/indices?s=index ---> System.Net.WebException: Error: ConnectFailure (Connection refused) ---> System.Net.Sockets.SocketException: Connection refused
  at System.Net.Sockets.SocketAsyncResult.CheckIfThrowDelayedException () [0x00014] in <88f564ea69dd4dc8ba9bf979e48d5996>:0
  at System.Net.Sockets.Socket.EndConnect (System.IAsyncResult asyncResult) [0x0002c] in <88f564ea69dd4dc8ba9bf979e48d5996>:0
  at System.Net.WebConnection+<>c.<Connect>b__16_1 (System.IAsyncResult asyncResult) [0x00006] in <88f564ea69dd4dc8ba9bf979e48d5996>:0
  at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.Threading.Tasks.Task`1[TResult] promise, System.Boolean requiresSynchronization) [0x00019] in <f2b3ab7dfff746f594d2ef5b16ec3c90>:0
--- End of stack trace from previous location where exception was thrown ---

Any ideas how to fix?

Please check systemctl status elasticsearch and /var/log/onlyoffice/Index/elasticsearch.log for errors. Make sure you have enought RAM (8gb+ recommended).

Status showed active.  Server has 8 GB ram.  Log showed this:
[2021-02-05T16:28:50,901][INFO ][o.e.e.NodeEnvironment    ] [localhost] using [1] data paths, mounts [[/ (/dev/root)]], net usable_space [133.2gb], net total_space [156.9gb], types [ext4]
[2021-02-05T16:28:50,969][INFO ][o.e.e.NodeEnvironment    ] [localhost] heap size [990.7mb], compressed ordinary object pointers [true]
[2021-02-05T16:28:51,005][INFO ][o.e.n.Node               ] [localhost] node name [localhost], node ID [J8sHnQmrRGOb1UTHzE0PYg], cluster name [elasticsearch]
[2021-02-05T16:28:51,007][INFO ][o.e.n.Node               ] [localhost] version[7.4.0], pid[773], build[default/deb/22e1767283e61a198cb4db791ea66e3f11ab9910/2019-09-27T08:36:48.569419Z], OS[Linux/5.10.2-x86_64-linode140/amd64], JVM[AdoptOpenJDK/OpenJDK 64-Bit Server VM/13/13+33]
[2021-02-05T16:28:51,008][INFO ][o.e.n.Node               ] [localhost] JVM home [/usr/share/elasticsearch/jdk]
[2021-02-05T16:28:51,009][INFO ][o.e.n.Node               ] [localhost] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -Des.networkaddress.cache.ttl=60, -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/tmp/elasticsearch-3341852734001699046, -XX:HeapDumpPath=/var/lib/elasticsearch, -XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/elasticsearch/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Djava.locale.providers=COMPAT, -Dio.netty.allocator.type=unpooled, -XX:MaxDirectMemorySize=536870912, -Des.path.home=/usr/share/elasticsearch, -Des.path.conf=/etc/elasticsearch, -Des.distribution.flavor=default, -Des.distribution.type=deb, -Des.bundled_jdk=true]
[2021-02-05T16:28:56,526][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [aggs-matrix-stats]
[2021-02-05T16:28:56,527][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [analysis-common]
[2021-02-05T16:28:56,528][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [data-frame]
[2021-02-05T16:28:56,528][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [flattened]
[2021-02-05T16:28:56,529][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [frozen-indices]
[2021-02-05T16:28:56,529][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [ingest-common]
[2021-02-05T16:28:56,529][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [ingest-geoip]
[2021-02-05T16:28:56,530][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [ingest-user-agent]
[2021-02-05T16:28:56,530][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [lang-expression]
[2021-02-05T16:28:56,531][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [lang-mustache]
[2021-02-05T16:28:56,531][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [lang-painless]
[2021-02-05T16:28:56,531][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [mapper-extras]
[2021-02-05T16:28:56,532][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [parent-join]
[2021-02-05T16:28:56,532][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [percolator]
[2021-02-05T16:28:56,532][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [rank-eval]
[2021-02-05T16:28:56,533][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [reindex]
[2021-02-05T16:28:56,533][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [repository-url]
[2021-02-05T16:28:56,534][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [search-business-rules]
[2021-02-05T16:28:56,534][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [spatial]
[2021-02-05T16:28:56,534][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [systemd]
[2021-02-05T16:28:56,535][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [transport-netty4]
[2021-02-05T16:28:56,535][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [vectors]
[2021-02-05T16:28:56,536][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-analytics]
[2021-02-05T16:28:56,536][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-ccr]
[2021-02-05T16:28:56,536][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-core]
[2021-02-05T16:28:56,537][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-deprecation]
[2021-02-05T16:28:56,537][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-graph]
[2021-02-05T16:28:56,538][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-ilm]
[2021-02-05T16:28:56,538][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-logstash]
[2021-02-05T16:28:56,538][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-ml]
[2021-02-05T16:28:56,539][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-monitoring]
[2021-02-05T16:28:56,539][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-rollup]
[2021-02-05T16:28:56,540][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-security]
[2021-02-05T16:28:56,540][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-sql]
[2021-02-05T16:28:56,540][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-voting-only-node]
[2021-02-05T16:28:56,541][INFO ][o.e.p.PluginsService     ] [localhost] loaded module [x-pack-watcher]
[2021-02-05T16:28:56,542][INFO ][o.e.p.PluginsService     ] [localhost] loaded plugin [ingest-attachment]
[2021-02-05T16:29:03,884][INFO ][o.e.x.s.a.s.FileRolesStore] [localhost] parsed [0] roles from file [/etc/elasticsearch/roles.yml]
[2021-02-05T16:29:05,054][INFO ][o.e.x.m.p.l.CppLogMessageHandler] [localhost] [controller/2027] [Main.cc@110] controller (64 bit): Version 7.4.0 (Build 11d694e7bae395) Copyright (c) 2019 Elasticsearch BV
[2021-02-05T16:29:06,042][DEBUG][o.e.a.ActionModule       ] [localhost] Using REST wrapper from plugin org.elasticsearch.xpack.security.Security
[2021-02-05T16:29:06,776][INFO ][o.e.d.DiscoveryModule    ] [localhost] using discovery type [zen] and seed hosts providers [settings]
[2021-02-05T16:29:08,603][INFO ][o.e.n.Node               ] [localhost] initialized
[2021-02-05T16:29:08,604][INFO ][o.e.n.Node               ] [localhost] starting ...
[2021-02-05T16:29:08,855][INFO ][o.e.t.TransportService   ] [localhost] publish_address {<IP_ADDRESS>:9300}, bound_addresses {[::1]:9300}, {<IP_ADDRESS>:9300}
[2021-02-05T16:29:08,937][WARN ][o.e.b.BootstrapChecks    ] [localhost] the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
[2021-02-05T16:29:08,947][INFO ][o.e.c.c.Coordinator      ] [localhost] cluster UUID [D2pHZG_wSSGiDjeaJYyQHw]
[2021-02-05T16:29:08,964][INFO ][o.e.c.c.ClusterBootstrapService] [localhost] no discovery configuration found, will perform best-effort cluster bootstrapping after [3s] unless existing master is discovered
[2021-02-05T16:29:09,255][INFO ][o.e.c.s.MasterService    ] [localhost] elected-as-master ([1] nodes joined)[{localhost}{J8sHnQmrRGOb1UTHzE0PYg}{SHc8daXDR-yjpRGtJkh-cg}{<IP_ADDRESS>}{<IP_ADDRESS>:9300}{dilm}{ml.machine_memory=8330313728, xpack.installed=true, ml.max_open_jobs=20} elect leader, _BECOME_MASTER_TASK_, _FINISH_ELECTION_], term: 5, version: 27, reason: master node changed {previous [], current [{localhost}{J8sHnQmrRGOb1UTHzE0PYg}{SHc8daXDR-yjpRGtJkh-cg}{<IP_ADDRESS>}{<IP_ADDRESS>:9300}{dilm}{ml.machine_memory=8330313728, xpack.installed=true, ml.max_open_jobs=20}]}
[2021-02-05T16:29:09,369][INFO ][o.e.c.s.ClusterApplierService] [localhost] master node changed {previous [], current [{localhost}{J8sHnQmrRGOb1UTHzE0PYg}{SHc8daXDR-yjpRGtJkh-cg}{<IP_ADDRESS>}{<IP_ADDRESS>:9300}{dilm}{ml.machine_memory=8330313728, xpack.installed=true, ml.max_open_jobs=20}]}, term: 5, version: 27, reason: Publication{term=5, version=27}
[2021-02-05T16:29:09,595][INFO ][o.e.h.AbstractHttpServerTransport] [localhost] publish_address {<IP_ADDRESS>:9200}, bound_addresses {[::1]:9200}, {<IP_ADDRESS>:9200}
[2021-02-05T16:29:09,600][INFO ][o.e.n.Node               ] [localhost] started
[2021-02-05T16:29:09,971][INFO ][o.e.l.LicenseService     ] [localhost] license [67053363-ec49-4432-b9de-a422c3607f9a] mode [basic] - valid
[2021-02-05T16:29:09,972][INFO ][o.e.x.s.s.SecurityStatusChangeListener] [localhost] Active license is now [BASIC]; Security is disabled
[2021-02-05T16:29:09,997][INFO ][o.e.g.GatewayService     ] [localhost] recovered [0] indices into cluster_state

Also check systemctl status onlyofficeIndex and it's log for errors. Try to restart it. Run this curl http://localhost:9200/_cat/indices.


Rewrite in Laravel

See https://flexisourceit.com.au/resources/blog/information-technology/8-reasons-why-php-for-web-development-is-still-the-best/

@radmorecameron https://dev.to/verystrongfingers/part-3-100-eloquent-sucks-1k45


Hexadecimal display of a 32-bit value should pad with zeros

Issue Type: Bug
Open the watch window and use the ",x" suffix to display a 32-bit variable as hexadecimal. Note, for example, that 25165824 displays as 0x1800000 rather then 0x01800000.
This would make it easier to compare values in the watch window if the hex output was a consistent length.
VS Code version: Code 1.27.2 (f46c4c469d6e6d8c46f268d1553c5dc4b475840f, 2018-09-12T07:11:15.873Z)
OS version: Linux x64 3.10.0-862.2.3.el7.x86_64

System Info

Item
Value

CPUs
Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (8 x 3700)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: unavailable_softwarevideo_encode: unavailable_softwarewebgl: enabledwebgl2: enabled

Load (avg)
0, 0, 0

Memory (System)
31.21GB (19.90GB free)

Process Argv
/usr/share/code/code

Screen Reader
no

VM
0%

VS Code does not format any values. Please file issue against the debugger extension you are using.


Added icon for IP Addresses in Available devices

Related issues
Fixes #19
Description

Added a cast icon before IP Addresses. I have added the feather icon package in the project for future use as well.
Also removed an extra instance of the IP Address list which caused the second list of the same IP Addresses.

Output

give @ritvij14 25 points


Illogical heading structure - DAC_Illogical_Heading_Structure_Issue1

On page 52 of the report DAC have identified an issue with ID DAC_Illogical_Heading_Structure_Issue1 that relates to skipped heading levels that exist on the introduction page. While this page is not actually part of the pubic facing service, it does reflect an issue that will grow with time if we don't do something soon.
We can fix this by ensuring that reusable components which editors can freely place within a page:

Allow the editor to select an appropriate heading level
Are provided with hint text that explains to editors the importance of a meaningful heading level

@JamesWChan has started to explore this but it may be that additional advice and support is needed under the Wagtail specialist contract.
Note: while DAC have identified this as a Level AAA failure I also suspect it may result in other failures under Success Criterion 1.3.1
Why was this not picked up in the in-house testing?
We knew about this issue and that it was only present on this non-service page. I thought we'd asked for this page not to be tested. That said, it is an issue that we knew needed to be fixed.

This has been addressed by allowing editors to select from a range of headings in the Wagtail editorial interface so that the appropriate heading tag is used and doesn't cause the heading structure to break.


Take Working Incorrectly When Used WIth OrderByDescending

Given the following query:
this.Context.Media
  .OrderByDescending(m => m.Created)
  .Skip(0)
  .Take(60)
  .Include(m => m.Files);

I'm getting 3 files for one piece of media, and 0 for another. There should be 3 for each (there are only two pieces of media).
However if I do this:
this.Context.Media
  .OrderBy(m => m.Created)
  .Skip(0)
  .Take(60)
  .Include(m => m.Files);

Works fine (aside from the files being in the wrong order). Generated SQL looks fine, it matches in both ways aside from "DESC" being removed when doing "OrderBy".
Additionally applying "OrderByDescending" after Skip/Take appears to fix the issue, not sure if this is intentional.

@StrangeWill Which version of EF Core are you running?

@anpete Terribly sorry about that... that's an obvious should-be-here thing.
EntityFramework.Core 7.0.0-rc1-final

Confirming this is fixed in RC2.


feat(api-key-service): add runtime migrations

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#260  👈
#256
#255
#230
main

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

Join @jakim929 and the rest of your teammates on  Graphite


MacPorts jupyter expects versioned command names

I have read https://github.com/JuliaLang/IJulia.jl/issues/453 because I am getting a similar error when trying to use my macports installation as my jupyter environment in julia.
This problem crops up in trying to execute the script with the macports jupyter installation in OS X 10.9. In reference to #453, I avoid using pip with macports.
I think the following is why (but it could be much more complicated than I realize):
https://trac.macports.org/ticket/50608
If I could set my ENV["JUPYTER"} properly this would save me well over half a gigabyte of miniconda and auxiliary software in the .julia directory.
I've deleted ~/.julia until I know that installing the full IJulia package is absolutely necessary.
Edit to add: It occurs to me that I could try adding ipython and jupyter to the Apple python2.7 installation, but I can't rightly recall just how large that will be in comparison to the standard IJulia package which seems to duplicate several hundred megabytes of dylibs in running the miniconda or whatever other reason there might be for doing that.

See this comment about how to set your PATH so that the jupyter command works.
Alternatively, if you want to provide a PR (patch) to the IJulia build script, so that if you supply jupyterX.Y then it looks for jupyterX.Y kernelspecX.Y etcetera for MacPorts, that would be welcome.

That my current macports jupyter won't support IJulia has deeper roots than I thought: I don't think a simple patch to the build script would fix what's wrong, there, even if I had a clue how to go about that business.
My macports jupyter executable does not even list kernelspec as one of its available subcommands. This is odd, because that macports ticket I referenced leads off with a probe for subcommands that does include it. As far as I know, installing kernels is way above my paygrade, and that is why the pre-cooked (brewed?) IJulia installation may be the only way to go for me.
Interestingly, I also had a look inside my sage installation, which is also full of python and boasts its own notebook interface. This interface is heavily customized, probably for the same reasons that IJulia's is. There are executable jupyter executables (with unversioned filenames, even!) and a kernelspec is visible, but when I stick that in as my ENV["JUPYTER"] path, the version of jupyter that gets returned is 0.0.0, which is too low to suit the IJulia build script. Even though the sage jupyter version I have is actually 4.x, using it seems also (sadly) unworkable from where I sit.
Someday, when the world improves, we won't be duplicating gigabytes of Python to install several different math packages. It's not that we lack disk space; the situation just shouts wastage. Maybe that improved world will be Linux. Sorry to have troubled you, and thanks for my little sniff of the rarefied air of a big software project.
PS: This news might require another change to the thread title, but I'll leave that to the experts, too.

@dyne2meter, according to the linked thread, if the command is jupyter3.4, then kernelspec is jupyter3.4 kernelspec3.4.  Potentially our build script could check for this.
(Nowadays, a lot of people have switched from macports to homebrew.)

I'm not sure when things changed with Macports' Jupyter, but this now works:
$ jupyter-3.6 notebook
So, now IJulia can work with Macports' Jupyter:
$ Julia
julia> ENV["JUPYTER"] = "jupyter-3.6"
julia> Pkg.add("IJulia")

Great!


Adding delegate dropdown

Instead of writing the delegate name, show a dropdown menu with all registered delegates to choose from.

+5


Release v2.19.1

Bumps both bugsnag-android and bugsnag-cocoa to latest versions.

It would be nice to have new release with this PR

@AleksandrChernyavenko sorry for the delay, we had to wait for further end to end tests (that are not on CI) to complete.
This has now shipped.

@bengourley Thank you!


consider ratelimit sleep in metric calculations

if there is a ratelimit.sleep_duration key present in env then the
value of this will be used to calculate actual swift service time
and ratelimiting statistics. existing full duration of request and
any artificial delay are stored under total_duration and total_srt

lgtm- i'm not all that concerned with my comment. i'll approve it if whale says not to worry about it

well i dunno, when we're doing statsd, we're not really reporting any one time series in relation to another. so its just a new number to look at rather than anything that impacts on the duration timer.  so %sratelimit.%s:%d|ms|@%s would be a new time series like stats.servers.proxy1-z1.ratelimit.obj.put.201 showing the min/max/avg time spent in ratelimit sleep - i dont know if its better to just not send a value, but then statsd should keep sending aggregated values to graphite every x seconds after it sees a metric the first time. and you can always filter the series in graphite i guess, to see the avg ratelimit when actually ratelimiting.
i think its going to be mostly 0, but like we have in IAD now I think over half the reqs have some sleep happening.

ok yeah tested on saio with graphite and varying levels of concurrency and ratelimit settings and the stuff we talked about yesterday, looks like its showing reasonable values and we can at least get insight into ratelimit behaviour on hosts while also ignoring self inflicted impact on first byte timers


doc/ansible/project_layout.md: fix Ansible Galaxy link

Description of the change: fix Ansible Galaxy reference link
Motivation for the change: page seems to have been moved to https://docs.ansible.com/ansible/latest/reference_appendices/galaxy.html

/test e2e-aws-go


Improved Rust attributes

Rust attributes with nested brackets are currently not correctly highlighted.
For example, in
#[foo(bar = [baz, qux])]

the attribute is only highlighted until the first closing square bracket.
I think this should fixed with these changes.

Can you please add a test for this? There's a rust example file, it should be sufficient to add one line with an attribute like that there.

You mean like that?
Unfortunately I'm not familiar with pygments so I'm not exactly sure what I'm doing here...

Yeah, adding it to the example file is sufficient, thanks!

i just stumbled over this problem as well. as far as i can see, the diff needed to make the rust tests pass is
diff --git a/tests/examplefiles/rust/eval.rs.output b/tests/examplefiles/rust/eval.rs.output
index 186a7c0c..dd0f7997 100644
--- a/tests/examplefiles/rust/eval.rs.output
+++ b/tests/examplefiles/rust/eval.rs.output
@@ -218,7 +218,10 @@
 '/// Represents a value (either 16-bit or 32-bit) at runtime.\n' Literal.String.Doc

 '#['          Comment.Preproc
-'derive(Clone, PartialEq, Eq, Debug)' Comment.Preproc
+'derive'      Comment.Preproc
+'('           Comment.Preproc
+'Clone, PartialEq, Eq, Debug' Comment.Preproc
+')'           Comment.Preproc
 ']'           Comment.Preproc
 '\n'          Text.Whitespace

aka the #[derive(..)] line is now looked at in more detail as well, just like the initial example.

Actually, why are we tracking ( and ) pairs? The only thing that's relevant is nested [ and ]...

For highlighting purposes it should indeed be sufficient to look at square brackets.
Should I change the code accordingly?

That would be nice, and it will also reduce the number of individual tokens.

Thanks!


Updated to API 4.0.0

📋 What's this pull request about?
This PR adds support for API 4.0.0 and this has been tested and works as expected.
🔧 Is this pull request related to an issue?
No.

Thanks for contributing 👍 I'm merging this into the 'pm4' branch for now as v4 is still in beta, will be merged to master when v4 is officially released. I've just changed the event cancel calls, $event->isCancelled() doesn't do anything but returning if the event is cancelled or not, the correct function call to cancel the event is $event->cancel().


added alternative hands to 4.0

this PR adds the new hand models to the 4.0 dev branch
added highpoly and lowpoly version of hand models
added skin materials
added 36 Hand Poses
The hands use a Animation Library that was extracted from a dummy model, both hands share the same library as the naming of the skeletal bones is the same, this way new poses need to be made only once in blender for one hand and once added to the pose library they can be used by both hands

The fingers are having a little difficulty with the pinky distorting when fully closed - it actually invert and dents in:

I Just checked and it also happens on the Godot 3 versions as well. It just seems like it's more obvious due to the lighting differences, and I can't find any differences in the lighting settings. The weird edge-shadows are the problem.

Also could you get ghost-hands working in the climbing demo. This involves:

edit /scenes/climbing_demo/materials/ghost-hand.tres
Expand out the material in "Next Pass"
In the Next Pass material set the albedo to /addons/godot-xr-tools/hands/textures/glove_caucasian_green_camo.png
Save and apply the material to both hands Hand Material Override

aye, heading to work.. gonna do that later in 15h
and over the weekend or so am gonna do the suggested changes by @BastiaanOlij
(the renaming of all bones etc. will mean a complete reexport of the hands and animations for both 3 & 4)

@BastiaanOlij
via discord you mentioned that u want me to rename the bones and add additional for Potential handtracking as well. Now i want to clarify if you are aware about the bone orientation issue or requirements for handtracking?
Because Julian mentioned that the bones need to be oriented the same way as the ones from the valve handmodels.
If i do this, it will make it almost impossible for the evryday Joe"dev" to rigg new hand Models with that kind of skeleton and it will make the current poses unuseable as a new bone orientation would mean that new poses would need to be made.

@BastiaanOlij via discord you mentioned that u want me to rename the bones and add additional for Potential handtracking as well. Now i want to clarify if you are aware about the bone orientation issue or requirements for handtracking?
Because Julian mentioned that the bones need to be oriented the same way as the ones from the valve handmodels.
If i do this, it will make it almost impossible for the evryday Joe"dev" to rigg new hand Models with that kind of skeleton and it will make the current poses unuseable as a new bone orientation would mean that new poses would need to be made.

Yeah OpenXR is a bit weird here as it doesn't have a rest pose so we try and manage the delta movement ourselves. If it doesn't work by just renaming the bones, I wouldn't worry about this right now. This is something to worry about for the future ifit even can be done.

preparing commit that replaces the lowpoly mesh with a fixed version since the previous one had issues as it had too few vertices
and at the same time am restructuring, placing all prefab scenes in corresponding folders for high/lowpoly to distinguish further


updateState no longer called when changing URL query parameter

Describe the bug
I have a BeamLocation that overrides updateState in order to notify some widgets down the tree when a query parameter in the URL has changed.  In 1.3.0 this worked perfectly.  However, when I upgraded to 1.4.0 this stopped working.  After a bit of digging I found that "updateState" is no longer being called when the query parameter changes, thus preventing me from notifying my child widgets that the parameter has changed.  I have a hunch this is related to change #475.  Unfortunately I don't have much time to dig further and have rolled back to 1.3.0.
Beamer version: 1.4.0
To Reproduce
Steps to reproduce the behavior:

Create a BeamLocation which overrides "updateState"
Go to that URL with a query parameter:  /#/?date=2022-02-28
Print or put a breakpoint in the overridden updateState method
Change the query parameter value:  /#/?date=2022-02-27
Observe the print statement/breakpoint is not triggered

Expected behavior
updateState would be called when the query parameter changes
Desktop (please complete the following information):

OS: macOS
Browser: Chrome
Version: 98

Hey @ryanaston
Thanks for the detailed report.
I will try to reproduce and will let you know when v1.4.1 with a fix is available. At first glance, it shouldn't be due to #475 because query is a part of RouteInformation.location, but we'll see.

Hey @ryanaston Thanks for the detailed report.
I will try to reproduce and will let you know when v1.4.1 with a fix is available. At first glance, it shouldn't be due to #475 because query is a part of RouteInformation.location, but we'll see.

Was this issue addressed in 1.4.1?

Hey @ryanaston
sorry for late response.
Thanks for reminding me of this as I clearly forgot. I managed to find the culprit and fix it - you can see in the commit what was wrong. It was a bit tricky to test it (I'll need to restructure the tests some time soon...), but it should work now.
Thanks again for your patience.


A value of type 'Iterable' can't be returned from the function '_restaurantsFromJson' because it has a return type of 'List'.

Hello Dart Team.
First of amazing work the language and framework are tops.
I am however facing a problem I am unable to debug.
I am writing a restaurant app, and have a function, that returns all JSON gotten from the API of each restaurant.
Please check it out:
List _restaurantsFromJson(Map<String, dynamic> json) {
final List restaurants = json["restaurants"];
return restaurants.map((e) => Mapper.fromJson(json));
}
I created a Mapper helper function that does this:
import 'package:restaurant/src/domain/restaurant.dart';
class Mapper {
static fromJson(Map<String, dynamic> json) {
return Restaurant(
id: json['id'],
name: json['name'],
type: json['type'],
displayImageUrl: json['image_url'] ?? '',
location: Location(
longitude: json['location']['longitude'],
latitude: json['location']['latitude']),
address: Address(
street: json['address']['street'],
city: json['address']['city'],
county: json['address']['county']),
);
}
}
But I get a wierd error, please help I get a linter alerting me that:
A value of type 'Iterable' can't be returned from the function '_restaurantsFromJson' because it has a return type of 'List'.
Please help I don't know what I'm doing wrong. Considering I just switched to beta from dev channel, where I had a similar function that still works.
Please help.
Thanks In Advance.

return restaurants.map((e) => Mapper.fromJson(e)).toList();
This actually worked for me I didn't need to post here, thank you.