ansible-core 2.11 support?

Hi, I don't see an existing issue so creating one. Are there plans to support ansible 2.11? Thank you.
ERROR! Your Ansible version (2.11.0) is too recent. The most recent version
supported by Mitogen for Ansible is (2, 10).x. Please check the Mitogen
release notes to see if a new version is available, otherwise
subscribe to the corresponding GitHub issue to be notified when
support becomes available.

    https://mitogen.rtfd.io/en/latest/changelog.html
    https://github.com/dw/mitogen/issues/

I found the following patch to provide minimal support for ansible-core 2.11. My test playbook seems to work with ansible 4.0.0 (ansible-core 2.11.0), as well as ansible 3.4.0 (ansible-base 2.10.9), but I did not test older Ansible versions.
The main issue was that Ansible no longer exposes the options of the ssh connection plugin as play_context attributes.
https://github.com/ansible/ansible/pull/73708

@upekkha That patched worked for me too! You should submit a PR.

Unfortunately, the patch seems to ignore ansible_ssh_common_args which I set at group level, so my SSH jump host stops working.

Good catch. Looks like one also has to pass the variables as argument to allow for config overrides. If this also works for you, I will update the PR.

Thanks for taking a look. I had to remove the access to the second vars sub-dict, so https://github.com/mitogen-hq/mitogen/pull/841/files#diff-a98bb8f749289d5b203cc23fbe75d1a1e651bf8b20a80d4e3a7598129f1a4472R467 looks like this for me:
variables = self._task_vars.get("vars", {})

With self._task_vars["vars"].get("vars", {}) I would only get an empty dict. I have ansible==4.0.0 and ansible-core==2.11.1.

You are right. I reverted the additional "vars" key. I did my test by adding a ansible_ssh_args variable to a host directly inside the inventory. After my first commit I got somehow confused by the different syntax for groups (with vars:) and hosts (without vars:).

As far as I know there is still no update for mitogen. You have to stick closer to the Ansible releases! Workarounds are not good enough here. Please release 2.11.(.2) support short term!

Is there anything left to do for the patch @upekkha provided? I was wondering if something is blocking a merge.

I also use that patch, but I always get errors with the apt module.
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: AttributeError: module '__main__' has no attribute '_module_fqn'
fatal: [<reacted>-mon]: FAILED! => changed=false
  ansible_facts:
    discovered_interpreter_python: /usr/bin/python3
  module_stderr: |-
    Traceback (most recent call last):
      File "master:/<reaced>/<reacted>/mgit/mitogen/ansible_mitogen/runner.py", line 975, in _run
        self._run_code(code, mod)
      File "master:/home/<reacted>/<reacted>/mitogen/ansible_mitogen/runner.py", line 939, in _run_code
        exec(code, vars(mod))
      File "master:/usr/lib/python3.9/site-packages/ansible/modules/apt.py", line 1310, in <module>
      File "master:/usr/lib/python3.9/site-packages/ansible/modules/apt.py", line 1114, in main
      File "master:/usr/lib/python3.9/site-packages/ansible/module_utils/common/respawn.py", line 39, in respawn_module
        payload = _create_payload()
      File "master:/usr/lib/python3.9/site-packages/ansible/module_utils/common/respawn.py", line 76, in _create_payload
        module_fqn = sys.modules['__main__']._module_fqn
    AttributeError: module '__main__' has no attribute '_module_fqn'
  module_stdout: ''
  msg: |-
    MODULE FAILURE
    See stdout/stderr for the exact error
  rc: 1

Ansible Version:

Interestingly is the patch forcing to use as interpreter python3 (/usr/bin/python3) and it is just ignoring `interpreter_python = /usr/bin/python` used in ansibe.cfg.

@ohdearaugustin  Just out of curiousity, could you try ansible.builtin.apt instead of apt?

- name: install prometheus
  apt:
    name: prometheus
    state: present

@GhostLyrics Tried it with ansible.builtin.apt and I get the exact same issue. If it helps I can post a more verbose error message.

I can confirm that setting interpreter_python = /usr/bin/python in ansible.cfg gets ignored by mitogen, while setting ansible_python_interpreter: /usr/bin/python at the level of host/group vars seems to work. Nevertheless I get the impression that this is not related to the linked patch, but some other change in Ansible breaking the interpreter discovery of mitogen. Hopefully one of the mitogen developers joins in at some point to shed some light on the future support of Ansible 2.11+.

@moreati Thank you so much for getting this done. 🙏


Fix Rails 5 test

This removes a test that was added for a Rails 5 behavior which has been fixed here - https://github.com/rails/rails/pull/22564

@lucasmazza This fixes the failing Rails 5 test


Lines not drawing with CapsStyle.NONE

After updating to the latest builds of OpenFL/Lime (from openfl.org/builds) lines won't draw with CapsStyle.NONE. Interestingly, drawCircle() works, where moveTo() then lineTo() doesn't.
This was working in lime 2.0.5 / openfl 2.2.3 (and possibly newer versions too).
package;

import openfl.display.CapsStyle;
import openfl.display.LineScaleMode;
import openfl.display.Sprite;

class Main extends Sprite {

	public function new () {

		super ();

		graphics.lineStyle(10, 0x000000, 1., false, LineScaleMode.NORMAL, CapsStyle.NONE);
		graphics.moveTo(100, 200);
		graphics.lineTo(200, 300);

	}

}

Was fixed.


Create layer from capabilities xml

In the old version of eox-map we had a convenient way to create a layer from capabilities; this was done with the getCapabilities method.
We could also add this to the new version of the map by creating a custom layer type, where a layer could be defined like e.g.
{
  type: "Tile",
  source: {
    type: "WMTSCapabilities",
    url: "<link to capabilities xml>",
    identifier: "<layer identifier"
  }
}

Relevant resources

https://openlayers.org/en/latest/examples/wmts-capabilities.html
https://openlayers.org/en/latest/examples/wmts-layer-from-capabilities.html
https://openlayers.org/en/latest/apidoc/module-ol_source_WMTS.html#.optionsFromCapabilities
https://tiles.maps.eox.at/wmts/1.0.0/WMTSCapabilities.xml

Can be used for supporting a web map link of type WMTS: https://github.com/stac-extensions/web-map-links?tab=readme-ov-file#ogc-wmts.

Implemented in https://github.com/EOX-A/EOxElements/pull/767


Incorrect syntax highlighting of cshtml files in GitHub

Razor pages (i.e. those with an extension of .cshtml) are syntax highlighted using the C# syntax highlighter. However, the vast majority of a Razor page is HTML instead of C#, and the syntax highlighting of the HTML part is either absent or completely wrong. Not only that, but many of the at-directives are not correctly syntax highlighted.
(see https://github.com/infinnie/TodoServer/blob/master/TodoServer/Views/Todos/Index.cshtml )

The cshtml extension is currently associated with the C# language itself, whereas it sounds like this should be categorised as a separate language altogether.
Are all cshtml files "Razor pages"? Or do some "ordinary" C# files use that file extension as well?

No ordinary C# files use that file extension.
Razor pages with the extension .cshtml are pages such as views in ASP.NET MVC or standalone ASP.NET Web Pages.

I second this.  Razor, like other view engines, uses a syntax that's kind of a hybrid of HTML and an actual programming language--in this case, C#.  So neither HTML nor C# is an appropriate language tag for Razor code in Github comments, issues, etc.

Visual Studio Code editor already has grammars that are needed to correctly highlight cshtml files. The grammars are located in Visual Studio Code syntaxes folder and are fully compatible with Atom & Github parsing engines as far as I know. So why not to take production-ready highlighters from there? atom/language-csharp repository already uses Microsoft's grammar (but packages don't seem to be uploaded yet), so this can be done with cshtml too. @Alhadis hope this helps!

The *.cshtml is a mix of html and c#. I would say treat it as HTML, but when you see @<expression>, then it's a C# code.
For example:
@if (User.Identity.IsAuthenticated)
{

Sign out

}
else
{

Sign in

}

Where @<expression> can be inside HTML tag. For instance,
<img width="20" height="20" class="avatar"<EMAIL_ADDRESS>src="@User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value">

This issue is still relevant as the linguist languages.yml file still considers the .cshtml extension to be C#.  Looks like @worldbeater provided a pretty good reference above for how this Razor highlighting can be correctly implemented.

Worth using .cshtml grammar located at https://github.com/austincummings/razor-plus repository (see syntaxes directory). See it in action, looks pretty good.

Does one of you want to open a pull request to implement this change (move .cshtml to its own language entry with the adequate grammar)?

Closing as this is resolved by https://github.com/github/linguist/pull/4314.

if this was fixed at some point - cshtml is now being considered as html again - and i agree with others, that it should de it's own categorized language because it isn't actually either of those languages

This is still annoying. Quotes aren't correctly being highlighted.

This is still annoying. Quotes aren't correctly being highlighted.

@alphonso77 This isn't a Linguist issue. This is an issue with the grammar. If you wish to have it resolved, you need to log an issue with the grammar.

@lildude, I'm sorry - I saw the comment earlier stating that, it was just a moment of frustration.


Add support for scheduling profiles and add a predefined bin-packing profile

/area auto-scaling control-plane
/kind enhancement
What this PR does / why we need it:
This PR adds support for selecting scheduling profiles in the Shoot spec. Apart from supporting the default/balanced profile, it also adds support for a bin-packing profile.
Which issue(s) this PR fixes:
Fixes #1455
Release note:

