text:
Real exception has been swallowed during call chain

When i tried make sql-query on non-existent table i got exception of type
android.database.sqlite.SQLiteException: no such table: persons (code 1): , while compiling: SELECT * FROM persons in PreparedGetListOfObjects.executeAsBlocking():122.
But later going thru call chain this type was hidden and only StorIOException("Error has occurred during Get operation. query... was in error message.
imho this is not so clear as it may be.

Yes, we wrap exception into StorIOException.
Exception message should include query that may contain mistake.
But we don't swallow the original exception - it is places as cause.
throw new StorIOException("Error has occurred during Get operation. query = " + (query != null ? query : rawQuery), exception);

Are there original exception in stack trace?

Yes i saw that, thanks. But real error is not in "bad query" or something like that. Root mistake was in non-existence table. Maybe reasonable for show it for client? In my case i wasted some time and bulk of breakpoints to  solve the problem.

Cause of the exception should be shown in stacktrace with its message, wrapping should not be a problem!

authors: ValeriusGC artem-zinnatullin nikitin-da

repo: pushtorefresh/storio


text:
do markers update with the tile?

I am trying to show the location of something that moves through the map.
the coords arrive via socket.io but the map doesn't render when the markers are added to the array (the array starts empty but it then gets objects from the socket.io)
i thought that having updateInterval on TileOptions would do it but turns out it wasn't the case.
maybe a solution would be to call the function to draw the markers with the updateInterval?
thanks

I'll look into this asap.
If you have time contributing that'd be perfect! :)

sure, i'll try to get the call thank you

hi, im also trying to use the flyTo function to pan the map to different coords after it loads
so today im trying to do both things

Oki! I'll try to fix asap.

so today i found a way to do the markers thing
in the node_modules/react-native-leaflet-ts/src/Leaflet/index.tsx file, i added an interval for the sendAction of the markers
it now looks like this:
setInterval(() => {       if (markers) sendAction({ markers });     }, 100)
but the issue now is deleting them, i was trying to use map.removeLayer() with a setTimeout() on /node_modules/react-native-leaflet-ts/android/src/main/assets/Leaflet.html but it didn't work

i managed to resolve the flyto part using useState and useEffect.
i think i can do the same thing with the markers.
by the way, i think you should change injectJavascript from string to void when you declare the props since you are going to run a script. having it on string will throw an error saying that it expects a string, not void. :)

Nice! I'll look into it!

source: gharchive/issue

authors: loloide putteabrahamsson

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 TV Manager is down

In c8bf188, TV Manager ($SITES_URL_TV_MANAGER) was down:

HTTP code: 502
Response time: 591 ms

Resolved: TV Manager is back up in d379327.


text:
Events

I tried to listen for some events, like this:
document.body.addEventListener('htmx:beforeRequest', function(evt) {
    console.log('htmx:beforeRequest');
});

document.body.addEventListener('htmx:afterRequest', function(evt) {
    console.log('htmx:afterRequest');
});

document.body.addEventListener('htmx:beforeOnLoad', function(evt) {
    console.log('htmx:beforeOnLoad');
});

document.body.addEventListener('htmx:afterOnLoad', function(evt) {
    console.log('htmx:afterOnLoad');
});

But only beforeRequest and beforeOnLoad are triggered.
I am missing something?
Any idea?

Sounds like this issue resurfacing: https://github.com/bigskysoftware/htmx/issues/79
Please create an issue in the htmx Github repo for this.

authors: bencroker rauwebieten

repo: putyourlightson/craft-sprig


text:
first_solar_spectral_correction deprecation points to a non-existent alternative

Describe the bug
This line  points calls to pvlib.atmosphere.first_solar_spectral_correction to pvlib.spectrum.spectral_factor_firstsolar which doesn't exist. The deprecation should point to pvlib.spectrum.mismatch.spectral_factor_firstsolar
Versions:

pvlib.__version__: 0.10.1

Hey I would like to work on this issue, may I?

@ai-naymul yes, please!

It's true that spectral_factor_firstsolar lives in pvlib/spectrum/mismatch.py, but the spectrum __init__.py file imports it into the pvlib.spectrum namespace: https://github.com/pvlib/pvlib-python/blob/main/pvlib/spectrum/init.py#L7
So the function is indeed accessible with pvlib.spectrum.spectral_factor_firstsolar:
In [133]: pvlib.spectrum.spectral_factor_firstsolar
Out[133]: <function pvlib.spectrum.mismatch.spectral_factor_firstsolar(precipitable_water, airmass_absolute, module_type=None, coefficients=None, min_precipitable_water=0.1, max_precipitable_water=8)>

This is also the name that is used in the docs: https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.spectrum.spectral_factor_firstsolar.html
So I think it makes sense to leave the deprecation message as-is.

OK, my mistake. I don't quite grok how that import works and couldn't find the function when I was looking for it.

authors: ai-naymul cwhanse kandersolar

repo: pvlib/pvlib-python


text:
Error when add a developer controller block

I get error when add Developer Controller Block:
"Invalid argument supplied for foreach() (View: ...\vendor\pvtl\voyager-page-blocks\resources\views\vendor\voyager\page-blocks\edit-add.blade.php)"
Can you help me?

Thanks for the report @thieuns88. This has been fixed in 0.8.16.

repo: pvtl/voyager-page-blocks


text:
User Container Metrics - Understanding Scaling

Measurements done using docker stats.
Just running a pwncollege-challenge container uses ~4MiB of memory. This low number makes sense, it's just a single bash process. In this state, neither VS Code, nor the desktop, are accessible. Of course. The processes aren't running.
After container start, starting VS code brings us up to ~72MiB, and then after a few moments settles down to ~58 MiB.
After container start, starting the desktop brings us up to ~174MiB.
After container start, starting both (aka /opt/pwn.college/docker-entrypoint.sh) brings us up to ~231MiB, and then after a few moments settles down to ~222MiB.

Looking at our user containers at a random point in time (Saturday @ ~4:00pm MST, 1 day before a 365 final deadline), we have:
import subprocess
import statistics

output = subprocess.check_output('docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}" | grep user_', shell=True)

cpus = []
mems = []
for line in output.strip().decode().splitlines():
    user, cpu, mem, *_ = line.split()
    cpu = float(cpu[:-1]) / 100
    mem = float(mem[:-3]) * (1024 if mem[-3:] == 'GiB' else 1)
    cpus.append(cpu)
    mems.append(mem)

print("### cpu")
print(f"- count: {len(cpus)}")
print(f"- total: {sum(cpus):.2f} vcpu")
print(f"- mean: {statistics.mean(cpus):.2f} vcpu")
print(f"- median: {statistics.median(cpus):.2f} vcpu")
print(f"- min: {min(cpus):.2f} vcpu")
print(f"- max: {max(cpus):.2f} vcpu")
print()
print("### memory")
print(f"- count: {len(mems)}")
print(f"- total: {sum(mems):.2f} MiB")
print(f"- mean: {statistics.mean(mems):.2f} MiB")
print(f"- median: {statistics.median(mems):.2f} MiB")
print(f"- min: {min(mems):.2f} MiB")
print(f"- max: {max(mems):.2f} MiB")

cpu

count: 211
total: 13.16 vcpu
mean: 0.06 vcpu
median: 0.01 vcpu
min: 0.00 vcpu
max: 2.01 vcpu

memory

count: 211
total: 93785.55 MiB
mean: 444.48 MiB
median: 375.10 MiB
min: 221.00 MiB
max: 3246.08 MiB

User containers are constrained to 4vcpus, and 4GiB of memory.
Our current server has 40vcpu and 251.87 GiB of memory.
Of course, we use the server for more than user containers (web service, database, cache, etc), but ignoring this for now, this means we are using:

32.9% of our vcpus
36.4% of our memory

