iOS 15 fails to fetch products.

Please use Discussion board if you want to get some help out of it. Please report issue if there is a bug.

Version of react-native-iap
react-native-iap 7.3.0 (tried in 7.5.0 also)
Version of react-native
react-native: 0.64.0
Platforms you faced the error (IOS or Android or both?)
iOS, version 15.0
Expected behavior
getSubscriptions call should populate subscriptions  (useIAP)
Actual behavior

getSubscriptions will never trigger callback.
In the log I am getting ->  Background Task 88 ("SKProductsRequest"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

Looks like an iOS 15 related issue.
Tested environment (Emulator? Real Device?)
Real Device
Steps to reproduce the behavior

Install app in the device which already has an expired device (Not sure about fresh install)
currentPurchase will get populated with older purchase details.
Quit the app and try again. No product will be fetched, getSubscriptions will continue forever.
At this time TestFlight app turns into renew status.

Refer threads

https://developer.apple.com/forums/thread/691663?login=true
https://developer.apple.com/forums/thread/688416?login=true

Any luck as i am facing the same issue in iOS 15 @andresordonezfm @arshad-slate  ?

Definitely the same for me.
I can't get available purchases and subscriptions from getSubscriptions and getAvailablePurchases.
What is the main reason? react-native-iap version problem or any other things?
Needed help!

@darkhorse-coder I was reading about the problem in the apple forums, apparently it is a problem with iOS 15.
Check this
691663
688416
688416

I doubt this is a test flight issue. Please share any news if anyone solve the problem.

Does it work on iOS 15.4 for you, guys?

The promise is not resolving at all.
import { useIAP } from 'react-native-iap';

getSubscriptions(['MONTHLY']).then(() => {
   console.log('Done');
}).catch(() => {
   console.log('Error')
});

Done or Error is never logged.

Does not work for me on TestFlight with iOS 15.4 and React Native 0.66.0

Please help us test the alpha version of 11.0.0 Migrates to storekit 2 that targets ios 15 and above


Page Redirects no longer work

Page Redirects as documented here are no longer working.
For example, a redirect exists that maps /getting-started.html to /getting-started/overview.html. Visiting docs.smartthings.com/en/latest/getting-started.html does not redirect; it simply 404's.

Exact Redirects don't seem to be working for me either.

The same for http://docs.platformio.org :cry:
http://docs.platformio.org/en/latest/librarymanager/index.html should map to http://docs.platformio.org/en/latest/userguide/lib/index.html

:+1: - also does not work here for https://neos.readthedocs.org/

As our docs state, redirects only work on 404's. All of the pages listed above resolve, and so won't redirect.

In my case, the source page definitely does not exist.  I get a 404 for http://docs.haskellstack.org/en/stable/faq.md, which should redirect to faq.html.
I have this redirect set up:

Page Redirect: /faq.md -> /faq.html

However, I noticed something interesting: http://docs.haskellstack.org/faq.md does redirect to http://docs.haskellstack.org/en/stable/faq.html.

@ericholscher My pages don't exist either. Redirects that used to work no longer work.
For example:

Page Redirect: introduction/smartthings-architecture.html -> architecture/index.html
Page Redirect: introduction/groovy-the-smartthings-programming-language.html -> getting-started/groovy-basics.html
Page Redirect: smartapp-web-services-developers-guide/implementation.html -> smartapp-web-services-developers-guide/tutorial-part1.html

And we have many more redirects. These pages do not exist.
Prior to this issue being opened, these redirects worked correctly. Now they end up 404'd like this.
If there's something we can do to get this working again please let us know - we have a few top google hits that are now getting 404'd - not good.

Can this be re-opened?

If someone would like to submit some test cases that show this failing, it would be a great help, and move it up on our priority list of things to fix. https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/tests/test_redirects.py#L181 is the place to start looking.

It looks to me like test_redirect_keeps_version_number should already be testing this case, but it is passing.  Here's something I don't understand: why does the test contain this fragment?
        with patch('readthedocs.core.views._serve_docs') as _serve_docs:
            _serve_docs.side_effect = Http404()

If I remove that fragment, I get this test failure:
rtd_tests/tests/test_redirects.py:239: in test_redirect_keeps_version_number
    self.assertEqual(r.status_code, 302)
E   AssertionError: 200 != 302

Why would it be returning a 200 status when the page doesn't exist, and why does the test have to force a 404?

Hi All,
I also have failing redirects, even when I get 404s. My question is what determines the 404? The current version of the docs being viewed, the stable or latest version? Others? The pages exist for some branches and not others as things move around.

FWIW, I experience the same problem on docs.graylog.org.
These are my configured rules:

While http://docs.graylog.org/en/2.0/pages/users_roles.html does exist (and won't be redirected), http://docs.graylog.org/en/2.0/pages/foobar.html does not and should be redirected to http://docs.graylog.org/en/2.0/pages/users_and_roles.html if I understand the redirect feature correctly.
Unfortunately, readthedocs.org still delivers the 404 page:
$ curl -i http://docs.graylog.org/en/2.0/pages/foobar.html
HTTP/1.1 404 Not Found
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 26 Apr 2016 13:48:33 GMT
Content-Type: text/html
Content-Length: 177
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: sessionid=h64oqdtwdts50rr6jyh8cn1i69kfllv0; Domain=readthedocs.org; expires=Tue, 10-May-2016 13:48:33 GMT; httponly; Max-Age=1209600; Path=/

<title>404 Not Found</title>

404 Not Found

nginx/1.4.6 (Ubuntu)

I ended up working around this by including static HTML files that do meta refresh/javascript redirects, such as this one.  I'm using mkdocs and include them in the extra_templates: section of mkdocs.yml (not sure how to do it with Sphinx).  Would be much better if proper HTTP redirects worked, though.

I think the problem here (or at least part of it...) is that the slash at the beginning of the URL is required. The 'Outcome' panel at the bottom of the form wrongly adds an extra slash, which will inevitably prompt users to correct it by removing the slash from their input fields:

(I notice @joschi's screenshot above is missing the leading slashes, which is probably why those redirects aren't working...)

Unless anyone has any information to suggest otherwise, I believe that #2380 fully accounts for the problems described here, and so this can be closed now that the fix (#3811) is merged.

@gasman thanks for following this! I think the same, this was the problem as #2380. I'm closing this, if anyone is having this problem, feel free to ask to reopen this issue or create a new one with more information.


Dan table css

Can one of the admins verify this patch?

[Current coverage][cc-pull] is 79.64%

Merging [#34][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master        #34   diff @@
==========================================
  Files           112        112
  Lines          7123       7123
  Methods        1535       1535
  Messages          0          0
  Branches       1041       1041
==========================================
  Hits           5673       5673
  Misses         1450       1450
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [38f1271...6ffd401][cc-compare]
[cc-base-branch]: https://codecov.io/gh/voyagersearch/navigo/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/voyagersearch/navigo/compare/38f1271ff369c1645ff5ba0e5df836208467c579...6ffd401ac2c0a7311f9eac14fb9372cc2e794553
[cc-pull]: https://codecov.io/gh/voyagersearch/navigo/pull/34?src=pr


docs: Clarify H2 database caching strategy

Description of Change

Fixes a few typos for repository for RetireJS
Attempts to clarify the intent of the first H2 DB caching strategy

I understand this is about caching JUST the H2 DB alone, not the entire data directory
Theoretically, I think you could use the single node approach caching either the H2 DB alone OR the entire data directory, so it's possible there needs to be some rewording or re-titling of the strategies here
It's possible there are actually three strategies here?

Caching H2 DB alone with single node update
Caching entire data dir with single node update
Caching entire data dir with multiple/all node update (all nodes can upload archive)

Is the intent of the two strategies to primarily focus on

single node vs multiple node update, OR
to focus on whether the H2 DB vs. the entire data dir including cache is archived (and other files such as publishedSuppressions.xml, jsrepository.json etc)

?
I'll help reword/adjust to meet your intention :-)

I was trying to focus on single node update vs multiple node updating. If you scan with autoupdate off and you don't cache the retire js JSON file, etc. there could be problems.

OK, in that case do we want to specifically recommend that users are best to archive the entire data directory (including cache and oss_cache subfolders) in both single node and multi-node strategies (to keep it simple for them)?
Or are there circumstances in which you would not want to include the cache directories (perhaps when they become "build specific" and might actually break ODC in some way?) so we can possibly give users some guidance as to how to make the decision on what to include in the archive. Zipping an entire directory is obviously easier than filtering it, unless we can give more specific guidance on what you might need to filter without constraining the future development too much by creating an implicit "contract" on how the data dir is used and structured.

likely just zipping the entire data directory is best. If you use a single update node - there won't be anything in the cache if the only thing it is doing is updating the db...

OK, thanks. How does that read to you? Hope I have covered your intent.


Use unicorn

Hi Dan,
There wasn't a specific problem, I had just read this from http://unicorn.bogomips.org/unicorn_rails_1.html and thought I would follow the suggestion:
Rails 3 users are encouraged to use unicorn(1) instead of unicorn_rails(1). Users of Rails 1.x/2.y may also use unicorn(1) instead of unicorn_rails(1).
A small change for sure.  Thanks anyway!  :)
Chip

Merged, thanks!


include center parameter in th.ftomb

hey timo --
these patches are excellent, thanks for making them.
i noticed that the "center" parameter has been omitted from the routepass and patcherargs objects within th.ftomb. i assume that because center is a configurable parameter in th.scala and in the gen patcher within th.ftomb, you'll also want it to be on the parent level of th.ftomb.
simple fix i believe... just [patcherargs @hires 0 @base 440 @center 69] and [routepass hires base center].
thanks,
philip

Hey! Thanks for suggesting. The main reason I omitted it as because [ftom] also only has an @base attribute. But of course no reason to include the @center as well if it is of any use. So added in 14f4f8e5d2005622fd8cb105b2074ff73e598548


Permissions error with Mongo Authentication

Waterline version: 0.12.13
Node version: v6.10.3
NPM version: 3.10.10
Operating system: Ubuntu 16.04.2 LTS

I am attempting to utilize MongoDB authentication for my database. The application lifts as it should, but when I go to insert a new line within the database, I receive this error:
Sending 500 ("Server Error") response:
 Error (E_UNKNOWN) :: Encountered an unexpected error
MongoError: not authorized on quiq-math to execute command { insert: "user", documents: [ { firstName: "Doug", lastName: "Niccum", email<EMAIL_ADDRESS>encryptedPassword: "XXXXXX", stripeCustomerId: "placeholder", subscriptionDate: new Date(1532533782121), lastLoggedIn: new Date(0), createdAt: new Date(1500997782152), updatedAt: new Date(1500997782152), _id: ObjectId('597768963a2d172d1a41b34f') } ], ordered: true, writeConcern: { w: 1, fsync: false, wtimeout: 0 } }
    at Function.MongoError.create (/var/www/html/node_modules/mongodb-core/lib/error.js:31:11)
    at commandCallback (/var/www/html/node_modules/mongodb-core/lib/topologies/server.js:1206:66)
    at Callbacks.emit (/var/www/html/node_modules/mongodb-core/lib/topologies/server.js:119:3)
    at Connection.messageHandler (/var/www/html/node_modules/mongodb-core/lib/topologies/server.js:371:23)
    at Socket.<anonymous> (/var/www/html/node_modules/mongodb-core/lib/connection/connection.js:301:22)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at TCP.onread (net.js:547:20)

This is what my production environment configuration looks like:
mongoProd: {
      adapter: 'sails-mongo',
      host: 'XX.XXX.XXX.XXX',
      port: XXXXXX,
      username: 'QuiqMath',
      password: 'XXXXXXX',
      database: 'quiq-math',
      authenticationDatabase: 'quiq-math',
      schema: true
    }

I have created a Mongo user that looks like this:
{
	"_id" : "quiq-math.QuiqMath",
	"user" : "QuiqMath",
	"db" : "quiq-math",
	"roles" : [
		{
			"role" : "readWrite",
			"db" : "quiq-math"
		}
	]
}

I can verify that my Sails application can connect to a remote database server, as the lift process does not fail, so it is not a firewall issue. I can also verify that credentials provided above do in fact work as I can connect to the database and insert new records via Robo 3T.
Are there known issues with the authentication database attribute?

Hi @dniccum -- can you try authSource instead of authenticationDatabase?


Update repository links across repository

Closes #3252
I updated every link in the repository to point to the current repository name, rather than the old repository name.

Thanks for the PR! Can you sign the CLA?

Unfortunately, no. I don't want to share my email publicly.

No worries, we understand!

Sorry

Just so you know, I just used the find/replace feature in vscode to replace the old URL with the new one.


git push flynn master freezes on local instance

Hi,
I have setup flynn on my local machine with the vagrant method. Everything seems to be really simple for deploying an app using flynn.  But when I am deploying an application from the examples, when I push the code to flynn using
git push flynn master
The command line freezes when it tries to  install the environment, be it in the given example go application or the example phthon application.
root@Shaurya-Z510:/home/xuryax/Desktop/work/flynn-go/python-flynn-example# sudo git push flynn master
Counting objects: 23, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (23/23), 3.19 KiB | 0 bytes/s, done.
Total 23 (delta 5), reused 0 (delta 0)
-----> Building pexample...
-----> Python app detected
-----> Installing python-3.6.1

Not sure why this is happening.

How long did you wait before determining that it had "frozen"? is there any network activity? Usually this is the point where Python is downloaded.

Around 45 minutes. I figured it would take time, but I don't think it should freeze for 45 minutes for python.Could not see any network activity either.

It does seem to download. The network activity spikes  up when I run the command. A 6-7  minutes it comes down back. Probably download is completed by this time. But even if it is installing after this, it should not take this long.

I dont know what the issue was. Restarted a couple of times. Same steps  works  good now.


Azure CLI can't be installed in latest Pulumi docker image

What happened?
The docs state that the Debian images are based on the buster release, but that no longer appears to be the case; here's the release info for the current image:
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

This makes it impossible to install the azure CLI in the image. Attempting to install from Microsoft's package fails with this error:
The following packages have unmet dependencies:
 azure-cli : Depends: libffi7 (>= 3.3~20180313) but it is not installable
             Depends: libssl1.1 (>= 1.1.1) but it is not installable
E: Unable to correct problems, you have held broken packages.

This happens even when setting "AZ_REPO=bullseye"  per Microsoft's docs: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt
Expected Behavior
az CLI should be installable in Pulumi Docker image
Steps to reproduce
https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt
Output of pulumi about
$ pulumi about
CLI
Version      3.72.2
Go Version   go1.20.5
Go Compiler  gc
Plugins
NAME                      VERSION
azure-native              1.103.0
azuread                   5.38.0
kubernetes                3.29.1
kubernetes-ingress-nginx  0.0.10
python                    unknown
Host
OS       debian
Version  12.0
Arch     x86_64
This project is written in python: executable='/usr/local/bin/python3' version='3.9.17
'
Backend
Name           pulumi.com
URL            https://app.pulumi.com/durist
User           durist
Organizations  durist, UCAR
Dependencies:
NAME                             VERSION
pip                              23.1.2
pulumi-azure-native              1.103.0
pulumi-azuread                   5.38.0
pulumi-kubernetes-ingress-nginx  0.0.10
setuptools                       68.0.0
sshkey-tools                     0.10.1
wheel                            0.40.0
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hey, I'm checking with the author of the commit for some more context around the change, but it looks to be introduced in this change:
https://github.com/pulumi/pulumi-docker-containers/commit/cdb8187a21aa58d5de8d8b4c1c395466d61d7c3a

This was fixed in https://github.com/pulumi/pulumi-docker-containers/pull/214


Remove Advance linux-tests-pass and all-tests-pass branches

[x] remove Advance linux-tests-pass and all-tests-pass branches (a0794bef26c2a1f95492e4d154797867dd9607f4)

Comments
It's failing and I don't think it has any practical use really.
Issue Number

We could consider removing the other caller of the script

Yes. The whole windows.yml needs to be refined, as it tries to get binaries from hydra.

Yeah, the buildkite step mentions branches windows-tests-pass and all-tests-pass, but they don't even exist anymore.

bors r+


tools: Create output_redirected() context manager.

We may want to get away from writing directly to sys.stdout() in
some situations, such as when being run via git hooks, so
this isolates all the sys.stdout logic to a single context
manager.

Automated message from Dropbox CLA bot
@showell, it looks like you've already signed the Dropbox CLA. Thanks!

I'm going to hold off on merging this until we get to the bottom of today's lint adventure...

This is kind of a complicated patch that was part of a debugging process.  Since the key thing seems to be calling flush() at the right time, I think we might just want to abandon this and put a one-line patch in run_parallel.  pinging @timabbott @christi3k

Yeah, I think that makes sense to me!

(Would be nice to do other cleanups to the script to make it easier to follow, but this change probably isn't the top focus for achieving that goal)

Closing this.

I thought I closed this yesterday.  Trying again.


Create Sendgrid API Key for TUPU profile

[ ] Add SENDGRID_API_KEY to the .env configuration on Netlify
[ ] Set also the DEV_EMAIL_RECIPIENT to an email, so that all test emails before the release, go to a known addres.

SendGrid works only with verified senders.
I have then added a SENDGRID_EMAIL_VERIFIED_SENDER in the .env.local so that:

on a dev machine we can set both SENDGRID_EMAIL_VERIFIED_SENDER and DEV_EMAIL_RECIPIENT to a dev email (personal sendgrid account, verified)
on netlify you can set  SENDGRID_EMAIL_VERIFIED_SENDER to the verified one for tupu, and temporarily DEV_EMAIL_RECIPIENT to yours.

Could you please add SENDGRID_EMAIL_VERIFIED_SENDER to the netlify .env.local?

this can be closed I think


Not including tkinter for standalone exe

Cannot create standalone exe for scripts using tkinter.

nuitka pip installation
Compiler installed VS 2017
output of nuitka generation:

Microsoft Windows [Version 10.0.16299.665]

Jorj@ARRAKIS C:\Users\Jorj\Desktop\test
$ python -m nuitka --portable test.py

Jorj@ARRAKIS C:\Users\Jorj\Desktop\test
$ python -m nuitka --version
0.5.33
Python: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]
Executable: C:\Users\Jorj\AppData\Local\Programs\Python\Python37\python.exe
OS: Windows
Arch: x86_64

Script:

import tkinter
root = tkinter.Tk()
root.bbox()
root.bell()

Output when running test.exe:
Jorj@ARRAKIS C:\Users\Jorj\Desktop\test\test.dist
$ test.exe
Traceback (most recent call last):
 File "C:\Users\Jorj\Desktop\test\test.dist\test.py", line 2, in <module>
  File "C:\Users\Jorj\Desktop\test\test.dist\tkinter\__init__.py", line 2020, in __init__
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
    {C:\Users\Jorj\AppData\Local\Programs\Python\Python37\tcl} C:/Users/Jorj/AppData/Local/Programs/Python/Python37/tcl8.6 C:/Users/Jorj/Desktop/test/lib/tcl8.6 C:/Users/Jorj/Desktop/test/lib/tcl8.6 C:/Users/Jorj/Desktop/lib/tcl8.6 C:/User
s/Jorj/Desktop/test/library C:/Users/Jorj/Desktop/library C:/Users/Jorj/Desktop/tcl8.6.8/library C:/Users/Jorj/tcl8.6.8/library

This probably means that Tcl wasn't installed properly.

Problem goes away when I (e.g.) copy the two directories C:\Users\Jorj\AppData\Local\Programs\Python\Python37\tcl\tcl8.6 and C:\Users\Jorj\AppData\Local\Programs\Python\Python37\tcl\tk8.6 side-by side in a common directory called lib on the same level as test.dist.
What am I missing / doing wrong?

You are missing the PR that adds the code to do it automatically. :-)
Can you try to add that to Nuitka? I think the data files plugin might be a good spot, depending on what is in those directories. Are there DLLs or .PYD files in there?

Thanks for the quick answer, Kay.
I will try the data plugin then.
The directories are pure TCL source - no DLL, no PYD, not even Python source :-)
I always disliked including tkinter as the Python de-facto GUI standard - together with yet another scripting language. It is an architectural uncleanliness ...

@MikeTheWatchGuy Please try without rebooting in the middle of things, you might have an incomplete .dist folder.
@JorjMcKie given the nice reproducer I will try and create a plugin. Is is certain that for Tkinter to be run, code like tkinter.Tk() will be in the source? I will use that as a warning trigger from the plugin, much like done with multi-processing. Please allow for some time though.

Thanks for looking into this anyway!
For the time being, I have built a script that envelops nuitka - so there is no urgency (for me).
To answer your question:
Yes, at some point inside the imported package PySimpleGUI, an object tkinter.Tk() will be created.
But I think it would perfectly be adequate to request that an explicit plugin name is given - e.g. "tk-plugin" in analogy to the qt-plugin.
What needs to happen then is the creation of a folder named lib at the same level as the .dist folder of the compiled script. This lib folder must contain the two sub folders os.path.join(sys.exec_prefix,"tcl", "tk8.6") and os.path.join(sys.exec_prefix,"tcl", "tcl8.6") (valid at least for Windows Py 3.4 thru 3.7, both bitnesses).
I am in the process of researching

