[Bug][Feature] Convert datetime to UTC before saving into database.

Cross timezone aware web application should save all DateTime field in UTC format and convert it back into application timezone settings when retrieving it back.
I use this BaseModel patch to convert all DateTime field into UTC timezone and convert it back. BaseModel extends Eloquent.
// Patch for saving all date time into UTC timezone
protected function fromDateTime($value)
{
    if ($value instanceof DateTime && $value->getTimezone()->getName() != 'UTC') {
        $value->setTimezone(new DateTimeZone('UTC'));
    }

    return parent::fromDateTime($value);
}

// Patch to convert back time from UTC format into Application wide timezone
protected function asDateTime($value)
{
    $date = parent::asDateTime($value);
    $date = new Carbon($date->toDateTimeString(), 'UTC');
    $date->timezone = Config::get('app.timezone');
    return $date;
}

Benefit from saving in UTC is when Application wide timezone is changed, all DateTime field in database is still pointing into the right date and time.

I think perhaps the docs could be clearer on this.
By setting app timezone as UTC I assumed that whatever timezone my dates were in that they would be saved as UTC. Where as they are saved just as a time and then when they are loaded it is assumed they are UTC.

@jeremyfrench Consider writing a pull request to the docs to explain this further:
https://github.com/laravel/docs

This is still a big mess:
'timezone' => 'UTC', in my config/app.php
I have these 2 dates:
Carbon\Carbon {#598
     +"date": "2016-03-26 20:22:11.000000",
     +"timezone_type": 2,
     +"timezone": "EET",
}

and
Carbon\Carbon {#600
     +"date": "2016-03-26 20:22:11.000000",
     +"timezone_type": 3,
     +"timezone": "UTC",
}

When I save both of them to DB with Eloquent I get 2016-03-26 20:22:11 for both of them!
IMHO this is very unexpected, isn't it?

I think this can be done without it seeming magical. If given a Carbon or DateTime instance with a timezone that doesn't match the default then convert it to the default. I can't imagine many people are explicitly setting the timezone on a per model instance without a reason.
Like the following case where UTC is the app default, but a different timezone is explicitly set..
$timestamp = new Carbon('2016-01-01 00:00:00', 'America/Detroit');
$task = new Task(); //eloquent model
$task->due = $timestamp; //where 'due' is cast to datetime
//the due time should be automatically cast to UTC, because it differs from the default
$task->due->toDateTimeString(); //Outputs: 2016-01-01 05:00:00

That being said, it didn't take much to modify the default behavior. I ended up overriding the asDateTime method
<?php namespace App\Traits;

use Carbon\Carbon;

Trait ConvertTimes
{
    /**
     * Return a timestamp as DateTime object.
     *
     * @param  mixed $value
     * @return \Carbon\Carbon
     */
    protected function asDateTime($value)
    {
        if ($value instanceof Carbon) {
            //Timezones match, don't do anything
            if ($value->tzName === config('timezone')) {
                return $value;
            }

            //Timezone is different than the default so change it
            $value->setTimezone(config('timezone'));
            return $value;
        }

        return parent::asDateTime($value);
    }
}

Just to add to this for anyone landing here in the future.
My application is intended to be used internationally and needs to support users all over the world. Therefore, I need to ensure that UTC time is used throughout the entire application. I want to ensure that the database stores times as UTC and I want to access times as UTC as well. I would only ever use a different timezone for display purposes.
It's possible to set the timezone when connecting to the database in Laravel through the configuration. You can do this in the config/database.php file by setting a timezone option. For example:
<?php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', '<IP_ADDRESS>'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE'),
            'username' => env('DB_USERNAME'),
            'password' => env('DB_PASSWORD'),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'case_sensitive_charset' => 'utf8mb4',
            'case_sensitive_collation' => 'utf8mb4_bin',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => '+00:00'
        ],

You can use a named timezone such as UTC or Europe/London if you want, but you need to make sure that the time zone information tables in the mysql database have been created and populated.
In addition to this, I have a base model class that all of my application's models extend. In this class I have overridden the asDateTime method, as suggested by @andybeesee above, with a bit of a modification:
/**
 * Return a timestamp as DateTime object.
 *
 * @param  mixed  $value
 * @return \Carbon\Carbon
 */
protected function asDateTime($value)
{
    $dateTime = parent::asDateTime($value);

    $timezone = config('app.timezone');

    if (!$dateTime->getTimezone()->getName() !== $timezone) {
        $dateTime->setTimezone(
            new DateTimeZone($timezone)
        );
    }

    return $dateTime;
}

As you can see, I call the parent implementation of asDateTime first, which should ensure that an instance of Carbon or DateTime is returned. This method can accept input in the form of Carbon, DateTimeInterface, strings, integers etc. and returns instances of Carbon, so by calling the parent implementation first, I can account for values that aren't originally instances of DateTime or Carbon. I then compare the returned object's timezone against that of my config's timezone (UTC) and make the necessary adjustments.
This allows my models to accept a DateTime or Carbon object with any timezone for any attribute in my dates cast, and it will automatically be converted to UTC:
$example = new Example();
$example->created_at = new Carbon('2017-06-16 14:05:00', 'Europe/London');
dd($example->created_at->format('Y-m-d H:i:s (T)')); // Outputs "2017-05-16 13:05:00 (UTC)"

I found a less intrusive solution. I just leave UTC as timezone in app config and use this trait in my models:
trait LocalDateTrait
{
    public function getAttribute($key)
    {
        $localTz = false;
        if (starts_with($key, 'local_tz_')) {
            $localTz = true;
            $key = str_replace('local_tz_', '', $key);
        }

        $attribute = parent::getAttribute($key);

        if ($localTz) {
            $attribute->timezone(config('app.display_timezone'));
        }

        return $attribute;
    }
}

Any date attribute that I access using local_tz_<original_attribute_name> will get converted to the configured display_timezone.

That is why I prefer unix timestamp, It's annoying bug in laravel

What @oleynikd said is a big issue.
@taylorotwell you are telling us:

I don't think we should magically convert times to a given timezone.

But this is exactly what Laravel does right now in the example mentioned by @oleynikd. Not exactly to be honest. It replaces timezone information, which is even worse than converting.
I want my system to take any DateTime and normalize it to UTC (or what's configured in Laravel config). The current behavior is really confusing IMO.

I'm very much in agreement with @slykar. Laravel completely ignores the timezone of the Carbon object  when saving the model. This is unexpected behavior and, in my opinion, a bug.

I ran into this issue today.
I have a model with an attribute defined as a date.
If I set this attribute as 1999-01-01T10:00:00+03:00 (either as a string or a proper carbon object) it will be stored in the database as 1999-01-01 10:00:00 even though my application is configured to be in UTC.
Eloquent just "throws away" the timezone information and stores an (in my opinion) timestamp.

@emil-nasso you're responsible for storing datetimes as utc. Convert the time to UTC before you store it.

@emil-nasso you're responsible for storing datetimes as utc. Convert the time to UTC before you store it.

I beg to differ. :) I believe eloquent is responsible for storing data.
I defined an attribute as a date and provided a date encapsulated in a Carbon object to an eloquent object.
In this case, I provided eloquent with the date 1999-01-01 07:00:00 UTC (wrapped in a Carbon object with a +3 tz). This was serialized as 1999-01-01 10:00:00 UTC. Those are not the same.
Eloquent serializes 1999-01-01T10:00:00+03:00 to 1999-01-01T10:00:00+00:00. I really can't see how that would be correct behavior.
The problem is that in asDateTime of HasAttributes the date is instanced as carbon objects and later just serialized.
https://github.com/illuminate/database/blob/master/Eloquent/Concerns/HasAttributes.php#L881
You can't do that without losing information unless you make sure that the date of the timestamp and the application are identical. The problem is not that I have a timestamp of the wrong timezone. The problem is that eloquent claims to support Carbon dates and dates in various formats that contain the timezone but completely disregard the timezone when serializing.
The point of serialization is that you should be able to serialize something and then unserialize it again to get the exact same thing back. The way eloquent serializes datetimes doesn't fulfill that.

@kylekatarnls can you maybe pitch in on the above?

Hello,
i don't think laravel should convert timezone, they are meaningful, 12H00 +0200 is not the same as 11H00 +0100, even if they have the same utc value, original timezone should be preserved and not lost.

@lk77 no it shouldn't. Laravel creates timestamp fields for any of its date times which have no context of a timezone. You should convert to UTC before saving and save the timezone separately in a different column.

@emil-nasso that's incorrect sorry. Laravel has no knowledge of what timezone you're storing your dates in. It mainly uses timestamps which have no context of a timezone. We can't enforce converting to UTC or whatever because people could be assuming the time is stored in a different timezone. You are responsible yourself for converting to the correct timezone before storing any DateTime object (regardless of it being Carbon or not).
Timezones are a presentational concept at best. It's always best to store DateTime objects as UTC for any programmatically action on them and then store the timezone that's related to the timezone as a separate column. Then you can apply the timezone later when presenting it to a user.
Also see: https://www.mysqltutorial.org/mysql-datetime/

MySQL stores TIMESTAMP in UTC value. However, MySQL stores the DATETIME value as is without timezone.

When storing to a simple DATETIME field, you always loose the timezone information. Either you choose UTC or current timezone of the object. If you assume you can have various timezones for dates to store in the same SQL column, then you can use ->dateTimeTz() type. This will save the date as 2 informations. But the timezone date is an offset. Having the timezone in a separated string column as said @driesvints is even better because string timezone is more precise.
If you have a GMT (UTC) database and an other timezone for your app (config('app.timezone')) you should reconsider the relevance of this divergence. If your app is accessed worldwide or could be someday, then your app should be timezone-agnostic like your DB: 'timezone' => 'UTC' in config/app.php. Then the timezone to display a date can be:

linked to an other data (for instance a flight: the airport cities)
device/OS setting (local browser)
user setting (for instance when sending a email notification)
custom input (the timezone can be picked in a selector, calculated, and it can be for 1 date of a record or for the whole record)

That means, if Eloquent would proceed a conversion on retrieving dates, it would be highly arbitrary and would break many existing apps.
By not doing any conversion, Eloquent let a wider control application-side to adapt closely to those different cases.
About the conversion on storing. This is actually "too late" to do a conversion IMO. $date->tz(config('app.timezone')) should be done right after getting the input, so when you work with it in your back-end (compare it to now() for instance) you know you're working with aligned dates.