An obvious method for reducing memory consumption is to limit the starting of VS Code and the desktop until a user wants to use them. Probably, we want to be smarter than this for the user experience. We can keep track (in the user's home directory?) of the last time they accessed the dojo through VS Code / desktop, and automatically start it on container start if they have used it in the last week (or if their most recent method of interacting with the dojo was that method, depending on how easy it is for us to collect that level of information).
We already do a similar thing for the virtual machine, only starting it automatically if the challenge has a .ko.

What is left to do on this after https://github.com/pwncollege/dojo/commit/402fbf93af080fd64ca653c167f09bde29fe08c2 ?

repo: pwncollege/dojo


text:
🛑 NARLabs is down

In 551d9a4, NARLabs (https://www.narlabs.org.tw/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NARLabs is back up in d0cbbda.

repo: pwtsai/upptime


text:
Add back group methods - take 2

just running tests here, then will likely force push this to #274

ok @getzze, I think we're there.  I pulled it out into a new PR so that I could focus on a couple things.  I'd be happy to either force push this branch onto yours, or just add you as an author to the squash-merge here, whichever you prefer.
and, if you have time, I'd appreciate your eyes on this

I was checking the restrictions for using mypyc and some parts are not compatible with it, namely that you cannot delete attributes from classes and classes don't have __dict__.
Then maybe the implementation can be simplified by creating a factory function to create SignalGroup subclasses to be used in SignalGroupDescriptor, allowing passing a keyword argument with conflicting signals on subclassing SignalGroup, then just raise an error in SignalGroup creation if there is an attribute name conflict.
Also, we should call __set_name__ on conflicting Signals otherwise they have an empty name.
def signal_group_forbidden_attr(name: str):
    return name.startswith("_psygnal")

def signal_group_reserved_attr(name: str):
    reserved = set(dir(SignalGroup))
    return name in reserved or name.startswith("psygnal")

def factory_signal_group(name: str, signals: dict[str, Signal], strict: bool = False) -> SignalGroup:
    conflicts = {}
    for key, sig in signals.copy().items():
        if signal_group_forbidden_attr(key):
            # forbidden
            del signals[key]
            continue

        if signal_group_reserved_attr(key):
            conflicts[key] = sig
            del signals[key]

        # Special SignalInstance
        sig._signal_instance_class = _DataclassFieldSignalInstance

    if conflicts:
        Names = "Names" if len(conflicts) > 1 else "Name"
        Are = "are" if len(conflicts) > 1 else "is"
        warnings.warn(
            f"{Names} {sorted(conflicts)!r} {Are} reserved. You cannot use these "
            "names to access SignalInstances as attributes on a SignalGroup. (You "
            "may still access them as keys to __getitem__: `group['name']`).",
            UserWarning,
            stacklevel=2,
        )

    print(f"{signals=}, {conflicts=}")
    return type(name, (SignalGroup,), signals, reserved_signals=conflicts)

    def __init_subclass__(
        cls,
        strict: bool = False,
        reserved_signals: Mapping[str, Signal] = {},
    ) -> None:
        """Collects all Signal instances on the class under `cls._psygnal_signals`."""
        # Collect Signals and remove from class attributes
        # Use dir(cls) instead of cls.__dict__ to get attributes from super()
        forbidden = {
            k for k in dir(cls)
            if isinstance(getattr(cls, k), Signal) and (signal_group_forbidden_attr(k) or signal_group_reserved_attr(k))
        }

        if forbidden:
            raise TypeError(
                f"SignalGroup subclass cannot have attributes starting with '_psygnal'."
                f" Found: {forbidden}"
            )

        _psygnal_signals = {}
        for k in dir(cls):
            val = getattr(cls, k, None)
            if isinstance(val, Signal):
                _psygnal_signals[k] = val

        for k, sig in reserved_signals.items():
            sig.__set_name__(cls, k)
        cls._psygnal_name_conflicts = reserved_signals

        # Collect the Signals also from super-class
        # When subclassing, the Signals have been removed from the attributes,
        # look for cls._psygnal_signals also
        cls._psygnal_signals = {
            **getattr(cls, "_psygnal_signals", {}),
            **_psygnal_signals,
            **reserved_signals,
        }

        cls._psygnal_uniform = _is_uniform(cls._psygnal_signals.values())
        if strict and not cls._psygnal_uniform:
            raise TypeError(
                "All Signals in a strict SignalGroup must have the same signature"
            )
        super().__init_subclass__()

Thanks!

I was checking the restrictions for using mypyc and some parts are not compatible with it, namely that you cannot delete attributes from classes and classes don't have dict.

Can you make a test that fails according to what you think the issue would be?  Because we do test conflicts on both compiled and uncompiled code here... and it seems to be working fine

Also, we should call set_name on conflicting Signals otherwise they have an empty name.

👍

However, I have doubts if it's a good idea to have real and fake Signal attributes in SignalGroup.
An example of unexpected behavior:
class MyGroup(SignalGroup):
    sig: Signal[int]
    connect: Signal[bool]

hasattr(MyGroup, "sig")  # True
hasattr(MyGroup, "connect")  # True
delattr(MyGroup, "sig")  # success
delattr(MyGroup, "connect")  # AttributeError, trying to delete the method on `SignalGroup`

To go back to your example, why would somebody want to do hasattr(MyGroup, "sig")? If it's to check if the signal sig is in the group, then it's not a safe method, as conflicting signal names would point to the method anyway. One would need a dedicated function or classmethod to check if the Signal is in the class instead.
It seems safer to me to document well that SignalGroup is a special class, first that it has to be subclassed, second you can define the Signals attached to the group using syntactic sugar, although the Signals end up not being attributes of the class. So the primary way of subclassing SignalGroup would be with a factory function, the above example would just be syntactic sugar.

Can you make a test that fails according to what you think the issue would be? Because we do test conflicts on both compiled and uncompiled code here... and it seems to be working fine

I didn't test very well before posting, actually this code is not even working correctly...
I didn't know it was tested on compiled code also and that it worked fine, then forget about it then. What I understood from mypyc documentation is that these were the restrictions of native classes, but then SignalGroup is probably not a native class.

However, I have doubts if it's a good idea to have real and fake Signal attributes in SignalGroup.
An example of unexpected behavior:
class MyGroup(SignalGroup):
    sig = Signal[int]
    connect = Signal[bool]

hasattr(MyGroup, "sig")  # True
hasattr(MyGroup, "connect")  # True
delattr(MyGroup, "sig")  # success
delattr(MyGroup, "connect")  # AttributeError, trying to delete the method on `SignalGroup`

To go back to your example, why would somebody want to do hasattr(MyGroup, "sig")? If it's to check if the signal sig is in the group, then it's not a safe method, as conflicting signal names would point to the method anyway. One would need a dedicated function or classmethod to check if the Signal is in the class instead.
It seems safer to me to document well that SignalGroup is a special class, first that it has to be subclassed, second you can define the Signals attached to the group using syntactic sugar, although the Signals end up not being attributes of the class. So the primary way of subclassing SignalGroup would be with a factory function, the above example would just be syntactic sugar.

Quoting myself here, but with the factory function this unexpected behavior would go away, so I solved my own problem :laughing:

The main issue I have with the factory function is that it's a solution only for evented dataclasses, but not for directly created SignalGroups subclasses.  So, i'd like to focus on the current solution and determine if there are any tests we can make that show undesirable behavior.
delattr(MyGroup, "connect")  # AttributeError, trying to delete the method on `SignalGroup`

to be honest i'm not worried about this example at all.  It's likely to be a very rare attempt (deleting a signal only in the case of a conflict).  The user would have already received a warning that something funny was up with connect, and it's actually the correct exception to raise at that point.
Were there any other issues you can demonstrate with the current pattern?

class MyGroup(SignalGroup):
    sig = Signal(int)
    connect = Signal(bool)

g = MyGroup()

I tried making a copy and deepcopy of MyGroup, a copy and deepcopy of g, and sig and connect behave identically. I don't know what else to try, maybe pickling?

I tried making a copy and deepcopy of MyGroup, a copy and deepcopy of g, and sig and connect behave identically. I don't know what else to try, maybe pickling?

can you give me an assert line to show what you expect to happen?

I run test_group.test_group_deepcopy with MyGroup with sig and connect signals. I'll paste the code.

that's enough info, thanks.  I'll parametrize that test with a group with conflicts and work on it

added a test: https://github.com/pyapp-kit/psygnal/pull/286/commits/5b1f7014cfdae95d0c9ef78be84e0423d2024182
it still seems to be working though... so you might indeed need to paste some code if you think you found a case that raises an unexpected error

also added tests to make sure that the set_name is called on both conflicting and non-conflicting names on SignalGroups and all their subclasses.  They were, and we don't need to call it explicitly

it still seems to be working though... so you might indeed need to paste some code if you think you found a case that raises an unexpected error

No, no, I didn't find any error, all working great!

Oh good!  Ok, I'll merge then so I can cut a new release without the deprecations, and so you can finally actually use the original previous value emission feature that you originally added here ;)

source: gharchive/pull-request

repo: pyapp-kit/psygnal


text:
Add support for astral-sh/uv

Description
uv is a quick Python package installer and resolver, made with Rust. It's meant to work just like pip and pip-tools, but faster.
Motivation
The introduction of the uv tool (https://astral.sh/blog/uv) marks a significant leap in package management efficiency. Offering notable speed improvements over pip, uv demonstrates superior performance across various scenarios. This enhanced speed translates to quicker package installations, contributing to smoother and more efficient workflow experiences.
Possible Implementation

pyproject.toml
publish_pypi.yml

Additional context
No response

This would be a great addition even though uv is pretty new and possibly far from production use.
I would suggest waiting on using it with the PyPI publishing workflow (see https://github.com/astral-sh/uv/issues/1663) and rather add it to the PR tests after https://github.com/astral-sh/uv/issues/1646 is resolved from their end (I am indeed following uv's developments pretty closely haha)

Is using pip a bottleneck on any of our tests?

Is using pip a bottleneck on any of our tests?

No that's not the case, but as we have a large dependency tree uv can make significant improvements in workflow speeds, plus example notebooks can also take advantage of the same once we're done experimenting with this new tool and it is stable & production ready.

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

Yeah I would be against switching at an early stage for the tool. Pip is well tested and most users already have it installed. Maybe something to revisit in a year or so

A new release for nox is out which includes a [uv] extra, and it's pretty cool: https://github.com/wntrblm/nox/releases/tag/2024.03.02. Whoever wishes to work on this could also consider adding a nox badge to our README.

Seems interesting, this could also potentially decrease the build times of docker containers and the project setup times in cookiecutter templates and virtual environments or nox.
pyproject.toml and noxfile.py can be initially worked upon to test this feature and then can be moved to CI/CD (publish_pypi.yml).

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

Yeah I would be against switching at an early stage for the tool. Pip is well tested and most users already have it installed. Maybe something to revisit in a year or so

If this issue is not being already worked upon by someone, I would be happy to create a draft for future references.

I still think we should not do this one. I don't see the gain for changing to a new tool when pip is well tested

Just to reiterate, I don't think the pip install is a major bottleneck

I still think we should not do this one. I don't see the gain for changing to a new tool when pip is well tested

Just to reiterate, I don't think the pip install is a major bottleneck

@santacodes @kratman on the contrary – I feel we can try it now, uv seems more stable to me and before and there's no harm (users won't get it anyway, just the developers). I was looking at this earlier in the day today and with my hopefully thorough testing mostly everything seems to work perfectly – with the exception of the error I just posted on their tracker (see above).

Properly using and caching uv can shave us off ~1–1.5 minutes in our CI pipelines, which doesn't sound like a lot, but coupled with #3857 we should be able to get under the 5-minute mark with that and improve local development. But yes, it has to be done properly (https://github.com/actions/setup-python/issues/822 isn't done yet, but we know the uv cache locations).

I see that nox has cut a release with uv now, should simplify things!

I just think that we can speed up CI in other ways than continually changing the build system. For instance when I removed the benchmarks from every PR it saved 30 minutes off the total runtime of the CI.
Right now we have 46 CI jobs, at most 10 seem to run at once, and (last time I checked) on average they run around 20 minutes -> (46/10) × 20 ~ 80 minutes to run CI. If we cut down our build matrix by half it would save us 40 minutes and we would not need to make backend changes.
To me it does not seem like pip is the bottle neck. For some of the builds we might save more time by trying to find ways to avoid building our dependencies from source

Yes, that's right – removing a lot of the redundant CI would be quite helpful. But about the bottleneck part, I see that by replacing pip I see some insane speedups locally (it takes a minute in CI if one installs [all,dev,jax,odes] where having a cached wheel for scikits.odes would help – we recently removed those because it breaks sometimes, might be worth removing that hack)

Maybe @santacodes you can try out with a draft PR (or in branch on your fork) and we can see to it if everything works well in CI? If it doesn't, we can always close it and look at this at another time

Maybe @santacodes you can try out with a draft PR (or in a branch on your fork) and we can see to it if everything works well in CI? If it doesn't, we can always close it and look at this at another time

Sure, happy to try it out in my fork with CI resources to test the performance

The uv developers' implementation of their dependency resolver is correct here and pip's resolvelib is in the wrong (they have a lot of open issues about pre-release backtracking) – so we won't be able to install scikits.odes at this time with Python 3.11 unless either scikits.odes fixes the Cython upper pin on their end with a new release (which no one takes how long it can take), or we drop scikits.odes as a dependency.
We can keep this open for a while – with the exception of scikits.odes, all of our dependencies have pure Python or binary wheels, are maintained with no absurd upper bounds[^1] for their build-time dependencies, and installing them is much more trivial (I tested an editable installation without [odes] and it took 40 seconds instead of three minutes, with most of the time spent in compiling PyBaMM).
[^1]: The scikits.odes developers upper-pinned to cython<3.0.0a8, which means uv correctly picks an earlier pre-release (3.0a7), while pip picks a stable release (0.29.37). They should have pinned to cython<3 instead which would have had fixed all problems here. Note that the backtracking for pre-releases is ambiguous, so there is no right answer (but uv's is making more sense to me).

Some arguments for switching to uv (eventually; hence, keeping this issue open to keep an eye on the development) -

Nox has a uv backend now

PyPA's build now supports uv (making things kind of official)

Pixi now supports uv

A lot of conversation and experiments involving uv are taking place in Scikit-HEP:

Switching to uv cut the total job times for hist in half.

For example, using nox to build nox’s docs goes from 22 seconds to 4 seconds using uv.

to add to the above: #3932 will remove scikits.odes, so all of our dependencies will have wheels for all platforms that we support (both platform-specific binaries or pure Python ones).

authors: Saransh-cpp agriyakhetarpal arjxn-py kratman santacodes

repo: pybamm-team/PyBaMM


text:
Use tempfile for temporary JSON files.

After merging #4125 , we generate a lot of temporary JSON files while running tests. These files are short-lived and are created and deleted with every test passing, although if the tests fail these files have to be deleted manually.
You can see the number of json files being generated when test suit fails many times :

We can use tempfile to generate temporary files to fix this. See : https://docs.python.org/3/library/tempfile.html

You can assign this to me, I will open a PR soon.

This is true for notebooks as well. They make images and other files, but do not clean them up

For the notebooks, I think it's better to not use tempfiles so as to not mislead newcomers to PyBaMM and Python, plus users might want to inspect the images after the notebook/cell has been executed

authors: agriyakhetarpal kratman prady0t


text:
Extended documentation in README.md

I added a bit more documentation in README.md. I have yet to add the pybamm-cookie logo to the README and I will add it within this PR itself.
#26

Also, I did not document about entry points as I was unsure if it should go in README or in actual pybamm docs upstream.

repo: pybamm-team/pybamm-cookie


text:
wip: Retrieve PyCast data from Spotify and serve the data through API

Types of changes

[x] New feature

Description
Retrieve episode data of PyCast (Podcast channel of PyCon TW) from Spotify using spotipy and serve with API.

Codecov Report

Merging #1044 (0234f39) into master (879021c) will decrease coverage by 0.23%.
The diff coverage is 44.44%.

@@            Coverage Diff             @@
##           master    #1044      +/-   ##
==========================================
- Coverage   69.01%   68.77%   -0.24%
==========================================
  Files          82       82
  Lines        3295     3331      +36
==========================================
+ Hits         2274     2291      +17
- Misses       1021     1040      +19

Impacted Files
Coverage Δ

src/events/api/urls.py
100.00% <ø> (ø)

src/events/api/views.py
42.42% <33.33%> (-1.63%)
:arrow_down:

src/events/api/serializers.py
66.66% <100.00%> (+1.70%)
:arrow_up:

.../proposals/management/commands/recent_proposals.py
98.76% <0.00%> (+1.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 879021c...0234f39. Read the comment docs.


text:
Fix indentation in nginx.conf

https://github.com/pydanny/cookiecutter-django/blob/master/{{cookiecutter.project_slug}}/compose/nginx/nginx.conf contains a mix of tabs and spaces, I think. Or maybe they're tabs, just misaligned.
Either way, it would be good for them to be consistently aligned.

fixed in https://github.com/pydanny/cookiecutter-django/commit/a4884bb5d76f49f823361eac12cd905d82ea2313

authors: audreyr luzfcb

repo: pydanny/cookiecutter-django

license_source: bigquery


text:
Add Unicode support

Open all files with encoding="utf-8". Fixes #56. Fixes #82.

Can we use the same technique as @Zac-HD in https://github.com/Zac-HD/shed/commit/a757277a3ca282769fd7a60a8a844c4a87f68d00 ? 🙏

Fwiw Python source code is (these days!) all supposed to be in utf-8; shed does a fancier thing because it also formats code blocks embedded in documentation.  But you're welcome to grab the relevant snippet under the local licence rather than AGPL to include it here if you like.

Fwiw Python source code is (these days!) all supposed to be in utf-8; shed does a fancier thing because it also formats code blocks embedded in documentation. But you're welcome to grab the relevant snippet under the local licence rather than AGPL to include it here if you like.

Ah, ok. Thanks @Zac-HD :)

You may also want to enable https://docs.python.org/3/library/io.html#opt-in-encodingwarning in CI to make sure this doesn't come back.  It's a bit fiddly but worth it IMO.

You may also want to enable docs.python.org/3/library/io.html#opt-in-encodingwarning in CI to make sure this doesn't come back. It's a bit fiddly but worth it IMO.

How the CI will say anything useful about it? I didn't get it 🤔

authors: Kludex Zac-HD lemonyte

repo: pydantic/bump-pydantic


text:
Get attribute values from frame variables

This makes this work:
import logfire

foo = 1
logfire.info('foo is {foo}')

The ultimate goal is allow passing an f-string, this is the first step.

https://pydantic.slack.com/archives/C05AF4A4WRM/p1715092161303329 is making me think that this is NOT a first step towards how the f-string magic will work. So unless we want this as a feature in addition to f-string magic, I might throw a lot of this away.

Canceling this feature and closing in favour of https://github.com/pydantic/logfire/pull/151

repo: pydantic/logfire


text:
Validation not working for Annotated with conlist

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
Using conlist within Annotated isn't triggering validation -- is this expected?
Example Code
from typing import Annotated
from pydantic import BaseModel, conlist

class MyModel(BaseModel):
    li: Annotated[list, conlist(int, min_length=2)]

print(MyModel(li=[]))  # I expected this to raise a validation error

Python, Pydantic & OS Version
pydantic version: 2.6.4
        pydantic-core version: 2.16.3
          pydantic-core build: profile=release pgo=true
                 install path: /tmp/venv-XGP7/lib/python3.11/site-packages/pydantic
               python version: 3.11.0 (main, Nov 28 2022, 13:51:36) [GCC 11.3.0]
                     platform: Linux-6.5.0-18-generic-x86_64-with-glibc2.35
             related packages: typing_extensions-4.10.0
                       commit: unknown

I have the same problem - max_length doesn't work either.

conlist itself is an Annotated[list, ...], so you can just use conlist without the Annotated!:

Indeed that works, but then mypy fails. Should I report this as a mypy bug? :thinking:

Indeed that works, but then mypy fails. Should I report this as a mypy bug? 🤔

Function calls are not allowed by type checkers, hence the con* functions are discouraged (see the warning here).
In your case, you can use instead:
from typing import Annotated

from pydantic import BaseModel

from annotated_types import Len

class MyModel(BaseModel):
    li: Annotated[list[int], Len(2)]

authors: Viicos eliasdorneles lukasz-matter

repo: pydantic/pydantic


text:
Update booleans.md and bytesize.md

Closes DOC-62, DOC-63
Selected Reviewer: @lig

please review

please update

@lig I merged your suggestion, did you have any other feedback? (hooky: please review)

authors: dmontagu lig


text:
ENH: Supporting REPEATED schema for list types

Basically, at the moment if there are lists inside a column, we have no way to put that data in GBQ. This enables REPEAT mode in a simple way.

Codecov Report

Merging #60 into master will decrease coverage by 45.12%.
The diff coverage is 75%.

@@             Coverage Diff             @@
##           master      #60       +/-   ##
===========================================
- Coverage   73.44%   28.32%   -45.13%
===========================================
  Files           4        4
  Lines        1540     1543        +3
===========================================
- Hits         1131      437      -694
- Misses        409     1106      +697

Impacted Files
Coverage Δ

pandas_gbq/gbq.py
19.62% <75%> (-55.71%)
:arrow_down:

pandas_gbq/tests/test_gbq.py
27.94% <0%> (-54.94%)
:arrow_down:

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 852b2a3...03b201b. Read the comment docs.

tests!

I don't get what if failing, the test is there but doesn't look like it's being executed.... 🤔

FWIW it's not 'pandantic' to put lists in a dataframe, and IIRC if they're on an index you'll face issues with a lot of pandas functionality
We approach this with either:
a) separate dataframes uploaded to BQ, and then run a BQ query to merge them into a nested format in a single table
b) stack / unstack, with a BQ query to merge columns

@MaximilianR I guessed it is not, but is something we use, thankfully not too often, but still need.

Should we put a warning or something to warn about a list schema being generated?
Can you tell me why the test isn't being executed?

What makes you think it's not being executed?

Thanks @txomon! I think #25 may help us provide support for BigQuery repeated fields. I'd like to keep this PR open just in case #25 doesn't provide this functionality.
Regarding the integration tests being skipped, some integration tests will be skipped if a BigQuery project id is not set. I think the tests should fail if a project id is not set. I've created #72 to track this improvement.
Follow these steps to run the BigQuery integration tests on Travis:
https://pandas-gbq.readthedocs.io/en/latest/contributing.html#running-google-bigquery-integration-tests

Yeah, #25 may help. This is also something to make sure we handle when we switch from streaming writes to bulk upload https://github.com/pydata/pandas-gbq/issues/7.

Closing as stale, but open to a solution for writing repeated fields

authors: MaximilianR codecov-io jreback max-sixty parthea tswast txomon

repo: pydata/pandas-gbq


text:
Typo util -> utils

I have spotted a typo that makes all the import fail when I install from the sources. Since I've spent half an hour trying to find from where it was coming from, I let you benefit from the patch ;-)

Good spot, thanks. I'm glad to hear people are using this channel to use PydioSync.

repo: pydio/pydio-sdk-python


text:
Feature/read audio files

Which issue(s) are closed by this pull request?
Closes #229
Changes proposed in this pull request:

added functions to read and write audio files based on soundfile
updated read_wav and write_wav accordingly
added tests, errors in underlying package are handled

Travis fails due to the missing sndfile library, any suggestions what to do?

I think you can add apt install sndfile (pseudocode) to tox.ini. Probably for the environments build and wheel

Thanks for the effort in finding out more about the clipping. I slightly changed you function and looked at the output:

Thanks for the effort in finding out more about the clipping. I slightly changed your function and looked at the output to find an easy pattern (code below):
The types FLOAT, DOUBLE, VORBIS do not clip to +/- 1, all other types clip to +/- 1.
How about the following:

We raise a warning if the users writes data with abs values > 1 if the subtype is not FLOAT, DOUBLE, or VORBIS
We keep the modified version of the private function
We would not need clipped_audio_subtypes(format) anymore

def _clipped_audio_subtypes_dict_creation():
    """Creates a dictionary of format/subtype combinations which are clipped by
    :py:func:´write_audio`.

    This function is not called directly due to the need of writing all files
    to disk. Instead, the dict is manually copied.
    """
    collection = {}
    signal = pyfar.Signal([-1.5, -1, -.5, 0, .5, 1, 1.5]*100, 44100)
    with tempfile.TemporaryDirectory() as tmpdir:
        formats = pyfar.io.audio_formats()
        for format in formats:
            filename = os.path.join(tmpdir, 'test_file.'+format)
            for subtype in pyfar.io.audio_subtypes(format):
                write_valid = not _soundfile_write_errors(format, subtype)
                read_valid = not _soundfile_read_errors(format, subtype)
                format_valid = sf.check_format(format, subtype)
                if write_valid and read_valid and format_valid:
                    if format == 'RAW':
                        write_audio(signal, filename, subtype=subtype)
                        signal_read = read_audio(
                            filename, samplerate=44100, channels=1,
                            subtype=subtype)
                    else:
                        write_audio(signal, filename, subtype=subtype)
                        signal_read = read_audio(filename)
                    if np.any(signal_read.time > 1.1) and np.any(signal_read.time < -1.1):
                        behavior = 'not clipping (' + format + ')'
                    elif np.any(signal_read.time > .1) and np.any(signal_read.time < -.1):
                        behavior = 'clipping to +/- 1 (' + format + ')'
                    else:
                        raise ValueError(f"{format}/{subtype}")

                    if subtype not in collection:
                        collection[subtype] = [behavior]
                    else:
                        collection[subtype] = collection[subtype] + [behavior]

    return collection

Added the libsndfile information to the README. I think it raises an OSError('sndfile library not found') when installing SoundFile. This is fine from my point of view.

authors: f-brinkmann sikersten

repo: pyfar/pyfar


text:
Document using serde_bytes with CBOR byte strings

CBOR byte strings are much more efficient than generic arrays.  Also,
add tests for encoding CBOR's various fixed-width byte string types.
Fixes #53

Something is sending SIGKILL to the test process.  Does Travis object to tests that use 8GB of RAM?  I'll disable that part of the test.

Travis nodes have 7.5 GB of RAM.

authors: asomers sfackler

repo: pyfisch/cbor


text:
ENH: Exclude same input geometry from output of nearest_all

In this issue in Shapely, there is a need to find the nearest items in a tree constructed of the same geometries that are being used to query the tree, but return the non-self nearest neighbor(s).
One way to approach this would be to provide a new function that does not take new geometry inputs, but instead uses the underlying tree geometries in such a way that we can compare addresses of a geometry to the results returned within the nearest callback function, so as to avoid a more expensive test for equality.  We would then return an arbitrarily large distance for the self-pair, to force the tree to look for the next nearest neighbor.
/cc @liunx7594

@brendan-ward that's a good insight about the cost of an equality test. In https://github.com/Toblerity/Shapely/pull/1166/files#diff-6108807fae8f58167beefb19a5c3270a442c26cc1e5b3b62e0ce25ebbe4673c3R254 I'm promising an exclusive keyword argument to make the set of possible results and the input exclusive. One thing that's not great about using the GEOS distance is that all shapes that contain a shape have the same distance: 0.

One thing that's not great about using the GEOS distance is that all shapes that contain a shape have the same distance: 0

This is partly why we return all equidistant results via nearest_all, though that does present a bit of an awkward API ("nearest" implies a singular result).  We leave it up to the caller to determine how to then ordinate the results where distance is 0; perhaps they could do so by comparing the distance between centroids or some other metric to better refine that (but it all seems very use specific so I don't know that we can do more here).
It looks like your implementation would extend nicely to nearest_all here as something broadcastable to the shape of the inputs, but I think we'd want to work out whether or not we want to express this in terms of avoiding self-nearest neighbors (proposed above, using pointer addresses), avoiding input nearest neighbors (via exclusive, using equality test), or both.  I didn't do a performance test on the equality test, so the gains of using the pointer approach may or may not be negligible; it just seemed like it would involve fewer operations.

I didn't do a performance test on the equality test, so the gains of using the pointer approach may or may not be negligible; it just seemed like it would involve fewer operations.

Performance might be a reason to choose the pointer method, but the two methods also can give a different result (there can be multiple geometries in the tree that are not identical, but are spatially equal: the one method only excludes the identical geometry, the other method excludes all equal geometries). Although I don't really have a good sense which of the two behaviours would be most preferable (probably also use case dependent)

I agree that we should stick to the “equals” and not go for the identity (pointer equality).
I don’t see a pygeos geometry as something that has an identity. They are like integers of strings: immutable and only their value gives them meaning.
Within the context of a tree, we could only do an exclusion by identity if one would specify the query geometry with an index into the tree. (e.g. tree.query(geom_idx) ) but something like that will have a very limited usability.

authors: brendan-ward caspervdw jorisvandenbossche sgillies

repo: pygeos/pygeos


text:
Fixed issue with single-line comments in TransactSqlLexer

This pull request fixes an issue with the regex for the Comment.Single token type in the TransactSqlLexer class.
In the current version of pygments (2.18.0), the existing regex causes single-line comments to be lexed incorrectly whenever they are immediately followed by a non-comment token on the next line. For example, consider the following code:
from pygments.lexers.sql import TransactSqlLexer
for token_type, token_contents in list(
    TransactSqlLexer().get_tokens(
        """
        -- this is a single line comment
        select
        """
    )
):
    print(token_type, repr(token_contents))

When run, this results in the following stream of tokens: (Note that the comment is lexed as various other tokens)
Token.Text.Whitespace '        '
Token.Operator '-'
Token.Operator '-'
Token.Text.Whitespace ' '
Token.Name 'this'
Token.Text.Whitespace ' '
Token.Keyword 'is'
Token.Text.Whitespace ' '
Token.Name 'a'
Token.Text.Whitespace ' '
Token.Name 'single'
Token.Text.Whitespace ' '
Token.Name 'line'
Token.Text.Whitespace ' '
Token.Name 'comment'
Token.Text.Whitespace '\n        '
Token.Keyword 'select'
Token.Text.Whitespace '\n        \n'

Lexing with the modified regex for the token Comment.Single in this commit results in the following stream of tokens: (Note that the comment is now lexed correctly.)
Token.Text.Whitespace '        '
Token.Comment.Single '-- this is a single line comment\n'
Token.Text.Whitespace '        '
Token.Keyword 'select'
Token.Text.Whitespace '\n        \n'

Can you please add the snippet there as an example snippet?

Hi @Anteru,
Absolutely. I have added a test_single_line_comment.txt snippet that tests this specific case.
Additionally, I noticed that tests were failing as tsql_example.sql includes single-line comments that are now lexing differently. The token output looked good to me so I updated tsql_example.sql.output with tox.
Please let me know if any additional action is required of me. Thanks!

No, this looks good. Thanks!

authors: Anteru will-hinson

repo: pygments/pygments


text:
feat: Add application responses

* Add application responses for pyhf October 15 2022 round.

@kratsg @lukasheinrich I know this is a very short turn around time, but if you can :+1: or :-1: with comments on this I can submit it today (the deadline for the 2022 application period).

LGTM

:+1:

authors: lukasheinrich matthewfeickert


text:
Function to keep column in a specified range

Brief Description
I would like to propose a feature to make  columns within a dataframe only have values in between a specified range. Values that are out of that range will be removed from the dataframe.
I would like to propose...
Example API

import pandas as pd

""" dataframe should only have values in a column that are between the minimum and maximum set by the user """

def within_range(df, column_name: str, minimum: int, maximum: int):
    try:
        df = df[ (df[column_name] >= minimum ) & (df[column_name] <= maximum) ]
       df = df.reset_index()
    except Exception as e:
        print(e)
    return df

data = {"Name":["Bob","Chad","Venessa","Carmen","Peter"], "Age":[15, 3,10, 60,25]}
example_df = pd.DataFrame(data)

"""
Example Dataframe

Name       | Age
-- ---- -- | --
Bob         | 15
Chad       | 3
Venessa | 10
Carmen  | 60
Peter      | 25

Function Call:
example_df.between_range( "Age", 10, 25)

Returned DataFrame:

Name       | Age
--   -- ---| --
Bob        | 15
Venessa | 10
Peter      | 25
"""

hi @maxineattobrah, is this different from pd.Series.between? if it is, do you mind adding examples? thanks

Hi @samukweku I updated my proposal above with an examples

@maxineattobrah closing this as it is already covered by Pandas.

authors: maxineattobrah samukweku

repo: pyjanitor-devs/pyjanitor


text:
Double read timeout to fix 'The read operation timed out'

We've been getting lots of errors on the CI, for example https://github.com/pylast/pylast/actions/runs/7532231359:
======== 81 passed, 9 skipped, 1 xfailed, 50 errors in 84.73s (0:01:24) ========

pylast.NetworkError: NetworkError: The read operation timed out

Coming from:
httpx.ReadTimeout: The read operation timed out

Coming from:
httpcore.ReadTimeout: The read operation timed out

Coming from:
 = <ssl.SSLSocket [closed] fd=-1, family=30, type=1, proto=0>, len = 65536, buffer = None

    def read(self, len=1024, buffer=None):
        """Read up to LEN bytes and return them.
        Return zero-length string on EOF."""

        self._checkClosed()
        if self._sslobj is None:
            raise ValueError("Read on closed or unwrapped SSL socket.")
        try:
            if buffer is not None:
                return self._sslobj.read(len, buffer)
            else:
>               return self._sslobj.read(len)
E               TimeoutError: The read operation timed out

We can work around this by doubling the default read timeout from 5s to 10s.
I've not so far seen this happen in my normal use of pylast, so perhaps this should only be changed when running tests?

I have now sometimes seen a timeout in normal use, let's try this.

repo: pylast/pylast


text:
Remove terminal output when discovering available devices

Hello,
we are using the following code snippet to discover available devices at the startup of the programme:
MMC_DEVICE_MAP = {}
core = mmc.CMMCorePlus.instance()
adapters = core.getDeviceAdapterNames()
for adapter in adapters:
    try:
        devices = []
        types = [mmc.DeviceType(type) for type in core.getAvailableDeviceTypes(adapter)]
        names = core.getAvailableDevices(adapter)
        for t in types:
            if t == mmc.DeviceType.Camera:
                devices.append(names[types.index(t)])
        if len(devices) > 0:
            MMC_DEVICE_MAP[adapter] = devices
    except:
        pass

When running this code we get the following output:

Is it somehow possible to change this behaviour and remove the output?
Thanks for your help!

Hey, @tlambert03, I'm working with @felixwanitschke on the same project. I tried your solution (sorry for the late reply) but unfortunately it doesn't work. I believe it's due to the fact that the wurlizter package only works natively on Linux (it's based of the fcntl package) while we mostly work on Windows. The replacement using nullcontext doesn't seem to work.

yeah, then there's probably not much we can do on our side.  nullcontext by the way is a no-op fallback in the case of a missing wurlizter import... I tried a number of things like modifying sys.stdout and nothing worked.
I'd say the linked issues above https://github.com/micro-manager/mmCoreAndDevices/issues/402 is the correct way to fix this... and possible the only way without some terribly invasive strategies.  since that issue exists, i'm inclined to close this as in-actionable, but let me know if you have any additional ideas

Yeah I'd say the issue can be closed for now, as I also don't have any idea how to fix this and it's not very critical for us at the moment. Thanks for the help nonetheless!

thanks for reporting.  I made a PR for mmCoreAndDevices here: https://github.com/micro-manager/mmCoreAndDevices/pull/413 ... will update after discussion is had over there

authors: felixwanitschke jacopoabramo tlambert03

repo: pymmcore-plus/pymmcore-plus


text:
Problems flashing a TI LP MSPM0G3507 via XDS110

Hi, I've a new Texas Instruments LP MSPM0G3507 board, that uses the XDS110 chip to program the M0+.
I'm using pyocd 0.35.1 it write the first 35% of the code OK, but then barfs
pyocd flash ./mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --pack=TexasInstruments.MSPM0G_DFP.1.1.0.pack -t mspm0g3507 -u MG350001
0004561 I Loading /home/summers/ti/mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex [load_cmd]
[=================                                 ]  35%Exception in thread Thread-2 (rx_task):
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.11/site-packages/pyocd/probe/pydapaccess/interface/pyusb_backend.py", line 156, in rx_task
    read_data = self.ep_in.read(self.ep_in.wMaxPacketSize,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0015462 E Error during board uninit: [session]
  File "/usr/lib/python3.11/site-packages/usb/core.py", line 423, in read
    return self.device.read(self, size_or_buffer, timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/core.py", line 1029, in read
    ret = fn(
          ^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 864, in intr_read
    return self.__read(self.lib.libusb_interrupt_transfer,
0015466 E Probe error during disconnect: [session]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 954, in __read
    _check(retval)
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 602, in _check
    raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
0015481 C Device MG350001 read thread exited [__main__]

Now the Texas Instruments command for flash via uniflash come line also produces and error, but does flash the device
/home/summers/ti/uniflash_8.3.0/deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite flash --config=MSPM0G3507.ccxml ../mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --verbose
DSLite version 12.3.0.3041
Configuring Debugger (may take a few minutes on first launch)...
	Initializing Register Database...
	Initializing: CS_DAP_0
	Executing Startup Scripts: CS_DAP_0
	Initializing: CORTEX_M0P
	Executing Startup Scripts: CORTEX_M0P
	Initializing: SEC_AP
	Executing Startup Scripts: SEC_AP
Connecting...
CORTEX_M0P: GEL Output: Memory Map Initialization Complete
Loading Program: ../mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex
	Preparing ...
	0 of 1280 at 0x0
error: CORTEX_M0P: Flash Programmer: Device init failed
	Finished
	Setting PC to entry point.
Success

I'm running it on a 15 year old computer AMD E350 device - so yes its an old low powered machine. But it programs an NXP LPC845-BRK device via pyocd fine. So its only the XDS110 device that has problems.
Yes TI only seems to have started using the XDS110 programming chips on the new Cortex M0+ chips they are moving to. The development boards have only started becoming available a few weeks ago, that means you can get an XDS110 program device for $15 or so, whereas for an external XDS110 programming device, its over $100 IIRC.
Is there any way of increasing the USB timeout? As a whole I prefer the pyocd programming a device than the TI version, although that isn't bad.

If it helps here is the usbmon output when the timeout happens. What is the best program to read it with for the information you require.
5.mon.out.gz

I just ordered an LP-MSPM0G3507 board, so hopefully it will be here within a week or so.
For usbmon, it seems Wireshark might be able to read the output? You should also be able to record directly within Wireshark. Although, I've never tried this for USB. If I have a chance this weekend, I'll try to review it, but there are several other issues I'm working on, too.
It's not possible to change the USB timeout from the command line, though there is a constant in the code.
https://github.com/pyocd/pyOCD/blob/dc9f2c00f761e36527ff96598bb6a7f698307e62/pyocd/probe/pydapaccess/interface/interface.py#L25
However, it's already set to 10 seconds… If the probe isn't responding within this time, then there's something seriously wrong.

Something to try: you can set the cmsis_dap.limit_packets session option to prevent multiple outstanding commands (eg via -Ocmsis_dap.limit_packets). This is sometimes required in a VM.

Thanks Chris, I'll try those. A timeout of 10s is huge! I've never known anything to take that time! But still when pyocd gives an error, it is at least several second - I didn't think it as long as 10s, but I change that to test.
Thanks for ordering the Ti MSPM0G3507 LP board, like all TI launch pads, its a nice little development board, with plenty of pin outs etc. The one unusual bit is going to the XDS110 programming chip - it means the programming chip is twice as large as the cortex M0+ (guess the XDS110 is a QFP 144 pin, and the M0+ a QFP 48 pin). Guess you ordered direct from TI (seems only place available right now) - for me it meant the board was delivered from Singapore (board made in China) so shipping was five days or so, but very hassle free.
Just tried the -Ocmsis_dap.limit_packets option - that ran immediately, and without error - but didn't seem to write anything!
pyocd flash ./mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --pack=TexasInstruments.MSPM0G_DFP.1.1.0.pack -t mspm0g3507 -u MG350001 -Ocmsis_dap.limit_packets
0006691 I Loading /home/summers/ti/mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex [load_cmd]
[==================================================] 100%
0007764 I Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 2048 bytes (2 pages) at 1.96 kB/s [loader]

The timeout is used in this case mostly to prevent hangs from a stuck device. It could very well be that the Linux kernel has a shorter timeout for USB than 10 seconds.
By default, pyocd will read the target's memory and compare with the data being programmed to prevent unnecessary flash erase/write cycles. In this case, you were reprogramming the same image so it didn't need to do anything. That's why it says "skipped 2048 bytes".
To force it to always program flash, pass -Osmart_flash=0.

Bingo! And yes the -Osmart_flash=0 worked! Yes I was passing the same .hex file that I had flashed before, so I could compare the TI software to pyocd!
So problem was the multiple outstanding commands. Oh yes looked at the XDS110 part of the card closer yesterday, its just an MSP432 chip, so an older TI arm processor. If it helps the software on the XDS11/MSP430 device is the 03.00.00.25 CMSIS-DAP software; so I guess that is where the issue lies.

Wow, I'm somewhat surprised that worked! I'll add a note to the docs.
Is this ok?

XDS110 firmware version 03.00.00.25 is known to have an issue when using multiple outstanding packets (the default setting). To work around this, set the cmsis_dap.limit_packets session option, e.g. -Ocmsis_dap.limit_packets=1 on the command line. Earlier firmware versions most likely exhibit the issue; it is unknown whether it is fixed in more recent versions.

Also, is it ok to close this issue now? Thanks!

Yes - happy for you to close the issue, as you found the cause of the problem, and have a work around. So yes its a fault with XDS110, I wonder if we should escale the problem with Texas Instruments, so they know the issue - and will maybe solve with a future update?
Don't know, maybe it caused by the MSP432 chip that provides the XDS110 connection, maybe its just under powered?

And Closing the ticket

Thanks for closing.
There's no reason the MSP432 can't handle the task. We are able to run DAPLink (our open source CMSIS-DAP implementation) on far less powerful chips. Someone even has a custom CMSIS-DAP implementation running on an ultra cheap 8-bit 8051-compatible MCU! So it's almost certainly just a software bug.
Reporting the issue would be good, even if they don't take action. When I get my board, I'll try to find time to write a simple reproducer script that sends a valid command sequence which causes the device to hang.

I've started a thread on the TI forum: [(https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1250134/xds110-programming-device-msp432-based-on-03-00-00-25-cmsis-dap-software-can-t-handle-multiple-requests)]
The TI staff are pretty responsive there, so suspect it will be rapidly passed onto the right person.

That's refreshing to hear!

Well, I got the LP-MSPM0G3507 board… and immediately bricked it. Actually, it's almost certainly just locked, but in any case pyocd can't connect anymore. This happened because I did a chip erase, and now the DebugDeviceUnlock sequence from the CMSIS-Pack fails to run. Seems like the device got locked, and the access port for the CPU is disabled, causing the  connection to fail. 🤦🏽

When you say bricked it, do you mean the MSP432 or the MSPM0G3507?
The MSPM0G3507 can go into a low power mode, and then its hard to talk to. The TI flashing program can write to it though, and that brings it back to life.
The MSP432 think it goes into an old style flash disk you can copy new firmware to, and again the TI software for the XDS110 can connect and upgrade the MSP432 firmware.
I'm off to work now, but I'll post more when I get back.

The MSPM0G3507 is bricked. It's not in a low power mode… It responds to SWD. But the AP for the CPU is missing, indicating it's in a debug-protected secure state. Anyway, it can probably be recovered using the TI tools. It's just a pain to get everything installed and understand it when I only use it for testing.
Btw, you should be able to use --connect=under-reset to wake the target from sleep in order to connect.

Sorry to hear that Chris, sound a bit strange that you can still do SWD, but not enough to write to the flash - so must be something strange. Haven't read that the TI MSPM0G3507 has a protected state in the TRM, e.g. it doesn't seem like the NXP devices where you can lock them down hard ...
The TI tool I use to write the device is uniflash, its mainly a GUI, has similar functionality to pyocd, but not everything (pyocd is more transparent to use). Uniflash has always be able to connect to the MSPM0G3507 in my experience, even when I was "bricking" it when I first got the device. That said though as soon as I've got my own code on the device, its been very reliable with either pyocd or uniflash - my code is current simple, but evolving - so ends up in a big look just flashing an led; just while I get understanding of the Ti SDK.
Oh yes, in post above, where I reported to TI, the link got garbled, and wasn't showing - I've added it back. TI say this isn't an issue (I think because pyocd isn't a supported application) - bit sad, (and I tried pushing) but is what it is. Don't know if you at ARM have other routes into TI you can use.
Have think it would be nice to get DAPLink working on the MSP432 - as it sets everything up as common, and would move CMSIS-DAP onto version 2. Then again don't know how DAPLink compares to the TI software, and as a whole the TI software & SDK are pretty good, better than most of other arm producers, and better support. So may be TI are wedded to their own software ...

Oh yes, meant to ask. Did you try typing the pyocd command, but not hit return. Then push and hold S3 next to the USB cable on the LP-MSPM0G3507, hit return, and immediately release S3. That usually got into the device for me.

Just tried the reset button, as well as trying --connect=under-reset (which should have the same effect). Neither worked. It's not a big deal, I can try using the TI tools to recover it if needed. And I can test the XDS110 using another target via a cable.
Honestly, it doesn't surprise me that TI won't look at the issue. They seem to still have the old-school silicon vendor mindset regarding tools.
DAPLink should compare pretty well against XDS110. There don't appear to be any proprietary features in TI's probe. Just CMSIS-DAPv1 plus a serial port.

Pity about that. Yes last night I was reading the TRM slau846 and 1.4 does say that you can switch off SWD, but BSL may be open on the UART. However if you do factory reset, you need to rewite the NONMAIN data structure - otherwise it my kill the machine.
Now I guess as your chip erase, it must have over written this (and everything else) with 0xff. Strange thing is TRM says that you need a password to change anything, and the password is never 0xff; so if it isn't allowed by hardware - how did you write it. Its suggests that SWD bypasses the check, and writes 0xff; and effect from that is what you found.
Does this mean a problem with  TexasInstruments.MSPM0G_DFP.1.1.0.pack shouldn't have allowed you to do an erase there?

Yep, I figured it was something similar to that. I just ran pyocd erase --chip. It appears the MSPM0G flash algo in the CMSIS pack doesn't have a chip erase entry point. When pyocd sees this condition, it just performs a sector erase over all the flash regions—including the config area in this case.
It actually looks like there might be some issues with pyocd's generation of memory regions from the pack data. There is a default flag, which when set to 0 should prevent the region from being created (it's meant to then allow the user to enable the region in a GUI). The MSPM0G pack sets default=0 for the NONMAIN flash region. I was certain that pyocd checked this flag, but it could be broken somehow… ☹

There is a bug, but it's more in the chip erase functionality which currently doesn't check the default flag before erasing a region automatically.
Pyocd will go ahead and create non-default flash regions as long as there is a memory region + flash algo defined together (memory regions and flash algos are separate definitions in CMSIS-Packs). The intent is to allow the user access to anything defined in the pack that doesn't cause conflicts.
It's arguable whether it would be better to create a memory region without a flash algo (so it can't be programmed) if the algo is marked as non-default. Unfortunately, there's not a strictly correct way to handle it since vendors all have slightly different interpretations and intended usages.
Thanks for helping me work through this! 😄

Yes - and its good that we understand that the XDS110 can only handle one command, and that it isn't safe to erase the NONMAIN memory region. And as you say, you still have XDS110 probe, and so can still use that - at at least it has an 8pin output IIRC.
When I finish my current project with the MSPM0G I may look at converting the MSP432 to DAPLink - but won't do this until project is finished.
Oh yes, went through the TRM to see what effect writing 0xff everwhere in the NONMAIN region, its only the first few bytes that are important. Basically both SWD and BSL are disable unless two demi words have exactly the right bits - and 0xFF isn't correct so both BSL and SWD are disabled. You'll probably also have a CRC fault, which kicks off slightly different route through the code. There is a slim chance you may be able to do a SWD factory reset at power on, but probably as SWD is disabled even that not allowed.
So my reading is its a total brick now. Quite a surprise, but does say really should be no writing to NONMAIN.

Wow, it's surprising how dangerous erasing NONMAIN is!
If you do get around to working on an MSP432 port of DAPLink, there's a DAPLink channel on the pyOCD Slack workspace. The join link in on the home page of pyocd.org.

Oh pooh - think I may have bricked my mspm0g3507. When trying the unlock command. Afterwards it has just frozen, and nothing (even TI software) can connect. Here is the cmd session:
`pyocd> reset
Resetting target
pyocd> unlock
pyocd> reset
Resetting target
0151137 W Core #0 is not accessible after reset [cortex_m]
Transfer failed: Memory transfer fault @ 0xe000edf0-0xe000edf3
pyocd> list
Probe/Board                                                   Unique ID   Target

0   NXP Semiconductors LPC11U3x CMSIS-DAP v1.0.7                  0F009015    n/a
1   Texas Instruments XDS110 (03.00.00.25) Embed with CMSIS-DAP   MG350001    n/a
pyocd> halt
Transfer failed: Memory transfer fault
`

Yes, that's the same symptom I have. Really sorry to hear that!
I'd double check with TI support to make sure there's not a way to recover a device which had its NONMAIN flash erased accidentally using their tools. If not, complain vigorously that it's a broken design. 😉
From my own experience working on MCU architecture… having the default flash state be secured is a Very Bad Idea. The NXP Kinetis devices work like this, although in that case the mass erase does unlock the device by writing the unlocked bit pattern into flash for you (it's the normal chip erase that enables security). Still dangerous and troublesome at best.
I'll also work more on making pyocd honour the default flash for flash. Unfortunately, that will make some other devices harder to use, but it's probably tradeoff worth making.

Yes I've started a thread on the ti forums:
https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1253733/lp-mspm0g3507-lauchpad-in-funny-state-how-to-reset
and following your security page, have confirmed I can access the addition access ports (guess you found the same).
TI has at least now given information on what AP=1-4 do; not clear if one can enable SWD again. If I get SWD alive, I can write the bytes I need to to NONMAIN.
The logic on the words in NONMAIN controlling SWD and BSL is a bit strange, there is a word for enabled, and another word for disabled. But so that accidental bit fips don't give access to a locked machine, if any other word value is set, then SWD/BSL are also disabled. The net effect of this is that there are two or three words in NONMAIN that must have specific values.
Anyway that I can access other Access Points, shows the boot rom is still booting, and does give some access - only question is what can be done with it. The list posted on the ti site - and none of the Access Points seem to give access to resetting the machine; but lets see what TI says ....
The list of AP points given are:
AP=0; AHB-AP; MCPUSS debug access port; Debug of the processor and peripherals
AP=1; CFG-AP; Configuration access port; Access device type information
AP=2; SEC-AP; Security access port; Access the debug mailbox (DSSM)
AP=3; ET-AP; Energy Trace technology access port; Read the power state data from power aware debug
AP=4; PWR-AP; Power access port; Configure the device power states (interfaces with PMCU/SYSCTL)
Gut feeling with pyocd erasing NONMAIN, it probably at least a warning should be given that NONMAIN is being erased, and ask for confirmation (as default = 0). That then should at least work with other machines as well, e.g. you can force the erase of a default =0 sector, but need to make an active choice to do that. e.g. what caused my problem was the command "unlock", that only in the documentation does it mention that means a mass erase, so is easily missed.
Thanks though for your time on this.

Having all values except certain ones cause a locked state is a common way to prevent things like physical glitching attacks from forcibly unlocking an intentionally-protected device. (This is why security for the NXP Kinetis devices works similarly.) But there are far better ways to do handle this using things like a redundant lifecycle state setting.
What really sucks is that, unless there's a way to use the SEC-AP to unlock the device, then there is no way for customers to temporarily lock a device for production testing and then recover it to continue development.
Agreed regarding the erase subcommand. I was thinking of changing it to only erase default regions unless an --nondefault option is provided. Perhaps also only erase the boot memory unless an "--all" or similar option is provided. And report which regions are erased or not.

Hi Chris,
After a bit of moaning - TI has said they will another MSPM0G3507 - which is good of them; so can still continue to write code.
Thought a bit about the above, and much reading. Yes default=0 doesn't mean you can't use it, its only default=1 that means that you have to! So probably the main problem  is name "unlock" - as it unlocks some machines, but locks TI MSPM0. How about rename the command to "masserase" - then it describes what it does, and users then have to know what that means. I think thats the simplest way of making people aware.
I've dug into:
AP=1; CFG-AP; Configuration access port; Access device type information
AP=2; SEC-AP; Security access port; Access the debug mailbox (DSSM)
which are still runing. CFG-AP just give information so
pyocd> readap 1 0x1000000
AP register 0x1000000 = 0x1bb8802f
tells you about what CPU is there, its says version=1, which is inserting the same info in flash says version=1
SEC-AP is more difficult, it write to DSSM, and that sents mail to the CPU. So:
writeap 2 0x2000000 0x020
should take back to where you started, but:
pyocd> readap 2 0x2000004
AP register 0x2000004 = 0x00000001
Means you have sent mail, but the CPU hasn't yet picked it up. It goes back to 0, when picked up.
08 is for messages back to you, and 0c that you have read it.
Hope this helps,
David

Good to hear they'll send another!
Probably the best change would be to remove the fallback to erasing all regions when there isn't a special unlock routine. You're right that it's not really an unlock. The issues comes from "unlock" falling back to "mass erase" which falls back to "erase all regions" which erases non-default regions.
Thanks again for your help discussing and working through this!

Hi Chris, am just closing down the thread on the TI site, and in write up realised something. I guess you use MSPM0G_NONMAIN.FLM for doing the mass erase of NONMAIN, specifically calling EraseSector or maybe EraseChip commands in the algorithm.
Just wondering, what if those functions did nothing and returned status=1 or failure. Could you still write to the chip with ProgramPage?
Now this kinda makes sense, one should never erase NONMAIN on these boards, and only ever write occasional words.
The other beauty is that MSPM0G_NONMAIN.FLM is maintained by TI, its a TI executable; so its TI that sets the policy on how you write to the chips, and how they require you to using the chip. So like this approach - as its clear that TI is responsible for both.
Does this make sense?

authors: davidjohnsummers flit

repo: pyocd/pyOCD


text:
Maya: Refactor moved usage of CreateRender settings

Brief description
This is a draft untested PR to fix #3642
Description
Please test publishing from Maya with up-to-date saved settings.
Testing

Ensure render images file rule works as expected.
Ensure aov separator works as expected

Only thing still missing to be able to submit renders from Maya again is the actual populating of [full_exp_files and thus expectedFiles remaining empty currently.] It's missing this line that was there originally.
This commit would fix it.
Wasn't sure whether it made sense to include it in this PR.

still not passing through

I believe you should set it to just renders without the slash?

shouldn't we put some default value here?

I'd just put whatever the default workspace.mel sets that comes with OP, which is indeed renders

Yes, it is the slash so we should change the wording in the validator message

Yes, it is the slash so we should change the wording in the validator message

Technically this would also work renders/lighting or whatever subfolders you'd like.
What wording would describe it better for you?
Might just be best to strip any starting/trailing slashes when checking against it?
Also I'm not sure whether the workspace.mel actually allows storing the value with a slash at the end - if it does then technically it could also explicitly check the value directly with the trailing slash.

as a "user" I was strictly following the validators messages to use the trailing slash:
Validates "images" file rule is set to "renders/"
and
Workspace's images file rule must be set to: renders/

@m-u-r-p-h-y How about like this? (Just configured it to foobar to test)

Changed default value and changed the validator's wording.

Might just be best to strip any starting/trailing slashes when checking against it to avoid user error anyway?

Would you still like me to update the validator for this?

Another question. Is there any reason why this:
def get_file_rule(rule):
    """Workaround for a bug in python with cmds.workspace"""
    return mel.eval('workspace -query -fileRuleEntry "{}"'.format(rule))

value = get_file_rule("images")

Isn't just this:
value = cmds.workspace(fileRuleEntry="images")

And is there a reason why we're setting the workspace rule with Pymel using:
        pm.workspace.fileRules["images"] = default
        pm.system.Workspace.save()

Instead of doing this:
cmds.workspace(fileRule=("images", value))
cmds.workspace(saveWorkspace=True)

Especially since we might want to use as little Pymel as possible also with things like #2353 and #3233

Might just be best to strip any starting/trailing slashes when checking against it to avoid user error anyway?

Would you still like me to update the validator for this?

I'd just treat it the standard way we do it in other places where we deal with paths. No special treatment.

Nice! :)

// Error: pyblish.ValidateRenderSettings : AOV file format is not the same as the one set globally 1 != 6 //

This is a known bug: https://github.com/pypeclub/OpenPype/issues/3410

// Error: pyblish.ValidateRenderSettings : AOV (Z) image prefix is not set correctly <BeautyPath>/<BeautyFile>.<RenderPass> != <BeautyPath>/<BeautyFile>_<RenderPass> //

The others show that it's not being validated against the correct AOV separator.
That bug comes from the fact that it validates against instance.data["aovSeparator"] which is the aov separator actually being collected by the layer/AOV as collected in CollectRender and not the aov separator that the settings define.
As such, instead the validator should just be doing instance.data["aovSeparator"] != settings_aov_separator however that would technically be incorrect since Redshift allows a separator per AOV to be set instead of per layer and thus we should be validating that PER aov and not per layer.
As such this identifies an issue that might not be a simple fix - should we separate into an issue of its own?

should we separate into an issue of its own?

Yeah, it is not only redshift that allows separator to be defined per AOV (or rather the whole prefix, but  that is question if we even want to support). So I vote for another issue as that one will be harder to solve. I thought we have one already for this but I cannot find it.

should this be merged than to get images file rule fixed?

I'd say so. This is a decent hotfix now for the issue at hand except for maybe this missing commit:

This commit would fix it.

source comment

authors: BigRoy antirotor m-u-r-p-h-y

repo: pypeclub/OpenPype


text:
Filter users within an organization based on user role or pending invitations

In an organization, there is no way to filter the users based on the user roles or pending invitations. This is useful for organizations that will have many users who are members of the organization.
To replicate this issue-

Click on 'Your organizations'
Click on 'Manage'
Scroll to the bottom of the page where the members of the organization are listed

Priority- 1/3

The filtering should be similar to the feature available on Github

Priority - low

Authorities

repo: pypi/warehouse


text:
ao2mo for GHF orbitals

An efficient routine for real AO (scalar) integrals and complex GHF orbitals

Hi @sunqm , has this been resolved now due to the merge of #1411 ?

authors: sunqm verena-neufeld

repo: pyscf/pyscf


text:
Error while using ChatGooglePalm

from pyspark.sql import SparkSession
import pyspark_ai
spark = SparkSession.builder.appName('dummy').getOrCreate()

data = [("Java", "20000"), ("Python", "100000"), ("Scala", "3000")]
columns = ["language","user_cnt"]

rdd = spark.sparkContext.parallelize(data)

from pyspark.sql.types import StructType, StructField, StringType
schema = StructType([
    StructField("language", StringType(), nullable=False),
    StructField("user_cnt", StringType(), nullable=False)
])
df=spark.createDataFrame(data,schema=schema)
# llm=palm.get_model("models/chat-bison-001")
from langchain.chat_models import ChatGooglePalm
llm = ChatGooglePalm(temperature=0.9,google_api_key="GOOGLE_API_KEY")
spark_ai=pyspark_ai.SparkAI(llm=llm,spark_session=spark)
spark_ai.activate()
df.ai.transform("language with high user count")

ChatGooglePalmError: ChatResponse must have at least one candidate.

@kannankvsp could you show us the usage code and the error stack trace?

I added full code and error message.

authors: gengliangwang kannankvsp

repo: pyspark-ai/pyspark-ai


text:
Make PriceComp fields public

While writing some unit tests for deserializing the Pyth data types, I couldn't create a PriceComp of my own. I believe the pubs may have been desired there anyway (it's the only struct without them).

Thanks, I believe this was resolved with the latest commit

repo: pyth-network/pyth-client-rs


text:
enable deepcopy for DictWrapper

i run into this because i want to dump the response object into a yaml file.
products_api = mws.Products()
products = products_api.get_x()
mydict = vars(products)  # same as products.__dict__
type(mydict['_response_dict'])

this returns
luigipipe.mws.mws.utils.ObjectDict
i think it should return: dict
A very simple approach for problems of that kind i found here.
If you think that is a good idea i can try to understand and fix this.

I haven't ignored this one, just been tossing it around in my head for a while.
I see no real issue offering that functionality, since it's unlikely to get in the way of other methods.
Note that in your pseudocode, products is an instance of DictWrapper, and that parsed attribute is a shorthand to response_dict.
Thus, products.parsed will result in an instance of ObjectDict, which is similar to the dict-like object in the example you've linked. That's the part where we'd add a __deepcopy__ to enable this function.

I have a bit of bandwidth this weekend, so I'll play around with this stuff, see what we can work out. :)

I try to understand how manipulated dictionaries or dict like classes from  scratch work.
It seem those problems are the price you pay for your class like dicts.
What i find striking is that everyone implements this different.
I am trying a lot of them out.
Opinions are: don't inherit from dict,that would break things like get(item , default) will return a dict and not a DotDict, it somehow isn't using your getattr . Those people are using the collections module.
What's interesting with our ObjectDict it does not the heavy lifting of recursion. It takes as input only none nested dictionaries.
That have to change if we want to pass a nested dictionary once (like that we get from xmltodict).

Like argued in the comment section of that link, the copy should work without a dunder deecopy method.
In my new version it does. Tough it's a bit inconvenient since vars returns the dict nested:
{'_DotDict__data': {'EndDate': '2018-05-29T04:24:10+00:00',
'ReportProcessingStatus': 'SUBMITTED',
'ReportRequestId': '548585017',
'ReportType': 'GET_FLAT_FILE_OPEN_LISTINGS_DATA',
'Scheduled': 'false',
'StartDate': '2018-05-29T04:24:10+00:00',
'SubmittedDate': '2018-05-29T04:24:10+00:00'}}
But all nested Dicts are Dicts and not DotDict objects.

authors: GriceTurrble elcolumbio

repo: python-amazon-mws/python-amazon-mws

license: Unlicense


text:
miso tf2ss fails without slycot

This looks like it is failing to throw the warning to the user about it being miso and not supported without slycot for some reason.
tf = control.tf([[[-235, 1.146e4],
    [-235, 1.146E4],
    [-235, 1.146E4, 0]]],
    [[[1, 48.78, 0],
      [1, 48.78, 0, 0],
      [0.008, 1.39, 48.78]]])
tf
Out[80]:

Input 1 to output 1:
-235 s + 1.146e+04
------------------
  s^2 + 48.78 s

Input 2 to output 1:
-235 s + 1.146e+04
------------------
  s^3 + 48.78 s^2

Input 3 to output 1:
  -235 s^2 + 1.146e+04 s
--------------------------
0.008 s^2 + 1.39 s + 48.78
In [81]:

control.tf2ss(tf)
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/home/jgoppert/anaconda3/lib/python3.5/site-packages/control-dev-py3.5.egg/control/statesp.py in _convertToStateSpace(sys, **kw)
    646         try:
--> 647             from slycot import td04ad
    648             if len(kw):

ImportError: No module named 'slycot'

During handling of the above exception, another exception occurred:

ValueError                                Traceback (most recent call last)
<ipython-input-81-c8ef26438f31> in <module>()
      1
----> 2 control.tf2ss(tf)

/home/jgoppert/anaconda3/lib/python3.5/site-packages/control-dev-py3.5.egg/control/statesp.py in tf2ss(*args)
   1082             raise TypeError("tf2ss(sys): sys must be a TransferFunction \
   1083 object.")
-> 1084         return _convertToStateSpace(sys)
   1085     else:
   1086         raise ValueError("Needs 1 or 2 arguments; received %i." % len(args))

/home/jgoppert/anaconda3/lib/python3.5/site-packages/control-dev-py3.5.egg/control/statesp.py in _convertToStateSpace(sys, **kw)
    671             # I think this will fail if num and den aren't 1-D after
    672             # the squeeze
--> 673             lti_sys = lti(squeeze(sys.num), squeeze(sys.den))
    674             return StateSpace(lti_sys.A, lti_sys.B, lti_sys.C, lti_sys.D,
    675                               sys.dt)

/home/jgoppert/anaconda3/lib/python3.5/site-packages/scipy/signal/ltisys.py in __init__(self, *system, **kwargs)
    759         self._den = None
    760
--> 761         self.num, self.den = normalize(*system)
    762
    763     def __repr__(self):

/home/jgoppert/anaconda3/lib/python3.5/site-packages/scipy/signal/filter_design.py in normalize(b, a)
   1084     if len(b.shape) == 1:
   1085         b = asarray([b], b.dtype.char)
-> 1086     while a[0] == 0.0 and len(a) > 1:
   1087         a = a[1:]
   1088     outb = b * (1.0) / a[0]

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Scipy doesn't seem to like SIMO or MISO, including when denominators are matched.  Note the error in that last case: I get the feeling scipy.signal.lti is intended for SISO.
import sys
import numpy
import scipy
print('sys.version:',sys.version)
print('numpy.__version__:',numpy.__version__)
print('scipy.__version__:',scipy.__version__)

import numpy as np
from control.matlab import *
import scipy.signal

def testit(sys):
    print('sys is ',sys.outputs,'x',sys.inputs)
    try:
        scipy.signal.lti(np.squeeze(sys.num),np.squeeze(sys.den))
        print('success!')
    except ValueError as e:
        print('gives ValueError',e)

# 1x1
testit(tf([1],[1,1]))
# 1x1 as list-of-list-of-vectors
testit(tf([[[1]]],[[[1,1]]]))

# 1x3
testit(tf([[[-235, 1.146e4],
         [-235, 1.146E4],
         [-235, 1.146E4, 0]]],
         [[[1, 48.78, 0],
           [1, 48.78, 0, 0],
           [0.008, 1.39, 48.78]]]))

# 3x1
testit(tf([[[-235, 1.146e4]],
        [[-235, 1.146E4]],
        [[-235, 1.146E4, 0]]],
         [[[1, 48.78, 0]],
           [[1, 48.78, 0, 0]],
           [[0.008, 1.39, 48.78]]]))

# 3x1 with matched denominators
testit(tf([[[-235, 1.146e4]],
        [[-235, 1.146E4]],
        [[-235, 1.146E4, 0]]],
         [[[1, 48.78, 0]],
           [[1, 48.78, 0]],
           [[1, 48.78, 0]]]))

gives
$ python sample.py
sys.version: 3.5.2 |Continuum Analytics, Inc.| (default, Jul  2 2016, 17:53:06)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
numpy.__version__: 1.11.1
scipy.__version__: 0.18.0
sys is  1 x 1
success!
sys is  1 x 1
success!
sys is  1 x 3
gives ValueError The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
sys is  3 x 1
gives ValueError The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
sys is  3 x 1
gives ValueError Denominator polynomial must be rank-1 array.

Since I was fixing up some errors associated with not having slycot installed, I went ahead and addressed this in c90a399.  Should be fine to resolve once PR #122 is accepted.

addressed by commit c90a399a38babc7b496fe2f848d3ac9593b954f0, now in master branch from PR #122

addressed by commit c90a399a38babc7b496fe2f848d3ac9593b954f0, now in master branch from PR #122

authors: jgoppert murrayrm roryyorke slivingston

repo: python-control/python-control


text:
Hacktoberfest Re-organisation

Relevant Issues
Closes #861.
Description

Moved all hacktoberfest commands into _cog.py
Moved all hacktoberfest util functions into _utils.py
Deleted the three hacktoberfest command files (since merged into _cog.py and _utils)
Migrated all hacktoberfest commands to be under the Hacktoberfest cog and .hacktoberfest command (alias .hacktober)
Renamed some commands (.hackstats --> .hacktoberfest stats, .hacktoberissues --> .hacktoberfest issues and .timeleft --> .hacktoberfest timeleft)
Added a temp-fix to the already broken .hacktstats courtesy of @hedyhli. I believe they're planning to write a more permanent fix soon:tm:.

Did you:

[x] Join the Python Discord Community?
[x] Read all the comments in this template?
[x] Ensure there is an issue open, or link relevant discord discussions?
[x] Read and agree to the contributing guidelines?

Hey @TizzySaurus (for your PR description) the tempfix was for .hackstats not .hacktoberissues :)