how this can be achieved using the nuitka plugin feature
how volatile this information is, WRT to Python versions and, of course, platforms. What I already know: the 2 directories are named tcl8.5 and tk8.5 in Python 2.7 ...

As a reference, this is the script that I am working with currently:
make-exe.zip
In it, I am assuming that compilation results go to a sub folder of the script's one (called compiled). Also - for several more to-be-compiled scripts - I am xcopying the .dist content over to a folder with the fixed name bin. If I am not too wrong, nothing bad can happen copying all .dist content over each other in that same folder bin.
The advantage being: it can then be distributed as a folder of installation binaries covering more than just one single EXE.

Thanks for specifying that, very nice. And yes, you are free to rename the ".dist" folder to anything of your liking.
Multi-binary distribution has not really been explored by me, but in my thinking, copying them all into one should just do.

:-)
I have been testing this for half a dozen scripts now: whatever their .dist folders are, I am "xcopying" that content over to the bin folder with xcopy /E/S/Y ....
So far it is working just fine.

Multi-binary distribution has not really been explored by me, but in my thinking, copying them all into one should just do.

One possible way to allow multi-binary distribution would be using nuitka to compiling/freezing pip freeze packages at once before compiling any executables. So for instance, app1->{package1, package2, package3}, app2->{package1, package2}. By compiling/factoring out package1/package2 you're saving nuitka to compile heavy packages more than once for those apps.

Good point. In distutils world, if you have a package, then an extension module with it will be created in the wheel. Currently for entry points, it is not having something that compiles them. Also from my experience, pip installing a wheel ignores the entry points you provide and creates new ones anyway.
That however is only usable for cases, where there is a target Python installation to begin with. But installing these wheels to a virtualenv, an then making standalone compilation of all the entry points, seems workable. However, I would much rather first have distutils integration work flawlessly before basing anything else on it.
Clearly this will be coming. I am ignoring multi-entry point standalone right now. But it probably makes sense to even add it as a use case in the user manual, because the manual procedure works and can be used right now.

@JorjMcKie Has made a script that does a bunch of the copying, etc.  It worked GREAT for me!
I'm SO excited because my project could really do some cool things if it's packaged into a .EXE.  PySimpleGUI makes it very easy to create a nice looking custom GUI.  Coupled with Nuitka means my programs launch straight into a GUI, just as you would expect a .EXE file on windows to do.
Thank you guys SO much.... it's exciting to see the stuff work and work well.  I was playing the demo pong game and it performed beautifully.

Update:
This issue does not exist on all platforms: on Ubuntu everything works just fine when using the same parameters.
I have no OSX, so I don't know what is happening there.

These seem relevant too:
os.environ['TCL_LIBRARY'] = 'system/tcl/tcl8.6'
os.environ['TK_LIBRARY'] = 'system/tcl/tk8.6'
Probably that gives us leaway where to put the TCL files. It also prevents using defaults compiled in the CPython to be used.
Yours,
Kay

@JorjMcKie Did you manage to make a standalone build of a PySimpleGUI project with Nuitka in the end ?

Nuitka building standalone PySimpleGUI executables also works on Linux (tested in a Ubuntu VM). Just did not bother creating a similar script for that environment ...

@MikeTheWatchGuy - interesting question. I will try that in the next few days.

@JorjMcKie The script works indeed, thanks.
But a simple test program with PySimpleGUI takes 48MB for both bin and lib directories, whereas PyInstaller creates a single executable of 7.8MB.
Have you found any solution to skim the weight of the Nuitka compiled stuff ?

@deajan As far as I recall, there are a handful of basic differences between both approaches (and maybe Kay feels motivated to comment on this as well):

the PyInstaller file is a self-extracting ZIP which at execution time expands itself into a temp folder from which the packaged-in Python interpreter starts and which in turn executes your script.pyc.

So the size of this expanded temp folder should actually be compared to be fair (or alternatively the compressed folder of nuitka-generated stuff - which is about 20 MB when no specialties like wxPython, PyQt, etc. are needed).
the TK/TCL directory (lib) alone is 4.5 MB, but 650 KB compressed.
the afore-mentioned approach of PyInstaller does not meet everyone's taste ... I personally dislike it.
PyInstaller also has a one-folder approach, which leads to considerable folder sizes as well.

nuitka in contrast leads to a binary-only distribution. The script code is compiled and is not excuted via interpretation.

by its very nature, compiled code is not easy to reverse-engineer if this is a concern. Very much in contrast to the script.pyc.
the same dist folder can be re-used for many script-EXEs. For every additional script-EXE it will only grow by ca. 3.4 MB, if you compress it via UPX (double size or more otherwise). UPX worked in all my cases so far.
You can also UPX-compress the rest of the binaries (except for the vcruntimeXXX.dll!). This brings down the complete folder size to those ballpark 25 MB.
A few more MB can be squeezed out if you use a 32bit Python version to feed nuitka with. This may be advisable anyway if you want your program be executable on 32bit and 64bit machines.
if you want some smart installation approach, you can automatically generate *.lnk files on the user's DESKTOP for every EXE you have compiled into the dist folder. I am using AutoIT for this. Elegant stuff like this type is hard to achieve with PyInstaller.

I just tried a perhaps more relevant comparison:
Taking a non-trivial script and generating it with (1) cxfreeze and (2) nuitka gave the following results (cxfreeze is comparable to pyinstaller).
I then compressed both the resulting dist folders with UPX -9. These where the results (MB):

cxfreeze creation size 82.7, after compression 35.5
nuitka creation 92.8, after compression 33.6

This seems to indicate an at least comparable size when it comes to more complex scripts than "Hello, world!".

I know the difference between an interpreter + pyc packer and a full blown python to C parser and compiler :)
I'd feel more confident being able to distribute my python programs without the necessity of being interpreted, but here's my point.
I took a threaded GUI program  I need to distribute and prepared it with both PyInstaller and Nuitka, and here are the results:

PyInstaller 3.4 using python -OO -m PyInstaller --onefile --noconsole imf_thread.py and UPXing all files except VCRUNTIME140.dll made 10,5MB, which could be compressed down with LZMA to a single file of 5,3MB
Nuitka 0.60.6 using make-exe.py script produced 48MB, UPexd down to 18,2MB, which still could be compressed down with LZMA to a single file of 13,0MB

Nuitka takes more than 240% of the size of a PyInstaller dist.
A quick analysis shows that there are a lot of files in the Nuitka bin directory that I'm pretty sure my program is not needing.
For instance, I use the following imports in my pyhon program
from threading import Thread
from concurrent.futures import Future
from time import time, sleep
import PySimpleGUI as sg

but endup with files like d3d12.dll or sqlite3.dll which I'm pretty sure aren't relevant for me.
I have successfully removed 6,9MB of unused dll files from the bin directory, without my program not being executed (okay, I might have some DLLs already in system32, but I'm still convinced that I don't need Direct3D support for my simple Tcl/Tk gui app).
Removing unused dlls brings the following result:

Nuitka 0.60.6 using make-exe.py script, manual skimmed down and UPXed version is 11,3MB, which can be compressed down to a single LZMA file of 6,7MB

Now we're talking about 25% percent size, which IMHO is very nice considering the performance improvements Nuitka brings along.
So the question is, how may I reduce what Nuitka is building me ?
I am sure I can have numerous --nofollow statements, but the should be a "standard" list already existing, that will prevent all those fancy dlls to be added ?

I see. Please forgive if my remarks were too close to "elementary school". No offense intended.
Your very valid baseline question is however one for Kay. As yet, I haven't cared to search for criteria in nuitka's decision machinery, when to include things and when not.
That those criteria must be different from what is used in packages like cxfreeze, seems quite obvious: in the example I tested (a wxPython script with no tkinter use), cxfreeze did not include any trace of sqlite / Tk / Tcl, whereas nuitka did include the DLLs. I imagine, that currently a strategy à la "better safe than sorry" is used.

Hello there,
I think it is larger because Nuitka includes all of standard library in
bytecode form or as extension modules, which then can pull in a bunch of
DLLs.
My rationale for that is that there always could be code like this:
import os os.listdir("some_dir") __import__(some_plugin_name)
So do I only include the os module in this case, and even there, only
what os.listdir is, and what if then whatever gets loaded as un-compiled
code from the import, does then uses standard library beyond that. What if
it uses the sqlite3 module and finds it not working?
So this far, Nuitka errors on the side of completeness. But I am open to
pull requests, where people make a plugin that prevents it from including
stuff typically not used, and even from including all standard library
modules by default, but only ones apparently used.
Also what can happen, is that people have test as a directory installed
in standard library, something Nuitka will ignore already, and a few things
like turtle that absolutely make no sense.
But for me, Nuitka is foremost about maximizing run time speed, not
distribution size. But if you are willing to hack it, you surely can make
Nuitka deliver everything as bytecode and become very minimal. Already some
namespaces (search unworthy in Nuitka) are never compiled. Just don't
expect me to do it. But again, I am open to pull requests that make these
things accessible.
Yours,
Kay

I am going to include this script next, last thing before 0.6.1 release, just to clean this up. Is the make-exe.py still your best, @JorjMcKie or do you have anything better.

@JorjMcKie No offense taken :)
Btw, since UPX gives good results on Nuitka compiled code, you might consider including a --upx-dir parameter to the script that would, if found, call upx for every file found in dist_path, except VCRUNTIME*.DLL and PYTHON*.DLL which should never be UPXed.
Also, could copy_cmd ="xcopy ..."  be replaced with shutil.copytree in order to become portable ?
@kayhayen Thanks for your answer, explains a lot.
It's probably too far from my todays Python knowledge to make a good PR for nuitka, but yet I'm curious.
Read a bit code from nuitka/freezer/Standalone.py, wondering where to find the piece of code that includes the standard lib ?
Thank you.

@deajan - good points. As I mentioned to @kayhayen - I plan to do some reworks on the script anyway. Among those changes indeed are replacing xcopy by a more sophisticated bit which only does this copy if binary compatibility is ensured (well, at least not obviously broken ...).

And does anyone have a headless Tcl/TK example I could use in my Buildbot testing, where I have no display? One that shows Tcl is accessible and alive, and ideally the path it runs from?

@kayhayen, @deajan - here is my new "best" version of that standalone EXE creator script:
make-exe.zip
It does this:

displays a (Tkinter) GUI for entering all the information. It is based on PySimpleGUI and looks like this:

