Add arg-less Time.utc constructor

This is a follow-up to #5321 which added the Time.utc constructor.
I think this constructor should allso be callable without arguments resembling Time.new with location UTC. You can use Time.new() for the current and Time.new(2017, 12, 4, 12, 51) for a specific time instance in local time. Time.utc(2017, 12, 4, 12, 51) and Time.utc() should be usable in the same way to get time instances in UTC.
There is already Time.utc_now which could stick around as an alias like Time.now for Time.new or we could remove it.

I think we should go the other way, remove the new with args. We'd end up with 2 constructor groups:
.new which take a specific moment in time, and now and utc_now which construct a time instance by consulting the system clock.

This would be equally consistent as my suggestion, but I'm not sure it would be wise to go this separate way. I believe it makes the API more complicated.
To me, it seems natural that calling a constructor of Time without any arguments returns an instance holding the default value, i.e. the current time. That's the way of the least surprise.
If we'd want to get rid off the alias, I'd rather lose Time.now - it's an additional method to remember and Time.new() comes just natural. This is even more true for the UTC variant: People shouldn't have to remember if it was Time.utc_now or Time.now_utc. Using just Time.utc is easier, shorter and equally expressive.

We should have Time.now take a timezone argument after #5324. It will return Time.now as if the current timezone was the same as the argument you pass in.
Then it's simple: Time.new for specifying a point in time which isn't now, Time.now for specifying now (just in a few seperate encodings).