Fixed, thanks :+1:

@TizzySaurus is this PR only focused on migrating the code as-is and the restructuring or are you wanting to refactor the three commands as well? Many of Jason's suggestions are on (mostly 😃) copied original implementations (from #7, #46, #296, #466, #475, 047902d, possibly more). IMO it should just copy the functions over for now plus many adjustments (which you've done) and then refactor them later in separate PRs (someone else could do this) since this is only about putting the three subcommands under a single hacktoberfest command.

I may redo certain easy parts, but I won't be completely refactoring the code. I agree with you that refactoring is outside the scope of this PR.

@Shivansh-007 @hedyhli Have just pushed #fca5a45 which fixes all the reviews I said I'd do :+1:

mm, @Bluenix2, you make a fair point, but we shouldn't block this merge over this small amount of git blame. It's fine to lose a little git blame in a refactor like this, and cleaning this up now after the fact is going to be quite annoying. I don't want this PR getting closed or abandoned over a technicality that might never have any real practical use for us, especially after all these wonderful people spent time reviewing it.

Hey @TizzySaurus, would you be able to continue working on this?

I'll be closing this PR due to staleness.
@hedyhli if you'd like to work on this, please ping me and I'll assign you, and the PR can be re-opened.

authors: TizzySaurus Xithrius hedyhli lemonsaurus

