text:
Can I financially support Warehouse and other PyPA projects?

Y'all are doing the Lord's work here, I tell ya.
Is there a central pool I can give to to support PyPA projects? Or perhaps a way I can donate to the Warehouse project specifically?
I'm not sure if donations to the PSF can be designated for specific projects.

Hey,
Sorry for the delay in responding to you. I just moved on Friday so things are a bit hectic here.
We (the PyPA) do not currently have a way of accepting donations. Accepting donations comes with some overhead that nobody has really stepped up to handle, particularly since I don't believe that there's a whole lot we have to spend money on (all of our services like hosting etc, are donated) and the cost for people's time tends to be a lot more than we're likely to get donated. We totally appreciate the sentiment though!

No worries, I understand.
Perhaps this is better discussed elsewhere, but has the PyPA considered using a platform like BountySource's Salt (FAQ)?
The Neovim team, for example, seems to have been very successful in funding its own development using Salt. And they've mostly been paying for people's time, not infrastructure.
There is also a related set of discussions on Paying the piper.
Anyway, with all the good things coming out of the PyPA -- Warehouse, the Packaging Guide, improvements to pip, etc. -- which benefit so many people, it seems a shame there isn't a way to financially back the team.
If that kind of backing could make a difference, I'd be interested in hearing what the team needs to make it a reality--even if it was just as a short-term experiment. For example, you mentioned overhead. What kind of overhead specifically would need to be handled?

From a PSF perspective, while we can accept earmarked donations, we don't really have a way to funnel donations to PyPA as such, so we can currently only accept in-kind donations that go towards providing the PyPI web service (e.g. Fastly for CDN, Rackspace for hosting, etc).
I'm optimistic that may change in 2016, though - we're just finishing up the process of hiring a paid infrastructure manager for the PSF, which will hopefully give us the capacity to more effectively administer freelance and contract activities targeting PSF provided services, including PyPI.
Another way the situation could change is if some of the PyPA organisers (e.g. @dstufft, @qwcode) were to approach the PSF about setting up a formal fiscal sponsorship arrangement (similar to the arrangement with PyLadies), but it probably makes sense to first wait and see how things change with the infrastructure manager in place.

Thanks for starting this thread @nchammas.
For what it is worth, I would certainly find it easier to make more time for the redesign were there a financial incentive.  I do my best to make progress on the project, but paid work always has to come first.  An income that corresponds to a number of development hours would allow me to make more regular, scheduled contributions, instead of having to 'snatch' a few hours here and there.  I am sure my experience here is not unique and there would be many PyPUG contributors who would benefit in the same way (not to mention the benefit to the projects).

So I guess the question is, how can we accept money and then distribute it to folks like @nlhkabu where we can actually purchase some of their time to dedicate towards it? Should we just direct people who want to contribute to donate directly to those people? Should we try and work something out with the PSF? There's also options like what Twisted has done with the Software conservancy thing. I have no problem putting in time to make this sort of thing happen but it's far outside of my wheel house to be able to evaluate the options and push for one.

In addition to the options that @dstufft mentioned, I'd once again call out Salt as an option to look at. I haven't used it extensively, but my impression is that it has a relatively low overhead and directly lets us solve the problem of funding bits of development on PyPA projects.
Maybe @tarruda from the Neovim project can briefly chime in here? I think the Neovim team's experience with Salt may be a model we can follow.

The main thing is having someone willing to take responsibility for directing funds that folks will accept as a legitimate PyPA authority, so if @dstufft is willing to do that (perhaps with @qwcode as a backup), it should be possible to work something out. (It's best if the folks administering the funds aren't themselves likely to be recipients of the funds in the near term, since it significantly reduces the potential for financial conflicts of interest)
In terms of what would be involved in setting up a fiscal sponsorship arrangement with the PSF and the potential benefits of doing so, the PyLadies organisers are probably the best folks to ask about that. Perhaps @econchick, @audreyr or @willingc could provide some insight?

I'll also note that PSF fiscal sponsorship wouldn't be mutually exclusive with the idea of a PyPA team account on a platform like salt.bountysource.com or the revamped gratipay.com - the fiscal sponsorship merely lets the PSF collect and disburse funds on behalf of the sponsored project, as described in https://wiki.python.org/moin/FiscalSponsorship
The advantage from a sponsor perspective is that the PSF is a formally constituted non-profit organisation in the US, so many sponsors will be eligible for tax deductions when contributing through the PSF that they wouldn't receive when contributing through a payment platform like salt.bountysource.com.

PSF fiscal sponsorship sounds good to me, and I agree it would definitely add additional incentive for people and companies to donate when the donation is tax-deductible.

I want to echo @ncoghlan 's suggestion to ask for fiscal sponsorship for PyPA - definitely a positive for PyLadies when collecting donations and allowing them to be tax-deductible.
*puts on my PyLadies hat* I will be upfront in that it can be a bit manual. For instance, I have to file for reimbursements against the PyLadies account; there's no easy way to directly draw against the account itself.  As well, it's one pool - there aren't sub-accounts for specific PyLadies locations (say, if PyLadies in AwesomeCity Town accepts $100 donation for help in running an event). I, as the designated "project manager" for the fiscal sponsorship relationship have to keep track that AwesomeCity Town PyLadies has $100, and have to "okay" their request for reimbursement.
But being able to accept tax-deductible donations without the hassle of incorporating as a 501c3 (note: only US-based tax-deductible) heavily outweighs the manual cost of everything in our PoV.
*puts on my PSF board member hat* A simple email to the PSF to start the conversation would be all that's necessary at this point.  There wasn't much work at all from the perspective of PyLadies & PyPA (as well as the PSF).

Another thing to consider is that it's entirely possible that if @dstufft and @nlhkabu (say) were to put together a proposal describing the cool stuff that they could do given $xx USD, then that the PSF might be willing to fund this out of existing funds. This is orthogonal to the original question about how to accept funds, but something to think about in any discussion of whether more funds would actually be useful...

So, this is starting to get a better answer-- You can visit https://donate.pypi.io/ :)

Related discussions for others coming through: #1315, #1321

authors: dstufft econchick nchammas ncoghlan njsmith nlhkabu

repo: pypa/warehouse


text:
Comment out project dependencies tab

Commented out project dependencies tab for issue https://github.com/pypa/warehouse/issues/1309