Why force two names when one would be enough? We can have both Time.new(location = Location.local) and Time.new(year, month, day, hour, minute, second, location = Loation.loal) (that's already in #5324) and in the same manner Time.utc() and Time.utc(year, month, day, hour, minute, second). I'd take that for the smartest API.

On the flipside, why not have 2 names form doing 2 different things. Technically, both solutions are equal. I prefer to distinguish the two cases by name to make it clear what Time.new returns (now).

Time.utc_now always felt too long to me. I'll welcome renaming it to Time.utc.
Still on personal preference, I'd go for dropping the argless Time.new which duplicates Time.now.

Any other ideas about this? @RX14 what do you think about @ysbaddaden's suggestion to rename utc_now to utc which IMHO is a clear win because it is shorter and equally expressive? That's exactly what this PR is supposed to do (should utc_now be removed entirely or deprecated?). We could discuss new vs. now separately? Though I'm not sure if it would be benefitial to split off this discussion...

I don't think utc & utc_now are equally expressive by the name.. Time.utc doesn't sound like you're trying to get the current time to me.

What else would it mean? Maybe I'm just misguided by my past experience, but as far as I can remember, it is common practice in object oriented programming that if you create a time instance without any arguments it is initialized to represent the time at which it was created. For example Ruby Time.new, Java new Date(), JavaScript new Date(), PHP new DateTime(), Lua os.time() all operate in that way.
I don't see any benefit in adding now in the constructor because this should be evident when there is no value describing any specific time.

I still prefer this:

now
specified time

local
Time.now
Time.new

UTC
Time.utc_now
Time.utc

I'm welcome to rename these, but I'd like to keep separate names for each cell, with the UTC ones simply being aliases of the local ones with the kind pre-sepcified.

I was tripped up by this the other day because I thought Time.new would be utc. I think it would be clearer if we did something like this:

type
now
specific time

local
Time.local
Time.local(args)

UTC
Time.utc
Time.utc(args)

I could also see it being local_now and utc_now, but I like the idea of having local in the name so people know what they are getting. This could prevent a lot of timezone bugs

@paulcsmith This looks also interesting. I would certainly prefer that over having different names for current/specific instance.
But I am not sure if changing from new to local would help that much.
Generally, there is the issue that using new/local to create a specific time completely arbitrary in respect to incremental time. You can't know what the local time zone will be when this instance is created. It won't even reliably work if you're comparing different specifc time instances because the local time zone might change in between.
time_a = Time.new(2017, 12, 13, 21, 17)
# some code in between
time_b = Time.new(2017, 12, 13, 20, 17)

If nothing is changed in between time_a - time_b will equal 1.hour. If for example the code in between results in changing the TZ env var or the system's time zone is changed at some point, the result can vary about several hours, it might even be negative.
A safe way would be to store the time zone for reference later:
location = Time::Location.local
time_a = Time.new(2017, 12, 13, 21, 17, location: location)
# some code in between
time_b = Time.new(2017, 12, 13, 20, 17, location: location)

This would ensure that time_a - time_b equals 1.hour no matter what happens in between (apart from changing the local variable).
If you want to reference a specific point in incremental time, you can't use a constructor with implicit local location. I'm wondering if it should be supported at all... it would help avoid a lot of problems if you'd have to be explicit. If you wan't to reference a specific point in time, it should be expressed with an explicit time zone (preferably UTC to avoid potential ambiguity).
The "now" constructor with implicit location will always reference one specific point in incremental time. Several time instances created by Time.now can be compared without issues, it doesnt matter if the local time zone changed in between.

I really like the idea of always requiring a time zone. We ran into a few bugs because of this confusion. Making it explicit would have been a big help 👍

What do you think about the following constructors for Time:

location
current
calendrical
timestamp

specified
Time.local(location)
Time.local(year, month, day, hour, minute, second, nanosecond, location)
Time.local(seconds, nanoseconds, location)

local
Time.local
Time.local(year, month, day, hour, minute, second, nanosecond)
Time.local(seconds, nanoseconds)

UTC
Time.utc
Time.utc(year, month, day, hour, minute, second, nanosecond)
Time.utc(seconds, nanoseconds)

Besides that, there are still parser methods (parse, parse!, parse_local, parse_utc) and for UNIX timestamp (epoch, epoch_ms).
All in all, this would be pretty straightforward and easy to follow, having just two methods with different sets of arguments.
Instead of Time.local, all non-UTC methods could also be called Time.new but without location argument it is not explicit about which location it uses and this is bad as per @paulcsmith's argument. Time.local makes it clear that it constructs a local time instance.
An alternative would be to use Time.new for specific location. But I think it makes more sense to keep the same name for both and only differentiate by the presence of location argument (which default to local location).

Please don't merge seconds/nanoseconds timestamps with other constructors. It's confusing, and kinda internal detail.
What we want is a UNIX timestamp, easily usable for the common seconds / milliseconds form (others seem uncommon). I'm not fond of the epoch and epoch_ms namings, but at least they're somewhat descriptive —I'd use .unix I think.
I like the .local and .utc.

The seconds/nanoseconds constructors are currently exposed as .new(seconds, nanoseconds, location) and .utc(seconds, nanoseconds) so I think it makes sense to include them into the considerations. They resemble the internal representation, but this is quite important, because it is more performant than the calendrical constructor and allows to integrate extensions to the time API very easily (additionally, Time#total_seconds should be public for this).
I'm fine to leave them as is (.new/.utc) differently from the other discusses constructors. But it might seem a little bit inconsistent.
I agree that .epoch is not optimal, especially considering that epoch of Time is actually not Unix epoch  (1970-01-01) but 0001-01-01.

While following this suggestions, I noticed that throughout stdlib, very often Time.new() and Time.now() are used when they're not really necessary. In most cases it is just about retrieving a current time stamp and doesn't need any location attached. An obvious example is Time.now.epoch, which goes a long way to retrieve the current location (potentially reading from the file system) just to immediately discard it.
In my opinion this usage pattern supports renaming .new and .now to .local to make it more obvious for the developer to decide explicitly between utc and local instead of a generic new/now.

The seconds/nanoseconds constructors are currently exposed as .new(s, ns, location) and .utc(s, ns)

They're internal implementation details of Time and Time::Span; they should be either protected or tagged with :nodoc:. They may be faster to use now, but that's a side effect of exposing internal details; changing the internal API can break this assumption at any time (bad) or prevent changes to the internal API (bad).

Let's not bother with the seconds, nanoseconds constructor here, they're not even touched in this PR. I just included them in the overview to see how they could be changed (in a different PR).
This PR is about renaming Time.now/.newtoTime.localandTime.utc_nowtoTime.utc` to improve the API making it a little bit simpler, more expressive and in total easier to understand

This will be a massive breakage, but I guess it's fine. I liked Time.now but it's true that it's not clear whether that's local or UTC... that said, I always think of Time.now as local, so what was wrong with that?

I guess Time.now would just be an alias for Time.local 😛 Hence it adds more methods to learn and a little bit of uncertainty whether it's local time.
But that's not really a big issue and I would be totally fine with keeping (or re-adding) it as an alias.

Let's see what happens with this change in the next release. We are always experimenting so it's fine to try new ideas (I think it's a pretty radical change, but the idea of clarity is really good).

IMHO that's one of the few cases where I'd say such an alias would be desirable - there's nothing nice about breaking tons of code, or making steeper learning curve for people coming from Ruby-land.

One thing I love about Crystal is that there are fewer aliases than in Ruby. One thing we may want to consider is adding a helpful error when using Time.now to people know what they need to do:
def now
  {% raise "'Time.now' has been renamed to 'Time.local'" %}
end

This could also be down with the other methods that have been renamed to help people out.
This has worked well in Lucky so far because it's allowed us to keep things clean and focused but also help people find out what they need to do without looking at changelogs or asking for help. Thoughts?

local is a good and short name, let's deprecate nowfor a while.

@paulcsmith Nice error message or not, it still breaks the code nevertheless for very lil' gain. Apart from having less aliases than Ruby what I personally like in Crystal is striving for a balance between ideology (no aliases) and clean APIs (3.seconds.ago). I believe in importance of moderation (See Goldilocks principle), which is at stake when ideology is over-represented. Time.now intuitively implies locality, since when referring to now in most cases you'd think here and not now in Alaska or now in GMT but maybe that's just me...

I actually don't have a strong preference either way for now or local and I also love the idea of Goldilocks principle. But in general, fewer aliases is good IMO. And if we do remove now then I think having a good error message would be great.
FWIW I also think certain breakages are not a big deal. In this case all you need to do is a find and replace across your project and you're done. But really this suggestion is more about how to handle deprecations and removal to make things as easy as possible. In the past stuff has been renamed/moved and the only way to know was to check the changelog. Adding a nice error message at compile time would make it a lot easier to make changes to Crystal w/o causing too much trouble

My preferred way is to deprecate functionality with a compile time warning in one version, then remove it in a next version. That way you can upgrade, your code still compiles (and dependencies too), and eventually by the next version everything's working fine. The point about dependencies is really important.

Totally agree 👍  But even after the deprecation I think having the compile time error is nice.

@paulcsmith You mean, like, forever?

Depends on the method I think. If it is something that people might expect coming from another language, or that they often get wrong, then yeah I'd leave it forever. If it is something just in Crystal that has changed then I'm not sure. Maybe ~6 months?
SO for example. If we do keep Time.local and remove Time.now then yeah I'd leave some kind of compile time message like Please use Time.local or something`

Sorry, I can't help to think wouldn't be better to make Time.now an alias, instead of breaking peoples expectations and littering the codebase with compile-time warnings? I mean that's one alias, and the one many people know/is used to, why to over-complicate things?

Only at the beginning you would have compile-time warning. Then you change the method calls and they're gone. After that they raise errors (so new code would get an error and you'd fix it immediately). I think this is better than an alias for a few reasons:

You don't need to know two methods.
You don't need to wonder why a codebase sometimes uses Time.now and sometimes Time.local. Are they the same thing? Do they work slightly differently like ActiveRecord.size/count/length?

By having just one method you don't need to wonder why someone is using one or not the other. You never need to look it up.
I'd flip the question around. Why would you want an alias? Once everything is converted to the new method there is no long term benefit. The benefit is only short term. It makes upgrading Crystal easier.
I'd say right now Crystal is still in its early stages and we should not be adding aliases yet. Maybe if it were more mature it would be better to keep the alias around, but right now I think really nailing the API is key even if it means a bit of extra work for maintainers right now.

@paulcsmith These are good arguments, I'm convinced by lack of long-term benefits—other than familiarity to Ruby devs. In the short term it'll be a PITA and many under/not-maintained shards will suffer from that but oh well...

and many under/not-maintained shards will suffer from that

They're gonna break sooner or later anyway, so it's just making it break earlier. Which might even be a good thing because it makes people notice it's unmaintained.

Can the developers at Manas please step in and stop all these time changes?
It all started in November of 2018: https://crystal-lang.org/2018/11/01/crystal-0.27.0-released.html

Time keeps moving forward. In this release, there are breaking changes in favor of cleaner and more portable names. All references to “epoch” are be replaced by “unix”. Effectively: Time#epoch was renamed to Time#to_unix, #epoch_ms to #to_unix_ms, and #epoch_f to #to_unix_f. Read more at #6662.

In the beginning Time.now.epoch_ms was used, it made perfect sense (amount of milliseconds since the Unix epoch).  This change didn't really bother me, so I replaced all my code with Time.now.to_unix_ms to conform to the new changes.
Then, in April 2019: https://crystal-lang.org/2019/04/17/crystal-0.28.0-released.html, which did:

Although you should leave in the present, Time.now is now deprecated. But only because you need to know where you are. The code will need to decide between Time.local or Time.utc, much more explicit. This also affects constructors. Time.new is also deprecated and Time.local or Time.utc can be used to build specific values. Read more at #5346 and #7586.

So now, Time.now is depreciated, and we need to switch to Time.local or Time.utc. I just updated and I'm bombarded with more Time warnings. Which now, ".local" seems confusing, because I'm so used to ".now".
Can asterite or a lead dev at Manas please step in and make sure Time is protected / stay consistent in the future. IMO it's not a good idea to keep changing the method names all the time, please stop

@girng I totally feel you on this. It can be frustrating, but at the same time if the changes are not made now they will never be made. Time is an insanely tricky concept so adding clarity  through improved method names can make a huge impact in the long run, so I think these were some good changes. This is one of the pain points of using a pre-1.0 language, but it is also one of the exciting things. We can see how things improve (or take a step back!) and be a part of that change. I'm glad you shared your opinion so that it is easier to figure out what devs want/need.
My guess though is that most of the experiments have been run and changes to Time will start slowing down. In my opinion the Time API is quite nice now and probably doesn't need much change. I also think once Crystal hits 1.0 this will not be an issue much longer

I understand that these breaking changes can seem annoying. But renaming those methods is just a simple grep. Until 1.0 we don't guarantee API stability. We try to avoid breaking changes, but accept them, when they seem worthy.


Add KMD version check

At device enumeration or device instantiation, determine the version of the kernel driver and log it.  Later on this path can be used to enforce a minimum required KMD version for UMD to operate.

Related to #62


Update scripts.js

Hi Brian, I just added codes to make sure when the last keyboard deleted, the display disappear also. #2

In future versions, the actual DOM elements should be preserved so as to allow the collection to be "rebuilt".

In future versions, the actual DOM elements should be preserved so as to allow the collection to be "rebuilt".


Package name doesn't match containing directory

Description

Bug encountered in version 4.3.2-RC2.

The static code analysis fails saying that the package name doesn't match containing directory in the jvmTest source set (see the integration workflow run #462).
For fixing this, we shouldn't set a Java package prefix within the Gradle build scripts.
Instead, we should align the folder structure with the package name of each source file.
Here's an example for the AnyInt.kt file:
package kotools.types.number // file location: "kotools/types/number"

public interface AnyInt

Checklist

[ ] Fix.

This issue is fixed by https://github.com/kotools/types/commit/2c033c93941ee7417057e3c1ebad3b33a009c60d.


Flask support!

Current coverage is 99.80%

Merging #2 into master will increase coverage by +0.02% as of b1e11ad

@@            master     #2   diff @@
=====================================
  Files            2      2
  Stmts          470    502    +32
  Branches         0      0
  Methods          0      0
=====================================
+ Hit            469    501    +32
  Partial          0      0
  Missed           1      1

Review entire Coverage Diff as of b1e11ad

Powered by Codecov. Updated on successful CI builds.

We'll postpone this for now. There are other changes coming that will conflict with this.


Introduce Kubernetes

Kubernetes/Metaparticle - https://metaparticle.io
Metaparticle is a standard library for cloud native applications on Kubernetes.
The goals of the Metaparticle project are to democratize the development of distributed systems. Metaparticle achieves this by providing simple, but powerful building blocks, built on top of containers and Kubernetes.

Sorry, @ferantivero,
This entry isn't going to make the list for the following reason(s):

Possibly too new
No response from the community suggested the previous statement is false

Don't let this setback cause you to lose heart, and we look forward to your next contribution.
Thanks, Pleb


creating pyproject.toml file

Setting up a pyproject.toml file for the project

/assign

@AtmegaBuzz Getting Error: [tool.poetry] section not found in pyproject.toml !

hey, is this issue still open? i want to start participating in the project and am looking for a starting point.

There is a major code refactoring ongoing right now with additional work done as part of Google Summer of Code 2024. We will include your suggestions once the new version of Nettacker with refactored codebase is released at the end of August

Implemented in https://github.com/OWASP/Nettacker/pull/863


META: low precision in stats distributions methods

This issue lists known precision issues for scipy's distributions.
Univariate and multivariate t distribution

[x]  #18386
[ ] multivariate_t methods entropy, logpdf and pdf fail for large degrees of freedom

Entropy calculations failing for large values:

[x] #18093

Closing as low priority issues until the new distribution infrastructure is in place.


Add new ICON SCM data

I have added two more ICON SCM data files:
FixN and FixN_noice

@martin-koehler Thanks, Martin. Approved!


Db schema

What does this PR do?
It  adds database schema file o the repo and update code climate file path

Coverage remained the same at 92.418% when pulling 00ba7840523c97b21060ae82b017f2fb43f46e2f on db-schema into 7050f92f0bc454385f6aadbff2f871504940165d on staging.


fix: bug bash slate issues

:tada: This PR is included in version 0.324.31 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


user fails to signup with facebook if there is also local auth

Im using a yeoman generated feathers app,  with local and facebook authentication enabled.
The authentication service is as follows:
    const authentication = require('feathers-authentication');

    const FacebookStrategy = require('passport-facebook').Strategy;
    const FacebookTokenStrategy = require('passport-facebook-token');
    const LinkedinStrategy = require('passport-linkedin-oauth2').Strategy;
    const LinkedinTokenStrategy = require('passport-linkedin-token-oauth2').Strategy;

    module.exports = function() {
      const app = this;

      let config = app.get('auth');

      config.facebook.strategy = FacebookStrategy;
      config.facebook.tokenStrategy = FacebookTokenStrategy;
      config.linkedin.strategy = LinkedinStrategy;
      config.linkedin.tokenStrategy = LinkedinTokenStrategy;

      app.set('auth', config);
      app.configure(authentication(config));
    };

The user model:
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

export const niveles = [
    {nombre: 'superadmin', nivel: 10},
    {nombre: 'owner', nivel: 3},
    {nombre: 'admin', nivel: 2},
    {nombre: 'user', nivel: 1}
];

const userSchema = new Schema({
  facebookId: { type: String },
  facebook: { type: Schema.Types.Mixed },
  linkedinId: { type: String },
  linkedin: { type: Schema.Types.Mixed },
  email: {type: String, required: true, unique: true},
  password: { type: String, required: true },
  nivel: { type: String, enum: niveles.map(n => n.nombre), required: true, default: 'owner'},

  createdAt: { type: Date, 'default': Date.now },
  updatedAt: { type: Date, 'default': Date.now }
});

const userModel = mongoose.model('user', userSchema);

export default userModel;

The local authentication works fine, but facebook does not, When the callback its called, the new user does not gets created because the validation fails with:
[BadRequest: user validation failed]
  type: 'FeathersError',
  name: 'BadRequest',
  code: 400,
  className: 'bad-request',
  data: undefined,
  errors:
   { password:
      { [ValidatorError: Path `password` is required.]
        message: 'Path `password` is required.',
        name: 'ValidatorError',
        properties: [Object],
        kind: 'required',
        path: 'password',
        value: undefined },
     email:
      { [ValidatorError: Path `email` is required.]
        message: 'Path `email` is required.',
        name: 'ValidatorError',
        properties: [Object],
        kind: 'required',
        path: 'email',
        value: undefined } } }

