feat: add computed fields

Change Summary
I'm waiting for feedback on the API and doc 🙏
property-like syntax
from functools import cached_property
from random import randint

from pydantic import BaseModel, computed_field

class Square(BaseModel, underscore_attrs_are_private=True):
    side: float
    _private_attr: int = 1

    @computed_field(title='The area')
    @property
    def area(self) -> float:
        return self.side ** 2

    @area.setter
    def area(self, area: float) -> None:
        self.side = area ** .5

    @area.deleter
    def area(self) -> None:
        self.side = 0

    @computed_field(alias='The random number')
    @cached_property
    def random_n(self) -> int:
        return randint(0, 1_000)

    @property
    def public_attr(self) -> int:
        return self._private_attr + 1

    @public_attr.setter
    def public_attr(self, v: int) -> None:
        self._private_attr = v - 1

sq = Square(side=10)
assert sq._private_attr == 1
assert sq.public_attr == 2
sq.public_attr = 5
assert sq._private_attr == 4
assert sq.public_attr == 5
the_random_n = sq.random_n
assert sq.dict(by_alias=True) == {'side': 10, 'area': 100, 'The random number': the_random_n}
sq.area = 49
assert sq.dict() == {'side': 7, 'area': 49, 'random_n': the_random_n}
del sq.area
assert sq.dict() == {'side': 0, 'area': 0, 'random_n': the_random_n}
assert sq.dict(exclude={'random_n'}) == {'side': 0, 'area': 0}

ComputedField syntax
from pydantic import BaseModel, ComputedField, ValidationError, validator

class User(BaseModel, validate_assignment=True):
    first_name: str
    surname: str
    full_name: str = ComputedField(lambda self: f'{self.first_name} {self.surname}')

    @validator('full_name')
    def should_not_have_pika(cls, v: str) -> str:
        if 'pika' in v.lower():
            raise ValueError('We love pika but not that much!')
        return v

u = User(first_name='John', surname='Smith')
assert u.dict() == {'first_name': 'John', 'surname': 'Smith', 'full_name': 'John Smith'}
u.first_name = 'Mike'
assert u.dict()['full_name'] == 'Mike Smith'

try:
    User(first_name='Pika', surname='Chu')
    assert False
except ValidationError:
    # pydantic.error_wrappers.ValidationError: 1 validation error for User
    # full_name
    #   We love pika but not that much! (type=value_error)
    assert True

See the tests for more examples
Related issue number
closes #935
closes #1241
closes #2313

Checklist

[x] Unit tests for the changes exist
[x] Tests pass on CI and coverage remains at 100%
[x] Documentation reflects the changes where applicable
[x] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)

Writing computed_field instead of field seems good but writing
If TYPE_CHECKING:
    computed_field = property

won't work with kwargs like alias and stuff.
This is why I chose to keep the combo field + property (or any other property-like descriptor), which is well supported by mypy and the IDE without any effort. The only issue is that decorating property itself is not yet handled by mypy but it's a known issue that may be solved in the near future.
If anyone wants to work on a better mypy support feel free! But I won't do it myself: I have not the will nor the energy to do it since it's a lot of work for IMHO not a big gain.

Writing only @computed_field instead of @field with @property is annoying because of mypy and IDE. Writing
If TYPE_CHECKING:
    computed_field = property

won't work with kwargs like alias and stuff.
And it won't work fine with property-like descriptors
This is why I chose to keep the combo @field + @property, which is explicit, just a few characters longer and well supported without any effort. The only issue is that decorating property itself is not yet handled by mypy but it's a known issue that may be solved in the near future.
If we want to change the API and need to work on a better mypy support fine but I won't do it myself sorry: I have not the will nor the energy to work on the mypy plugin since it's a lot of work for IMHO not a big gain.

I think this is very well done.  My only concern is that it's synonymous with Field (sans the capitalisation) which can be confusing, especially because fields are not constructor arguments. Is there a reason not to call this computed_field or dynamic_field - why do you think it'd need to be tied to @property for that?

@layday Thanks!
Writing
...
    @computed_field(title='The area')
    def area(self) -> float:
        return self.side ** 2

    @area.setter
    def area(self, area: float) -> None:
        self.side = area ** .5

    @area.deleter
    def area(self) -> None:
        self.side = 0

is already supported with
        if not (ismethoddescriptor(func_) or isdatadescriptor(func_)):
            func_ = property(func_)

but it doesn't work well with mypy and some IDEs
error: Name 'area' already defined on line 10  [no-redef]
error: Name 'area' already defined on line 10  [no-redef]
error: Cannot assign to a method  [assignment]
error: Incompatible types in assignment (expression has type "int", variable has type "Callable[..., Any]")  [assignment]

So I felt like keeping property (or cached_property or whatever) and just add a basic decorator on top of them. It makes everything work properly without extra plugin.
And writing
    @computed_field(title='The area')
    @property
    def area(self) -> float:

felt a bit weird to me because a property is by definition computed hence the reduced decorator name 'field'.
I don't have a strong opinion on all of this but as I said in my comment I just don't want to tackle the whole mypy / type checking issue myself.

I think it's fine to have both @property and @field. For non-pydantic pros this makes it super obvious what this is doing, might make usage of "property" vs. "cached_property" easier as well.
Perhaps it would even be good to have some sort of warning if the user defines a field without specifying a  property decorator?

I think it's fine to have both @property and @field. For non-pydantic pros this makes it super obvious what this is doing, might make usage of "property" vs. "cached_property" easier as well.
Perhaps it would even be good to have some sort of warning if the user defines a field without specifying a  property decorator?

Question, what would be the right way to add validation for a property?
Would this be possible?
class Thing(BaseModel):
    @property
    def prop(self):
        return self._thing

    @prop.setter
    def set_prop(self, val):
        self._thing = val

    @validator("prop", always=True)
    def validate_prop(cls, v, values, field):
        # do some validation
        return v

or would we just have to add the validation in the setter method?

@aiguofer It was not decided so I didn't want to make it too complicated. As you can see there are still discussions on the interface and the desired configuration. IMO the PR is already big enough and tackles most of the problem.
If it stays like this you'll need to add validation in the setter yes.
But your feedback is welcome on what would make more sense

Just resolved conflits. Please review whenever you can for the global approach🙏 There is still some debate on the API and I changed multiple times between computed_field and field and made my point here.
Once we all agree on the names and expected usage I'll work on the documentation ✍

I find this idea very nice.

As already mentioned by others, it would be great if we could control if such a field appears or not in the repr.
Could we imagine that ComputedField can receive the class ? In subclassing scenarii that could be worth having. This makes me think that maybe ComputedField could be generalized into some kind of FieldFactory, that could redefine the field description, type, default value, and other json props, based on the subclass. Or maybe this is something for a separate PR ?

A particular use-case where I see interest is to manually disambiguate Union of types that are all subclasses of a common parent basemodel. Using a constant field in the parent class, computed based on the subclass type, does the trick in an elegant way without needing the subclasses to redefine the field themselves.
(of course PR #2336 is a more integrated alternative, but the computed field could be a good first stab, and I'm sure that it is representative of other similar usage scenarii)

Thanks @PrettyWood for that contribution. 🚀
Is there's something we can do to have that PR merge any time soon ?

As already mentioned by others, it would be great if we could control if such a field appears or not in the repr.
repr has been added. Feedback welcome

Could we imagine that ComputedField can receive the class ?
Let's wait for some feedback. This PR is already quite huge and a lot may change for v2. But interesting idea thanks!

@nhuray A 1.9 will be done in September. This will most likely be in it

Thanks @PrettyWood !

How would this apply to async methods/properties?

Could you elaborate? AFAIK, there is no async properties in Python.

Guys, can we please get on with this ? :). I miss that @property support really hard!

@MrMrRobat if you need to do an async operation like a database (tortoiseORM) and want to fetch some additional data that has no relation with the model, most orm's don't know how to do it, so async properties could make it work.
e.g:
async def get_data_from_a_table(self) -> Optional[OrmModelSchema]:
    return await OrmModel.get(id=1)

pydantic doesn't wait for it, so is returned "None" and raises a warning: Coroutine object was never waited.

What is the value of this over just using a property by itself?

Well, one reason is to define some complex actions that should be taken when changing a value. For instance, converting a full filesystem path to a relative one. Or adding a fixed prefix to a relative path when reading a value.

@PrettyWood What needs to happen for this great PR to be merged?

It is still awaiting review.

If you are on poetry, and can't wait:
pydantic = { git = "https://github.com/PrettyWood/pydantic.git", branch = "field-property" }

Crash when abstract classes with compute fields are inherited.
Test code:
from abc import ABC

from pydantic import BaseModel, computed_field

class AbstractBase(BaseModel, ABC):
    ren: int

    @computed_field
    @property
    def test_compute_field_field(self) -> int:
        return self.ren * 5

class ConcreteEnd(AbstractBase):
    reni: float