Stumbled across this thread today, because I had odd problems with date/times being stored by Laravel. I also strongly encourage to re-open this issue, because this is an annoying Laraval bug.
IMHO, @emil-nasso, @oleynikd, @andybeesee and @slykar  are totally right in what they suggest.
You, the Laravel developers, claim that
a) Laravel should not alter the datetime when it is stored and should not magically convert it, and
b) Laraval stores timestamps in UTC
But this is exactly that does not happen. a) Laraval alters the datetime which is being stored in the most insane way. It simply cuts off any timezone information which might be available in a Carbon instance and then re-interprets the result according to the configured applications timezone. This is even worse than a correct conversion, because it alters the specified instance in time. b) Laravel passes the datetime as a formatted string without any timezone information to the SQL server. The SQL server then interprets this datetime (without a timezone information) according to its own configured default timezone.
A Full Example of the Problem
A sequence diagram

Assume the SQL table has a dateime column without timezone information. Moreover, assume that for the sake of this example the SQL server and the SQL connection is using EET (i.e UTC+2).
The PHP application is configured to use CET (i.e. UTC+1)
We have the two Carbon objects Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "EST" }, i.e. UTC-5, and Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "PST" }, i.e. UTC-8.
I assume, that we all agree that both denote two totally different instants of time on the universe timeline although the represent the "wall time" with respect to there local timezones. The first one is the same instant of time as "2016-03-26 20:22:11 UTC" or<PHONE_NUMBER> in seconds since epoch and the latter is the same instant of time as "2016-03-26 23:22:11 UTC" or<PHONE_NUMBER>.
If Laravel serializes those dates to the database, Laravel simply puts the string "2016-03-26 15:22:11" into the SQL query, i.e. it cuts off the timezone information without proper conversion. Hence, both times look the same.
But the story gets even worse: The SQL layer interprets both times as if they were relative to EET, because that is the configured default of the SQL server, i.e. the SQL server interprets them as "2016-03-26 15:22:11 UTC+2" which is equal to "2016-03-26 13:22:11 UTC" or<PHONE_NUMBER> in seconds since epoch. Finally, the timestamp<PHONE_NUMBER> will be stored on disk.
If Laraval fetches those dates from the database back into the model space, the DB layer transforms the internally stored timestamp<PHONE_NUMBER> into "2016-03-26 15:22:11 UTC+2" again and reponse "2016-03-26 15:22:11" to Laraval as part of the SQL result. (I.e. here the false transformation on the DB layer is luckily reverted.)
Laraval receives "2016-03-26 15:22:11" for both (!) datetimes and creates two Carbon instances which use the application's  default timezone CET, i.e. Laravel creates two Carbon objects Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "CET" } which represent the instant "2016-03-26 14:22:11 UTC" or<PHONE_NUMBER>.

The actual result
We create

Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "EST" }  --> epoch:<PHONE_NUMBER>
Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "PST" }  --> epoch:<PHONE_NUMBER>
store them into the database and receive
Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "CET" }  --> epoch:<PHONE_NUMBER>
Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "CET" }  --> epoch:<PHONE_NUMBER>
back.

The problems are twofold

Two different instants of time collapse into the same instant of time
The resulting instant of time neither match any of the original instants

There is no way, one could call that "correct behaviour".
The expected result
We create

Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "EST" }  --> epoch:<PHONE_NUMBER>
Carbon\Carbon { "date": "2016-03-26 15:22:11", "timezone": "PST" }  --> epoch:<PHONE_NUMBER>
store them into the database and receive
Carbon\Carbon { "date": "2016-03-26 21:22:11", "timezone": "CET" }  --> epoch:<PHONE_NUMBER>
Carbon\Carbon { "date": "2016-03-27 00:22:11", "timezone": "CET" }  --> epoch:<PHONE_NUMBER>
back.

Yes, the "wall time" which we receive back differs from the original "wall time", but they represent the orginal instant in time. The change of wall time (and the change of timezone) is expected, because this simply happens if one does not store the timezone in the database and is an unavoidable loss of information. There is just no other way, than using the application's default timezone, if the original timezone has not been stored.
How it should be solved
See @andybeesee [post|https://github.com/laravel/framework/issues/1841#issuecomment-205051718]. This is actual the correct solution with one minor addition:

If Laravel opens the database connection, first invoke a SET TIMEZONE <fixed-timezone> to ensure that the PHP application and the database server and the PHP application have common understanding how time string without timezone information shall be interpreted. Do not rely on the assumption, that the default time zone of the PHP application and the default time zone of the SQL server are the same. Probably, the best choice is for <fixed-timezone> is UTC, but actually it does not matter.
Then use @andybeesee solution. Whenever a datetime is stored into the database properly convert it to the fixed timezone the SQL server and the PHP application have agreed upon. Whenever a datime without timezone information is received from the database, interpret it according to the fixed timezone and then convert it properly into the applications default timezone.

Proposed solution is LGTM, but clearly a breaking-change needing to wait a major version.

Nothing to say about that, except that it should be a 1-shot compile time operation, if app/db timezone can change on runtime we are in more troubles that what Laravel can help us with.
Is great for consistency in the database but to avoid the model dates properties to be mutated it involves to copy the date (if not immutable) before running ->setTimezone(config('app.timezone')) then the format as of now.

To be considered: setting the timezone before saving can make the storing process a little bit slower.

Last, you should remember than even if Laravel would ->setTimezone(config('app.timezone')) before saving dates, you're still not safe:
Config::set('app.timezone', 'UTC');

$model = Model::find(1);
$model->date = Carbon::parse('15:22 EST');
echo $model->date->format('H:i'); // 15:22

$model->save();
$model = Model::find(1);
echo $model->date->format('H:i'); // 15:22
// If we implement the change above:
echo $model->date->format('H:i'); // 20:22

We're still loosing the "EST" information and this will still cause bad surprises to some users. As in only 1 DATETIME/TIMESTAMP column you can't properly save the timezone information, it's still relevant application side to manually set the timezone before you attach a date to a model so you're sure having the same thing once you'll retrieve again this object from the DB.
Eventually this could be immediately converted on __set() and update() but I'm unsure it can be implemented without getting more other troubles.

Last, you should remember than even if Laravel would ->setTimezone(config('app.timezone')) before saving dates, you're still not safe:
Config::set('app.timezone', 'UTC');

$model = Model::find(1);
$model->date = Carbon::parse('15:22 EST');
$model->save();
$model = Model::find(1);
echo $model->date->format('H:i'); // 20:22

We're still loosing the "EST" information and this will still cause bad surprises to some users. As in only one DATETIME/TIMESTAMP column you can't properly save the timezone information

I never denied that you loose information. You obviously haven't read my post carefully. I wrote

Yes, the "wall time" which we receive back differs from the original "wall time", but they represent the original instant in time. The change of wall time (and the change of timezone) is expected, because this simply happens if one does not store the timezone in the database and is an unavoidable loss of information.

If users - in this case developers to be more precise - are surprised that "2016-03-26 15:22:11 EST" represents the same instant as "2016-03-27 00:22:11 CET" they simply have not understood time zones.
I completely disagree: Observing that "2016-03-26 15:22:11 EST" and "2016-03-27 00:22:11 CET" are the same instant in time and are completely identical from the database perspective of view if the database does not keep timezone information is by far less surprising than putting two completely different instants of time into the database like "2016-03-26 15:22:11 EST" and "2016-03-26 15:22:11 PST" and then receiving back identical timestamps "2016-03-26 15:22:11 CET" with neither of them being correct.
Let me re-phrase your counter example from above. At the moment we get the following
Config::set('app.timezone', 'UTC');

$model = Model::find(1);
$model->date = Carbon::parse('15:22 EST');
echo $model->date->format('H:i e'); // 15:22 EST
$model->save();
$model = Model::find(1);
echo $model->date->format('H:i e'); // 15:22 UTC --> Argghh?

Your counter example from above only appears allegedly surprising, because you intentionally did not print the timezone but suppressed it from the output. If one applied the recommended patch, we would get
Config::set('app.timezone', 'UTC');

$model = Model::find(1);
$model->date = Carbon::parse('15:22 EST');
echo $model->date->format('H:i e'); // 15:22 EST
$model->save();
$model = Model::find(1);
echo $model->date->format('H:i e'); // 20:22 UTC --> Not perfect, original tz information is lost, but at least the time is correct

Even worse the database even messes up relative ordering. Obviously, "2020-01-15 12:00:00 UTC-2" < "2020-01-15 10:00:00 UTC-5" holds. The first one is "2020-01-15 14:00:00 UTC", the latter one is "2020-01-15 15:00:00". Hence, an event at the first instant happens before an event which happens at the latter instant. However, after hydration from database they come back as "2020-01-15 12:00:00 <app's timezone>" > "2020-01-15 10:00:00 <app's timezone>", i.e. there ordering has been inverted. Even relativity theory is not able to achieve that!
Please note, the loss of timezone information is not the problem here. That is expected. This is already the case with the current implementation. If a new instance of a Carbon object is created by the HasAttributes trait during hydration from database, the Carbon object always has the application's default timezone. There is already a loss of information. But at the moment, this unavoidable loss of information is done in the most insane way possible. By simply cutting off timezone information, we end up with many funny quirks.

I completely disagree

disagree to what, I said I agreed your proposal 😏
And there is no need to be rude, it's quite easy to judge something done years ago and just ask to change it, but it's also fair from Laravel core team to consider BC wisely, because they will have to deal with helping users to migrate and get their apps working with the new timezone handling if it changes.

Love Laravel, but this has bitten me a few too many times. Thoughts on the following one line change to prepareBindings in Illuminate\Database\Connection.php?
// set the default app time zone rather than laravel's default behavior of discarding it
$bindings[$key] = (clone $value)->setTimeZone(config('app.timezone'))->format($grammar->getDateFormat());

This clones the datetime object so we don't affect what we were given, then sets the app time zone (should be UTC) before the time zone truncation happens during string conversion.
The bonus here is that in addition to ensuring model dates are stored in UTC this would also ensure all queries against models would correctly compare against the same time zone.
To be clear, presenting a model date as local time would still need to be handled separately as it should be.
Thoughts?

This is relevant IMO, but this might need to be an opt-in because, for devs currently doing:
$bindings['date'] = Carbon::parse('2023-01-01 12:00');
$bindings['timezone'] = 'America/Toronto';

(user can select explicitly a timezone for instance), they can expect to get the Toronto digits in the DB (in order to perform some raw SQL queries on it) and having UTC would be a breaking change for them.

Just to hopefully help someone else out in the future, Laravel's less than ideal way of simply discarding any time zone information when storing in the database can be fixed with the following two overrides:
use Illuminate\Database\Eloquent\Model as BaseModel;

class Model extends BaseModel
{
	// override so that we can stop laravel from simply discarding time zone information when storing a DateTime object in the database
	public function fromDateTime($value)
	{
		if (empty($value)) return $value;

		return $this->asDateTime($value)->setTimeZone(config('app.timezone'))->format($this->getDateFormat());
	}
}

and in AppServiceProvider (anonymously):
    public function register()
    {
		// override the mysql connection class so that we can stop laravel from simply discarding time zone information when storing a DateTime object in the database
		Connection::resolverFor('mysql', function($connection, $database, $prefix, $config) {
			return new class($connection, $database, $prefix, $config) extends MySqlConnection {
				public function prepareBindings(array $bindings)
				{
					$grammar = $this->getQueryGrammar();

					foreach($bindings as $key => $value)
					{
						if($value instanceof \DateTimeInterface)
						{
							// clone so we don't affect what we were provided, then always set UTC before converting to a string
							$bindings[$key] = (clone $value)->setTimeZone(config('app.timezone'))->format($grammar->getDateFormat());
						}
						elseif(is_bool($value))
						{
							$bindings[$key] = (int) $value;
						}
					}

					return $bindings;
				}
			};
		});
    }

This allows work to be done with local time in a less paranoid fashion (Carbon compares in a time zone agnostic fashion) and still always store all dates and times in the database as UTC.

I have to add my voice to the chorus here.
Laravel handles so much troublesome logic under the hood that it hadn't even occurred to me that this would be a problem. Especially when Laravel Eloquent casts to DateTime/Carbon right out of the box. Both of those classes explicitly support timezone as a factor of their timestamp value and to simply omit the timezone from storage consideration fundamentally changes the value that gets stored, tantamount to scrambling the letters of a string value when storing. And I think one could reasonably and easily make the case that not supporting DateTime/Carbon holistically here, when you lean on its use out of the box, is a legitimate bug.
It was earlier stated that you don't think Laravel should be in the business of converting timestamps like this but that's the rub: you're in the business whether you want to be or not because storing a Carbon object's 2023-10-08T16:32:45-07:00 value as 2023-10-08 16:32:45 in the database is still a "conversion" and a broken one at that. It's far better to take the reigns and deliberately normalize on app.timezone (or other configurable timezone setting) to retain value integrity than to allow natural conversion to break integrity and corrupt the data. And break it in a way that developers might not even immediately detect.

I think most of the people who dug a bit this issue including Laravel team would agree that applying app.timezone (with ->setTimezone()) before saving is better than dropping the timezone of DateTime objects.
It would be easy to make it so with a brand new framework you build from scratch. It would likely be a 2-lines-of-code features implemented in 1 minute.
But with Laravel, it would be a big breaking change for thousands users. It would be plannable for a later major release 11 or 12, however it would still require the tooling so Laravel 10 users can migrate their app with reasonably low efforts.
This one is the difficult part to solve: imagine an app currently relying on the timezone truncation (for instance a meeting table that could have mixed timezone in it but would work fine because it also has an office column and each office has a linked timezone, so on app-level you can work with DateTime objects having the timezone synchronized on the office, either this idea is good or not is out of scope, because it just might already exist in many applications and work just fine for who built/use them), those might be big (we can imagine a million-rows table so it would take time to update the whole table) and it might be a very hot table (with hundred insert/delete per second, and way more select), telling such a business to put the application down for maintenance for multiple hours to proceed the migration of the DB and the update of the code in the same time is likely not affordable.
So, Laravel needs to provide to existing apps incremental steps without needing downtime. It's no longer a 2-lines-of-code change, I probably don't see everything it needs bu at least:

An option to use the new behavior (old behavior by default, but opt-in for new apps)
Ideally a way to set this option in a fine granularity per table/column
A way for users to discover the new behavior, why it's recommended and know which part of their code uses the old one, and where toggling the option would change the outcome (i.e. detect when a DateTime is saved and has a timezone that is different from app.timezone, and log it as a deprecation notice but not fail on it)
A way to distinguish values saved in DB using the old behavior, and those using the new one
An helper for users so they can tel according to their own use cases how is computed the timezone for tables that have datetimes with dynamic timezones
A way to update values from old to new behavior in database (with progressive rollout so it can be ran in background on application still running)

But with Laravel, it would be a big breaking change for thousands users. It would be plannable for a later major release 11 or 12, however it would still require the tooling so Laravel 10 users can migrate their app with reasonably low efforts.

As I understand it, yes and no. As @thunberg's solution shows, there's two points where this behavior can be introduced. One time at the low MySqlConnection level and one time at the higher Eloquent Model layer. I agree that changing it at the lower level would be problematic but at the Model level? You could toggle the new behavior with a simple boolean property on your Model subclass and opt-in for the new behavior. And I think that's where it'd matter for people the most.

Just wanted to let anyone who stumbles upon this know that I found a package that solves this weird broken Laravel behaviour it for me:
https://github.com/whitecube/laravel-timezones
Make sure to read well, the app.timezone should be UTC and you must set your actual timezone somewhere else! Only then it will convert properly.


Cleanup

Once we have a bit more time, some code clean-up is in order:

[ ] grep TODOs, fix them and remove obsolete ones
[ ] Refactor cell_level_analysis by moving InstanceFeatureExtraction and ExtractBackground to separate file
[ ] Clean up class hierarchy CellLevelAnalysisBase, CellLevelAnalysisBaseWithTable (the hierarchy makes sense, but the top-level base class is too specific right now; it should not require knowing the keys)
[x] Remove the segmentation_on_corrected / analysis_on_corrected options, we will never change this away from defaults and this creates the very annoying _corrected names.
[ ]  Change the name of the dont_ignore_nuclei parameter, it's super confusing.
[ ] Clean up the background config parameter handling (only need a single param and don't need to be so convoluted with the use_fixed_background flag).

Removing segmentation_on_corrected etc was implemented in #107

Refactors are part of #130.
After that, only need to clean up TODOs and FIXMEs


Dreame has its own app and is no longer with Xiaomi

Hi,
Dreame has its own app and is no longer with Xiaomi, Hi I wanted to add the plugin. However, I cannot log in with the credentials because I need a Xaomi cloud here. I have also created an account there but the robot does not appear. I googled something. Dreame has its own app. So it probably doesn't work anymore. Does anyone have an idea or can help me?
Thanks Max

Same issue here, just purchased a Dreame and unable to log in to this integration

Perfekt I use v 2.0.0b9 it works with a dream Account

With the latest beta, and an L20 Ultra I cannot get the integration to connect with either my Xiaomi cloud or dreame.com user/password. It says not authenticated. Is there a very specific website credentials we should use instead of the dreame.com email/password combination.


[SPARK-17666] Ensure that RecordReaders are closed by data source file scans

What changes were proposed in this pull request?
This patch addresses a potential cause of resource leaks in data source file scans. As reported in SPARK-17666, tasks which do not fully-consume their input may cause file handles / network connections (e.g. S3 connections) to be leaked. Spark's NewHadoopRDD uses a TaskContext callback to close its record readers, but the new data source file scans will only close record readers once their iterators are fully-consumed.
This patch modifies RecordReaderIterator and HadoopFileLinesReader to add close() methods and modifies all six implementations of FileFormat.buildReader() to register TaskContext task completion callbacks to guarantee that cleanup is eventually performed.
How was this patch tested?
Tested manually for now.

Nice one, looks like something that can only help.

Test build #65931 has started for PR 15245 at commit e4b8577.

Test build #65931 has finished for PR 15245 at commit e4b8577.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/65931/
Test PASSed.

Merged build finished. Test PASSed.

LGTM

Merging in master. There is a conflict with 2.0. Can you make a backport pull request?

I've opened #15271 to backport.


remove livestream

https://github.com/lnbits/livestream

Codecov Report

Merging #1504 (6df8494) into main (5bc2646) will increase coverage by 0.11%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1504      +/-   ##
==========================================
+ Coverage   49.47%   49.59%   +0.11%
==========================================
  Files         194      186       -8
  Lines       13064    12746     -318
==========================================
- Hits         6464     6321     -143
+ Misses       6600     6425     -175

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Cache fragment metadata in-memory

For Take we currently have to perform one set of IOs to read fragment metadata, and then we read the actual data.
We could significantly improve the e2e latency by caching the fragment metadata. We would also need a reliable mechanism to "warm up" this metadata cache.

We do cache the metadata, page table, statistics, and deletion vector. I'd be happy to take a look at what we might be missing.


Problem in generating the pertained output like Elmo

I followed the example to generate pretrained features. However, unlike other examples, it cannot find the pretrained model, with the error message like this:
INFO:tensorflow:Could not find trained model in model_dir: /tmp/tmp6sn66z76, running initialization to predict..  This message print when running line for result in estimator.predict(input_fn, yield_single_examples=True):
However, after this, in the model_fn function, tf.train.init_from_checkpoint is called. So not sure if this actually a problem or is just a meaningless printing .

Yes that warning is expected, it just means that you didn't do any training (which is what we expect in this case).


Uncaught non-precached-url: non-precached-url :: [{"url":"/"}]

Hey, I am getting the following error:
Uncaught non-precached-url: non-precached-url :: [{"url":"/"}]
I checked the _urlsToCacheKeys, and the base URL is not included.
Prerendering is completely disabled in my project.
The dev mode works fine - the problem only occurs in production mode.
  System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (16) x64 Intel(R) Core(TM) i9-9900KS CPU @ 4.00GHz
    Memory: 3.67 GB / 15.54 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 8.4.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 107.0.5304.87
  npmPackages:
    @sveltejs/adapter-node: 1.0.0-next.100 => 1.0.0-next.100
    @sveltejs/kit: 1.0.0-next.548 => 1.0.0-next.548
    svelte: ^3.53.1 => 3.53.1
    vite: ^3.2.4 => 3.2.4

@Cluster2a can you shared your pwa plugin options?

Hey - sure! Her you go.
SvelteKitPWA({
	srcDir: './src',
	mode: process.env.NODE_ENV as 'development' | 'production',
	strategies: 'injectManifest',
	filename: 'sw.ts',
	scope: '/',
	base: '/',
	injectRegister: 'script',
	includeAssets: ['favicon.ico', 'apple-touch-icon.png', '/img/mask-icon.svg'],
	manifest: {
		short_name: 'freispace',
		name: 'freispace',
		description: 'Your supercharged resource and project management.',
		start_url: '/dashboard?source=pwa',
		scope: '/',
		display: 'standalone',
		theme_color: '#006aa3',
		background_color: '#f3f4f6',
		icons: [
			{
				src: '/img/pwa-192x192.png',
				sizes: '192x192',
				type: 'image/png',
				purpose: 'any'
			},
			{
				src: '/img/pwa-512x512.png',
				sizes: '512x512',
				type: 'image/png',
				purpose: 'any'
			},
			{
				src: '/img/favicon.svg',
				sizes: 'any',
				type: 'image/svg+xml',
				purpose: 'any'
			}
		],
		shortcuts: [
			{
				name: 'freispace Dashboard',
				short_name: 'Dashboard',
				url: '/dashboard?source=pwa',
				icons: [
					{
						src: '/img/pwa-dashboard.png',
						type: 'image/png',
						sizes: '96x96'
					},
					{
						src: '/img/pwa-dashboard.svg',
						type: 'image/svg+xml',
						sizes: 'any'
					}
				]
			},
			{
				name: 'freispace Planner',
				short_name: 'Planner',
				url: '/planning/overview?source=pwa',
				icons: [
					{
						src: '/img/pwa-planner.png',
						type: 'image/png',
						sizes: '96x96'
					},
					{
						src: '/img/pwa-planner.svg',
						type: 'image/svg+xml',
						sizes: 'any'
					}
				]
			}
		]
	},
	injectManifest: {
		globPatterns: ['client/**/*.{js,css,ico,png,svg,webp,woff,woff2}']
	},
	devOptions: {
		enabled: true,
		type: 'module',
		navigateFallback: '/'
	}
})

@Cluster2a can you share your sw.ts?

I am using the standard service worker.
import {
	cleanupOutdatedCaches,
	createHandlerBoundToURL,
	precacheAndRoute
} from 'workbox-precaching';
import { NavigationRoute, registerRoute } from 'workbox-routing';

declare let self: ServiceWorkerGlobalScope;

self.addEventListener('message', (event) => {
	if (event.data && event.data.type === 'SKIP_WAITING') self.skipWaiting();
});

// self.__WB_MANIFEST is default injection point
precacheAndRoute(self.__WB_MANIFEST);

// clean old assets
cleanupOutdatedCaches();

let allowlist: undefined | RegExp[];
if (import.meta.env.DEV) allowlist = [/^\/$/];

// to allow work offline
registerRoute(new NavigationRoute(createHandlerBoundToURL('/'), { allowlist }));

After removing the offline part, the service worker is working fine.

@userquin, what if I want to use the offline mode?
Removing this is just like a workaround but not a real fix, or am I mistaken here?

@Cluster2a try configuring /404 adding +error.svelte with prerender enabled in +error.ts: export const prerender = true;.

Do you mean like this? Doesn't work either:

@userquin, ah I see - you asked for an +error.ts. This does not seem to be allowed in svelteKit:

@Cluster2a try adding it at leat to the entry point (/: +page.ts), if there is no prerender we cannot fallback to any url...

@Cluster2a have you tried to just requets some missing page without the offline entry?

@Cluster2a the docs allows you to create an error.html under src folder, check where it is moved then use it as fallback:
https://kit.svelte.dev/docs/routing#error

I created a /sw/+page.svelte & /sw/+page.ts (prerender = true).
registerRoute(new NavigationRoute(createHandlerBoundToURL('/sw'), { allowlist }));

I also excluded this route from my hook.
This seems to work now.
Is this a valid way to handle this?

I also checked the fallback error:

But I wasn't able to access it via URL.

@Cluster2a what adapter are you using? try adding the fallback to kit config file and also to kit entry in pwa options

@userquin, i am using @sveltejs/adapter-node.
I am not aware of the fallback option. I need to check that out.

@Cluster2a you can check this repo:

pwa: https://github.com/Giszmo/nostroid/blob/master/nostroid-config.js#L46
kit: https://github.com/Giszmo/nostroid/blob/master/svelte.config.js#L15
vite: https://github.com/Giszmo/nostroid/blob/master/vite.config.ts#L13

@userquin, I can not use the static adapter since I am using server-side endpoints which are not supported by this adapter.
The node-adapter does not seem to accept a fallback option.
My build folder looks like this:

@Cluster2a it is using also build folder, and it is copying all client and prerendered folders, so we need to add a custom manifestTransform to the pwa plugin: just check the code in the config.ts module in this repo.
The layout is different, static-adapter will copy the client and prerendered folders contents in the build folder, adapter node will copy also the client and the prerendered to the build.

The node-adapter does not seem to accept a fallback option.

Then, how the adapter serves the client assets? Maybe you only need to add a node/express middleware, when requestion /sw just serve the content from prerendered/sw.html

EDIT: Im think we don't need to change it, it is a problem serving assets: what is the url for /sw? it should be /sw and not /prerendered/sw so you need a hack to serve any generated html page.

I think you got me wrong... When requesting /sw the prerendered/sw.html is served correctly and the service worker is working.
But somehow this feels kind of hacky to create a custom pre-rendered page just for the service worker to work correctly.

@Cluster2a configure /sw in the offline route: try requesting some non existing route/page

@userquin requesting an invalid route will bring up my error-page (404). So this seems to work.

@userquin requesting an invalid route will bring up my error-page (404). So this seems to work.

try it also setting offline the browser

@userquin, the cache seems to be messed up:

All the JS files are served directly from the /_app -Folder.
When accessing the files form cache, it somehow messes up the path:

It is adding the folder of the route, which is wrong.
The cache seems good though:

@Cluster2a can you create a minimal repro?

@Cluster2a can you create a minimal repro?

https://github.com/Cluster2a/pwa_examle - same stuff with the wrong URLs.

@Cluster2a I'll check it tmr, thx

@Cluster2a check this commit on my fork: https://github.com/userquin/vite-pwa-kit-issue-16/commit/29fb7bc69580d34865b2e67243cf4cff6a840cf3
The main problem with this approach is the navigation pages is not being cached, so you need to refresh/visit the page twice, check and the offline support should work.
Check also the changes in the pwa options, added useCredentials and removed includeAssets adding also the exclusion of the icons in the manifest (on kit there is no need, only when using Vite)

@Cluster2a doing some more testing...

I'm adding @vite-pwa/sveltekit to my SvelteKit template project, and I have the same issue, though I'm using adapter-static for debugging. So I stepped through the sw.js with debugger in the browser and figured out that there is a disconnect between how the urls are actually handled and how example code shows them.
If I replace:
- registerRoute(new NavigationRoute(createHandlerBoundToURL('/sw'), { allowlist: [/^\/$/] }));
+ registerRoute(new NavigationRoute(createHandlerBoundToURL('prerendered/pages/sw.html'), { allowlist: [/^\/$/] }));

it gets to pass this route ok.

However, it fails further down with the same error trying to cache the very first item from the manifest, and the code is complaining about url:
/client/_app/immutable/assets/_layout-ba887965.css
I find the same item in the precache manifest, but without the leading slash '/':
client/_app/immutable/assets/_layout-ba887965.css
I'm guessing that in the recent SvelteKit, @vite-pwa/sveltkit and workbox updated there were some changes that modified how the precache manifest is handled and it is all screwed up now. I will investigate a bit more.

I investigated further, and concluded that SW on client is wrong place to sort out the problem. Precache manifest should be handled at build time, with manifestTransforms parameter to SvelteKitPWA plugin.
Here's version that works with adapter-static, adapter-netlify and adapter-vercel (sorry, I don't have a setup to try adapter-node):
const scope = '/';

// For @sveltejs/adapter-static, @sveltejs/adapter-netlify, @sveltejs/adapter-vercel
/** @type {import('workbox-build').ManifestTransform} */
const manifestTransformStatic = async (manifestEntries) => {
  console.info('Precache Manifest Entries:');
  const manifest = manifestEntries
    .filter(
      ({ url }) =>
        // Remove paths that should not be cached:
        url !== 'client/vite-manifest.json' && url !== 'prerendered/fallback.html'
      // && url !== 'client/manifest.webmanifest' && !url.endsWith('sw.js') && !url.startsWith('workbox-')
    )
    .map((e) => {
      // Adjust paths to match what the adapter server understands:
      const url1 = e.url;
      let url = e.url;
      if (url.startsWith('/')) url = url.slice(1);
      if (url.startsWith('client/')) url = url.slice(7);
      if (url.startsWith('prerendered/pages/')) url = url.slice(18);

      // router paths
      if (url && url.endsWith('.html')) {
        url = url === 'index.html' ? '' : `${url.substring(0, url.lastIndexOf('.'))}`;
      }
      e.url = scope + url; // Canonical URL starts with base
      console.info(`  ${url1.padEnd(100)} => ${JSON.stringify(e)}`);
      return e;
    });
  return { manifest };
};
const manifestTransforms = [manifestTransformStatic];

Pass manifestTransforms to SvelteKitPWA.

I also checked source of @vite-pwa/sveltekit, and found it sets default manifestTransforms by createManifestTransform() which does pretty much the same as what I posted above in manifestTransformStatic(), with createManifestTransform() handling settings more thoroughly.
The reason it was not working in my case, is I had manifestTransforms set to a non-transform, just to log the precache manifest.
So for the adapter-node - it server static, client and prerender. Note that adapter-static serves prerender/pages, which means adapter-node will have /page/index.html, not /index.html. Default createManifestTransform() does not handle that case. The quick fix could be to use my manifestTransformStatic() and adjust the paths until they match what adapter-node serves.
BTW, createManifestTransform() might emit precache manifest with a duplicate entry, if fallback is set to index.html. Just note that it is a special case and handle it accordingly - precache manifest is created from list of paths found in ./.svelte-kit/output/client, and transformManifest should emit the list of paths matching what is served by the adapter.

@iva2k thx for investigating this, I have it pending,  maybe we can add some presets, pr welcome

@kyllerss pwa plugin is just a wrapper for workbox-build, that is  file based, that's, to generate the sw precache manifest (injection point/self.__WB_MANIFEST), and so kit integration will configure pwa plugin to run after prerender but before adapter processes in kit/vite lifecycle.
Once prerender finish, pwa plugin will call workbox-build to generate the sw precache manifest: we need to configure pwa plugin properly via globDirectory on workbox or injectManifest : workbox-build will use globDirectory to traverse it and generate the sw in the sw with the sw precache manifest. We also need to configure properly the output folder, that's, the sw.js should be generated in the kit output build folder, that adapter will copy to the final build folder.
Once we have configured the pwa plugin, we can add some hooks to workbox-build before sw.js is written to disk: kit integration adds a ManifestTransform (will receive file paths in globDirectory and their revision/hash, a list of ManifestEntry objects) to apply some custom transformations (pretty url and fallback url for adapter). You can check it here, the config module has a few comments about kit output folder: https://github.com/vite-pwa/sveltekit/blob/main/src/config.ts#L60
With latest vite-plugin-pwa version released 0.14.0 (kit integration not updated nor released yet) we can use custom sw without injection point (I also need to update the docs to add this new option).

@userquin

thx for investigating this, I have it pending, maybe we can add some presets, pr welcome

I'd like to submit a PR, but the scope is unclear...
I'm thinking that best design would be to have createManifestTransform() coordinate with the adapter, maybe just get a map (source file -> URL destination) from the adapter and use that map, or adapter should provide the transform function, since it only knows how things will be on the server.
Another improvement is to expose / export createManifestTransform(), and allow caller to compose their array of transforms and invoke the standard one which came from the adapter in their chain. That way adapter will have a say, and custom transform added before or after can act on URLs (post) or on file paths (pre), and won't need to know how things are mapped.
Right now custom transform should know what the adapter does, but it has no context to get which adapter is used. In case of adapter-auto, there are few possible actual adapters that custom transform has to figure out. And users could make their own custom adapters. Extending adapter scope will go into sveltejs/kit repo. If that PR is rejected, there's no way to make an informed transform.

@iva2k if you provide a custom TransformManifest the plugin will no register the default one. We can add some preset folder adding there the required stuff, maybe also adding some custom configuration options, not only the TransformManifest:
https://github.com/vite-pwa/sveltekit/blob/main/src/config.ts#L56

@userquin

if you provide a custom TransformManifest the plugin will no register the default one

Yes. What I'm saying is if I can call createManifestTransform() and get the default transform, I could use it in my chain and do this:
  const myPreTransform = (manifest) => {... my file transforms; return manifest; }
  const myPostTransform = (manifest) => {... my URL transforms; return manifest; }
  const defaultTransform = createManifestTransform();
  const transforms = [
    myPreTransform,
    defaultTransform,
    myPostTransform
  ];

Then just pass transforms to the plugin.

@iva2k oh yeah, maybe we can add preManifestTransform and postManifestTransform options to the kit entry with the following logic:

if manifestTransform not empty, then unshift preManifestTransform and add postManifestTransform
if manifestTransform not configured or empty then add preManifestTransform, then add default one and finally add postManifestTransform

We can also  export createManifestTransform: I guess we can also add default presets for adapters (if needed).

Hi, checking in. Is the fix for this one on the roadmap or is there some workaround I should be applying in the meantime (wasn't clear from the comments). Thanks!

I'm also getting this issue with the default config provided in the docs  and using adapter-auto, seems like it's preventing the service-worker to install in safari

check #30 we've detected a bug in custom manifest transform, should be fixed once new version released, in the meantime try adding the manifest transform in the PR to your workbox: { manifestTransform: [] } or injectManifest: { manifestTransform: [] } array depending on the strategy used.

So has this issue been resolved? And if so, is there a guide or demo project I can follow? The above discussion does not seem to solve my iasue. I can't seem to get the offline caching of the pages working, receiving the error Uncaught non-precached-url: non-precached-url :: [{"url":"/"}] when deployed to Vercel.
I want to purely store the application in cache and nothing else, the webapp can just make http requests which will be handled by the service workers.

This is also failing for me. I'll try the SvelteKit suplied service worker, but it would be cool to have a bit notice saying vite-pwa doesn't work in SvelteKit if you're using adapter-node` so we don't lose so much time trying to guess what happens.

@nadanke @ktecho  Yes, that's what I am doing now, I am using the Workbox libraries and use these functions directly in the Sveltekits serice-worker.ts.
But since VitePWA advertises with being zero-config, I was hoping the caching & offline working part of PWAs would be automatically solved for my application.

closed via #32

Yeah I'm getting this too, not sure what it's about as I have a path / and it works fine, so I can't see why it'd whine about it.

@phil-w You need to prerender that route, workbox requires the html file, check if the index.html is present in your kit output folder, inside prerender folder

Ah, thanks, copy that.


fix(audio-player): tooltip duplication

What I did

Removed unnecessary focus() on menu button when menu is closed

Testing Instructions

Go to the Prevent concurrent playback demo from the DP.
Click the More options menu button (kebab icon) on the first player.
Click the More options menu button (kebab icon) on the second player.
Verify that the More options tooltip appears only on the first player.
For good measure, try clicking and using the keyboard to jump between various buttons on the players, opening and closing the menus.
Verify that the focus and tooltips behave as expected.

Notes to Reviewers

@hellogreg please take a look

Fixed for mouse users. It's still possible to get multiple concurrent tooltips via keyboard. Tab to the first "More options" menu and press spacebar. Continue tabbing to the second "More options" menu and press space again. This happened in Safari, Chrome, and Firefox.


Pokemongobot object has no attribute 'position'

Expected Behavior
When I go to json.config and add a latitude and longitude or city/state combination they do not work.
Actual Behavior
[2016-08-02 12:56:25] [x] PokemonGO Bot v1.0
[2016-08-02 12:56:25] [x] Configuration initialized
[2016-08-02 12:56:26] [x] The location given using -l could not be parsed. Checking for a cached location.
[2016-08-02 12:56:27] [#] Username: HIDDEN
[2016-08-02 12:56:27] [#] Acccount Creation: HIDDEN
[2016-08-02 12:56:28] [#] Bag Storage: 296/350
[2016-08-02 12:56:28] [#] Pokemon Storage: 234/250
[2016-08-02 12:56:28] [#] Stardust: 56617
[2016-08-02 12:56:28] [#] Pokecoins: 0
[2016-08-02 12:56:28] [#] PokeBalls: 19
[2016-08-02 12:56:28] [#] GreatBalls: 3
[2016-08-02 12:56:28] [#] UltraBalls: 0
[2016-08-02 12:56:28] [#] -- Level: 16
[2016-08-02 12:56:28] [#] -- Experience: 137823
[2016-08-02 12:56:28] [#] -- Experience until next level: 2177
[2016-08-02 12:56:28] [#] -- Pokemon Captured: 430
[2016-08-02 12:56:28] [#] -- Pokestops Visited: 322
[2016-08-02 12:56:28] [#]
Traceback (most recent call last):
File "pokecli.py", line 220, in
main()
File "pokecli.py", line 206, in main
bot.start()
File "/Users/tr/PokemonGo-Bot/pokemongo_bot/init.py", line 32, in start
self.stepper = Stepper(self)
File "/Users/tr/PokemonGo-Bot/pokemongo_bot/stepper.py", line 32, in init
self.origin_lat = self.bot.position[0]
AttributeError: 'PokemonGoBot' object has no attribute 'position'
Steps to Reproduce
just type python pokecli.py
Other Information
OS: OS X YOSEMITE
Git Commit:
Python Version: 2.7

Did you checkout to dev?

@Marco208 meaning? Confused, sorry

That location is likely not precise enough -- a tenth of a degree in latitude is huge -- roughly 6.9 miles.

Location precision is not an issue, tried it to varying degrees of distance

What is the most precise you've tried?  Also, what commit, and what Python version?

Down to exactly what google says

I had the error changing my location (since last commit few mins ago to include the new pgoapi), I used another precision (less accurate) and stopped working, I used this format, and it should work for you too:
"location": "43.3696709, -8.396026, 17"
Regards.

Starting over with yungfrancis addition, will let you know!

@yungfrancis You the man, what location is that?
WORKS.

@HelloTroy haha, cheers bud, A Coruña, Spain ;)

@yungfrancis what does the number 17 at the end mean?

@zchen1018 altitude


Roll Flutter Engine from 7b91f9d08f2c to ebc8b049f5eb (2 revisions)

https://github.com/flutter/engine/compare/7b91f9d08f2c...ebc8b049f5eb
2023-03-24<EMAIL_ADDRESS>Listen to WM_CLOSE message on Windows to allow framework to cancel exit (flutter/engine#40493)
2023-03-24<EMAIL_ADDRESS>[web] Migrate canvaskit_api to JS types.(#40538)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC bdero@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Put freestanding init decls in a test into a type.

Even though these aren't semantically valid Swift, these parse correctly
with the 9/26 snapshot we're currently on. At a more recent commit we
noticed that these inits seem to be hitting a code path that causes an
assertion in the parser:
assertion failed in swift::Type swift::ValueDecl::getInterfaceType() const:
ctx.getLegacyGlobalTypeChecker() && "The type checker must be installed to
make semantic queries!"

We should try to pinpoint this crash, but for now I'm patching this so
that the test is more "correct" and it unblocks some of our internal work.

\cc @nathawes could you take a look?

@allevato Are you still seeing this after the changes in https://github.com/apple/swift/pull/28226? That fixed several cases where we were hitting this assertion in SourceKit's syntactic requests so might fix this too.

@nathawes Thanks for the link. I first wanted to grab the 2019-11-11 trunk snapshot (the snapshot that Swift for TensorFlow's branch was last rebased on, before your patch) to verify failure, but I wasn't able to reproduce my issue using either SwiftSyntax or -frontend -emit-syntax from the command line.
Digging a little deeper, I think this might be a result of a subtlety in Google's internal Bazel build for libswiftSyntaxParser; we're not defining SWIFT_BUILD_ONLY_SYNTAXPARSERLIB because we can't change configurations for the same build targets based on who depends on them, so the parser we build ends up with some real code paths in libAST instead of the #if SWIFT_BUILD_ONLY_SYNTAXPARSERLIB-guarded early-returns that are there. I'm wondering if one of those code paths was triggering the assertion.
Since this might be related to our weird setup, I'll have to wait until Swift for TensorFlow rebases on top of your change and see if the old inits still fail, and look into addressing the issue with our build targets so that we define the proper preprocessor symbols to avoid this again (if that is indeed the problem).

Actually the SWIFT_BUILD_ONLY_SYNTAXPARSERLIB is not defined in any of the builds that Swift CI produces, currently we only use that internally.

So much for that theory then! Indeed, I just tried defining that symbol universally in our internal build as a quick test and it didn't make the issue go away, so I'm glad I'm wrong because it means I don't have to rearrange all those build targets.
Anyway, @nathawes' patch was small enough that I could apply it on top of our internal copy of the toolchain and I can verify that that did fix the issue; the tests passed again with the surrounding type removed from the initializers. Thanks!


NoBreakCommentFixer - fix for "default" in "match"

Fixes https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/5797

Coverage decreased (-0.004%) to 91.568% when pulling 874bf1ce1e1a84c6f6cbf527aaa03b79fcf8da87 on kubawerlos:fix_NoBreakCommentFixer into bddb80c8a5d9e64e91f8d15e0087c3ee3d44ba7d on FriendsOfPHP:2.19.

Thank you @kubawerlos.


Dev

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.4 out of 6 committers have signed the CLA.:white_check_mark: agnelpraveen:white_check_mark: aniruddha-k:white_check_mark: shalini-peeka:white_check_mark: boonbaluri:x: SHPEEKA:x: venkat-99SHPEEKA seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Remove the reflective lookup of json serializers.

Libraries should enforce minimal proguard rules
This PR transitions the reflection lookup of serializers to explicit serializers
Added bonus: Increased performance due to no need for reflective class lookups

It looks good for me


Update link

Fixes #28330

@Potapy4 : Thanks for your contribution! The author, @mlottner, has been notified to review your proposed change.

#sign-off


Missing Card Animation

I went through the website and want to raid this issue, that when we hover over the cards, they just pop out suddenly which provide less attractive UX.
So, I want to work to enhance the animations of cards and other small details.
@lovishprabhakar

Go ahead @hs-07!

@hs-07 updates?

@lovishprabhakar
yaa , just working over the  issue, got stuck in some other stuffs.

PR Made ,
kindly have a look and ping me if any changes required. @lovishprabhakar


OpenBLAS 0.3.13 fails to build on ppc64le / gcc 8.2

I'm building OpenBLAS 0.3.13 using Spack on a POWER8 machine running Debian 10.
Build fails because of the new POWER10 dynamic support:
==> Error: ProcessError: Command exited with status 2:
    'make' '-j16' 'CC=/grid5000/spack/lib/spack/env/gcc/gcc' 'FC=/grid5000/spack/lib/spack/env/gcc/gfortran' 'MAKE_NB_JOBS=0' 'DYNAMIC_ARCH=1' 'USE_OPENMP=0' 'USE_THREAD=0' 'RANLIB=ranlib' 'libs' 'netlib' 'shared'

2 errors found in build log:
     1190    /grid5000/spack/lib/spack/env/gcc/gcc -O2 -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DNO_WARMUP -DMAX_CPU_NUMBER=160 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=
             1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.13\" -Ofast -mcpu=power8 -mtune=power8 -mvsx  -fno-fast-math -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=openblas_env -DASMFNAME=openblas_env_ -DNAME=openblas_
             env_ -DCNAME=openblas_env -DCHAR_NAME=\"openblas_env_\" -DCHAR_CNAME=\"openblas_env\" -DNO_AFFINITY -I../.. -c openblas_env.c -o openblas_env.o
     1191    /grid5000/spack/lib/spack/env/gcc/gcc -O2 -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DNO_WARMUP -DMAX_CPU_NUMBER=160 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=
             1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.13\" -Ofast -mcpu=power8 -mtune=power8 -mvsx  -fno-fast-math -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=dynamic_power -DASMFNAME=dynamic_power_ -DNAME=dynamic
             _power_ -DCNAME=dynamic_power -DCHAR_NAME=\"dynamic_power_\" -DCHAR_CNAME=\"dynamic_power\" -DNO_AFFINITY -I../..   -c -o dynamic_power.o dynamic_power.c
     1192    dynamic_power.c:9:1: warning: multi-line comment [-Wcomment]
     1193     //#if (!defined __GNUC__) || ( __GNUC__ >= 11) \
     1194     ^
     1195    dynamic_power.c: In function 'gotoblas_dynamic_init':
  >> 1196    dynamic_power.c:57:6: error: cpu 'power10' is an invalid argument to builtin '__builtin_cpu_is'
     1197      if (__builtin_cpu_is("power10"))
     1198          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> 1199    make[1]: *** [<builtin>: dynamic_power.o] Error 1
     1200    make[1]: *** Waiting for unfinished jobs....
     1201    make[1]: Leaving directory '/var/spack/stage/root/spack-stage-openblas-0.3.13-57p57xjbiiv757vjq4uickpldoq4vcfy/spack-src/driver/others'
     1202    make: *** [Makefile:165: libs] Error 1

Here are the versions:
# gcc --version
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# ld --version
GNU ld (GNU Binutils for Debian) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

I browsed other issues, and as far as I can tell, POWER10 support is supposed to be disabled with old versions of GCC. Not sure what's up.

Looks like fallout from #2994 (and yes RajalakshmiSR warned about this happening, I should not have merged antonblanchard's PR without further clarification from him probably. This did not come up in my tests back then though)

Looks like fallout from #2994 (and yes RajalakshmiSR warned about this happening, I should not have merged antonblanchard's PR without further clarification from him probably. This did not come up in my tests back then though)

FYI, 0.3.12 builds fine (also using Spack, on the same POWER8 host).
I assume you already have access to POWER machines, but just in case, the GCC compile farm has several hw/sw POWER environments to test things: https://cfarm.tetaneutral.net/

FYI, 0.3.12 builds fine (also using Spack, on the same POWER8 host).
I assume you already have access to POWER machines, but just in case, the GCC compile farm has several hw/sw POWER environments to test things: https://cfarm.tetaneutral.net/

Thx, I'm allowed to use the OpenPOWER minicloud at unicamp.br

Thx, I'm allowed to use the OpenPOWER minicloud at unicamp.br

@martin-frbg  Should we just back out 2994 for now?

@martin-frbg  Should we just back out 2994 for now?

Either that, or put another gcc version check for >=11 around that __builtin_cpu_is() call. The other change in #2994 looked more important, and I can only assume I got fixated on whether "cc -Wl,--version" was actually safer than "ld --version".

Either that, or put another gcc version check for >=11 around that __builtin_cpu_is() call. The other change in #2994 looked more important, and I can only assume I got fixated on whether "cc -Wl,--version" was actually safer than "ld --version".

@jonglezb You posted debian compiler version, does not matter, no released gcc would work.
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/gcc/package.py

@jonglezb You posted debian compiler version, does not matter, no released gcc would work.
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/gcc/package.py

Actually gcc 10.2 would work, as RajalakshmiSR pointed out to me in #3075 the relevant gcc patch was backported from mainline shortly before its release.

Actually gcc 10.2 would work, as RajalakshmiSR pointed out to me in #3075 the relevant gcc patch was backported from mainline shortly before its release.

Thanks, I just tested a build from the develop branch and it builds fine!

Thanks, I just tested a build from the develop branch and it builds fine!


Not compatible with Python 3.7?

I tried to install with with conda, but get this problems:
UnsatisfiableError: The following specifications were found to be incompatible with the existing python installation in your environment:
Specifications:

tox-pyenv -> python[version='>=3.6,<3.7.0a0']
Your python: python=3.7

I did not specifically exclude python > 3.6 ...
Is there something I need to do to allow for use with python 3.6/7 ?


Immediate Window in Python projects prints too much data

This issue has been moved from a ticket on Developer Community.

[severity:I'm unable to use this version] [regression] [worked-in:16.7]
If I debug a Python project and hit a breakpoint, I often use the Immediate Window to display different values. For instance, if I type 's' and press the Enter key, it prints 's'. However, if I type 1, 2, 3 and press the Enter key, it prints (1, 2, 3) but also prints 37 lines of useless data and I must to scroll up to see that first line:
    count: <built-in method count of tuple object at 0x0000015347C1E688>
    index: <built-in method index of tuple object at 0x0000015347C1E688>
    __add__: <method-wrapper '__add__' of tuple object at 0x0000015347C1E688>
    __class__: <class 'tuple'>
    __contains__: <method-wrapper '__contains__' of tuple object at 0x0000015347C1E688>
    __delattr__: <method-wrapper '__delattr__' of tuple object at 0x0000015347C1E688>
    __dir__: <built-in method __dir__ of tuple object at 0x0000015347C1E688>
    __doc__: "Built-in immutable sequence.\n\nIf no argument is given, the constructor returns an empty tuple.\nIf iterable is specified the tuple is initialized from iterable's items.\n\nIf the argument is a tuple, the return value is the same object."
    __eq__: <method-wrapper '__eq__' of tuple object at 0x0000015347C1E688>
    __format__: <built-in method __format__ of tuple object at 0x0000015347C1E688>
    __ge__: <method-wrapper '__ge__' of tuple object at 0x0000015347C1E688>
    __getattribute__: <method-wrapper '__getattribute__' of tuple object at 0x0000015347C1E688>
    __getitem__: <method-wrapper '__getitem__' of tuple object at 0x0000015347C1E688>
    __getnewargs__: <built-in method __getnewargs__ of tuple object at 0x0000015347C1E688>
    __gt__: <method-wrapper '__gt__' of tuple object at 0x0000015347C1E688>
    __hash__: <method-wrapper '__hash__' of tuple object at 0x0000015347C1E688>
    __init__: <method-wrapper '__init__' of tuple object at 0x0000015347C1E688>
    __init_subclass__: <built-in method __init_subclass__ of type object at 0x00007FFBE48B6810>
    __iter__: <method-wrapper '__iter__' of tuple object at 0x0000015347C1E688>
    __le__: <method-wrapper '__le__' of tuple object at 0x0000015347C1E688>
    __len__: <method-wrapper '__len__' of tuple object at 0x0000015347C1E688>
    __lt__: <method-wrapper '__lt__' of tuple object at 0x0000015347C1E688>
    __mul__: <method-wrapper '__mul__' of tuple object at 0x0000015347C1E688>
    __ne__: <method-wrapper '__ne__' of tuple object at 0x0000015347C1E688>
    __new__: <built-in method __new__ of type object at 0x00007FFBE48B6810>
    __reduce__: <built-in method __reduce__ of tuple object at 0x0000015347C1E688>
    __reduce_ex__: <built-in method __reduce_ex__ of tuple object at 0x0000015347C1E688>
    __repr__: <method-wrapper '__repr__' of tuple object at 0x0000015347C1E688>
    __rmul__: <method-wrapper '__rmul__' of tuple object at 0x0000015347C1E688>
    __setattr__: <method-wrapper '__setattr__' of tuple object at 0x0000015347C1E688>
    __sizeof__: <built-in method __sizeof__ of tuple object at 0x0000015347C1E688>
    __str__: <method-wrapper '__str__' of tuple object at 0x0000015347C1E688>
    __subclasshook__: <built-in method __subclasshook__ of type object at 0x00007FFBE48B6810>
    0: 1
    1: 2
    2: 3
    len(): 3

While it's true it prints the items of a tuple at the end also, they are arranged vertically so long tuples scroll out of view and it will print only those items it knows how to convert to a string. If I import numpy with import numpy as np and type 1, np.ndarray in the Immediate Window and press the Enter key, it prints the following as the last two lines.
    0: 1
    len(): 2

Although I highlighted the behavior with tuples, it happens with all non-primitive values. For instance, if I type np.ndarray in the Immediate Window and press the Enter key, it prints <class 'numpy.ndarray'>, which is useful and expected, followed by 105 lines of useless, unexpected data.
    T: <attribute 'T' of 'numpy.ndarray' objects>
    all: <method 'all' of 'numpy.ndarray' objects>
    any: <method 'any' of 'numpy.ndarray' objects>
    argmax: <method 'argmax' of 'numpy.ndarray' objects>
    argmin: <method 'argmin' of 'numpy.ndarray' objects>
    argpartition: <method 'argpartition' of 'numpy.ndarray' objects>
    argsort: <method 'argsort' of 'numpy.ndarray' objects>
    astype: <method 'astype' of 'numpy.ndarray' objects>
    base: <attribute 'base' of 'numpy.ndarray' objects>
    byteswap: <method 'byteswap' of 'numpy.ndarray' objects>
    choose: <method 'choose' of 'numpy.ndarray' objects>
    clip: <method 'clip' of 'numpy.ndarray' objects>
    compress: <method 'compress' of 'numpy.ndarray' objects>
    conj: <method 'conj' of 'numpy.ndarray' objects>
    conjugate: <method 'conjugate' of 'numpy.ndarray' objects>
    copy: <method 'copy' of 'numpy.ndarray' objects>
    ctypes: <attribute 'ctypes' of 'numpy.ndarray' objects>
    cumprod: <method 'cumprod' of 'numpy.ndarray' objects>
    cumsum: <method 'cumsum' of 'numpy.ndarray' objects>
    data: <attribute 'data' of 'numpy.ndarray' objects>
    diagonal: <method 'diagonal' of 'numpy.ndarray' objects>
    dot: <method 'dot' of 'numpy.ndarray' objects>
    dtype: <attribute 'dtype' of 'numpy.ndarray' objects>
    dump: <method 'dump' of 'numpy.ndarray' objects>
    dumps: <method 'dumps' of 'numpy.ndarray' objects>
    fill: <method 'fill' of 'numpy.ndarray' objects>
    flags: <attribute 'flags' of 'numpy.ndarray' objects>
    flat: <attribute 'flat' of 'numpy.ndarray' objects>
    flatten: <method 'flatten' of 'numpy.ndarray' objects>
    getfield: <method 'getfield' of 'numpy.ndarray' objects>
    imag: <attribute 'imag' of 'numpy.ndarray' objects>
    item: <method 'item' of 'numpy.ndarray' objects>
    itemset: <method 'itemset' of 'numpy.ndarray' objects>
    itemsize: <attribute 'itemsize' of 'numpy.ndarray' objects>
    max: <method 'max' of 'numpy.ndarray' objects>
    mean: <method 'mean' of 'numpy.ndarray' objects>
    min: <method 'min' of 'numpy.ndarray' objects>
    nbytes: <attribute 'nbytes' of 'numpy.ndarray' objects>
    ndim: <attribute 'ndim' of 'numpy.ndarray' objects>
    newbyteorder: <method 'newbyteorder' of 'numpy.ndarray' objects>
    nonzero: <method 'nonzero' of 'numpy.ndarray' objects>
    partition: <method 'partition' of 'numpy.ndarray' objects>
    prod: <method 'prod' of 'numpy.ndarray' objects>
    ptp: <method 'ptp' of 'numpy.ndarray' objects>
    put: <method 'put' of 'numpy.ndarray' objects>
    ravel: <method 'ravel' of 'numpy.ndarray' objects>
    real: <attribute 'real' of 'numpy.ndarray' objects>
    repeat: <method 'repeat' of 'numpy.ndarray' objects>
    reshape: <method 'reshape' of 'numpy.ndarray' objects>
    resize: <method 'resize' of 'numpy.ndarray' objects>
    round: <method 'round' of 'numpy.ndarray' objects>
    searchsorted: <method 'searchsorted' of 'numpy.ndarray' objects>
    setfield: <method 'setfield' of 'numpy.ndarray' objects>
    setflags: <method 'setflags' of 'numpy.ndarray' objects>
    shape: <attribute 'shape' of 'numpy.ndarray' objects>
    size: <attribute 'size' of 'numpy.ndarray' objects>
    sort: <method 'sort' of 'numpy.ndarray' objects>
    squeeze: <method 'squeeze' of 'numpy.ndarray' objects>
    std: <method 'std' of 'numpy.ndarray' objects>
    strides: <attribute 'strides' of 'numpy.ndarray' objects>
    sum: <method 'sum' of 'numpy.ndarray' objects>
    swapaxes: <method 'swapaxes' of 'numpy.ndarray' objects>
    take: <method 'take' of 'numpy.ndarray' objects>
    tobytes: <method 'tobytes' of 'numpy.ndarray' objects>
    tofile: <method 'tofile' of 'numpy.ndarray' objects>
    tolist: <method 'tolist' of 'numpy.ndarray' objects>
    tostring: <method 'tostring' of 'numpy.ndarray' objects>
    trace: <method 'trace' of 'numpy.ndarray' objects>
    transpose: <method 'transpose' of 'numpy.ndarray' objects>
    var: <method 'var' of 'numpy.ndarray' objects>
    view: <method 'view' of 'numpy.ndarray' objects>
    __abs__: <slot wrapper '__abs__' of 'numpy.ndarray' objects>
    __add__: <slot wrapper '__add__' of 'numpy.ndarray' objects>
    __and__: <slot wrapper '__and__' of 'numpy.ndarray' objects>
    __array__: <method '__array__' of 'numpy.ndarray' objects>
    __array_finalize__: <attribute '__array_finalize__' of 'numpy.ndarray' objects>
    __array_function__: <method '__array_function__' of 'numpy.ndarray' objects>
    __array_interface__: <attribute '__array_interface__' of 'numpy.ndarray' objects>
    __array_prepare__: <method '__array_prepare__' of 'numpy.ndarray' objects>
    __array_priority__: <attribute '__array_priority__' of 'numpy.ndarray' objects>
    __array_struct__: <attribute '__array_struct__' of 'numpy.ndarray' objects>
    __array_ufunc__: <method '__array_ufunc__' of 'numpy.ndarray' objects>
    __array_wrap__: <method '__array_wrap__' of 'numpy.ndarray' objects>
    __bool__: <slot wrapper '__bool__' of 'numpy.ndarray' objects>
    __class__: <class 'type'>
    __complex__: <method '__complex__' of 'numpy.ndarray' objects>
    __contains__: <slot wrapper '__contains__' of 'numpy.ndarray' objects>
    __copy__: <method '__copy__' of 'numpy.ndarray' objects>
    __deepcopy__: <method '__deepcopy__' of 'numpy.ndarray' objects>
    __delattr__: <slot wrapper '__delattr__' of 'object' objects>
    __delitem__: <slot wrapper '__delitem__' of 'numpy.ndarray' objects>
    __dir__: <method '__dir__' of 'object' objects>
    __divmod__: <slot wrapper '__divmod__' of 'numpy.ndarray' objects>
    __doc__: 'ndarray(shape, dtype=float, buffer=None, offset=0,\n            strides=None, order=None)\n\n    An array object represents a multidimensional, homogeneous array\n    of fixed-size items.  An associated data-type object describes the\n    format of each element in the array (its byte-order, how many bytes it\n    occupies in memory, whether it is an integer, a floating point number,\n    or something else, etc.)\n\n    Arrays should be constructed using `array`, `zeros` or `empty` (refer\n    to the See Also section below).  The parameters given here refer to\n    a low-level method (`ndarray(...)`) for instantiating an array.\n\n    For more information, refer to the `numpy` module and examine the\n    methods and attributes of an array.\n\n    Parameters\n    ----------\n    (for the __new__ method; see Notes below)\n\n    shape : tuple of ints\n        Shape of created array.\n    dtype : data-type, optional\n        Any object that can be interpreted as a numpy data type.\n    buffer : object
 exposing buffer interface, optional\n        Used to fill the array with data.\n    offset : int, optional\n        Offset of array data in buffer.\n    strides : tuple of ints, optional\n        Strides of data in memory.\n    order : {\'C\', \'F\'}, optional\n        Row-major (C-style) or column-major (Fortran-style) order.\n\n    Attributes\n    ----------\n    T : ndarray\n        Transpose of the array.\n    data : buffer\n        The array\'s elements, in memory.\n    dtype : dtype object\n        Describes the format of the elements in the array.\n    flags : dict\n        Dictionary containing information related to memory use, e.g.,\n        \'C_CONTIGUOUS\', \'OWNDATA\', \'WRITEABLE\', etc.\n    flat : numpy.flatiter object\n        Flattened version of the array as an iterator.  The iterator\n        allows assignments, e.g., ``x.flat = 3`` (See `ndarray.flat` for\n        assignment examples; TODO).\n    imag : ndarray\n        Imaginary part of the array.\n    real : ndarray\n        Real part o
f the array.\n    size : int\n        Number of elements in the array.\n    itemsize : int\n        The memory use of each array element in bytes.\n    nbytes : int\n        The total number of bytes required to store the array data,\n        i.e., ``itemsize * size``.\n    ndim : int\n        The array\'s number of dimensions.\n    shape : tuple of ints\n        Shape of the array.\n    strides : tuple of ints\n        The step-size required to move from one element to the next in\n        memory. For example, a contiguous ``(3, 4)`` array of type\n        ``int16`` in C-order has strides ``(8, 2)``.  This implies that\n        to move from element to element in memory requires jumps of 2 bytes.\n        To move from row-to-row, one needs to jump 8 bytes at a time\n        (``2 * 4``).\n    ctypes : ctypes object\n        Class containing properties of the array needed for interaction\n        with ctypes.\n    base : ndarray\n        If the array is a view into another array, that array is its `base`\n
  (unless that array is also a view).  The `base` array is where the\n        array data is actually stored.\n\n    See Also\n    --------\n    array : Construct an array.\n    zeros : Create an array, each element of which is zero.\n    empty : Create an array, but leave its allocated memory unchanged (i.e.,\n            it contains "garbage").\n    dtype : Create a data-type.\n\n    Notes\n    -----\n    There are two modes of creating an array using ``__new__``:\n\n    1. If `buffer` is None, then only `shape`, `dtype`, and `order`\n       are used.\n    2. If `buffer` is an object exposing the buffer interface, then\n       all keywords are interpreted.\n\n    No ``__init__`` method is needed because the array is fully initialized\n    after the ``__new__`` method.\n\n    Examples\n    --------\n    These examples illustrate the low-level `ndarray` constructor.  Refer\n    to the `See Also` section above for easier ways of constructing an\n    ndarray.\n\n    First mode, `buffer` is None:\n\n    >>> np.nda
rray(shape=(2,2), dtype=float, order=\'F\')\n    array([[ -1.13698227e+002,   4.25087011e-303],\n           [  2.88528414e-306,   3.27025015e-309]])         #random\n\n    Second mode:\n\n    >>> np.ndarray((2,), buffer=np.array([1,2,3]),\n    ...            offset=np.int_().itemsize,\n    ...            dtype=int) # offset = 1*itemsize, i.e. skip first element\n    array([2, 3])'
    __eq__: <slot wrapper '__eq__' of 'numpy.ndarray' objects>
    __float__: <slot wrapper '__float__' of 'numpy.ndarray' objects>
    __floordiv__: <slot wrapper '__floordiv__' of 'numpy.ndarray' objects>
    __format__: <method '__format__' of 'numpy.ndarray' objects>
    __ge__: <slot wrapper '__ge__' of 'numpy.ndarray' objects>
    __getattribute__: <slot wrapper '__getattribute__' of 'object' objects>
    < More... (The first 100 of 162 items were displayed.) >

While this new behavior might be useful to some in some situations, I has not yet proven useful to me in any situation. I'd like to at least have the option for the Immediate Window to display only the value of what I type, excluding all of the additional data about that value.

Original Comments
Feedback Bot on 11/25/2020, 09:00 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Yingying Zhang [MSFT] on 12/16/2020, 09:10 PM:
Sorry, we don’t know what you want to do through the window.
The Immediate window is used to debug and evaluate expressions, execute statements, and print variable values.
If you want to print variable values, you can use “>Debug.Print varA” or “? varA”
If you want execute some command, please enter the greater than sign (>).
Here is the doc about how to use Immediate window:
https://docs.microsoft.com/en-us/visualstudio/ide/reference/immediate-window?view=vs-2019
Feedback Bot on 12/29/2020, 08:56 PM:
We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.
Mark Kotwicz Herniczek on 1/5/2021, 02:23 PM:
I'm having the same issue. It doesn't occur when checking the value of simple variables but it is very inconvenient when dealing with structures such as lists or numpy arrays. For example, if I have an array and I want to display it using "arrA" or "? arrA", much more than just the array values are printed.The situation is even worse when checking attributes of arrays ("arrA.shape" for example), where every built-in method is first printed before the desired information is shown. The immediate window worked as desired in the past as the author mentioned.An example of interaction with the immediate window is shown below:input:x = [1,2]? xoutput:[1, 2]
    append: <built-in method append of list object at 0x0000028034B8CE48>
    clear: <built-in method clear of list object at 0x0000028034B8CE48>
    copy: <built-in method copy of list object at 0x0000028034B8CE48>
    count: <built-in method count of list object at 0x0000028034B8CE48>
    extend: <built-in method extend of list object at 0x0000028034B8CE48>
    index: <built-in method index of list object at 0x0000028034B8CE48>
    insert: <built-in method insert of list object at 0x0000028034B8CE48>
    pop: <built-in method pop of list object at 0x0000028034B8CE48>
    remove: <built-in method remove of list object at 0x0000028034B8CE48>
    reverse: <built-in method reverse of list object at 0x0000028034B8CE48>
    sort: <built-in method sort of list object at 0x0000028034B8CE48>
    __add__: <method-wrapper '__add__' of list object at 0x0000028034B8CE48>
    __class__: <class 'list'>
    __contains__: <method-wrapper '__contains__' of list object at 0x0000028034B8CE48>
    __delattr__: <method-wrapper '__delattr__' of list object at 0x0000028034B8CE48>
    __delitem__: <method-wrapper '__delitem__' of list object at 0x0000028034B8CE48>
    __dir__: <built-in method __dir__ of list object at 0x0000028034B8CE48>
    __doc__: 'Built-in mutable sequence.\n\nIf no argument is given, the constructor creates a new empty list.\nThe argument must be an iterable if specified.'
    __eq__: <method-wrapper '__eq__' of list object at 0x0000028034B8CE48>
    __format__: <built-in method __format__ of list object at 0x0000028034B8CE48>
    __ge__: <method-wrapper '__ge__' of list object at 0x0000028034B8CE48>
    __getattribute__: <method-wrapper '__getattribute__' of list object at 0x0000028034B8CE48>
    __getitem__: <built-in method __getitem__ of list object at 0x0000028034B8CE48>
    __gt__: <method-wrapper '__gt__' of list object at 0x0000028034B8CE48>
    __hash__: None
    __iadd__: <method-wrapper '__iadd__' of list object at 0x0000028034B8CE48>
    __imul__: <method-wrapper '__imul__' of list object at 0x0000028034B8CE48>
    __init__: <method-wrapper '__init__' of list object at 0x0000028034B8CE48>
    __init_subclass__: <built-in method __init_subclass__ of type object at 0x00007FFF2B954D30>
    __iter__: <method-wrapper '__iter__' of list object at 0x0000028034B8CE48>
    __le__: <method-wrapper '__le__' of list object at 0x0000028034B8CE48>
    __len__: <method-wrapper '__len__' of list object at 0x0000028034B8CE48>
    __lt__: <method-wrapper '__lt__' of list object at 0x0000028034B8CE48>
    __mul__: <method-wrapper '__mul__' of list object at 0x0000028034B8CE48>
    __ne__: <method-wrapper '__ne__' of list object at 0x0000028034B8CE48>
    __new__: <built-in method __new__ of type object at 0x00007FFF2B954D30>
    __reduce__: <built-in method __reduce__ of list object at 0x0000028034B8CE48>
    __reduce_ex__: <built-in method __reduce_ex__ of list object at 0x0000028034B8CE48>
    __repr__: <method-wrapper '__repr__' of list object at 0x0000028034B8CE48>
    __reversed__: <built-in method __reversed__ of list object at 0x0000028034B8CE48>
    __rmul__: <method-wrapper '__rmul__' of list object at 0x0000028034B8CE48>
    __setattr__: <method-wrapper '__setattr__' of list object at 0x0000028034B8CE48>
    __setitem__: <method-wrapper '__setitem__' of list object at 0x0000028034B8CE48>
    __sizeof__: <built-in method __sizeof__ of list object at 0x0000028034B8CE48>
    __str__: <method-wrapper '__str__' of list object at 0x0000028034B8CE48>
    __subclasshook__: <built-in method __subclasshook__ of type object at 0x00007FFF2B954D30>
    0: 1
    1: 2
    len(): 2

Original Solutions
(no solutions)

Duplicate of #6342

Duplicate of #6342


Reopen Ar-world after hide

It's me again!
After calling 'Ionicitude.hide();', it won't open the Ar-world. This is only happening on Android.
Ionicitude.init()
  .then(function () {
    Ionicitude.addAction(close);
  })
  .catch(function (error) {
  });
  function close() {
    Ionicitude.hide();
  }
});

When I run the command 'launcAr('world')' this is the console in android studio:
D/ViewRootImpl: ViewPostImeInputStage processPointer 0
D/ViewRootImpl: ViewPostImeInputStage processPointer 1
I/chromium: [INFO:CONSOLE(340)] "launch", source: file:///android_asset/www/lib/ionicitude/dist/ionicitude.js (340)
First launch is running perfectly!

Well...
That's an interesting one.
I'm going to have to run some tests but I won't be able to help you on this one for a few days: I'm on vacation, away from my work computer.
Anyway, normally, to "relaunch" a previously hidden world, you should call Ionicitude.show() rather than lauching it again.

Did you understand this issue?
I also have an issue with the Ionicitude.close() function. It does not respond.
Ionicitude.hide() works!

I have the same issues when using Ionicitude.close()
I get "Function required as first argument!" at file: lib/ionic/js/ionic.bundle.js (26794)
and when I call show() after hide() nothing happens

Hi!
Could you give me a little more detail regarding the context of your Ionicitude.close() call?
This method of the service does nothing more than calling the Wikitude's native close() function.
So in all honesty, I have no idea what's causing this issue ^^
Especially with an error message like the one you have, since close() doesn't require any argument.

 La fonction Ionicitude ne réagit pas

Mh not really funny thing is when I call WikitudePlugin.close() it works not sure whats the problem here

Do you call Ionicitude.close () inside an action, like this?
Ionicitude.addAction (myAction);

function myAction () {
  Ionicitude.close ();
}

If it's the case, try using the service argument instead, that is passed to an action when it is called:
Ionicitude.addAction (myAction);

function myAction (service) {
  service.close ();
}

Gonna try it on monday thank You very much

Did You already Experiment with the wikitude Plugin API?

Hum... not sure to understand what you mean by that.


General CLI improvements: dumping, upgrade clap, yaml config, serialize IR, bump versions, etc

Changes

feat: --dump option to inspect config and IR
feat: upgrade to clap v4, read config from .yml file

reads from .frb.yml, .frb.yaml and .frb.json

fix: compile CLI without chrono feature
feat: implement Serialize for IR structs

guarded behind serde feature

fix(ci): bump MSRV to satisfy cargo-ndk
feat: reanchor paths when parsed from yaml

Checklist

[ ] An issue to be fixed by this PR is listed above.
[ ] New tests are added to ensure new features are working. End-to-end tests are usually in the ./frb_example/pure_dart example, more specifically, rust/src/api.rs and dart/lib/main.dart.
[x] The code generator is run and the code is formatted (via just precommit).
[x] If this PR adds/changes features, documentations (in the ./book folder) are updated.
[x] CI is passing.

Remark for PR creator

Justfile is a task runner for the command line interface that allows you to run shell commands from a file named justfile in your project directory. You can use Justfile after installing it. Note that commands written in justfile of this repository are expected to be run in bash, not cmd or powershell. Running just ... commands in cmd or powershell will produce errors as the syntax is not compatible. On Windows, you can use git bash if you have Git installed.
If fzyzcjy does not reply for a few days, maybe he just did not see it, so please ping him.

Preferably I'd have liked to have this usage line:
flutter_rust_bridge_codegen [CONFIG_FILE]
flutter_rust_bridge_codegen --rust-input <RUST_INPUT> --dart_input <DART_INPUT> [OPTIONS]

But I'm not very good at clap-foo, it's not a dealbreaker but if anyone knows how to accomplish this it would be wonderful.

After CI goes green, I think it's a good stopping point to merge.

Good job!


KeyError token

Hi!
Install worked fine (Version 1.0.16)
settings.py
DEBUG = False

PLUGINS = [
    'mattermost_bot.plugins',
]
PLUGINS_ONLY_DOC_STRING = False

BOT_URL = 'http://servername.domain.tld/api/v1'
BOT_LOGIN =<EMAIL_ADDRESS>BOT_PASSWORD = 'password'
BOT_TEAM = 'teamname'

IGNORE_NOTIFIES = ['@channel', '@all']
WORKERS_NUM = 10

Error
[root@ mattermost_bot-1.0.16]# matterbot /opt/appl/source_files/mattermos                                                        t_bot-1.0.16/mattermost_bot/settings.py
[06/01/2016 10:16:30] Starting new HTTP connection (1): siik.oebb.at
Traceback (most recent call last):
  File "/bin/matterbot", line 9, in <module>
    load_entry_point('mattermost-bot==1.0.16', 'console_scripts', 'matterbot')()
  File "/opt/appl/source_files/mattermost_bot-1.0.16/mattermost_bot/cli.py", lin                                                        e 17, in main
    b = bot.Bot()
  File "/opt/appl/source_files/mattermost_bot-1.0.16/mattermost_bot/bot.py", lin                                                        e 26, in __init__
    settings.BOT_LOGIN, settings.BOT_PASSWORD,
  File "/opt/appl/source_files/mattermost_bot-1.0.16/mattermost_bot/mattermost.p                                                        y", line 118, in __init__
    self.login(team, email, password)
  File "/opt/appl/source_files/mattermost_bot-1.0.16/mattermost_bot/mattermost.p                                                        y", line 122, in login
    self.user = self.api.login(team, email, password)
  File "/opt/appl/source_files/mattermost_bot-1.0.16/mattermost_bot/mattermost.p                                                        y", line 36, in login
    self.token = p.headers["Token"]
  File "/opt/appl/source_files/mattermost_bot-1.0.16/requests/structures.py", li                                                        ne 56, in __getitem__
    return self._store[key.lower()][1]
KeyError: 'token'

I tested the url -> works
I tested the user login with email and passwort -> works

Hi,
BOT_URL = 'http://servername.domain.tld/api/v3'