The validation is there for new local user accounts, but should not work with facebook or others.
Is there a way to configure this behavior? perhaps using the adquired email from facebook and a random generated password to create the new accounts.

 If you simply want to bring the email from the facebook profile top level then you always add a before hook to your user service create method.
We might make a change to the generator so that email and password aren't required by default but this  is where the generator naturally starts to fall down. It's too hard to anticipate the requirements for every app so it'll probably have to be manual changes from here (ie. hooks or custom validators).
Changing you validations should allow you to continue on so I'm going to close this. If it doesn't work out then we can re-open and revisit. Thanks for reporting! 😄

Thanks for the guidance.
I'd ended up doing it all in a hook: obtaining the email from facebook and inserting it on the user, also generating a random password.
I'd leave the validation at model level, but yes, validation at service level seems to be the ideal.
Thanks again!


Example file complex.ino does not compile.

I think the final message is the main one:  'Complex' was not declared in this scope
Arduino: 1.8.19 (Windows 10), Board: "Seeeduino XIAO, Arduino, Off, USART"

In file included from sketch\complex.ino.cpp:1:0:

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:69:30: error: expected unqualified-id before 'const'

   template<typename _Tp> _Tp abs(const complex<_Tp>&);

                              ^

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:69:30: error: expected ')' before 'const'

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:69:30: error: expected ')' before 'const'

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:601:5: error: expected unqualified-id before 'const'

     abs(const complex<_Tp>& __z) { return __complex_abs(__z); }

     ^

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:601:5: error: expected ')' before 'const'

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:601:5: error: expected ')' before 'const'

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex: In static member function 'static _Tp std::_Norm_helper<true>::_S_do_it(const std::complex<_Tp>&)':