I think this is probably fine, but @nlhkabu might want to take a look to make sure!

Thanks for the PR @TheJJ100100
Can we please use Jinja2 block comments rather than HTML comments - this will prevent it from rendering in the HTML source.

Another option would be to use the {# ... #} syntax.

@nlhkabu Is this correct? @nlhkabu https://github.com/pypa/warehouse/pull/1346/commits/89175c76c575cfe27b9d2bff2f4f75126ddf511a

Looks good to me @TheJJ100100 - assuming all checks pass this is ready to merge :)

:tada: Thanks @TheJJ100100

Thanks @nlhkabu

source: gharchive/pull-request

authors: TheJJ100100 berkerpeksag dstufft nlhkabu

license_type: permissive

license_source: github-api


text:
Update help link to remove decommissioned mailing list

Per https://groups.google.com/d/msg/pypa-dev/rUNsfIbruHM/LCEx-CB5AgAJ
the pypa-dev Google Group is now decommissioned.
Instead, in the FAQ, we point users to Discourse.
Signed-off-by: Sumana Harihareswara sh@changeset.nyc

@di I may have missed something in the contributor documentation -- how should I have created updated translations to include in my commit?

@brainwane: #8022

Thanks!

authors: brainwane di


text:
Add support for building coordinate system with from_cf/to_cf

Since WKT (or PROJ JSON) is the backend for the CF conversions, additional support for different units and axis order are now possible. Currently the x/y axis order and units of meters for projected degrees for geographic are assumed.
http://cfconventions.org/cf-conventions/cf-conventions.html#coordinate-system
Examples of input units can be accessed from the coordinates:
http://cfconventions.org/cf-conventions/cf-conventions.html#coordinate-types
  double y(y);
    y:units = "km";
    y:long_name = "y coordinate of projection";
    y:standard_name = "projection_y_coordinate";
  double x(x);
    x:units = "km";
    x:long_name = "x coordinate of projection";
    x:standard_name = "projection_x_coordinate";
  double lat(y, x);
    lat:units = "degrees_north";
    lat:long_name = "latitude coordinate";
    lat:standard_name = "latitude";
  double lon(y, x);
    lon:units = "degrees_east";
    lon:long_name = "longitude coordinate";
    lon:standard_name = "longitude";

Additionally, the vertical component can be supported:
http://cfconventions.org/cf-conventions/cf-conventions.html#vertical-coordinate
axis_name:units = "meters" ;
axis_name:positive = "down" ;

See also: https://github.com/cf-convention/cf-conventions/issues/223

Horizontal dimensions are those whose coordinate variables have an axis attribute of X or Y, or a units attribute indicating latitude and longitude.

Issues that would help with this:

https://github.com/cf-convention/cf-conventions/issues/247
https://github.com/cf-convention/cf-conventions/issues/248

This looks useful: https://github.com/SciTools/cf-units
Using:  m.convert(1, "m") on any unit should get the unit conversion factor.
Not going to include in pyproj as it adds unnecessary dependencies for a piece of functionality that may or may not be used. Instead, I am leaning towards documentation for how to do it yourself.

https://github.com/OSGeo/PROJ/blob/master/data/sql/unit_of_measure.sql

Can do fraction of unit - this can be used for unit conversion factor:
>>> from cf_units import Unit
>>> u = Unit("0.5 m")
>>> u.convert(1, "m")
0.5

source: gharchive/issue

license: mit

license_source: bigquery


text:
Impossible to reach webserver once built

Thanks to the previous #42, the webserver builds successfully on Rpi.
However, it seems not possible to reach it (either localy or from another machine on the network)
I receive the following error ``curl: (56) Recv failure: Connection reset by peer  when doing a curl http://localhost:8002/docsto reach the documentaion.
Having no time to investigate further, I am opening this issue, hoping that this just an oversight from my side and it will quickly closed :)
Thanks a lot

@fe51 this is just à PORT issue I will fix this today 😉

I had this port mapping issue in mind! Coool :)

repo: pyronear/pyro-engine


text:
Potential bug in generalized TDDFT/spinor X2C TDDFT

Hi, I recently tried out some two-component tddft functionalities in pyscf and noticed there might be some problem in the current implementation. In principle, if I use a gks reference to do a tddft calculation and don't involve any spin orbit coupling, I should get all singlet and triplet states from a normal rks-tddft calculation. I made a simple example here to demonstrate this problem
from pyscf import gto, scf, tddft
mol = gto.M(atom='''
        Cl 0.0 0.0 0.0
        Cl 1.8 0.0 0.0
''',
        basis='def2svp',
        unit='A')
mf = scf.RKS(mol,'pbe')
mf.kernel()
td = mf.TDA()
td.singlet=False
td.nstates=10
e_trip, _ = td.kernel()
td.singlet=True
td.nstates=10
e_sing, _ = td.kernel()

print('GKS-TDDFT')
mf = scf.GKS(mol,'pbe')
mf.kernel()
td = mf.TDA()
td.nstates=20
e, _ = td.kernel()

The output I get is
Excited State energies (eV)
[ 4.12501912  4.12501912  8.04737914  8.04737914  9.24665838 14.76025357
 14.76025357 15.50539365 18.48949197 18.48949197]
Excited State energies (eV)
[ 5.15609534  5.15609534  9.05915059  9.05915059 12.87068189 15.29182477
 15.29182477 17.46449571 19.38660315 19.38660315]
GKS-TDDFT
converged SCF energy = -919.661959801975  <S^2> = 8.8817842e-15  2S+1 = 1
Excited State energies (eV)
[ 4.12501912  4.12501912  4.57758845  4.57758845  4.57758845  4.57758845
  5.15609534  5.15609534  8.04737914  8.04737914  8.52897941  8.52897941
  8.52897941  8.52897941  9.05915059  9.05915059  9.24665838 10.17312645
 10.17312645 12.87068189]

In the last GKS-TDDFT calculation, the 3rd-6th root, 11th-14th root does not show up in any of the rks-tddft calculation.
If not doing TDDFT but doing TDHF, the GHF-TDHF result then recovers the RHF-TDHF singlet and triplet excitations in the absence of spin orbit coupling. Thus, I suspect there might be some problem with GKS-TDDFT itself. Do you have any clues Qiming @sunqm?

