initial sample data

this PR establishes the config and class structure for the sample data.

Example config:
dataset_description = (
    "3D reconstruction of HIV virus-like particles from cryo-electron"
    "tomography data in EMPIAR-10164 and associated particle poses."
)

hiv_config = {
    "name": "hiv",
    "author": "Alister Burt",
    "description": dataset_description,
    "base_url": "doi:10.5281/zenodo.6504891/",
    "tomogram": {
        "file_name": "01_10.00Apx.mrc",
        "checksum": "md5:426325d006fe04276ea01df9d83ad510",
        "reader": mrc_reader,
    },
}

Here's the current repr/str:
cryoET DataSet
	name: hiv
	author: Alister Burt
	base url: doi:10.5281/zenodo.6504891/

	Description:
	  3D reconstruction of HIV virus-like particles from cryo-
	  electrontomography data in EMPIAR-10164 and associated particle poses.

	data
	  └── tomogram
		  ├── file name: 01_10.00Apx.mrc
		  └── checksum: md5:426325d006fe04276ea01df9d83ad510

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@4a2b602). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   81.06%
=======================================
  Files           ?        7
  Lines           ?      132
  Branches        ?        0
=======================================
  Hits            ?      107
  Misses          ?       25
  Partials        ?        0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@alisterburt , I've integrated config and downloader into the same class. As mentioned above, I think this is cleaner and I think we can factor out the config in a non-breaking way pretty easily.
This is ready for review! The only thing that would be nice to add in the future is a downloader test. Maybe we can upload a tiny fake test mrc file to zenodo or this repo for testing in the future.


Upgrade build-depends for GHC 8.10.4