C:\Users\Egil\AppData\Local\Arduino15\packages\Seeeduino\hardware\samd\1.8.5\cores\arduino/Arduino.h:137:16: error: expected unqualified-id before '(' token

 #define abs(x) ((x)>0?(x):-(x))

                ^

In file included from c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\ccomplex:39:0,

                 from c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex.h:32,

                 from C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:11:

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex: In function 'std::complex<_Tp> std::__complex_log(const std::complex<_Tp>&)':

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex:773:26: error: expected primary-expression before '(' token

     { return complex<_Tp>(log(std::abs(__z)), std::arg(__z)); }

                          ^

In file included from sketch\complex.ino.cpp:1:0:

C:\Users\Egil\AppData\Local\Arduino15\packages\Seeeduino\hardware\samd\1.8.5\cores\arduino/Arduino.h:137:16: error: expected unqualified-id before '(' token

 #define abs(x) ((x)>0?(x):-(x))

                ^

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex: In function 'std::complex<_Tp> std::__complex_sqrt(const std::complex<_Tp>&)':

C:\Users\Egil\AppData\Local\Arduino15\packages\Seeeduino\hardware\samd\1.8.5\cores\arduino/Arduino.h:137:16: error: expected unqualified-id before '(' token

 #define abs(x) ((x)>0?(x):-(x))

                ^