They are triplet states, corresponding to the HOMO_alpha -> LUMO_beta and HOMO_beta -> LUMO_alpha excitation. In theory, if you use mcfun functional, the spin-flip excitation triplets in GKS should be degenerated with the triplet states you obtained from RKS-TDDFT. There are four degenerated HOMO orbitals, therefore you get four states. The RKS and UKS LDA implementation are not able to couple spin flip excitation since the spin-flip matrix is not computed. In GKS, the spin-flip terms are computed although their values are zero. Such excitations are also the egienvectors of the GKS response kernel. The HF exchange of TDHF (and TDDFT of hybrid functionals) can couple the spin-flip excitation.

There is no spin-orbit coupling in this calculation, and therefore, the GKS triplet states should be identical with RKS triplet states, since there are two degenerate triplets in RKS case, then in GKS, I should see 6 degenerate states with from root 3 to root 9, there shouldn't be a four-fold degeneracy and a two-fold degeneracy that splits this triplet by over half eV.

The collinear functional rather than non-collinear functional will be used in the SCF or TDDFT/TDA calculations at the scf object built by  "scf.GKS(mol,'pbe')" , in fact. Correspondingly, the kernel given by collinear functional can not describe the six-fold degeneracy in excited energies.  A noncollinear functional, such as multi-collinear or locally collinear functional, can give this  six-fold degeneracy correctly, with a calculation keyward set as "mf.collinear = 'mcol'". An example is given below.
print('GKS-TDDFT')
mf = scf.GKS(mol,'pbe')
mf.collinear = 'mcol'
mf.spin_samples = 266 # the number of sample points in spin space
mf.kernel()
td = mf.TDA()
td.nstates=20
e, _ = td.kernel()
with output
GKS-TDDFT
converged SCF energy = -919.661959801974  <S^2> = 7.283063e-14  2S+1 = 1
Excited State energies (eV)
[ 4.12501865  4.12501865  4.1250189   4.1250189   4.12501916  4.12501916
5.15609516  5.15609516  8.04737852  8.04737852  8.04737867  8.04737867
8.04737882  8.04737882  9.05915017  9.05915017  9.24665744  9.24665861
9.24665978 12.87068219]

Related to #1878 . Should be fixed with new MCfun.

authors: Haskiy sunqm xubwa

repo: pyscf/pyscf


text:
Invite token needs to be updated to not be Matt's test token

We need to create a new admin user (pyslackers-admin?) to create a Legacy Token with and add it to pyslackers/ansible
Note: requires an admin

This doesn't really matter, it includes my name but I don't hide it a ton online. We can evaluate this later.

repo: pyslackers/website-old


text:
Fix warning messags in tests; update rlocus/pzmap limits

This PR fixes some warning messages that were showing up due to bad default limits in root locus plots and pole-zero diagrams.
(There are still a few warnings that show up in unit tests, but these seem to be due to some deprecations that matplotlib needs to fix and some strange "divide by zero" errors in computing determinants that must be in numpy or openblas.)

coverage: 94.416% (-0.009%) from 94.425%
when pulling dea3821e5f49ff1db4a43436f48787cabfaf7500 on murrayrm:fix_warnings-30Mar2024
into 4d878a966ca576f53b0d2ae9fd93ce598f60d748 on python-control:main.

authors: coveralls murrayrm

repo: python-control/python-control


text:
Image Collage

Script Title -
Image Collage using Python
Brief -
A script which is used to make 2X2 image collage and the final image can be saved in the system.
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md (using this template) in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x] Python

Happy Coding

@pawangeek  I would like to work on this issue can you please assign it to me.

would be happy to work on it. Kindly assign it to me.

Script Title -
Image Collage using Python Brief - A script which is used to make 2X2 image collage and the final image can be saved in the system.
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md (using this template) in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x]  Python

Happy Coding

would be happy to work on it. Kindly assign it to me. Hope to get it done in a week.

you can see the example of above explaination in my password manager project https://github.com/dth99/password-manager

repo: python-geeks/Automation-scripts

license: MIT


text:
Tornado example implementation

Why leave Tornado out of the fun of example implementations?

I'm really interested in helping on this one. My plan is to use Hyper in a Tornado-based Apple Push Notification Server once they release their HTTP/2-based protocol v3. (date unknown)

Nice! So, feel free to start playing around with the Twisted example and seeing how it might port to Tornado.

Can I get example of using flask, tornado and hyper together?

@akshatjain1995 Using hyper-h2 in what form? As a server? As a client?

@Lukasa As a server

See #304.

@Lukasa Thank you so much

authors: Lukasa akshatjain1995 greencoder


text:
String with German Umlaut as core property

Hello,
I try to set a unicode string which contains a German Umlaut as document.core_properties.subject with the following code:
#!/usr/bin/python
# -*- coding: utf-8 -*-

from docx import Document

document = Document()
document.core_properties.subject = u'Jürgen Somename'

But an error occurs:
Traceback (most recent call last):
  File "C:/test_docx.py", line 7, in <module>
    document.core_properties.subject = u'J��rgen Somename'
  File "C:\Python27\lib\site-packages\docx\opc\coreprops.py", line 123, in subject
    self._element.subject_text = value
  File "C:\Python27\lib\site-packages\docx\oxml\coreprops.py", line 184, in subject_text
    self._set_element_text('subject', value)
  File "C:\Python27\lib\site-packages\docx\oxml\coreprops.py", line 299, in _set_element_text
    value = str(value)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 1: ordinal not in range(128)

When I remove  value = str(value) from docx\oxml\coreprops.py line 299 everything works fine.
Is it necessary to change unicode to str in _set_element_text()?
Can I avoid this error by changing the encoding or something else?
Thanks

For me it works to change line 299 in docx\oxml\coreprops.py to
value = unicode(value)

I don't think that solution is quite general because it doesn't specify an encoding. The unicode() function doesn't actually quite do what it sounds like. Also, there's no unicode() function in Python 3 IIRC.
However there's a function in python-pptx at pptx.compat.to_unicode() that should do the trick. I'd have to spend some quality time to look through the design notes and tests to be sure, but if someone wants to transplant that and get it working with tests I'd be open to a patch.

authors: julmayer scanny

repo: python-openxml/python-docx


text:
Add Kerberos authentication support

As of version 3.4, Zookeeper allows authentication via Kerberos, but at the moment only the Java client supports it. Are there plans to add this to Kazoo in the near future?

@mkomitee, do you have your current patches pushed somewhere?
We are going to have a look (we use PyKerberos, not PyGSSAPI) to see how long it would take.

I'll see if I can dig them up.

Thanks, right now we went up with SASL module in https://github.com/python-zk/kazoo/pull/284

I submit #287 to serve as a reference. I hope it helps.

I'd be happy to merge a new PR for this, until there's more traction on this I'm closing this issue.

authors: bbangert dcl mkomitee romainr

repo: python-zk/kazoo


text:
Make a new release (2.1 or 2.0.1)

Could you make a release from master, as it contains a lot of bugfixes?

Any idea why a release might be blocked? It'd be great to have a new release :)

Should this be closed now?

Andddd closed!

authors: TheSriram harlowja mdevaev philipcristiano


text:
Update Continuous Integration to ZooKeeper 3.5.3-beta

Currently, .travis.yml uses the to-be-released ZOOKEEPER_VERSION=3.5.2-alpha. The current release (as of 2017-08-24) of the 3.5 line is 3.5.3-beta. Unless there is some motivation to continue to test against the old ZK server, .travis.yml should be updated to use the newer version.

Great idea!
Pull request welcome if you want to update it. Otherwise I'll try to do it in the next week or so.

So this is somewhat annoying...it seems that the file fetched in ensure-zookeeper-env will be zookeeper-3.5.3-beta.tar.gz. Despite the .tar.gz file suffix, it is actually a non-gzipped tarball, which makes the tar -zx fail. Changing this to tar -x works, but of course breaks all the properly-compressed files. Aside from opening a bug against ZK's packaging, I'm not sure what to here.

Ugh, that's no fun.
Can you open a ticket on the Zookeeper Jira and link back to it here?
Generally I've found that team is reasonably responsive, especially to something like this which sounds like a very annoying packaging bug that is likely to bite a lot of folks.

Bug is ZOOKEEPER-2885. Hopefully I'll get an email when it's fixed.

Perfect, as long as you're a watcher on the JIRA ticket you'll get an email...

@tgockel now that this is fixed upstream, do you want to submit a PR containing your commit that fixes this?

It's marked as fixed, but the file hasn't propagated out to everywhere...there's some likelihood that it will not ever in a lot of mirrors, since people usually expect artifacts to be permanent.

Is it still breaking on travis? That's really the point here, so if it's just their cache that needs updating I can file a bug there...

Yeah...3.5.3 is beta anyway :-)

authors: jeffwidman tgockel


text:
asyncio.Condition() in async with - dry

The following doesn't work. The equivalent in threading works.
cond = asyncio.Condition()
async with cond as c:
    await c.wait()

Considering the DRY principle, I think asyncio/locks.py:_ContextManagerMixin.__aenter__ should return self instead of None:
    @coroutine
    def __aenter__(self):
        yield from self.acquire()
        return self

PEP492 actually doesn't mention anything about returning None. Iinstead it explicitly mentions VAR = await aenter in the pseudocode example https://www.python.org/dev/peps/pep-0492/#new-syntax and the example with lock is a few paragraphs afterwards.
Opinions? Did I miss anything?

Your PR brings non-consistence with threading module.
with threading.Condition() as lock:
    ...

returns lock status, not Condition itself.
lock status is just bool value:

True for acquired lock
False for try to lock but failure for timeout reason.

Since asyncio has no timeout for locking the return value from context manager should be always True.
Now it's None, which is not bad -- nobody will check always true conditions.

@asvetlov Thanks for the explanation. I should have looked more carefully in threading. It is still slightly against DRY and the way normal Contexts work. Will give the PEP's another read, if anything we should explicitly mention it in there if it's missing.

Technically context manager may return any object, not itself.
It's rare but possible and makes sense in some contexts.
Anyway, changing semantic to not compatible with threading is worse than supporting existing approach (while the approach maybe is not very obvious).
From other hand you may think that acquiring lock from condition is an operation which returns something new (an information about acquirement) but not condition instance itself.

@gvanrossum I did not await a response but what I meant by DRY is that the last statement #3 looks the cleanest.
#1
async with self.state[topic].conditions[id]:
    self.state[topic].conditions[id].wait()

#2
cond = self.state[topic].conditions[id]
async with cond:
    cond.wait()

#3
async with self.state[topic].conditions[id] as c:
    c.wait()

But this won't allow returning the True/False return values when asnycio will have timeouts. If i might go even furher I would suggest to standardize both asyncio and threading on returning the object and introducing is_locked() API. This would align asyncio/threading Contexts with normal Contexts and make the API for (R)Lock and Condition (is_locked) more similar to Event (is_set).
async with self.state[topic].conditions[id] as c:
    if c.is_locked():
        c.wait()

Compared to what one would write today, it is more elegant and simple.
with self.state[topic].thread_conditions[id] as flag:
    if flag:
        self.state[topic].thread_conditions[id].wait()

or
cond = self.state[topic].thread_conditions[id]
with cond as flag:
    if flag:
        cond.wait()

Furthermore, one cannot specify the timeout in the with statement, so would probably be also a nice idea to implement a __call__ wrapper that passes the parameters to acquire() so you can do something like this:
with cond(timeout=1.0) as c:
    if c.is_locked():
        c.wait()

FWIW, setting a timeout on a lock using a with statement is not supported
in threading. There is no way to pass the timeout (even though acquire()
does take a timeout). The idea would be absurd -- what would you do inside
the with statement if you didn't get the lock? So returning True there is
nonsense too. It should just return None to indicate that it has no
information.

@gvanrossum Here is the working 'hack' to exemplify threading.
import threading

class CallableCondition(threading.Condition):
    def __call__(self, *args, **kwargs):
        self.args = args
        self.kwargs = kwargs
        return self

    def acquire(self):
        threading.Condition.acquire(*self.args, **self.kwargs)

    def is_locked(self):
        return self._lock.acquire(False)

    def __enter__(self):
        self._lock.__enter__()
        return self

x = CallableCondition()
with x(timeout=1.0) as f:
    if f.is_locked():
        f.wait(timeout=2.0)

authors: asvetlov dbivolaru gvanrossum

repo: python/asyncio


