feat: add DataConverter to convert types

Description
Supersedes #7995

add DataConverter class to convert column values

        $types = [
            'id'   => 'int',
            'date' => 'datetime',
        ];
        $converter = new DataConverter($types);

        $dbData = [
            'id'   => '1',
            'date' => '2023-11-18 14:18:18',
        ];
        $data = $converter->fromDataSource($dbData);
        dd($data);

array (2) [
    'id' => integer 1
    'date' => CodeIgniter\I18n\Time#44 (6) (
        protected 'timezone' -> DateTimeZone#45 (2) (
            public 'timezone_type' -> integer 3
            public 'timezone' -> string (3) "UTC"
        )
        protected 'locale' -> string (2) "en"
        protected 'toStringFormat' -> string (19) "yyyy-MM-dd HH:mm:ss"
        public 'date' -> string (26) "2023-11-18 14:18:18.000000"
        public 'timezone_type' -> integer 3
        public 'timezone' -> string (3) "UTC"
    )
]

Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

The codes are almost identical. However, this PR is not a feature in Entity, and can be used in Models (or others)

The current Entity has problems.

An Entity is a PHP object, but it holds data retrieved from a DB (except for dates) and does not have the correct type of values in PHP. So there is a bug #5905 where hasChange() returns the wrong value.
Entity has too much knowledge about DB; since Entity is a PHP representation of a DB record, knowledge of DB is essentially unnecessary.

Each handler has a specific type(s) to handle. So, I think I can do it, but as far as I tried a little, I could not specify the types well.

Entity has too much knowledge about DB; since Entity is a PHP representation of a DB record, knowledge of DB is essentially unnecessary.

I agree. Entities could have been value objects only.

Each handler has a specific type(s) to handle. So, I think I can do it, but as far as I tried a little, I could not specify the types well.

I tried something like these:
diff --git a/system/Database/DataConverter/Cast/CastInterface.php b/system/Database/DataConverter/Cast/CastInterface.php
index 540623ea33..b793b6ea20 100644
--- a/system/Database/DataConverter/Cast/CastInterface.php
+++ b/system/Database/DataConverter/Cast/CastInterface.php
@@ -12,27 +12,28 @@
 namespace CodeIgniter\Database\DataConverter\Cast;

 /**
- * Interface CastInterface
+ * @template TDbColumn
+ * @template TPhpValue
  */
 interface CastInterface
 {
     /**
      * Takes value from database, returns its value for PHP.
      *
-     * @param bool|float|int|string|null $value  Data
-     * @param array                      $params Additional param
+     * @param TDbColumn    $value  Data
+     * @param list<string> $params Additional param
      *
-     * @return array|bool|float|int|object|string|null
+     * @return TPhpValue
      */
-    public static function fromDatabase($value, array $params = []);
+    public static function fromDatabase(mixed $value, array $params = []): mixed;

     /**
      * Takes the PHP value, returns its value for database.
      *
-     * @param array|bool|float|int|object|string|null $value  Data
-     * @param array                                   $params Additional param
+     * @param TPhpValue    $value  Data
+     * @param list<string> $params Additional param
      *
-     * @return bool|float|int|string|null
+     * @return TDbColumn
      */
-    public static function toDatabase($value, array $params = []);
+    public static function toDatabase(mixed $value, array $params = []): mixed;
 }