repo: python-discord/sir-lancebot


text:
Bug: text always underlined in Wordpad

System Info
python-docx==1.0.1
Problem
I copied an example from the official documentation and added the option to toggle the font underline:
document = Document()

p = document.add_paragraph('A plain paragraph')
p.add_run('bold').bold = True
p.add_run(' and some ')
p.add_run('italic.').italic = True
p.add_run(' underline.').underline = True
document.save('hello.docx')

When I open it with WordPad, switching the bold and italic attributes to True or False produces the expected result. However, whether I set underline to True or False, the text always appears underlined.
How can it be solved?
add_run('my_text').underline = True should make 'my_text' appear underlined, while add_run('my_text').underline = False should leave 'my_text' not underlined.

Try setting run.underline to None. It's possible that WordPad is misinterpreting the spec and showing underline whenever the <w:i> element appears, even if its value is False.
run = p.add_run('underline') = True
run.underline = None

authors: Keredu scanny

repo: python-openxml/python-docx

license: mit


text:
ASYNC912: timeout/cancelscope with only conditional checkpoints

oh, turns out #183 was already planning on using ASYNC912.
It looks like I broke some stuff, but I gotta go for the day so I thought I'd push in case you have time to review tests/eval_files/async912.py and have any opinions on the behavior in some of the edge cases in there.