text:
is black playground ok ?

submitting this:
SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
                       "Environment", SMTO_ABORTIFHUNG, 5000)

I get that, with a coma after last parameter 5000
SendMessageTimeout(
    HWND_BROADCAST,
    WM_SETTINGCHANGE,
    0,
    "Environment",
    SMTO_ABORTIFHUNG,
    5000,
)

I suspect this is an error

well, apparently it's not forbidden to have a trailing coma

repo: python/black


text:
[Coverage] ValueError: The meta val for input node max_pool2d_default is of type : <class 'tuple'>

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/execution_context.py", line 156, in _execute_function
    fire.Fire(func, unwrapped_args)
  File "/usr/local/lib/python3.10/dist-packages/fire/core.py", line 141, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
  File "/usr/local/lib/python3.10/dist-packages/fire/core.py", line 466, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
  File "/usr/local/lib/python3.10/dist-packages/fire/core.py", line 681, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/correctness/correctness_script.py", line 93, in correctness
    comp_output = runner.infer(sample)
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/runners/base.py", line 325, in infer
    output = self.infer_impl(feed_dict, *args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/runners/torch.py", line 94, in infer_impl
    outputs = self._infer(feed_dict=feed_dict)
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/runners/torch.py", line 135, in _infer_v1
    outputs = self._loaded_model(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1714, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1725, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/eval_frame.py", line 434, in _fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1714, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1725, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 1121, in __call__
    return self._torchdynamo_orig_callable(
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 948, in __call__
    result = self._inner_convert(
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 472, in __call__
    return _compile(
  File "/usr/local/lib/python3.10/dist-packages/torch/_utils_internal.py", line 85, in wrapper_function
    return StrobelightCompileTimeProfiler.profile_compile_time(
  File "/usr/local/lib/python3.10/dist-packages/torch/_strobelight/compile_time_profiler.py", line 129, in profile_compile_time
    return func(*args, **kwargs)
  File "/usr/lib/python3.10/contextlib.py", line 79, in inner
    return func(*args, **kwds)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 817, in _compile
    guarded_code = compile_inner(code, one_graph, hooks, transform)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/utils.py", line 233, in time_wrapper
    r = func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 636, in compile_inner
    out_code = transform_code_object(code, transform)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/bytecode_transformation.py", line 1270, in transform_code_object
    transformations(instructions, code_options)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 178, in _fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/convert_frame.py", line 582, in transform
    tracer.run()
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/symbolic_convert.py", line 2476, in run
    super().run()
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/symbolic_convert.py", line 904, in run
    while self.step():
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/symbolic_convert.py", line 816, in step
    self.dispatch_table[inst.opcode](self, inst)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/symbolic_convert.py", line 2667, in RETURN_VALUE
    self._return(inst)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/symbolic_convert.py", line 2652, in _return
    self.output.compile_subgraph(
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/output_graph.py", line 1102, in compile_subgraph
    self.compile_and_call_fx_graph(tx, list(reversed(stack_values)), root)
  File "/usr/lib/python3.10/contextlib.py", line 79, in inner
    return func(*args, **kwds)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/output_graph.py", line 1324, in compile_and_call_fx_graph
    compiled_fn = self.call_user_compiler(gm)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/utils.py", line 233, in time_wrapper
    r = func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/output_graph.py", line 1415, in call_user_compiler
    raise BackendCompilerFailed(self.compiler_fn, e).with_traceback(
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/output_graph.py", line 1396, in call_user_compiler
    compiled_fn = compiler_fn(gm, self.example_inputs())
  File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/repro/after_dynamo.py", line 129, in __call__
    compiled_gm = compiler_fn(gm, example_inputs)
  File "/usr/local/lib/python3.10/dist-packages/torch/__init__.py", line 2223, in __call__
    return self.compiler_fn(model_, inputs_, **self.kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/backend/backends.py", line 44, in torch_tensorrt_backend
    return DEFAULT_BACKEND(gm, sample_inputs, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/backend/backends.py", line 52, in aot_torch_tensorrt_aten_backend
    return _pretraced_backend(gm, sample_inputs, settings)
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/backend/backends.py", line 108, in _pretraced_backend
    trt_compiled = compile_module(
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/_compiler.py", line 383, in compile_module
    submodule_inputs = partitioning.construct_submodule_inputs(submodule)
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/partitioning/common.py", line 111, in construct_submodule_inputs
    raise ValueError(
torch._dynamo.exc.BackendCompilerFailed: backend='torch_tensorrt' raised:
ValueError: The meta val for input node max_pool2d_default is of type : <class 'tuple'>. Supported types: torch.Tensor|FakeTensor|torch.SymInt
Set TORCH_LOGS="+dynamo" and TORCHDYNAMO_VERBOSE=1 for more information
You can suppress this exception and fall back to eager by setting:
    import torch._dynamo
    torch._dynamo.config.suppress_errors = True
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/pipelines/pipeline.py", line 121, in _execute_unit
    command_output = execution_unit.command().run(
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/base.py", line 127, in run
    output = self._run(*args, **_filter_dict_for_func(kwargs, self._run))
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/correctness/correctness.py", line 150, in _run
    context.execute_python_script(
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/execution_context.py", line 142, in execute_python_script
    self._execute_function(func, unwrapped_args, allow_failure, cmd)
  File "/usr/local/lib/python3.10/dist-packages/model_navigator/commands/execution_context.py", line 168, in _execute_function
    raise ModelNavigatorUserInputError(cmd_to_reproduce_error) from e
model_navigator.exceptions.ModelNavigatorUserInputError: Command to reproduce error: /bin/bash torch/reproduce_correctness-torchtensorrtcompilerunner.sh
2024-09-01 15:27:29.211 | INFO     | MainProcess | /usr/local/lib/python3.10/dist-packages/model_navigator/pipelines/pipeline.py:148 - Execution time: 57.80[s]

This is resolved by the fix in PR #3002 in the file py/torch_tensorrt/dynamo/lowering/passes/replace_max_pool_with_indices.py.

repo: pytorch/TensorRT


text:
[docs] use versionadded, versionchanged and deprecated directive

📚 Documentation
Use .. versionadded::, .. versionchanged:: and .. deprecated:: directive, so that user knows which features are added / changed / deprecated in which version and they can navigate the docs easily without changing the docs from version to version.
Ref: https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-versionadded

Locking the conversation to consolidate the discussion to https://github.com/pytorch/text/issues/1130
I will not close the issue as this is very useful suggestion.

Locking the conversation to consolidate the discussion to https://github.com/pytorch/text/issues/1130
I will not close the issue as this is very useful suggestion.

This proposal was approved in https://github.com/pytorch/pytorch/issues/51197, so we can start working on / accepting PRs for this.

hello

authors: mthrok sathmali ydcjeff

repo: pytorch/audio


text:
[ROCm] add rocm wheels

This PR adds wheels for rocm. It is based on this PR for pytorch vision(https://github.com/pytorch/vision/pull/3575) that adds rocm wheels .
It works by creating a rocm version of the binary_linux_wheel build jobs that use pytorch/manylinux-rocm instead of manylinux-cuda102.

@micmelesse Let us know when this PR is ready. This looks like a good addition.

@michaelauli Can you rebase on the latest master, just in case? I fixed some of the macOS issues.

Thank you for the change. PR looks good to me, but let's not merge it until we understand why those builds are failing.

@mthrok I have rebased and force pushed.

@malfet Is  #1497 done?

HI @micmelesse
#1497 has been merged. Could you rebase ?

@mthrok @malfet I have rebased and everything passes.

authors: malfet micmelesse mthrok


text:
How to build encoder.json and dict.txt

I am training RoBERTa on a different language. I found how to build vocab.bpe using other BPE methods but not able to figure out how to get dict.txt and encoder.json.
Please suggest how to do this.

I am using sentencepiece BPE

You shouldn't need encoder.json at all.  Follow these instructions, and skip the "Next encode it with the GPT-2 BPE" section, and encode using your sentencepiece BPE.  The rest should be the same.

But in the preprocessing step there is srcdict argument and train.bpe valid.bpe test.bpe files are needed whereas I only got one model file and vocab from sentencepiece BPE.
 fairseq-preprocess \
    --only-source \
    --srcdict gpt2_bpe/dict.txt \
    --trainpref wikitext-103-raw/wiki.train.bpe \
    --validpref wikitext-103-raw/wiki.valid.bpe \
    --testpref wikitext-103-raw/wiki.test.bpe \
    --destdir data-bin/wikitext-103 \
    --workers 60

@lematt1991

The *.bpe files are the names of the BPE encoded files.  You would do something like:
for SPLIT in train valid test; do \
    cat wikitext-103-raw/wiki.${SPLIT}.raw | spm_encode --model=<model_file> --output_format=piece > wikitext-103-raw/wiki.${SPLIT}.bpe
done

And then:
fairseq-preprocess \
    --only-source \
    --trainpref wikitext-103-raw/wiki.train.bpe \
    --validpref wikitext-103-raw/wiki.valid.bpe \
    --testpref wikitext-103-raw/wiki.test.bpe \
    --destdir data-bin/wikitext-103 \
    --workers 60

By not specifying --srcdict it will generate a dictionary for you.

Does this solve your problem?  If so, do you mind closing this issue.  Thanks!

Closing due to inactivity

Hi, I am having a problem with training Roberta on Turkish. I followed your instructions and created bpe files with sentencepiece and then run fairseq-preprocess command. Everything seemed fine until I tried to get predictions from the model (the training was over without an error). I tried to make prescriptions using roberta.fill.mask, for example when I test it with roberta.fill.mask('Tugberk be Ferhat bir proje  çalışıyor.') it gives an error with decoding, an int base decoding error for '_bağırma'. Can you help me with how to get predictions from the model I am trying to train for Turkish. Idk at which step there is a mistake I make

what if dict.txt is not present and I have multiple data-bins (data-bin1:data-bin2:data-bin3, ec...), how can I create a general dict.txt that is valid for each data-bin and not create a new one for each of them that will also cause problems?

@lematt1991 lematt1991

What BPE are you using (sentencepiece, fastbpe, something else)? The encoder.json is specific to GPT2's BPE. The dict.txt file will get created when you preprocess your data using fairseq-preprocess
@lematt1991 please guide me how to create encoder.json using gpt-2 bpe for other language.

The *.bpe files are the names of the BPE encoded files. You would do something like:
for SPLIT in train valid test; do \
    cat wikitext-103-raw/wiki.${SPLIT}.raw | spm_encode --model=<model_file> --output_format=piece > wikitext-103-raw/wiki.${SPLIT}.bpe
done

And then:
fairseq-preprocess \
    --only-source \
    --trainpref wikitext-103-raw/wiki.train.bpe \
    --validpref wikitext-103-raw/wiki.valid.bpe \
    --testpref wikitext-103-raw/wiki.test.bpe \
    --destdir data-bin/wikitext-103 \
    --workers 60

By not specifying --srcdict it will generate a dictionary for you.

Hi @lematt1991, in case you want to use a specific dictionary, you should create by hand dict.txt, right? Afaik, fairseq-preprocess will generate the dictionary by looking at the unique tokens appearing in training, but in case some of the tokens in your original dictionary don't appear in the train set (e.g., placeholder tokens you want to reserve, or special tokens you may use in a future fine-tuning but not during pre-training), these will not be added to dict.txt, and there are no arguments to add them. In this case, one would have to manually concatenate them to dict.txt, with frequency 0?

repo: pytorch/fairseq


text:
BPE codes bug for Ru En model WMT 2019

I get error when I download the ru en model, WMT 2019 from this url https://github.com/pytorch/fairseq/blob/master/examples/translation/README.md. All files path(es) are good. Is this a bug or I need other settings?
Error: invalid line 1 in BPE codes file: с т 173158785
The line should exist of exactly two subword units, separated by whitespace
Example line of BPE is  bellow so there is a number at the end, and there are also multiple models.
Бе зопасности 358890
вы пу 358849
по в 358781
 from fairseq.models.transformer import TransformerModel
ru2en = TransformerModel.from_pretrained(
 '/root/models/ruen/wmt19.ru-en.ensemble/',
  checkpoint_file='model1.pt',
  data_name_or_path='/root/models/ruen/wmt19.ru-en.ensemble/',
  bpe='subword_nmt',
  bpe_codes='/root/models/ruen/wmt19.ru-en.ensemble/bpecodes'
)

Solution:  bpe="fastbpe"


text:
Best validation checkpoints are not updated properly

🐛 Bug
When training a translation model I set the flag --keep-best-checkpoints 5, to keep the 5 best validation checkpoints. I just noticed, that at the end of training this will not keep the 5 best checkpoints, but only those 5 that have been better than any checkpoint before.
I give an example for --keep-best-checkpoints 2:

epoch1 : BLEU 2   -> Files in run_dir:  checkpoint.best_bleu_2.pt
epoch2 : BLEU 6  -> Files in run_dir:  checkpoint.best_bleu_2.pt and checkpoint.best_bleu_6.pt
epoch3 : BLEU 4 -> Files in run_dir:  checkpoint.best_bleu_2.pt and checkpoint.best_bleu_6.pt

Expected behavior
I think after epoch 3 the checkpoint with BLEU 4 should be kept and not the one with BLEU 2.
Environment

fairseq Version (e.g., 1.0 or master): master (updated a couple of days ago)

I found the same problem of saving the best ckpts.

authors: shuo-git villmow


text:
How to perform jvps and not vjps?

Hi! Thanks for the working prototype, it would be a great addition to pytorch!
I'm currently using pytorch for research purposes, and I would like to implicitly compute jacobian-vector products (i.e. where the given vectors should multiply the "inputs" and not the "outputs" of the transformation).
Is there a jvp function? Is there a workaround?

I have possibly found a workaround to simulate jvp using vjp.
from functorch import vjp

def jvp(f, i):
    """
    Implementation of jvp using vjp.

    The jacobian of the vjp function is J^T.
    So to obtain Jv we have to use the vjp of the vjp function.
    """
    ans, f_vjp = vjp(f, i)
    _, f_vjp_vjp = vjp(f_vjp, torch.zeros_like(ans))
    return ans, lambda i: f_vjp_vjp((i,))[0]

It seems to be of acceptable performance, does torch optimizes such a computation?

@trenta3 Sorry for missing this - I think it was since it was closed very quickly :P
I don't think there's anything wrong with computing jvp using 2 vjps. The primary issue, from my understanding, is that this will take 2 function evaluations compared to the 1 from a proper jvp implementation. Of course, this is still way better than calling autograd.grad once per function output.
The "proper" way to do this is to use PyTorch's (experimental) forward-mode AD. You can see the tracking issue here: https://github.com/facebookresearch/functorch/issues/20, and try it out with functorch.experimental.jvp. Be warned that Pytorch's forward-mode AD is not mature yet, and you may run into forward-mode formulas that are missing.

@Chillee Thanks for the reply, very useful information indeed, especially the fact that by using two vjps I only loose a 2x factor.
I will subscribe to the other issue to see when the jvp function is mature enough!
Thank you for this great repository, that is essential for my research!

I will now close this issue as the jvp function is readily available.
Thank you very much for the great work!

Please let us know if you run into any other issues or have more feedback!

repo: pytorch/functorch


text:
Pt 2d integration

This is done using the new TensorFlattener API in https://github.com/pytorch/pytorch/pull/85039
To enable it:  import spdm.fsdp and use spdm.fsdp.is_available() to check if it's working.

I hope it is not too inconvenient, but I am renaming TensorFlattener to FSDPExtensions after receiving feedback from FSDP side since the name is more reflective. I am cleaning up the unit tests a bit and will push soon. There will be no semantic changes.
I can ping you once I have pushed.

I hope it is not too inconvenient, but I am renaming TensorFlattener to FSDPExtensions after receiving feedback from FSDP side since the name is more reflective. I am cleaning up the unit tests a bit and will push soon. There will be no semantic changes.
I can ping you once I have pushed.

Can't never complaint about better naming. <3 for leading the effort on getting the extensions merged into PT.

authors: awgu kumpera

repo: pytorch/tau


text:
There is a mistake in Example of "class DLRM(nn.Module)" ?

dense_arch_layer_sizes=[20],   But eb1_config and eb2_config 's embedding_dim == D
Code:https://github.com/pytorch/torchrec/blob/2813bcd484bdde5c3081f9690fb0b0e7401f6ddd/torchrec/models/dlrm.py#L486
the example commet will 'raise ValueError('
https://github.com/pytorch/torchrec/blob/2813bcd484bdde5c3081f9690fb0b0e7401f6ddd/torchrec/models/dlrm.py#L530
I try it in colab

https://github.com/peitao/search-as-you-type/blob/master/test.ipynb
another mistake is "f2 is not pass to the model" in L503
https://github.com/pytorch/torchrec/blob/2813bcd484bdde5c3081f9690fb0b0e7401f6ddd/torchrec/models/dlrm.py#L503

Hi,
Thanks for the catch - we'll make the fix in the notebook

Made the fix to the docstrings in
https://github.com/pytorch/torchrec/pull/1136

authors: YLGH peitao

repo: pytorch/torchrec


text:
AdaptiveAvgPool2d in resnet not working with small images eg.64x64

When I try to forward a tensor of size Bx3x64x64 through resnet.ResNet(...),
at x = self.avgpool(x)
it complains
RuntimeError: Given input size: (512x2x2). Calculated output size: (512x-4x-4). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47

which does not make sense.
I found that the errors were gone if the AdaptivePool2d is intialized as
self.avgpool = nn.AdaptiveAvgPool2d(1) instead of self.avgpool = nn.AdaptiveAvgPool2d((1, 1))
It might be a bug in nn.AdaptiveAvgPool2d

This is very weird, because the error message that you have is from AvgPool2d. Maybe you have an older version of torchvision that doesn't have the nn.AdaptiveAvgPool2d improvement?

I think you should update the torchvision version and see if the issue is solved.

Just confirmed the bug on a clean conda environment with Python 3.6.8, Ubuntu18.04, cuda9.1
outputs of pip freeze | grep torch
torch==1.0.0
torchvision==0.2.1

To reproduce,
from torchvision.models.resnet import resnet18, resnet50, resnet101
import torch

for sz in (64, 96, 128, 256):
    for func in (resnet18, resnet50, resnet101):
        try:
            print('== Testing 3x{}x{} input for {}'.format(sz, sz, func))
            model = func()
            model.cuda()
            x = torch.FloatTensor(1, 3, sz, sz).cuda()
            model(x)
            print('!! Passed !!')
        except RuntimeError as e:
            print(e)

Output log on my side:
== Testing 3x64x64 input for <function resnet18 at 0x7fcac6297730>
Given input size: (512x2x2). Calculated output size: (512x-4x-4). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x64x64 input for <function resnet50 at 0x7fcac6297bf8>
Given input size: (2048x2x2). Calculated output size: (2048x-4x-4). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x64x64 input for <function resnet101 at 0x7fcac6297c80>
Given input size: (2048x2x2). Calculated output size: (2048x-4x-4). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x96x96 input for <function resnet18 at 0x7fcac6297730>
Given input size: (512x3x3). Calculated output size: (512x-3x-3). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x96x96 input for <function resnet50 at 0x7fcac6297bf8>
Given input size: (2048x3x3). Calculated output size: (2048x-3x-3). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x96x96 input for <function resnet101 at 0x7fcac6297c80>
Given input size: (2048x3x3). Calculated output size: (2048x-3x-3). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x128x128 input for <function resnet18 at 0x7fcac6297730>
Given input size: (512x4x4). Calculated output size: (512x-2x-2). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x128x128 input for <function resnet50 at 0x7fcac6297bf8>
Given input size: (2048x4x4). Calculated output size: (2048x-2x-2). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x128x128 input for <function resnet101 at 0x7fcac6297c80>
Given input size: (2048x4x4). Calculated output size: (2048x-2x-2). Output size is too small at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THCUNN/generic/SpatialAveragePooling.cu:47
== Testing 3x256x256 input for <function resnet18 at 0x7fcac6297730>
size mismatch, m1: [1 x 2048], m2: [512 x 1000] at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THC/generic/THCTensorMathBlas.cu:266
== Testing 3x256x256 input for <function resnet50 at 0x7fcac6297bf8>
size mismatch, m1: [1 x 8192], m2: [2048 x 1000] at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THC/generic/THCTensorMathBlas.cu:266
== Testing 3x256x256 input for <function resnet101 at 0x7fcac6297c80>
size mismatch, m1: [1 x 8192], m2: [2048 x 1000] at /opt/conda/conda-bld/pytorch_1544174967633/work/aten/src/THC/generic/THCTensorMathBlas.cu:266

It is should be caused by a bug in SpatialAveragePooling.cu. But the simple fix in https://github.com/pytorch/vision/pull/697 should work it around for torchvision.

i think torchvision==0.2.1 does not have the AdaptiveAvgPool2d layer yet...

Still cannot solve this problem in the latest or 0.2.1 version torchvision.

@wangjinjie722 if you want to use a very small image size, you need to modify the network architecture, as we don't provide models for cifar-sized images, only for imagenet-sized

This is annoying and I experience the same problem when using 64x64 image size. Replacing with AdaptiveAvgPool2d fixed it.

@Quetzalcohuatl we already use AdaptiveAvgPool2d in resnet, so this shouldn't be a problem with torchvision 0.4 or 0.5

@fmassa I encountered this problem when dealing with se-resnext, so maybe these architectures can also be changed.

Just reporting, 64x64 images do not work for AvgPool2d as well.
    x = self.Avergepool(x)   File "/people/kimd999/bin/Miniconda3-latest-Linux-x86_64/envs/pytorch/lib/python3.8/site-packages/torch/nn/modules/module.py", line 550, in __call__     result = self.forward(*input, **kwargs)   File "/people/kimd999/bin/Miniconda3-latest-Linux-x86_64/envs/pytorch/lib/python3.8/site-packages/torch/nn/modules/container.py", line 100, in forward     input = module(input)   File "/people/kimd999/bin/Miniconda3-latest-Linux-x86_64/envs/pytorch/lib/python3.8/site-packages/torch/nn/modules/module.py", line 550, in __call__     result = self.forward(*input, **kwargs)   File "/people/kimd999/bin/Miniconda3-latest-Linux-x86_64/envs/pytorch/lib/python3.8/site-packages/torch/nn/modules/pooling.py", line 553, in forward     return F.avg_pool2d(input, self.kernel_size, self.stride, RuntimeError: Given input size: (512x4x4). Calculated output size: (512x-1x-1). Output size is too small

authors: Quetzalcohuatl fmassa githubssd kimdn lsqshr timonbimon wangjinjie722

repo: pytorch/vision


text:
Remove Python 3.6 from CI

Python 3.6 reached end of life on 23 Dec 2021(https://endoflife.date/python).
Failing test: https://app.circleci.com/pipelines/github/pytorch/vision/13644/workflows/b9b3b259-1f6c-4cfd-8f3b-f42e9db075d0/jobs/1097625 (due to pyav installation)
cc @seemethere

I'm happy to see this, thanks for working on it @prabhat00155 .
Has pytorch core confirmed that they would drop 3.6 in the next release? We discussed it in https://github.com/pytorch/pytorch/issues/69005 but there was no definitive decision last time I checked. Perhaps @seemethere @malfet could confirm that core is indeed going to drop 3.6?

We intend to drop 3.6 since it has hit EOL

authors: NicolasHug prabhat00155 seemethere


text:
move datapoints compat to prototype datasets

This is the same idea as https://github.com/pytorch/vision/pull/6663#discussion_r982567437. Whatever we decide there, can also be applied here.
cc @bjuncek

If we move forward with #7170 (and it looks like it so far), this PR can be reduced to converting everything to a plain torch.Tensor and making sure that an image is coming first in the sample.

I've run the prototype datasets tests locally and they are passing.


text:
[Release only] Pin test-infra repo for 2.1 release

This needs to be pin in addition to the action branch

Replace by https://github.com/pytorch/vision/pull/8045


text:
Sheets OSTRAVA and VENUE

I updated the sheet OSTRAVA with the info provided by Adel. The part with the credit ticket for public transport will be updated once more info is available. This is also written on the website. I checked the sheet VENUE as well, from my point of view it looks ok but please double check. Let me know if  further amendments are required.

Please, check whether everything is ok. I checked it several times but still I could have overseen something.

Closing as this event was cancelled due to covid. Thank you for your work, it is appreciated!

authors: Giraafje benabraham


text:
Fix mistake in VectorField's angle conversion if invert_axes

Title says it all.

Thanks again, very much appreciated!

authors: philippjfr poplarShift

repo: pyviz/holoviews