Output:
Traceback (most recent call last):
  File "/home/can/Software_Projects/BiKiPy/examples/test.py", line 15, in <module>
    class ConcreteEnd(AbstractBase):
  File "pydantic/main.py", line 144, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/utils.py", line 631, in pydantic.utils.smart_deepcopy
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 146, in deepcopy
    y = copier(x, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 230, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 161, in deepcopy
    rv = reductor(4)
TypeError: 'NoneType' object is not callable

please update.

Over all this looks awesome. I want to use it. Thank you again @PrettyWood for all your effort. 🙏
My main concern is around performance, particularly performance where compute fields are not being used but the extra checks/logic being used here is still called.
Roughly what performance impact does this have?
The main question I have in terms of implemenation is whether computed field results should be stored in the __computed_fields__ dict rather than in __dict__? Also whether __computed_fields__ should be separate from __fields__.
Would it be possible for computed fields to just be more fields at the end of __fields__ (end so they could get access to values)? If so I think this would significantly improve performance.
In other words, what if computed fields were really just syntactic sugar for
class Rectangle(BaseModel):
    width: int
    length: int
    area: int = None

    @validator('area', always=True, pre=True)
    def calc_area(cls, v, values):
        if (width := values.get('width')) and (length := values.get('length')):
            return width * length

?
Other reminders:

@caniko has a comment about inheritance
conflicts

One potential drawback with the "computed fields are just fields/sugar" approach would be that it would hint to tooling (e.g. IDEs) that the computed field is a valid/expected attribute when initializing a model instance, when in reality providing a value at initialization time (instead of computing it from the dependencies) should probably be an error.  So however this is implemented, it would be ideal if it can be done in a way that plays nicely with IDEs and the like.

Could we make sure that these fields are compatible with frozen?

Why hasn't this feature been merged yet? What's the best work-round right until this gets added?

Why hasn't this feature been merged yet? What's the best work-around right now until this gets added?

Use cached property, and this in you BaseModel:
    class Config:
        keep_untouched = (cached_property,)

I'm testing this out right now, and @computed_field is a dream come true!
I did notice that when using "response_model=" with FastAPI routes, any Pydantic class using @computed_field causes FastAPI to throw the following error and crash:
TypeError: 'NoneType' object is not callable
Perhaps something I'm missing in the configuration? Simple example:
@computed_field
def running(self) -> bool:
return self._running

@DCMattyG, could you perhaps share a complete code snipped that can be ran as is and the full traceback it produces?

@DCMattyG, could you perhaps share a complete code snipped that can be ran as is and the full traceback it produces?

This is the exact same issue that @caniko shared above, which includes a complete code snippet.
TL:DR, if you have a @computed_field on your Pydantic class, and you set a response_model, you get the following error:
TypeError: 'NoneType' object is not callable
Example of attaching the Pydantic class to a route:
@router.get("/{name}", response_model=Profile)
async def get_profile(name):
for profile in PROFILES:
if(profile.name == name):
return profile

Another request: computed_fields should also be available for validation, validate("<computed_field>"). Validating all of computed fields might be computationally expensive, consider adding a config flagg to enable this (default: false; disabled).
The feature might be a little outside the scope of the current PR. Also, considering the newly suggested onion protocol for validation might also get outdated, food for thought!

@samuelcolvin regarding the syntactic sugar approach using the validator decorator. I couldn't see any caching in the provided example:
class Rectangle(BaseModel):
    width: int
    length: int
    area: int = None

    @validator('area', always=True, pre=True)
    def calc_area(cls, v, values):
        if (width := values.get('width')) and (length := values.get('length')):
            return width * length

I don't see this being both syntactic sugar, and have caching without introducing several lines of code. Having no caching as the given example is definitely a waste of compute.
@PrettyWood, what is your opinion?

will this be updated?

Since it is unclear when and if this will ever be merged, I wrote my own computed fields function (not for the properties, just for fields which are supposed to be computed (using other model fields).
from typing import Any, Callable, Dict

from pydantic import Field, validator

def ComputedField() -> Any: # NOSONAR # Since this simulates a class, the class naming is used.
    """Wrap the pydantic field to provide None as default value."""
    return Field(None)

def computed_field(name: str):
    """
    Python Decorator for computed fields.

    Args:
        name: The name of the pydantic model field which should be computed.
    """

    def wrapper(func: Callable):
        required = [arg for arg in func.__annotations__.keys() if arg not in ['cls', 'return']]
        func_return_type = func.__annotations__.get('return')

        @validator(name, always=True, allow_reuse=True)
        def inner(cls, v, values: Dict, field):
            # Check that the computed field is unassigned.
            if v is not None:
                raise RuntimeError(f"Field '{name}' is computed and should not be provided.")

            # Check that all fields are defined.
            missing_fields = [r for r in required if r not in values]
            if missing_fields:
                raise RuntimeError(f"The fields {missing_fields} must be defined in model.")

            expected_type = field.type_
            # Check that return type of defined function matches model.
            if func_return_type != expected_type:
                raise TypeError(f"Return type should match type {expected_type} of '{name}' field.")

            computed_value = func(cls, **{r: values[r] for r in required})

            # Check that type of computed value matches model.
            if not isinstance(computed_value, expected_type):
                raise TypeError(f"Computed value should match type {expected_type} of '{name}' field.")

            return computed_value

        return inner

    return wrapper

Here some tests to show how it works / can be used:
import unittest

import xmlrunner
from pydantic import BaseModel, ValidationError
from airamed_utils.pydantic_utils import ComputedField, computed_field

class TestComputedField(unittest.TestCase):
    """Test the computed field decorator."""

    def test_sets_computed_value(self):
        """Test that setting a computed field via the compute method works."""
        expected = 'test_value'

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls) -> str:
                return expected

        test_model = TestModel()

        self.assertEqual(test_model.computed, expected)

    def test_reject_provided_value(self):
        """Test that setting a computed field via the model constructor is not allowed."""

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls) -> str:
                return 'test'

        with self.assertRaises(RuntimeError):
            TestModel(computed='should not be allowed')

    def test_attribute_injection(self):
        """Test that the injection of model field via parameters works."""

        class TestModel(BaseModel):
            injected: int
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls, injected: int) -> str:
                return str(injected)

        test_model = TestModel(injected=42)

        self.assertEqual(test_model.injected, 42)
        self.assertEqual(test_model.computed, '42')

    def test_require_non_existing_field(self):
        """Test that requiring a non existing model field does not work."""

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls, non_existing_field: str) -> str:
                return 'test'

        with self.assertRaises(RuntimeError):
            TestModel()

    def test_wrong_type_annotation(self):
        """Test that using a non matching type annotation does not work."""

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls) -> int:
                return 42

        with self.assertRaises(ValidationError):
            TestModel()

    def test_missing_type_annotation(self):
        """Test that using no type annotation does not work."""

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls):
                return 42

        with self.assertRaises(ValidationError):
            TestModel()

    def test_wrong_return_type(self):
        """Test that returning data with a non matching type does not work."""

        class TestModel(BaseModel):
            computed: str = ComputedField()

            @computed_field('computed')
            def compute_computed(cls) -> str:
                return 42  # type: ignore # NOSONAR # This is on purpose here.

        with self.assertRaises(ValidationError):
            TestModel()

    def test_missing_attribute_assignment(self):
        """Test that the ComputedField assignment is required."""

        class TestModel(BaseModel):
            computed: str  # Missing ComputedField() assignment

            @computed_field('computed')
            def compute_computed(cls) -> str:
                return 'test'

        with self.assertRaises(ValidationError):
            TestModel()

if __name__ == "__main__":
    unittest.main(testRunner=xmlrunner.XMLTestRunner(output='test-reports'))

This will be merged.
It'll go in the next minor release.
On Tue, 5 Apr 2022, 08:45 Sebastian Penhouet, @.***>
wrote:

Since it is unclear when and if this will ever be merged, I wrote my own
computed fields function (not for the properties, just for fields which are
supposed to be computed (using other model fields).
from typing import Any, Callable, Dict
from pydantic import Field, validator
def ComputedField() -> Any: # NOSONAR # Since this simulates a class, the class naming is used.
"""Wrap the pydantic field to provide None as default value."""
return Field(None)
def computed_field(name: str):
"""    Python Decorator for computed fields.    Args:        name: The name of the pydantic model field which should be computed.    """
def wrapper(func: Callable):
    required = [arg for arg in func.__annotations__.keys() if arg not in ['cls', 'return']]
    func_return_type = func.__annotations__.get('return')

    @validator(name, always=True, allow_reuse=True)
    def inner(cls, v, values: Dict, field):
        # Check that the computed field is unassigned.
        if v is not None:
            raise RuntimeError(f"Field '{name}' is computed and should not be provided.")

        # Check that all fields are defined.
        missing_fields = [r for r in required if r not in values]
        if missing_fields:
            raise RuntimeError(f"The fields {missing_fields} must be defined in model.")

        expected_type = field.type_
        # Check that return type of defined function matches model.
        if func_return_type != expected_type:
            raise TypeError(f"Return type should match type {expected_type} of '{name}' field.")

        computed_value = func(cls, **{r: values[r] for r in required})

        # Check that type of computed value matches model.
        if not isinstance(computed_value, expected_type):
            raise TypeError(f"Computed value should match type {expected_type} of '{name}' field.")

        return computed_value

    return inner

return wrapper

Here some tests to show how it works / can be used:
import unittest
import xmlrunnerfrom pydantic import BaseModel, ValidationErrorfrom airamed_utils.pydantic_utils import ComputedField, computed_field
class TestComputedField(unittest.TestCase):
"""Test the computed field decorator."""
def test_sets_computed_value(self):
    """Test that setting a computed field via the compute method works."""
    expected = 'test_value'

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls) -> str:
            return expected

    test_model = TestModel()

    self.assertEqual(test_model.computed, expected)

def test_reject_provided_value(self):
    """Test that setting a computed field via the model constructor is not allowed."""

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls) -> str:
            return 'test'

    with self.assertRaises(RuntimeError):
        TestModel(computed='should not be allowed')

def test_attribute_injection(self):
    """Test that the injection of model field via parameters works."""

    class TestModel(BaseModel):
        injected: int
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls, injected: int) -> str:
            return str(injected)

    test_model = TestModel(injected=42)

    self.assertEqual(test_model.injected, 42)
    self.assertEqual(test_model.computed, '42')

def test_require_non_existing_field(self):
    """Test that requiring a non existing model field does not work."""

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls, non_existing_field: str) -> str:
            return 'test'

    with self.assertRaises(RuntimeError):
        TestModel()

def test_wrong_type_annotation(self):
    """Test that using a non matching type annotation does not work."""

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls) -> int:
            return 42

    with self.assertRaises(ValidationError):
        TestModel()

def test_missing_type_annotation(self):
    """Test that using no type annotation does not work."""

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls):
            return 42

    with self.assertRaises(ValidationError):
        TestModel()

def test_wrong_return_type(self):
    """Test that returning data with a non matching type does not work."""

    class TestModel(BaseModel):
        computed: str = ComputedField()

        @computed_field('computed')
        def compute_computed(cls) -> str:
            return 42  # type: ignore # NOSONAR # This is on purpose here.

    with self.assertRaises(ValidationError):
        TestModel()

def test_missing_attribute_assignment(self):
    """Test that the ComputedField assignment is required."""

    class TestModel(BaseModel):
        computed: str  # Missing ComputedField() assignment

        @computed_field('computed')
        def compute_computed(cls) -> str:
            return 'test'

    with self.assertRaises(ValidationError):
        TestModel()

if name == "main":
unittest.main(testRunner=xmlrunner.XMLTestRunner(output='test-reports'))
—
Reply to this email directly, view it on GitHub
https://github.com/samuelcolvin/pydantic/pull/2625#issuecomment-1088372327,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA62GGNKLDACLRELXS5SPLLVDPVSFANCNFSM42JRDL3A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Crash when compute fields are inherited. There should be at least one test for inheritance.
Test code:
from pydantic import BaseModel, computed_field

class Base(BaseModel):
    ren: int

    @computed_field
    @property
    def test_compute_field_field(self) -> int:
        return self.ren * 5

class ConcreteEnd(Base):
    reni: float

Output:
Traceback (most recent call last):
  File "/home/can/Software_Projects/BiKiPy/examples/test.py", line 13, in <module>
    class ConcreteEnd(Base):
  File "pydantic/main.py", line 144, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/utils.py", line 631, in pydantic.utils.smart_deepcopy
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 146, in deepcopy
    y = copier(x, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 230, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 161, in deepcopy
    rv = reductor(4)
TypeError: 'NoneType' object is not callable

System info:
             pydantic version: 1.8.2
            pydantic compiled: True
                 install path: /home/can/.cache/pypoetry/virtualenvs/bikipy-Cb5pIUSo-py3.9/lib/python3.9/site-packages/pydantic
               python version: 3.9.7 (default, Oct 21 2021, 08:33:25)  [GCC 11.1.0]
                     platform: Linux-5.15.2-zen1-1-zen-x86_64-with-glibc2.33
     optional deps. installed: ['typing-extensions']

My temporary solution.
fix fields.py:
class ComputedField(Representation):
      ...

     def __getattr__(self, name: str) -> Any:
        ...

        raise AttributeError(f'{self.__class__.__name__} object has no attribute {name}')

Reference: https://stackoverflow.com/a/49902096/251496

Crash when compute fields are inherited. There should be at least one test for inheritance.
Test code:
from pydantic import BaseModel, computed_field

class Base(BaseModel):
    ren: int

    @computed_field
    @property
    def test_compute_field_field(self) -> int:
        return self.ren * 5

class ConcreteEnd(Base):
    reni: float

Output:
Traceback (most recent call last):
  File "/home/can/Software_Projects/BiKiPy/examples/test.py", line 13, in <module>
    class ConcreteEnd(Base):
  File "pydantic/main.py", line 144, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/utils.py", line 631, in pydantic.utils.smart_deepcopy
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 146, in deepcopy
    y = copier(x, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 230, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/home/can/.pyenv/versions/3.9.7/lib/python3.9/copy.py", line 161, in deepcopy
    rv = reductor(4)
TypeError: 'NoneType' object is not callable

System info:
             pydantic version: 1.8.2
            pydantic compiled: True
                 install path: /home/can/.cache/pypoetry/virtualenvs/bikipy-Cb5pIUSo-py3.9/lib/python3.9/site-packages/pydantic
               python version: 3.9.7 (default, Oct 21 2021, 08:33:25)  [GCC 11.1.0]
                     platform: Linux-5.15.2-zen1-1-zen-x86_64-with-glibc2.33
     optional deps. installed: ['typing-extensions']

My temporary solution. fix fields.py:
class ComputedField(Representation):
      ...

     def __getattr__(self, name: str) -> Any:
        ...

        raise AttributeError(f'{self.__class__.__name__} object has no attribute {name}')

Reference: https://stackoverflow.com/a/49902096/251496

I am not sure if this solves the problem. Does this mean the problem is in Python, and not the implementation?

@caniko Don't worry I'll get back to this PR when I have time. @samuelcolvin didn't mean it would be merged as is

I am not sure if this solves the problem, @yicone. Does this mean the problem is in Python, and not the implementation?

I have changed my previous comment, there are no exception are expected.

Thank you for working on this PR so much 🙇
Two questions.
1. Will I be able to make a field both computed and abstract?
E.g.:
class Shape(BaseModel, ABC):
    @computed_field
    @property  # is this decorator needed when computed_field is already here?
    @abstractmethod  # will this work as expected?
    def area(self) -> float:
        pass

class Square(Shape):
    side: float

    def area(self) -> float:
        return self.side ** 2

2. Will I be able to alias computed field names? Context: I need to use type field name. However, in the case of defining the field as a @property I get NameError: Field name "type" shadows a BaseModel attribute; use a different field name with "alias='type'". I'm talking here from the perspective of Pydantic 1.9.0.
Looking forward to using the computed fields feature, it's super-useful!

Will I be able to make a field both computed and abstract?

But why would you do this? I would just use abstract property.

Thank you for answering.

But why would you do this? I would just use abstract property without including the computed_field.

My use-case:
from __future__ import annotations
from enum import Enum

from pydantic import BaseModel, Field

class EventType(Enum):
    JOB_STARTED =  "job_started"
    JOB_FINISHED =  "job_finished"

class BaseEvent(BaseModel):
    id: str
    event_type: EventType

    @classmethod
    def create_event(cls) -> BaseEvent:
        id_ = "generated id"
        return BaseEvent(
            id=id_,
            event_type=...,  # without this parameter mypy correctly complains, but what goes here?
        )

class JobStartedEvent(BaseEvent):
    event_type = Field(EventType.JOB_STARTED, const=True)

class JobFinishedEvent(BaseEvent):
    event_type = Field(EventType.JOB_FINISHED, const=True)

The const=True part is the key -- I want to make sure each BaseEvent's subclass won't be instantiated with an incorrect EventType (I only need to remember to include the const=True on each subclass).
I tried different combinations of @abstractmethod, @classmethod and @property, and every time something came up that made the whole thing broken on some level (either mypy was complaining, or there was a runtime issue, or it was incompatible with pydantic). When I saw this PR I thought something like this might be the solution:
from __future__ import annotations
from abc import ABC, abstractmethod
from enum import Enum

from pydantic import BaseModel, Field, computed_field

class EventType(Enum):
    JOB_STARTED =  "job_started"
    JOB_FINISHED =  "job_finished"

class BaseEvent(BaseModel, ABC):
    id: str
    event_type: EventType

    @computed_field
    @property
    @abstractmethod
    def type(cls) -> EventType:
        pass

    @classmethod
    def create_event(cls) -> BaseEvent:
        id_ = "generated id"
        return BaseEvent(id=id_)

class JobStartedEvent(BaseEvent):
    @computed_field
    @property
    def type(cls) -> EventType:
        return EventType.JOB_STARTED

class JobFinishedEvent(BaseEvent):
    @computed_field
    @property
    def type(cls) -> EventType:
        return EventType.JOB_FINISHED

Another thing is aliasing it -- type field won't work in Pydantic, as I've mentioned above.

I'm aware this usage of @computed_field is not the intended purpose of it as no computation is really being made. I'm probably just grasping at straws here.

Also, you don't want to use@abstractmethod. It is deprecated in the newer versions. :)

abc.abstractmethod is not deprecated. abc.abstractproperty is deprecated.

abc.abstractmethod is not deprecated. abc.abstractproperty is deprecated.

I know that. I've never mentioned it :)

So, getting back to being able to use @computed_field together with @abstractmethod. I think it's a reasonable thing -- ABC and abstract method is a well-established part of Python and I'm pretty sure multiple cases are going to emerge.
Mind I have no idea how time-consuming implementing this would be.

When reference a property with @comuted_field annotation, the type hint of the reference is gone.
I'm not sure if the bug comes from this branch or the Python extension of VS Code currently.
E.g.:
@property
def A(self) -> int:
	print(self.B)  # actual is "(method) B: Any", expect is "(property) B: List[float]"
	return 1

@computed_field
@property
def B(self) -> List[float]:
	return []

Editor version info:

Visual Stuido Code: 1.67.2
with Python extension : v2022.6.2

Pydantic version info:

         pydantic version: 1.9.0
        pydantic compiled: False
             install path: /Users/Tr/Workspace/yicone/pydantic/pydantic
           python version: 3.9.12 (main, Mar 26 2022, 15:51:15)  [Clang 13.1.6 (clang-13<IP_ADDRESS>)]
                 platform: macOS-12.2-x86_64-i386-64bit
 optional deps. installed: ['typing-extensions']

any reason there hasnt been movement on this in a while? are we ever going to get it?

@yicone, can reproduce. Also can fix by replacing Any to T in annotation for func argument and return annotation of computed_field.

@pawelswiecki I'd suggest not to dig down into the rabbit hole when it comes to the changes that can be made after the release. I think changes should be gradual and easy to make. Adding @abstractmethod is possible after releasing this. Removing such support is not so trivial, since it would introduce breaking changes.
Let's focus on things that can't be easily changed/fixed after release.
As for your example, let me suggest this (click here):
from enum import Enum
from typing_extensions import Self

from pydantic import BaseModel, Field

class EventType(Enum):
    JOB_STARTED =  "job_started"
    JOB_FINISHED =  "job_finished"

class BaseEvent(BaseModel):
    id: str
    event_type: EventType

    def __init_subclass__(cls, **kwargs) -> None:
        return super().__init_subclass__(**kwargs)
        if (event_type_field := cls.__fields__.get('event_type')) is None or not event_type_field.field_info.const:
            raise NotImplementedError('You must define event_type for concrete event')

    @classmethod
    def create(cls, **data) -> Self:
        id_ = "generated id"
        return cls(id=id_, **data)

class JobStartedEvent(BaseEvent):
    event_type = Field(EventType.JOB_STARTED, const=True)

class JobFinishedEvent(BaseEvent):
    event_type = Field(EventType.JOB_FINISHED, const=True)

print(JobFinishedEvent.create().event_type)  # EventType.JOB_FINISHED

class InvalidEvent(BaseEvent):  ...  # NotImplementedError: You must define event_type for concrete event

To summarize, things to do before merging:

[ ] Fix typing: https://github.com/samuelcolvin/pydantic/pull/2625#pullrequestreview-649988316
[ ] Fix inheritance: https://github.com/samuelcolvin/pydantic/pull/2625#issuecomment-1093799303

[ ] raise AttributeError in ComputedField.__getattr__ when condition is not met
[ ] add tests that include inheritance

[ ] Decide whether to support @abstractmethod (IMO, no, see https://github.com/samuelcolvin/pydantic/pull/2625#issuecomment-1150460832)

Is there something else I'm missing?

@Bobronium thanks for the recap. I'll work on it this weekend. Sorry for being inactive, just a lot on my plate with both professional and personal matters

Can relate. Please take care!
Also, feel free to ask for any help if needed.

Suggestion:
I don't disagree with this, and think it makes most sense:
...
    @computed_field
    @cached_property
    def hard_compute():
        <very hard problem>
...

However, I suggest that we also introduce shorthand notation for property and cached_property:
    @cached_computed_field_property
    ...

And:
    @computed_field_property
    ...

This is nice when computed_fields are used frequently in a package, like my case. I don't want to end up in decorator-hell. Hope this makes sense.
Another question:
Would this computed_fields work with numba.jit decorator?

Feature suggestion:
Can we make computed_fields work with numba.jit decorator? Where it property and cached_property is optional?
@computed_field
@jit
def some_func(self):
    ...

cached_computed_field_property is rather long.
What about something like?
@computed_field(cache=True)
def calculate(self):
    pass

@bjmc, that is also an option. Where property is the default.

This won't be added for v1.10. I don't know if we can use some of this logic in V2 or whether we'll need a new implementation.

@Bobronium Thank you for your suggestion, with the working code, much appreciated!

For those waiting for this feature, it will be 100% added in v2!
Even though we may change the implementation, we got a lot of precious feedbacks (thanks everyone ❤) on the desired APIs: a "property-like" one and a more "type annotation" one.
So we will most likely have these examples work the same 👍

Wow. Looks like pylance (pyright) supports custom defined properties through simple descriptor typing.
I've managed to create a computed_field type that is interpreted by VSCode as a property (borrowed code for generic property here: https://github.com/python/typing/issues/985#issuecomment-1002770338):
from __future__ import annotations
from random import randint
from typing import Any, Callable, Generic, NoReturn, TypeVar, overload

_G1 = TypeVar("_G1")
_G2 = TypeVar("_G2")
_S1 = TypeVar("_S1")
_S2 = TypeVar("_S2")

class computed_field(Generic[_G1, _S1]):
    fget: Callable[[Any], _G1] | None
    fset: Callable[[Any, _S1], None] | None
    fdel: Callable[[Any], None] | None

    @overload
    def __new__(
        cls,
        fget: Callable[[Any], _G2],
        fset: None = ...,
        fdel: Callable[[Any], None] | None = ...,
        doc: str | None = ...,
    ) -> computed_field[_G2, NoReturn]:
        ...

    @overload
    def __new__(
        cls,
        fget: Callable[[Any], _G2],
        fset: Callable[[Any, _S2], None],
        fdel: Callable[[Any], None] | None = ...,
        doc: str | None = ...,
    ) -> computed_field[_G2, _S2]:
        ...

    @overload
    def __new__(
        cls,
        fget: None = ...,
        fset: None = ...,
        fdel: Callable[[Any], None] | None = ...,
        alias: str | None = ...,
        title: str | None = ...,
        description: str | None = ...,
        exclude: set[str] | None = ...,
        include: set[str] | None = ...,
        repr: bool = True,
        doc: str | None = ...,
    ) -> computed_field[NoReturn, NoReturn]:
        ...

    def __call__(self: computed_field[NoReturn, NoReturn], fget: Callable[[Any], _G2]) -> computed_field[_G2, NoReturn]:
        ...

    def getter(self, __fget: Callable[[Any], _G2]) -> computed_field[_G2, _S1]:
        ...

    def setter(self, __fset: Callable[[Any, _S2], None]) -> computed_field[_G1, _S2]:
        ...

    def deleter(self, __fdel: Callable[[Any], None]) -> computed_field[_G1, _S1]:
        ...

    def __get__(self, __obj: Any, __type: type | None = ...) -> _G1:
        ...

    def __set__(self, __obj: Any, __value: _S1) -> None:
        ...

    def __delete__(self, __obj: Any) -> None:
        ...

class Square:
    side: float

    @computed_field
    def area(self) -> float:
        return self.side**2

    @computed_field(alias="The random number")
    def random_n(self) -> int:
        return randint(0, 1_000)

reveal_type(Square().area)
reveal_type(Square().random_n)

Type of "Square().area" is "float"
Type of "Square().random_n" is "int"

Unfurtunately, both mypy and pycharm still don't know how to handle (generic) descriptors.

Another thing that I thought of is to include a keyword argument for computing all computed fields when running model.dict() or model.json().
Example:
model.dict(define_computed_fields=True)

Will evaluate and provide dict with all computed fields computed.

@PrettyWood Any update on this feature, think it is a great addition and gets rid of accomplishing this in validators. Thank you!

Thank you all (especially @PrettyWood) for 2 years (! :see_no_evil:) of patience.
I've migrated this feature to pydantic V2 and pydantic-core, see #5502.
Thank you so much @PrettyWood for your work on this, I've used some of your code, and most of your tests and docs in the new PR :bow: :pray:.


Cannot load model list

After upgrading to the latest version of ComfYUI, cannot open the model list when using the checkpoint and LORA loader

i have the same problem. its even freeze when i try to create one

+1

Same, I also find that other lora loaders' textbox filter are gone and i'm left with only a dropdown menu

have it got fixed yet

fixed it

i dont know why i still have the problem

I'm done too. Please close it.

Same problem over here as well - a fix would be amazing !


Determine desired capabilities of sl-chart and remove dependency on Highchart

http://blog.taucharts.com/taucharts-data-focused-charting-library/ is a possible alternative to research.

Tau-chart ember component proof of concept:
http://jsfiddle.net/XbDEM/12/

@erangeles The Fiddle does not work and throws a bunch of errors


Bugs in conversations

This PR tries to resolve 2 bugs:
Bug 1
When we are working in conversations in Xef (remember that we are creating by default the conversionId in  CoreAIScope)
The problem is the order of the messages when we are sending the messages to OpenAI
Currently, we are storing the messages in the conversation in the wrong order. When we send the request to OpenAI the messages have the following order:
ASSISTANT: <response>
USER: <question>
ASSISTANT: <response>
USER: <question>

And when we add a new question from the user, we add this message to the end like this:
ASSISTANT: <response>
USER: <question>
ASSISTANT: <response>
USER: <question>
USER: <new-question>

In my tests, this is a problem that sometimes OpenAI isn't responding to the last question, it is responding to the second to last
The right order should be:
USER: <question>
ASSISTANT: <response>
USER: <question>
ASSISTANT: <response>
USER: <new-question>

This PR changes the way that we are storing the conversation in the memory in order to fix that
Note: You can revert the changes in Chat.kt and you will see that the Conversation.kt example gives the same result both times
Bug 2
Resolving this issue

I hadn't noticed the reversed(), it's better to do it like this, thank you @victorcrrd
I have found other 2 bugs in the conversations when we are storing the messages in the LocalVectorStore. I'm fixing them now

I have updated the PR with the new fixes and added some tests
@victorcrrd @raulraja could you please review it?

@victorcrrd @raulraja I have fixed some problems in the order messages on CombinedVectorStore and I have created some tests for this
We are using CombinedVectorStore in contextScope inside Xef. They are important changes in the base code. Could you please review the changes?

@raulraja @Montagon This PR is ready for review. Here are the changes:

When we are getting messages from the VectorStore implementations, the messages are sorted by timestamp
Messages are always sent in ascending order
We should address the Lucene implementation in a separate PR. We have to include integrations tests for that and this is not the proposal for this PR


First Issue for Noam & Jacob

This is your first task!
Please set each bullet once done, when all bullets are marked, close the issue as done
@NoamRahat :

[ ] read the README of this repository
[ ] Have a first read of the wiki TFM
[ ] see 2 Youtube videos from the README Inspiration

@jacobavitan837:

[ ] read the README of this repository
[ ] Have a first read of the wiki TFM
[ ] see 2 Youtube videos from the README Inspiration

@NoamRahat @jacobavitan837
I don't see any progress on this task.
The subtask "read the README of this repository" should take less than 5 minutes.
Please update the task when done each subtask

I have started with the ReadMe but I saw I'm mising some context so I skiped to the TFM welcom

I have started with the ReadMe but I saw I'm mising some context so I skiped to the TFM welcome

@NoamRahat

Please read the README in full..
Then watch 2 videos.

@jacobavitan837 which 2 videos did you watch?
I recommend the two:
Tesla: DOJO | Watch the video on Youtube
Tenstorrent: Wormhole & more | Watch the video on Youtube

I can certainly see the inspiration you've drawn from here!

I can certainly see the inspiration you've drawn from here!

@NoamRahat Yup - I hope that now that you have seen the video we will have a common language and a similar understanding of the project's vision!


support simple include

Hey there!
Thanks for the collaboration.
But note that, release branch for releases. The right branch to merge into is main.
Also, can we make inclusion as is, i. e. without top-level config element?
Similar to:

http://logging.apache.org/log4j/2.x/manual/configuration.html#XInclude

Hi Artsiom!
I found my change doesn't work as expected,
will continue to work on it taking in account your suggestion.
BR, Ilya

Closing since no update.


ARROW-4932: [GLib] Use G_DECLARE_DERIVABLE_TYPE macro

Codecov Report

Merging #3945 into master will increase coverage by 0.81%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3945      +/-   ##
==========================================
+ Coverage   87.75%   88.56%   +0.81%
==========================================
  Files         727      593     -134
  Lines       89507    79924    -9583
  Branches     1252        0    -1252
==========================================
- Hits        78547    70788    -7759
+ Misses      10842     9136    -1706
+ Partials      118        0     -118

Impacted Files
Coverage Δ

go/arrow/math/uint64_amd64.go

go/arrow/memory/memory_avx2_amd64.go

js/src/enum.ts

go/arrow/array/builder.go

js/src/Arrow.node.ts

js/src/schema.ts

go/arrow/type_traits_boolean.go

js/src/ipc/node/writer.ts

js/src/visitor/vectorloader.ts

js/src/visitor.ts

... and 124 more

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 9d2280f...eb12259. Read the comment docs.


CC is asking for format of coordinate after it has been converted

When you import coordinates from a spreadsheet the tool asks the format of the coordinate after it has already been added to the list.

Reproduce this by :

import a list of coordinates
right click on the list and select flash

The problem is the tool should not be asking where the coordinate is after it has already been marked by a graphic on the map. Also, no matter what you choose the flash happens in the same place.

This issue was fixed in #389

in arcmap and arcgis pro, i am importing a .csv. the import happens as expected. there is no dialog for ambiguous coordinates. with the points imported to the list, i can flash each point, and it is flashing for a different point for each different coordinate from the list that i click. also the points are being added to the list as expected in that the tool treats the list as the first row in the input is treated like it was the first point clicked. closing


cv2_api doesn"
t

Error	CS1061	'cv_api' does not contain a definition for 'Absdiff' and no accessible extension method 'Absdiff' accepting a first argument of type 'cv_api' could be found (are you missing a using directive or an assembly reference?)

EmguCV is much more maintained than SharpCV, maybe you can find the functionality you want there:
https://github.com/emgucv/emgucv


189 oe testing setup has some environment specific hardcoded values

There are two more hardcode values in oeCoreTest.p GetJsonInputObject and AssertOutputJson procedures


Make tests more stable

Currently most tests depend on the exact values in the testdata/example files. As a result if we update an example file, many changes are required in the tests. In most cases, the exact values are not relevant for the test logic, but rather the presence or absence of values needs to be checked. This PR updates the tests to check invariants on the values (e.g., length of a SHA256 hash) rather than the exact values.

Thanks for the review :)


The route request-docs/localhost/... could not be found.

Hi, my problem is that the right URL is displayed but not used.

And if you open the displayed URL you will get just fine:

My enviroment is this image:
# syntax=docker/dockerfile:experimental

FROM ubuntu:latest

ARG DEBIAN_FRONTEND=noninteractive

RUN apt update && apt upgrade

RUN apt install mysql-client openssl -y

RUN apt install php php-common php-curl php-json php-mbstring php-mysql php-xml php-zip -y

RUN apt install composer -y

Oh, if you click on the URL displayed you will go to:

Awesome project btw!

Request URL isn't bringing in the port. Just the APP_URL

Following is how the REQUEST URL *required field value is taken Laravel -> View as below:
https://github.com/rakutentech/laravel-request-docs/blob/2ad26262a205e23a81a3fe0159bbfa72787a38cc/resources/views/index.blade.php#L595-L603
and then it is picked by the View -> JS as below:
https://github.com/rakutentech/laravel-request-docs/blob/2ad26262a205e23a81a3fe0159bbfa72787a38cc/resources/views/index.blade.php#L373-L377

Request URL isn't bringing in the port. Just the APP_URL

Good point, make sure your APP_URL is in the .env (and then config) is correctly set
PS: REQUEST URL field is an editable field btw, you can edit it to the correct URL to make the request, Although it should be picking up the correct URL by default based on your APP_URL, you might want to double check that.

Just FYI to all,
In the new renewal (which is awesome UI btw), we will be adding a fallback as the current domain via JS, in cases where APP_URL is not set. Although, most Laravel projects have that set up.
bcc @truongns and @kitloong

Yeah, I figured that was the issue and had run into this as well with running the app in Laravel Sail.
At first I was going to suggest looking if the APP_PORT(Sail has you use this to change the port the app is available on) env was set, but as I think about it, I'm kind of surprised that config('app.url') doesn't take into account APP_PORT.
Either way, it's an easy enough fix.
Side note, any screenshots or place we can see the new UI? @kevincobain2000

I have set my APP_URL with the port as APP_URL=http://localhost:8000 and it picks up just fine.
About the screenshot, I'd have to say please wait a little more but it includes the libraries: daisyui, dark mode, monaco-editor, font changes, postman-styled query params (with JSON editable body), save the query params in browser for the user, etc etc.
We should be able to release it in a couple more weeks.

I have set my APP_URL in local with the port as APP_URL=http://localhost:8000 and it picks up just fine.
About the screenshot, I'd have to say please wait a little more but it includes the libraries: daisyui, dark mode, monaco-editor, font changes, postman-styled query params (with JSON editable body), save the query params in browser for the user, etc etc. We should be able to release it in a couple more weeks.

I have this setup, just not with the port. I'm going to check it.

I have set my APP_URL in local with the port as APP_URL=http://localhost:8000 and it picks up just fine.
About the screenshot, I'd have to say please wait a little more but it includes the libraries: daisyui, dark mode, monaco-editor, font changes, postman-styled query params (with JSON editable body), save the query params in browser for the user, etc etc. We should be able to release it in a couple more weeks.

Adding the port to APP_URL worked for me as well.
Sounds good. Appreciate it.

I have set my APP_URL in local with the port as APP_URL=http://localhost:8000 and it picks up just fine.
About the screenshot, I'd have to say please wait a little more but it includes the libraries: daisyui, dark mode, monaco-editor, font changes, postman-styled query params (with JSON editable body), save the query params in browser for the user, etc etc. We should be able to release it in a couple more weeks.

Adding the port to APP_URL worked for me as well.
Sounds good. Appreciate it.

Mine env var was setup too (tried with and without port), I didn't try to run locally though. Maybe it was docker issue, I'll check it without the container later 🤔

Cool. Looks like all good then. I ll close this issue. よろしく

@kevincobain2000 sorry, the issue was me. I found it will not work with:

If you don't put http:// in the beginning (only localhost:8000 will not do)
If you open the backend with the address below it will not work (even though the app works fine):

http://<IP_ADDRESS>:8000/request-docs
http://<IP_ADDRESS>:8000/request-docs

You must open in the same address to avoid CORS error (in my case was http://localhost:8000/request-docs)

Welp, thanks for the quick answers and hope you guys can go on with the project! I'll put a print of it working, awesome tool!

Thanks for the confirmation.


Get rid of thumbnailSize from DescribeRequest

There is no longer any need for it -- clients can get the aspect ratio from the
description of images, and then use the mh parameter to ui/thumbnail to request the
image size they want.

This will also naturally result in getting rid of the weird code in the search package
that knows about the icons the web ui likes to use for folders and files.

https://camlistore-review.googlesource.com/5127

1576fdad6da43b75b54d81858829cdc007e576b0
not closing, because I haven't thought about @wathiede's question.

closing until it @wathiede 's question becomes relevant again.


PostProcessor JPEG Compression Loses Quality Over Base ImageProcessor JPEG Compression?

Prerequisites

[X] I have written a descriptive issue title
[X] I have verified that I am running the latest version of ImageProcessor
[ ] I have verified if the problem exist in both DEBUG and RELEASE mode
[X] I have searched open and closed issues to ensure it has not already been reported (I saw a similar issue, but it wasn't quite the same, and didn't have much detail)

Description
A few months ago, I asked you a question here: http://jamessouth.me/archive/announcing-imageprocessorwebpostprocessor/
Here is the question and answer:

I've now had a chance to test that, and it seems that PostProcessor actually is lossy as compared to the compression done with ImageProcessor.Web. That is, for the same image and query string parameters, you get an image that is visually slightly different.
Steps to Reproduce
I have an Umbraco website running on local in debug mode. It has ImageProcessor <IP_ADDRESS>, ImageProcessor.Web <IP_ADDRESS>, and ImageProcessor.Web.Plugins.PostProcessor <IP_ADDRESS> installed (all using NuGet). Doubt the version of Umbraco matters, but I think it's 7.10.4 (or thereabouts).
I upload an image to the media section of Umbraco. I then visit the URL for that media item to view and download the image. Let's call that "original.png". That URL might be /media/1234/image.png.
I then navigate to the URL with a query string parameter to convert it to a JPEG and to set the quality to 100%. That URL might be /media/1234/image.png?format=jpg&quality=100. I save that image as "with-post-processor.jpg".
I then uninstall PostProcessor, delete the bin and obj folders, delete the App_Data/cache folder, then rebuild the solution in Visual Studio and run it. I visit the same URL as before (/media/1234/image.png?format=jpg&quality=100) in Chrome, this time with the inspector open and caching disabled in the network tab. I save that image as "no-post-processor.jpg".
I then compare with-post-processor.jpg and no-post-processor.jpg with an online visual diff tool to get this:

The red pixels occur when the pixels are very different (i.e., they differ significantly).
I also observe that when I then open both images side-by-side in different Chrome tabs and switch between those tabs rapidly, I can observe significant visual differences. The difference seem more pronounced near the top/center of the hair.
Here are each of the above mentioned images (hopefully GitHub doesn't recompress them).
original.png (1.55MB)

no-post-processor.jpg (804KB)

with-post-processor.jpg (162KB)

Assessment
I'm not sure I'd call this a bug. It's nice that the image is so much smaller with post processing. However, for some situations, the extra compression is not desirable (some of my coworkers have noted the quality degradation and would like to avoid it). I still want to use ImageProcessor.Web for cropping and I still want to use PostProcessor for compressing PNG's (and some JPEG's), but there are edge cases where I'd like to turn off post processor (or otherwise find some way of avoiding this extra quality loss).
Some ideas:

A configuration file to bypass post processing for certain file types (or to disable particular post processors).
A query string to bypass post processing.
A C# event that can inspect a request (e.g., URL and query string) and utilize custom logic to cancel post processing.
Swap out a post processor to one that doesn't have quality loss.

System Configuration

ImageProcessor version: <IP_ADDRESS>
ImageProcessor.Web version: <IP_ADDRESS>
ImageProcessor.Web.Plugins.PostProcessor version: <IP_ADDRESS>
Windows 10
Umbraco 7.10.4
.NET Framework version: targetFramework="4.5" in the web.config

Here's another example that makes it super apparent.
original

post-processed

The post-processed one is with 100% quality. They're both PNG's because I just took a screenshot of a small portion of the images (don't want to reveal much about an in-progress client build).
As you can see pretty clearly in this example, the necklace and folds in the shirt become blurry even with 100% quality when using post processor. No resizing or cropping was done (i.e., I just used the format and quality query string parameters).

Hi Nick,
I'm gonna be really blunt here. I've said very clearly before (it's in the readme) that I am not adding any new features to the library.
That said....
I wasn't 100% accurate in my response there. In some cases there would be a change due to the difference in the huffman tables MozJpeg uses. By all accounts though, these changes should be acceptable and would not account for the blurriness of the second example.
That would be caused by the System.Drawing encoder's shitty handling of sub pixel rendering. Even at 100% the output is subsampled when it shouldn't be.

The red pixels occur when the pixels are very different (i.e., they differ significantly).

No they have more than a 2% difference. That is all.
I'm not going to make any changes to the library. The tools I'm using are industry standard and you would get the same results if you optimized them elsewhere.

That would be caused by the System.Drawing encoder's shitty handling of sub pixel rendering.

That is odd that it's doing sub pixel rendering when I'm not cropping or resizing the image. Note that what appears to be a crop above is just me screenshotting a portion of the image (i.e., that crop wasn't created by ImageProcessor).
Also odd that it only has the sub pixel rendering issue only when PostProcessor is installed (i.e., I don't see it with just ImageProcessor installed). This to me implies that the issue is not with the way that System.Drawing is handling things (as System.Drawing is used by ImageProcessor rather than just by PostProcessor). Maybe I'm misunderstanding this somehow.

No they have a 2% difference. That is all.

By "significant" I meant "different enough that this tool is showing there is a difference above the threshold I have configured" (i.e., the most significant of the differences). Wasn't meaning to imply that the pixel difference was super different.

I'm not going to make any changes to the library.

No worries, that's about what I was expecting, but thought I'd at least explain what I was seeing. Keep up the good work with ImageSharp.


perf setup scripts: add link to dailies and update for post 0.5.0

cc @danehans

@ldemailly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
84be8ea4986c80678ff1054f24f98e2e19456a39
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ldemailly do you mind adding a note to the following section:
$ ./install/updateVersion.sh
This step is only needed when using Istio from source.

done, thanks!

@ldemailly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
0dc6307be3d9dadfd0234ed65b72e2c593b4b040
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


feat: Service Accounts (WIP)

Service Accounts tf resource/datasource implementation
This is a work in progress and far from complete - will work on this + other resource implementations over the course of Aug/Sep 2023
Update 📅 2023-08-31: Still implementing service account feature
Update 📅 2023-09-13: Back on this. Currently testing service account feature locally and addressing issues
Update 📅 2023-10-01: Service Account creation is now working using my local build of the provider. Currently testing other CRUD operations (update/destroy), correct passing of outputs to other resources, and adding better error messages for API client errors

hey @armalite -- i'm part of the platform team at Prefect, where we've recently gotten some new internal targets on publishing this provider + have resumed concerted development efforts here. as I started work on #27, I just noticed your PR.  this is fantastic work and i don't want to step on any of it.
Given some of these new internal targets, I'm tasked with pushing things over the finish line on a more accelerated timeline, so we can get this provider out to ya'll.  that said, I definitely don't want to apply any pressure on you since you've already generously given your free time and energy here -- wanted to see if you had any thoughts/preferences on tag-teaming this, or possibly handing it off to us?  I'd also totally understand + respect if you're committed to taking this home on your own, in which case I'd love to sync up on an ETA

wanted to see if you had any thoughts/preferences on tag-teaming this, or possibly handing it off to us? I'd also totally understand + respect if you're committed to taking this home on your own, in which case I'd love to sync up on an ETA

Hi @parkedwards, great to hear this is being pushed for! :-) Out of curiosity what kind of timeline are you looking at?
I'm quite tied up elsewhere at the moment but the plan was to wrap this up in the next couple of weeks - at least to a state where it can then be built further upon. If you need to get this through faster, I'd be happy to hand this over to you or tag-team and get this over the line (it's almost there I think). I've enabled maintainer edits, so would you be happy to continue working directly on this PR?

If you need to get this through faster, I'd be happy to hand this over to you or tag-team and get this over the line. If maintainer edits are enabled, would you be happy to continue working directly on this PR?

@armalite i think this sounds like the right way to go - let's do this. You're 99% of the way there on this PR, and I'm thinking we can rope this off to the core CRUD functionality.  I'll begin pushing a few commits here for you to take a look when you're able, with the aim of merging this PR by this week.  In a followup, I'll begin extending your work to include handling api key rotation updates for the service account resource

It's almost there I believe - but may need some refactoring if we need to stick with the 'bot' over 'service account' naming

I left a comment above, but your intuition on the service_account nomenclature is better here, so I'm going to close out #63

relates to https://github.com/PrefectHQ/terraform-provider-prefect/issues/27

awesome work on this!


如果source有新交易就会导致失败.

          如果source有新交易就会导致失败.

Originally posted by @hujw77 in https://github.com/helix-bridge/contracts/pull/31#discussion_r1234700197

攻击者每一次会支付手续费

provider is in service


NextjsSite: deploy on normal lambda instead of Lambda @ edge

Lambda@Edge has more limitation compare to classic AWS Lambda. AWS Lambda is more powerful, more tooling, etc.
Lambda@Edge limit our Next.js api's to accept only 1MB of data.
Normal lambda is cheaper and better for API purpose
It could be great if we can choose between classic AWS Lambda and Lambda@Edge at least for API routes and SSR.

Hi @ixartz, this is on our roadmap and we are experimenting with it. I don't have a firm date around when we can have a v1. But I will keep you posted when we have something.

Hi @fwang, thank you for taking the time to respond.
With recent announcement of Next JS 12, _middleware run on edge. So perfect to run it on edge like Lambda@Edge.
But, for Api routes and serverless function on Vercel, there is a region and doesn't run on edge.
https://vercel.com/docs/concepts/functions/regions
I'm not an Vercel expert, I just read the official documentation. I might be wrong.
Thank you again for making an alternative.

We are transition this repo to https://github.com/sst/v2 and are closing this issue for now. If it is still relevant please reopen it there - sorry for the trouble


Packages that have been set to private continue to appear on yarnpkg

It appears that packages that have their access changed from public to private remain listed on yarnpkg.
Looking through the code, as far as I can tell, there isn't a mechanism for detecting changes in access level, which would mean the private package will remain indexed indefinitely.

Unfortunately that might be on npm's side, we are listening to changes in the registry, and visibility change doesn't seem to trigger a change event.
I'd love to have this handled automatically, possibly there's another event we can listen to? Feel free to reach out if you want to contribute


Tensor2Tensor Intro tensorflow.python.framework.errors_impl.OutOfRangeError: Read fewer bytes than requested

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
no
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
windows 10, x64
TensorFlow installed from (source or binary):
pip (pip install --upgrade tensorflow)
TensorFlow version (use command below):
1.10.0
Python version:
3.6
GPU model and memory:
not using GPU, 12GB memory
Mobile device: N/A
Bazel version : N/A
CUDA/cuDNN version : N/A

Describe the problem
I'm trying to make the Tensor2Tensor intro: English to German translation with a pre-trained model work locally. I have downloaded the checkpoints to the right directory, however it's returning this error:
tensorflow.python.framework.errors_impl.OutOfRangeError: Read fewer bytes than requested
As you can see the checkpoints are in the proper directory:

I have tried redownloading the checkpoints many times, I can't seem to get the English to German translation working with the provided checkpoints.
@lukaszkaiser

Exact command to reproduce:

# Imports we need.
import tensorflow as tf
import matplotlib.pyplot as plt
import numpy as np
import os
import collections

from tensor2tensor import models
from tensor2tensor import problems
from tensor2tensor.layers import common_layers
from tensor2tensor.utils import trainer_lib
from tensor2tensor.utils import t2t_model
from tensor2tensor.utils import registry
from tensor2tensor.utils import metrics

# Enable TF Eager execution
tfe = tf.contrib.eager
tfe.enable_eager_execution()

# Other setup
Modes = tf.estimator.ModeKeys

# Setup some directories
data_dir = os.path.expanduser("~/t2t-ende/data")
tmp_dir = os.path.expanduser("~/t2t-ende/tmp")
train_dir = os.path.expanduser("~/t2t-ende/train")
checkpoint_dir = os.path.expanduser("~/t2t-ende/checkpoints")
tf.gfile.MakeDirs(data_dir)
tf.gfile.MakeDirs(tmp_dir)
tf.gfile.MakeDirs(train_dir)
tf.gfile.MakeDirs(checkpoint_dir)
gs_data_dir = "gs://tensor2tensor-data"
gs_ckpt_dir = "gs://tensor2tensor-checkpoints/"

# Fetch the problem
ende_problem = problems.problem("translate_ende_wmt32k")

# Copy the vocab file locally so we can encode inputs and decode model outputs
# All vocabs are stored on GCS
vocab_name = "vocab.translate_ende_wmt32k.32768.subwords"
vocab_file = os.path.join(gs_data_dir, vocab_name)

# Get the encoders from the problem
encoders = ende_problem.feature_encoders(data_dir)

# Setup helper functions for encoding and decoding

def encode(input_str, output_str=None):
    """Input str to features dict, ready for inference"""
    inputs = encoders["inputs"].encode(input_str) + [1]  # add EOS id
    batch_inputs = tf.reshape(inputs, [1, -1, 1])  # Make it 3D.
    return {"inputs": batch_inputs}

def decode(integers):
    """List of ints to str"""
    integers = list(np.squeeze(integers))
    if 1 in integers:
        integers = integers[:integers.index(1)]
    return encoders["inputs"].decode(np.squeeze(integers))

# Generate and view the data
# This cell is commented out because WMT data generation can take hours

ende_problem.generate_data(data_dir, tmp_dir)
example = tfe.Iterator(ende_problem.dataset(Modes.TRAIN, data_dir)).next()
inputs = [int(x) for x in example["inputs"].numpy()]  # Cast to ints.
targets = [int(x) for x in example["targets"].numpy()]  # Cast to ints.

# Example inputs as int-tensor.
print("Inputs, encoded:")
print(inputs)
print("Inputs, decoded:")
# Example inputs as a sentence.
print(decode(inputs))
# Example targets as int-tensor.
print("Targets, encoded:")
print(targets)
# Example targets as a sentence.
print("Targets, decoded:")
print(decode(targets))

# Create hparams and the model
model_name = "transformer"
hparams_set = "transformer_base"

hparams = trainer_lib.create_hparams(
    hparams_set, data_dir=data_dir, problem_name="translate_ende_wmt32k")

# NOTE: Only create the model once when restoring from a checkpoint; it's a
# Layer and so subsequent instantiations will have different variable scopes
# that will not match the checkpoint.
translate_model = registry.model(model_name)(hparams, Modes.EVAL)

# Copy the pretrained checkpoint locally
ckpt_name = "transformer_ende_test"
gs_ckpt = os.path.join(gs_ckpt_dir, ckpt_name)
ckpt_path = tf.train.latest_checkpoint(os.path.join(checkpoint_dir, ckpt_name))

# Restore and translate!
def translate(inputs):
    encoded_inputs = encode(inputs)
    print(encoded_inputs)
    with tfe.restore_variables_on_create(ckpt_path):
        model_output = translate_model.infer(encoded_inputs)["outputs"]
        print(model_output)
    return decode(model_output)

inputs = "The animal didn't cross the street because it was too tired"
outputs = translate(inputs)

print("Inputs: %s" % inputs)
print("Outputs: %s" % outputs)`

Source code / logs

def translate(inputs):
...     encoded_inputs = encode(inputs)
...     print(encoded_inputs)
...     with tfe.restore_variables_on_create(ckpt_path):
...         model_output = translate_model.infer(encoded_inputs)["outputs"]
...         print(model_output)
...     return decode(model_output)
...
inputs = "The animal didn't cross the street because it was too tired"
outputs = translate(inputs)
{'inputs': <tf.Tensor: id=202, shape=(1, 15, 1), dtype=int32, numpy=
array([[[   28],
[ 4705],
[ 6253],
[   83],
[   62],
[ 3444],
[    4],
[ 3825],
[  244],
[   40],
[   53],
[  362],
[19285],
[   85],
[    1]]])>}
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in translate
File "C:\Users\david.salsbach\AppData\Local\Programs\Python\Python36\lib\contextlib.py", line 81, in enter
return next(self.gen)
File "C:\Users\david.salsbach\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\contrib\eager\python\saver.py", line 91, in restore_variables_on_create
ckpt_var_cache[k] = reader.get_tensor(k)
File "C:\Users\david.salsbach\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 348, in get_tensor
status)
File "C:\Users\david.salsbach\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\framework\errors_impl.py", line 519, in exit
c_api.TF_GetCode(self.status.status))
tensorflow.python.framework.errors_impl.OutOfRangeError: Read fewer bytes than requested
print("Inputs: %s" % inputs)
Inputs: The animal didn't cross the street because it was too tired
print("Outputs: %s" % outputs)
Traceback (most recent call last):
File "", line 1, in
NameError: name 'outputs' is not defined

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Mobile device

@davypepe From your screenshot it appears that at least some of the files were not downloaded completely. You may consider switching to GPU or use Git LFS.

@wt-huang Thanks! I'll try that out and close the issue for now! 😎


Build Error "array type has incomplete element type"

Thank you for making this great package.
In one of my applications, two build errors of the same type were triggered: array type has incomplete element type. The file that has these two array types is an automatically generated header file: globalVAR.h. It seems this header file is generated based on the PLC project's Global.var and the tags that caused this error are arrays of global UDT.
The two array type tags from globalVAR.h are:
_GLOBAL_RETAIN struct UDT_VesselDetails ShipList[10];
_GLOBAL struct PLCConnected PLC_Connected[31];

The global tags that they are generated based on are:
ShipList : ARRAY[0..9] OF UDT_VesselDetails;
PLC_Connected : ARRAY[0..30] OF PLCConnected;
The UDT are defined:
UDT_VesselDetails : 	STRUCT
	Name : STRING[80]; (*Name of vessel*)
	ShipIPString : STRING[80]; (*IP Address of MicroLogix PLC*)
	HasControl : BOOL; (*Selected ship has control of berth*)
	MMSI : DINT; (*MMSI of vessel*)
	LOA : INT; (*LOA of vessel*)
	ShipID : SINT; (*Internal Cavotec ID number of Ship (array index)*)
	Distance : REAL; (*AIS generated distance to berth*)
END_STRUCT;

PLCConnected : 	STRUCT
	TxEnabled : BOOL;
	Connected : INT;
	WDogValue : DINT;
	PrevWDogValue : DINT;
	TMR_Connected : TON;
	TMR_TxEnabled : TON;
END_STRUCT;

The PLC project can compile with no issue without installing this package.
Let me know if I can provide any further information. 👍

Thanks for sharing your issue.
I suspect this is related to the default includes mechanism in Automation Studio projects, but I'm not certain.
Can you follow this link and try out the compiler setting.
You only have to set -U _DEFAULT_INCLUDES for the "BuildVer" task (or whatever it's named) in the software configuration "cpu.sw".  Nothing else in the project should have to change.
If that doesn't resolve your issue, can you send a screenshot of the build console showing the info, warning, and error messages and numbers.

Hi tmatijevich,
Thank you very much for your quick response.
By setting the default include option, the compile error is resolved and I can see that all the buildversion type data is available in the task now.
Thank you very much for creating this cool package, it is very helpful to us 👍

Issue resolved by adding default include option in the buildversion task's compiler option.


The preview breaks every time, and I need to reload the page again

Describe the bug
The preview breaks every time, and I need to reload the page again
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-bpgevw
Steps to reproduce
make any changes whatsoever.

Expected behavior
I expected the preview to make the edits that were made in the code.
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 130
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 177145889,
  "usedJSHeapSize": 156999437,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = jimjcranshaw
Chat ID = 0ea43b1e9785

Additional context
No response

Appreciate the feedback! We are aware of this issue and are tracking it here: #1791. You can also try typing “npm run dev” in the Bolt console to see if that resolves the issue. We appreciate your patience as improvements continue to be made!

Hi Brian,
Thanks for the quick response and the workaround suggestion. I'll give that
a try.
Cheers,
Jim
https://www.linkedin.com/in/jim-cranshaw-b450b430/
Jim Cranshaw
Consultant
[image: envelope]  @.***
[image: phone] (0044)<PHONE_NUMBER>
[image: linkedin] https://www.linkedin.com/in/jim-cranshaw-b450b430/ [image:
telegram-plane] https://www.flourishnonprofits.org/
Book a call directly into my calendar
https://tidycal.com/jimjcranshaw/60-min-meeting
[image: Email Badge] https://emailbadge.com/?utm_source=signature
On Tue, 12 Nov 2024 at 14:09, Brian @.***> wrote:

Appreciate the feedback! We are aware of this issue and are tracking it
here: #1791 https://github.com/stackblitz/bolt.new/issues/1791. You can
also try typing “npm run dev” in the Bolt console to see if that resolves
the issue. We appreciate your patience as improvements continue to be made!
—
Reply to this email directly, view it on GitHub
https://github.com/stackblitz/bolt.new/issues/2090#issuecomment-2470633967,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7ZO4GBERJPQHWMULFXP5T32AIDYTAVCNFSM6AAAAABRT76OP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZQGYZTGOJWG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


GraphQL Examples

Thank you for the GraphQL update a few months back. I've actually had some time to play around with this, as it's my first experience with GraphQL. In a previous issue, you gave an example to pull some basic data, which works perfectly.
Can we get just a few more basic examples using mutations for example? I'm struggling to get one simple query working with Basic-Shopify-API throwing an error at me, Undefined property: stdClass::$extensions.
Any help is much appreciated.

Whats the query? Sorry I don't use the GraphQL as its still "beta" by shopify.

Ok so long story short, can't get mutations working using application/graphql, only application/json.
So lets take the adding of a collection using mutations. Shopify URL.
Using postman, I'm able to use the following, under content-type: application/json. This will successfully create a collection and return the approprate results. Note: Postman doesn't play nicely with GraphQL.
{
    "query": "mutation collectionCreate($input: CollectionInput!) { collectionCreate(input: $input) { userErrors { field message } collection { id } } }",
    "variables": {
        "input":{
            "title":"Test Collection"
        }
    }
}

In Basic-Shopify-API, using that same query will throw an exception. This is because there is no check if the body contains an error, it just assumes there will always be a cost. $calls = $body->extensions->cost;. However, changing the 'Content-Type' to application/json allows mutations to work as expected (if you follow the right formula).
I followed this up on the Shopify Slack, to quote from Richard Borek on the GraphQL channel

Yes I too struggled at first, the key is that GraphQL is only JSON and that the query is a single JSON object.  I was able to reverse engineer this using Insomnia to test then looked at the raw HTTP Requests.  I’m an avid Postman user so if that is the tool your using to test I will say it is possible but not until you grasp the subtle formatting of the JSON object.  Also the request header is application/json not application/graphql.

I know that the Shopify docs state the content-type should be graphql but I for the life of me cannot get it working.

That's interesting... Yes I completely based it off the docs but if it's
just doing JSON then that certainly changes some things. I guess that's why
it's beta :/ This information is great, thank you.
I'll have to mod the code to support this and patch a fix in. Hopefully
this evening if I don't run into issues. And hopefully they do not change
it up in the future to cause a break!
On Thu., Aug. 23, 2018, 8:10 a.m. Kim Skinner<EMAIL_ADDRESS>wrote:

Ok so long story short, can't get mutations working using
application/graphql, only application/json.
So lets take the adding of a collection using mutations. Shopify URL
https://help.shopify.com/en/api/graphql-admin-api/reference/mutation/collectioncreate
.
Using postman, I'm able to use the following, under content-type:
application/json. This will successfully create a collection and return
the approprate results. Note: Postman doesn't play nicely with GraphQL.
{
"query": "mutation collectionCreate($input: CollectionInput!) { collectionCreate(input: $input) { userErrors { field message } collection { id } } }",
"variables": {
"input":{
"title":"Test Collection"
}
}
}
In Basic-Shopify-API, using that same query will throw an exception. This
is because there is no check if the body contains an error, it just assumes
there will always be a cost. $calls = $body->extensions->cost;. However,
changing the 'Content-Type' to application/json allows mutations to work
as expected (if you follow the right formula).
I followed this up on the Shopify Slack, to quote from Richard Borek on
the GraphQL channel
Yes I too struggled at first, the key is that GraphQL is only JSON and
that the query is a single JSON object. I was able to reverse engineer this
using Insomnia to test then looked at the raw HTTP Requests. I’m an avid
Postman user so if that is the tool your using to test I will say it is
possible but not until you grasp the subtle formatting of the JSON object.
Also the request header is application/json not application/graphql.
I know that the Shopify docs state the content-type should be graphql but
I for the life of me cannot get it working.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/Basic-Shopify-API/issues/10#issuecomment-415371357,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTuOoV_PaZOnEhRe9puczZd74gbYX__ks5uToahgaJpZM4WFBaY
.

@KimKJDesigns  Dug into it... yes using JSON encoded body/header works now.
Passing query (and variables if needed), seems to solve it. Running the below:
<?php
require __DIR__.'/vendor/autoload.php';

use OhMyBrew\BasicShopifyAPI;

$api = new BasicShopifyAPI(true);
$api->setShop('xxx');
$api->setApiKey('xxxx');
$api->setApiPassword('xxx');

$result = $api->graph(
    'mutation collectionCreate($input: CollectionInput!) { collectionCreate(input: $input) { userErrors { field message } collection { id } } }',
    ['input' => ['title' => 'Test Collection']]
);
print_r($result->body->collectionCreate);

$result = $api->graph('{ shop { products(first: 1) { edges { node { handle } } } } }');
print_r($result->body);

Produces:
stdClass Object
(
    [userErrors] => Array
        (
        )
    [collection] => stdClass Object
        (
            [id] => gid://shopify/Collection/63168315434
        )
)

stdClass Object
(
    [shop] => stdClass Object
        (
            [products] => stdClass Object
                (
                    [edges] => Array
                        (
                            [0] => stdClass Object
                                (
                                    [node] => stdClass Object
                                        (
                                            [handle] => test-product
                                        )
                                )
                        )
                )
        )
)

Theres a minor bug I need to solve but so far -- working.. will push up a fix within the weekend.

@KimKJDesigns Updated with unit tests, passed. Updated readme with examples. Added support for the mutations/variables, a long with checking if costs come into play, and errors.
Would you mind pulling graph-ql-adjustment branch and testing? I've tried product mutations, queries, collection mutations, queries... all seems fine unless I'm missing something.

@ohmybrew Perfect!! After testing the branch, Basic-Shopify-API is working as expected.  You've gone above and beyond, integrating it directly into graph function.
Previously, I was creating a payload (query and variables) and json_encoding the payload before sending the request.
The response checking for errors has stopped the exception being thrown if an error is returned.
$query = 'mutation collectionCreate($input: CollectionInput!) {
    collectionCreate(input: $input) {
        userErrors {
            field
            message
        }
        collection {
            id
        }
    }
}';

$variables = [
    'input' => [
        'title' => 'Test Collection'
    ]
];

$shop = $api->graph($query, $variables);

Thanks for taking the time to make these changes.

Thanks for confirming! Will close this, v3.0.2 (previous v3.0.1) contains the branch fixes, plus passing tests.


Use fbp-graph dependency instead of NoFlo

build/the-graph.js goes from around 3 MB to 300 KB :)

There are no tests, so CI result is not super useful. Did you verify that it works? Related to #315

@bergie yes, by running both examples and clicking around (demo-full.html and demo-simple.html)


Improve permissions management

Maybe define permissions as a list in a configuration file:
{
    "permissions": [{
        "verbose_name": "Download request",
        "name": "can_request_download",
        "description": "The user can request the bot to download a torrent by sending it a magnet"
    }]
}

Or in TOML maybe.

I went with a Python class. Code has been extracted into pawamoy/privibot


Add 5.1 images with a little cleanup

Built on @ianpartridge's original 5.1 effort. Adds signature verification, ability to override the key fingerprint used for verification, and ability to override the base URL used for downloads.

@swift-ci test

@swift-ci test

@swift-ci please test

Test failures were for the ever-wonderful failure to bind requested address for the keyservers. The images build correctly locally.

cc @shahmishal

Thanks! For the slim images we only want the runtime libraries, not the whole toolchain. See https://github.com/apple/swift-docker/blob/master/5.0/ubuntu/16.04/slim/Dockerfile#L40

@ianpartridge Yikes, thanks! Nothing like a little copypasta to mess you up 😅 I also fixed the caching of the images around curl and gnupg (with the latter turning out to only be needed by the slim 18.04 image, since Xenial has it as a dependency of apt and in non-slim Bionic we get it via dpkg-dev's recommends via our pkg-config)

@swift-ci please test

@swift-ci please test

No rush, but I would love to have this image available soon. :D

I could also really use this image when it's convenient to release it ❤

@shahmishal your changes look good!

Created new PR with Swift 5.1 release packages - https://github.com/apple/swift-docker/pull/147


error in tomcat

I tested the Helloworld sample in local standalone project and it works fun. but when i used WebCam.getDefault() method and packaged it to war file and deployed into tomcat, the program went something wrong after startup tomcat. no errors in logs, but the program "appears" to sleep. and I found the Bootstrap process is in "no response" status. I am using mac.

any one could help?
Webcam webcam = Webcam.getDefault(); // the program "appears" to sleep when this method is invoked.

In fact, i got this exception during getDefault() method: ERROR c.g.sarxos.webcam.ds.buildin.WebcamDefaultDriver - Processor has been interrupted
public OpenIMAJGrabber newGrabber() {
try {
this.process();
} catch (InterruptedException var2) {
WebcamDefaultDriver.LOG.error("Processor has been interrupted");
return null;
}
        return (OpenIMAJGrabber)this.grabber.get();
    }


Initial Q# Package System

Q# Package System
Definitions

package: an exported or imported Q# project.
package system: the canonical and conventional way to export or import Q# projects, as packages.

Note the above constrained definitions -- we are not trying to build a registry or robust SemVer-based system at this point.
Objectives

Unblock code-sharing for library authors.
Provide alternative canonical Microsoft libraries that are not the standard library
Provide a conventional system that supports the common use case of sharing publicly available code
Don't immediately support private libraries, that can be a follow-on task
Be able to construct a complete list of sources and fetch them before compilation begins

User Stories

As a hardware partner, I would like to publish an algorithm, as a Q# library, to showcase my hardware's capabilities.
As a Q# author, I would like to import code without having to copy-paste it into my project.

Potential Design
We initially only support shared code on GitHub. We use the GitHub REST API, which supports listing directories and cloning subfolders. This helps us avoid libgit2, which is impermissively licensed, and any native git implementations which may not work on all of our scenarios.
To import a Q# package, the user will add an entry to their manifest file's dependencies property. This will look similar to the dependencies property in a package.json. We could even use their GitHub URL shorthand., or we could just use GitHub URLs.
We will browse to that URL, look for a qsharp.json in the specified subfolder, or the root if no subfolder is specified, and parse the dependencies of that package. We will continue this process, browsing to them and parsing their manifests, with all dependencies until we have a complete graph of direct dependencies and transitive dependencies. At this stage, we will load all of these sources into memory and begin compilation as normal. In non-web scenarios, we may be able to cache these dependencies to disk, but in web scenarios, they may be cached in the state of the language service.
Related: #73
### Tasks
- [ ] Tests: test dependency ordering edge cases with different language features enabled, etc
- [ ] Tests: test that entry points in libraries are not used

feature/party tasks

[ ] support files property in qsharp.json for package authoring

[ ] require it if packageType == "lib"
[ ] warn about missing source files items after crawling directory on disk
[ ] provide way to automatically add missing source files to qsharp.json


msadgraph

Name of the app
msadgraph
Integration
App integrates with Microsoft Active Directory
About
Connects to Microsoft AD using MS Graph REST API services
Thank you for contributing to Splunk SOAR!

Repo created at https://github.com/splunk-soar-connectors/msadgraph


controller files *.js.erb silently fail (with new loader stimulus-loading)

Hello,
New loader module stimulus-loading.js, when used in default eager loading mode, silently fails. My setup shows only hello-controller on the list of app assets in dev console. out of 3 controller files, 2 of them are with .erb. When switched to lazy loading, produces warning
Failed to autoload controller: output
Error: Unable to resolve specifier 'controllers/output_controller' from http://localhost:3003/assets/stimulus-loading-685d40a0b68f785d3cdbab1c0f3575320497

My output_controller.jr.erb is using erb code and worked fine before updating to new loader in 0.7.1
importmap.rb:
pin_all_from "app/javascript/controllers", under: "controllers"
sprockets manifest.js:
//= link_tree ../../javascript .js
I am not sure if this is a bug or something wrong in my app setup.
If I use rails stimulus:manifest:update task generated imports are using .erb in the import names, which is not working. But after correcting import names to end with .js they work.

Having this issue with stimulus-rails 1.0.4 and sprockets. Did you resolve this?

@alanq, I do not recall the details now, it's been a while. I am sure that I had to refactor my code to avoid using .erb templates, as Sprockets does not recompile them to JS code.


allow instance with missing or background activity

In the previous version, it was possible to instantiate the nfc handler in states where the app would crash.
This allows the user to instantiate the class at the very beginning of the app, as well a in the middle of a foreground activity.
fix #45

@EddyVerbruggen Hi Eddy,
Could you please check this pr?

I hope today even!

Turned out I had to change a few small things, otherwise the demo app (npm run demo.android) crashed upon start.
I've just published 4.0.4 to npm and hope it's all fine for your usecase.


Local Network Device Discovery Script 🌐🔍

Objective:
Create a Python script to discover devices on a local network. This script will send ARP requests to obtain information about active devices.
Features:

Device Discovery:

Implement a function to send ARP requests to all devices on the local network.

Information Retrieval:

Retrieve and display the IP and MAC addresses of discovered devices.

User-Friendly Output:

Present the information in a clear and easy-to-read format.
or just return a list of dictionaries that contain discovered information.

Example Usage:
# Example usage of the local network device discovery script
import network_discovery

devices = network_discovery.discover_devices("<IP_ADDRESS>/24")

Difficulty: Beginner/Intermediate
Tags: Python, Utility, Networking
Additional Information:

Familiarity with networking concepts and Python scripting is recommended for contributors taking on this task.
Important---Ensure to obtain proper authorization before conducting any network scanning.

Assign it to me @bhargavnova


isAvailable() doesn't work on Android 11+ without change to AndroidManifest.xml

Very nice module – thanks!  It's perhaps worth mentioning in the documentation that, from Android 11 onwards, you need to add this to AndroidManifest.xml, otherwise the isAvailable() function will always return false:
    <queries>
      <package android:name="com.google.android.apps.fitness" />
    </queries>

See https://developer.android.com/training/package-visibility/declaring for more information.

@rblakesley we did. https://github.com/StasDoskalenko/react-native-google-fit#android-11