optional output folder serves as collecting multiple nuitka compilation output in one bin sub-folder of this. It is mandatory if Tkinter support is requested (default). In that case another sub-folder lib of it is created. If no output folder is specified, no special processing takes place and the compilation output can be found in script.dist in the folder where script.py lives.

if "Output Folder" is provided, compilation output script.dist is created as a sub-folder of it. After successful compile, all new binaries in it are copied over to bin. Any duplicates (i.e. same names also existing in bin) will be verified to have identical content (but not copied of course).

if all works fine, sub-folder script.dist of the output folder is deleted.

Further remarks:

File copying is done in Python (shutil) - no longer Windows xcopy.
UPX compression is not (yet) implemented. My reasons are:

UPX must be executed in every sub-folder of script.dist, taking care of excluding certain binaries (e.g. vcruntimeXXX.dll, which may exist multiple times)
check for binary compatibility must be done only after compression
so it seems to me that compression makes most sense immediately before actually distributing the (merged) binaries. One should also evaluate the option to just compress the distributed folder as a whole, e.g. using the very effective LZMA (e.g. 7zip) method, potentially combining with self-extraction and elegant installation options. Besides, contents of Tkinter support sub-folder lib is source and cannot be UPX-compressed - it is also quite large (4 MB) and compresses very well with LZMA.

I am still thinking about an (independent) UPX based script, which recursively compresses nuitka output (like script.dist and bin).

Another update to my make-exe.py ... forgot something
make-exe.zip

@kayhayen - something like this?
tk-test.zip
invokes tkinter and displays some success message about the physical screen size

Works on my Python 3.7, just asking myself if there should be a exit code handling so the buildbot can get a proper failure reason.
Here's what I propose https://gist.github.com/deajan/7fa32d33ab70b34545154bc8476a1342

Please find current versions of the above-mentioned scripts upx-packer.py and make-exe.py here.

@kayhayen - from my point of view, this issue can be closed ...

@JorjMcKie Tested your make-exe.py script successfully. Also tested upx-packer, made a quick PR to check for upx binary :)
Indeed the main issue can be closed, just hoping someday we'll be able to have a single executable including Tk, but hey... it's already nice yet.

@deajan
Actually off topic - this comment is only concerning binary folder size.
I did a little research with the new Nuitka v0.6.1rc9 - might be interesting for you.

@JorjMcKie To be fair, Nuitka had a fair similar footprint to PyInstaller once all optional modules were removed.
As for your last comparaison, I think it's about recursing all optional modules or not, hence depending on what kind of modules you import, PyInstaller will be bigger than Nuitka or the contrary.

@deajan I understand and I agree. However, I used both without giving them any guidance on what eventually to neglect ... therefore both followed their standard algorithm. In so far I believe the comparison scenario was fair.
One reason for the big size(s) in my test case is the fact, that my two scripts use the imaging library PIL / Pillow, which contains references to big packages: PyQt, and -- even worse -- numpy (with MKL, in my installation).
Myself, I am not using numpy here, so, in another test round, I told Nuitka to not recurse down to this package via --recurse-not-to=numpy (which is now easy to do with my revised exe-maker.py script). This leads to a another size reduction of the merged Nuitka folder: from 151 MB (which is the number in the above comparison), down to non-compressed 116.5 MB - a 35 MB saving. When UPX-ing this, the packed folder size is 47.0 MB.
What would I have to tell PyInstaller to ignore numpy?

any objections to closing this one?