Hi, It is like the #1 issue but for base-4.14.1
Are there any restrictions to update build-depends for successful build?
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.4
> cabal install unescaping-print

Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: unescaping-print-0.1 (user goal)
[__1] next goal: base (dependency of unescaping-print)
[__1] rejecting: base-<IP_ADDRESS>/installed-<IP_ADDRESS> (conflict: unescaping-print
=> base>=4.10 && <4.14)
[__1] skipping: base-<IP_ADDRESS>, base-<IP_ADDRESS> (has the same characteristics
that caused the previous version to fail: excluded by constraint '>=4.10 &&
<4.14' from 'unescaping-print')
[__1] rejecting: base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>,
base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>,
base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>,
base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>,
base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>,
base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>, base-<IP_ADDRESS>
(constraint from non-upgradeable package requires installed instance)
[__1] fail (backjumping, conflict set: base, unescaping-print)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, unescaping-print

Thanks for the ping! I've made a revision on Hackage. It should work now.


[Issue #100] Move the "report success" functionality configuration to a flag that utilizes $FIREWATCH_DEFAULT_* environment variables

This PR will migrate the "report success" functionality from PR #77 out of the firewatch config rules and into a CLI flag (--report-success) that makes use of the $FIREWATCH_DEFAULT_* environment variables.
I have done this promote uniform rules in the firewatch config. Considering this functionality is set at the job level rather than on a per step/failure-type basis, I feel it is more suited to a CLI flag.
How to use:

Set the following environment variables (and all other config values that are normally set):

FIREWATCH_DEFAULT_JIRA_PROJECT [REQUIRED]: This value should already be set anyway, it is not a new piece of the functionality. This is the Jira project where the story will be created
FIREWATCH_DEFAULT_JIRA_EPIC [OPTIONAL]: This is an optional environment variable that can be set. If it is set, the story will be linked to that Epic. If it is unset, the story will not be associated with an Epic.

Execute firewatch report --report-success

$FIREWATCH_DEFAULT_JIRA_EPIC
This is the first of a few new $FIREWATCH_DEFAULT_* optional environment variables that will be able to be utilized in firewatch rule sets. If set, not only will it affect where the success story is reported (if that functionality is used), but it will allow you to specify "jira_epic": "!default" in your rules. Using this value in a rule will cause firewatch to report any issue created for that rule to the $FIREWATCH_DEFAULT_JIRA_EPIC epic.
I have only included this variable in this PR as it pertains the to work item I am completing with this PR. The other optional default variables will come in a later PR attached to Issue #25.

NOTE
This change will not go into affect in OpenShift CI until the rest of the "release-v2" feature and change requests are complete.

/verified

/verified

/retest can-be-merged


Aster plot: fixed 2487 Chart renders categories inside itself

Aster plot: fixed 2487 Chart renders categories inside itself

Hi @deniskudelin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Denis Kudelin (Akvelon)). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

reviewed, lgtm


discovery: Rewrite Python APM instrumentation detection

What does this PR do?
Rewrite and enable Python APM instrumentation detection.
https://datadoghq.atlassian.net/wiki/spaces/UT/pages/4027154514/

Motivation
https://datadoghq.atlassian.net/browse/USMON-1158

Additional Notes
This includes three levels of tests: one with a canned maps file, one with real map files but with faked libraries and faked python, and an E2E test with real instrumented and non-instrumented servers without faking.

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Support for WebAuthn (FIDO2)

Describe the feature you'd like
I'd like to have the option to use my FIDO2 security token as 2FA.
Describe the benefits this would bring to existing BookStack users
Expand user account security
Can the goal of this request already be achieved via other means?
Actually only via TOTP, which is working great.
So, this is just additional.
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?
1-5 years
Additional context
No response

This is something that I'd like to use

that would help me too. +1

Being able to upgrade to physical tokens from TOTP would be an excellent forward step!

I'd quite like to add this, even just as a way to learn the WebAuthn standard.
I have though been holding off due to passkeys becoming a bigger deal. There's a lot of overlap with WebauthN.
If anyone has experience/knowledge of both passkeys and webauthn, and how these fit together both now and in the future, both from a technical and UX point of view, I'd appreciate feedback.
Just don't want to to cause trouble for myself in the future.

I would like this as well. I have trouble setting up TOTP in Bitwarden, so Passkey support would mean I can choose to use either my Yubikey or Bitwarden.


Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory

Do you want to request a feature or report a bug?
Bug
What did you do?

What did you expect to see?
Pushing to azure blob as storage and then downloading it the files the binary content of the files are the same
What did you see instead?
Pushing to azure blob as storage and then downloading it the files have differences such that nuget reports and error: Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory
Output of git rev-parse HEAD: (What version of BaGet are you using?)
recent master
(paste your output here)

What is your environment & configuration (arguments, platform, ...)?
windows 7
If applicable, please paste the log output in DEBUG level
(paste your output here)

Based on my own experimentation, the PackageContentType of BlobPackageStorageService needs to be updated to application/octet-stream but want to give others an opportunity to confirm while I work on a pull request

How did you download the package? Using the v3/package/<id>/<version>/<id>.<version>.nupkg route?

Can confirm this using the v3/package/<id>/<version>/<id>.<version>.nupkg route

I believe my fix was to change the BlobPackageStorageService PackageContentType to application/octet-stream but havn’t had time to do a repo
From: maxgus<EMAIL_ADDRESS>Sent: Thursday, September 13, 2018 10:35 AM
To: loic-sharma/BaGet
Cc: Nelson Lamprecht; Author
Subject: Re: [loic-sharma/BaGet] Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory (#86)
Can confirm this using the v3/package///..nupkg route
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Floic-sharma%2FBaGet%2Fissues%2F86%23issuecomment-421050326&data=02|01||7c82777137b3409eefcf08d6198e72ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636724496955175438&sdata=vOSYH4cfE6b4tBs0FpwMvOxMFYSzMKHIctYXvmWcxW0%3D&reserved=0, or mute the threadhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANrwDAVVz5ZmnQ17xXyE0BWmQAvmtkrdks5uansbgaJpZM4WIIjI&data=02|01||7c82777137b3409eefcf08d6198e72ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636724496955175438&sdata=P4VX5R%2BHRsFg4v89PdhC%2BXWQW3iI7YibeBMGY7gCsQA%3D&reserved=0.

I don't understand why using a MIME type of application/octet-stream helps. The blob's content type shouldn't affect the v3/package/<id>/<version>/<id>.<version>.nupkg route.
Does this reproduce for all packages? Or does this reproduce just a single package? If it's just a single package, could you link this package? Thanks!

I was able to reproduce this. I'll work on a fix. Thanks for reporting :)


Refactor An's Changes to module

roll in changes to core modules.
type annotations & docstrings on methods.
encapsulate non-ROS stuff + add to main module

So, this is started in a0c553ae9ef5575e00b86baea1ac6ba4a9e81458
But, color and GPS are not rolled in yet.

color integrated 2aa4efdf7383a970c613bc6a1d9304786e649f9d


Vue support in other files (such as .html, .php)

Hey, I was wanting to try out the the plugin, but it seems that its current scope is limited to .vue files. As I sometimes just need small snippets that I write directly into my laravel application's blade.php files, i was wondering if you could add support for vue (and its tags) to every html-like file type. Cheers!

or example twig files for instance (.html.twig) ;)

@mrjeye do you think?

This is why I installed this plugin but it seems it does not meet my demands :(
I want to get rid of these warnings in my .html files saying the vue attributes aren't valid.

Sorry, this plugin is mainly used for the.Vue template file. Other documents are not considered for the time being.


Upgraded dependencies.

[x] Updated Vue to 2.4.4
[x] Upgraded Laravel to 5.5

This change is

Reviewed 6 of 6 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Julia-evaluation broken

Hello!
If one tries to evaluate julia-codesnippets, it breaks with the following error:

ERROR: option -e/--eval is missing an argument

Reproduction:

```julia
1+1
```

Maybe something along those lines will do it?

printf %s "$1" | julia || true

julia -E "$1" || true

Cheers!

If problems still persist, please open it up at Myriad!


Installing the mysql2 gem on ubuntu 20.04

There seems to be an openssl incompatibility between chef and the system, which used to be solved by the mysql2_chef_gem cookbook, but that hasn't been updated in a while. Is there a better way to install the mysql2 gem to be used by chef?

@axos88 AFAIK this cookbook no longer uses the mysql2 so this shouldn't be a problem anymore. We removed it exactly for this reason.

@axos88 AFAIK this cookbook no longer uses the mysql2 so this shouldn't be a problem anymore. We removed it exactly for this reason.

That's great, but as far as I see the cookbook does not provide a way to run SQL queries against the server either (to create and grant privileges to users and databases AND to initialize the db schema). I was looking to do that using the database cookbook, but this means that's not an option either.
Is there something i overlooked?

That's great, but as far as I see the cookbook does not provide a way to run SQL queries against the server either (to create and grant privileges to users and databases AND to initialize the db schema). I was looking to do that using the database cookbook, but this means that's not an option either.
Is there something i overlooked?

@axos88 this was actually just added in #655


Changes to --stores flag

See https://github.com/cockroachdb/cockroach/issues/4577

Closed by PR #80


Can't get an access token

Hi Omar,
First of all, thanks for doing this. I'm pretty new to Lumen, so your tutorial definitely helped me to found out how all this is working!
Now, the bad news: I can't find a way to get an access token using Postman.
Here are the users and oauth_clients tables I have now.
Also, here's the POST request I send, and its response.
What am I missing? If you need any other information, feel free to ask me and I'll provide the according details. 😊
Thank you for your time!

Hey,
your problem is, you have set the parameters and values in the Headers and not in the Body section.
Best regards

Wow, one of these moments I feel so mad at myself!
Thank you, it works perfect now @blacknet76!
Have a nice day my friend.


SLA Miss Alert Callbacks : Allow DAGs to specify a callback function for SLA miss handling

This is in response to https://github.com/airbnb/airflow/issues/873
Essentially, I would like to add a callback function to SLA miss handling. In the callback function, I can decide whether to post to Slack and to VictorOps/PagerDuty, or some other 3rd party ops solution. Email is too limiting.
I've added another column to the table to track SLA notifications in general. Not in this PR is a fix for a general problem which can occur is SLAs were enabled on a task but no emails or sla alert call back were provided. In this case, the query to return all SLA misses would progressively return more and more data, slowing down the Scheduler. We need a separate fix to place a window on the max number of sla misses queried.

FYI, I tried to write a test for this, but it proved too difficult .. There was way to execute SchedulerJob.manage_slas that I could find in a few hours of digging.

@r39132  love the sla callback. I myself make extensive use of callbacks. At first glance my only question is why the callback is not defined in the BaseOperator along with the success,retry, and failure callbacks ... as well as the task level SLAs ?

Thanks @syvineckruyk
Currently, SLA miss checks are done in the scheduler. Each worker or executor will execute an operator. The central scheduler (or perhaps another daemon in the future) queries the DB to figure out which tasks are falling behind and sends a report of all tasks that have missed their SLAs in a single email. In that centralized logic, I added the callback hook to allow for similar notifications : I currently publish the list of delayed tasks to both VictorOps and Slack. Here's a screen capture of the Slack Notification for one execution of a callback -- 2 tasks were behind.

Though each task defines its SLAs, the detection and reporting of the SLA misses happens in the scheduler in jobs.py.

@r39132 got it.. thanks


Support laravel 8

All is in the title thanks :)

https://github.com/PheRum/laravel-bbcode/commit/63f9197dd06a55bd0bfe26e0cc150a4378bed5d5


incorrect units in results table

units in results table are incorrect despite being correct in the SolutionArray. MWE:
from gpkit import Variable, Model, units

T = Variable("T", "N", "thrust")
Tmin = Variable("T_{min}", "N", "minimum thrust")

M = Model(T, [T >= Tmin])
M.substitutions.update({Tmin: 1000*units.lbf})
SOL = M.solve()
print SOL.table()
print 'SOL("T_{min}") is %s' % (SOL("T_{min}"),)

printout from the above is:
Using solver 'cvxopt'
Solving for 1 variables.
Solving took 0.00301 seconds.

Cost
----
 4448 [N]

Free Variables
--------------
T : 4448  [N] thrust

Constants
---------
T_{min} : 1000  [N] minimum thrust

Sensitivities
-------------
T_{min} : 1 minimum thrust

SOL("T_{min}") is 1000 force_pound

I decided the right way to fix this was to convert the values in the solution dictionary back to the original units of the variable. If you want to change a variable's units it should be done in a different way.


[stable/sonarqube] Remove privileged securityContext from chmod-volume-mounts init container

What this PR does / why we need it:
Recently this chart has begun to fail to install on our managed cluster, where running containers with a privileged securityContext is not allowed.
This PR deletes that securityContext privilege escalation from the chmod-volume-mounts init container, which does not seem to have any adverse effects when starting the chart with default values.  I'm not seeing any reason why this may be needed, as the point of this container seems to be to just initialize some directories inside the sonarqube volume to ensure they have the correct permissions.  This fix resolves the issue that is preventing our users from running the latest version of this chart.
I also added some tweaks to the Elasticsearch section of the README.  I had added that section and the elasticsearch section to values.yaml for a similar reason in PR #17634.  I can move this commit to a separate PR if so requested.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @rjkernick

/assign
/ok-to-test

@rjkernick have you had a chance to look at this?  Our users are unable to use the latest version of this chart without this fix.

/lgtm

Thanks for the merge!


Wrong addition solved in add_faux_rows by adding parseInt

This solves https://github.com/ducksboard/gridster.js/issues/425.
The
fn.add_faux_rows = function(rows) {
var actual_rows = this.rows;
var max_rows = actual_rows + (rows || 1);
The second part was being added as a string before this patch.  This gave a huge row number and caused lots of lags.  Now it flies again.
I think also related to:
https://github.com/ducksboard/gridster.js/issues/340  (see comments of canfiax)

Looks great I merged it into my fork dsmorse/gridster.js


Azure Cosmos DB Provisioner support for token-based auth

Enhance the Azure Cosmos DB provisioner to support token based auth.
Background
Currently the Aspire service-side components for CosmosDB support specifying a URI as the connection string which triggers its support for token-based authentication (great!). The problem is that the provisioner supplies a connection string, so we aren't able to exercise that token based auth flow in the inner loop.
It is easy enough to just supply the Cosmos DB URI in the connection string, the user identity that is used for token auth almost certainly won't have the roles it needs for the freshly configured account so their code can create databases, collections, and read/write items. This is something that the provisioner will need to handle.
The problem is that there is no top level role that we can assign that would grant a developer access. we need to define a custom role with specific permissions to unlock access. Some of these permissions may require knowledge of the specific databases being accessed although this isn't 100% certain.
We'll need to work with the Cosmos DB team to better understand the best permissions to give that enables the following:

Create/delete /databases
Create/delete containers in databases
Read/write items to containers

If the answer is to automatically create a custom role we need to consider whether there are any implications of many developers running this provisioning logic and what we do to avoid collisions and whether we would pollute the namespace with random custom role definitions.

@mitchdenny - did #1583 fix this?

No it doesn't. For inner loop we still use connection string with account key.


Can't use Http fake when testing requests

I'm trying to test my code with the Http::fake() method. I'm expecting this to work with the http-sender plugin.
/** @test */
public function it_can_configure_the_base_url(): void
{
    Http::fake(function (Request $request) {
        dd($request);
    });

    /** @var MCOConnector $connector */
    $connector = $this->app->make(TestConnector::class);

    $request = $connector->send(new TestRequest());
}

I know there are some other ways to test the requests, but I like the freedom you get with the Http::fake() callback. Even if this becomes possible with Saloon, I'm still questioning why this isn't working in the first place.
Keep up the good work, I'm loving the package and ecosystem!

That's a possibility. I'm not really familiar with the package yet so this is hard to debug.
Can you confirm that the snippet I provided is a bug? Maybe I'm just using it wrong.

Looks like #15 might have you covered! 🔥

Going to close this issue as I think Saloon's faking helpers are okay for now.


When clicking on group by hour or day, nothing is displayed

When clicking on "Group by Hour or Day" nothing is displayed on screen but a white, blank page.

Fixed.


MathHelper.cs issues

I see MathHelper.cs has some Russian comments in it, can you change those to English?
Also, I see very similar versions of it at GraphX.METRO.Controls and at GraphX.WPF.Controls that I can easily merge into one using some conditional compilation block near the top (the rest is very similar code as I see with WinMerge).
The question is where would the merged file be put? Should it go to GraphX.PCL.Common or to GraphX.PCL.Logic? I only see a Helpers/ThreadingHelper.cs at the 2nd one and an empty Helpers folder at the 1st one. Also I'd need to change the namespace to GraphX.PCL.Common.Helpers I guess instead of GraphX.WPF.Controls and GraphX.METRO.Controls that the two files have now
BTW, why use different namespaces in GraphX? You will never have WPF and METRO library linked together in the same project, so why not use the same namespace so that client code that uses the library can easily be ported (or shared via linked files) between WPF and METRO apps (and the coming UWA ones)? I've been using this practice in ClipFlair Studio and other projects and I'm very happy with code reuse (without even maintaining separate files, just have multiple projects for different platforms reference the same sources via linked files) like that.
...in my projects I even set the target assemblies to not have a platform in their name so that I can reuse XAML files (via linked files again) between WPF and Silverlight (else I'd need to have different XAML cause of XAML namespace definitions that needed assembly name). Metro unfortunately added the "using" syntax for XAML namespaces and MS uses that with UWA apps too and I think they don't support the older syntax at all which is very sad since they force you use separate XAML files in such case (given that there is no XAML include directive to include the rest of the common XAML between platforms). Can check the pattern I use with linked files at http://clipflair.codeplex.com/SourceControl/latest#Client/ZUI/ImageButtons/ for example (see the folders)

I see MathHelper.cs has some Russian comments in it, can you change those to English?

Yes i can, must had missed them

Also, I see very similar versions of it at GraphX.METRO.Controls and at GraphX.WPF.Controls that I can easily merge into one using some conditional compilation block near the top

The problem with this file is that it uses (or extends) classes like Point that are not PCL compatible so they can't be placed in PCL. Can be placed in WPF project and be linked to METRO though (using conditional directives).

BTW, why use different namespaces in GraphX?

Honestly, i haven't tried to implement  cross-platform apps so some things can be out of my sight.  So the one namespace sounds nice :) Also i've completely forgot about file linking benefits, it would be nice to reinspect WPF and METRO for files to combine.
So in summary, first of all i'll try to implement single namespace for WPF and METRO. Then i can take a look at these projects files to see if i can merge some into one.

PS: Also i'll make MathHelper files more similar for easier merge. I'll try to upload changes tomorrow. I have a lot of job to do so can't promise anything.

Changed namespace to GraphX.Controls across WPF and METRO libs. I suppose i had to change assembly name to that name too but i like the platform name reflected in file name. Still not sure.

Can use same assembly name and file too because it helps with classic XAML namespace declarations (not the METRO ones that do "using:"
That way you can reuse XAML files (via linked files or shared project [there is VS extension for such])
Not sure if NuGet packaging has issue, probably not though

at https://msdn.microsoft.com/en-us/library/ms747086(v=vs.110).aspx it says:
assembly=  The assembly that contains some or all of the referenced CLR namespace. This value is typically just the name of the assembly, not the path, and does not include the extension (such as .dll or .exe). The path to that assembly must be established as a project reference in the project file that contains the XAML you are trying to map. In order to incorporate versioning and strong-name signing, the assembly value can be a string as defined by AssemblyName, rather than the simple string name.
so most probably XAML namespace declarations search for the assembly name, don't care of filenames, so to be able to reuse XAML files via file linking or shared projects (between WPF and Silverlight that use the same XAML namespace syntax that is), I guess you can just use the same assembly name and different filenames to show the platform (like xx for the assembly name field at the project properties/build tab and xx.WPF.dll or xx_WPF.dll for the output filename)
I think I was having some issues though with this practice (don't remember for sure) and I decided to use same value for BOTH the assembly name AND the filename eventually for all versions
BTW, for METRO (Win8 store) and UWA apps there is new syntax:
•Instead of using a clr-namespace:/assembly= qualifier set for code-to-XAML namespace references, you use the using: qualifier. XAML namespaces no longer reference specific assemblies; all assembly qualification and inclusion is handled by the application model and how you compose your app package.
but haven't tried it yet to see if the older syntax is also supported (fear it isn't)
ALSO, see http://www.codeproject.com/Articles/111911/A-Guide-to-Cleaner-XAML-with-Custom-Namespaces-and - IT IS MAYBE BETTER TO DEFINE A URL FOR THE NAMESPACE (YOU DO IT IN ASSEMBLYINFO.CS FILE). If this (using a URL) is still supported at METRO and UWA XAML, then it is much better since you'll be able to reuse XAML files (via shared projects or linked files) between WPF, Silverlight, Win8 Store Apps (WinRT) and UWA (Win10) apps. Have to look a bit into it though

regarding the XmlnsDefinition I mention above (for AssemblyInfo.cs), an article from 2012 says WinRT doesn't support neigther 1:1, nor 1:n (another nice feature of Silverlight/WPF) namespace mapping using such URLs (it doesn't have XmlnsDefinition attribute). Will check in case Microsoft added support for that, or what happens if one defines the XmlnsDefinition attribute themselves (if it is just ignored then in WinRT)
The 1:n-Namespace-Mapping with XmlnsDefinition-Attribute
The Namespace-Mappings above have been 1:1-Mappings. One XML-Namespace was mapped to one Silverlight/WinRT-Namespace.
In Silverlight-XAML you can create a 1:n-Namespace-Mapping by placing the XmlnsDefinitionAttribute (Namespace: System.Windows.Markup) on your assemblies like this:
[assembly: XmlnsDefinition(
"http://thomasclaudiushuber.com/","UIRocker.Special")]
[assembly: XmlnsDefinition(
"http://thomasclaudiushuber.com/", "UIRocker.Mvvm")]
Classes out of the Namespaces UIRocker.Special and UIRocker.Mvvm can be used in XAML with one alias by making a 1:n-Namespace-Mapping like this:
xmlns:rocker="http://thomasclaudiushuber.com/"
Unfortunately in WinRT-XAML there is no possibility for a 1:n-Mapping. The Namespace Windows.UI.Xaml.Markup contains a XmlnsDefinition, but it’s not an attribute, it’s a struct and therefore not usable.
Especially when you create a library with many Namespaces in it, it’s great to use just one alias for the library in XAML. Maybe the next Version of WinRT will contain such a mapping. By the way, first versions of Silverlight also didn’t support 1:n-Namespace-Mappings.

A discussion at https://social.msdn.microsoft.com/Forums/windowsapps/en-US/026baea0-6324-46ee-956a-72dbb4c90ca1/xmlnsdefinition-replacement-in-winrt?prof=required says:
"...there is no analogous attribute.
You might be able to provide similar data in a custom IXamlMetadataProvider implementation, but since that is automatically generated for you I'm not sure it can be overridden."
there is some more info related to IXamlMetadataProvider here: http://stackoverflow.com/questions/12747591/possible-to-use-a-uri-as-an-xml-namespace-in-winrt-xaml
also found some encouraging info at:
http://www.sharpgis.net/post/2013/05/30/Decoding-the-IXamlMetadataProvider-interface-Part-1
"So the auto-generated code automatically detected that my custom library has a second metadata provider embedded, and injects it into this list as well as the auto-generated one. So it looks like we should be able to provide our own implementations, which I’ll get back to later."

but haven't tried it yet to see if the older syntax is also supported (fear it isn't)

I've tried to use it but it seems it's not supported :(

IT IS MAYBE BETTER TO DEFINE A URL FOR THE NAMESPACE (YOU DO IT IN ASSEMBLYINFO.CS FILE)

That's super cool feature i've also forgot about :) I knew of it but actualy haven't used yet. Thanks, i'll take a look and try to adapt it for GraphX! I see there are some problems with WinRT so i'll check it also.
Many thanks for pointing me such good coding practices! :)

I've failed to implement IXamlMetadataProvider for METRO. It requires fields to be implemented that are not implemented in all examples i've found and much more time for an investigations. I might look at it later or you can play with it if you want. I leave sources in GraphX.METRO.Controls\Models\XamlTypes with commented XamlMetadataProvider to not trigger it.
I've also changed assembly name to the identical GraphX.Controls and added "http://schemas.panthernet.ru/graphx/" XAML namespace for WPF.

Also, please inform me if you want to do some cleaning by referencing WPF files to METRO instead of identical duplicates cause i plan to do it too. So there will be no overhead. Thanks!

Will not have good network till the weekend so feel free to work on it.
There is a Compare files extension for Visual Studio that can work with WinMerge, but there is also an amazing compare tool for free as VS extension that shows VS editing panes side by side with intellisense etc. AMAZING producivity when merging separate WPF and Silverlight implementations of a library with that one is my experience. Will need to checkout the name of that exrension, maybe was CodeCompare
I love doing refactoring and have some stuff already to submit but I'm confused with GitHub desktop's Pull request dialog. It tries to make pulls for master, not PCL branch

Ok, got it, thanks! I'll check that extension. I haven't submitted anything to other projects on GitHub so i'm afraid i can't help with this one :( But surely there must be some option to select correct branch. I've used SmartGit before VS started to support git repos natively.

Haven't tried vs native git support, that might be better option than the github desktop app, although that one looks very nice

I haven't thought that would be so exciting! I'm not only able to merge substantial amount of code but also able to see and implement additional performance/feature tweaks and fix some bugs found in the process. For example i've merged different edge pointer controls into universal one and notably increased edge drawing performance. Currently i'm somewhere past the middle of the work that should be done and slowly move to the end :) There are also some issues that slows me done and had to be solved but that's makes the task interesting :)

looking at the folders/projects/libraries/namespaces naming, I think it would be more appropriate to add the platform at the end of the name, say GraphX.somePart.PCL, GraphX.somePart.UWA (=Universal Windows Application model [aka Win10]) etc. Not sure how easy it will be though for contributors to merge pending changes via GitHub if you do such drastic changes (I'm still struggling with Git myself, prefer Mercurial)

Speaking of moving the platform to the end of the name (e.g. GraphX.Controls.WPF, GraphX.Controls.SL5 etc.), to do it on the folder names (apart from doing at the source code for packages, target assemblies etc.), I think one has to use some Version Control command to "move" (Git should have something like that) the files to the new folder, else other contributors may have issue merging their changes.
Despite the trouble to do it, I think it is better for the long run. Also, all GraphX.SomePart.* subfolders could then be grouped in a GraphX.SomePart folder as subfolders where a Source or Common subfolder would also exists that has all the common code those platform-specific versions of GraphX.SomePart share (via linked files to ..\Common\SomeFile, ..\Common\SomeFolder\SomeFile and ..\Common\SomeOtherFolder\SomeFile etc.)
This is the scheme I've been using (and are very satisfied with) at http://clipflair.codeplex.com and other projects (e.g. at the AmnesiaOfWho game [http://facebook.com/AmnesiaOfWho] that has separate versions for SL5, WP7 and WP8 and WPF version on the works, plus WRT (WinRT) and UWA [Universal Windows App] too coming in the near future, with all code and most XAML shared via linked files)

Hi, i can't see much problems in graphX with these. Platform specific GraphX versions are contained each in own project and separate folder reflecting platform name (excl. WPF version folder name for now). All platform specific projects share single GraphX.Controls namespace now based on your recommendations and i share cross-platform files as links now.
PCL stands aside as unified library :)

I meant I'd expect GraphX.Common folder with GraphX.Common.PCL int and GraphX.Common.WP7 etc. versions for example also in that folder since PCL is usually set at WP8 level. This is just an example.
What I'm saying is that the platform name is the last part of the specialization chain, so logically GraphX comes first then say comes Controls then comes WPF, SL5, WP8 etc. in the folder name.
Also would have 3 parent folders Controls, Common and Logic. The last two would just contain the respective .PCL subfolder for now, but I can contribute subfolders for specific platforms too, esp for those the common PCL profile doesn't cover. Source would be at Controls\Source, Common\Source, Logic\Source and respective platform specific projects (even the pcl projects) would use linked files

btw, regarding PCL useful resources are:

.NET Portability Analyzer extension
https://visualstudiogallery.msdn.microsoft.com/1177943e-cfb7-4822-a8a6-e56c7905292b

API Portability Analyzer - Alpha (command-line version)
http://www.microsoft.com/en-us/download/details.aspx?id=42678

PLIB API XLS
https://onedrive.live.com/view.aspx?resid=8A7FB4A4B32FB2C9!180&app=Excel&authkey=!AHaBmLAhQ49YCI0

Xamarin Scanner (How Mobile is your .NET code?)
http://scan.xamarin.com/

Speaking of Xamarin, adding support for that too could follow the same pattern as described above (PCL where possible and platform-specific versions for .XamarinIOS, .XamarinAndroid etc. where needed)

Thanks for the analyzers, i'll play with them a bit later. Regarding structural changes, honestly, i don't have much time now and no will either to do them though they are seemed quite logical to me. Currently the file structure is a bit wacky if you look at it from the explorer, but in VS it is operable and clean. I think i'll return to that question in a while, may be i should make completely new upload and use master branch with the new file structure... hm...

btw, since I saw at some reply of yours that you have some build task to rename the .DLLs, I see NuGet is suggesting to output the DLLs with same filename in different subfolders:
https://docs.nuget.org/create/enforced-package-conventions
''''
When NuGet installs an assembly from a package, it checks the target .NET Framework version of the project you are adding the package to. NuGet then selects the correct version of the assembly in the package by selecting the correct subfolder within the lib folder.
To enable NuGet to do this, you use the following naming convention to indicate which assemblies go with which framework versions:
lib{framework name}{version}
The following example shows a folder structure that supports four versions of a library:
\lib
\net11
\MyAssembly.dll
\net20
\MyAssembly.dll
\net40
\MyAssembly.dll
\sl40
\MyAssembly.dll
''''

This build task is cosmetic, not sure if i will leave it there as it is now. While messing with QuickgraphPCL NuGet i've learned how true NuGet package should be organized :) It is similar to what you've wrote up there. For Quickgraph i had two subfolders, one for net40 and other for all the others plarforms portable-win+net4+sl5+wp8+win8+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10. So the next GraphX release should have net40 and win81 subfolders.

btw, that article I mentioned at #24 (http://oren.codes/2015/06/16/demystifying-pcls-net-core-dnx-and-uwp-redux) says they're adding a platform agnostic identifier too that will mean "see the platforms my dependencies support" - guess that goes down the tree of those dependencies recursively). Problem is I guess it will take some time till Microsoft and others re-release their packages to turn on that one


Add metadata watcher and informer

Introduce metadata-only watchers to the kubernetes package. These are useful if we only need to track metadata for a resource - a good example are ReplicaSets, for which we usually only care about the OwnerReferences. As a result, we only store the metadata, reducing steady-state memory consumption, but also only get updates involving metadata, reducing churn greatly in larger clusters.
The implementation introduces new constructors for the Watcher, allowing an informer to be passed in. Existing constructors are implemented using the new constructor, though none of the code actually changes. As a result, it is now possible to unit test the watcher, and I've added some basic unit tests for it.
We also add two helper functions:

GetKubernetesMetadataClient creates a metadata-only kubernetes client, and is very similar to the existing GetKubernetesClient
RemoveUnnecessaryReplicaSetData is a transform function that can be passed into an informer so it only stores the metadata we actually use

:hourglass_flowing_sand: Build in-progress, with failures

Buildkite Build
Commit: cbbd7ba4764ed9f41963a983d46bdef70bfc083f

Failed CI Steps

:golangci-lint: Lint

:hourglass_flowing_sand: Build in-progress, with failures

Buildkite Build
Commit: 74d960f5e65618bf34ad5e8f79eaafe346a88e29

Failed CI Steps

:linux: Tests on Linux

History

:broken_heart: Build #266 failed cbbd7ba4764ed9f41963a983d46bdef70bfc083f

:green_heart: Build Succeeded

Buildkite Build
Commit: 962b390bea06428ee527bf4498d68c4c361ed668

History

:broken_heart: Build #267 failed 74d960f5e65618bf34ad5e8f79eaafe346a88e29
:broken_heart: Build #266 failed cbbd7ba4764ed9f41963a983d46bdef70bfc083f

:green_heart: Build Succeeded

Buildkite Build
Commit: 3fe2e43cefeb871ddbe49487ff815d73da252742

History

:green_heart: Build #269 succeeded 962b390bea06428ee527bf4498d68c4c361ed668
:broken_heart: Build #267 failed 74d960f5e65618bf34ad5e8f79eaafe346a88e29
:broken_heart: Build #266 failed cbbd7ba4764ed9f41963a983d46bdef70bfc083f

:green_heart: Build Succeeded

Buildkite Build
Commit: d7f0a732132e11df083e9f99fa4aa0a616a7ab25

History

:green_heart: Build #270 succeeded 3fe2e43cefeb871ddbe49487ff815d73da252742
:green_heart: Build #269 succeeded 962b390bea06428ee527bf4498d68c4c361ed668
:broken_heart: Build #267 failed 74d960f5e65618bf34ad5e8f79eaafe346a88e29
:broken_heart: Build #266 failed cbbd7ba4764ed9f41963a983d46bdef70bfc083f

:green_heart: Build Succeeded

Buildkite Build
Commit: ddffdc439e09ba8890beccfbe68cca36293f008d

History

:green_heart: Build #272 succeeded d7f0a732132e11df083e9f99fa4aa0a616a7ab25
:green_heart: Build #270 succeeded 3fe2e43cefeb871ddbe49487ff815d73da252742
:green_heart: Build #269 succeeded 962b390bea06428ee527bf4498d68c4c361ed668
:broken_heart: Build #267 failed 74d960f5e65618bf34ad5e8f79eaafe346a88e29
:broken_heart: Build #266 failed cbbd7ba4764ed9f41963a983d46bdef70bfc083f


Populate legend color picker with suggested colors present in table

The color picker should have suggested (preset) colors populated from the table.

include all manually assigned colors
include gradient steps if the user has assigned a score to any technique.

The legend now includes gradient steps and the colors from the preset background list. Pushed to develop.


fix: PropertiesPanel.setWidth and Height not allowing negative values

we can now set width and height to negative values from properties Panel
refactored the ugly Gizmo.canflip style of preventing shape flip
refactored PanelProperties.updateDisplay
refactored selectTools.selectShapesUnderRectangle to use overlayLayout to draw rectangle as opposed using div and html body

The features were already accepted in another PR.


Fix server-side compiles with conflicting SSL config in .inmanta file (#5213)

Pull request opened by the merge tool on behalf of #5213

Pull request rejected by merge tool. The tests for this branch did not succeed.

Merged into branches iso5 in 603c8ffd6d788ee43d5c86400791458a588802c7


Remove unnecessary dependencies, add versions to other packages

Redis is no longer a necessary dependency.
Pin other dependencies to the latest major version numbers to
prevent the possibility of breaking changes when releasing in
production.

Closing this as I've received no feedback in 3 years.


Update loop of HelmChart

Context:
I set reconcileStrategy: Revision. In general gitrepo and helmrelease looks in the following way:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
...
spec:
  secretRef:
    name: github-auth
  interval: 300s
  url<EMAIL_ADDRESS>    tag: v1.0.5
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
....
  chart:
    spec:
      chart: charts/mychart
      reconcileStrategy: Revision
      sourceRef:
        kind: GitRepository
        name: myapp

But what is happens is that HelmChart resource is getting updated every 5min.
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmChart
...
   chart: charts/mychart
   interval: 5m0s
   reconcileStrategy: ChartVersion
   sourceRef:
     kind: GitRepository
     name: myapp
   version: '*'

So one time reconcileStrategy is ChartVersion, next time Revision and the value toggle every 5min.
Stopping kustomize-controller freezed the value, but I'm still not sure if issue with kustomize component.
Info:

kustomize-controller:v0.31.0
source-controller:v0.32.1
helm-controller:v0.27.0:
k8scluster:v1.22.10

What is also weird is that I have set interval 300s, while it is displayed as 5m0s, previously I had value 5m. I'm going to change 300s to something like 305s to see if it going to change.

Is the HelmChart yaml in Git?

Is the HelmChart yaml in Git?

yes

HelmCharts are auto generated from the HelmRelease, remove it from git

oh, sorry, my previous answer is wrong (get confused a little). Not in git repo which has release manifests for flux, we only specify kinds GitRepository and HelmReleases.

Try using 5m0s as the value of intervals in the HelmRelease

Set 2 setups.
First:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
...
spec:
  ...
  interval: 5m0s
  url<EMAIL_ADDRESS>    tag: v1.0.5
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
....
  interval: 5m0s
  chart:
    spec:
      chart: charts/mychart
      reconcileStrategy: Revision
      interval: 5m0s
      sourceRef:
        kind: GitRepository
        name: myapp

Second:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
...
spec:
  ...
  interval: 5m10s
  url<EMAIL_ADDRESS>    tag: v1.0.5
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
....
  interval: 5m10s
  chart:
    spec:
      chart: charts/mychart
      reconcileStrategy: Revision
      interval: 5m10s
      sourceRef:
        kind: GitRepository
        name: myapp2

*just in case 0s become 00s (not sure if the case :))

After changes were pushed it survived like 10min, and now I again see that all rollbacked to ChartVersion and in ~3-5min again to Revision. Also, the release that previously survived 30min - now it changed as well.

Now again it rollbacked to ChartVersion and again to Revision. @stefanprodan do you have guesses whether it is kustomize or source controller is changing HelmChart(s) resources? I'm thinking about adding debug logs and redeploy it?
Once they again switched to Revision. I can see them running for last 15+ minutes. And then again..

Could it be that there are 2 HelmReleases with the same name? kustomize-controller can't undo fields like reconcileStrategy unless it is told so in some manifest

I'm going to leave only one release. But basically there is no helmrelease duplicates, checked it yesterday. But regarding namings HelmRelease has the same name as GitRepository.

Can you post here the output of kubectl get helmrelease --show-managed-fields for that HelmRelease and please do the same for the HelmChart.

kubectl -n example get "helmreleases.helm.toolkit.fluxcd.io/myapp" --show-managed-fields

NAME    READY   STATUS                             AGE
myapp   True    Release reconciliation succeeded   47h

kubectl -n example get gitrepo/myapp --show-managed-fields

NAME    URL                                  AGE   READY   STATUS
myapp<EMAIL_ADDRESS> 47h   True    stored artifact for revision 'v1.0.5/362172abf957254e6e2a7d4416f70e8d147a8cb3'

kubectl -n example get helmchart/example-myapp --show-managed-fields

NAME            CHART          VERSION   SOURCE KIND     SOURCE NAME     AGE   READY   STATUS
example-myapp   charts/myapp   *         GitRepository   myapp           47h   True    packaged 'myapp' chart with version '0.0.1+362172abf957'

Sorry I forgot about -oyaml please rerun those and post the YAML output

Time 1 when right version according to git repository was set (Revision):

helm release

- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      .: {}
      f:conditions: {}
      f:helmChart: {}
      f:lastAppliedRevision: {}
      f:lastAttemptedRevision: {}
      f:lastAttemptedValuesChecksum: {}
      f:lastReleaseRevision: {}
      f:observedGeneration: {}
  manager: helm-controller
  operation: Update
  subresource: status
  time: "2022-12-16T09:09:10Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:labels:
        f:kustomize.toolkit.fluxcd.io/name: {}
        f:kustomize.toolkit.fluxcd.io/namespace: {}
    f:spec:
      f:chart:
        f:spec:
          f:chart: {}
          f:interval: {}
          f:reconcileStrategy: {}
          f:sourceRef:
            f:kind: {}
            f:name: {}
      f:interval: {}
      f:releaseName: {}
      f:values: {}
  manager: kustomize-controller
  operation: Apply
  time: "2022-12-16T09:05:58Z"

helm chart

- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      f:interval: {}
      f:reconcileStrategy: {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T08:05:48Z"

Time 2 when wrong version according to git repository was set (ChartVersion):

helm release

- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:labels:
        f:kustomize.toolkit.fluxcd.io/name: {}
        f:kustomize.toolkit.fluxcd.io/namespace: {}
    f:spec:
      f:chart:
        f:spec:
          f:chart: {}
          f:interval: {}
          f:reconcileStrategy: {}
          f:sourceRef:
            f:kind: {}
            f:name: {}
      f:interval: {}
      f:releaseName: {}
      f:values: {}
  manager: kustomize-controller
  operation: Apply
  time: "2022-12-16T09:05:58Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:annotations:
        .: {}
        f:reconcile.fluxcd.io/requestedAt: {}
  manager: flux
  operation: Update
  time: "2022-12-16T09:27:02Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      .: {}
      f:conditions: {}
      f:helmChart: {}
      f:lastAppliedRevision: {}
      f:lastAttemptedRevision: {}
      f:lastAttemptedValuesChecksum: {}
      f:lastHandledReconcileAt: {}
      f:lastReleaseRevision: {}
      f:observedGeneration: {}
  manager: helm-controller
  operation: Update
  subresource: status
  time: "2022-12-16T09:29:50Z"

helm chart

- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      f:interval: {}
      f:reconcileStrategy: {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T08:05:48Z"

In git I have set Revision - time 1, while later it switched automatically to ChartVersion - time 2 (~2022-12-16T09:29:50Z)
Its like time does not reflect when the field was changed, but I still see that value:
fieldsV1:
    f:spec:
      f:reconcileStrategy: {}

is changing from one to another

FYI: when I set ChartVersion in git, the issue is not happening

when I set ChartVersion in git

Where else are you setting it? If valero restored the HelmChart (on idea why would you do that for an object that managed by Flux), then Flux can't delete the filed if you remove it from Git.

Created new release with Revision:

helm release:

- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:labels:
        f:kustomize.toolkit.fluxcd.io/name: {}
        f:kustomize.toolkit.fluxcd.io/namespace: {}
    f:spec:
      f:chart:
        f:spec:
          f:chart: {}
          f:interval: {}
          f:reconcileStrategy: {}
          f:sourceRef:
            f:kind: {}
            f:name: {}
      f:interval: {}
      f:releaseName: {}
      f:values: {}
  manager: kustomize-controller
  operation: Apply
  time: "2022-12-16T09:56:32Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:finalizers:
        .: {}
        v:"finalizers.fluxcd.io": {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      f:conditions: {}
      f:helmChart: {}
      f:lastAppliedRevision: {}
      f:lastAttemptedRevision: {}
      f:lastAttemptedValuesChecksum: {}
      f:lastReleaseRevision: {}
      f:observedGeneration: {}
  manager: helm-controller
  operation: Update
  subresource: status
  time: "2022-12-16T09:56:48Z"

helm chart:

- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      .: {}
      f:chart: {}
      f:interval: {}
      f:reconcileStrategy: {}
      f:sourceRef:
        .: {}
        f:kind: {}
        f:name: {}
      f:version: {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:finalizers:
        .: {}
        v:"finalizers.fluxcd.io": {}
  manager: source-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      f:artifact:
        .: {}
        f:checksum: {}
        f:lastUpdateTime: {}
        f:path: {}
        f:revision: {}
        f:size: {}
        f:url: {}
      f:conditions: {}
      f:observedChartName: {}
      f:observedGeneration: {}
      f:observedSourceArtifactRevision: {}
      f:url: {}
  manager: source-controller
  operation: Update
  subresource: status
  time: "2022-12-16T09:56:33Z"

After ~5-10min it switched to ChartVersion:

helm release:

- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:labels:
        f:kustomize.toolkit.fluxcd.io/name: {}
        f:kustomize.toolkit.fluxcd.io/namespace: {}
    f:spec:
      f:chart:
        f:spec:
          f:chart: {}
          f:interval: {}
          f:reconcileStrategy: {}
          f:sourceRef:
            f:kind: {}
            f:name: {}
      f:interval: {}
      f:releaseName: {}
      f:values: {}
  manager: kustomize-controller
  operation: Apply
  time: "2022-12-16T09:56:32Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:finalizers:
        .: {}
        v:"finalizers.fluxcd.io": {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: helm.toolkit.fluxcd.io/v2beta1
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      f:conditions: {}
      f:helmChart: {}
      f:lastAppliedRevision: {}
      f:lastAttemptedRevision: {}
      f:lastAttemptedValuesChecksum: {}
      f:lastReleaseRevision: {}
      f:observedGeneration: {}
  manager: helm-controller
  operation: Update
  subresource: status
  time: "2022-12-16T10:06:52Z"

helm chart:

- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      .: {}
      f:chart: {}
      f:interval: {}
      f:reconcileStrategy: {}
      f:sourceRef:
        .: {}
        f:kind: {}
        f:name: {}
      f:version: {}
  manager: helm-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:metadata:
      f:finalizers:
        .: {}
        v:"finalizers.fluxcd.io": {}
  manager: source-controller
  operation: Update
  time: "2022-12-16T09:56:32Z"
- apiVersion: source.toolkit.fluxcd.io/v1beta2
  fieldsType: FieldsV1
  fieldsV1:
    f:status:
      f:artifact:
        .: {}
        f:checksum: {}
        f:lastUpdateTime: {}
        f:path: {}
        f:revision: {}
        f:size: {}
        f:url: {}
      f:conditions: {}
      f:observedChartName: {}
      f:observedGeneration: {}
      f:observedSourceArtifactRevision: {}
      f:url: {}
  manager: source-controller
  operation: Update
  subresource: status
  time: "2022-12-16T09:56:33Z"

Can also post flux check to see the exact versions please

Have been running the following resources (manually applied using kubectl apply -f) for almost one hour now, and I am unable to reproduce this behavior.
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: proof
  namespace: flux-system
spec:
  interval: 1m0s
  url: https://github.com/hiddeco/proof
  ref:
    branch: main
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: dummy
  namespace: flux-system
spec:
  interval: 5m0s
  chart:
    spec:
      chart: charts/dummy
      reconcileStrategy: Revision
      sourceRef:
        kind: GitRepository
        name: proof

Which yields as HelmChart status:
$ kubectl describe helmchart flux-system-dummy
...
Status:
  Artifact:
    Checksum:          19e8fcf767693187c6c6db4046aa5df93a34f837633cfe96f823a32b06d128a4
    Last Update Time:  2022-12-16T11:39:00Z
    Path:              helmchart/flux-system/flux-system-dummy/dummy-0.1.0+4c6f7e800e7e.tgz
    Revision:          0.1.0+4c6f7e800e7e
    Size:              3765
    URL:               http://source-controller.flux-system.svc.cluster.local./helmchart/flux-system/flux-system-dummy/dummy-0.1.0+4c6f7e800e7e.tgz
  Conditions:
    Last Transition Time:             2022-12-16T11:39:00Z
    Message:                          packaged 'dummy' chart with version '0.1.0+4c6f7e800e7e'
    Observed Generation:              1
    Reason:                           ChartPackageSucceeded
    Status:                           True
    Type:                             Ready
    Last Transition Time:             2022-12-16T11:39:00Z
    Message:                          packaged 'dummy' chart with version '0.1.0+4c6f7e800e7e'
    Observed Generation:              1
    Reason:                           ChartPackageSucceeded
    Status:                           True
    Type:                             ArtifactInStorage
  Observed Chart Name:                dummy
  Observed Generation:                1
  Observed Source Artifact Revision:  main/4c6f7e800e7ebae68c99ca051ae540476a60c1db
  URL:                                http://source-controller.flux-system.svc.cluster.local./helmchart/flux-system/flux-system-dummy/latest.tar.gz
Events:
  Type    Reason                      Age                 From               Message
  ----    ------                      ----                ----               -------
  Normal  NoSourceArtifact            52m (x6 over 52m)   source-controller  no artifact available for GitRepository source 'proof'
  Normal  ChartPackageSucceeded       51m                 source-controller  packaged 'dummy' chart with version '0.1.0+4c6f7e800e7e'
  Normal  ArtifactUpToDate            84s (x11 over 51m)  source-controller  artifact up-to-date with remote revision: '0.1.0+4c6f7e800e7e'

Given the chart object is being controlled by the HelmRelease which does a value comparison between object as retrieved from API server versus the template of the release object. I do not see how this can be based on any behavior of the kustomize-controller (as the controller has no knowledge of this object), and my suspicion is some external factor in the cluster itself is triggering the change.

Can also post flux check to see the exact versions please

► checking prerequisites
✔ Kubernetes 1.22.10 >=1.20.6-0
► checking controllers
✔ flux-helm-controller: deployment ready
► fluxcd/helm-controller:v0.27.0
✔ flux-kustomize-controller: deployment ready
► fluxcd/kustomize-controller:v0.31.0
✔ flux-source-controller: deployment ready
► fluxcd/source-controller:v0.32.1
► checking crds
✔ buckets.source.toolkit.fluxcd.io/v1beta1
✔ gitrepositories.source.toolkit.fluxcd.io/v1beta1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta1
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1beta1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ all checks passed

kustomizations.kustomize.toolkit.fluxcd.io/v1beta1

Hmm you are using a CRD at least one year old, kustomize-controller v0.31.0 is not meant to be used with v1beta2. How did you end up with such a setup?

Thanks @hiddeco,

my suspicion is some external factor in the cluster itself is triggering the change.

I cannot deny this. The cluster was recently migrated to new version and it also have a lot of other controllers deployed through different namespaces, sec, monitoring, authN, authZ, certs, etc.
Thanks @stefanprodan,

Hmm you are using a CRD at least one year old, kustomize-controller v0.31.0 is not meant to be used with v1beta2. How did you end up with such a setup?

I have run the following command:
flux bootstrap github \
  --owner="<myorg>" \
  --repository="flux_v2" \
  --branch="main" \
  --path="/dev" \
  --namespace="<example>" \
  --image-pull-secret="docker-auth" \
  --watch-all-namespaces="false" \
  --components="source-controller,helm-controller,kustomize-controller" \
  --verbose

my local flux cli version is:
flux version 0.37.0

@rvolykh something is very wrong with that cluster as it didn't updated the CRDs. Please run flux uninstall and make sure the CRDs are gone. Then bootstrap again and see if the CRDs are at v1beta2, also for all source.toolkit.fluxcd.io.

I can see that in other namespace (of another team) in our cluster is using older flux version. Won't this affect them?

How can they use older versions, you've installed Flux more than once on a cluster?

How can they use older versions, you've installed Flux more than once on a cluster?

yes, it is as it is. All are --watch-all-namespaces="false"

If both Flux instances are having their own bootstrapped setup, they will constantly be competing with the current CRD definition. Which would explain the flipping of values, as we add things over time.

Sound like the root cause

Thanks a lot @stefanprodan and @hiddeco. I will try to check a little more about multiple flux deployment to a single cluster. Otherwise, will probably fallback to older version unless another team is planning to migrate to new version.

You can't deploy multi Flux instances on the same cluster, is like running multiple systemd instances on the same Linux box.


core dump error during 'call-methylation'

Hi,
I was recently using "nonopolish" on NA12878.native.simpson.103015 dataset. But the methylation call module gives core dump error. Will you help me to regarding this issue?
Below are the steps I have followed for the data analysis;
./nanopolish extract -q --type 2d-or-template ../NA12878.native.simpson.103015.fast5/pass/ > NA12878_native_simpson_103015_passed_reads.fastq
bwa mem -x ont2d -t 8 ../../Work/For_nonoporeSeq/hg38.fa ../NA12878.native.simpson.103015.fast5/NA12878_native_simpson_103015_passed_reads.fastq > > NA12878_native_simpson_103015_passed_reads.sam
samtools view -bT ../../Work/For_nonoporeSeq/hg38.fa NA12878_native_simpson_103015_passed_reads.sam > NA12878_native_simpson_103015_passed_reads.bam
samtools sort NA12878_native_simpson_103015_passed_reads.bam NA12878_native_simpson_103015_passed_reads_sorted
samtools index NA12878_native_simpson_103015_passed_reads_sorted.bam NA12878_native_simpson_103015_passed_reads_sorted.bai
./nanopolish call-methylation -t 8 -r ../NA12878.native.simpson.103015.fast5/NA12878_native_simpson_103015_passed_reads.fastq -g ../../Work/For_nonoporeSeq/hg38.fa -b NA12878_native_simpson_103015_passed_reads_sorted.bam > NA12878_native_simpson_103015_passed_reads_sorted_methylation.tsv
nanopolish: src/common/nanopolish_bam_processor.cpp:31: BamProcessor::BamProcessor(const string&, const string&, int): Assertion `m_bam_idx != NULL' failed.
Aborted (core dumped)

If you use the default bam index file name (*.bam.bai) then it should work.
Jared
On Sat, May 20, 2017 at 11:25 PM, sourav ghosh<EMAIL_ADDRESS>wrote:

Hi,
I was recently using "nonopolish" on NA12878.native.simpson.103015
dataset. But the methylation call module gives core dump error. Will you
help me to regarding this issue?
Below are the steps I have followed for the data analysis;
./nanopolish extract -q --type 2d-or-template ../NA12878.native.simpson.103015.fast5/pass/

NA12878_native_simpson_103015_passed_reads.fastq

bwa mem -x ont2d -t 8 ../../Work/For_nonoporeSeq/hg38.fa
../NA12878.native.simpson.103015.fast5/NA12878_native_
simpson_103015_passed_reads.fastq > > NA12878_native_simpson_103015_
passed_reads.sam
samtools view -bT ../../Work/For_nonoporeSeq/hg38.fa
NA12878_native_simpson_103015_passed_reads.sam >
NA12878_native_simpson_103015_passed_reads.bam
samtools sort NA12878_native_simpson_103015_passed_reads.bam
NA12878_native_simpson_103015_passed_reads_sorted
samtools index NA12878_native_simpson_103015_passed_reads_sorted.bam
NA12878_native_simpson_103015_passed_reads_sorted.bai
./nanopolish call-methylation -t 8 -r ../NA12878.native.simpson.
103015.fast5/NA12878_native_simpson_103015_passed_reads.fastq -g
../../Work/For_nonoporeSeq/hg38.fa -b NA12878_native_simpson_103015_passed_reads_sorted.bam

NA12878_native_simpson_103015_passed_reads_sorted_methylation.tsv

nanopolish: src/common/nanopolish_bam_processor.cpp:31:
BamProcessor::BamProcessor(const string&, const string&, int): Assertion
`m_bam_idx != NULL' failed.
Aborted (core dumped)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jts/nanopolish/issues/144, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXxnyyr46WoIjm7XnLqn49H9LIS8YSGks5r766ogaJpZM4NheyM
.

Note that file is R7 data, which is no longer well supported. I suggest trying the more recent data set here instead: https://github.com/nanopore-wgs-consortium/NA12878

Thanks for your prompt reply.
I am going to try with *.bam.bai file, and if it will give the same error I will use the new data for the link provided by you.
Thanks once again.


Run time error raised from image.random_contrast

Environment info
Operating System: SUSE 64bit
Tensorflow version: 0.6.0
Steps to reproduce
I am following the CNN tutorial, and encounter the problem:
E tensorflow/core/common_runtime/executor.cc:264] Executor failed to create kernel. Unimplemented: Op AdjustContrast is not available in GraphDef version 5. It has been removed in version 2. Use AdjustContrastv2 instead.
[[Node: adjust_contrast = AdjustContrast[T=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"](RandomCrop, random_uniform, adjust_contrast/min_value, adjust_contrast/max_value)]]
And something like this:
UnimplementedError: Op AdjustContrast is not available in GraphDef version 5. It has been removed in version 2. Use AdjustContrastv2 instead.
Thank you in advance.

This error is a sign that the code used to run the graph is (much) newer than the code that generated the graph.
It seems to me you must have an older TensorFlow somewhere on the system, could you check that it's clean?

Actually, I am using a server which bases on a lot of computers. And the administrators installed several versions of tensorflow as 'module', including: tensorflow/python2/gcc/0.5.0, tensorflow/python2/gcc/0.6.0, tensorflow_gpu/python2/intel/0.7.1, etc.
The module I loaded is tensorflow/python2/gcc/0.6.0 and I used the examples of tensorflow at the version 0.6.0.

I'm not sure I'll be a lot of help in this kind of situation.
I suggest you stud your code with assertions about the tensorflow version to make sure you're on 0.7.1 when you create the graph, and then do the same when you actually run it. If you write out a graph, you can check its supported graphdef versions too, it's the versions field in core/framework/graph.proto, filled by core/public/version.h.
You should probably also consider running one of our docker containers instead of using the installed binaries (if that is possible), or at least install into a virtualenv to get at least some isolation from the rest of the versions.
I'll close this bug, I don't believe there's an indication of a bug, but please feel free to continue commenting, I will try to help out if I can.

In the end, the administrator of my server helped to install newest version (0.8) of tensorflow. I tried to install on a virtualenv, but failed. I guess my problem was raised from conflict of versions of tensorflow. Thanks anyway.


Pause stream consumption in realtime table

The following document proposes a design to pause/resume consumption in realtime tables:
https://docs.google.com/document/d/19uKzPRowJ8WLE0A4g6i8XLOBwqpswH2_OvFvbxxZ_X4/edit#
This feature can be used to address the following issues: #6302, #7280, #6854, #6679, #7100, and #7039.
CC: @mcvsubbu @npawar @Jackie-Jiang @snleee

https://github.com/apache/pinot/pull/8986 adds the support for pause/resume feature.


Python: added token usage with client base

Motivation and Context

Added token usage tracking to the OpenAI classes, similar to how that is done in dotnet.
Similar approach as #2526 but for Python
With to_dict and from_dict methods on the (Azure)OpenAI service classes.
TODO: add a similar construct to python for the SKContext.LastResult.
Description

Adds a completion client base class with trackers for the prompt, completion and total tokens.
This has a add_tokens method that can be used to increment the totals.
This is called from the OpenAI completion classes to add the tokens.
Also added serialization to the service classes, using pydantic, building on #131
Added deprication for "logger" parameter on Azure OpenAI service classes, this was inconsistent with OpenAI, which used "log", added both to AzureOpenAIChatCompletion class with a warning when using "logger" to not break existing implementations.
Added tests for from_dict and to_dict on the Azure classes.
Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

Split this PR into two


Refactor

Two main changes:

Now uses filecoin-address library
Uses a fork of signing-tools library

Yeah, the front end would call sendTx which is already parameterized.
To get the lists, forEach would have to be called but that's not exported yet and is a bit cumbersome, I'll push something else soon.


Broken link causing nightly build failure

E.g. this build log
Nightly build should pass again, finally, if we replace this dead link in the Times and Dates notebook.
The link is about the definition of lunar day. The old link to http://oceanservice.noaa.gov/education/kits/tides/media/supp_tide05.html seems to be dead. I'll look through the NOAA educational site to find something equivalent.

Here it is: https://tidesandcurrents.noaa.gov/glossary.html#lunarday
I'll fix the link in the notebook.


Get the associated char of a GlyphId ?

I can query the glyph ID from a char but how to do the opposite?
The use case is to make a list of char available in the font. To do that, I'm able to get the number of glyph with glyph_count(). It says "Glyph identifiers for this font will always be in the range 0..self.glyph_count()", therefore I understand that all the glyphs are from 0 to this number. But then I don't know how to retrieve the char associated to each glyph ID.
Also, I'm not sure if all glyph has an associated char. I think it does, but I can't be sure.

By the way, I prefer ab_glyph interface over rusttype, however, for developers who don't have a strong background in font-related stuff, it's a bit cryptic. Stuff like 'side bearing', kern, advance, ascent, descent,  I was able to figure out the meaning of some but not all of them. Do you have a link where I could get those infos ? For instance, even the description of the draw() message is unclear, at least to me: "[...] with a coverage value in the range [0.0, 1.0].". It took me time to understand it was the amount of gray color. But that's just my opinion, I may be lacking in the literature.

When it comes to new functionality, like glyph_id -> char there are probably two main things to consider

How would it be done using ttf-parser directly?
Should the functionality be provided by ab_glyph?

ab_glyph isn't intended to supply everything in ttf-parser, so I'd start with using ttf-parser alongside then proposing the addition to this crate if that makes sense.
ab_glyph doesn't expose ttf-parser internals intentionally but you can just build a new Face from the font data.
let font = ab_glyph::FontRef::try_from_slice(EXO2)?;
let ttfp_face = ttf_parser::Face::from_slice(EXO2, 0)?;

it's a bit cryptic

Yes that's my personal experience with font stuff too. PRs to improve the docs are very welcome! This answer provides some info on ascent/descent I'm not sure we can put images in the docs yet. Maybe ascii?
But the coverage value isn't "amount of gray color", drawing does not support any color. It just returns how much the glyph covered a particular pixel. Let's improve this one, let me know your thoughts: #19

ttf_parser now allows for reading all codepoints from a font. This way you can build up a table matching codepoint to glyphID (and thus vise-versa).
This should at least work, although not very performant for large fonts.

I stumbled over this issue because iterating over all characters and getting their glyph IDs used to work fine in rusttype 0.8 (with stb_truetype) but is terribly slow with rusttype 0.9 and ab_glyph (with ttf-parser; ~ factor 5 in release mode, much worse in debug mode).  (I thought I had created an infinite loop when refactoring from rustttype 0.8 to 0.9, but no, it’s just really, really slow!)  Consider this benchmark:
running 4 tests
test stb_truetype          ... bench:   4,600,619 ns/iter (+/- 8,141)
test ttf_parser            ... bench:  23,700,239 ns/iter (+/- 137,010)
test ttf_parser_codepoints ... bench:      58,589 ns/iter (+/- 259)
test ttf_parser_subtable   ... bench:   9,930,148 ns/iter (+/- 813,532)

#![cfg(test)]
#![feature(test)]

extern crate test;

const DATA: &[u8] = include_bytes!("/usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf");
const COUNT: usize = 668;

#[bench]
fn stb_truetype(b: &mut test::Bencher) {
    let font = stb_truetype::FontInfo::new(DATA, 0).unwrap();
    b.iter(|| {
        let mut count = 0;
        for c in char::default()..std::char::MAX {
            if font.find_glyph_index(u32::from(c)) > 0 {
                count += 1;
            }
        }
        assert_eq!(count, COUNT);
    });
}

#[bench]
fn ttf_parser(b: &mut test::Bencher) {
    let font = ttf_parser::Face::from_slice(DATA, 0).unwrap();
    b.iter(|| {
        let mut count = 0;
        for c in char::default()..std::char::MAX {
            if font.glyph_index(c).map(|gid| gid.0 > 0).unwrap_or(false) {
                count += 1;
            }
        }
        assert_eq!(count, COUNT);
    });
}

#[bench]
fn ttf_parser_subtable(b: &mut test::Bencher) {
    let font = ttf_parser::Face::from_slice(DATA, 0).unwrap();
    let subtables: Vec<_> = font.character_mapping_subtables().filter(|s| s.is_unicode()).collect();
    b.iter(|| {
        let mut count = 0;
        for c in char::default()..std::char::MAX {
            if subtables.iter().filter_map(|s| s.glyph_index(u32::from(c))).any(|gid| gid.0 > 0) {
                count += 1;
            }
        }
        assert_eq!(count, COUNT);
    });
}

#[bench]
fn ttf_parser_codepoints(b: &mut test::Bencher) {
    let font = ttf_parser::Face::from_slice(DATA, 0).unwrap();
    let subtables: Vec<_> = font.character_mapping_subtables().filter(|s| s.is_unicode()).collect();
    b.iter(|| {
        let mut chars = std::collections::HashSet::new();
        for subtable in &subtables {
            subtable.codepoints(|c| {
                use std::convert::TryFrom as _;

                if let Ok(ch) = char::try_from(c) {
                    let idx = subtable.glyph_index(c);
                    if idx.map(|gid| gid.0 > 0).unwrap_or(false) {
                        chars.insert(ch);
                    }
                }
            })
        }
        assert_eq!(chars.len(), COUNT);
    });
}

You have to decide whether you want to add a wrapper for the codetables approach to ab_glyph, but I wanted to leave this here in any case for everyone with the same problem.

Thanks, I think that ttf_parser_codepoints example points us towards how this can be done with ttf-parser.

Should the functionality be provided by ab_glyph?

This isn't core functionality of ab_glyph, which means I don't 100% understand the use case myself. But it is quite related to the concepts ab_glyph does already expose (char -> GlyphId). So perhaps we should expose a lightweight method for this.
Would a method where you could iterate through distinct (char, GlyphId) pairs suffice?
struct ExampleFont<'a> {
    face: &'a ttf_parser::Face<'a>,
}

impl<'a> ExampleFont<'a> {
    fn codepoints(&self) -> impl Iterator<Item = (char, ab_glyph::GlyphId)> + 'a { ... }
}

for (ch, glyph_id) in font.codepoints().sorted_by_key(|&(_, gid)| gid).take(20) {
    eprintln!("{}: {:?}", glyph_id.0, ch);
}

1: ' '
2: '0'
3: '1'
4: '2'
5: '3'
6: '4'
7: '5'
8: '6'
9: '7'
10: '8'
11: '9'
12: 'A'
13: 'B'
14: 'C'
15: 'D'
16: 'E'
17: 'F'
18: 'G'
19: 'H'
20: 'I'

I don't 100% understand the use case myself

To add some context:  printpdf needs to build a character map when embedding fonts into a PDF document.  Currently, it uses rusttype 0.8 and iterates over 0x0000..0xffff.  I tested upgrading to 0.9 or using ab_glyph.  In the meantime, I realized it might be sufficient to use ttf-parser directly for this usecase because printpdf only has to access the unscaled glyph metrics.  So I won’t be mad if you consider this feature out of scope for ab_glyph.  That being said, an API for easier access to the codepoints would definetely be useful, either in this crate or in ttf-parser.

Would a method where you could iterate through distinct (char, GlyphId) pairs suffice?

Yes, I think that would be a good interface.

I would absolutely love this, but in the original discussion for ttf_parser it was brought up that there could be duplicate characters with different glyphids in different tables. This is some kind of undefined behavior in ttf/otf fonts I think, so it would need to be decided whether or not to filter out duplicates, or something else.
This is where I kind of disagree with the ttf_parser implementation because it separated the tables and requires you to get the glyphID yourself after the fact, while the glyphID is literally up for grabs when iterating over the codepoints. This does mean that you always get a correct mapping from char->glyphID, but it lowers performance because you basically always need the glyphID so why not provide it.
@robinkrahl The way I did it by basically just doing the same as you did in your bench. I tried to advocate for an easier API as well but it didn't work.

Let me know what you guys think of #24. Does the naming make sense, does it help?

Yeah the naming makes sense to me. I would switch the tuple order around because the char is the main object and id is just a property related to the char but that is just nitpicking.

I would switch the tuple order around because the char is the main object and id is just a property related to the char

Yeah I had it that way to start with. I'm not 100% but it seemed nice to have (GlyphId, char) to make it easy to collect into a lookup map (since char -> GlyphId lookup is already provided by Font::glyph_id).
let map: HashMap<_, _> = font.codepoint_ids().collect();
assert_eq!(map.get(&GlyphId(75)), Some(&'!'));


build(deps): Add flake8-bugbear

See also: https://github.com/PyCQA/flake8-bugbear

Codecov Report

Merging #361 (4965f7c) into master (788c245) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 4965f7c differs from pull request most recent head d5df623. Consider uploading reports for the commit d5df623 to get more accurate results

@@            Coverage Diff            @@
##            master      #361   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines           73        73
=========================================
  Hits            73        73

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


Add link to PluralSight and link to F# for fun and profit page

Looks good, thanks @ErikSchierboom!


Empty error messages in PR comments

See as an example: https://github.com/osbuild/osbuild/pull/151
Error message:
(0)
Reason:

Mentioned repository uninstalled packit app, so we are left empty-handed for debugging or retrying.


Is it possible to execute multiple queries in a single call?

The documentation explains how to execute multiple mutations in a single call but not multiple queries. I've tried using the same approach as documented but it doesn't work. Is this possible at the moment? Thanks.

I worked it out; it's actually quite obvious now! Example query with multiple roots below.
var query struct {
    Customers []struct {
        Id int
        ...
    } `graphql:"customers(where: { ... })"`
    Orders []struct {
        Id int
        ...
    } `graphql:"orders(where: { ... })"`
}


brev-cli: 0.6.204 -> 0.6.206

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/brevdev/brev-cli/releases.
meta.description for brev-cli is: Connect your laptop to cloud computers
meta.homepage for brev-cli is: https://github.com/brevdev/brev-cli
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.6.206 with grep in /nix/store/nx8myixr8mc40x92d2kx78fvpz84h60n-brev-cli-0.6.206
found 0.6.206 in filename of file in /nix/store/nx8myixr8mc40x92d2kx78fvpz84h60n-brev-cli-0.6.206

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
brev-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/nx8myixr8mc40x92d2kx78fvpz84h60n-brev-cli-0.6.206 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A brev-cli https://github.com/r-ryantm/nixpkgs/archive/b160281fe91ff054dda7405b1ef17d7e664a0f96.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/nx8myixr8mc40x92d2kx78fvpz84h60n-brev-cli-0.6.206
ls -la /nix/store/nx8myixr8mc40x92d2kx78fvpz84h60n-brev-cli-0.6.206/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

brev-cli

Maintainer pings
cc @dit7ya for testing.

Result of nixpkgs-review pr 216286 run on aarch64-darwin 1

1 package built:

brev-cli


added welsh support

With #144 as a caveat, this looks good to merge.
http://www.youtube.com/watch?v=Qa_gZ_7sdZg&t=2m17s

:+1:


feat: add more reasoning questions

@kjappelbaum I modified it to: Considering a geometry predicted using the VSEPR model

the content looks now very good to me - we might only want to wait with merging until we clarified the keywords


Bug in small screen size devices

I tested it in my LG p990 whose screen size is 480*800 . The datePicker can't scroll to the other pages which means that I can only pick a date in current month.

Is that because the dialog itself scrolls? (I recently added some scrollviews around the content)

@wdullaer  Unfortunately no, the dialog doesn't scroll and the content in the dialog doesn't scroll either.

@wdullaer Maybe this time it's a OS problem ? I then tested it on a virtual device with a 7201280 screen on Android 4.1.1 (in fact it's a virtual Galaxy Nexus) . The problem still exist . Then I tested it on a virtual Moto X whose screen size is also 7201280 on Android 4.4.4 , the picker worked as expected.

@wdullaer  I've found that even though I can't scroll the picker with finger swiping ,  I can scroll it with the mouse wheel when using a virtual device

I have the same problem on physical Android 4.1.1 480x800 device. Everything was ok in 1.4.2, so it looks like this commit caused it.

@PavelSynek That is exactly what I thought, but I can't reproduce the behaviour on my devices, which is why I was still asking some questions.
I'll release a new version this evening.

I found same problem on Android 4.2.2 devices, i can't scroll to select next month or next year.


Fix single result page test flakiness

Fixes

Fixes #3112 by @obulat
Description

The use-layout composable watches the page width and updates the breakpoint property in the ui store if the page width changes.
We used throttle to prevent frequent updates from affecting the site performance. However, throttled watch meant that we might not update the breakpoint to the last screen width.
I think that when taking the screenshot, the screen width is lowered, the breakpoint is updated so the layout is changed to xs layout (so, the metadata is shown as a vertically), and then the breakpoint is not updated to the value that the screen ends up with (the non-xs) - so the metadata stays vertical instead of being horizontal for sm and up.
This PR also adds the single result page visual regression tests for when additional_search_views flag is on. In this PR, they are the same as the off snapshots, but they will be updated in #2933 for audio and in #3164 for images.
Testing Instructions

I will re-run the CI several times to check that there is no flakiness.
Checklist

[ ] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.
[ ] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Playwright failure test results: https://github.com/WordPress/openverse/actions/runs/6482175402
It looks like some of the Playwright tests failed. You can download the trace output and image diffs for the failed tests under the "Artifacts" section in the above page.
You can read the docs on how to use this artifact.
If the test is flaky, follow the flaky test triage procedure.

This failure was caused by long running tests and not by the failure of snapshot tests.


Exhibition json ld

References #440
Type
🚑  Health
Value
Adds exhibition data for SEO
Screenshot

Checklist
All

[x] PR labelled and assigned
[x] Any introduced code complexity has been flagged

@davidpmccormick have you run it against:
https://search.google.com/structured-data/testing-tool ?

Have you noticed the errors we're getting because it's pulling schema in from the HTML?
Probably worth pulling out?

I have not – can you show me/explain?

I have now. And updated.


No Vim Session

I did all the steps according to readme, but vim session doesn't come up when I open a problem. Only "INFO: Source code downloaded from server." appears on the console. By the way, I use MacVim.

What did you set as your Vim command in the settings? I'm actually not sure what it should be to invoke MacVim (maybe the path to the executable file within the app bundle?). It's been so long since I've used OS X...

I used '/usr/local/bin/gvim'. It works in terminal.


Fix safe set

NAG debug uncovers a problem with variable "var" in safe_set.  This variable needs to be intent(inout)

Wait a sec...
My Held-Suarez changes are in here too and I don't want them yet.

OK - my two letter commit is ready for review!

Actually, Do we want to reference issue #15 above so that it is closed once this PR is merged?


Best way to determine "project name"

I'd like to determine a project name (similarly to how docker compose determines a project name based on the directory). In my case, I'd like to set the kind cluster name environment variable so that every project gets its own kind cluster by default.
My idea is to derive the project name from the DEVENV_STATE env var, but I'm not sure it's the best option.
Also, I remember seeing some discussions about dropping the impure requirement which may make that solution non-functional anyway.
Any thoughts? Is this something that might be interesting as a feature implemented in devenv?

What if we allowed auto-generating the project name?

I guess that could work, but if the name is used in "global" resources, like docker container name, it might be rather hard to trace it back to the project if the name is random.
What do you think?


Update dynamics-open-api.md

Changed Azure Active Director to Azure Active Directory

Docs Build status updates of commit 639a99d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

dynamics-nav/api-reference/v1.0/dynamics-open-api.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Created a LightCurveCollections and TargetPixelFileCollections class

This class collects together multiple lightcurves or tpfs and allows operations over all of them such as:

Plot
PCA (TODO)

The TPFCollections hasn't properly implemented

Plot
PCA

To create a Collections class, you need to provide the lightcurves/targetpixelfiles (targets) in a tuple object. Within the Collections class, specific targets can be referenced through their keplerids. These can be used to retrieve targets, add new targets to your collection, etc. Or you can treat the Collections class as one object (the main use) and it behaves similarly to the single lightcurve or TPF class.

This is in collaboration with #164.

You can add a tutorial for LCC and TPFC in docs/source/tutorials. Just something very short, as we will update it when we fix from_archive.

Also working on a jupyter notebook.

I also created the jupyter tutorial for LightCurveCollection.

This is really good work! Thanks for putting this together Johnny it's super impressive. I'm going to ask @barentsen to please review your code now as I think it's in a really good shape. He normally does very thorough reviews :)
Make sure you get those temporary files (e.g. lightkurve.py~ and setup.py~) out of the PR before we merge it.

Travis is failing and I'm not sure it's just a mast error it looks like there might be something a little funky with the test?

Yes, the Travis build is failing to download from the mast website but I think its most likely a bug with Travis and not with lightkurve. I've removed the temporary files and I'll push it again!

New PR in #187


Help

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

I already warned you: https://github.com/Homebrew/brew/pull/11811
I'm going to block your account now.


Adding opts to contract.invoke

An attempt at fixing #75
I haven't yet tested, and I'm not sure this is breaking any of the project's conventions. But I wanted to at least get the work going, since I'm currently needing this feature

This change looks good, just a couple of small things to do before I can merge:

Generate a changeset with yarn changeset, for this change I think patch is fine.
Add the new options to the documentation.
Maybe change the demo to use the overrides.

Also can you update the version of starknet to the minimum one that includes the overrides?

Merged in #116


Cron Scaler to Scale the deployments as per a particular cron schedule.

A clear and concise description of what scaler you'd like to use and how you'd want to use it:
Cron scaler is being developed in order to scale the deployments based on a particular time schedule. Whenever the currentTimestamp is inbetween a start and endTime, we say the scaler is active and inactive in all other times.

Scaler Source: Deployment replicas from the k8s deployment in the namespace itself.
How do you want to scale: The cron scaler will scale the pods to the desiredReplicas when the scaler is active. By Active, I mean the timestamp should be between the start and end time specified in the metadata. All the other times, the replicas will be equal to the minReplicaCount
Authentication: None

By scaler source, I understand something like kafka topic, rabbitmq etc. Please correct me if I am wrong.

@ckuduvalli yeah scaler source, is the source of the events, as you mentioned eg. kafka topic..)
In this case, I suppose the source would be the cron implementation itself?
There's community call this Thursday https://keda.sh/community/, you can join and we can discuss it.

@zroubalik I have a question regarding my scaler. I implemented a cron scaler. What I am observing is that keda passes the metric to scale up to some value x, but HPA is scaling to some value less than x due to CPU utilization taking over. Is there a way I can have my scaler override the HPA?

@ckuduvalli yeah scaler source, is the source of the events, as you mentioned eg. kafka topic..)
In this case, I suppose the source would be the cron implementation itself?
There's community call this Thursday https://keda.sh/community/, you can join and we can discuss it.

Sure.. I will join the call on Thursday

This is interesting and at the same time it doesn't need hpa to determine how many to scale to. Similar to ScaledJob.

This is interesting and at the same time it doesn't need hpa to determine how many to scale to. Similar to ScaledJob.

This happened due to my misunderstanding of the metric. Will discuss over the call today.

And I could not add the agenda for cron scaler in the hackmd

Good idea for a scaler if you ask me!