diff --git a/system/Database/DataConverter/Cast/BaseCast.php b/system/Database/DataConverter/Cast/BaseCast.php
index d35b761622..e8ef0e13ba 100644
--- a/system/Database/DataConverter/Cast/BaseCast.php
+++ b/system/Database/DataConverter/Cast/BaseCast.php
@@ -14,28 +14,25 @@ namespace CodeIgniter\Database\DataConverter\Cast;
 use TypeError;

 /**
- * Class BaseCast
+ * @template TDbColumn
+ * @template TPhpValue
+ *
+ * @implements CastInterface<TDbColumn, TPhpValue>
  */
 abstract class BaseCast implements CastInterface
 {
-    /**
-     * {@inheritDoc}
-     */
-    public static function fromDatabase($value, array $params = [])
+    public static function fromDatabase(mixed $value, array $params = []): mixed
     {
         return $value;
     }

-    /**
-     * {@inheritDoc}
-     */
-    public static function toDatabase($value, array $params = [])
+    public static function toDatabase(mixed $value, array $params = []): mixed
     {
         return $value;
     }

     /**
-     * Throws TypeError
+     * @throws TypeError
      */
     protected static function invalidTypeValueError(mixed $value): never
     {

diff --git a/system/Database/DataConverter/Cast/ArrayCast.php b/system/Database/DataConverter/Cast/ArrayCast.php
index 4b41d9367d..3f0e517289 100644
--- a/system/Database/DataConverter/Cast/ArrayCast.php
+++ b/system/Database/DataConverter/Cast/ArrayCast.php
@@ -15,13 +15,12 @@ namespace CodeIgniter\Database\DataConverter\Cast;
  * Class ArrayCast
  *
  * DB column: string <--> PHP: array
+ *
+ * @extends BaseCast<string, mixed[]>
  */
 class ArrayCast extends BaseCast implements CastInterface
 {
-    /**
-     * {@inheritDoc}
-     */
-    public static function fromDatabase($value, array $params = []): array
+    public static function fromDatabase(mixed $value, array $params = []): array
     {
         if (! is_string($value)) {
             self::invalidTypeValueError($value);
@@ -34,10 +33,7 @@ class ArrayCast extends BaseCast implements CastInterface
         return (array) $value;
     }

-    /**
-     * {@inheritDoc}
-     */
-    public static function toDatabase($value, array $params = []): string
+    public static function toDatabase(mixed $value, array $params = []): string
     {
         return serialize($value);
     }

and tested with this script:
<?php

use CodeIgniter\Database\DataConverter\Cast\ArrayCast;

ArrayCast::fromDatabase([]);

resulted in:
$ vendor/bin/phpstan analyse -v test.php
Note: Using configuration file C:\Users\P\Desktop\Web Dev\CodeIgniter4\phpstan.neon.
 1/1 [============================] 100% 2 secs

 ------ -------------------------------------------------------------------------------------------------------------------------------------
  Line   test.php
 ------ -------------------------------------------------------------------------------------------------------------------------------------
  :5     Parameter #1 $value of static method CodeIgniter\Database\DataConverter\Cast\ArrayCast::fromDatabase() expects string, array given.
         ✏  test.php:5
 ------ -------------------------------------------------------------------------------------------------------------------------------------

 [ERROR] Found 1 error

Used memory: 114 MB

Hmm... Looks like a truncated Entity class with a cast option.
What is the plan for this? A part of the Entity class rewrite or an entirely separate thing?
As it stands, it is moderately useful. Sure - it works, but if I have to manually declare types every time, I'll start pulling my hair out. I would like to declare types one time and then reuse them for the data I work with. Just like in the Entity class.
I'm really curious about a plan for this class.

@michalsn This class is now complete.
The ultimate goal is to fix bug #5905 in Entity, but it is not easy.
The next step is to make this class available from Model so that the model can return data with the correct type of values when Entity is not used.

@kenjis IMO the solution for Entity is one and simple, as long as everyone will agree on it. The values provided to the Entity class should be casted right away, when creating an instance and then treated as an original data.
From what you're saying DataConverter class looks like an additional option that we will be able to use instead of the Entity class. Will the final Entity class deprecate the cast option and use the input values provided by the DataConverter class? Because if not, I don't see how this will help resolve the issues with an Entity class.
I'd like to know a little more concrete plan for what changes you want to make before we add another layer to convert the data. Right now I can't decide if I like the potential level of complexity the new layer adds.

I realize I'm out of touch here, but this does seem like an overly complex solution to the original issue. And definitely doesn't seem to follow the old CodeIgniter way of attempting to keep things simple. This problem has been solved before by other frameworks. Have we looked at them to see how they've solved it as inspiration?
Sorry, without diving into the code deeper right now I don't have any advice on solutions but watching the email threads got me a little concerned we're slapping a complex bandaid on an issue that can be solved in a simpler fashion somewhere else.

The values provided to the Entity class should be casted right away, when creating an instance and then treated as an original data.

That is what I'm trying to do.

The big picture at this point looks like this.

This DataConverter provides some of the functionality of Entity's property casting. It only converts data to and from the database.
Using DataConverter, Model will have the functionality of casting.
Entity will use the casting in Model, and we don't need to use Entity's property casting for data conversion to and from the database.

@lonnieezell Thank you for your comment!
I don't think this is overly complex. The DataConverter just converts data, and I just move a part of functionality from Entity's property casting. Entity is already too complex.
I have no idea what the solution in other frameworks means. I would appreciate it if you could give me some concrete examples. At the very least, in Laravel the model has casting functionality.

Thank you @kenjis for this enhancement. I asked for this feature some time ago.
My two cents:

This is different from using Entitiy, because using Entitiy is an ORM pattern, which could be overcomplicated for users over the Query Builder. I mean - it forces the user to create and work with new classes, which he might not want to do.
For me casting to integer was fine, but nowadays many tables (almost all of mine) have JSON fields and casting from/to them every time working with DB is very inconvenient and error prone. So this feature is really in demand.
My workaround was to have a PHP file with table feald type definitions and use model hooks ($beforeUpdate etc) for type conversions, but native solution would be much better
This is the example of it:

class ResourcesMeta
{
    private static $resources = [
        "user_activity" => [
            "exposedFields" => ["*"],
            "types" => [
                "number" => ["id", "userId"],
                "json" => ["extraData"],
            ],
        ],
        "user_balance_history" => [
            "exposedFields" => ["*"],
            "types" => [
                "number" => ["id", "userId", "balanceAfter", "balanceBefore", "walletId"],
                "json" => ["data"],
            ],
        ],

I sent a draft PR #8243 about casting in the model.
I think I can make the model without breaking changes, but I'm not sure yet what will happen to Entity.

Why these errors by Psalm?
ERROR: NoValue - system/Database/DataConverter/Cast/CSVCast.php:32:29 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
        return explode(',', $value);

ERROR: NoValue - system/Database/DataConverter/Cast/CSVCast.php:44:29 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
        return implode(',', $value);

ERROR: NoValue - system/Database/DataConverter/Cast/DatetimeCast.php:37:28 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
        return Time::parse($value);

ERROR: NoValue - system/Database/DataConverter/Cast/JsonCast.php:41:21 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
            (strlen($value) > 1 && in_array($value[0], ['[', '{', '"'], true))

ERROR: NoValue - system/Database/DataConverter/Cast/JsonCast.php:45:39 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
                $output = json_decode($value, $associative, 512, JSON_THROW_ON_ERROR);

ERROR: NoValue - system/Database/DataConverter/Cast/URICast.php:34:24 - All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
        return new URI($value);

because using Entity is an ORM pattern

@altrusl Entities are not ORM objects, they are intended to be data source object representations  in the Repository pattern.

@kenjis

I think I can make the model without breaking changes, but I'm not sure yet what will happen to Entity.

In the worst-case scenario, I would not be opposed to "depreciating" the current one and creating a new Entity class.
However, I believe that the casting functionality in the Entity class should remain as an option (and probably use DataConverter by default?), because no one has said that Entities cannot be used for data that does not come from a database. I personally was using the casting option in Entity class for data that comes from files and API endpoints before.
Given this, maybe we should reconsider the chosen namespace since casting should not be reserved only for working with database data.

@MGatner @altrusl There seems to be some confusion as to what Entity is in CI4.
In fact, I am not sure what this Entity is either.
There seems to be also some confusion as to what "Repository Pattern" is.
The user guide includes the following statements:

CodeIgniter supports Entity classes as a first-class citizen in it’s database layer

At its core, an Entity class is simply a class that represents a single database row. It has class properties to represent the database columns, and provides any additional methods to implement the business logic for that row.
https://codeigniter4.github.io/CodeIgniter4/models/entities.html#entity-usage

After reading this in the past, I understood as the following:
It is a database layer object that has database columns and represents a database row.
However, the current discussion seems to be moving in the direction that the Entity is not a DB layer object.
I agree with that idea.

https://chat.openai.com/share/9437d9ca-6365-4070-b11b-9c31cede7a2a
The Repository Pattern is a design pattern commonly used in software development to abstract the data access logic from the rest of the application. In the context of PHP development, the Repository Pattern is often applied to manage database interactions.
The main idea behind the Repository Pattern is to create a layer of abstraction that sits between the application's business logic and the data source (usually a database). This layer, known as the repository, provides a set of methods for performing CRUD (Create, Read, Update, Delete) operations on the data without exposing the underlying database details to the rest of the application.
Here's a simple example of how you might implement a basic UserRepository in PHP using the Repository Pattern:
// User model representing a user entity
class User {
    public $id;
    public $username;
    public $email;

    // Additional properties and methods can be added as needed
}

// UserRepository interface defining the contract for data access
interface UserRepositoryInterface {
    public function getById($id);
    public function getByUsername($username);
    public function save(User $user);
    public function update(User $user);
    public function delete(User $user);
}

// UserRepository implementing the Repository Pattern
class UserRepository implements UserRepositoryInterface {
    private $db;

    public function __construct(PDO $db) {
        $this->db = $db;
    }

    public function getById($id) {
        // Logic to fetch a user by ID from the database
    }

    public function getByUsername($username) {
        // Logic to fetch a user by username from the database
    }

    public function save(User $user) {
        // Logic to save a new user to the database
    }

    public function update(User $user) {
        // Logic to update an existing user in the database
    }

    public function delete(User $user) {
        // Logic to delete a user from the database
    }
}

// Example of how the UserRepository might be used in your application
$db = new PDO('mysql:host=localhost;dbname=mydatabase', 'username', 'password');
$userRepository = new UserRepository($db);

// Example of fetching a user by ID
$user = $userRepository->getById(1);

// Example of saving a new user
$newUser = new User();
$newUser->username = 'john_doe';
$newUser->email =<EMAIL_ADDRESS>$userRepository->save($newUser);

// Example of updating an existing user
$userToUpdate = $userRepository->getById(2);
$userToUpdate->email =<EMAIL_ADDRESS>$userRepository->update($userToUpdate);

// Example of deleting a user
$userToDelete = $userRepository->getById(3);
$userRepository->delete($userToDelete);

In this example, the UserRepository class provides methods for fetching users by ID or username, saving new users, updating existing users, and deleting users. The actual database interactions are encapsulated within the repository, allowing the rest of the application to work with user objects without having to know the details of how the data is stored or retrieved from the database.

However, I believe that the casting functionality in the Entity class should remain as an option (and probably use DataConverter by default?), because no one has said that Entities cannot be used for data that does not come from a database. I personally was using the casting option in Entity class for data that comes from files and API endpoints before.

Besides the backward compatibility issue, we have to leave the Entity casting so that we can do something like JoeCast.

Given this, maybe we should reconsider the chosen namespace since casting should not be reserved only for working with database data.

Changed the namespace to CodeIgniter\DataConverter.

I have no idea what the solution in other frameworks means. I would appreciate it if you could give me some concrete examples. At the very least, in Laravel the model has casting functionality.

I was just asking if you had looked at their solutions. I haven't done a deep dive in any of the other frameworks around this either. Laravel has it in the model because their model handles the functionality of both our model and our entity.

Entity has too much knowledge about DB; since Entity is a PHP representation of a DB record, knowledge of DB is essentially unnecessary.

Looking through the Entity class I see no direct knowledge of the database. I didn't look through all of the casts, but IIRC the model fills the data into the Entity class and from there it acts as a value object with capabilities to map/cast the data and that should be about it. What am I missing?

Unpopular opinion here, but it seems like maybe the entire issue could be solved by doing a loose check in the hasChanged function instead of a strict check? I haven't thought through every case but if the database returns everything as a string, and web forms provide everything as a string, then we should be able to have the Entity class work with those strings easily. It seems that we're making things difficult by trying to force strict types in a place that is stuck between 2 layers that operate in strings. That would fix the issue that was reported in #5905 that this was trying to fix.
PHP is and always will be a loosely-typed language at its core so we shouldn't always shy away from that.

Looking through the Entity class I see no direct knowledge of the database. I didn't look through all of the casts, but IIRC the model fills the data into the Entity class and from there it acts as a value object with capabilities to map/cast the data and that should be about it. What am I missing?

Raw data or raw values in Entity are values from the database.
These values are database dependent and can change if the data source changes.
These are the knowledge of the database. E.g., MySQL returns a string data even if the column type is integer.
Entity does not need to know them.
The model just needs to fill the correct values to the Entity.
Cast handlers also exist mostly for these raw values and are not needed without them.

This PR is also for fixing #5905, but it is an enhancement.
Casting in Entity can be used only when we use the Entity, but this PR make it possible to cast with other custom objects.
There was a feature request:
https://forum.codeigniter.com/showthread.php?tid=85956

if the database returns everything as a string, and web forms provide everything as a string, then we should be able to have the Entity class work with those strings easily.

True, but that is a thing of the past, and the PHP world has now moved on to stricter typing many years ago.
And it is currently impossible for all values coming from outside to be strings.

if the database returns everything as a string

That is not exactly true. PostgreSQL will respect the types by default if I'm not mistaken and in MySQL there is a flag MYSQLI_OPT_INT_AND_FLOAT_NATIVE which can be switched on (even via the connection config in codeigniter) and then results will not contain only strings.
I agree that this is an upgrade. Now we will be able to cast objects and arrays too, not only Entities. While using DataConverter will still be optional, I see no downsides.

Unpopular opinion here, but it seems like maybe the entire issue could be solved by doing a loose check in the hasChanged function instead of a strict check?

It might be unpopular, since from what I see we're following the path to strict types as much as possible in the framework. Even if we would follow that route with a loose check, after some time there would be someone who would open a bug report about this, saying that it's working incorrectly.

Just because someone opens a bug report doesn't mean they're right and the thing needs to be changed.
Just because there's been ways to do type checking doesn't mean the language itself is strictly typed.
Either way I'm out voted.

Just because someone opens a bug report doesn't mean they're right and the thing needs to be changed.
Just because there's been ways to do type checking doesn't mean the language itself is strictly typed.

Agreed, I probably used too much shorthand to describe what I mean. If strong typing is promoted throughout the framework, then changing to loose check for Entity would be pretty hard to defend. At least that's what I think, so reporting it as a bug would be justified. Of course, we can always say that this is by design, but should it really be? Here I have my doubts.
In any case, we'll probably come back to this discussion on the occasion of a dedicated PR for Entity and there will be an opportunity to weigh the pros and cons. I have my doubts, but I'm not ruling anything out yet.

Obviously I'm not going to change any minds here but here's my overall issue.
Unless I've missed it in the latest versions of PHP there is no way to tell the language to be strictly typed. So if I pass a string to a function that requires an int argument its type is going to be coerced into an int if possible. So there's no way to change that which mean the developer generally already expects this and is used to it. So yes we can support that argument I feel. If I wanted to use a language that was strongly typed I would choose another one.
So instead of working with the language we have we are choosing to add more complexity and code and technical debt to maintain in the future. Codeigniter's code used to one of finding the simplest solution to a problem, something that I believe we have strayed from over the last few years. And yes I am aware that my rewrite of v4 was partially to blame for that. I apologize. I just miss a framework with a vision for simplicity and clarity. I apologize for my part in that.

So if I pass a string to a function that requires an int argument its type is going to be coerced into an int if possible.

It is not true. It will cause a TypeError when we use declare(strict_types=1).
https://3v4l.org/gdeE7

If strong typing is promoted throughout the framework, then changing to loose check for Entity would be pretty hard to defend. At least that's what I think, so reporting it as a bug would be justified.

I agree with this opinion.

It's been awhile but I'm pretty sure strict types only apply to calls made from that file to functions within the same file. It does not affect calls from outside of the file to those functions.
That was a compromise made when they added it so they didn't break all of the existing websites if a library wanted to use strict types.

This is actually a huge part of my point. No matter how strict we are on types within the framework itself it has almost no impact on external developers using the framework. Loose typing still works and type coercion happens automatically as they interact with framework code.
Because of this - there's nothing to defend on loose typing here. All external usage is loosely typed.

I'm pretty sure strict types only apply to calls made from that file to functions within the same file. It does not affect calls from outside of the file to those functions.

Yes.

Strict typing applies to function calls made from within the file with strict typing enabled, not to the functions declared within that file. If a file without strict typing enabled makes a call to a function that was defined in a file with strict typing, the caller's preference (coercive typing) will be respected, and the value will be coerced.
https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict

So then, from an external developers point of view is this the only place we are forcing strict typing on them?

@lonnieezell I don't understand your question well.
However, there are developers who have strict mode enabled for all files. Some developers do not like loose typing.
It seems impossible to satisfy developers who prefer loose typing and those who don't at the same time.

@lonnieezell I don't understand your question well.

I apologize. And I probably didn't phrase it well, but to me the hasChanged method is the only place in the framework that currently requires me, as a developer to care about strict typing. I understand you're trying to fix that by providing ways to cast in a different area and then juggle the types between all of the reads and writes. But it seems like a lot of extra code and maintenance for something that can be resolved by removing an equals sign in that method and dealing with the loose typing there. In my mind that provides what users are expecting to have happen and does so in a much simpler way with less code duplication.
The only reason I'm harping on this is because of what you original said this feature was trying to fix:

The current Entity has problems.

An Entity is a PHP object, but it holds data retrieved from a DB (except for dates) and does not have the correct type of values in PHP. So there is a bug https://github.com/codeigniter4/CodeIgniter4/issues/5905 where hasChange() returns the wrong value.
Entity has too much knowledge about DB; since Entity is a PHP representation of a DB record, knowledge of DB is essentially unnecessary.

First, I'll say it again, the Entity has no dependency or knowledge of the database. The data provided to it could be from a database, and often will be, but could also be used completely independent of the database.
Second, I believe the loose checking fixes all related issues the hasChanged bug that's cropped up a couple of times.
I really don't see this feature as a useful addition, but it does seem to be one that doesn't really solve the hasChanged bug, if just punts potential issues into a new location and will lead to questions about when to use casting from the model and when from the entity.
But I've said my piece (way more than I originally intended) and will leave it to the rest of the team to decide which route they'd like us to go.

I have to say that @lonnieezell's arguments spoke to me and a loose check in Entity can defend itself. I'd not be against it. Still, not sure what would be the best choice, since I never really used the hasChanged feature... would lose type checking work for most cases?
However, when it comes to the idea of implementing casting right in the Model, I would say that this is something I would like to see happen. As something optional - I really see an added value here. I am not afraid to confuse users with options. I think this can be easily explained - if you only need casting, then you can use Model, but if we want something more, something custom, or something that doesn't come from the DB - then Entity is the way to go. But... I would like to find a way to reuse the casting functionality (Cast classes) we already have in the Entity. Is that possible?
In general, I do believe that casting in the Model would be useful. And I don't associate it with solving problems in the Entity class.

Good conversation here, I'm glad everyone is able to share their opinions. I want to highlight a few things that have fallen off:
Other frameworks
Pretty much everyone these days uses an ORM - and not even their own, either Eloquent or Doctrine. Cake is the only other one I am aware of that's worked hard on spinning their own, and they went with a hybrid solution.
Full disclosure: I don't like ORMs. I made my own foray into CodeIgniter-ORMs with Tatter\Relations and contributed to CI4ORM a bit and found the limitations very quickly. I wasn't part of the original discussion around our data source architecture, but I'm happy with the decision not to offer a native ORM.
Architecture
Which brings me to the next point: what is our offered architecture? It seems to me that this would guide a lot of the discussion, instead of forging a path and then drawing up the plans later. Our User Guide has a few references to the Repository Pattern, though we don't strictly follow that through.
I see what we have currently to be tools suggesting a Repository-like pattern, with BaseModel class being the "repository interface" and Model being "repository using SQL", and Entities being the data objects - but there's a lot of bleeding of concerns. As is typical of this pattern we find the need for a data mapper and we are scrambling to figure out where to put it because it doesn't properly belong in either the Repository or the Data Object.
Intent
Now do we want to promote this pattern? CI4 has been content to do its own thing, one of the things I love about it. But I think it is important to be able to state in clear language that non-CI4 devs can understand what we are doing, and using existing architectural terms that we've had for 30 years helps promote that. It will also helps us to keep things clean.
NoSQL
Small addendum here: a lot of my pain with CI4's database layer has come from necessarily. I took a side gig on a project using Firebase and spin up a CI4 project for it - and it has been nothing but pain since. At this point I've pretty much written my own entire data access layer using Tatter\Firebase and in-project DDD code... but I am always aware in these discussions how coupled we are to SQL databases which I believe are still dominant but less and less popular with new devs. I don't want us to make too many commitments to the framework (outside of Model) based on SQL assumptions, because it not only decreases our viability but it belies poor SOLID practices.

Indeed, I think that the hasChanged() bug would not cause problems in most cases if it were changed to a loose comparison. However, it does not solve the problem of not knowing the exact type.
Without a strong belief that '1' and 1 should be exactly the same, I think we will have a problem someday.
In the end, if a dev wants loose typing, the current Entity is fine, and if a dev wants strict typing, the current Entity has many problems.

I don't understand the following errors by Psalm, so I suppress them.
Error: system/DataConverter/Cast/ArrayCast.php:22:45: MissingTemplateParam: CodeIgniter\DataConverter\Cast\ArrayCast has missing template params when extending CodeIgniter\DataConverter\Cast\CastInterface, expecting 3 (see https://psalm.dev/182)
Error: system/DataConverter/Cast/CSVCast.php:30:29: NoValue: All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
Error: system/DataConverter/Cast/CSVCast.php:39:29: NoValue: All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
Error: system/DataConverter/Cast/CastInterface.php:24:15: UndefinedDocblockClass: Docblock-defined class, interface or enum named CodeIgniter\DataConverter\Cast\TDbColumn does not exist (see https://psalm.dev/200)
Error: system/DataConverter/Cast/CastInterface.php:34:15: UndefinedDocblockClass: Docblock-defined class, interface or enum named CodeIgniter\DataConverter\Cast\TPhpValue does not exist (see https://psalm.dev/200)
Error: system/DataConverter/Cast/DatetimeCast.php:37:48: NoValue: All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
Error: system/DataConverter/Cast/JsonCast.php:39:35: NoValue: All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
Error: system/DataConverter/Cast/URICast.php:32:24: NoValue: All possible types for this argument were invalidated - This may be dead code (see https://psalm.dev/179)
------------------------------
8 errors found
------------------------------

I am always aware in these discussions how coupled we are to SQL databases which I believe are still dominant but less and less popular with new devs. I don't want us to make too many commitments to the framework (outside of Model) based on SQL assumptions, because it not only decreases our viability but it belies poor SOLID practices.

CodeIgniter does not support any non-SQL databases. So it is nearly impossible to improve it.
In order to improve it, I think we need to set up the environment so that we can write test code for non-SQL databases.

CodeIgniter does not support any non-SQL databases. So it is nearly impossible to improve it.
In order to improve it, I think we need to set up the environment so that we can write test code for non-SQL databases.

I don't think we ever had a real conversation about this one (or I missed it). But I don't like the idea of the Query Builder to handle NoSQL databases. IMO the differences in working with NoSQL databases are simply too big. We would end up with a totally different API for NoSQL databases. I don't see the point of trying to handle it with the "same class".
If we want to handle NoSQL, then we should create a separate layer that will be fully adapted to handle this type of database and will make it easier to work with them. Trying to do it in the current Query Builder makes no sense in my opinion.

If we want to handle NoSQL, then we should create a separate layer that will be fully adapted to handle this type of database and will make it easier to work with them. Trying to do it in the current Query Builder makes no sense in my opinion.

I would agree with this too. I would even go so far as to say in v5 we remove the BaseModel and simplify back to just the Model. The entire reason that was done originally was making it simpler to extend to NoSQL use cases.

In my understanding, Model is for SQL databases, BaseModel is for all databases including NoSQL.

the idea of the Query Builder to handle NoSQL databases.

I think nobody has the idea.
Probably the idea is BaseModel handles both SQL and NoSQL databases.
That is it is an abstraction.
I don't understand why removing BaseModel makes it easier to handle NoSQL.
Model is tightly coupled to Query Builder, and QB is only for SQL databases.

Yup - I know that's why it was originally abstracted and why we allowed it. However it adds a fair amount of complexity to the database layer for a feature we don't implement.
Whenever I have used NoSQL in the past, I have quickly come to realize the way you use them is a fair bit different than a SQL database. If we were to implement our own it would probably make more sense to have it be standalone layer.

@lonnieezell Thank you! I got your point.
I don't have a strong opinion right now, but my original opinion is similar to that.
However, I don't think the idea of BaseModel is wrong because there are operations common to NoSQL and SQL.

However, I don't think the idea of BaseModel is wrong because there are operations common to NoSQL and SQL.

The only common thing is that we read, write, and delete data. The problem is everything else - how we do it and how we structure the data. Relying on patterns we know from relational databases won't get us very far. Additional methods or additional syntax will be needed.
I could be wrong but I don't know of any framework that has successfully offered a common API to work with these different databases. Even if we managed to do this, to some simplified extent, it's probably not worth the effort and code complexity it will lead to.
For me, the point of using the Model class has always been that it provides an abstraction that can be used regardless of the database being used. In this case, I don't see this portability between NoSQL and RDB. IMO there are enough nuances between different NoSQL databases to justify a separate layer (if it happens).

We left this in flux, but now that I'm not looking at is a fix for the Entity, I think this is a fine feature to have. We should get it merged.

@kenjis Is there a specific problem that prevents us from using the Cast classes that Entity uses?

They are the same in that they are casting, but they are designed differently.
So it is difficult to use Entity Cast classes, and we should not do.
The difference is that Entity casting works at (1)(2)(3)(4), but this PR casting is designed to work at (2)(3) only.
[App Code] --- (1) --> [Entity] --- (2) --> [Database]
[App Code] <-- (4) --- [Entity] <-- (3) --- [Database]

But can't we just add fromDataSource() and toDataSource() to our existing Casting classes? If the code is the same, they can use set() and get() under the hood, and if not, they will provide a custom implementation. We can also add an interface to handle casting methods that will support the database. I'm open also to other ideas.
My point is, that while I really like the idea, I'm not a fan of the redundancy of the code the DataConverter brings.

But can't we just add fromDataSource() and toDataSource() to our existing Casting classes?

We can. set/get and fromDataSource/toDataSource are similar, but different interfaces.
So the existing Casting classes will implements two interfaces, but it is possible.
Then, DataConverter will depend on Entity Casting.
We don't/can't use the both Casting at the same time.
So I don't see much point in combining them into one class.
And I would like to hear @MGatner opinion. See https://github.com/codeigniter4/CodeIgniter4/pull/7995#pullrequestreview-1663217421

I just checked 3 first casting classes: array, boolean, and csv and they look identical to DataConverter casting classes in terms of what they do. I looked some more into the code and I don't get why we can't use the set/get method when we convert data in the Model.
Honestly, I don't really get @MGatner concerns described in the linked review since casting is just casting - it converts between different data types. No matter what the source of data is. If you need something custom from the most common usage, then you have to create your own casting type. Although I suggested before that the casting class should be aware of the source of the data: https://github.com/codeigniter4/CodeIgniter4/pull/8230#discussion_r1401601112
Anyway, I would suggest a different approach. I would make a DataConverter class to use casting classes from the CodeIgniter\Entity\Cast namespace. We could then make changes to the Entity and Model so both would benefit from using the same casting classes. That should prevent any breaking changes and allow us to reuse the code we already have.

My point in the linked review was that Entity is tied unnecessarily to Database. Maybe we want to lean into that, but the Repository pattern is all about being agnostic of the data source. Adding database conversion fields belongs to database-specific classes. This approach, of situating them in a dedicated namespace, isn't a problem but they are clearly SQL database mappings (strings => PHP natives).

[BaseModel NoSQL support is] probably not worth the effort and code complexity it will lead to

I've come to agree with this. My Firebase project now uses completely standalone classes because trying to fit it into BaseModel was a giant pain. I agree with @lonnieezell that v5 should probably revert to a single abstract Model class that is SQL-specific. If we want to have some support for NoSQL sources it could be a separate Collection layer of some kind, but should be very basic (I think every project could benefit from a CRUD interface for data sources).

I just moved the code in ArrayCast, BooleanCast, CSVCast to Entity Cast classes: 5eebc8f827a3e6959f0707328d0bb2c010aadafb
If there is agreement in this way, move the other classes into the cast classes in Entity and remove the DataConverter cast classes.
https://github.com/codeigniter4/CodeIgniter4/blob/5eebc8f827a3e6959f0707328d0bb2c010aadafb/system/Entity/Cast/ArrayCast.php
Looking at the code, it appears possible to make it common since there are similar codes.
But in the end, I think what MGatner is trying to say is that the layers are different.
fromDataSource() and toDataSource() are database (infrastructure) layer knowledge.
get()/set() should be Entity (domain layer) knowledge.
In my opinion, all the cast classes of Entity that we have now are unnecessary in the end.
And if Entity has PHP native data, not raw data from the database,
Entity will be completely independent of the infrastructure layer.

But in the end, I think what MGatner is trying to say is that the layers are different.
fromDataSource() and toDataSource() are database (infrastructure) layer knowledge.
get()/set() should be Entity (domain layer) knowledge.

Yes layer is different, but from the casting classes perspective, there is no difference. It either casts to/set or from/get and it doesn't care what is the source of data. Even more, rn it does not know the source of the data.

In my opinion, all the cast classes of Entity that we have now are unnecessary in the end.
And if Entity has PHP native data, not raw data from the database,
Entity will be completely independent of the infrastructure layer.

From the v4 perspective casting in the entities should not go away. IMO any breaking changes in this area would be probably too big to swallow for the majority of users.
Also, entities are not used exclusively with the database data.

Looking at the ArrayCast it seems the code is identical - except for throwing an exception (not sure if this is a crucial feature).
I would really like to try a different approach - the one I described in my previous comment.
A DataConverter class, that would have the castAs() method and would use CodeIgniter\Entity\Cast classes. This way we could reduce the redundancy of the code from the Entity class and use DataConverter in both cases: Entity and Model.
I know it might not sound ideal, but if we think about backward compatibility and code simplicity it makes sense to me. There may be some downsides to what I'm proposing, so please share your concerns.

No worry. I just think the Entity cast classes we have now are not originally needed.
But I do not intend to discontinue them. We will have to maintain them for a long time.
I've given it a lot of thought, but my concern is that they are different layers after all.
Breaking Changes will happen in the future if we move (copy?) the cast classes under DataConverter.

from the casting classes perspective, there is no difference.

Yes, it is true, but the problem is the casting classes are in the Entity namespace (it is not infrastructure layer).
However, if other members also agree that DataConverter should use the Entity Cast classes, then I do so.

I just think the Entity cast classes we have now are not originally needed.

I see the place for casting in the entities - if my model uses custom queries I still would like to have the possibility to cast data when I use getCustomResultObject(). The model casting would only work with the model's methods.

I've given it a lot of thought, but my concern is that they are different layers after all.

Until we share the same implementation in both places, IMO there is no issue. We can always extend it later (or in v5) to have/support different handlers, although I see no use case for it now.

Yes, it is true, but the problem is the casting classes are in the Entity namespace (it is not infrastructure layer).

Yes, I agree, 100% that the namespace will not be ideal, but it is only a temporary compromise.
Ok, let's wait for the opinions of other members. Maybe they will come up with something totally different 😜

I think this is a fork in the path that are both heading in the right direction, just have different implications for the future. I don't know that we'll be able to "see" where we want this to go that far out (e.g. v5) so I'd lean more towards getting something in now that at least points us in the general direction. @kenjis PR is ready and acceptable, and doesn't lock us out of consolidating the code in another iteration. I'm not opposed to seeing an alternate if @michalsn wants to show what that would look like? I don't want us to over-spend time though.

I also want to call out that @kenjis has introduced some architecture language (or maybe I did before, not sure, no blame) that we haven't necessarily agreed on but should probably be a topic of discussion at some point; it would help these discussions tremendously to have a blueprint.

@michalsn

I see the place for casting in the entities - if my model uses custom queries I still would like to have the possibility to cast data when I use getCustomResultObject(). The model casting would only work with the model's methods.

What do you mean? How will you do?
getCustomResultObject() or fetchObject() does not use Entity casting now.
It calls Entity::injectRawData(), just injects raw data into the Entity.
[App Code] --- set() --> [Entity] --- toRawArray() -----> [Database]
[App Code] <-- get() --- [Entity] <-- injectRawData() --- [Database]

@kenjis What I'm trying to say is that I can create a custom query, which will not use model methods, like: find(), findAll(), or first(). As I understand only with these methods casting in the model will be available.
With my custom query, I can still take advantage of casting with the use of the entity: getCustomResultObject(PostEntity::class). This way the entity will be seeded with the data just like we do it now. I can then define casting rules for my fields and use casted data.

Bottom line is the Entity class has to retain them. For a couple of reasons: First, since it can be used without a model it shouldn't have its functionality moved to the database layer. Second, and by far most importantly, a quick look on Packagist shows that CI4 has been download over 1.6 million times. Even if only 1/2 of those ever became websites, that's a huge amount of sites to break for no reason.

@michalsn @lonnieezell I'm confused and am not sure what we are discussing.

With my custom query, I can still take advantage of casting with the use of the entity: getCustomResultObject(PostEntity::class). This way the entity will be seeded with the data just like we do it now. I can then define casting rules for my fields and use casted data.

It injects raw data into the Entity and no casting occurs.
When you get a value from the Entity, the casting will occurs.
This feature is already implemented in Entity class, and you can use it now and after merging this PR.
I dropped the last commit https://github.com/codeigniter4/CodeIgniter4/commit/5eebc8f827a3e6959f0707328d0bb2c010aadafb
As you all see I do not change Entity anything in this PR.
All functionality in Entity remains as it is.

Sorry, I was probably responding out of thread and a bit late. I was responding to this quote:

I just think the Entity cast classes we have now are not originally needed.

And probably misunderstanding it to mean you didn't think Entity's needed to have casting now that its in the Model. Sorry. I take it back. :)

No problem. My English may have been misunderstood.
I also think the current design of Entity keeping raw data is somewhat reasonable, although there are some problems, such as hasChanged() being unreliable in some cases.
Query Builder/PHP database functions have the feature to return custom objects.
So I think it is probably fastest to have the PHP function generate the Entity object.
In that case, Entity should keep raw data.

I just think the Entity cast classes we have now are not originally needed.

And probably misunderstanding it to mean you didn't think Entity's needed to have casting now that its in the Model.

That's what I thought too, and I was referring to it. In that case, all is well.

I made a draft, that should explain better what I personally expect from the casting feature: #8352

@michalsn Thank you. I got your idea better.
If you can handle DatetimeCast well, I can use the DataCaster.
But I say again and again,
Entity casting works at (1)(4), but DataConverter casting works at (2)(3).
They are different interfaces even if the 90% of implementations are the exactly same.
[App Code] --- (1) --> [Entity] --- (2) --> [Database]
[App Code] <-- (4) --- [Entity] <-- (3) --- [Database]

If you can handle DatetimeCast well, I can use the DataCaster.

Hmm... that will be tricky.
In any case, it was never my intention to force my idea into the framework. Now that I've described in code what I mean, let's hear from others whether they think it would be a good direction or not.

The parameter types or meanings are different:

I'm still confused. Looking at the methods and typings used, both accept and return the same thing, but one uses mixed for types and one is more explicit like we've been converting the code to be. What am I missing?
If that's true, and the code does exactly the same thing but our static analysis tools need to see it differently then maybe this is a case where the static analysis tools aren't right and we make our own call? Duplicating code just to make the SA like it seems crazy.

The crux of it lies in @kenjis's chart. We are talking about crossing two different boundaries, the traversal of which is often handled the same way. Here's another visualization of it helps: https://www.dotnetcurry.com/images/mvc/ASP.NET-MVC-5-Using-a-Simple-Repository-_6AFF/repository-pattern.png
Data comes and goes from userland as a map of scalars - e.g. web forms (all strings) or API submissions (JSON encoding of typed values), and view data back out. Data for SQL databases goes out as a map of scalars, and comes back in as a map of scalars or often just strings. In between these transitions is our code that prefers to work with typed objects using SOLID principles. @kenjis  DateTime is a great example because "employee birthday" will be a bunch of different things across its lifecycle: form input as '5/27/1983', then validated as Time/DateTime, then back to a string for the database as '1983-05-27', same thing back from the database and made into a Time, then displayed to a view as 'May 27, 1983'.
In this case I believe the clarity of the responsibility of these classes is worth more than what we would save by deduplicating code.

The two interfaces work on separate boundaries, as shown in this figure that MGatner linked.

However, at a higher level of abstraction, they can be viewed as a single interface, just casting data.
So if you want to make it a single interface, the concrete classes would be implemented separately. For example, you would create two classes, DatetimeCastForEntity and DatetimeCastForDataSource. That way you can handle both processes in one interface.
However, I think it would be confusing to developers to have processes with different boundaries in the same interface.

In this case I believe the clarity of the responsibility of these classes is worth more than what we would save by deduplicating code.

I agree with this opinion. The reason for having two interfaces is to lower the level of abstraction and make it clearer to developers what they do.

Added DataCaster that can use both Cast interfaces.

In my opinion, this PR is ready to merge. This PR alone does not change anything in behavior, but the next PR #8243 will allow casting in Model.
The cast classes are in Entity and DataCaster, but both are needed because they are used in different purposes (timing) and Entity cast classes are loose, but DataCaster cast classes are strict.
Review when you have time.


Error while creating ibm apic docker container from kitematic

Expected behavior
Actual behavior
(HTTP code 404) unexpected - {"message":"manifest for ibmcom/apiconnect:latest not found"}
Information about the Issue
Steps to reproduce the behavior

...
...

Go to https://hub.docker.com/r/ibmcom/apiconnect/tags/
Observe no latest tags were created for that image
Select a different tag in Kitematic (if one exists)
🎉  enjoy container running.

Ideally you open an issue with the repo owner to let them know how frustrating it is that they don't have a latest image tagged


mbedtls: 2.16.9 -> 2.26.0

Motivation for this change
Progress in the julia packaging (https://github.com/NixOS/nixpkgs/pull/117881) has revealed that nixpkg's version of mbedtls is a few months old. Julia 1.6 now requires >= 2.24.0.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 119838 at ac271763 run on aarch64-linux 1

7 packages marked as broken and skipped:

belle-sip
haxe_3_2
haxe_3_4
liblinphone
lime
linphone
obs-ndi

22 packages built successfully:

bctoolbox
belcard
belr
bzrtp
dislocker
gauche
gaucheBootstrap
haxe (haxe_4_2)
hxcpp (haxePackages.hxcpp)
haxePackages.hxcs
haxePackages.hxjava
haxePackages.hxnodejs_4
hiawatha
mbedtls
mediastreamer
mediastreamer-openh264
msilbc
neko
ortp
privoxy
shadowsocks-libev
trx

Can you leave a comment next to the no auto update comment indicating that it's disabled due to repology listing dev releases as release versions (from 0ee02a9d42b5fe1825b0f7cee7a9986bb4ba975d) - was wondering if there was some structural reason that had been done.
Otherwise, seems reasonable to me.

On my machine (x86-64):
> nix-shell -p nixpkgs-review --run "nixpkgs-review pr 119838"
$ git -c fetch.prune=false fetch --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0 pull/119838/head:refs/nixpkgs-review/1
From https://github.com/NixOS/nixpkgs
 + fe938d5ab5f...ac271763167 refs/pull/119838/head -> refs/nixpkgs-review/1  (forced update)
$ git worktree add /home/skainswo/.cache/nixpkgs-review/pr-119838/nixpkgs 5cacbc77323d3871c2fbdad33f6f216bd65bfdaf
Preparing worktree (detached HEAD 5cacbc77323)
Updating files: 100% (25459/25459), done.
HEAD is now at 5cacbc77323 Merge pull request #119823 from dotlambda/pytest-subprocess-1.1.10
$ nix-env -f /home/skainswo/.cache/nixpkgs-review/pr-119838/nixpkgs -qaP --xml --out-path --show-trace
$ git merge --no-commit ac27176316752d40f61e29f6efbfd9932e384746
Automatic merge went well; stopped before committing as requested
$ nix-env -f /home/skainswo/.cache/nixpkgs-review/pr-119838/nixpkgs -qaP --xml --out-path --show-trace --meta
41 packages updated:
bctoolbox belcard belle-sip belr bzrtp dislocker dolphin-emu dolphin-emu gauche gauche-bootstrap haxe haxe haxe hiawatha hxcpp hxcs hxjava hxnodejs liblinphone lime linphone-desktop lutris lutris polarssl (2.16.9 → 2.26.0) mbedtls (2.16.9 → 2.26.0) mediastreamer2 msilbc msopenh264-unstable neko obs-gstreamer obs-move-transition obs-multi-rtmp obs-ndi obs-studio obs-v4l2sink obs-wlrobs ortp privoxy shadowsocks-libev trx yojimbo

$ nix --experimental-features nix-command build --no-link --keep-going --option build-use-sandbox relaxed -f /home/skainswo/.cache/nixpkgs-review/pr-119838/build.nix
error: builder for '/nix/store/m7hb15a97j5mzlfsl5bqj3vwic5fnyl3-InstallNDISDK_v4_Linux.tar.gz.drv' failed with exit code 1;
       last 10 log lines:
       >
       >   https://ndi.tv/sdk/
       >
       > Once you have downloaded the file, please use the following command and
       > re-run the installation:
       >
       >   $ nix-prefetch-url file://$PWD/InstallNDISDK_v4_Linux.tar.gz
       >
       > ***
       >
       For full logs, run 'nix log /nix/store/m7hb15a97j5mzlfsl5bqj3vwic5fnyl3-InstallNDISDK_v4_Linux.tar.gz.drv'.
error: 1 dependencies of derivation '/nix/store/m8pmsh9l5w1ah8mv58lbcr8dvda27sbx-ndi-4.drv' failed to build
error: builder for '/nix/store/rzzsfw4b3aq2i2vvycfxk072vwdps8md-scout-runtime-0.20201203.1.tar.gz.drv' failed with exit code 1;
       last 7 log lines:
       >
       > trying https://repo.steampowered.com/steamrt-images-scout/snapshots/0.20201203.1/steam-runtime.tar.xz
       > curl: Can't open
       > curl: '/nix/store/0yd9cm656yl63q2wg76il267l9gcnac6-scout-runtime-0.20201203.1.t
       > curl: ar.gz'!
       > curl: (23) Failed writing received data to disk/application
       > error: cannot download scout-runtime-0.20201203.1.tar.gz from any mirror
       For full logs, run 'nix log /nix/store/rzzsfw4b3aq2i2vvycfxk072vwdps8md-scout-runtime-0.20201203.1.tar.gz.drv'.
error: 1 dependencies of derivation '/nix/store/i13s2dq882k0c02ibxlys2l2wch1ibj3-steam-runtime-0.20201203.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/2269pg5x87hizl7qllchajy1r7s8w8hp-steam-runtime-wrapped.drv' failed to build
error: 1 dependencies of derivation '/nix/store/g6s53zsrdlia2q4np3chb3iycmv6a7x4-steam-usr-multi.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vvwm6yzwjbp358msvzxy8947lhhqar9y-obs-ndi-4.9.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/p33my824kcshkqmqd1dj19dmn8gxx4hw-steam-fhs.drv' failed to build
error: 1 dependencies of derivation '/nix/store/mflgg9vld7hk7zva7zvmvvxd8vssyk3h-steam.drv' failed to build
error: 1 dependencies of derivation '/nix/store/4ydlpqzajcm2jkhil6sscj70ab95804h-steam.drv' failed to build
error: 1 dependencies of derivation '/nix/store/n91mi1vl30m7h6kkl2s9hr47pi7657mz-lutris-usr-target.drv' failed to build
error: 1 dependencies of derivation '/nix/store/v1jaa0hagapcavjxd336913hyd20f7sy-lutris-fhs.drv' failed to build
error: 1 dependencies of derivation '/nix/store/0xf095vw99bqkd4mm3v8nd9z31yyzyxq-lutris.drv' failed to build
error: 1 dependencies of derivation '/nix/store/j3gq6plkvhh8vncdlm066fc2fzi43wmm-lutris.drv' failed to build
error: 2 dependencies of derivation '/nix/store/kjbydgl6kws71lyn24m8ajdw1jn21bgs-env.drv' failed to build

Link to currently reviewing PR:
https://github.com/NixOS/nixpkgs/pull/119838

2 packages failed to build:
lutris obs-ndi

38 packages built:
bctoolbox belcard belle-sip belr bzrtp dislocker dolphinEmu dolphinEmuMaster gauche gaucheBootstrap haxe haxePackages.hxcpp haxePackages.hxcs haxePackages.hxjava haxePackages.hxnodejs_4 haxe_3_2 haxe_3_4 hiawatha liblinphone lime linphone lutris-free mbedtls mediastreamer mediastreamer-openh264 msilbc neko obs-gstreamer obs-move-transition obs-multi-rtmp obs-studio obs-v4l2sink obs-wlrobs ortp privoxy shadowsocks-libev trx yojimbo

error: build log of '/nix/store/j3gq6plkvhh8vncdlm066fc2fzi43wmm-lutris.drv' is not available
error: build log of '/nix/store/vvwm6yzwjbp358msvzxy8947lhhqar9y-obs-ndi-4.9.1.drv' is not available
$ nix-shell /home/skainswo/.cache/nixpkgs-review/pr-119838/shell.nix

[nix-shell:~/.cache/nixpkgs-review/pr-119838]$

Looks like the obs-ndi failure is due to it requiring a license to be accepted or something. lutris seems to be due to a network error.

Can you leave a comment next to the no auto update comment indicating that it's disabled due to repology listing dev releases as release versions (from 0ee02a9) - was wondering if there was some structural reason that had been done.
Otherwise, seems reasonable to me.

Should be resolved in https://github.com/NixOS/nixpkgs/pull/119838/commits/ffe009394a8537c18daffebde3d6ff282b4d196a!

This broke compilation on x86_64-darwin for me.
building
build flags: -j12 -l12
[1/608] Building C object CMakeFiles/mbedtls_test.dir/tests/src/drivers/size.c.o.oKt.c.o
/nix/store/2pb1r2zgw6yiabv4v3d4j66d3vwgdd5q-clang-wrapper-7.1.0/bin/clang  -I../tests/include -I../include -I../library -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wimplicit-fallthrough -Wshadow -Wvla -Wformat=2 -Wno-format-nonliteral -Werror -O2 -MD -MT CMakeFiles/mbedtls_test.dir/tests/src/drivers/size.c.o -MF CMakeFiles/bmedtls_test.dir/tests/src/drivers/size.c.o.d -o CMakeFiles/mbedtls_test.dir/tests/src/drivers/size.c.o -c ../tests/src/drivers/size.c
error: unknown warning option '-Werror=format-truncation' [-Werror,-Wunknown-warning-option]
…
ninja: build stopped: subcommand failed.
builder for '/nix/store/86bic0lk75x13sknvbnm9j8935rks12g-mbedtls-2.26.0.drv' failed with exit code 1

I think this is a clang/gcc flag inconsistency issue. I think I know the fix but I'm stuck unable to install nix on my macbook at the moment (https://discourse.nixos.org/t/installation-issues-on-macos-catalina/12560).

@OPNA2608 Ok, I created https://github.com/NixOS/nixpkgs/pull/119923 to resolve the build on x86_64-darwin.
@rmcgibbo Is there any way that we could get darwin/macOS builds on the nixpkgs-review bot in order to mitigate these kinds of issues in the future? I understand macOS machines are not as easy to come by as Linux ones on the cloud, but maybe we could pool resources from community somehow? Or just run a macOS VM inside a linux host? Anyhow, I'd be willing to pitch in to make it happen!

@samuela: This is a great idea, but it's not trivial to pull off. I can prototype a bit on some old / under-powered mac hardware that I have in my closet, but we should discuss better options.


Feat/turnpy

This pull request includes significant changes to the project, focusing on removing the dependency on the JavaScript Turndown library by porting its functionality to Python. Additionally, there are updates to the documentation and build scripts to reflect this change.
Key changes include:
Removal of JavaScript Turndown Dependency:

assets/convert.js: Removed the JavaScript Turndown script as it is no longer needed.
package.json: Removed the Turndown dependency from the package file.

Introduction of Python Turndown Port:

src/filters/converter.py: Updated the convert function to use the new Python MarkdownConverter instead of the JavaScript Turndown script.
src/turndown/: Added a new directory containing the ported Turndown library in Python, including files like README.md, __init__.py, collapse_whitespace.py, and commonmark_rules.py. [1] [2] [3] [4]

Documentation Updates:

README.md: Updated the documentation to reflect the removal of the Turndown package installation step and added a new section explaining the HTML to Markdown conversion using the ported Python version. [1] [2] [3]

Build Script Updates:

.github/workflows/ci.yml: Updated the mypy command to exclude the new src/turndown/turndown.py file.
format.sh: Added a new build script to format the codebase using isort, black, and other tools.

Summary by Sourcery
Port the Turndown library from JavaScript to Python.
New Features:

Introduce a Python port of the Turndown library for HTML to Markdown conversion.

Tests:

Update type checking to exclude the new Turndown module.

This pull request includes significant changes to remove the dependency on the Turndown JavaScript library by porting its functionality to Python, along with updates to documentation and configuration files.
Removal of Turndown JavaScript Dependency:

assets/convert.js: Removed the JavaScript file that used Turndown for HTML to Markdown conversion.
package.json: Removed the turndown dependency from the package file.
src/filters/converter.py: Replaced the Node.js script call with the new Python MarkdownConverter for HTML to Markdown conversion.

Addition of Python Turndown Implementation:

src/turndown/README.md: Added documentation for the new Python port of the Turndown library.
src/turndown/__init__.py: Added the initialization file for the new Python Turndown module.
src/turndown/collapse_whitespace.py: Added the collapse_whitespace function adapted from the original JavaScript library.
src/turndown/commonmark_rules.py: Added commonmark rules for the Python Turndown implementation.

Documentation and Configuration Updates:

README.md: Updated documentation to reflect the new Python Turndown implementation and removed the installation instructions for the JavaScript Turndown package. [1] [2] [3]
.github/workflows/ci.yml: Updated the mypy command to exclude the new Python Turndown files.
format.sh: Added a new script for code formatting and linting, including mypy checks.


Switch to using ConcurrentHashMap

Fixes #1025

I think it was because of order of entry. Linked hash map gives me that, concurrent does not

I can't imagine this is a performance hotspot? We'd want to be really sure that there is unforeseen impact.

@spencergibb got it, I can see why that is important.  I will close this as well as the issue.


@DataProvider with return type as a Iterator<Object[]>

TestNG Version

TestNG version 7.4.0

Expected behavior
Some message should be display so end user can usderstand what is the problem
Actual behavior
I get the blank output
Is the issue reproductible on runner?
-[]TestNG
Test case sample

I try to execute the simple test case which call dataProvider and this dataProvider has return type as Iterator<Object[]>,i know this return type is not accept by @DataProvider method but after excute the below programm i get the blank output nothing is display in colsole,i accept at least message like the dataProvider is not exsist,please refer below program.
      public class Practice {

     @Test(dataProvider="NotWorking")
     public void testCase(Object[] obj)
      {
         System.out.println(obj[0]);
         System.out.println(obj[1]);
      }

@DataProvider(name="NotWorking")
public Iterator<Object[]> dataProvider2()
{
    List<Object[]> obj =new ArrayList<Object[]>();
    Object[] obj1=new Object[2];
    obj1[0]=new String("First_Object_First_value");
    obj1[1]=new String("First_Object_Second_value");
    Object[] obj2=new Object[2];
    obj2[0]=new String("Second_Object_First_value");
    obj1[1]=new String("Second_Object_Second_value");
    Iterator<Object[]> itr = obj.iterator();
    return itr;
       }
   }

i get the below output for above code,
[RemoteTestNG] detected TestNG version 7.4.0
===============================================
Default test
Tests run: 1, Failures: 0, Skips: 0

My  udersatnding is wrong

@ankushpwar35 Did you solved your issue? How?

Actually I miss to add one line of code that’s why my test method doesn’t
get any data and if test method does not get data then testng will not
execute this test method
So now I know my mistake and this not a bug so I close this
But testng at least provide message like this test method does not get any
data so it was not execute
Thank you
Best Regards
Ankush pawar
On Fri, 28 May 2021 at 3:20 PM, Julien Herr @.***>
wrote:

@ankushpwar35 https://github.com/ankushpwar35 Did you solved your
issue? How?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cbeust/testng/issues/2563#issuecomment-850298084, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AUH4OIFXOBTATKETXPKYL7DTP5ROBANCNFSM45UO3Z2A
.

But testng at least provide message like this test method does not get any data so it was not execute

That's an excellent idea!

So I need to rise this bug or you take care of this
Thank you
On Fri, 28 May 2021 at 3:37 PM, Julien Herr @.***>
wrote:

But testng at least provide message like this test method does not get any
data so it was not execute
That's an excellent idea!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cbeust/testng/issues/2563#issuecomment-850308769, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AUH4OIGKJHIWNMRPS4KGVKLTP5TPVANCNFSM45UO3Z2A
.

I've just updated the current issue :)

Awesome, thanks!
On Fri, 28 May 2021 at 3:41 PM, Julien Herr @.***>
wrote:

I've just updated the current issue :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cbeust/testng/issues/2563#issuecomment-850310949, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AUH4OIFHHRQH2OASNYKGGWLTP5T5XANCNFSM45UO3Z2A
.

In version 7.3.0 the Test run would be displayed as:
[RemoteTestNG] detected TestNG version 7.3.0
Default test
Tests run: 0, Failures: 0, Skips: 0

In 7.4.0 in TextReporter.logResults, the count is derived from context.getAllTestMethods(). But whereas in 7.3.0 it was from TestListenerAdapter.m_allTestMethods.

@juherr - Just to be clear on the expectations of this issue. We need to warn a user when

a data provider either returns an Iterator on an empty collection or
when a data provider returns an empty 2D array right ?

a data provider either returns an Iterator on an empty collection

This case

when a data provider returns an empty 2D array right

This case is a different warning: when you set a data provider on a test method that has no params (except the ones injected by TestNG itself)

@juherr

a data provider either returns an Iterator on an empty collection or

We have a proper warning message for this, but its the logger that is goofing up things for us.
Our customised logger by default sets the log levels for every logger instance to WARN (3). And we are logging the problem at an INFO level.
https://github.com/cbeust/testng/blob/54329910b9b729b836620aafe926e58cbc4a7dc7/testng-core/src/main/java/org/testng/internal/Parameters.java#L803-L809
So we should be doing a few things here.

Consider implementing https://github.com/cbeust/testng/issues/2646 so that a user can basically work with configuring the logger in a much more easier way. TestNG logging has the following problems:

Its custom written
Its confined to ONLY console logging
Lacks documentation (I think we can fix this)

As a temporary fix for this problem, maybe change the logging level from INFO to WARN for the above code in question.

I am going to raise a PR which implements (2) and a separate PR which addresses (1)


Silence unreachable code warning in MSVC (/W4)

Disable level 4 warning C4702 on MSVC. Since the comments indicate, that the unreachable return 0 silences some other compiler warning I think it is best to simply ignore the MSVC warning.

Hi, have you considered using BOOST_UNREACHABLE_RETURN ? (see there) If not, would you please give a try?

I did try BOOST_UNREACHABLE_RETURN and it works for Release builds only. It seems that MSVC Debug builds require these return statements they warn about in Release builds.
I've tested VS2017 (15.2) with Boost 1.64 which does not trigger a warning in execution_monitor.ipp as I intended to fix. But it triggers the same warning in a different spot, util/named_params.hpp:138, which also can be fixed using BOOST_UNREACHABLE_RETURN only in Release builds. Debug builds cause level 1 compiler warning C4716, which is by default treated as a build error.
I've also tested VS2015 (14.x) with Boost 1.63, which led to this PR and, if I remember correctly (I don't have that computer available at the moment), produced the exact same problems as described above. The macro works in Release builds only and causes actual compile errors in Debug.
In Release this macro works fine and is definitely a superior solution to my pragma push/pop PR.

What about this: provide me with the commit, and I'll try to run it on other platforms. If there is something wrong with the macro, then I'll report to the boost ML.

You mean the commit using the macro? Sure. Should I just update the one I fixed in the initial PR or should I also take care of the ones in named_params.hpp?

I've added both changes in different commits. so you can separate them if necessary.
The code is tested and compiles flawlessly in MSVC 2017 at /W4 in Release builds. Debug builds fail as described before.

I've also tested with MVSC 2015 now. The behaviour is the same as in 2017. Release build is fine, but Debug build fails.

On branch topic/PR114-unreachable-code-warning-MSVC, tests running

Perhaps this never got merged.  Is it the same issue as #180 ?

Yes, the PR as proposed causes build issues and I never got the time to rework it.

I am not sure why you were seeing warnings, I believe the BOOST_UNREACHABLE_RETURN in execution_monitor.ipp is legit, but the ones in named_params.hpp are not. I am keeping the one in execution_monitor.ipp to finally close this PR.

Merged to master


test: use the same process for the test runner and test files

Instead of creating a subprocess to execute each test file, they are directly required into the main test runner. This allows us to use node:test to identify each test and create a single report at the end of execution.

This doesn't really work easily (CI is lying and incorrectly passing everything). Given enough time it could probably be made to work, but I don't think I have the mental capacity to push it through outside the fixit.

I'm not sure if it helps you, but I believe Astro is running node:test in a single process. Maybe they have something you could use quickly without too much work.


fixed WOPISERVER_INSECURE in entrypoint skript for wopiserver

Description
Currently setting WOPISERVER_INSECURE doesn't work. You will only see a line like
ocis_wopi-wopiserver-1  | /entrypoint-override.sh: 9: [: true: unexpected operator

in the log file. The reason is that bash script ain't no sh skripts:
docker-compose exec wopiserver bash
root@565a743c8ff2:/app# if [ "$WOPISERVER_INSECURE" == "true" ]; then echo test; fi
test
root@565a743c8ff2:/app# exit
docker-compose exec wopiserver sh
# if [ "$WOPISERVER_INSECURE" == "true" ]; then echo test; fi
sh: 1: [: true: unexpected operator
#

This PR fixes the issue by changing the execution shell of the skript from sh to bash
Related Issue

none

Motivation and Context
Bugfix
How Has This Been Tested?
Tested locally by setting WOPISERVER_INSECURE to true and checking if sslverify in /etc/wopi/wopiserver.conf becomes false.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[ ] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

@d7oc after merging master into your PR and trying to run it, I get:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown

@d7oc after merging master into your PR and trying to run it, I get:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown

Interesting. I tested this here, there was no such message. I will try again. Maybe there were some changes in master in the image which break this.

I don't get the error message here. Anything special you have configured? Maybe a different wopiserver tag?
> docker run -d cs3org/wopiserver:v10.1.0
69e9b768eb1966081792843f4c8ffa117ff95527e0bf77f51705b83439e0b80c
docker exec -it 69e9b768eb1966081792843f4c8ffa117ff95527e0bf77f51705b83439e0b80c bash
root@69e9b768eb19:/app#

Summarising the result of the research so far here:
Main problem is that the wopiserver has two base images, see linked issue above. The error I've written here only pops up with the arm64 image at all. The amd64 image doesn't even have the issue:
docker run -it --entrypoint /bin/sh --platform linux/arm64 cs3org/wopiserver:v10.1.0
# if [ "$WOPISERVER_INSECURE" == "true" ]; then echo test; fi
/bin/sh: 1: [: unexpected operator
root@d7-ubuntu-4gb-nbg1-2:~# docker run -it --platform linux/amd64 --entrypoint /bin/sh cs3org/wopiserver:v10.1.0
/app # if [ "$WOPISERVER_INSECURE" == "true" ]; then echo test; fi
---

This is because sh leads to different execution environments:
docker run -it --entrypoint /bin/sh --platform linux/arm64 cs3org/wopiserver:v10.1.0
# ls -la /proc/$$/exe
lrwxrwxrwx 1 root root 0 Aug 25 12:18 /proc/1/exe -> /bin/dash
---
root@d7-ubuntu-4gb-nbg1-2:~# docker run -it --platform linux/amd64 --entrypoint /bin/sh cs3org/wopiserver:v10.1.0
/app # ls -la /proc/$$/exe
lrwxrwxrwx    1 root     root             0 Aug 25 12:16 /proc/1/exe -> /bin/busybox

So the sh script is executed by dash on arm64.

Changed approach with https://github.com/owncloud/ocis/pull/7084/commits/004ac82f304b959119f2486f71f1b3dfda0b69a6. Made the script compatible with dash and busybox.


Switch DataCollectionViewModel to be @HiltViewModel

This should allow the DataCollectionViewModel to be injected and allow us to inject the SavedStateHandle.

/gcbrun

/gcbrun


Add wrappers for some time-related syscalls

gettimeofday, ~clock_gettime~, ~clock_settime~, ~clock_getres~, nanosleep and clock_nanosleep seem to be supported by various *nixes (at least Linux and FreeBSD), but bindings are not included in this crate.
I'd be happy to open a PR adding these bindings.

Check again.  https://github.com/nix-rust/nix/pull/1281 just added some of those.

Darn. I must have searched issues and not pull requests. Regardless, some are still not implemented (the original issue has been edited).

Why would you ever use gettimeofday in new code, instead of clock_gettime?  And why would you ever need nanosleep instead of thread::sleep?

My use case is rather niche - I'm instrumenting syscalls, which is quite possibly the only reason to use the first two functions in new code. clock_nanosleep could use a clock other than CLOCK_MONATONIC, which is what std frequently uses (std uses plain nanosleep for thread::sleep).
Do you think it would be worthwhile to at least implement clock_nanosleep?

Do you think it would be worthwhile to at least implement clock_nanosleep?

Yep.


Bump version

Getting problem when doing pod trunk push:
 -> LFLoginController (0.2.5)
    - ERROR | [iOS] xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information.
    - NOTE  | [iOS] xcodebuild:  <module-includes>:1:9: note: in file included from <module-includes>:1:
    - NOTE  | [iOS] xcodebuild:  /Users/lucasfarah/Library/Developer/Xcode/DerivedData/App-ezarzdifdsrebbdcyxtwqsyeupje/Build/Products/Release-iphonesimulator/LFLoginController/LFLoginController.framework/Headers/LFLoginController-umbrella.h:3:9: note: in file included from /Users/lucasfarah/Library/Developer/Xcode/DerivedData/App-ezarzdifdsrebbdcyxtwqsyeupje/Build/Products/Release-iphonesimulator/LFLoginController/LFLoginController.framework/Headers/LFLoginController-umbrella.h:3:
    - ERROR | [iOS] xcodebuild:  /Users/lucasfarah/Library/Developer/Xcode/DerivedData/App-ezarzdifdsrebbdcyxtwqsyeupje/Build/Products/Release-iphonesimulator/LFLoginController/LFLoginController.framework/Headers/LFLoginController-Bridging-Header.h:12:9: error: 'OnePasswordExtension.h' file not found
    - NOTE  | [iOS] xcodebuild:  <unknown>:0: error: could not build Objective-C module 'LFLoginController'

@JARMourato, I think this happened after your commit. Can you take a look?

@lfarah Hey, have you fixed this ? :)

@JARMourato Some file was broken in CocoaPods and I had to create another project and manually copy and paste the files, so we lost the Carthage support for now


[HOTFIX][gh-pages] Fix Maven web link for INTERPRETER type pkg

What is this PR for?
In current https://zeppelin.apache.org/helium_packages.html page, INTERPRETER type package web link is wrong. It should point Maven web link not npm. So I fixed it.
What type of PR is it?
Hot Fix
What is the Jira issue?
N/A
How should this be tested?
Run the website(gh-pages) locally as described in here and click any INTERPRETER type of package name.
Screenshots (if appropriate)

Before

After

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

@felixcheung Thanks!
CI failure is irrelevant with gh-pages change. Merge into gh-pages as a hotfix if there are no more comments on this.


Allow FileTrigger to accept the same file twice

Closes #4925
We decided to move this component away from forms, hence the removal of the name prop. As a future follow-up, we'd like to create a separate file input component that works specifically for forms.
With this implementation, we would expect that a user be able to submit the same file twice and that if the user clicked canceled on the file picker that the value of the file input would be cleared.
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
In the stories, you should be able to submit the same file twice and onSelect should be fired twice.
Might also want to sweep through DropZone/FileTrigger docs to make sure everything looks good.
🧢 Your Project:
RSP

Since we want to move this out of Forms, what category should this go under in the docs? Maybe drag and drop?

Since we want to move this out of Forms, what category should this go under in the docs? Maybe drag and drop?

DnD is a bit weird, it's associated, but maybe a better name for that section would then be something that joins them?
Asset Management
Assets
Asset Choosers
Asset Pickers
(replace word 'asset' with 'file'?)
otherwise... Buttons?

Would rather not have a whole new category for just one component. I'd say either Buttons or leave it in Forms anyway.

Looks good last question, is it weird to have FileTrigger before ToggleButton? I know it's alphabetical, but feels weird all the same in a section called buttons I don't expect a change for that in this pr

yeah i agree it does feel a bit strange. maybe we can reconsider where to put it in a follow-up


tendermint v0.14.1

Cutting a small point release to get the following version bump for the KMS:

Update prost-amino/prost-amino-derive to v0.6 (#367)

@liamsi can you publish? I don't have access any more...

Sure thing 👍  I think you are listed as an owner though (with the tony-iqlusion handle).

Aha, so I am 😅

https://crates.io/crates/tendermint/0.14.1

Thank you!


Update handling of output from group_and_sort function.

A small update to go along with https://github.com/sorgerlab/indra/pull/1214

Found some valid test errors, I will have to fix later.

Found some valid test errors, I will have to fix later.

As far as I know, it should be good now. :)

As far as I know, it should be good now. :)

Hi, can you resolve rebase conflicts and update to correct usage of make_string_from_relation_key in model_tests?

Hi, can you resolve rebase conflicts and update to correct usage of make_string_from_relation_key in model_tests?

There that ought to work. Hopefully the tests pass. Sorry for the delay!

There that ought to work. Hopefully the tests pass. Sorry for the delay!

Thank you! I will fix that one failing test

Thank you! I will fix that one failing test


Migrate docker provider traefik to engine-api

The docker provider now uses docker/engine-api and vdemeester/docker-events instead of fsouza-dockerclient 🐳.
Compared to before, this filters the events by container (the daemon will only send container events), thus should receive a little less events.

[ ] Do some more tests and benchmarks on this 🐙 (with -race).

/cc @emilevauge for how to run the benchmarks :angel:
🐸
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

@vdemeester, on benchmarks, I think it would be a good idea to launch/destroy a lot of containers at the same time, using a -race compiled version of traefik. Seems good ?

@emilevauge yep :+1:

@vdemeester can I merge this one ? Needs a rebase ;)

@emilevauge yes and will do quickly :dancer:

nice! (moving to engine-api)

@emilevauge rebased and update, should be ready to merge :angel:

No more github.com/fsouza/go-dockerclient!
Thanks @vdemeester !
LGTM

:tada:

:dancer: :dancer:


[tool_crash] FileSystemException: Failed to decode data using encoding 'utf-8', null

Command
flutter --no-color pub get

Steps to Reproduce

...
...
...

Logs
FileSystemException: Failed to decode data using encoding 'utf-8', null
#0      _File._tryDecode (dart:io/file_impl.dart:564:7)
#1      _File.readAsStringSync (dart:io/file_impl.dart:584:7)
#2      ForwardingFile.readAsStringSync (package:file/src/forwarding/forwarding_file.dart:96:16)
#3      ErrorHandlingFile.readAsStringSync.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:221:22)
#4      _runSync (package:flutter_tools/src/base/error_handling_io.dart:573:14)
#5      ErrorHandlingFile.readAsStringSync (package:flutter_tools/src/base/error_handling_io.dart:220:12)
#6      AndroidPlugin._getSupportedEmbeddings (package:flutter_tools/src/platform_plugins.dart:137:53)
#7      AndroidPlugin._supportedEmbedings (package:flutter_tools/src/platform_plugins.dart:91:70)
#8      AndroidPlugin.toMap (package:flutter_tools/src/platform_plugins.dart:83:30)
#9      _extractPlatformMaps (package:flutter_tools/src/plugins.dart:606:40)
#10     _writeAndroidPluginRegistrant (package:flutter_tools/src/plugins.dart:622:5)
#11     injectPlugins (package:flutter_tools/src/plugins.dart:1202:11)
<asynchronous suspension>
#12     FlutterProject.ensureReadyForPlatformSpecificTooling (package:flutter_tools/src/project.dart:322:5)
<asynchronous suspension>
#13     PackagesGetCommand.runCommand (package:flutter_tools/src/commands/packages.dart:167:5)
<asynchronous suspension>
#14     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1043:27)
<asynchronous suspension>
#15     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#16     CommandRunner.runCommand (package:args/command_runner.dart:196:13)
<asynchronous suspension>
#17     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:284:9)
<asynchronous suspension>

[✓] Flutter (Channel stable, 2.2.2, on Mac OS X 10.15.7 19H2 darwin-x64, locale zh-Hans-CN)
    • Flutter version 2.2.2 at /Library/flutter
    • Framework revision d79295af24 (3 weeks ago), 2021-06-11 08:56:01 -0700
    • Engine revision 91c9fc8fe0
    • Dart version 2.13.3
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/yangkang/Library/Android/sdk
    • Platform android-S, build-tools 30.0.3
    • ANDROID_HOME = /Users/yangkang/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    ✗ CocoaPods not installed.
        CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/platform-plugins
      To install see https://guides.cocoapods.org/using/getting-started.html#installation for instructions.

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] IntelliJ IDEA Ultimate Edition (version 2020.2.1)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin version 202.8531

[✓] Connected device (2 available)
    • PCHM10 (mobile) • a81b7dc1 • android-arm64  • Android 10 (API 29)
    • Chrome (web)    • chrome   • web-javascript • Google Chrome 85.0.4183.102

! Doctor found issues in 1 category.

Flutter Application Metadata
Type: app
Version: 3.1.0+3
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: stable
Creation framework version: 9f5ff2306bb3e30b2b98eee79cd231b1336f41f4
Plugins
path_provider-1.6.28
path_provider_linux-0.0.1+2
path_provider_macos-0.0.4+8
path_provider_windows-0.0.5
share-0.6.4+5
shared_preferences-0.5.12+4
shared_preferences_linux-0.0.2+4
shared_preferences_macos-0.0.1+11
shared_preferences_web-0.1.2+7
shared_preferences_windows-0.0.2+3
sqflite-1.3.2+4
url_launcher-5.7.10
url_launcher_linux-0.0.1+4
url_launcher_macos-0.0.1+9
url_launcher_web-0.1.5+3
url_launcher_windows-0.0.1+3
webview_flutter-0.3.24

Closing this as duplicate of https://github.com/flutter/flutter/issues/65021


Add textured background

Closes #101

bors r=alteous

Please keep in mind that we are wasting fillrate here. The background texture should be drawn between the opaque and the transparent passes, using depth test to avoid touching pixels already drawn.

@kvark got it, will fix soon


All labs disabled

It looks like all of the labs are disabled.  Why?

Hi @LarryReed99 ,
Azure DevOps Server Labs Virtual Environments are no more available. You need to download VM if required.
Thanks


@page is formatted with extra spaces like "@     page"

@page is formatted with extra spaces like "@     page"
while trying to beautify the following code the
img {
max-width: 100%!important;
}@page {
margin: .5cm;
}
was formatted as
img {
max-width: 100%!important;
}@     page {
margin: .5cm;
}

Seems similar to issue 35
https://github.com/senchalabs/cssbeautify/issues/35


Lack of consistency when decoding optional lists.

Hi, I've noticed that in some cases a decoder may not produce the same result:
import ru.tinkoff.phobos.decoding.*

case class Foo(i: Int)                  derives ElementDecoder
case class Bar(foo: List[Foo] = Nil)    derives ElementDecoder
case class Qux(bar: Option[Bar] = None) derives ElementDecoder

println(XmlDecoder.fromElementDecoder[Qux]("qux").decode("<qux><bar></bar></qux>"))
println(XmlDecoder.fromElementDecoder[Qux]("qux").decode("<qux><bar/></qux>"))
println(XmlDecoder.fromElementDecoder[Bar]("bar").decode("<bar></bar>"))
println(XmlDecoder.fromElementDecoder[Bar]("bar").decode("<bar/>"))

outputs
Right(Qux(Some(Bar(List())))) // <qux><bar></bar></qux>
Right(Qux(None))              // <qux><bar/></qux>
Right(Bar(List()))            // <bar></bar>
Right(Bar(List()))            // <bar/>

Is there any reason why a decoder outputs different result depending on if the value is optional or not? I would have expected "<qux><bar/></qux>" to be decoded like "<qux><bar></bar></qux>". Is there anything I can do at the decoder level to make this behavior consistent? I am using 15.1.

I've looked at the code, and this is feels odd to me:
implicit def optionDecoder[A](implicit decoder: ElementDecoder[A]): ElementDecoder[Option[A]] =
    new ElementDecoder[Option[A]] {
      def decodeAsElement(c: Cursor, localName: String, namespaceUri: Option[String]): ElementDecoder[Option[A]] = {
        if (c.isStartElement) {
          ElementDecoder.errorIfWrongName[Option[A]](c, localName, namespaceUri).getOrElse {
            // Why does it consider an empty element, or an element without attributes to be a None?
            if (ElementDecoder.isNil(c) || (c.isEmptyElement && c.getAttributeInfo.getAttributeCount == 0)) {
              c.next()
              new ConstDecoder(None)
            } else {
              decoder.map[Option[A]](a => Some(a)).decodeAsElement(c, localName, namespaceUri)
            }
          }
        } else {
          new FailedDecoder[Option[A]](c.error(s"Unexpected event: '${c.getEventType}'"))
        }
      }

Hi!
Thanks for the report. Current behavior of option decoder is strange. I too think that there should be no difference in processing <foo/> and <foo></foo>. We should remove the part of condition that you were pointing at. As far as I remember, there was no particular reason for it.
I am currently on vacation and I have no opportunity to make and publish this change. I'll get to it as soon as I come back to my laptop on September 14th

Thank you very much for your reply, I'll push a PR next week to address this :)

Hi! I'm back home, and now ready to review and publish the fix

Hey @valentiay, here's a PR for this issue: https://github.com/Tinkoff/phobos/pull/227

Hi!
Excuse me for the long absence. Had some personal issues to solve. I hope, I will respond regularly from now on.
I've merged the PR and I'll publish the fix in 0.17.0, it should happen today


Added dropdown for fqdn and ip address.

Signed-off-by: Himanshi Chhabra<EMAIL_ADDRESS>:nut_and_bolt: Description: What code changed, and why?
We currently require both the FQDN and the IP address of the chef server. We need to change and make it optional so add a dropdown in which the user can select any option of FQDN or IP address

:chains: Related Resources
#4945
:+1: Definition of Done
Added a dropdown in which the user can select any option of FQDN or IP address
:athletic_shoe: How to Build and Test the Change
STEP 1
inside the hab studio

[default:/src:0]# build components/automate-ui-devproxy/
[default:/src:0]# start_automate_ui_background
[default:/src:0]# start_all_services

STEP 2
open new window
go to automate UI path

$ cd components/automate-ui
and run the command

npm run serve:hab

To add data https://github.com/chef/automate/blob/master/dev-docs/adding-data/adding_test_data.md#adding-data-to-infra-views
Steps for policy file  tab:

Go To  Infrastructure -> Chef Servers -> click Add chef server -> Add name -> Select FQDN or IP Address option -> Add FQDN or IP Adress form filed data -> click Add chef server

:white_check_mark: Checklist
All PRs must tick these:

[x] I have read the CONTRIBUTING document.
[x] All commits signed-off for the Developer Certification of Origin.

With occasional exceptions, all PRs from Progress employees must tick these:

[x] Is the code clear? (complicated code or lots of comments--subdivide and use well-named methods, meaningful variable names, etc.)
[x] Consistency checked? (user notifications, user prompts, visual patterns, code patterns, variable names)
[x] Repeated code blocks eliminated? (adapt and reuse existing components, blocks, functions, etc.)
[x] Spelling, grammar, typos checked? (at a minimum use make spell in any component directory)
[x] Code well-formatted? (indents, line breaks, etc. improve rather than hinder readability)

All PRs from Progress employees should tick these if appropriate:

[ ] Tests added/updated? (all new code needs new tests)
[ ] Docs added/updated? (all customer-facing changes)

Please add a note next to any checkbox above if you are NOT ticking it.
:camera: Screenshots, if applicable

Space between 'Type' and dropdown must be less.

If I select IP Adress and I cancel/ close modal and open again then the dropdown value is IP Adress. Same for the FQDN. Can dropdown be set to the default value?

I have some observations

Font weight of dropdown must be normal.
space between dropdown and below test should be more.
height of dropdown should be the same

If there is no data available for FQDN or IP Address then can we show '-' instead of empty?