c:\users\egil\appdata\local\arduino15\packages\seeeduino\tools\arm-none-eabi-gcc\7-2017q4\arm-none-eabi\include\c++\7.2.1\complex: In function '_Tp std::fabs(const std::complex<_Tp>&)':

C:\Users\Egil\AppData\Local\Arduino15\packages\Seeeduino\hardware\samd\1.8.5\cores\arduino/Arduino.h:137:16: error: expected unqualified-id before '(' token

 #define abs(x) ((x)>0?(x):-(x))

                ^

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino: In function 'void setup()':

complex:21:3: error: 'Complex' was not declared in this scope

   Complex c1(10.0, -2.0);

   ^~~~~~~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:21:3: note: suggested alternative: '_Complex_I'

   Complex c1(10.0, -2.0);

   ^~~~~~~

   _Complex_I

complex:22:11: error: expected ';' before 'c2'

   Complex c2(3, 0);

           ^~

complex:23:11: error: expected ';' before 'c3'

   Complex c3(-10, 4);

           ^~

complex:24:11: error: expected ';' before 'c4'

   Complex c4(-5,-5);

           ^~

complex:25:11: error: expected ';' before 'c5'

   Complex c5(0, 0);

           ^~

complex:27:18: error: 'one' was not declared in this scope

   Serial.println(one);

                  ^~~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:27:18: note: suggested alternative: 'tone'

   Serial.println(one);

                  ^~~

                  tone

complex:28:18: error: 'c1' was not declared in this scope

   Serial.println(c1);

                  ^~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:28:18: note: suggested alternative: 'A1'

   Serial.println(c1);

                  ^~

                  A1

complex:29:18: error: 'c2' was not declared in this scope

   Serial.println(c2);

                  ^~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:29:18: note: suggested alternative: 'A2'

   Serial.println(c2);

                  ^~

                  A2

complex:30:18: error: 'c3' was not declared in this scope

   Serial.println(c3);

                  ^~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:30:18: note: suggested alternative: 'A3'

   Serial.println(c3);

                  ^~

                  A3

complex:31:18: error: 'c4' was not declared in this scope

   Serial.println(c4);

                  ^~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:31:18: note: suggested alternative: 'A4'

   Serial.println(c4);

                  ^~

                  A4

complex:38:3: error: 'c5' was not declared in this scope

   c5 = c1;

   ^~

C:\Users\Egil\AppData\Local\Temp\arduino_modified_sketch_141065\complex.ino:38:3: note: suggested alternative: 'A5'

   c5 = c1;

   ^~

   A5

exit status 1

'Complex' was not declared in this scope

OK... I am compiling for an Seeeduino Xiao, and seem to be affected by this issue: https://github.com/RobTillaart/Complex#known-problem

@ArnieO
Does the solution from the readme work for you?

@ArnieO Does the solution from the readme work for you?

Yes, it worked.


fix drishti_add_test() android gpu tests w/ qt dependencies

# The GPU tests currently require QT for the off screen GL context
# and this won't be installed with the simple shared library
# dependency walker, so the `AND NOT ANDROID` part is currently added
if(DRISHTI_BUILD_QT AND DRISHTI_BUILD_OGLES_GPGPU AND NOT ANDROID)
  set(DRISHTI_ACF_DO_GPU 1)
else()
  set(DRISHTI_ACF_DO_GPU 0)
endif()

Removed QT context in https://github.com/elucideye/drishti/pull/454


Add Gabsync

Provides extra container to run Gabsync every 24hours.

Hi @mhoffmann75,
thanks for your pr. I have looked through it but will need to think about it for a while. Like already said in #111 I do see that there is a need for this, but I am still unsure about the approach.
Instead of having an own image for gabsync I think the changes could even do directly into the z-push image and once could enhance the start.sh script with something like https://github.com/zokradonh/kopano-docker/blob/master/core/start-service.sh#L32-L36
This way you can just call docker-compose exec kopano_zpush /usr/share/z-push/tools/gab-sync/gab-sync.php -a sync (I think that should work then, did not try it).
Also still not sure (even though I do it myself in https://github.com/zokradonh/kopano-docker/blob/master/core/services/kopano-users.sh) if the trigger to do something on a regular base should come from inside of the container running the task.
Maybe a general task scheduler (for example based on https://github.com/aptible/supercronic) would be interesting?
I am open for ideas.

I think this is a matter of philosophy. The docker philosophy from my understanding is about micro services. So we should not create containers running multiple services unless forced to - e.g. mailserver is such an example. We should create a container for each service / task. For example you don't need gab sync because you don't plan to use KOE or later on its not needed anymore, just stop and remove the container. This is much easier than fiddling with the service from cron inside a container. Besides this "cron" container would need to have all components installed inside that are needed for various tasks making it heavy and you would have components inside you probably don't need at all.
So my vote is for micro service architecture making things granular and "simple". That is why I insisted on naming it kopano_gabsync instead of your suggestion kopano_zpush_utils - see https://github.com/zokradonh/kopano-docker/pull/111#discussion_r266970092

Just another thought: It seems to me that one thing that makes this container unnecessary heavy is the dependencies between the deb packets. From my understanding we need z-push-kopano-gabsync which required PHP Mapi which we can get from the packet z-push-backend-kopano. However the latter pulls in php (OK) and full apache server. So I'm not sure if this is really needed!?
That's the reason why my first approach was to built this container from kopano_base instead of kopano_zpush not realizing that it pulls in full z-push stack :-)
But you're right its easier to create and maintain it from zpush as template. Maybe with some litte additional overhead inside the container - maybe not. I have not yet looked over all the dependencies.

It seems to me that one thing that makes this container unnecessary heavy is the dependencies between the deb packets

yes, they indeed have not been designed with the thinking to be used completely separate (if you want z-push-admin then the usual way would be to have z-push on the same system as well). The apache part wonders me a bit though, as there is a dedicated config package for the webserver stuff.

The docker philosophy from my understanding is about micro services. So we should not create containers running multiple services unless forced

totally agree.

Besides this "cron" container would need to have all components installed inside that are needed for various tasks making it heavy and you would have components inside you probably don't need at all.

Maybe I was not clear enough in expressing my vision.
For the cron container I was really just thinking about a job scheduler in a separate container that then triggers commands in either running containers or spins up a new container to run a specific task.
Just like you can currently already run docker run --rm -it -v /var/run/kopano/:/var/run/kopano -v $(pwd):/kopano/path zokradonh/kopano_utils kopano-backup to create a backup. while backup runs there is a container and afterwards it gets destroyed. Or to stay within the reach of docker-compose docker-compose exec kopano_server kopano-cli --list-users to list users.
Similarly to how the kopano_core docker image is started multiple times all the needed packages for the gabsync could be installed and configured in the normal z-push image and then you define another container in docker-compose.yml that then just uses /usr/share/z-push/tools/gab-sync/gab-sync.php -a sync as its command. While the job runs the container is there and then it stops until the job scheduler starts it up again.

Ok i will see if a dedicated container with supercronic will work for this task.


Rethink the duplicate key constraint logic

Currently RadixDB tree structure is very lean by strategically using a minimal node structure. This complicates the distinction between nodes that are path components versus those explicitly holding values. This results in unexpected ErrDuplicateKey error on record insertion. Here's the current node structure:
// node represents an in-memory node of a Radix tree. This implementation
// is designed to be memory-efficient by using a minimal set of fields to
// represent each node. In a Radix tree, the node's key inherently carries
// significant information, hence reducing the need to maintain metadata.
type node struct {
	key      []byte  // Path segment of the node.
	value    any     // Data associated with this node, if any.
	children []*node // Pointers to child nodes.
}

Problem Illustration
Consider the following tree with keys apple, app, banana, and baking:
.
├─ app ("store")
│  └─ le ("sauce")
└─ ba ("<nil>")
  ├─ nana ("smoothie")
  └─ king ("show")

Attempting to insert a new record with the key ba would trigger a ErrDuplicateKey error, as ba is interpreted as an existing key. From Radix tree perspective, this is correct behavior, but it's misleading as a database library.
Food for Thought
There are couple of options that comes to mind:

Allow duplicate keys. Only provide Put(), which will overwrite an existing value.
Tag the node on insertion. Such as adding a 1-byte boolean field to the node struct.

(2) is likely necessary since it's not feasible to properly implement API methods like Exists(), Get() and so on without it.

Alternate implementation is to borrow Go's database/sql pattern of nullable fields (e.g. sql.NullString). We could implement a wrapper for the value which contains a flag to indicate the node's purpose. This information would nicely serialize/align on disk as well. Having said that, pragmatically, this wrapper with metadata is no different to adding a flag to the node struct.

As hinted above, and suggested by @pldubouilh, the conclusion is to add a 1-byte flag to node which will indicate if the node is a database record or not.


matrix-synapse: 1.40.0 -> 1.41.0rc1

Motivation for this change
https://github.com/matrix-org/synapse/releases/tag/v1.41.0rc1
Things done

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

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

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Version 1.41.0 was released: https://github.com/matrix-org/synapse/releases/tag/v1.41.0


Contents of the training dataset file data.pt

Hi,
Thanks for this excellent work. I am trying to understand and use this framework on another dataset but I have few doubts regarding the training data being used i.e. data.pt that is used to train the autoencoder and the behavior embedding. Seems like there are three types of data in the file with keys: 'params', 'traj', 'task'. with each having dim 0 length as 17286 and traj, task having dim 1 of length 1020, 117 respectively.
I understood the 'traj' tensor to be related to the long trajectory recorded for each checkpoint i.e. s_0, a_0, s_1, a_1, ....s_n, a_n
but I am not sure.
Also I am unsure about the data stored in the task tensor? Am I correct in understanding this is where the s_K to s_K+m post success states are stored or is there any other tensor storing s_K to s_K+m?
Can you please help me understand the contents of the training data file, data.pt, especially the traj tensor since I am unable to understand the shapes of each state and action and also the format in which they are stored ? This will help me in implementing the framework on my concerned dataset.
TIA!

Thank you for your advices!! We plan to update our dataset card but we meet some issues on the huggingface. Now let me update the dataset details for you.
'param': all the parameters in the policy network as a vector
'traj': prior trajectories, but as 's_0, a_0, a_1, a_2, s_3, a_3, a_4, a_5', because the actions in the next step are similar in most control tasks, so we choose multiple three actions following one states.
(About 1020=20*(39+34), the state dim=39, the action dim=4)
'task': the success three states (117=393)
However, if you want to train with your dataset or task, you can privately design the trajectory dimensions and encode them as the same dimension (for example we used 128).
Also, you can use our pretrained model with the same behavior dimensions to finetune on your dataset.
Hope our reply can help you! Thanks!

Thank you for providing the details of the dataset! It is very helpful in understanding the structure of the data and made it easier to implement the framework on my own dataset. May I know how you guys collected the trajectory data and the success states data? I assume the policy network parameters are first stored as a checkpoint during training, and then the policy is rolled out to collect the traj and task data. Please let me know if I am right or wrong in this regard. Thanks a lot for your help!

Yes, you are right! We rollout the policy to collect trajectories for training.

Oh okay. Thanks a lot for your support!

Hey @cheryyunl , I would like to know about the param tensor too, which stores the parameters of the policy network for every checkpoint. I am trying to adapt this framework onto my own dataset that I have acquired by training with PPO instead of SAC. In my training dataset, I tried storing the parameters for every checkpoint, in a list, as it is given by the agent.state_dict() function, which returns a dictionary of the agent's parameters. This format doesn't allow me to train on my dataset, so I would like to ask for the format in which the parameters are stored in the tensor for every checkpoint. Thanks!