Got the major shit working, but needs some cleanup, comments, documentation and a self-review pass. So no need to review yet.

Added a couple corner cases, I don't think wrapping calls is terribly common - but if it is feel free to open an issue and I'll make it search for the matching calls differently.
    # wrapped calls do not raise errors
    with customWrapper(trio.fail_at(10)):
        ...
    with (res := trio.fail_at(10)):
        ...
    # but saving with `as` does
    with trio.fail_at(10) as res:  # ASYNC912: 9
        if bar():
            await trio.lowlevel.checkpoint()


text:
🛑 Catalog Api is down

In 8c01f93, Catalog Api (https://catalog.roblox.com/) was down:

HTTP code: 503
Response time: 589 ms

Resolved: Catalog Api is back up in 558177c after 24 minutes.

repo: pythoniaweb/roblox-status


text:
Generate codegen on the fly

Now that @ezyang's torchgen has been landed into PyTorch nightlies, we can start to codegen functorch codegen instead of checking it into the codebase.
This will make us more resilient to changes to pytorch/pytorch operators that functorch doesn't use.
NB: this is going to require changes in our codegen on the OSS side and on the fbcode side.

So, it turns out, this isn't sufficient: to do the code generation, we also need to package pytorch/aten/src/ATen/native/native_functions.yaml somehow so that torchgen can access it without requiring a source checkout of pytorch. AFAIK native_functions.yaml isn't included in the regular PyTorch installation

Oh yeah, we should fix this

repo: pytorch/functorch