I came here because the current version of Nuitka (0.6.7) still does have the issue with tkinter (I am using PySimpleGUI), and the make-exe fixes that problem. Since the problem still very much exists (and even if it didn't), it might be a good idea to mention the existence and de facto necessity of NUITKA-Utilities in the main repo or on nuitka.net as that would save people a lot of time troubleshooting. If I hadn't come here and actually read through this, I wouldn't have known about the whole host of useful tools.

@Silun - are you using --standlone --enable-plugin=tk-inter?

I did not use that in the beginning because I found no reference to that option at all. I saw that --enable-plugin exists, but not that tk-inter is an option. So that's what I meant by saying the make-exe fixes that problem, because it adds that option and there seemed to be no obvious way for me to know I'd have to set that specific flag, especially not with the hyphen in there. Now that I found Nuitka utilities I'm good though, which is why I'm suggesting to make those more prominently visible.

Inside this reference, you will find information on plugins here.
As you have noted, there also is the utilities, which contains this folder on hinted compilation.
This is a way to have required plugins be detected automatically - among other benefits.

This seems to  be a duplicate, and will be solved anyway, once all plugins become enabled by default. The tkinter one seems very prudent for that to be done.


Not completely functioning in React Router v4.

I tried several configurations. I got it scroll to the top for each new page, but no scroll occurred when navigating with back/next buttons.

Scroll restoration on history navigation works for me with RRv4 in the project I originally created this library for. Please share code that reproduces the issue.

Ok. Will do once I get a bit of time.


numeric literals

numeric literals are not supported as in the code
Limit is 100
Counter is 0
Fizz is 3
Buzz is 5
which generates the output
Limit = 0
Counter = 0
Fizz = 0
Buzz = 0
when it should generate the output
Limit = 100
Counter = 0
Fizz = 3
Buzz = 5

I know the minimalist FizzBuzz example uses this syntax, but I'm not sure it should work. I'll put that on hold and create an issue at Rockstar docs. Thanks for pointing that out, though!


dynamic_reconfigure: 1.7.1-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository dynamic_reconfigure to 1.7.1-1:

upstream repository: https://github.com/ros/dynamic_reconfigure.git
release repository: https://github.com/ros-gbp/dynamic_reconfigure-release.git
distro file: noetic/distribution.yaml
bloom version: 0.9.8
previous version for package: 1.7.0-1

dynamic_reconfigure
* narrow down required boost dependencies (#160 <https://github.com/ros/dynamic_reconfigure/issues/160>)
* Make Config object pickle-able in Python 3 (#154 <https://github.com/ros/dynamic_reconfigure/issues/154>)
* Fix python3 issue in a backward compatible way (#157 <https://github.com/ros/dynamic_reconfigure/issues/157>)
* import setup from setuptools instead of distutils-core (#153 <https://github.com/ros/dynamic_reconfigure/issues/153>)
* Contributors: Alejandro Hernández Cordero, Mikael Arguedas, Scott K Logan

holding for the upcoming Noetic sync


OATs build fixes, better HTTP error test

Changes
Updates build for .NET 8 SDK
Improves HTTP GET error controller action to return a 500, and adds OATs test looking for HTTP error span.
Merge requirement checklist

[x] Unit tests added/updated
[ ] CHANGELOG.md file updated for non-trivial changes
[ ] Changes in public API reviewed (if applicable)

Thanks for adding this. I added a few comments, related to the fact that tests aren't consistently defined with new HTTP semantic conventions.
However, even with those changes, I don't get the new error-test to pass.

The Ginkgo --focus parameter was skipping some tests due to how testcase names were being generated. This PR improves name generation.
Running Ginkgo from the OATs yaml directory should show the HTTP tests now working, even without the PR to improve focus filtering.


Document hint in VS Code shows HTML tags

VSCode Version: 1.8.0
OS Version: Windows 10 64bit 1511

We noticed a visual issue with documentation tooltip when hovering the mouse on an API from RxJs library. Then created an issue over there: outcome is that document format respects JSDoc standard, so now it's more a question of whether VS Code should fully support JSDoc or what.
Steps to Reproduce:

have an Angular 2 / TypeScript 2 web application with a dependency on RxJs (5.0.0-rc.1)
open it in Visual Studio Code, v1.8.0
reach for an Observable<>.do() invocation
hover mouse to show documentation tooltip

Here's a screenshot showing the unexpected tags:

Related to #1920. Even for markdown content we display, we usually strip out html tags to workaround fun security and ui issues. We could look into preprocessing jsdocs perhaps

Closing as a duplicate of #1920. We likely will not support regular html contents in jsdocs, but do want to provide better support for markdown content


[ASCII-2585] Migrating ProcessAgent to use IPC cert

What does this PR do?
This PR replaces the self-signed certificate used in the Process Agent with the new Agent-wide IPC certificate. This change will allow Agents to identify this API as legitimate when they act as a client.
The certificate generation/retrieval implementation have been made in the following PR:

#31838

Motivation
This PR takes place in a plan of Agent security IPC improvement.
Describe how you validated your changes

Process Agent API is extensively used in Process Agent e2e tests. They should fail if the current PR introduce bugs.
Possible Drawbacks / Trade-offs
Additional Notes

/merge


⚠ Thumbnails API Endpoint has degraded performance

In 01f6c1d, Thumbnails API Endpoint (https://thumbnails.roblox.com/v1/assets?assetIds=82738847&format=Png&isCircular=false&size=30x30) experienced degraded performance:

HTTP code: 200
Response time: 1006 ms

Resolved: Thumbnails API Endpoint performance has improved in 33bff60 after 12 minutes.


add ability to link to headings

(This is the same as pegdown issue 110. )
I have classes with rather much documentation organized by headers.  It would be very helpful to be able to link to a header directly from another class or other page.
multimarkdown is an example of a markdown package that enables this.  Each header is given a fragment identifier as the name of the header run together without spaces and all lowercase.
For example a header specified in markdown
## Global Variable Usage

results in HTML like this:

Global Variable Usage

You can then use the fragment identifier in a link.  If the document is named Overview.html you can write in markdown elsewhere:
See the section [Global Variable Usage](Overview.html#globalvariableusage).

Or in the Overview.html document that contains the header you could write:
See the section [Global Variable Usage](#globalvariableusage).

Multimarkdown further adds markdown syntax to make a link to a header, what they call a "cross reference".  This syntax is less useful to me than just generating the fragment identifier. See the "cross reference" section in the MultiMarkdown Guide.  Within the same document you can generate a cross reference to the header like this:
[Global Variable Usage][]

No need to file against pegdown. I've actually had numerous formatting issues with pegdown and have been working on migrating to a CommonMark compliant parser (which will at least yield more consistent and predictable behavior).
As for your issue here, how would you disambiguate between identical headings in multiple files?

I think having identical headings in different files should be OK because there is also a file reference, for example:
See the sections [Global Variable Usage](Overview.html#globalvariableusage)
or [Engine2D Global Variables](Engine2DOverview.html#globalvariableusage)

Having identical markdown headings in a single file would of course be a problem, but it is easy to avoid doing that – just add a unique word, like the name of the method that the markdown header applies to.  For example adding in fooBar to the heading here avoids conflict with another ##Global Variable Usage heading:
/** Add a foo to the bar of the baz.

## Global Variable Usage in fooBar

This method uses several global variables such as `foo`, `bar`, and `baz`.

*/
Baz.prototype.fooBar = function() {};

You could accidentally make a heading that results in the same fragment identifier as the name of a method  in the same file.  Here is an example:
/**
## Foo Bar
This section discusses Foo Bar.

@constructor
*/

/** This is the foobar method.
@method
*/
Baz.prototype.foobar = function() {};

But if you are using CamelCase names then this would not come up in most cases.  The method above would be fooBar instead of foobar, whereas the heading fragment identifier would be foobar according to the rules followed by multimarkdown (everything run together with no spaces and lowercase).
The remaining problem case is:  methods that are named a single all-lowercase-word, and having a markdown heading with the same name.  Seems rather unlikely to me to name a markdown heading with a single lowercase word, but it could happen.
Of course, a warning would be nice if any conflicts occur.  Seems like one could easily make a grep expression that could find files with this problem.

After doing a google search on "markdown cross reference" I've found there is a way to do this now:
http://stackoverflow.com/questions/5319754/cross-reference-named-anchor-in-markdown
The example above would be
## Global Variable Usage

It would be more in the spirit of markdown to auto-generate these anchors for headings.  (Perhaps there could be a dossier option to enable or disable this).
BTW, see that stackoverflow page for a note about why to use name= instead of id=.  The reason is that id= creates JavaScript globals.


Transparent Admin login button

To allow basic functions like
-reboot
-shutdown
implement these functions as button available on non-authenticated page.
To allow access in case admin login button is hidden, have second option to instead make the button transparent and count several clicks before accessing it.

I like the idea about a transparent button, the button could be placed in one of the corners, so that it is easy to hit

This one is implemented in v5.
Will look like following in normal mode:

Made the button transparent even in default mode because it's less intrusive then.
If the button is configured to invisible, it's still rendered but with opacity 100%. Also there is a click-counter and the admin page is called only after 5 clicks each within 500ms:
https://github.com/user-attachments/assets/3f437534-56cd-4021-b9d6-310e33b7ece7

Looks great.... Looking forward to all the good improvement in v5.
Another improvement could be the option of having a number-keypad where you could enter a code to access the Admin section.
This would serve as an alternative to the login field, solving the issue of the touch keyboard not appearing when using kiosk mode.
Example:

Yeah, I am hesitant to implement, because it’s just half way. You could enter admin, but then there is still no keyboard to really use it.
I hope the raspberry on screen keyboard is getting better so it would be actually useful.
on the other side I would expect the shutdown and reboot button to be most useful to access.
These could be located right on the login screen so even normal users could shutdown the system correctly.


ES6 module support?

Many frameworks are changing to exclusively using ES6 modules, such as Ember (already has) and Angular (will for 2.0). Currently, the only way to do a proper ES6 import is via wrapping it in double backticks like so:
``import foo from './bar'``
# do stuff with foo

This is very ugly on multiple levels. Could there be support added for ES6 module syntax?
One potential issue may be reserving/replacing the import operator, but getting people to shift to the current equivalent to << (or import all to <<<) could be a start.
(Note: apparently this even has some traction in making it into CoffeeScript, whose implementors have historically put web-compat as first priority)

I'll reopen this, because I think we want this. We just need somebody who actually uses them to get some time for them :-).

Good point. I was just closing a seemingly stale issue (that I don't have the time to devote to).

Continue discussion at #705


Add a DMA USB wrapper

Added

USB DMA wrapper
A DMA interface class

Changed

Merged PCIe TRX Looper code with the main looper code and made it based on the DMA interface
USB devices use the singular remaining TRX Looper
Made LitePCIe inherit the DMA interface
Split interfaces in IComms into their own separate files
Simplified a few pieces of code for ease of reading

Fixed

USB enumeration not filtering devices properly on Windows

Removed

USB-specific TRX Looper

Known issues

Hacky workaround to set packet size in the FPGA for PCIe devices only
Samples transmission stops after a few seconds on USB devices on Linux
Windows issues, receiving sometimes working sometimes not, might be related to if a wait is triggered two times (first via Wait() then via CacheFlush())

Putting this in as a draft for now as I feel like a fresh pair of eyes would be quite beneficial at this point, as this does have a workaround that should not be in the final code but have no place to put it in a clean way, as well as probably a few misunderstandings on how DMA actually works, and a few issues I do not have a clear idea on how to fix, and probably some issues I don't even know about

@rjonaitis Not sure if you've seen this


Created Indian Flag using turtle  in Python 3.

Thank You @sandipan898 for merging the PR.

You're welcome, please give a star to the repository and also share it with your friends so they can also contribute.

For sure.


Addded clarification to README. fixes #805

The code will fail to execute when pasted into the terminal due to comments.


Remove doc_cfg attributes

with "Make cfg imply doc(cfg)" https://github.com/rust-lang/rust/pull/89596, these attributes are no longer necessary.
One pain point is that now doc_cfg generates info that's sort of...wonky for some things in the ffi module.

I think the best way to fix that is to combine them into a single struct (?). That way it's easy to document the fields as well.
Alternatively there's doc(cfg(all)) to override that.
I'm personally leaning towards the first option. What do you think?

I agree that sounds better, because presumably that way the individual fields get their cfg information rendered correctly?

It doesn't look like it. I think this feature is designed for a system where all features are additive. PyO3 is not one of those.
With it condensed in one struct, this is how it renders:

I've experimented with this and it seems the conditional compilation happens before the rustdoc pass. So only if those fields are active at the time are the field and the "is supported on..." banner rendered. For example, it does render the ob_pypy_link field if --cfg PyPy is passed to rustdoc. However that also gets rid of all the non(PyPy) banners elsewhere.
There is a cursed workaround for it, of course:
#[repr(C)]
#[derive(Copy, Clone, Debug)]
pub struct PyObject {
    #[cfg(py_sys_config = "Py_TRACE_REFS")]
    pub _ob_next: *mut PyObject,
    #[cfg(py_sys_config = "Py_TRACE_REFS")]
    pub _ob_prev: *mut PyObject,
    #[cfg(docsrs)]
    #[doc(cfg(py_sys_config = "Py_TRACE_REFS"))]
    pub _ob_next: *mut PyObject,
    #[cfg(docsrs)]
    #[doc(cfg(py_sys_config = "Py_TRACE_REFS"))]
    pub _ob_prev: *mut PyObject,
    pub ob_refcnt: Py_ssize_t,
    #[cfg(PyPy)]
    pub ob_pypy_link: Py_ssize_t,
    #[cfg(docsrs)]
    #[doc(cfg(PyPy))]
    pub ob_pypy_link: Py_ssize_t,
    pub ob_type: *mut PyTypeObject,
}

However, given that...

the feature is nightly
it adds some tedious and error prone cfg magic
it would be dangerous/confusing if somehow someone uses pyo3 with a docsrs cfg active

...I'm really not that enthusiastic about doing that. I'm not sure how many things would require covering it like this. I suppose we could do it for a couple of really important things...?

Unngh, ok. I think let's not worry about the cfg at field-level for now then? As you say, the feature is nightly so with luck it'll improve (especially if we report these papercuts upstream).

Oh yeah, it also doesn't work correctly if the cfg is on the module and glob imports are used. [...] So a lot of our ffi module has missing not(Py_LIMITED_API) banners.

Hmm, that's frustrating. I think at least it's no worse that what we currently have? I guess that that's another papercut which hopefully will get fixed in time if we report it.


Agda can't find standard library modules

Issue description
Agda can't find standard library modules.
Steps to reproduce

Install haskellPackages.Agda and AgdaStdlib.

Create the following file called hello-world.agda.

module hello-world where

open import IO

main = run (putStrLn "Hello, World!")

At a shell prompt, type agda --compile hello-world.agda.

$ agda --compile hello-world.agda
Checking hello-world (/home/amy/néal/agda/hello-world.agda).
/home/amy/néal/agda/hello-world.agda:3,1-15
Failed to find source of module IO in any of the following
locations:
  /home/amy/néal/agda/IO.agda
  /home/amy/néal/agda/IO.lagda
  /nix/store/yrcgczibkkx3zgry8g44l9gamz0k87fh-Agda-<IP_ADDRESS>-data/share/ghc-8.6.5/x86_64-linux-ghc-8.6.5/Agda-<IP_ADDRESS>/lib/prim/IO.agda
  /nix/store/yrcgczibkkx3zgry8g44l9gamz0k87fh-Agda-<IP_ADDRESS>-data/share/ghc-8.6.5/x86_64-linux-ghc-8.6.5/Agda-<IP_ADDRESS>/lib/prim/IO.lagda
when scope checking the declaration
  open import IO

Technical details
$ nix-shell -p nix-info --run "nix-info -m"
warning: unknown setting 'system-features'
these paths will be fetched (0.11 MiB download, 0.45 MiB unpacked):
  /nix/store/61shjilahl0d237fg9b3z3chza2lgms4-patchelf-0.9
  /nix/store/67ddmyshs02nqkfs2sgyvq3wn0fgdpwa-bash-interactive-4.4-p23-dev
  /nix/store/bh0034wm3y1zrizdg3pcfx6h56lc7wk3-stdenv-linux
copying path '/nix/store/67ddmyshs02nqkfs2sgyvq3wn0fgdpwa-bash-interactive-4.4-p23-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/61shjilahl0d237fg9b3z3chza2lgms4-patchelf-0.9' from 'https://cache.nixos.org'...
copying path '/nix/store/bh0034wm3y1zrizdg3pcfx6h56lc7wk3-stdenv-linux' from 'https://cache.nixos.org'...
warning: unknown setting 'system-features'
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.118, NixOS, 19.09pre181392.4ab1c14714f (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
warning: unknown setting 'system-features'
 - version: `nix-env (Nix) 2.1.3`
warning: unknown setting 'system-features'
 - channels(amy): `"nixpkgs-18.09.1676.7e88992a8c7"`
warning: unknown setting 'system-features'
 - channels(root): `"nixos-19.09pre181392.4ab1c14714f"`
warning: unknown setting 'system-features'
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Note: Possibly related to issue #19434.

More info:
$ sudo find / -name IO.agda
/nix/store/ljcr12pj1zspiyi4w5s421j8xx4h0wxh-agda-stdlib-1.0/share/agda/IO.agda
/nix/store/nkiqj8c08sa7x05vabig6m6bfj5sv731-Agda-<IP_ADDRESS>-data/share/ghc-8.4.4/x86_64-linux-ghc-8.4.4/Agda-<IP_ADDRESS>/lib/prim/Agda/Builtin/IO.agda
/nix/store/yrcgczibkkx3zgry8g44l9gamz0k87fh-Agda-<IP_ADDRESS>-data/share/ghc-8.6.5/x86_64-linux-ghc-8.6.5/Agda-<IP_ADDRESS>/lib/prim/Agda/Builtin/IO.agda

I've had a little look into this and agda seems to be in a bit of a mess. I managed to get hello world to work with the following shell.nix
{ pkgs ? import ./nixpkgs {} }:

with pkgs;

let
  pkg = agda.mkDerivation(self: {
    name = "MyPackage";
    buildDepends = [ pkgs.AgdaStdlib (pkgs.haskellPackages.ghcWithPackages ( p: [p.ieee]) ) ];
  });
in
  pkg.env

I agree this really isn't ideal and it really wasn't obvious that my compile wasn't working due to missing ghc packages. Ideally a ghc with the correct packages loaded would be fed into agda. A agdaWithPackages as suggested in #39318 would also be nice although that pr seems to have not much happening / have problems I don't really understand about interactive mode and emacs.
Sorry if this wasn't much help

Thank you @alexarice , that's a good workaround.

What needs to happen for this issue to be resolved?

This somehow solves the issue for compilation. How do I use the standard library in interactive mode, though?

FWIW, I found this helpful: http://blog.ielliott.io/agda-nixos/
It helped me get agda up and running interactively.

you might also be able to use direnv

Unfortunately I wasn't able to get any of the suggested workarounds here working myself. However, I was able to use agda-pkg in a nix-shell environment to get things running. Here's my template repository: https://github.com/bbarker/LearningAgda. I hope others might find it useful in the meantime, and any feedback you have is welcome.


bndtools < 5.3 may create invalid ZIP file extra fields (jar loading exceptions with recent JRE versions)

I've just noticed (after creating new Jenkins nodes with up-to-date JREs used for builds) that we get the following exception for one of our bundles created by the bnd-platform plugin (from maven/tycho):
Caused by: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: \
   Exception parsing OSGi MANIFEST [...]c.i.e.h.all-3.3.0.v20230901-1110.jar: \
   Invalid CEN header (invalid extra data field size for tag: 0xbfef at 125)
    at org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest (DefaultBundleReader.java:69)

I believe this is related to: https://bugs.openjdk.org/browse/JDK-8313765 - in this backported fix the JDK team loosened a very recently introduced ZIP stricter header validation. However, they state that even with this relaxed validation, there will still be errors for bundles created by BND < 5.3
The bnd release notes mention the fix here, I believe (Fixed handling of ZIP file extra field support.): https://github.com/bndtools/bnd/wiki/Changes-in-5.3.0
So I guess my main question is: is there anything stopping us from updating bnd-lib from 5.2 to 5.3? If it were a matter of "just bumping the version", I could open a pull request.

I was working on some fixes anyway and used the opportunity to update bndlib to 6.4.1.
Would be great if you can give the current SNAPSHOT version (3.0.0-SNAPSHOT) a try to see if the problem is solved.

Thanks a lot. I'll report back - will need some time, though, as the update from gradle 6 to 7/8 is causing some problems here.

Looks as if this does indeed fix the issue, at least for me.

I've just verified it, too: The error under JDK <IP_ADDRESS>+1 is present when building with bnd-platform 2.0.1 and gone when building with the current 3.0.0-SNAPSHOT

Thanks a lot for the feedback!
Just released 3.0.0 which is available from Maven Central or the Gradle Plugin Portal.


Fails to connect to known host with ed25519 fingerprint

If you have already connected to a server over ssh and saved a ssh-ed25519 fingerprint in ~/.ssh/known_host then doing :DistantLaunch [host name] fails to read the fingerprint.
Failed (1): Failed to launch server
Caused by:
    Fatal: host verification: host key mismatch for ssh server <IP_ADDRESS>:22.
    Got fingerprint SHA256:7Bekk1Nx0yOKspOjOHEw+RfeaC2K9NDg51BUoVZEWBI instead of expected value from known_hosts
    file ~/.ssh/known_hosts.

Tried using v0.2 branch

Whoops, had a reply waiting for this and never sent it. Thanks for the port, @trevarj!
I've seen this happen and not sure why. My workaround was just to delete the entry from the known_host file and recreate it as part of :DistantLaunch.
You could try changing the backend that powers the ssh functionality by doing :DistantLaunch options="ssh.backend=libssh" and see if that helps.

My workaround was just to delete the entry from the known_host file and recreate it as part of :DistantLaunch

Yep, this is what I ended up doing too. It recreates with a ecdsa key, so my guess is the default ssh backend must be expecting only that.

Closing out as an outdated issue. There's a workaround included in this issue, and this may also get resolved with https://github.com/chipsenkbeil/distant/issues/193 for distant.
Nothing else that can be done in the neovim plugin itself.


fix isnan

The PR is to fix a compiling issue in using Visual Studio C++ compiler. This issue was observed by Danielle initially when we pip install seq2pat on Windows with a compiler in Visual Studio C++ Build Tools.
The issue is error code C2668: `fpclassify`: ambiguous call to overloaded function, which is caused by the isnan function introduced in my last commit. This function doesn't cause the issue in my tests on Mac using Clang 10.0.0.
This seems to be a known issue with VC compiler and the solution can be referred to a discussion here. Later on, we would need to have a test on Windows once backend gets updated.

All good from my side. Perhaps not important for now, but might be possible to explore Windows compilation as well: https://github.blog/changelog/2022-01-11-github-actions-jobs-running-on-windows-latest-are-now-running-on-windows-server-2022/

Thanks @dorukkilitcioglu , there shows a comprehensive VC components and build tools in the list. I will look into this.


[T5A1][W11-B4] Tay Keming Justin

@INCENDE
Some comments added. Please ack & close the PR after reading comments.


Escape backslashes in docstring

If we escape backslashes in docstring, we won't face "invalid escape" warnings.
Fixes #2551

Thank you so much for your contribution @onlined!
@msyyc I think this is a safer approach. For searching where we're escaping, we also need to search any place we touch \ etc.
I think for now this is the way to do it, but @msyyc we can keep the raw docstring issue open, and after further investigation, we might decide to switch all documentation strings to raw strings

thank you so much @onlined!


add -fsynopsys option to ghdl

As requested here
I added the testcase under examples, because I am not sure how you want to organize it

I see.
What would then be a way to set additional options in the build script?
I tried
chip.set('eda', 'ghdl', 'option', 'import', '0', '-fsynopsys')

but, set aside the fact that forcing step and index like this is really ugly, the -fsynopsys option is at the very first one, and for some reason GHDL doesn't like it.
| INFO    | job0  | import     | 0  | ghdl -fsynopsys --synth --std=08 --out=verilog --no-formal /siliconcompiler/examples/ghdl_fsynopsys/build/binary_4_bit_adder_top/job0/import/0/outputs/binary_4_bit_adder_top_cd49da6cfcadc1c2e0f72496cb6d853fba7f792f.vhd -e binary_4_bit_adder_top
/usr/local/bin/ghdl: unknown command '-fsynopsys', try 'help'

..but, set aside the fact that forcing step and index like this is really ugly

You bring up a good point. The options are there to address tools like openroad that get called for many different steps and need the ability to drive the option on a per index/step basis. We can consider adding a wrapper function to make it nicer or some kind of global option.

-fsynopsys option is at the very first one, and for some reason GHDL doesn't like it.

Is this a ghdl bug?

I think GHDL probably expects a command name (like --synth) to come first. I don't think that's a bug, just how it works.
I don't think many of our tool wrappers are carefully written to allow additional user-supplied options at this point. I think ghdl.py will need to be refactored to set up options in setup(), and it could make sense to see if the user has supplied any options first, and then append those to the end of the default options before overwriting the options schema entry.

Something like this?

We'll give this a bit more thought and then get back to you!

Sorry for the delay getting back! I think there are a couple things that need to change to get a really good general solution here. However, in order to resolve this in the meantime I'd propose:
Right now we have the ['tool', <tool>, 'var', ...]  keypath that lets you set arbitrary tool-specific key/value pairs. I think you could use this parameter to control whether the -fsynopsys parameter gets added.
In your build script, to enable -fsynopsys:
chip.set('tool', 'ghdl', 'var', step, index, 'extraopts', '-fsynopsys')
That lets you do something like in ghdl.py:
if chip.valid('tool, 'ghdl', 'var', step, index, 'extraopts'):
  extra_opts = chip.get('tool', 'ghdl', 'var', step, index, 'extraopts')
  # some validation code for extra_opts?
  # add extra_opts to CLI options in correct place

This is abusing this keypath a little bit, since the docs specify that the reference scripts should be consuming the vars set here (in this case, GHDL isn't running from a script). However, we don't have any other free passthrough keys in the tool schema, and I haven't decided on a proper entry in the schema. The reason to not just do this through ['tool', <tool>, 'option', ...] is that allowing a user to manually tweak the exact CLI options list seems error-prone, since there's a certain behavior that the tool driver tries to produce, and this could be broken if the CLI flags are changed arbitrarily. Giving the user a new field to put additional options in, and then letting the tool driver validate and manage it, seems like a safer interface.
Now, this doesn't fix your point about specifying the step/index being ugly (which is a point well taken, by the way). I'm treating this is an orthogonal issue, and I'm not 100% convinced that we should be adding something else to the schema for it. At the very least, I think the issue applies to multiple values under the ['tool', ...] keypaths, so we'll want a solution that scales to each (I'm leaning towards some sort of helper function).
TL;DR: as an incremental approach, I'd propose using ['tool', <tool>, 'var', ...] to pass in extra CLI options, which ghdl.py could then validate and append to existing options in the correct place. The other issues you raised we can address separately.

Hi @nmoroze I changed the usage of -fsynopsys following your indication


(In mysite.js at 47 line is missing a semicolon

// 1a. load default config
cody.config = require(path.join(__dirname, sitename, "config.json"));
cody.config.controllers = cody.config.controllers || []

Fixed in 7af59af26cb1c9f9a08a75f155a40af25eeb4da1, thanks! ;)
(Well, it's changed in the doc/empty/index.js, so you'll only see the fix if you create a new site)


App freezes when scrolling through results and never recovers ("The window is not responding")

Type: Bug

Connect to a sql server database
Execute a query that will return at least a few thousand rows (not sure if row count matters - reproduced with ~3500)
Records are returned and visible in the Results pane
Scroll through the records in the Results pane
Eventually the application will freeze and a "The window is not responding" message will display. Subtitle: "You can reopen or close the window or keep waiting."
The application never recovers, even if I click 'Keep Waiting' multiple times

Issue started after installing 1.45.1 and has occurred multiple times.

Azure Data Studio version: azuredatastudio 1.45.1 (88c21b1725a3e79440027bdb7b5a55fb036be0e2, 2023-08-03T00:42:37.945Z)
OS version: Windows_NT x64 10.0.22621
Restricted Mode: No
Preview Features: Enabled
Modes:

System Info

Item
Value

CPUs
12th Gen Intel(R) Core(TM) i7-1260P (16 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.70GB (4.99GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

Hi @AlmostRemember
Could you please try out the latest insiders build and let us know if issue persists?
If yes, please let us know the nature of data in the rows, e.g. number of columns, number of characters in large data columns, if anything if out of ordinary.

I installed the insider build and haven't seen it freeze so far. But the error is intermittent and I can't reproduce it on demand. I'll continue using the insider build for my normal work and will report back.

The insider build finally froze on me at the end of the day. The result set was 79 rows. Here's what the table looks like:
CREATE TABLE [dbo].[Table1](
	[Col1] [int] NOT NULL,
	[Col2] [int] NOT NULL,
	[Col3] [datetime] NOT NULL,
	[Col4] [datetime] NULL,
	[Col5] [varchar](20) NOT NULL,
	[Col6] [varchar](1000) NOT NULL,
	[Col7] [bit] NOT NULL,
	[Col8] [varchar](4) NULL,
	[Col9] [varchar](50) NULL,
 CONSTRAINT [PK_Table1] PRIMARY KEY CLUSTERED ([Col1] ASC)
)

Data in the varchar(1000) column was 20-50 characters. I ran the same query again after restarting and was able to scroll through the results without it crashing.

I had ADS freeze with the "window is not responding" message in a different area - while reviewing an execution plan in the 'Query Plan' view. I had the properties list open at the time and was clicking different parts of the execution plan.

Still an issue on 1.46.1. Seems to be pretty consistent if your results have a lot of columns and you try scrolling sideways in the results view. Number of records doesn't seem to matter...could by 5 results or 5000...but the number of columns seems to play a part.  But scrolling at a normal pace, you can see the column headers start to get messed up (they're in the wrong spot) and then it'll freeze.

@dev-the-dev
Can you share your table schema we can use to replicate the case? Also do your columns contain any and how many XML/JSON data columns?

How is this not fixed yet?

Intermittent issues are difficult to diagnose. It's probably not happening for everyone and the specific conditions to reproduce it haven't been identified yet.  The developers want to help but they have a lot of competing priorities. If you can help in narrowing down the conditions when it happens that will give them more to work with.


[SYCL 2020] Add accessor simplifications/deduction guides, host_accessor

(cc @tomdeakin)
Initial implementation of

Accessor simplifications, deduction guides and no_init property
host_accessor (partial implementation)
Redesigned property_list which was required by the new accessor interface.

Allows code patterns such as
q.submit([&](sycl::handler& cgh){
  // read-write default for non-const buffer type
  sycl::accessor acc{buff, cgh};
  // Using deduction guides and no_init property
  sycl::accessor acc2{buff, cgh, sycl::read_only, sycl::no_init};
});
sycl::host_accessor hacc{buff, sycl::read_only};

Note: This PR does not yet contain additional changes/additions to the members of accessors, such as the iterator interface.
The only thing I'm not sure about is the pattern:
sycl::buffer<int> buff {...};
// construct read-only accessor
sycl::accessor<const int> acc{buff};

I think originally the intent was to allow this pattern in order to make read-write/read-only expressible only with accessor const-ness, but I don't see how the interface in the spec allows for that, and the wording in the spec appears pretty vague to me.
The spec hardcodes that the buffer arguments to the accessor<T> constructors is of type buffer<T>.
We would need additional accessor(buffer<std::remove_const_t<T>>&) constructors to make constructing accessor<const T> from buffer<T> work, which the spec does not seem to anticipate (which would also double the number of constructors because we don't have enough yet ;-) )

@hipSYCL-ci-bot test


Some combination glyphs in Khmer return inconsistent width values

Defect Report
I use NotoSansKhmer and uharfbuzz together with fpdf2 to create a pdf document. To right align the text I need the width of a string after being adjusted by the font shaping engine for combined characters. With all Noto fonts (Sans, Serif, SansUI) I get for some glyphs values that are too small. Therefore the right alignment is shifted by several pixel. A demonstration is attached below. Switching to Google font Khmer-Regular.ttf solves the problem.
Title
Some combination glyphs in Khmer return inconsistent width values
Font

NotoSerifKhmer-Regular.ttf
NotoSansKhmer-Regular.ttf
NotoSansKhmerUI-Regular.ttf

Where the font came from, and when
Site: https://notofonts.github.io/khmer/
Site: https://notofonts.github.io/khmer/fonts/NotoSansKhmer/googlefonts/ttf/NotoSansKhmer-Regular.ttf
Date: 2024-06-06
Font Version
2.004
OS name and version
Windows 11 Pro 23H2
Application name and version
fpdf2 2.7.9 with uharfbuzz 0.39.1
Issue
As written in the introduction, the returned width of a string after font shaping with harfbuzz is too small for several combinations with Noto fonts. The python program will produce the observed results for a variety of fonts, but is consistently flawed for Noto fonts while the Google font solves the problem.
I draw a box with the width of the drawn string as returned as pdf.string_width() function. See the comparison in screenshots below. The python program is:
from fpdf import FPDF
fontname = ["NotoKhmer.ttf", "Khmer-Regular.ttf",
            "NotoSansKhmer-Regular.ttf", "NotoSansKhmer-Regular.otf", "NotoSansKhmerUI-Regular.ttf",
            "NotoSansKhmerUI-Regular.otf", "NotoSansKhmerUI-Regular1.ttf", "NotoSansKhmerUI-Regular1.otf",
            "NotoSansKhmer-RegularDev.ttf", "NotoSerifKhmer-Regular.ttf"]
# strings:    years,  alone,    1st year, sword,  fork
teststrings = ["ឆ្នាំ", "ម្នាក់ ឯង", "ឆ្នាំទី១", "ដង្កាវ", "ង្គ្រា"]

def render_strings(teststrings):
    pdf.set_font('noto', size=24)
    pdf.set_draw_color(160)
    pdf.set_line_width(0.3)
    for string in teststrings:
        pdf.rect(pdf.get_x(), pdf.get_y()+2, pdf.get_string_width(string), 13, style="D")
        pdf.cell(h=17, text=string + " ")
    pdf.ln()

def info(text):
    pdf.set_font("Helvetica", size=12)
    pdf.cell(text=text)
    pdf.ln()

for typeface in fontname:
    pdf = FPDF(orientation="P", unit="mm", format="A4")
    pdf.add_page()
    pdf.c_margin = 0
    pdf.add_font("noto", style="", fname="../../fonts/" + typeface)
    info("Rendering without shape engine:")
    render_strings(teststrings)
    info("Now activating the shape engine and try this again:")
    pdf.set_text_shaping(use_shaping_engine=True, script="khmr", language="khm")
    render_strings(teststrings)
    render_strings([''.join(teststrings)])
    pdf.output("fpdf2_stringwidth" + typeface + ".pdf")

Character data
One example is years: ឆ្នាំ or U+1786, U+17D2, U+1789, U+17B6, U+17C6. It is the first string in my example above.
Screenshot
This is the result of all Noto fonts (glyphs are slightly different, of course) but the box is consistently too small:

Problem solved with using another font: https://fonts.google.com/specimen/Khmer

Tools for reporting bugs
Harfbuzz hb-view and hb-shape
These are part of the HarfBuzz distribution and can help isolate if an issue is in the app/OS, shaping engine, or font.

hb-view renders the text with the exact font (for example, to see how ligatured characters shape) using your installed version of HarfBuzz.

For example:
  hb-view --font-file {path to font} --text-file {path to text file} --output-file '{sample}.png'

hb-shape shows glyph selection and positioning

Fontview

Fontview displays the text.

Fontdiff

Fontdiff displays the text using two versions of the font side by side.

Here is reference of Khmer Unicode scripts ISO 15924
Khmer Unicode
Some of software required to define each characters in binaries and decode to output. using REGX.
But I am not good at NLP.

I can understand why this seems like an issue with the font, because you have tried a different font and it works. However, Dan Hong's Khmer font is constructed differently and does not use mark attachment; and a problem which occurs when using a font with an open source PDF library - and nobody has reported it in general - is almost always caused by the PDF library.
I believe that the problem here is that FPDF is not correctly accounting for the advance width of mark attached glyphs.

Closing as this is now fixed in the PDF library.


Towards vectorized convolution (PR 3 of 3)

This PR adds the necessary pass to align transfer_read. It is based on mlir-aie's aievec, see:
https://github.com/Xilinx/mlir-aie/blob/d3da586305ebc22e5ecdf1d3e682b44853436e91/lib/Dialect/AIEVec/Transforms/VectorToVectorConversions.cpp#L123
Some changes were needed for our use case, however. The main one is that the lowering in this PR skips the vector.extract_strided_slice operation, because we have an offset which is not constant. i.e. the offsets in https://mlir.llvm.org/docs/Dialects/Vector/#vectorextract_strided_slice-vectorextractstridedsliceop cannot be integers for us, because they are determined from loop induction variables. The pass implemented here goes straight to aievec extract and shift operations, where mlir Values are used for offsets.
Also included in this PR: an aievec.shift folder. I can make this a separate PR if preferred.
This PR enables vectorization for convolution and resolves https://github.com/nod-ai/iree-amd-aie/issues/820

Could you rename your PRs to be more descriptive of what they actually add? I was looking at the commit history earlier and Towards vectorized convolution (second PR) isn't a great commit message.

This PR enables vectorization for convolution and resolves #820

Are you planning to add an e2e testcase?

Are you planning to add an e2e testcase?

The e2e numerical tests are now vectorized because of the change here in Passes.cpp


Feature request: allow deschashonly=True for CLN invoices

Please allow setting the flag deschashonly=True via the SDK so that we can create LNURL invoices.

Related: https://github.com/breez/breez-sdk/issues/367

@JssDWt agreed, fully exposing the flags for the invoice call would be a lot more useful then only this flag. It will pave the way for atomic swaps or hodl invoices for example.


Add private modifier and refactor some code

Thank you for this great project.
I'm always really impressed with your works.
This pull request includes following points

add private modifier
remove brackets in if statement  and switch statement
remove true or false in if statement
use let instead of var
use guard and exit early

Please merge this If you would like :)

Thank for this nice refactoring!

Thank for this nice refactoring!


Add ability to list ECS services by launch type

Add optional launchType parameter to the ECS service according to the latest boto3 version and AWS API

Codecov Report

Merging #5138 (2ae4ccf) into master (30c2aea) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #5138   +/-   ##
=======================================
  Coverage   95.88%   95.88%
=======================================
  Files         680      680
  Lines       67269    67293   +24
=======================================
+ Hits        64499    64523   +24
  Misses       2770     2770

Flag
Coverage Δ

servertests
36.89% <10.00%> (-0.01%)
:arrow_down:

unittests
95.82% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/ecs/models.py
93.02% <100.00%> (+0.02%)
:arrow_up:

moto/ecs/responses.py
99.30% <100.00%> (+<0.01%)
:arrow_up:

moto/ram/models.py
99.12% <0.00%> (ø)

moto/organizations/utils.py
100.00% <0.00%> (ø)

moto/ec2/responses/subnets.py
100.00% <0.00%> (ø)

moto/organizations/models.py
99.59% <0.00%> (+<0.01%)
:arrow_up:

moto/ec2/models/subnets.py
94.71% <0.00%> (+0.02%)
:arrow_up:

moto/organizations/responses.py
98.27% <0.00%> (+0.23%)
:arrow_up:

Continue to review full report at Codecov.

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


test: do not force Cypress click

Didn't understand why that was needed. It isn't in theory. And now it works without it. So removing it

#850  👈 (View in Graphite)
main

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


Updated sram BUILD with naja command line

bazel build naja launches naja_edit.
For primitives, the embedded asap7 Python version in naja is currently used. It would be better to point to the liberty file provided to Yosys.

naja package must be installed in naja/install dir inside sram.


[Feature Request] Add a hotkey for toggle

Adding a hotkey would be nice, just that, thank you

or a command

Supported in 2.0.0


Handle massive json annotations

Currently, we parse annotations by loading the entire annotation into memory.  Usinb an iterative approach for larger files (e.g., via https://github.com/ICRAR/ijson) would be mord scalable.

A quick but limited solution to this would be to pick a bigger size than Girder's default of 16MB and read those using the current technique.


Add performance test for using macro includes

@lptr @big-guy I addressed your comments, could you have another look?


Allow EKS users to authenticate by assuming a role.

This provides the possibility to authenticate against an EKS cluster by assuming a AWS IAM role.

@jens-solarisbank Thank you for PR. To proceed to merge this PR, please read our CLA. If you accept it, please say so in this thread.

Hi @superbrothers, I accept the CLA.


Test Code Coverage has contains the tests directory, How can I solve this problem?

Looks like this was fixed by #1039

Yep. I'll publish a new version today.


upgrade the intl version

Kindly upgrade the intl version in the package. thanks.

the latest intl 0.19.0 fails to resolve
Because <app>b depends on month_picker_dialog 2.7.0 which depends on intl ^0.18.1, intl ^0.18.1 is required.
So, because <app> depends on intl 0.19.0, version solving failed.

Please upgrade intl to 0.19.0

I have added a PR https://github.com/zulfahmi93/month-year-picker/pull/37/
@zulfahmi93 Please check and merge it...


How to set up DATAPATH environment?

I am trying to use  Dligand2 for my calculations but cannot find out how to set up DATAPATH environment, any help?

in their example/run_example.sh file:
export DATADIR=../dligand2/bin
export PATH=../dligand2/bin:$PATH


replace text node names with numbers

After trying this, it turns out this makes the code less readable, and it actually hurts performance a little. There's no benefit.


Mobile clients: Android & iOS release date?

Thanks for your great work!
When we could use it on mobiles?

yes, you can integrate this project to your iOS / Android App as your wish.

Actually, it's easy to do this job based on https://github.com/ShadowsocksR-Live/iShadowsocksR and https://github.com/ShadowsocksR-Live/ssrDroid .

Thank @ssrlive for reply
I am familiar with SSROT and using it on Android & Linux.
So overtls is just the same SSROT on rust language?

No. Overtls is equivalent to an extremely simple implementation written in Rust language after removing SSR and SS from SSROT, and it only retains OT.

Nice!
its so great that client has to need to be changed!

ssrDroid now support overtls directly.


Add prefix to custom attributes

Hello,
Can you please add a prefix to your custom attributes so it can play nicely with other libraries such as the newly introduced Android Design Support Library?

Same issue in #274

I have modified the attribute "rippleColor" to "mRippleColor"
Have forked the current version in here: https://github.com/vajro/MaterialDesignLibrary


Added scroll listener with number in middle

Added a callback to know when the view is being scrolled and what is the number in the middle while doing so, for example to update other views dinamically while scrolling or to make the phone vibrate when scrolling over numbers

I think this feature is already implemented as OnValueChangeListener. Please reopen this PR if I misunderstood anything.

You are correct, i seem to have completely missed it, my bad

You are correct, i seem to have completely missed it, my bad


Please add a license file

I'd like to add this to awesome-zsh-plugins, but it doesn't have a license file.
Please add a license file - if you don't have one in mind,  I recommend using choosealicense.com to help choose an appropriate one.
Thanks!

Hello,
I never thought that this tiny bit of code could interest anyone.Usually
I use GNU General Public License or GNU Affero General Public License,
but for such short code an X11 License or BSD would be better. And the
code will integrate more easily with awesome-zsh-plugins.
When do you think ?
Thank you
Le 25/11/2021 à 15:25, Joe Block a écrit :

I'd like to add this to awesome-zsh-plugins
https://github.com/unixorn/awesome-zsh-plugins, but it doesn't have
a license file.
Please add a license file - if you don't have one in mind, I recommend
using choosealicense.com https://choosealicense.com to help choose
an appropriate one.
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cosmonet-fr/prompt-zsh/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQOW5CO5EZL2DIFNHGHFXDUNZBL5ANCNFSM5IYVKFIQ.

I always choose Apache 2 or BSD, but MIT and GPL are good too. Whatever works for you :-)

It's okay, I just added the MIT
Le 25/11/2021 à 15:59, Joe Block a écrit :

I always choose Apache 2 or BSD, but MIT and GPL are good too.
Whatever works for you :-)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cosmonet-fr/prompt-zsh/issues/1#issuecomment-979282500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQOW5FSRAFENAMLEC73223UNZFNBANCNFSM5IYVKFIQ.

One last thing - could you rename it something less generic than prompt? Even naming it after your github username will make it look distinct in the list. Sorry for not mentioning this in the issue when I created it.


Spring Kafka filter not filtering consumer record

Here is my issue created in Stack overflow
https://stackoverflow.com/questions/54894537/spring-kafka-filter-not-filtering-consumer-record

It is not necessary to post in two places; you need to provide much more information, including some sample data or a simple application that exhibits the behavior you see.

I have updated my question with sample logs and my kafka listener code as well.

Closed in favor of mentioned SO question: https://stackoverflow.com/questions/54894537/spring-kafka-filter-not-filtering-consumer-record


YamlMetrics collector for pulling values out of YAML/JSON files

Wrote this so that we could pull a few values out of the /etc/mcollective/facts.yaml file, but it's generally useful for any JSON or YAML file.
I've tested on a dev box, and in the vagrant setup. Also tests are pretty good for me ;)
LMK if you'd prefer this squashed up some, the commits do tell a decent story tho.

@mikepea : tests are failing, unfortunately.
Both @dichiarafrancesco and me are going to be out for a bit, so, if this is urgent, please ask someone else from our team to look at this PR and merge it.

Yeah, it's a race condition detected in one of my tests, waaah:
==================
WARNING: DATA RACE
Write at 0x00c42001e168 by goroutine 61:
  fullerite/vendor/github.com/Sirupsen/logrus.SetLevel()
      /home/travis/gopath/src/github.com/Yelp/fullerite/src/fullerite/vendor/github.com/Sirupsen/logrus/exported.go:34 +0xbc
  fullerite/collector.TestGetMetricSimple()
      /home/travis/gopath/src/github.com/Yelp/fullerite/src/fullerite/collector/yaml_test.go:63 +0x5c
  testing.tRunner()
      /home/travis/.gimme/versions/go1.7.linux.amd64/src/testing/testing.go:610 +0xc9
Previous read at 0x00c42001e168 by goroutine 88:
  [failed to restore the stack]
Goroutine 61 (running) created at:

Have you seen this before? I've no idea how to start fixing it :(
No real urgency btw, this is a pet project and tbh I think i'll withdraw it and add shell exec and HTTP support too before i ask for a release with it in.

Unfortunately I haven't seen this before. We got quite a few data races discovered when we switched to golang 1.7, but we thought we fixed them all. They are usually due to two goroutines accessing the same map at the same time, but I can't be sure this one is the same.


When google plugin throws exception most probably due to not finding a specific rate, it wont restore previous libxml_disable_entity_loader mode

When google plugin throws exception, most probably due to not finding a specific rate, it won't restore previous libxml_disable_entity_loader mode, effectively disabling any further Soap operations, the
libxml_disable_entity_loader($disableEntities); restore operation is executed just after

Thanks for reporting this @FantomX1.
It is fixed in the latest version of Exchange. composer update florianv/exchanger

Thanks very much, maybe I haven't updated it for a longer period.


Dashboard link did not work

In my tests, the "service dashboard" link didn’t work. It brought up the GP dashboard, but produced an error when clicking on the "bundles" tab.

Has a workaround, to go find the GP instance manually.


ipv6 compatible ingress checks

Reference Issues or PRs
Addresses #2485
For ipv6 working, at least an update of keycloak is also necessary.
What does this implement/fix?
Ingress checks will be successful on ipv6 also using getaddrinfo instead of gethostbyname.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[x] Did you test the pull request locally?
[ ] Did you add new tests?

Any other comments?

Hi @jorop, thank you for your contribution! We're currently in the midst of a significant update focused on our RBACs and JupyterHub, which might cause some delays in addressing your input.
We discussed this in our internal sync yesterday, and I’d like to invite you to join our community sync meetings as well: https://www.nebari.dev/docs/community/#community-meetings. These meetings are open to everyone and provide a great platform for further discussion. Please note that this item is not yet on our roadmap because we are assessing the stability of specific components that support IPv6 exclusively, which would require some more thought into it...
In the meantime, for backward compatibility, it would be beneficial to include a custom field in the ingress section of the nebari-config.yaml file. This field would allow us to toggle between different implementations as needed.

@jorop I will be doing a check on this

Hi @jorop, sorry for the late feedback; thanks for submitting the PR! Regarding your statement about updating the keycloak, can you elaborate further on why you see that as a requirement? I assume it's due to it only formally supporting it on >=20.x but I also would like to hear if you encountered any other settle back while playing around with an ipv6 deployment

Can you add a test for get_ip as well?


Add setting membership type in influx auth command

influx org members add now allows for the --owner flag so the CLI can create a user of type owner

@samhld What is the difference between a user that is an organization owner vs just a member?

Or is this a user that is an owner/operator (across all orgs(?

@sanderson the latter.