The Shoot spec now supports selecting scheduling profiles. Apart from the "balanced" (aka "default") profile it is possible to configure a `bin-packing` profile (alpha feature). For more details see the [usage docs](https://github.com/ialidzhikov/gardener/blob/75d786fcecf3ddf52ca29947fab777d1e40d389d/docs/usage/shoot_scheduling_profiles.md).

Another question: Can you explain how you plan to enable the bin-packing feature for seed cluster (IIUC, you want to deprecate and remove the SeedKubeScheduler feature?)?

Yes. The ManagedSeed references a Shoot and the bin packing feature can be enabled via the Shoot spec. This has the downside that the bin packing cannot be enabled for the non-ManagedSeeds. As far as I understand from the issue we are fine with this - ref https://github.com/gardener/gardener/issues/1455#issuecomment-959389009.
Yes, the longterm plan is to deprecate and remove the SeedKubeScheduler feature.
Do you mean to document that the SeedKubeScheduler is deprecated as part of this PR or do you want to have a dedicated doc that explains how to enable the feature for ManagedSeeds?

Another question: Can you explain how you plan to enable the bin-packing feature for seed cluster (IIUC, you want to deprecate and remove the SeedKubeScheduler feature?)?

Yes. The ManagedSeed references a Shoot and the bin packing feature can be enabled via the Shoot spec. This has the downside that the bin packing cannot be enabled for the non-ManagedSeeds. As far as I understand from the issue we are fine with this - ref #1455 (comment). Yes, the longterm plan is to deprecate and remove the SeedKubeScheduler feature. Do you mean to document that the SeedKubeScheduler is deprecated as part of this PR or do you want to have a dedicated doc that explains how to enable the feature for ManagedSeeds?

OK, I see, thanks for the explanation. I think nothing else has to be done as part of this PR.
/lgtm
/approve


Allow setting rediss protocol for Sidekiq plugin

This allows people using the Rediss protocol for encryption to use the plugin.
Not sure if there's a way to make this into a checkbox rather than an input field. I think currently if you ever set this and then try to unset it (to an empty string) it might just get considered as true. Alternatively, this could just be a protocol option, but that might be weird to allow.

Rediss protocol for encryption to use the plugin

Ohhhhhhhh....I thought redisswas a typo for a long time and this makes SO MUCH more sense. 🤦♂

Hi @ibrahima,
We will take a look at your PR and let you know when it's accepted.
Thank you for the input.

Thanks for merging this! Is there anything I need to do to get this updated version of the plugin to show up on Pingdom? When I try to install the plugin I don't see this field - not sure if I just messed it up somehow?

@ibrahima the plugin has been deployed on production. In your account you should be able to go to the plugin (or plugin template) settings -> code and Update option should be visible for you.


fix: Allow higher for sale price on reclaim

Description
Allow a higher for sale price than claim price on reclaim.
Issue
fixes #ISSUE
Checklist:

[x] My commit message follows the Conventional Commits specification
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have tested my code
[x] My changes generate no new warnings
[x] My PR is rebased off the most recent main or appropriate feature branch
[x] My PR is opened against the main or appropriate feature branch

Additional comments
Please post additional comments in this section if you have them, otherwise delete it
Alert Reviewers

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 88.636%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
515

Relevant Lines:
560

💛  - Coveralls


ORC-1051: Update benchmark dependencies

What changes were proposed in this pull request?
This PR aims to update the transitive dependencies of Spark 3.2.0.

aircompressor: 0.16 -> 0.21
Netty-all: 4.1.67.Final -> 4.1.68.Final
scala-librari: 2.12.10 -> 2.12.15
spark.jackson.version: 2.10.0 -> 2.12.3

Why are the changes needed?
When ORC-1037 updates to Spark 3.2.0, these dependencies are missed.
How was this patch tested?
Pass the CIs.

+1, LGTM

Thank you, @guiyanakuang ! Merged to main/1.7.


Cargo should give helpful errors when unsupported flags are used.

Problem
There are several flags one might imagine users passing to Cargo that aren't supported yet. It'd be nice if we told users who try to use these what to use instead, and perhaps also linked to the issue (if any) proposing to add such a flag. Some examples:

There's no -C for running in a different directory.
There's no -w or -W short for --workspace (except in update).
There's no -x for --exclude
There's no -t for --target
There's no -s for --quiet (-s is "silent" in curl)
It's --manifest-path, not --path (though there is --path for cargo add)
There's no -c for --config
There's no -z, only -Z
There's no -O, only --out-dir
There's no -n for --dry-run

Proposed Solution
No response
Notes
No response

Does it make sense having this as a built-in mechanism in clap for suggesting an alternative flag?

@weihanglo I think that can make sense to seed clap with specific suggestions and not just rely on the automatic suggestions and that would help simplify things for application, like cargo.  Mind opening an issue?

More examples:

There's no --debug for cargo build. Only --release.
There's no --release for cargo install. Only --debug.

These does confuse people a lot. See #12009.

I am not sure if we should wait for upstream fix or make our own custom suggestion. Let's label it as waiting for upstream first. We still seek a ad-hoc solution for each case if somebody is interested in.
@rustbot label +S-blocked-external

https://github.com/clap-rs/clap/pull/5075 just got landed with<EMAIL_ADDRESS>People, we now can have basic suggestions for unsupported arguments!
I'll write down a list of flags of interest and instructions shortly.
@rustbot label -S-blocked-external +S-accepted +E-easy

Not sure if this is the relevant clap issue https://github.com/clap-rs/clap/issues/4853. Supposed we are going to leverage UnknownArgumentValueParser for those well-known unknown arguments, it might cause unwanted typo suggestion for them.
Let me label it blocked on that issue at this moment.
@rustbot label -S-accepted +S-blocked-external

@weihanglo could you give an example of where that causes a problem worth blocking this issue?

Something like this? Though for short aliases clap doesn't suggest them I feel like. If that's the case we can continue working on short aliases part.
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/cargo install --please`
error: unexpected argument '--please' found

  tip: a similar argument exists: '--release'

Usage: cargo install --release [crate]...

For more information, try '--help'.

Asking to better characterize the problem: is that always bad though?
Take the prior work in #12529, like cargo test --keep-going.  If the user thought it should work and did cargo test --keep-goign, today they would get a correction and then be pointed to the correct flag (yes, ideally the two steps would be one step which might be a consideration where suggest_arg is appropriate).  With the proposed change, the user would just get an unexpected argument error and would fall back to --help.  Trying to understand which path is best.

It's not inherently bad, and agree with that two steps is better than infinite steps searching in --help. Just it is lying that “a similar argument exists”, which doesn't.
I am convinced that it's not really a blocker 😆. Would be great if clap can improve the situation.
@rustbot label +S-accepted -S-blocked-external

@rustbot claim


ion-slides coverflow effect - incorrect perspective applied to transforms of ion-slide, suggested workaround

Ionic version:
[ ] 2.x
[ x ] 3.x
[ ] 4.x
I'm submitting a ...
[ x ] bug report
[ ] feature request
Current behavior:
Incorrect perspective applied to transforms on slide elements becoming more pronounced as you move to later slides when using coverflow effect
Expected behavior:
same perspective applied to all slides
Steps to reproduce:
See plnkr below
Related code:
A workaround that resolves the issue for me is placing the following in app.scss (the parent element with class swiper-container-3d  already has perspective applied)
// Fix for swiper on coverflow, perspective needs to be in the parent element only.
.swiper-container-coverflow .swiper-wrapper,
.swiper-container-flip .swiper-wrapper {
    perspective: unset;
}

Here is a plnkr created by someone else that illustrates the problem quite well, see that the visible space between the 1st and 2nd slide is much smaller than the penultimate and last slides
https://embed.plnkr.co/p8GeoDf9jUXzm8Gtntkl/
Ionic info:
cli packages: (/usr/local/lib/node_modules)

    @ionic/cli-utils  : 1.15.2
    ionic (Ionic CLI) : 3.15.2

global packages:

    cordova (Cordova CLI) : 7.0.1

local packages:

    @ionic/app-scripts : 3.0.0
    Cordova Platforms  : android 6.3.0 ios 4.5.2
    Ionic Framework    : ionic-angular 3.7.1

System:

    ios-deploy : 1.9.2
    ios-sim    : 5.0.13
    Node       : v8.2.1
    npm        : 5.3.0
    OS         : macOS Sierra
    Xcode      : Xcode 9.0 Build version 9A235

Environment Variables:

    ANDROID_HOME : not set

Misc:

    backend : legacy

Thank you, friend. I was looking for this.

Year I can confirm, that it also happens to me.


best practices regarding code structure

I'm playing around with lodata again, everything works very well and a lot of the OData specification has been implemented which is great.
One thing I'm struggling with, is the whole code structure.
Operations
If I extend a class from Operation I basically build a global class, but most of the time an operation is specific to a model. If I have a model called Person, I would want the operation greet to be part of that model/class and not other model.
In pseudo code I'd probably want something like this:
class Person extends BaseRepository {
   model = PersonModel::class

   greet() {
      ...
   }
}

And then register the whole class, including the public methods which would turn into operations. That way I can nicely group my code which would make it easier for new people on my project to find the relevant pieces.
I'm aware that I can bind an entity, but this again looks global: https://lodata.io/modelling/operations.html#binding-entities
Overriding standard behaviour
This seems to be a use-case which I need a lot. If I take my pseudo code from above, I might want to turn it into something like this:
class Person extends BaseRepository {
   model = PersonModel::class

   greet() {
      ...
   }

   onSave() {
      fullName = first_name + middle_name + last_name
   }
}

In other words:

While I don't want to have classes with hundreds of lines, I also don't want to have a single file per method.
I'd like to keep things together from a business object point of view.

Maybe I could create a magic object register method that scans a bunch of annotations and register the entity as well as certain operations, but I wonder what others are doing to structure their lodata code.

Hi @Remo,
Exposing an Eloquent method as a bound operation on an entity in the way you describe is 100% the way this should be implemented, however as you point out it's not there yet 😉.
During Lodata's "discovery" of Eloquent models, it should look for methods decorated with PHP attributes that indicate the methods should be exposed as operations, and just dynamically generate those operation classes on the model with the right parameters - do you think this would work?
I am definitely interested in hearing ideas of different code patterns for creating operations and other pieces of the model. Lodata is still a relatively young project and can be changed based on what works in the real world.

There's just one thing I'm wondering about. Exposing decorated eloquent models methods would be cool, but it would only work if they are actually there. What if I'm using a repository pattern that wraps my model? I have to admit that in most projects I'm not mocking my models, but if the project gets large, a repository pattern with mocks can help and then it would fail.
Having just said that, I think this is probably a special use-case we can't easily support in lodata. A repository class can have any kind of method, if there's no contract, lodata wouldn't even know how to fetch a single model record. I guess lodata could ship with an interface that allows us to build repositories, but that's maybe a bit too opinionated.
Right now I'd say let's go with an automatic discovery of decorated eloquent model methods and make it easy for others, to write their own discovery method in case they want to support a custom repository class.

What about a really lightweight interface that simply returns the model?
<?php
use Illuminate\Database\Eloquent\Model;

interface ILodataEloquentRepository {
   getModel(): Model;
}

That way I could easily create a repository myself with custom methods and still make lodata happy by giving it a straight connection to the model:
<?php
#[LodataRepository]
class Flight implements ILodataEloquentRepository {
   public function getModel(): Model {
     return FlightModel::class;
   }

   #[LodataOperation]
   public function land() {
      ...
   }
}

And for those who would want to use their models directly we could go with something like this:
<?php
use Illuminate\Database\Eloquent\Model;

#[LodataModel]
class Flight extends Model {
}

In this pattern, what's the right way of calling land() so it gets access to the right instance of the model it needs to operate on?

I'd say: flights(1)/land

Ah I meant in PHP 😄  how should the instance of the model be passed to land?

Oh yes, that makes more sense 😄
Maybe we could do something like this:
<?php
use Illuminate\Database\Eloquent\Model;

interface ILodataEloquentRepository {
   setInstance(Model $instance);
   getInstance(): Model;
   getModel(): Model;
}

Otherwise we'd have to pass it as an argument:
#[LodataOperation]
public function land(Model $instance) {
   ...
}

I'd probably prefer the second approach, but either way, it becomes a little bit more opinionated.
It might be better to focus on traditional eloquent models?

Hi @Remo,
I have tagged https://github.com/flat3/lodata/releases/tag/v4.0.0-beta.1 which rewrites how operations are structured.
There are samples here: https://github.com/flat3/lodata/tree/4.x/tests/Operations
and here: https://github.com/flat3/lodata/blob/4.x/tests/Models/Airport.php
and here: https://github.com/flat3/lodata/blob/4.x/tests/Models/Repository.php
This should show how you can tag your methods with attributes, and then pass either the class name or a class instance to Lodata::discover($class) as described in https://github.com/flat3/lodata/blob/4.x/tests/Unit/Operation/DiscoveryTest.php
Once the interface is solid I will update the documentation.
Any feedback appreciated!

Wow this is great! At first glance this is exactly what I was hoping to have.
I haven't tested it, but will this work with PHP 7.3? I've just checked https://github.com/flat3/lodata/blob/4.x/composer.json and saw that we still allow it.
Do you think there's a way to find classes by an attribute like #[LodataClass] ? From what I understand it would be a bit of a brute force scan. Being able to declare the classes with an attribute would feel more consistent, it's what I'm used from my .NET projects, but I guess with PHP we'd have to scan all declared classes and then cache it?

Yes you can certainly use the functionality with 7.3, you just can't use attributes to automatically configure for you. All the attributes are doing are describing how an Operation should be configured.
I added tests at https://github.com/flat3/lodata/blob/4.x/tests/Unit/Operation/Repository73Test.php that test you can still create these operations in 7.3.
For finding classes decorated with an attribute you could do something as you're describing but I'm unsure what the performance would be. You could also only do it over all classes that had already been loaded, so if you had a class that hadn't yet been autoloaded yet you couldn't discover it, so you'd still have to add it for discovery manually.

Yes you can certainly use the functionality with 7.3, you just can't use attributes to automatically configure for you. All the attributes are doing are describing how an Operation should be configured.

That's great!

For finding classes decorated with an attribute you could do something as you're describing but I'm unsure what the performance would be. You could also only do it over all classes that had already been loaded, so if you had a class that hadn't yet been autoloaded yet you couldn't discover it, so you'd still have to add it for discovery manually.

I guess not being able to find such classes easily is a restriction we have with PHP. No big deal. I'll try to add some attributes to my classes in my lodata test project, but I'll need a bit of time to get that done.

I've upgraded a demo project of mine to the latest beta of lodata. The main functionality was up and running in no time, but one thing I'm not sure about.
I previously got this in my code:
\Lodata::discoverEloquentModel(\App\Models\Project::class)->discoverRelationship('issues');

I replaced it with Lodata::discover which works fine for project model data, but the relationship is missing.
I wonder, shouldn't we have something like #[LodataRelationship]? Or what did you have in mind regarding classes with relationships?
<?php

namespace Flat3\Lodata\Tests\Models;

use Flat3\Lodata\Attributes\LodataFunction;
use Illuminate\Database\Eloquent\Model;

/**
 * @property string $name
 * @property string $code
 */
class Airport extends Model
{
    public $timestamps = false;
    protected $guarded = [];
    protected $casts = [
        'construction_date' => 'date',
        'sam_datetime' => 'datetime',
        'open_time' => 'timestamp',
        'review_score' => 'float',
        'is_big' => 'boolean',
    ];

    public function country()
    {
        return $this->belongsTo(Country::class);
    }

    #[LodataRelationship]
    public function flights()
    {
        return $this->hasMany(Flight::class, 'origin', 'code');
    }

    public function scopeModern($query)
    {
        return $query->where('construction_date', '>', '1940-01-01');
    }

    #[LodataFunction]
    public function op1(): ?string
    {
        return $this->name;
    }

    #[LodataFunction]
    public function op2(string $prefix): string
    {
        return $prefix.$this->code;
    }
}

You're absolutely right, we should have that! Shouldn't be hard to add...

Okay that's all added, I tagged the https://github.com/flat3/lodata/releases/tag/v4.0.0 release that includes this.

I've tested it myself, it works perfect! What a great step forward.
I don't think there's anything right now that I would change. This issue can be closed from my point of view.

Thanks @Remo I appreciate the feedback!


Turn on codecov

Could you go here and activate codecov for this repo? https://app.codecov.io/gh/trulsf/UnitJuMP.jl
It'd help us write tests to catch all of the edge cases.

Hopefully, it should be activated now. Please let me know if it is not working.


Jbaker/update deps

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Summary:
update dependencies and add missing desciption
Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Incompatibility with Hammer Core

https://paste.dimdev.org/vurubesewe.mccrash

Don't use an unsupported version such as our dev builds without dev approval. 1.1.1 is no where near ready and shouldn't be used.


adding mega-linter github action

(This PR is not ready to merge. It's only being opened now as a formality to trigger GitHub Actions for debugging purposes.)
what

Adding a gitHub Action for mega-linter-based linting, using the cloudposse/actions/github/mega-linter action.

why

Mega-linter allows linting using a variety of linters, and validation of YAML/JSON formats using JSON schema. This means that it can lint much of our existing codebase and validate our Helmfiles all in one step.

references

https://github.com/cloudposse/actions/pull/95
https://github.com/nvuillam/mega-linter

Closing because mega-linter is not ready for production use. This can be reopened later if desired, but hopefully we will find a better solution soon.

Closing because mega-linter is not ready for production use. This can be reopened later if desired, but hopefully we will find a better solution soon.


doc: Clarify post-release steps

Clairfy docs after following the post-release steps at
https://github.com/cilium/cilium/issues/12630.

Coverage increased (+0.01%) to 37.207% when pulling 225fe6ef6ae26f765a914abaad5829e370371a27 on christarazi:pr/christarazi/update-release-docs into 4e11ae1bb82d3e3f1cde535405e5e79f9ce1606e on cilium:master.


Opencl linearpolar and lopolar

OpenCV version: 3.1
Host OS: Windows 10 VS 2013

Method logPolar and linearPolar using opencl
When opencl is activated first and desactivated this program give a wrong result :
#include "opencv2/imgproc/imgproc.hpp"
#include "opencv2/highgui.hpp"
#include "opencv2/core/ocl.hpp"
#include <iostream>

using namespace cv;
using namespace std;

int main(int argc, char* argv[])
{
cv::ocl::setUseOpenCL(true);
UMat u1,u2;
    imread("f:/lib/opencv/samples/data/lena.jpg", CV_LOAD_IMAGE_GRAYSCALE).copyTo(u1);
    imread("f:/lib/opencv/samples/data/chicky_512.png", CV_LOAD_IMAGE_GRAYSCALE).copyTo(u2);

    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 61,  CV_INTER_LINEAR);
    imwrite("u2FirstTrytrueAndFalse.png",u2);
    imshow("u2b((ocl=false))",u2);

cv::ocl::setUseOpenCL(false);
    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 25,  CV_INTER_LINEAR);
    imwrite("u2SecondTrytrueAndFalse.png",u2);
    imshow("u2(ocl=true)",u2);

    imshow("src",u1);

    waitKey();
    return 0;
}

same program with opencl false at begining and true after give a good result
int main(int argc, char* argv[])
{
cv::ocl::setUseOpenCL(false);
UMat u1,u2;
    imread("f:/lib/opencv/samples/data/lena.jpg", CV_LOAD_IMAGE_GRAYSCALE).copyTo(u1);
    imread("f:/lib/opencv/samples/data/chicky_512.png", CV_LOAD_IMAGE_GRAYSCALE).copyTo(u2);

    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 61,  CV_INTER_LINEAR);
    imwrite("u2FirstTryFalseAndTrue.png",u2);
    imshow("u2b((ocl=false))",u2);

cv::ocl::setUseOpenCL(true);
    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 25,  CV_INTER_LINEAR);
    imwrite("u2SecondTryFalseAndTrue.png",u2);
    imshow("u2(ocl=true)",u2);

    imshow("src",u1);

    waitKey();
    return 0;
}

I don't understand

Use imwrite for results into .png and attach them.
Are all OpenCV tests pass (OCL_*)?

opencv_perf_imgprocd.zip

    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 61,  CV_INTER_LINEAR);
    linearPolar(u1, u2, Point(u1.cols / 2, u1.rows / 2), 25,  CV_INTER_LINEAR);

the parameters is different 61-25

Yes there is no problem with these parameters it's only to check called linearpolar give differents results with or without opencl

Change UMat to Mat solve the problem.
I'm trying to figure out why UMat fails.
Is ocl designed to support UMat?

linearPolar internally calls
void cvLinearPolar( const CvArr* srcarr, CvArr* dstarr,
CvPoint2D32f center, double maxRadius, int flags )

which use a legacy class CvMat.
It looks like there is something wrong in the conversion path UMat<->Mat<->CvMat. The function works if cvLinearPolar is rewritten with Mat.
Another thing need to point out is that, there is no OpenCL code in cvLinearPolar except the last line,
cvRemap( src, dst, mapx, mapy, flags, cvScalarAll(0) );
which has a OpenCL branch.
However, even that OpenCL branch in cvRemap is not triggered, because cvLinearPolar pass CvMat to it.
I'm going to rewrite cvLinearPolar/LogPolar with a Mat and a UMat version. The UMat version is to advantage of the OpenCL routine in cv::remap.

It turns out that even if the type is change to UMat, the OpenCL branch in remap cannot be triggered.
Because  ocl_remap require mapx & mapy to be CV_16SC1, in the code snippet below
 if (borderType == BORDER_TRANSPARENT || !(interpolation == INTER_LINEAR || interpolation == INTER_NEAREST)
            || _map1.type() == CV_16SC1 || _map2.type() == CV_16SC1)
        return false;

but cvLinearPolar/cvLogPolar create them as CV_32F

I investigated a problem. Problem code is here:
CvMat c_dst = _dst.getMat();

where
_dst is OutputArray from UMat
_dst.getMat() is temporary Mat which holds mapped data from UMat
after this statement "temporary Mat" is destroyed and data is unmapped. CvMat c_dst holds only invalid pointers after this.
Fix for these functions is:
Mat dst = _dst.getMat(); // don't inline this, it holds mapped UMat data for CvMat
CvMat c_dst = dst;

The main question is how to detect/find and fix other broken functions.
/cc @vpisarev

I think we should remove the dependency on CvMat in the master branch.

I trying to catch locations with same problem by adding the move constructor:
#ifdef CV_CXX_MOVE_SEMANTICS
inline CvMat::CvMat(const cv::Mat&& m)
{
    CV_Assert(false && "Don't use: CvMat c_mat = _src.getMat();");
}
#endif

List of failures is here: http://pullrequest.opencv.org/buildbot/builders/precommit_windows64/builds/5383

Hi guys it looks you had deeply investigated the functions... your opinion on #7009 (docs: exchange rho and phi) it's welcome


Generate manifests with containers from local storage (HMS-3235)

osbuild: add containers-storage source
New containers-storage source.
See https://github.com/osbuild/osbuild/pull/1550

osbuild: add containers-storage sources to GenSources()
The local containers are handles along with the other container sources
and differentiated by the value of the StoragePath.

WIP: blueprint: replace container storage args with a bool
NOTE: This commit should be broken up into multiple patches for
readability.
Simplify the way local container storage is handled by adding a boolean
that specifies that a container is local.

The container transport in the local case should always be
containers-storage, so there's no need to force users to specify it
and fail if it's incorrect.
The storage-path could be configurable, but we can get that from the
system config instead.  We should only support pulling from the root
container storage anyway because pulling from a user storage might
cause problems with root modifying files (locks, etc) and owning them,
breaking the user's container store.
The resolver job in osbuild-composer runs on the worker, which runs as
root.
In bootc-image-builder, we run everything as root in the container, so
users would need to mount their root storage into the container at the
root storage path.

I tested this locally and it works with the version of osbuild from https://github.com/osbuild/osbuild/pull/1550
Steps to test:

Build a container locally and put it in the root store

Note: Build something and name it with something like a localhost/ prefix to be sure that it's not pulling the container from a remote.

Create a build config (blueprint) and add the local container name with the option local-storage: true.
Generate a manifest with the config.
Inspect the manifest for the image ID and appropriate source and input for he skopeo stage.

Example
› cat Containerfile
FROM scratch
COPY Containerfile /Containerfile

› sudo podman build . -t localhost/containerfile:latest
[sudo] password for achilleas@Jack:
STEP 1/2: FROM scratch
STEP 2/2: COPY Containerfile /Containerfile
--> Using cache 8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20
COMMIT localhost/containerfile:latest
--> 8117b1097e1c
Successfully tagged localhost/containerfile:latest
8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20

› sudo podman image ls
REPOSITORY               TAG         IMAGE ID      CREATED         SIZE
localhost/containerfile  latest      8117b1097e1c  12 minutes ago  3.54 kB

› cat local-container-config.json
{
  "name": "local-container-config",
  "blueprint": {
    "containers": [
      {
        "source": "localhost/containerfile:latest",
        "local-storage": true
      },
      {
        "source": "docker.io/library/alpine:latest"
      }
    ]
  }
}

› go build -o gen-manifests ./cmd/gen-manifests && sudo ./gen-manifests --metadata=false --distros fedora-39 --arches x86_64 --output ./manifests --images qcow2 --config ./local-container-config.json
[sudo] password for achilleas@Jack:
2024/02/16 20:49:11 Loaded repository configuration file: test/data/repositories/centos-8.json
<snip>
'-config' was provided, thus ignoring '-config-map' option
Collecting jobs
Collected 1 jobs
Initialised 16 workers
Submitting 1 jobs... done
Starting job fedora_39-x86_64-qcow2-local_container_config.json
WARN[0000] Failed to load consumer certs: no consumer key found
No match for group package "plymouth"
No match for group package "dracut-config-rescue"
No match for group package "firewalld"
INFO[0003] Not using native diff for overlay, this may cause degraded performance for building images: kernel has CONFIG_OVERLAY_FS_REDIRECT_DIR enabled
Finished job fedora_39-x86_64-qcow2-local_container_config.json
 == Jobs == Queue:    0  Active:    0  Total:    1
RPM metadata cache kept in /tmp/rpmmd

› grep -C10 8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20 manifests/fedora_39-x86_64-qcow2-local_container_config.json
        {
          "type": "org.osbuild.skopeo",
          "inputs": {
            "images": {
              "type": "org.osbuild.containers",
              "origin": "org.osbuild.source",
              "references": {
                "sha256:05455a08881ea9cf0e752bc48e61bbd71a34c029bb13df01e40e3e70e0d007bd": {
                  "name": "docker.io/library/alpine:latest"
                },
                "sha256:8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20": {
                  "name": "localhost/containerfile:latest"
                }
              }
            },
            "manifest-lists": {
              "type": "org.osbuild.files",
              "origin": "org.osbuild.source",
              "references": [
                "sha256:c5b1261d6d3e43071626931fc004f70149baeba2c8ec672bd4f27761f8e1ad6b"
              ]
--
              "compat": "1.1"
            }
          }
        }
      ]
    }
  ],
  "sources": {
    "org.osbuild.containers-storage": {
      "items": {
        "sha256:8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20": {}
      }
    },
    "org.osbuild.curl": {
      "items": {
        "sha256:006769c1faafdf58f2b730ac871e41f2c5cad1873b62b1108ea3fe1dfe72dcc6": {
          "url": "https://rpmrepo.osbuild.org/v2/mirror/public/f39/f39-x86_64-fedora-20231109/Packages/n/npth-1.6-14.fc39.x86_64.rpm"
        },
        "sha256:00c17c01066b3c4d2d6f64b2ee4a03bac0971183010d485cf3074b24421cbd1b": {
          "url": "https://rpmrepo.osbuild.org/v2/mirror/public/f39/f39-x86_64-fedora-20231109/Packages/o/openssh-9.3p1-9.fc39.x86_64.rpm"
        },

Found a slight bug with this:
"inputs": {
  "images": {
    "type": "org.osbuild.containers",
    "origin": "org.osbuild.source",
    "references": {
      "sha256:05455a08881ea9cf0e752bc48e61bbd71a34c029bb13df01e40e3e70e0d007bd": {
        "name": "docker.io/library/alpine:latest"
      },
      "sha256:8117b1097e1c229713dc483de47423b5d82e6291f1ae7c4510397c6d3d94df20": {
        "name": "localhost/containerfile:latest"
      }
    }
  },

It doesn't like when two different sources are used for the same input, so either we need to handle this in osbuild or maybe add a skopeo stage for the local containers in addition to the stage for containers being pulled in from a repo

Huh.  Wait, I messed up.  The input type for the local should be "org.osbuild.containers-storage" input (since we made a new input type as well).  So the skopeo stage should either have multiple types of input (if possible) or like you said, we should have multiple skopeo stages, one for each input type.

Two things:

Maybe we should split this into two PRs 😅 and have @mvo5's commits in the new PR as a follow up?
Looks like https://github.com/osbuild/osbuild/issues/1611 is hitting us here too.

Two things:
1. Maybe we should split this into two PRs 😅 and have @mvo5's commits in the new PR as a follow up?

[..]
I have no strong opinion either way. Given that we all have it in one place now and my changes are really just shuffling things around we I am slightly in favor of just doing it here in one go but happy to change my mind :)

Thanks everyone for taking care of this!!  <3


Created Test Count Class

Test class that counts number of tests in elegitfx package and fails if greater than one.

@kevinamick , thank you so much for doing this! It's fantastic that you are jumping in to help out.
Your test is working so well that it caught a problem with one of our other unit tests files: TreeLayoutFXTest.java has two tests inside it. For whatever reason, TestFX wasn't breaking on that file, but we nonetheless should have just a single test in there since TestFX might have trouble with it at some point. That's a great find.
Here's the one catch: I don't want to merge this into develop until all unit tests pass; by design, we keep the develop branch in a state where all tests pass. I fully admit that the reason a different test is now failing is because your test is working. That said, since I don't want to merge this and cause tests to start failing, would it be reasonable for me to ask you to modify TreeLayoutFXTest.java as well as part of the same pull request so that it has just one test? I think you could just get away with combining those two tests and making them one; alternatively, you could make it two different classes with a test in each. (That's more of a pain, though, because of the shares setUp code, which shouldn't be duplicated.)

@dmusican, no problem! Happy to help. I'll dig into modifying the TreeLayoutFXTest class tomorrow so that it only uses one test.

@kevinamick Agreed, it's not related to your code. I'm working on it. Stay tuned. :)

Thanks, @kevinamick ! The failing unit test was a known instability of TestFX. I added a rule to the test (all of them, actually) that the TestFX team recommended, which made the problem go away, though it might have gone away anyway... some of those tests sporadically fail due to threading-related issues.
Anyway, your fix is in, and I really appreciate your help. Feel free to jump in and help on future issues.


Add parentheses around specificity values

Fixes https://github.com/Microsoft/vscode/issues/62157

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: tlent sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks a lot!


NVIDIA server downloads fail

Hello @dusty-nv , I know that this is not your responsibility exactly, but several download links are (recently) broken for Jetson-related things, such as SD card images from https://developer.nvidia.com/embedded/downloads (404 Error) . Also,  SDK Manager returns the attached error. My co-worker and I have tried from two different countries. Please forward this problem to whomever is responsible for it in NVIDIA. Thank you.

Hi @tensorturtle, sorry about that, yes we are working to resolve the issue:
https://forums.developer.nvidia.com/t/tensorflow-download-removed/209866/2

Problem appears to have been fixed. Thank you.


YAML Schema for Power Platform Copy Environment Task

Can you provide the full YAML shcema of this task and others in YAML?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e2d7f63d-dcde-f057-555a-3fffce0f229c
Version Independent ID: e4bba5f7-ae53-260f-269b-c8ad002ef696
Content: Build tool tasks - Power Platform
Content Source: power-platform/alm/devops-build-tool-tasks.md
Service: power-platform
Sub-service: alm
GitHub Login: @mikkelsen2000
Microsoft Alias: pemikkel

@gregdegruy I added the YAML snippets for each task. If this is not what you are asking for, file a new issue.


[now dev] Error when starting, complaining about npm package "go"

❯ now dev
> Now CLI 16.1.4-canary.17 dev (beta) — https://zeit.co/feedback/dev
> Error! Command failed: /Users/aaron/.nvm/versions/node/v10.15.3/bin/node /Users/aaron/Library/Caches/co.zeit.now/dev/builders/yarn add --exact --no-lockfile --non-interactive @now/build-utils@latest @now/next
error An unexpected error occurred: "https://npm.pkg.github.com/@now%2fgo: npm package \"go\" does not exist under owner \"now\"".

Looks like its because i changed my registry.... smh yarn


Added two stats

Having the count of cached entries is useful to us. Tested against Unbound 1.7.2

Thanks!


Fix check_data.c to compile under musl-libc

Running make full-check on musl systems fails because:
tests/check_data.c:6:10: fatal error: error.h: No such file or directory
 #include <error.h>
          ^~~~~~~~~
compilation terminated.

as check_data.c does not use any of the functions defined in the library, it's safe to make this change.

@finnoleary Hmm, if unused why not just remove the #include altogether? Checked locally (so glibc) and at least all the test pass with that #include removed.

Just caught this. That's a fair option, I wasn't sure if it was a reminder to use it in the future :)

This being my first "larger" project in C... I have neither recollection nor idea :)

@finnoleary Thanks for contributing!


Update how-to-restart-server-portal.md (Typo "flexible server"→"Flexi…

…ble Server")
https://github.com/MicrosoftDocs/azure-databases-docs/blob/main/articles/mysql/flexible-server/how-to-restart-server-portal.md
#PingMSFTDocs

@code-sidd
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Command to switch pull-request base

Q
A

Bug report?
no

Feature request?
yes

BC Break report?
no

RFC?
no

We had this in Gush (mainly for contributors), but since GitHub allows to update pull-request of a contributor (unless disabled) it makes sense to have it in Hubkit also.
This makes it easier to help contributors without having to perform complex Git operations or resorting back to local Git merges and closing a pull-request (like Symfony's GH does).

This should also post an automatic reply (except when switching your own pull-request) to inform the base was changed and the author needs to reset it's local branch to ensure there are no conflicts when adding new commits.

Related to #16

Closed by #45


CLOUD-48264 Update consul watch container

@doktoric plz review

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2114/


Bug fixes for manga dataset creation

This PR closes #100.  It fixes a few bugs when creating the hugging face dataset.  The following issues were fixed:

The spaxel 1d array data for flux, ivar, mask, lsf, and lambda were not in the proper shape of [1, nwave]
The incorrect data extension was accessed for the MASK arrays.  This was causing some improper int/float conversions.
The spaxel_idx had the incorrect integer type.

This will require regeneration of the manga healpix files from the original dataset.  Once re-run, the code snippet from #100 should run.  Additional checks may be needed to ensure everything else in the hf dataset looks ok.

Thanks Brian, it looks very good. I'm currently doing a production run with these modifications and checking that everything works. Will merge once that's done.

@EiffL is there a progress update on this?  Did everything run ok?  Is there anything more I can do?

Hi Brian, I'm running into problems when trying to run the production code, my parallel processing script hangs and times out. I didn't have these issues before but I haven't yet figured out why this happens. A couple of healpix cells process just fine, and then it stops.

Hmm, that is strange.  Nothing has changed with the healpix generation code.  Could it be an issue with size of the healpix resolution (_healpix_nside)?   You already have all the data locally?  Does it always stop at the same data files each time you run it?

Yes, I have all the data locally. I suspect it's one of these that fails:
https://github.com/MultimodalUniverse/MultimodalUniverse/blob/2cca60efbea8b72c0edd6f512ad1e2e2e60d3c9e/scripts/manga/build_parent_sample.py#L298
But I haven't been able to get an error yet

I think I need to run without the multiprocessing to see what the issue is

Superseded by #129.


[.NET] Q: AdaptiveContainer

I've been looking at the code base and I'm wondering why ColumnSet, ImageSet, FactSet are not derived from containers, as these objects contain elements in the form of Colums, Images, Facts ?
I'm also wondering why AdaptiveColumn, AdaptiveImage, AdaptiveFact don't derive from the AdaptiveTypedElement?  IMHO if they did it would make parsing/rending/databinding code easier to write as these base classes express/group object into their classification and provide common attribute/notation for de/serialization & converting.

For the first question: Containers take a list of AdaptiveElement, whereas FactSet only takes a list of Fact items. If we made FactSet (and the others) derive from container, then we wouldn't be able to enforce the type restrictions. We could use generic types and have a common base class, but we decided to leave them separate.
For the second question: They do? AdaptiveColumn and AdaptiveImage derive from AdaptiveTypedElement (that's their root base class).
It's only AdaptiveFact that does not, but that's because AdaptiveFact doesn't require the type property. It still certainly could benefit from the AdditionalProperties though, so a smaller base class could certainly make sense.
Closing this for now, re-open if you have more questions!


Add scanning frame, only read the QR code in the scanning frame

Add a scanning box in the middle of the scanning area, crop the QR code in the scanning box in the video source, and only parse the QR code in the scanning box
You can refer to this: https://github.com/zxing-js/library/issues/39#issuecomment -769339674

Because this requirement is relatively personalized, there are currently no plans to add it to the component. but if you have a sample, we wellcom for your PR.


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-26-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2664

Questions ?
Please refer to the Backport tool documentation


[Feature]: Support for Lightning-flash

Describe the feature you'd like
Lightning-Flash is high-level deep learning framework for fast development and deployment.
It would be nice to have as part of the ZenML stack.
How do you solve your current problem with the current status-quo of ZenML?
Currently, we used Custom Materializer to store and load artifacts by following this link. But we're having problem.
StepInterfaceError: Materializer source `main.CustomImageClassificationData` for output 'datamodule' of step 'training_data_loader' does not resolve to a  `BaseMaterializer` subclass.

Thanks for the feature request! Usually feature requests go here but ill keep this thread open to ask you the following:
Could you paste in your custom materializer and pipeline code so we can debug it? It would help is in supporting lightning flash better

I have followed simple tutorial provided by lightning flash. And here is the link
from zenml.pipelines import pipeline
from zenml.steps import Output, step
from zenml.materializers.base_materializer import BaseMaterializer
from zenml.artifacts import DataArtifact, ModelArtifact
from zenml.io import fileio

import flash
from flash.image import ImageClassificationData, ImageClassifier

from typing import Type, Any

class CustomImageClassificationData(BaseMaterializer):
    ASSOCIATED_TYPES = (ImageClassificationData,)
    ASSOCIATED_ARTIFACT_TYPES = (DataArtifact,)

    def handle_input(self, data_type: Type[ImageClassificationData]) -> ImageClassificationData:
        super().handle_input(data_type)
        with fileio.open(os.path.join(self.artifact.uri, 'data.txt'), 'r') as f:
            lines = f.readlines()

        train_folder = lines[0].replace('\n', '')
        val_folder = lines[1].replace('\n', '')
        batch_size = lines[2].replace('\n', '')
        transform_kwargs = lines[3].replace('\n', '')

        return ImageClassificationData.from_folders(
            train_folder=train_folder,
            val_folder=val_folder,
            batch_size=int(batch_size),
            transform_kwargs=json.loads(transform_kwargs)
        )

    def handle_return(self, data: ImageClassificationData) -> None:
        """Write to artifact store"""
        super().handle_return(data)

        folder = data._train_input.data[0]['input'].split('train')[0]
        train_folder = folder + 'train/'
        val_folder = folder + 'val/'
        batch_size = data.batch_size
        transform_kwargs = str({"image_size": (196, 196), "mean": (0.485, 0.456, 0.406), "std": (0.229, 0.224, 0.225)})
        with fileio.open(os.path.join(self.artifact.uri, 'data.txt'), 'w') as f:
            f.write(train_folder + '\n')
            f.write(val_folder + '\n')
            f.write(str(batch_size) + '\n')
            f.write(str(transform_kwargs) + '\n')

@step
def training_data_loader() -> Output(datamodule=ImageClassificationData):
    datamodule = ImageClassificationData.from_folders(
        train_folder="data/hymenoptera_data/train/",
        val_folder="data/hymenoptera_data/val/",
        batch_size=4,
        transform_kwargs={"image_size": (196, 196), "mean": (0.485, 0.456, 0.406), "std": (0.229, 0.224, 0.225)},
    )
    return datamodule

@step
def train_flash(
    datamodule: ImageClassificationData
) -> Output():
    model = ImageClassifier(backbone="resnet18", labels=datamodule.labels)

    trainer = flash.Trainer(max_epochs=3, gpus=torch.cuda.device_count())
    trainer.finetune(model, datamodule=datamodule, strategy="freeze")
    return trainer

@pipeline(enable_cache=False)
def training_pipeline(
    training_data_loader,
    trainer,
):
    datamodule = training_data_loader()
    trainer(datamodule)

training_pipeline(
    training_data_loader=training_data_loader().configure(output_materializers=CustomImageClassificationData),
    trainer=train_flash(),
).run()

@Erdene-Ochir0417
Ah, you just unveiled a bug in our docs! The .configure() function does not return the step in the latest  change, as the docs incorrectly stated! Thank you so much for the report. I took the liberty of finishing off your work. there were some other minor bugs around json.loads() and also the fact that it has to be under __main__ == __name__ block:
from zenml.pipelines import pipeline
from zenml.steps import Output, step
from zenml.materializers.base_materializer import BaseMaterializer
from zenml.artifacts import DataArtifact, ModelArtifact
from zenml.io import fileio
import torch
import json
import os
import flash
from flash.image import ImageClassificationData, ImageClassifier

from typing import Type, Any

class CustomImageClassificationData(BaseMaterializer):
    ASSOCIATED_TYPES = (ImageClassificationData,)
    ASSOCIATED_ARTIFACT_TYPES = (DataArtifact,)

    def handle_input(self, data_type: Type[ImageClassificationData]) -> ImageClassificationData:
        super().handle_input(data_type)
        with fileio.open(os.path.join(self.artifact.uri, 'data.txt'), 'r') as f:
            lines = f.readlines()

        train_folder = lines[0].replace('\n', '')
        val_folder = lines[1].replace('\n', '')
        batch_size = lines[2].replace('\n', '')
        transform_kwargs = lines[3].replace('\n', '')

        return ImageClassificationData.from_folders(
            train_folder=train_folder,
            val_folder=val_folder,
            batch_size=int(batch_size),
            transform_kwargs=json.loads(transform_kwargs)
        )

    def handle_return(self, data: ImageClassificationData) -> None:
        """Write to artifact store"""
        super().handle_return(data)

        folder = data._train_input.data[0]['input'].split('train')[0]
        train_folder = folder + 'train/'
        val_folder = folder + 'val/'
        batch_size = data.batch_size
        transform_kwargs = json.dumps({"image_size": (196, 196), "mean": (0.485, 0.456, 0.406), "std": (0.229, 0.224, 0.225)})
        with fileio.open(os.path.join(self.artifact.uri, 'data.txt'), 'w') as f:
            f.write(train_folder + '\n')
            f.write(val_folder + '\n')
            f.write(str(batch_size) + '\n')
            f.write(transform_kwargs + '\n')

@step(enable_cache=False)
def training_data_loader() -> Output(datamodule=ImageClassificationData):
    datamodule = ImageClassificationData.from_folders(
        train_folder="data/hymenoptera_data/train/",
        val_folder="data/hymenoptera_data/val/",
        batch_size=4,
        transform_kwargs={"image_size": (196, 196), "mean": (0.485, 0.456, 0.406), "std": (0.229, 0.224, 0.225)},
    )
    return datamodule

@step
def train_flash(
    datamodule: ImageClassificationData
) -> None:
    model = ImageClassifier(backbone="resnet18", labels=datamodule.labels)

    trainer = flash.Trainer(max_epochs=3, gpus=torch.cuda.device_count())
    trainer.finetune(model, datamodule=datamodule, strategy="freeze")
    return trainer

@pipeline(enable_cache=False)
def training_pipeline(
    training_data_loader,
    trainer,
):
    datamodule = training_data_loader()
    trainer(datamodule)

if '__main__' == __name__:
    t = training_data_loader()  # the main error
    t.configure(output_materializers=CustomImageClassificationData)

    training_pipeline(
        training_data_loader=t,
        trainer=train_flash(),
    ).run(unlisted=True)

If you would like to see official support for Lightning, please consider making a PR to the repository following the external integrations guide which would help us immensely! All we really need is the above materializer with perhaps more robust and tested functions, and maybe include more types from the flash library.
Hope that all makes sense!

@Erdene-Ochir0417 Let me know if it worked please so I can close the issue :-)

@htahir1
I apologize for the delay in my response. It works correctly. I will close the issue. Thank you.


Recommend declaring annotations as api

Currently, dependency-analysis-android-gradle-plugin recommends downgrading org.apiguardian:apiguardian-api from api to implementation for Apache Calcite, however, that dependency should always be on the compile classpath.
Just in case, apiguardian-api is a single-annotation dependency: https://github.com/apiguardian-team/apiguardian
Here's a case by JUnit5 jhttps://github.com/junit-team/junit5/issues/1105
Similar case by Guava https://github.com/google/guava/issues/2824
Caffeine https://github.com/ben-manes/caffeine/issues/300
As far as I understand, many compilers need annotation classes for proper compilation (e.g. Error Prone compiler needs annotation definition for proper verification), so projects like Guava, JUnit5, Caffeine settled on using <scope>compile</scope> for their annotations.
It looks like dependency-analysis-android-gradle-plugin should suggest upgrading annotation dependencies to api in case they are used in public-like methods/classes.

I read through the junit discussion and it was very interesting -- thanks for linking. Have you tried to follow the (perhaps inaccurate) advice and downgrade apiguardian to implementation? And if so, what was the result? Did you see issues similar in nature to what the junit team discussed?

I have a PR now resolving this issue. Annotations on public types will now be considered part of the ABI.


i18n: rake gettext:store_model_attributes wouldn't create entries for model relations

rake gettext:store_model_attributes scans through application models and creates
config/model_attributes.rb file containing gettext strings representing all model attributes.
...
_('Host|Admin disabled')
_('Host|Asset tag')
_('Host|Connection state')
...

As things are, the task won't put model relations into the above file (for example Host|Miq templates
is missing in the above file).
Anytime our application would call human_attribute_name(), trying to get a nice & translated
string for an attribute / relation that isn't in model_attributes.rb (and therefore also is not in
translation catalogs), translation (or a nice human name) will not be found and the routine
just returnes titleized attribute name.
We need to investigate / find a solution for this problem (whether this will be a fix in our code
or a gem we use).

@mzazrivec if this issue is no longer relevant then please close.


⚠ Fetchers has degraded performance

In 4556d74, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 266 ms

Resolved: Fetchers performance has improved in a364394.


DEPLOY - Updates to Testnet  (staging)

This part needs an update to reflect 3Bot deployment.

[x] DECENTRALIZE YOUR APPLICATION -> DEPLOY ON THE THREEFOLD GRID

[x] Download and install the 3Bot application to move your workload over today.
-> ...via 3Bot, your virtual system administrator.

[x] install
the 3Bot
application
->
Install the 3Bot Connect mobile app.

[x] 2
Launch
The ThreeFold Marketplace
->
2
Deploy your virtual system administrator on the ThreeFold Grid.

[ ]

-> DEPLOY 3BOT
(remove BETA from button)
deploy3bot.testnet.grid.tf

[x] add section 3 with the old TFT image we had and removed for step 2 in a previous version of the website.

->
3
Get FreeTFT on Testnet
Button: FreeTFT Faucet
gettft.testnet.grid.tf

A few minor changes:

[ ]

move linebreak to after "Connect"

[ ] "your virtual system administrator on the ThreeFold Grid." ->"your virtual system administrator on the ThreeFold Grid Testnet."

[ ] GET
FreeTFT on Testnet
->
CLAIM
your FreeTFT for testing purposes.

done at staging

[ ] add text below GET TFT
to run almost any application on the ThreeFold Grid.

one last change

[ ] "application" -> "Connect mobile app"

[ ] then push to production


BitBuckets download site incorrect permissions

Not sure if intentional, but users can upload their own files on the download page
https://bitbucket.org/iBotPeaches/apktool/downloads
Could not find how to contact you through BitBucket so I had to do it here.

Thats great...
Thanks for heads up, looking into it.

This has been fixed. Thanks for the heads up.


fixing GPU memory leak in order_1_approx

I find then when I run scripts.sweep, I get OOM errors. It looks like there's an explicit OOM error handling path in the code, suggesting this is a common occurrence for running this script.
It looks like this is related to the order_1_approx() function, and I find that by adding .detach().clone() to the weight and bias it seems to alleviate the issue and I no longer get the OOM errors.  This is just my guess though, and I haven't done a memory profile to prove that's what going on.

I may have been too optimistic about this - I find that I still get occasional OOM errors with this PR, although they're much less frequent. Given that, I'm not sure if it makes sense to merge this or not as it doesn't seem to 100% solve the issue.

I think this fix should be correct now. I somehow overlooked the final tensor return value Jh in metadata. I updated the PR so this value as well has .detach().clone() called on it. I've been running the sweep script on a 24gb GPU for the past hour with no memory issues, so hopefully this means the leak is fixed.

closing for now as I'm not convinced this is fixing the core issue


Using Constructor Injection with the MessagesController

I have a service that I want to inject into my MessagesController but I can't as it says that it requires a parameterless constructor. I know, from reading earlier that you already use AutoFac which is what I want to use.
But what is the best way to inject this dependency into the controller? @willportnoy has mentioned elsewhere that it is best to avoid using the Service Locator pattern so I am at a bit of a loss here.
How do you advise I move forward?

Add @willportnoy  to comment.

What container are you using to resolve your MessagesController?  Can you specify the constructor you want to use?
http://docs.autofac.org/en/latest/register/registration.html#specifying-a-constructor

I managed to get this working by setting the HttpConfiguration property on the HttpConfiguration in the WebApiConfig


nudge log path

where should it go?

~/Library/Logs/Nudge seems to be the standard

yes, the user directory makes it easier when it comes to permissions.

That's where it will be then.


Add frontend support for xpedite profiling probes

Adds some basic plumbing to allow for injecting known no-op caves into
Hobbes code for instrumentation purposes (profiling, crazy code injection and so on).
Supports the following:

injectProbe :: ([char]) -> () 5 byte nop cave emission (also emits
metadata to stackmap section of executable blob) op.
Probe TString unqualifier that wraps constrained expression to have
named .start and .end probes injected around code-gen.
Doesn't compile when used on all expressions (e.g. lambda definitions)
Registering of information about injected probes with compiler.
Parsing the LLVM stackmaps as far as needed for this feature.

Does not currently support:

Dumping cave locations in such a way that some external
instrumentation can be done via the code caves.
Full source location information of probes.
Support for multiple defined probes of the same name is untested.
Non-x86_64 platforms. LLVM only support stackmaps under a handful of 64-bit platforms. We
explicitly use inline assembly to insert the no-op to work around LLVM bugginess, which is platform
specific.

Notes:

llvm patchpoints are utterly broken for x86_64 on llvm v6+. Use
platform specific stackmap into inline asm 5-byte nop instead.
llvm5+ doesn't support parsing the very stackmaps it emits.
This is not fixed until 9.

Originally intended to allow injection of instrumentation into Hobbes generated code for Xpedite, but the remaining work for integration has been left out. Only the more general implementation has been left as integrating with Xpedite would likely require pulling it in as a dependency at the moment due to some usage requirements. LLVMs JIT instrumentation support is fairly derelict in recent years & generally sub-par, so I am unsure as to the forward maintainability of this code, but the injection of and registering of named code caves works as of now, even if nothing is actually done with that feature.

Interesting change!  Is the objective just to probe latency or are we looking for other information?  This seems like a good first step that has a lot of room for growth.

LLVMs JIT instrumentation support is fairly derelict in recent
years & generally sub-par

To be honest, my impression is that JIT support is of secondary importance to LLVM generally.  That's why I added this PR (https://github.com/Morgan-Stanley/hobbes/pull/291) to provide an alternative backend.
Realistically, our only target is x86_64, and we can cut through a lot of boilerplate if we produce data/code ourselves.  Chasing the many versions of LLVM and breaking/changing abstractions there is a waste of time IMHO.  x86 machine code format is a fixed point, and there are only a couple of things that we need on top of that to make useful progress (move-coalescing register allocation for example, as implemented in my PR).

If this feature was used to integrate with something like Xpedite it would mean being able to get things like:

Timings between probes (particularly useful for measuring execution of expressions wrapped in
the Probe unqualifier).
Performance counter information.
Comparison to baseline performance recordings.

All without having to have the instrumentation embedded on initial compile. So core use-case is probably low-cost live performance instrumentation, debugging, logging etc.
Having said all that, we're still some ways from being able to actually get that working, but the concept of being able to insert and track enough space for some arbitrary jmp in some compiled Hobbes code could be quite useful. For example, temporarily injecting some jmps to code measuring which rules in a Hobbes-based rules engine get fired and how often. My imagination isn't quite wild enough to come up with more ideas on the spot unfortunately.
LLVMs JIT support is decaying due to lack of users. From what I can find out nobody openly uses patchpoints (or even stackmaps) at the moment, and haven't done since webkit ditched LLVM in favour of their own home grown B3 JIT, and Dropbox's Pyston Python JIT was abandoned. The particular segfault issue has been present for at least 2-3 years and hasn't had a single bug report despite being on x86_64. Additionally I had to work around a problem where they bumped the stackmap format version several years ago, and never updated the associated parsing code (until just this April in v9). All of this leads me to believe it's not worth trusting LLVM for this stuff. Certainly, using your new backend library should make integrating things like this considerably easier.

If this feature was used to integrate with something like Xpedite it would mean being able to get things like:

Timings between probes (particularly useful for measuring execution of expressions wrapped in
the Probe unqualifier).
Performance counter information.
Comparison to baseline performance recordings.

All without having to have the instrumentation embedded on initial compile. So core use-case is probably low-cost live performance instrumentation, debugging, logging etc.
Having said all that, we're still some ways from being able to actually get that working, but the concept of being able to insert and track enough space for some arbitrary jmp in some compiled Hobbes code could be quite useful. For example, temporarily injecting some jmps to code measuring which rules in a Hobbes-based rules engine get fired and how often. My imagination isn't quite wild enough to come up with more ideas on the spot unfortunately.
LLVMs JIT support is decaying due to lack of users. From what I can find out nobody openly uses patchpoints (or even stackmaps) at the moment, and haven't done since webkit ditched LLVM in favour of their own home grown B3 JIT, and Dropbox's Pyston Python JIT was abandoned. The particular segfault issue has been present for at least 2-3 years and hasn't had a single bug report despite being on x86_64. Additionally I had to work around a problem where they bumped the stackmap format version several years ago, and never updated the associated parsing code (until just this April in v9). All of this leads me to believe it's not worth trusting LLVM for this stuff. Certainly, using your new backend library should make integrating things like this considerably easier.

I'm sorry to hear about your pain going through this, but also relieved that I'm no longer the only one feeling the pain here! :D
Very cool on the performance monitoring points, definitely agree that's useful!

To clarify on what's missing for a full Xpedite integration here:

Dumping probe information to an expected format on disk (something-appinfo.txt, non-fixed format, internal to xpedite).
Handling Xpedite's expectation of opening a remote port and communicating with Xpedite. This appears to be the case even on same-box profiling via the loopback mechanism, and also can't be turned off (I think?).

Both 1 and 2 likely can be fixed by pulling in the Xpedite library as a dependency, which isn't something I want to push for until the dust has settled on other in-progress dep upgrades. We may be able to get away without pulling it in if we can get some changes made on their side (publicly documenting & fixing the disk format, and likewise for the networking features).

Nice work !
Pardon my ignorance, but what's the purpose of probing code injection into LLVM generated code ? Why can we not simply add Xpedite probes in the client consumer code ?
hobbes::cc cc;
auto fn = cc.compile<double()>("\\_.sin(10)");
// client code
auto main() -> void {
  // probe.start;
  fn();
  // probe.end;
  return 0;
}

llvm patchpoints are utterly broken for x86_64 on llvm v6+. Use
platform specific stackmap into inline asm 5-byte nop instead.
llvm5+ doesn't support parsing the very stackmaps it emits.
This is not fixed until 9.

Yeah, this gets worried about maintainability of this code. What do you think of stashing this off into a separate branch of its own ?
Also, I'd rather leave it to the interested users to combine Hobbes with Xpedite in order to run his perf benchmarks. What do you think ?

@smunix brings up a good point, which is that typical uses of hobbes would just generate different functions -- one with instrumentation and one without -- rather than patching code in place.  It's much simpler to atomically update one function pointer, has the same effect, and doesn't break modularity.
Given that this complicates our integration with LLVM and possibly complicates our dependency story if you're proposing integration with Xpedite (and/or Xpedite file formats), would you say that the benefit is worthwhile by comparison?
Why not generate different functions (allowing the user to choose whatever performance tracking method they want)?

To clarify what I had in mind with the particular use-case for this PR, because it'll make it easier to discus what we actually want in terms of profiling:
To add fine-grained, expression-based, performance-sensitive, toggle-able performance counter-based profiling via Xpedite to all Hobbes code.
It's worth discussing whether we actually want every facet of this because it affects the design.

If we don't care about being fine-grained with instrumentation placement, then going with the C++-level, client deferred approach brought up by @smunix makes a lot more sense. Measuring more complex and higher Hobbes-to-C++ ratio code-bases would be much more difficult with this approach due to lack of ability to easily and flexibly measure elements of the Hobbes code below the top-level boundary between C++ and Hobbes generated code. Clients may be able to architect their way around this by wrapping more individual Hobbes functions in C++ functions with probes, and then calling into these from the Hobbes code. Under this implementation, probe placement would be static and determined by the C++ code, requiring a recompilation of the C++ code-base on change, rather than defined by the Hobbes script. These all may be acceptable trade-offs depending on your purposes.

If we don't care about being able to do this kind of fine-grained profiling in a performance-sensitive environment (toggle-able probes), then we don't even need Xpedite style probes: You can just use a sampling profiler such as Linux Perf to measure Hobbes machine code invocations from C++ with minimal changes.

If we don't care about leveraging existing Xpedite tooling for profiling (probes, graphing, baseline comparisons, probe-to-probe measurements, tracking probes back to specific lines of code, remote profiling and so on) then it may be worth considering separately re-implementing a subset of the needed features for our profiling use-case, provided we actually want probes at all.

If we are willing to change the manual, user-applied approach provided in this PR to some automatic probe injection done by a compiler switch, it would likely mean injectProbe and ProbeP would still be used underneath, but in a way hidden from the user. The onus of using this feature would probably just be shifted to the person attempting to make sense of thousands of auto-generated probes in profiling results.

NOTE: Any approach attempting to integrate with Xpedite would need to pull it in as a library dependency. If we let the clients manually define probes in their C++ code using only Xpedite provided facilities, then this PR is both totally unnecessary and we can defer the need for the Xpedite dependency to the end-client. In other words, no work is required on our end. I am not opposed to this at all so long as it provides a rich enough feature-set.
With respect to the maintainability of LLVM stackmaps & inline no-ops:
Under LLVM, the Stackmap functionality is pretty much necessary in order to know where the probe code caves actually are in the generated binary. There are two intrinsics for this: patchpoint, and stackmap See here for details. Stackmap records the location of the intrinsic to a data section in the emitted binary. Patchpoint is essentially stackmap followed by guaranteed reserved no-op space of a given size in generate machine code (a code cave). Patchpoint is broken for x86_64 when followed by a call instruction in the same function IR (an extremely common pattern) as it segfaults during the machine lowering phase with LLVM v5+. The stackmap intrinsic is not broken. The stackmap intrinsic followed by manual inline asm no-ops is a workaround to the segfault issue that emulates patchpoints when they are working.
As mentioned earlier in this thread: It seems nobody uses the stackmap/patchpoint functionality nowadays, and so it has become somewhat derelict; these features are for JIT use, and LLVMs support as a JIT backend tends to be limited for various reasons. There are questions as to its forward reliability.
No-op insertion can be abstracted to any platforms with a no-op instruction fairly easily, but LLVM stackmaps & patchpoints are only available on a few 64-bit platforms (x86_64, Aarch64, SystemZ, PowerPC), and have demonstrated themselves to be very unreliable between major versions. They are, however, absolutely necessary for doing this kind of code cave injection without resorting to other platform specific hacks (manual no-op insertion with some convoluted way of tagging the location in the emitted executable blob for external injection).

If we don't care about being fine-grained with instrumentation placement, then
going with the C++-level, client deferred approach brought up by @smunix
makes a lot more sense.

But those aren't the only two options right?  What I mentioned before was that the typical way to do "code patching" with hobbes is to generate a fresh function rather than modifying a previous function in place -- could you address this approach?  That way would also get you fine-grained profiling and would be consistent with the way that hobbes is typically used.
Also if you do it that way, you can bolt on something like your ProbeP from outside hobbes so that we don't need to add to our dependency set.
What do you think?

This thread seems to have gone stale.    Maybe revisit with the alternative backend (no LLVM)?

I think the idea still has legs, but unfortunately I don't have any time to commit to this project at the moment (and neither am I at MS at the moment), so at any rate unless somebody else jumps on this particular PR it's probably dead in the water. I don't imagine the llvm or xpedite portions are up-to-date with changes that have been made since work was done this either, but this may be less of a stumbling block if it gets retargeted to the alternative backend.

Yes agreed it's a good idea, and clearly you put a lot of work into it, so it'd be a shame to lose it.  I'll leave it for a while at least, maybe somebody who works on xpedite will want to look at it.
I felt your pain w.r.t. LLVM's JIT support, definitely not their focus.
What are you working on these days?

If I learned anything from working on this particular PR, it's that trusting anything outside of the IRBuilder in LLVM to either stay stable or actually work properly between versions is a poor bet to be making. It's great when it works, but...
I went back to finish up my final year in university, so nothing too interesting going on for my part. Who knows what'll end up happening in a few months time. I hope you're also doing well despite everything going a bit awry in the world.

Shelving this PR since we've been cleaning up old PRs lately and this one doesn't have an active developer.  There are a lot of good ideas here, and performance is very important so I'm sure this will come up again in some form.


Call to dataView icon from another button

What problem does this feature solve?
Hi! I have been woorking with Angular and echarts in a proyect, and a i want to see the dataView table from another button. I read in the API Documentatión that i can call to echarts functions with the dispatch funcition, something like that
this.echartInstance.dispatchAction({ type: 'restore' });
But i cant do what i want with any action or events. Maybe is not possible for now??
I attach two images, the first is what i got now, the dataView icon (with label"A"), and the button (with label"B") what i want to have the same behaviour that the dataView icon.

The second image show what i got when i press the dataView icon, i want the same bhaviour when i press the another button.

Any ideas or advices? Thanks a lot !
What does the proposed API look like?
Maybe something like
echartInstance.dispatchAction({ type: 'show dataView' });
For show and hide the dataView table.

Please check http://echarts.apache.org/option.html#toolbox.feature for custom toolbox features.

Please check http://echarts.apache.org/option.html#toolbox.feature for custom toolbox features.

Thanks for the answer! But i want to call a toolbox feature from a button outside echarts (whit the echartInstance), not create a custom feature.

Hi, I need this feature too. I'd like to use
myChart.dispatchAction( type: 'dataView' }
or something similar to open the chart dataView.
This is not working, there isn't a dataView event on documentation either similar event.
How clould open the data view with toolbox no visible?

Can you provide an online demo about what you have done now? http://jsfiddle.net

Yes, i paste the link below
http://jsfiddle.net/8wa3e9cz/2/

The desire behaviour of the button with label A is show the table with the data, the same table that show the icon with label B

It seems that you are still using ECharts 2, which is not supported any longer. Please try with the latest version, and if there's still a problem with this, just let me know.

I use the latest version in my project, the online demo is only a example of the desire beahviour.

I update the example with the last versión and added some things, trying to explain the more the problem.
http://jsfiddle.net/dv9g4z3u/4/

Hi, I need this feature too. I'd like to use
myChart.dispatchAction( type: 'dataView' }
or something similar to open the chart dataView.
This is not working, there isn't a dataView event on documentation either similar event.
How clould open the data view with toolbox no visible?

I also need this feature.

Any updates on this (no doubt valid) feature request?

Any updates on this (no doubt valid) feature request?

Any updates? This is something we need aswell.

Please follow #17849


Use on Android tcp-over-http

Hi.
This looks great ! .
Can be possible to use this on Android as client and the server on a VPS to create a tunnel and use it like VPN ?
Can someone can create a app that allow http headers request, please ?
This way we can use it bypass firewall from ISP and many people can use this excellent program .
I hope your answers.

Hello,
Yes, I've actually thought about running the client on a phone, however I haven't got enough time to implement this in practice. I will do this eventually.

I will wait for it , I hope , I don't die before use it .
I really would like to use it . Thanks


Forecast calls for a partially sunny... night time?

Perhaps a bright sun peaking out from behind the clouds isn't an ideal way of representing Partly Cloudy for the Night time period?

Would also be curious if the oneline format at night could be moon icon instead of sun icon :)

Duplicate of Issue #258
...

This and #258 are actually duplicates of an older issue, #52.

I think we should close both this and #258 in favor of #52.
And the only reason why #52 is still open (besides the implementation itself, of course)
is the "One weather condition - one notation." controversy.
Probably, we should just implement it and add an configuration option for the "sunny night" format


message_history: Migrate to handlebars.

Testing plan:
GIFs or screenshots:

Merged, thanks @ganpa3!  The migration noted in this TODO would be a fine follow-up project.

Merged, thanks @ganpa3! The migration noted in this TODO would be a fine follow-up project.

@timabbott #18874


EASI-2093/db audit paradigm adr

EASI-2093
Changes and Description

Introduce ADR for auditing

POC branch

How to test this change

PR Author Review Checklist

[ ] Met the ticket's acceptance criteria, or will meet them in a subsequent PR.
[ ] Added or updated tests for backend resolvers or other functions as needed.
[ ] Added or updated client tests for new components, parent components, functions, or e2e tests as necessary.
[ ] Tested user-facing changes with voice-over and the rotor menu

PR Reviewer Guidelines

It's best to pull the branch locally and test it, rather than just looking at the code online!
Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.
Always make comments, even if it's minor, or if you don't understand why something was done.

Hey @StevenWadeOddball! I looked at the POC branch and saw a few migrations that looks like they were all comments - can you provide an overview of the different migrations? (I can't say I've worked much with triggers this complex, they're a bit over my head!)

Hey @StevenWadeOddball! I looked at the POC branch and saw a few migrations that looks like they were all comments - can you provide an overview of the different migrations? (I can't say I've worked much with triggers this complex, they're a bit over my head!)

Great question @ClayBenson94! So the first few migrations on the POC branch are some of my musings about how we might want to structure our specific implementation.  The bread in butter for functional testing is migration 22, which is an example I got from https://wiki.postgresql.org/wiki/Audit_trigger_91plus. I think it is a pretty good starting point! But we'd want to change some details in it (eg, we don't need to store quite as much information as it's storing, and we probably want to abstract some data into practical fields (eg primary key, foreign key etc).
It creates the table logged_actions, and inserts data there for every changed operation.  It sets up the trigger here, and then creates some wrapper functions to set the auditing on on a table level. (I've implemented that here on model plan).
The data right now is being stored in hstore format. You can see in this area, the trigger is casting old and new values into an hstore, and writing to the table.
So, every time the table is modified, a row gets written here. Further changes would be to add ignored fields (modified by, modified_dts etc).
We can query this data with something like this
SELECT
row_data ->'id' as ID,table_name,transaction_id,
(EACH(changed_fields)).*

from audit.logged_actions where

row_data ->'id' ='6e224030-09d5-46f7-ad04-4bb851b36eab'

That returns a result like this

I'm happy to demo it sometime too if you like!


Textures and map are not included

Hi,
I would like to see the map.tmx and the assets included in the project here. I hope you still have them; would like to test a few things on your code.
Kind regards,
MagicLegend

Found it. Had to change my working dir to PlatformerTutorial-master\core\assets works now :)


20231215 recharacterisation of q1 and q2 of spinq10q (qblox)

Assignment fidelities of ~80%

qubit
T1
T2

q1
15129
196

q2
10512
67

I was able to perform cz chevron:

@PiergiorgioButtarini @GabrielePalazzo @andrea-pasquale maybe we can close this since most likely it won't work anymore and we already merged the updated spinq10q runcard with the new configuration, right? If yes, please close.


Tab auto-complete regression

System Details

posh-git version: https://github.com/dahlbyk/posh-git/commit/efed853aa5c5ab235ded5c1a191fac189470eb28
PowerShell version: v6.2.3

Issue Description
PR #711 caused a regression that broke tab completion on PowerShell >= 6, causing:
git <command> \t

To incorrectly expand to:
git <command> <command>

Instead of what it expanded to in commit https://github.com/dahlbyk/posh-git/commit/89dafc1f37d9a44917d5ce6a84e889e54c6f98b9, which is what I was forced to roll back to.

Not sure if it's actually an regression, currently the new git command git switch <branch> doesn't work with tab-completion though.

If you git clone the repo, it has support for git switch.  Has had it for a few months now.  But we haven't published a new beta in almost a year and I'm not sure when the next beta will be published.  I recommend that you git clone this repo and import the module by path.

Would you be open to an update to 0.x that adds support for switch and restore?

Yes and no.  Obviously adding features to 0.x would help folks but I'd really like to "nudge" folks to 1.0.  That said, 1.0 is still beta so that's hard to do until we release a stable version of v1.  Supporting multiple versions is not ideal when we have such a small set of folks trying to maintain this module.  Whining aside ;-), I would accept a PR to add that functionality to 0.x but who knows when a new version of 0.x would be published.

I dug into this a bit... the main issue is that the handler for Register-ArgumentCompleter returns the "Text" for an autocomplete as git <command> with no trailing space, instead of the expected git <command>  with at least one trailing space.    The regexes in GitTabExpansionInternal expect at least one space after the command.
An annoying side-effect of this is that  Register-ArgumentCompleter  completions aren't unregistered if you unload the module, meaning debugging involves having to open a new PowerShell process for each attempt at debugging.

@cdonnellytx Thanks for taking the time to debug this.  If Register-ArgumentCompleter is removing the space between the command and the tab, then there's a challenge - how do we distinguish git checkout \t from git che\t?  Perhaps the space still exists in one of arg completer params?


Add a README with setup instructions

Put a .keep file in the app/libs folder so folks can put the .aar file in there without needing to make it first.

@neilalexander, how does this look?


modified build

The DevExpress.XAF repository includes commits that relate to this task:

HideToolBar: execute only when nested frame is a ListView #433
VersionConverter: Add Support for custom DevExpressVersion and for howtoenable verbose messaging  #435 #426
ModelMapper: documentation #434
Release ModelMapper StandAlone package #434
VersionConverter: version not updated to 1.0.29 #448 #436
VersionConverter: VersionConverter: Continue patching with a warning if symbols not matched #435 #426
VersionConverter: DevexpressVersion not detected when packageReferences #435 #426
VersionConverter: Skips patching if at least one package is already patched  #435 #426
VersionConverter: Does not handle all symbol related exceptions #435 #426 #436

Please update the related Nuget packages and test if issues is addressed. These are nightly nuget packages available only from our NugetServer.
If you do not use the Xpand.XAF.Modules directly but through a module of the main eXpandFramework project, please wait for the bot to notify you again when integration is finished or update the related packages manually.
Thanks a lot for your contribution.

eXpand.lab release 19.1.402.6 includes commit that relate to this task:

Integrate ModelMapper #434
EnumPropertyEditor: DataSourceAttribute support for ListView #439
Integrate modelmapper #434

Please test if it addresses the problem. If you use nuget add our LAB NugetServer as a nuget package source in VS.
Thanks a lot for your contribution.


Update issue template

Description
Updates the bug report template to a standard across all our repositories.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that validate the behaviour of the software
[ ] I validated that new and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have bumped the version of the library

Rebasing should fix the problem with the integration tests.

@Gmerold It's based on the most recent version already :confused:
DanielArndt committed 16 hours ago
1 parent 4e431d1
commit 1d76a37


dracut: require disk-uuid.service on coreos.randomize_disk_guid=1

LGTM. we also collapse both of these dracut modules into

Ugh.

We'll collapse/rename the bootengine module in a later cleanup pass


[SYMFONY62] Replace MessageHandlerInterface with asMessageHandler

see #318

Any pointers to how I can set the attribute properties from an array?
-#[\Symfony\Component\Messenger\Attribute\AsMessageHandler(priority: 10, fromTransport: 'async')]
+#[\Symfony\Component\Messenger\Attribute\AsMessageHandler('priority' => 10, 'fromTransport' => 'async')]

Right now I'm using PhpAttributeGroupFactory::createFromClassWithItems() which gives the example above.

ping @samsonasik @TomasVotruba 🙂

Thank you :clap:

Thank you @stefantalen

This PR does not fully fix #318 (Part of the reason I didn't use close but see 😉) since that issue also references the MessageSubscriberInterface which is not included here.

Ok, re-open then :+1: