helm upgrade does not re-create namespace when it is gone

When the namespace of a release had been deleted, upgrade fails:
Error: UPGRADE FAILED: failed to create resource: namespaces "xxxxx" not found

This is arguably a special situation, but I would expect helm to re-create the "resources that do not already exist" (https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L201), including namespaces.
How about calling ensureNamespace there in Update, as is done in Create? I can try and send a PR for this.

Is the namespace explicitly declared in the chart?

Good point, it is not. This is still slightly inconsistent with the behavior of install though, but that is a good workaround.

You're right. Just trying to figure out how best to re-create the problem. Thanks!

Actually, I am wondering if including the namespace in the chart necessarily works: is it guaranteed to be applied first? I guess if it is not, we could still get the issue above.

The same for me helm upgrade -i RELEASE CHART --namespace XXX throws "Error: UPGRADE FAILED: failed to create resource: namespaces "XXX" not found" even though helm install --name RELEASE CHART --namespace XXX succeeds. It is indeed inconsistent.

Another issue, when I crated namespace object like so:
apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Release.Namespace }}

and executed helm upgrade -i RELEASE CHART --namespace XXX, I get following error:
Release "segmenter" does not exist. Installing it now.
Error: release segmenter failed: namespaces "segmenter" already exists

Only the second time I run this command, deployment succeeds..

My workaround: Add namespace: {{ .Values.namespace }} to each resource and don't use --namespace flag
In helm list it looks like it's deployed under default namespace though.
@technosophos Isn't it weird that even Helm is supposed to work on global level, there are "namespaces" as first-class concept in both cli and helm list output? Wouldn't it make more sense to drop namespace concept from helm cli at all and allow to override namespaces of all resources in some way in templates? Like:
override:
  metadata:
    namespace: {{ .Values.namespace }}

/cc @tback @wjkohnen

Just wanted to say that I also just ran into this. I expected helm upgrade --namespace namespace to install my charts into the specific namespace just like install does.
Note that in my situation, the namespace already exists and it still doesnt install in the namespace

+1 just ran into this just now!

yeah...why is it not using the specified namespace on upgrade? anybody can explain?

The easiest way I know how to reproduce the issue is:
$ helm install stable/mongodb --name=mongodb --namespace=mongodb
$ helm delete mongodb
$ kubectl delete ns mongodb
$ helm upgrade --install mongodb stable/mongodb --set replicaCount=2
Error: UPGRADE FAILED: failed to create resource: namespaces "mongodb" not found

Likely, it is querying the namespace to prepare diffs, and the namespace doesn't exist. So no resource diffs can be generated. And it dies with an error.
On an install, we don't have to perform any queries on a namespace until after the namespace is created.

Just experienced the same issue.

/remove-lifecycle stale

Same issue here... It makes helm practically unusable if one tries to create namespaces and default resources (like default ingress per NS, default http backends) for "customers". If you add a new NS to the config - the upgrade fails, so does a install. Kinda stalled there...

Thank you @bacongobbler. Just for clarification, I understand if helm upgrade does not support re-creating namespaces. But, we use the --install flag along with upgrade by default helm upgrade --install and it would be nice if namespaces are also re-created in that case (when --install flag is used).

Oh, that is interesting... I thought --install walked the entire installation process if Tiller detected that the given chart was a new one. Or is this only happening when the release walks the upgrade path?

FYI, to be able to reproduce easily the original issue:
$ helm install stable/mongodb --name=mongodb --namespace=mongodb
$ kubectl delete ns mongodb
$ helm upgrade --install mongodb stable/mongodb --namespace=mongodb
Error: UPGRADE FAILED: "mongodb" has no deployed releases

@ultimateboy, I tried yours explained here https://github.com/helm/helm/issues/2013#issuecomment-335287205, but you are missing a --purge for the helm delete and a --namespace=mongodb for the helm upgrade. Thoughts?

Is it recommended practice to add a namespace.yml file like so:
apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Release.Namespace }}

any updates about this bug ?

also seeing this issue

helm upgrade --install should have the same behaviour as helm install and create the namespace if missing.

For context, helm upgrade --install just checks the release history for an existing release. If it's not present, perform a helm install, otherwise do a helm upgrade. Hope that helps clear things up.
In the install case, helm upgrade --install will create the namespace as expected. The issue here is the problem where helm upgrade will not re-create the namespace if it was deleted out-of-band. It applies to both helm upgrade and helm upgrade --install because the code paths are identical.

In my  experience that is not what happens. Today I was using helm upgrade --install and got an error saying the namespace doesn't exist.

any updates on this?

Closing. Helm 3 no longer creates the namespace as part of helm install (see #5753 for background context on why we changed this behaviour - this issue being one of those reasons). Thanks.

i run this command and found below error:
helm install --name XXXX  ./XXXX-chart --set service.type=ClusterIP --namespace=withhelm
Error: release XXXX failed: namespaces "namespace" not found


Move BwUni-CI to nla-gpu1 during maintenance

Since BwUniCluster is currently under maintenance, its jobs are moved to our new AMD systems for now.

Would it be possible to register a different runner under the same tag temporarily? Or is this change strictly necessary?

I think doing this in the background would make it easier to change back in the future, without having to create another PR.


Options for getSimilarWords and getNeighbors are not taken into account

Hi,
I tried this code :
const word2vec = require('word2vector');
const model = 'data/frWac_postag_no_phrase_700_skip_cut50.bin';
const word = 'yoga_n';

word2vec.load(model);
console.log(word2vec.getSimilarWords(word, {N:5}).length);
console.log(word2vec.getNeighbors(word2vec.getVector(word), {N:5}).length);

It displays 40 and 40.
In src/w2vLeeXun.cc, the number of words to be shown is set to 40 and never change.
const long long N = 40; // number of closest words that will be shown

Thanks for reporting. Will check asap.

#4  @LeeXun - I made a fix for this issue, please take a minute to review it and merge.  Thank you! :)
PS: Also I've changed the behavior when getSimilarWords is receiving an unknown word: before it was exit the NodeJS process, but now it just returns nothing, that I think makes sense.

Special thanks to @nowherenone
Merged in v2.1.0!


Synchronous API for creating instances and Hot-reload fix

This PR mainly focuses on creating Ably instances in a synchronous manner.
The following changes were made possible as all other operations on each ably instances is an asynchronous operation.
If not async? then, Sync + Lazy = Slazy!!! 😉

All platform calls from dart side are made lazy
Singleton Ably library instances on Android side (iOS will be caught up)

A peek on new APIs
import 'package:ably_flutter_plugin/ably.dart' as ably;

final clientOptions = ably.ClientOptions.fromKey("<YOUR APP KEY>");
clientOptions.logLevel = ably.LogLevel.verbose; //optional
ably.Rest rest = ably.Ably.Rest(options: clientOptions);

function testRest(){
  ably.RestChannel channel = rest.channels.get('test');
  await channel.publish(name: "Hello", data: "Ably");
}

function testRealtime(){
  ably.Realtime realtime = ably.Ably.Realtime(options: clientOptions);
    realtime.connection.on().listen((ably.ConnectionStateChange stateChange) async {
    print('Realtime connection state changed: ${stateChange.event}');
  });
}

Hot-reload issue fix 🌶  ♻  🎉  🎉

registerAbly is now used to dispose off any registered platform instances
Android StreamsChannel source is replicated and necessary changes are made to dispose all listeners on hot-reload (Will be removing the streams_channel plugin dependency eventually)

NOTE: Draft PR supporting Android only.

@QuintinWillison @mattheworiordan @paddybyers Please share your feedback on the API. Will make necessary changes and proceed with implementing iOS platform related changes.

Thanks for the responses to my review comments, @tiholic.
I think there are still a few improvements before we can merge this. Thanks.

@QuintinWillison Yeah, this PR is still in draft state. I just getting some inputs on how the final API should look like.
Now that we have enough information to proceed further, I will finish iOS implementation and try to address all the unresolved comments from above.

@QuintinWillison iOS side caught up, if the runway is clear for landing, we can merge this.
Regarding the pubspec.lock changes, that was probably due to automatic minor version upgrade behavior.
^A.B.C will upgrade packages if minor version releases are available. If we need strict version for dependencies, we can go with package: 'A.B.C' instead of package: '^A.B.C' (ref: https://dart.dev/tools/pub/dependencies)
Updated DeveloperNotes with instructions on static code analysis (includes all build time checks)

Regarding pubspec.lock changes, I'm happy to leave things as they are for now and thank you for explaining. 😁
There is perhaps a wider discussion to be had here at Ably, across all client libraries, around dependency version management / auto management.


GO:0004812 "aminoacyl-tRNA ligase activity”

Steve Marygold sent me an email
"I was going to ask that EC:6.1.1 be added to GO:0004812 "aminoacyl-tRNA ligase activity” - that’s a grouping term, so the partial EC should be OK, right?
But I checked the ‘change log’ for that term and I see that the 6.1.1 xref was recently removed."
By 'recently' in quickgo it means
2019-03-16 | Deleted | XREF | EC:6.1.1
Since this is a grouping term it's ok to have a partial EC; I guess I could have done it inadvertently in my EC cleanup. I will add it back

Fixed this and added some rhea to a few children that were missing them.
However, may have to remove again because
There is ONE EC entry that is NOT a tRNA ligase EC:<IP_ADDRESS>
https://www.qmul.ac.uk/sbcs/iubmb/enzyme/EC6/1/1/
D-alanine—poly(phosphoribitol) ligase
ATP + D-alanine + poly(ribitol phosphate) = AMP + diphosphate + O-D-alanyl-poly(ribitol phosphate)
I can see what because of the mechanism:
In a two-step reaction the ligase forms a high energy D-alanyl AMP intermediate and transfers the alanyl residues from AMP to lipoteichoic acid. (ester bond). PMID:7797557
I'm leaving the 6.1.1 for the moment because
This term is not in GO and RHEA has no entry for EC:<IP_ADDRESS>; I am emailing them about this.


GitHub Workflows security hardening

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted.
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

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

/area security
/kind enhancement

The test failure seems unrelated to the change. I created the following issue for the flaking test - ref https://github.com/gardener/gardener/issues/6607.
/test pull-gardener-integration

@oliver-goetz do you know why tide is not auto-merging this PR? It is in the merge pool since yesterday with all tests passed.

Github Apps do not have the permissions to change github workflows. That's a Github security feature.
Thus, I'll merge it manually.


Added: allow self_hosted_domain to be defined using a constant.

This takes care of issue https://github.com/plausible/wordpress/issues/78
This allows a constant, PLAUSIBLE_SELF_HOSTED_DOMAIN to be used to define the self_hosted_domain, as follows:
define('PLAUSIBLE_SELF_HOSTED_DOMAIN', 'yourdomain.com');
@metmarkosaric This should probably be mentioned somewhere in the documentation.

Nice! It would be cool to populate the self-hosted <input> and set disabled (so you know you can't change it) if this is hard-coded.

True. Should probably be accompanied by a notice telling us why the input is disabled. To avoid users rage quitting. 😅

This is live in the current version! I've added a little note to the option description to inform people about the usage of the constant.


Can't write welcome text to screen (step 41 - 42)

I've been slowly following this tutorial for a few days. hadn't had at major problems until now: I can't get the welcome message (editor name and version) to show up. My editorDrawRows() function (named voided_draw_rows() in my code) and editorRefreshScreen() (voided_refresh_screen()) are pretty much exactly the same as in the tutorial, so I don't know what's causing this. My code is in my voided repo.

ok i figured something out, but I still can't get rid of the bug: the row count is completely wrong, double what its supposed to be, and the editorRefreshScreen() function isn't actually clearing the screen. whenever i give the program some input, it re-prints the entire screen, scrolling the terminal down and just writing the new screen under the old one. I don't know what's causing this.

Hi!


Getting apparent magnitude of a star for a specific date

Hi. Can this library be used to find out what the apparent magnitude of a particular variable star was/will be at a particular time?
If so, would you please post an example source code for Algol? Thank you very much!

Hello!
This can be done in a few steps. The prediction of the apparent magnitudes on future dates won't be as accurate as those from a dedicated eclipsing binary modeling code, but probably enough to plan observations.
First, you need a light curve for Algol. I used STScI's MAST service to get one from the TESS archive [a full-frame-image (FFI) high level science product (HLSP)]: hlsp_qlp_tess_ffi_s0018-0000000346783960_tess_v01_llc.txt
This is a CSV file that you can read in:
import pandas as pd
import numpy as np

lc = pd.read_csv('hlsp_qlp_tess_ffi_s0018-0000000346783960_tess_v01_llc.txt', usecols=[0, 1], names=['BTJD', 'flux'], comment='#')

You can then use some astrobase functions to find the epoch of the primary eclipse phase (time at eclipse minimum), given the period of the eclipsing binary (2.867328 days from Wikipedia):
from astrobase.lcfit import nonphysical
from astrobase import plotbase

# use a Savitsky-Golay smoothing 'fit' to find the epoch
fit_results = nonphysical.savgol_fit_magseries(np.array(lc['BTJD']), np.array(lc['flux']), np.full_like(np.array(lc['BTJD']), 0.001), 2.867328, plotfit='savgol-fit.png', magsarefluxes=True, sigclip=50.0)

epoch = fit_results['fitinfo']['fitepoch']

Then, you can use this to plot a phased flux time-series to estimate some parameters for an eclipsing binary model fit:
times, fluxes, errs = np.array(lc['BTJD']), np.array(lc['flux']), np.full_like(np.array(lc['BTJD']), 0.001)
plotbase.plot_phased_magseries(times, fluxes, 2.867328, magsarefluxes=True, sigclip=50.0, epoch=epoch, outfile='phased-lc.png')

That gives you a plot like the one below:

Next, you can fit a simple eclipsing binary model:
from astrobase.lcfit import eclipses

ebfit = eclipses.gaussianeb_fit_magseries(times, fluxes, errs, [2.867328, 1796.84939402, 0.4, 0.1, 0.2, 0.5], plotfit='ebfit.png', magsarefluxes=True, sigclip=50.0, param_bounds={'period': 'fixed'})

This makes a fit plot:

Using this model, you can predict the magnitudes of the star into the future. First, convert the units of time in the light curve from TESS to BJD (Baryocentric Julian Date):
ref_bjd = 2457000.0
times_bjd = ref_bjd + times

# get the eclipse fit params
fit_params = ebfit['fitinfo']['finalparams']

# convert the fit epoch into BJD as well
fit_params[2] = ref_bjd + fit_params[2]

Generate an array of BJDs into the future:
from astrobase import timeutils
jd_now = timeutils.jd_now()
jd_to_oneyear = np.linspace(jd_now - 3.0, jd_now + 365.0, num=365*24)

Use the eclipse model to predict fluxes on these dates:
from astrobase.lcmodels import eclipses as ebmodels

model_fluxes, model_phases, model_times, _, _ = ebmodels.invgauss_eclipses_func(fit_params, jd_to_oneyear, np.full_like(jd_to_oneyear, 1.0), np.full_like(jd_to_oneyear, 0.0001))

Convert model fluxes to TESS apparent magnitudes. The median TESS apparent magnitude of Algol is 3.3684 and the relation between the normalized flux in the TESS light curve and apparent magnitude is:
apparent_mag - object_tess_mag = -2.5 log(normalized_flux)

So we can do the following to get an array of apparent magnitudes:
model_mags = 3.3684 - 2.5*np.log10(model_fluxes)

To figure out the apparent brightness of Algol on specific dates, you can convert these to Julian dates and then use the model output to see the magnitudes on those dates. For example, let's get the apparent magnitude light curve for the next two weeks.
from datetime import datetime, timezone, timedelta

# get today's date and two weeks in the future
date_now = datetime.now(tz=timezone.utc)
date_twoweeks = date_now + timedelta(days=14)

# convert dates to Julian dates
jd_now = timeutils.datetime_to_jd(date_now)
jd_twoweeks = timeutils.datetime_to_jd(date_twoweeks)

# sort the model output by time first
sorted_time_idx = np.argsort(model_times)
sorted_model_times = model_times[sorted_time_idx]
sorted_model_mags = model_mags[sorted_time_idx]

# then apply the date filter
date_filtered_idx = np.where((sorted_model_times >= jd_now) & (sorted_model_times <= jd_twoweeks))
date_filtered_times = sorted_model_times[date_filtered_idx]
date_filtered_model_mags = sorted_model_mags[date_filtered_idx]

Now, you can plot the apparent magnitudes for the next two weeks:
import matplotlib.pyplot as plt
plt.figure()
plt.scatter(date_filtered_times, date_filtered_model_mags, marker='.')
plt.ylim(4, 3)
plt.savefig('algol-next-twoweeks.png')

Thank you so much for your wonderfully elaborated response. Unfortunately, I'm pretty much a layman when it comes to astronomy and don't really understand it. Actually I need a function to calculate the apparent magnitude of Algol for a given time to generate data for my AI project. ( Later I will need the same for other variable stars, but if I understand correctly, the principle is exactly the same, just a different dataset will be needed.)
I tried to make a function based on what you wrote, but I'm missing a step, so it doesn't work, could you please take a look at it?
import numpy as np
import juliandate

def get_algol_magnitude(date): # python datetime
    # read data from text file
    data = np.genfromtxt('hlsp_qlp_tess_ffi_s0018-0000000346783960_tess_v01_llc.txt', delimiter=',')

    # calculate Julian Date and BTJD offset
    jd = juliandate.from_gregorian(date.year,date.month,date.day,date.hour,date.minute,date.second)
    btjd_offset = 2454833.0 - jd

    # find index of closest time to datetime_obj
    index = np.absolute(data[0] - btjd_offset).argmin()

    # calculate Algol magnitude
    magnitude = -2.5 * math.log10(data[1][index] / data[2][index])

    return magnitude

Ah okay, I think the problems I can see are:

btjd_offset is using the JD of the start date from the Kepler telescope instead of TESS. Since the light curve above is from TESS, you probably want to use the TESS start date of 2457000.0 in that calculation: btjd_offset = jd - 2457000.0
For magnitude, you only need column index 1 from the light curve, because that is already normalized flux (flux / flux_median). You also need the apparent magnitude corresponding to the flux_median, which is the apparent magnitude of the star in the TESS band.
The calculation of the magnitude would be: magnitude = tess_algol_mag - 2.5 * math.log10(data[1][index]) where tess_algol_mag is 3.3684. You can get TESS magnitudes for stars using the TESS input catalog.
The method here will only work if your intended query date is in the range of the observation dates of TESS for this object. If not, you'll need a eclipsing binary model to predict magnitudes on arbitary dates.

You can get TESS magnitudes for stars using the TESS input catalog: https://archive.stsci.edu/missions-and-data/tess#section-33e8b9e7-9cc2-414a-b830-c88f2b409b13

Someone advised me how to calculate the phase of Algol for a given date. This should give a number between 0.0 and 1.0 where 0.0 means Algol is at a minimum, 0.5 means Algol is half way between minima and 1.0 means Algol is at a minimum again.
import juliandate
import datetime

def get_algol_phase(time):
     time_jd = juliandate.from_gregorian(date.year,date.month,date.day,date.hour,date.minute,date.second)

     epoch_minimum_jd=2460072.826389
     algol_period=2.867328

     days_from_epoch = abs(epoch minimum_jd - time_jd)
     algol_phase = (days_from_epoch / algol_period) % 1.0

     return algol_phase

time = datetime.datetime.now()
algol_phase = get_algol_phase(time)

Is there a way how to use this together with your code so that I can get the magnitude for the given phase? :)

If you have series of times and associated magnitudes, you can get the phases and associated magnitudes at each phase using astrobase.lcmath.phase_magseries() function. You'll need the period and epoch.
from astrobase import lcmath

# times_jd and mags are from an existing light curve
phased_lc = lcmath.phase_magseries(times_jd, mags, period, epoch, wrap=False, sort=True)

# returned phased mags are sorted in order of phase
phases = phased_lc["phase"]
phased_mags = phased_lc["mags"]

Then, you can use numpy's array indexing or np.where() to find the mags at any phase value.


[tool_crash] FileSystemException: Cannot open file, OS Error: The system cannot find the file specified., errno = 2

Command
flutter create --template app --overwrite .

Steps to Reproduce

...
...
...

Logs
FileSystemException: Cannot open file, OS Error: The system cannot find the file specified.
, errno = 2
#0      _File.throwIfError (dart:io/file_impl.dart:629:7)
#1      _File.openSync (dart:io/file_impl.dart:473:5)
#2      _File.readAsBytesSync (dart:io/file_impl.dart:533:18)
#3      _File.readAsStringSync (dart:io/file_impl.dart:578:18)
#4      ForwardingFile.readAsStringSync (package:file/src/forwarding/forwarding_file.dart:99:16)
#5      ErrorHandlingFile.readAsStringSync.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:222:22)
#6      _runSync (package:flutter_tools/src/base/error_handling_io.dart:600:14)
#7      ErrorHandlingFile.readAsStringSync (package:flutter_tools/src/base/error_handling_io.dart:221:12)
#8      CreateBase._computeTemplateManifest (package:flutter_tools/src/commands/create_base.dart:674:37)
#9      CreateBase._templateManifest (package:flutter_tools/src/commands/create_base.dart:661:43)
#10     CreateBase._templateManifest (package:flutter_tools/src/commands/create_base.dart)
#11     CreateBase.renderMerged (package:flutter_tools/src/commands/create_base.dart:487:25)
#12     CreateBase.generateApp (package:flutter_tools/src/commands/create_base.dart:512:29)
#13     CreateCommand.runCommand (package:flutter_tools/src/commands/create.dart:351:37)
<asynchronous suspension>
#14     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1257:27)
<asynchronous suspension>
#15     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#16     CommandRunner.runCommand (package:args/command_runner.dart:209:13)
<asynchronous suspension>
#17     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:283:9)
<asynchronous suspension>
#18     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>

[✓] Flutter (Channel stable, 3.7.7, on Microsoft Windows [Version 10.0.19045.2965], locale en-ID)
    • Flutter version 3.7.7 on channel stable at C:\src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2ad6cd72c0 (3 months ago), 2023-03-08 09:41:59 -0800
    • Engine revision 1837b5be5f
    • Dart version 2.19.4
    • DevTools version 2.20.1

[✓] Windows Version (Installed version of Windows is version 10 or higher)

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
    • Android SDK at C:\Users\Agum\AppData\Local\Android\sdk
    • Platform android-33-ext5, build-tools 33.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-9505619)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Android Studio (version 2022.1)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-9505619)

[✓] VS Code (version 1.78.2)
    • VS Code at C:\Users\Agum\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.66.0

[✓] Connected device (2 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 114.0.5735.90
    • Edge (web)   • edge   • web-javascript • Microsoft Edge 113.0.1774.57

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Flutter Application Metadata
No pubspec in working directory.

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


Update links in README

More recent repo with current msieve version (1.54 from 2022) with updated docs in markdown. Existing link leads to 14 year old repo with outdated version.

Removed .git from yafu link.

I'm closing this since no further commits were added.

Dear Darío, my intention was to provide a link to the updated msieve repo on GitHub, which is a clone (or mirror) of the official repo on SourceForge.
Links

msieve.sourceforge.net — official msieve repo on SourceForge maintained by Jason Papadopoulos himself (jasonp_sf)

github.com/upiter/msieve — unofficial msieve repo clone with nice updated docs in markdown. This repo contains all commits from the official msieve SVN on SourceForge. README file has links to official repo (one, two, three).

I really don't understand why keeping an unofficial, unmaintained and abandoned repo (latest commit was made on 21 February 2011) is better than having a link to an updated, unofficial, maintained GiHub repo.
I'm not comfortable navigating SourceForge repos, as their design lacks some usability. So I suppose it's much more comfortable for GitHub users to read information the modern way.
Request for changes

If you want to contribute, send a PR with your contributions to the original repos.

Please explain what you mean by this request. The official repo is on SourceForge, it's the original.
If by "original repos" you mean the abandoned one, then I don't see any easy technical way to update that repo through PR, it's much easier to do it by the repo owner himself, but he's been abandoning his repo for 13 years. There have been hundreds (400+) of commits since then.

I'm only accepting the change in the yafu url for now.

The .git suffix was fixed with the main msieve repo link update, so I don't think it's really important to fix it, as GitHub redirects the link correctly.
Security issues
If you care about security and the integrity of the original commits, you could compare different repos and see that only markdown files are changed. If you need detailed instructions on how to compare git (GitHub) and svn (SourceForge) repos, I could create such a document.
Solution
May be it's better to provide a link to official msieve repo on SourceForge instead of GitHub mirror?
Best wishes, J.

The reason that I'm not accepting your link update is beacuse i'ts pointing to your own fork (think of supply chain attack).
If you still want to contribute you can send a PR with your contributions to https://github.com/RsaCtfTool/msieve I'll happy to merge.

Dear Darío, I suggested using a link to the official repo on SourceForge as a solution. Feel free to ignore my repo if you think it's risky.

If you still want to contribute you can send a PR with your contributions to RsaCtfTool/msieve I'll be happy to merge.

I already explained in my previous comment about repo you forked:
------ >8 ------
I don't see any easy technical way to update that repo through PR, it's much easier to do it by the repo owner himself, but he's been abandoning his repo for 13 years. There have been hundreds (400+) of commits since then.
------ 8< ------
It's not worth spending time updating this outdated repo, imho.


WIP - Import glide configuration during init

⚠ This is just a placeholder PR, to prove I'm still working on #380. 😊 It's not really ready for review yet, got a bit more work to do.

During dep init if glide.yaml and glide.lock are present, then use the glide configuration when initializing dep's manifest and lock. Importing config from other dependency manager's will be the default, specify -skip-tools to ignore existing configuration.

[x] Read glide.yaml and populate initial manifest constraints.
[x] Hit the dependency repo to determine if a glide project version is a branch or tag.
[x] Drop a dependency from the manifest if it's in glide.yaml but isn't imported.
[x] Read glide.lock and populate initial lock revisions.
[x] Unmarshal unsupported glide fields, detect if present and warn that they are being ignored.

First, yay!! Glad you're moving forward on this - I was actually just about to post something on one of the other issues 😄
I can't remember if I said this anywhere, but repeating just in case - the ideal place to attach this behavior would be as a method on the Analyzer - one that's compatible with the arguments to DeriveManifestAndLock().

the ideal place to attach this behavior would be as a method on the Analyzer - one that's compatible with the arguments to DeriveManifestAndLock().

Now, looking over the PR as-is - it's fine to have the bulk of the logic in internal, but the entry points should still be attached to the analyzer.

I've rebased to take in the gps merge. Tomorrow I'll move my hook out of init and into the Analyzer.

yay!

@sdboyer Can you point me in the right direction for looking up a version string like "master" or "v2" against a dependency's repo to determine if it's a branch/tag/version? I mostly am not sure if this lookup exists in some form or another already.

Hurray for progress! It now

checks the dependency repo to tell if a glide "version" is a branch/tag/version
uses the default branch when no version information is given in glide.yaml for a package.

Both of that is rolled into the same function used by ensure so that everyone (ensure, importers, etc) all benefit.
I think all that's left is:

housekeeping on the importer interface, going to bring it down to a single method
fix merge conflict with master
document how this works better so people know it exists. Right now just the helptext mentions -skip-tools but doesn't say what's supported or how it works.

@sdboyer The analyzer name returned by analyzer.Info() impacts the lock memo. I am using multiple analyzers, depending on if -skip-tools was specified. Do we want them to have different names (and therefore hashes)?
For example: dep/1 and dep.importer/1. If we do that, I'm not sure if I should try to distinguish between the external tool used to import as well, like dep.importer.glide or dep.importer.govendor?

@carolynvs I haven't reviewed your changes yet, so I don't know how much this lines up with what you've already done - so, speaking in generalities 😄
My instinctive preference is to have one actual analyzer struct that, perhaps based on some flag property, decides whether it will look for all existing tool metadata files, or only dep's. The name should similarly vary based on the state of that flag. When passing the analyzer to gps.Prepare(), just make sure it has the flag set for the narrower behavior.
For reference, the purpose of the name and version fields is really just to provide a simple way of categorizing the compatibility of solutions. More formally, their meaning would be:

If a solution differs from inputs by analyzer name, then the relationship is undefined, and no guarantee is made that the solution is valid for those inputs.
If a solution and inputs have the same analyzer name, but vary by version, then there is still no guarantee that the solution is valid for those inputs, but the user can be safely advised that their analyzer is either "newer" or "older" than the version used to create that lock.
If a solution and inputs have the same analyzer name and number, then it is guaranteed that the solution is valid for those inputs (with certain caveats)

My plan is to expose these fields directly in Gopkg.lock in #508, so that saner errors messages can be provided.

Thanks! That helps guide my next steps then. I was tempted to merge the two analyzers (skipping tools vs the current behavior) and that sounds like the way to go.

@sdboyer Okay I just finished consolidating the little analyzer structs I had made into a single analyzer in cmd/dep/root_analyzer.go. Hopefully that makes things less confusing to review. If I need to doc more, just poke me with a sharp stick. 😀
I stopped short of combining that with analyzer.go because I wanted to get feedback and ... because moving the analyzer out of cmd/dep into dep forces me to make more decisions about exported/unexported/internal which is a can of worms.
Working on your other feedback right now.

@sdboyer When glide.yaml has a constraint for a transitive dependency, we want to create an override for that in the manifest, right? I wasn't sure if we wanted to force people to notice a warning in the output, and then make the override manually so that it's such a PITA that no one bothers. 😉

@sdboyer Another question. 😊 Now that we have the nifty feedback in place, the text displayed is misleading because the importer doesn't currently have all the facts up-front.
I am relying on the solver doing what it does best and then making sure the manifest is cleaned up to match before writing to disk. I populate the initial root manifest with everything I find in glide.yaml. If after solving it turns out that the package was transitive or not imported, then I remove it from the manifest.
Now with instant-feedback, I either need to pass more info to the importer to correctly display feedback, or tweak the feedback text to make it more clear that it's not final.
Here's an example:

deptest is a transitive dependency
deptestdos is a direct dependency
lint is not imported

Current (Misleading) Output
Converting from glide.yaml and glide.lock...
  Using ^1.0.0 as constraint for direct dep github.com/sdboyer/deptest
  Locking in v1.0.0 (ff2948a) for direct dep github.com/sdboyer/deptest
  Using ^2.0.0 as constraint for direct dep github.com/sdboyer/deptestdos
  Locking in v2.0.0 (5c60720) for direct dep github.com/sdboyer/deptestdos
  Using master as constraint for direct dep github.com/golang/lint
  Locking in master (cb00e56) for direct dep github.com/golang/lint

Option A: More vague output which is refined later during solve
Converting from glide.yaml and glide.lock...
  Using ^1.0.0 as constraint for imported dep github.com/sdboyer/deptest
  Locking in v1.0.0 (ff2948a) for imported dep github.com/sdboyer/deptest
  Using ^2.0.0 as constraint for imported dep github.com/sdboyer/deptestdos
  Locking in v2.0.0 (5c60720) for imported dep github.com/sdboyer/deptestdos
  Using master as constraint for imported dep github.com/golang/lint
  Locking in master (cb00e56) for imported dep github.com/golang/lint

Option B: Importers use the packageTree(?) to get it right the first time
Converting from glide.yaml and glide.lock...
  Ignoring transitive dep github.com/sdboyer/deptest
  Using ^2.0.0 as constraint for direct dep github.com/sdboyer/deptestdos
  Locking in v2.0.0 (5c60720) for direct dep github.com/sdboyer/deptestdos
  Ignoring unimported dep github.com/golang/lint

I'm leaning towards option b. What do you think?

Now with instant-feedback, I either need to pass more info to the importer to correctly display feedback, or tweak the feedback text to make it more clear that it's not final.

I think there might be an easier option C, which seems to me like the path we should take at first: prior to all of the individual bits of output, print a brief message indicating more or less what you've said here - that the constraints, etc. we're pulling out are speculative, and may not apply exactly as expected.
That seems like the least work we can do right now while still being honest with the user, and leaving open the possibility of pursuing B later (which, just looking at that output, I would agree is the superior option).

I'm only now realizing that the root analyzer you're making won't be easy to directly convert to one we might inject for solving, as providing the incremental feedback sorta entails otherwise. This gives me a 😢, though not a terrible one.
Making it amenable would entail two things - only log incremental feedback if some config option says to do so, and separate out GOPATH into some standalone process (as we never need to do it when solving). I don't really want to block this PR on that, though - seems like a refactor we could do in a follow-up.

Making it amenable would entail two things - only log incremental feedback if some config option says to do so, and separate out GOPATH into some standalone process (as we never need to do it when solving). I don't really want to block this PR on that, though - seems like a refactor we could do in a follow-up.

I originally had gopath stuff in its own analyzer, then thought you wanted a mega analyzer and went whole hog in the other direction. 😊 Let me see if it's not too hard to go back to an older commit. I'd prefer to not move all the things, then make another PR to move them all back!

That seems like the least work we can do right now while still being honest with the user, and leaving open the possibility of pursuing B later (which, just looking at that output, I would agree is the superior option).

Yeah, while I really like option B, I think that's best left for a follow-up PR, where additional info like the package tree is supplied to the importers so that they can be smarter. For now I'll go with your suggested option C. Mostly because I want this to get in, so we can start building on top of it.

I'm only now realizing that the root analyzer you're making won't be easy to directly convert to one we might inject for solving, as providing the incremental feedback sorta entails otherwise.

root_analyzer has two functions, one for the root level which does gopath analysis and importers, and the standard analyzer function DeriveManifestAndLock which first checks for dep config files, then applies analyzers. As the PR stands right now, I am already injecting it as the solve analyzer. Did I paint myself into a corner and not realize it?

I originally had gopath stuff in its own analyzer, then thought you wanted a mega analyzer and went whole hog in the other direction.

Ugh, I'm sorry, I didn't communicate this well. (I'm also realizing that I didn't even understand it well until reading this PR.) To me, analyzers serve this really narrow role, as defined by that DeriveManifestAndLock() signature. GOPATH searches don't really make sense under that rubric, because there's no metadata to read. At most, they could return constraint information about the project being inspected - but the whole idea of that method is to return constraint information for dependencies of the project being inspected.

Yeah, while I really like option B, I think that's best left for a follow-up PR, where additional info like the package tree is supplied to the importers so that they can be smarter. For now I'll go with your suggested option C. Mostly because I want this to get in, so we can start building on top of it.

👍

As the PR stands right now, I am already injecting it as the solve analyzer. Did I paint myself into a corner and not realize it?

Maybe? This is complex stuff, easy to have it happen 😄 I think what's hard about this is that the dep init case is the least like the other cases, which sorta obscures the original purpose.
The way I think about the whole system is this:

DeriveManifestAndLock() is given an fs path and a ProjectRoot, and needs to return Manifest and Lock data.
The above is something we always need to do on the root project when running commands other than init, and we only want to do it using the dep analyzer (that is, specifically for Gopkg.{toml,lock})
We also need an analyzer for its original intended purpose - to give to the solver, so that it can read Manifest and Lock data out of dependencies while solving.

For now, we just want it to read dep's data - Gopkg.{toml,lock}.
We MAY want it to also read data from other tools, too. Doing so would allow dep to "seamlessly" interoperate with projects still using old tools, or just older versions of projects that were using old tools at the time.

The baseline of the init case is essentially 3.ii - make a Manifest and Lock out of any data we know how to convert. But GOPATH isn't a part of that system, at all. Even with init, it's kind of an afterthought - the thing we use to fill in any gaps.

I've rebased and addressed all feedback except pulling the gopath stuff out of the analyzer which I'm working on right now.

@carolynvs Thank you for this PR!! How would you feel about rebasing this branch on master so that it doesn't have merge conflicts?

It's the rebase race, I'm already out of date in less than 24 hours. 😀 Spoke with Sam, going to rebase and squash this down into just a few commits.

@sdboyer This is ready for review.

This only covers init. The ensure and status commands are still using dep.Analyzer when solving which doesn't look at external tools. We'll need another pass to address that after this PR.
Since I wasn't sure what to do about imported constraints for transitive deps, I decided to ignore them for now.
I'm not sure how to deal with code climate. Some stuff, like doc on exported functions seems to be ignored for existing code but enforced for new code. Should I add an ignore in CC, doc the new function, doc all the exported functions?
I'm not sure why appveyor is failing. I assume I borked up test cleanup(?) but nothing is jumping out at me.

Overview of changes

cmd/dep/root_analyzer handles calling dep.Analyzer and the importers correctly based on -skip-tools. The analyzer name changes depending on this flag (dep vs dep+import).
cmd/dep/gopath_scanner is just the gopath scanning logic extracted out of the init command. It overlays whatever it finds on the results from the rootAnalyzer, filling in any gaps, but not changing values found by the importers.
cmd/dep/glide_importer implements the importer interface for glide.
Updated test harness tests to use -skip-import unless they are actually testing import.

Reviewing now 😄
As a starter, looking at the appveyor failures, it looks like a couple tests might've forgotten a call to SourceManager.Release().

Doh! Thanks that was it.

I'm not sure how to deal with code climate. Some stuff, like doc on exported functions seems to be ignored for existing code but enforced for new code. Should I add an ignore in CC, doc the new function, doc all the exported functions?

Yeah, I just flipped the switch on the CC analyzer for FIXMEs, TODOs, etc. It only applies to changed lines, not existing ones.
We need to buckle down and be diligent about following these rules, at least with the new stuff we introduce. So yes, let's make sure we're correctly documenting new exported identifiers.

hmm - looking at dep init -v output run against Masterminds/glide:
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/sdboyer/ws/go/src/github.com/Masterminds/glide/glide.yaml
  Loading /Users/sdboyer/ws/go/src/github.com/Masterminds/glide/glide.lock
Converting from glide.yaml and glide.lock...
  Using 0bdedde as initial hint for imported dep github.com/codegangsta/cli
  Using abff190 as initial hint for imported dep github.com/Masterminds/semver
  Using 3084677 as initial hint for imported dep github.com/Masterminds/vcs
  Using b8bc1bf as initial hint for imported dep github.com/mitchellh/go-homedir
  Using a3f3340 as initial hint for imported dep gopkg.in/yaml.v2
Searching GOPATH for projects...
Root project is "github.com/Masterminds/glide"
 17 transitively valid internal packages
 5 external packages imported from 5 projects
(0)   ✓ select (root)
(1)	? attempt github.com/Masterminds/semver with 1 pkgs; at least 1 versions to try
(1)	    try<EMAIL_ADDRESS>(1)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(2)	? attempt github.com/Masterminds/vcs with 1 pkgs; at least 1 versions to try
(2)	    try<EMAIL_ADDRESS>Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/sdboyer/ws/go/pkg/dep/sources/https---github.com-Masterminds-vcs/glide.yaml
Converting from glide.yaml...
(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(3)	? attempt github.com/mitchellh/go-homedir with 1 pkgs; at least 1 versions to try
(3)	    try github.com/mitchellh/go-homedir@master
(3)	✓ select github.com/mitchellh/go-homedir@master w/1 pkgs
(4)	? attempt gopkg.in/yaml.v2 with 1 pkgs; 1 versions to try
(4)	    try gopkg.in/yaml.v2@v2
(4)	✓ select gopkg.in/yaml.v2@v2 w/1 pkgs
(5)	? attempt github.com/codegangsta/cli with 1 pkgs; at least 1 versions to try
(5)	    try<EMAIL_ADDRESS>(5)	✓ select<EMAIL_ADDRESS>w/1 pkgs
  ✓ found solution with 5 packages from 5 projects

Solver wall times by segment:
           b-gmal: 1.686396366s
      b-list-pkgs: 1.181170341s
      select-root:   1.577029ms
      select-atom:    355.459µs
          satisfy:    266.412µs
         new-atom:    129.091µs
  b-list-versions:    102.977µs
            other:      25.49µs
       b-pair-rev:     15.052µs
  b-source-exists:      8.269µs

  TOTAL: 2.870046486s

  Using master as constraint for direct dep github.com/mitchellh/go-homedir
  Locking in master (b8bc1bf) for direct dep github.com/mitchellh/go-homedir
  Using v2 as constraint for direct dep gopkg.in/yaml.v2
  Locking in v2 (cd8b52f) for direct dep gopkg.in/yaml.v2
  Using ^1.19.1 as constraint for direct dep github.com/codegangsta/cli
  Locking in v1.19.1 (0bdedde) for direct dep github.com/codegangsta/cli

we still have this thing where we produce feedback after the solve. either i'm forgetting something about the spec i wrote, or there's something fishy there. why are we not even applying constraints at all until after solving?

@sdboyer There are a couple problems with the output. 😊

It was a bug that it wasn't properly printing the imported constraints. After fixing the truncated output from the importer looks like this:
Converting from glide.yaml and glide.lock...
Using ^1.16.0 as initial constraint for imported dep github.com/codegangsta/cli
Trying ^1.16.0 (0bdedde) as initial lock for imported dep github.com/codegangsta/cli

The last line should print the version that goes with the revision. @darkowlzz wrote that logic and was asking about where it should live, or if it exists already in gps. I'm going to steal his code and put it in a function next to deduceConstraint for now.

The feedback shown after the solve is from a bad merge. I think we used to log feedback after solving, and must have dropped it since I started on this feature. I missed that when I copied that code from init to the gopath_scanner. Fixing!

I've addressed all your feedback, rebased and squashed. Here's the latest output of running dep init -v on glide.
$ dep init -v
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/carolynvs/go/src/github.com/Masterminds/glide/glide.yaml
  Loading /Users/carolynvs/go/src/github.com/Masterminds/glide/glide.lock
Converting from glide.yaml and glide.lock...
  Using ^1.19.1 as initial constraint for imported dep github.com/codegangsta/cli
  Trying v1.19.1 (0bdedde) as initial lock for imported dep github.com/codegangsta/cli
  Using ^1.3.0 as initial constraint for imported dep github.com/Masterminds/semver
  Trying v1.3.0 (abff190) as initial lock for imported dep github.com/Masterminds/semver
  Using ^1.11.1 as initial constraint for imported dep github.com/Masterminds/vcs
  Trying v1.11.1 (3084677) as initial lock for imported dep github.com/Masterminds/vcs
  Using master as initial constraint for imported dep github.com/mitchellh/go-homedir
  Trying master (b8bc1bf) as initial lock for imported dep github.com/mitchellh/go-homedir
  Using a3f3340 as initial hint for imported dep gopkg.in/yaml.v2
Searching GOPATH for projects...
Root project is "github.com/Masterminds/glide"
 53 transitively valid internal packages
 5 external packages imported from 5 projects
(0)   ✓ select (root)
(1)	? attempt github.com/Masterminds/semver with 1 pkgs; at least 1 versions to try
(1)	    try<EMAIL_ADDRESS>(1)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(2)	? attempt github.com/Masterminds/vcs with 1 pkgs; at least 1 versions to try
(2)	    try<EMAIL_ADDRESS>Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/carolynvs/go/pkg/dep/sources/https---github.com-Masterminds-vcs/glide.yaml
Converting from glide.yaml...
(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(3)	? attempt github.com/mitchellh/go-homedir with 1 pkgs; at least 1 versions to try
(3)	    try github.com/mitchellh/go-homedir@master
(3)	✓ select github.com/mitchellh/go-homedir@master w/1 pkgs
(4)	? attempt gopkg.in/yaml.v2 with 1 pkgs; 1 versions to try
(4)	    try gopkg.in/yaml.v2@v2
(4)	✓ select gopkg.in/yaml.v2@v2 w/1 pkgs
(5)	? attempt github.com/codegangsta/cli with 1 pkgs; at least 1 versions to try
(5)	    try<EMAIL_ADDRESS>(5)	✓ select<EMAIL_ADDRESS>w/1 pkgs
  ✓ found solution with 5 packages from 5 projects

Solver wall times by segment:
      b-list-pkgs: 1.730042899s
           b-gmal: 1.573923904s
      select-root:   3.099974ms
      select-atom:    349.794µs
          satisfy:    340.791µs
         new-atom:    189.522µs
            other:     20.486µs
  b-source-exists:     16.998µs
  b-list-versions:      9.218µs
       b-pair-rev:      1.732µs

  TOTAL: 3.307995318s

(2)	    try<EMAIL_ADDRESS>Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/carolynvs/go/pkg/dep/sources/https---github.com-Masterminds-vcs/glide.yaml
Converting from glide.yaml...
(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs

The question of whether we read e.g. glide files in deps is a separate one from whether we read them from the current project during dep init. Can we make it controllable via a single boolean flag - e.g. if true, it'll try all the types of files we support; if false, it'll only look for Gopkg.toml and Gopkg.lock.
Also, either way, I don't think we want to print there, as it interrupts the trace output.

I've disabled importing during solve. This means that if a dependency has glide config, it is not used at all. Previously -skip-tools controlled import both for the root project and dependencies, now it only controls at the root, and we never import for dependencies.
I've also tweaked the importer so that nothing is logged during solve, so that if we eventually use the importer during solve, it won't interrupt the output. Here's the new output:
$ dep init -v
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /Users/carolynvs/go/src/github.com/Masterminds/glide/glide.yaml
  Loading /Users/carolynvs/go/src/github.com/Masterminds/glide/glide.lock
Converting from glide.yaml and glide.lock...
  Using ^1.19.1 as initial constraint for imported dep github.com/codegangsta/cli
  Trying v1.19.1 (0bdedde) as initial lock for imported dep github.com/codegangsta/cli
  Using ^1.3.0 as initial constraint for imported dep github.com/Masterminds/semver
  Trying v1.3.0 (abff190) as initial lock for imported dep github.com/Masterminds/semver
  Using ^1.11.1 as initial constraint for imported dep github.com/Masterminds/vcs
  Trying v1.11.1 (3084677) as initial lock for imported dep github.com/Masterminds/vcs
  Using master as initial constraint for imported dep github.com/mitchellh/go-homedir
  Trying master (b8bc1bf) as initial lock for imported dep github.com/mitchellh/go-homedir
  Using a3f3340 as initial hint for imported dep gopkg.in/yaml.v2
Searching GOPATH for projects...
Root project is "github.com/Masterminds/glide"
 65 transitively valid internal packages
 5 external packages imported from 5 projects
(0)   ✓ select (root)
(1)	? attempt github.com/Masterminds/semver with 1 pkgs; at least 1 versions to try
(1)	    try<EMAIL_ADDRESS>(1)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(2)	? attempt github.com/Masterminds/vcs with 1 pkgs; at least 1 versions to try
(2)	    try<EMAIL_ADDRESS>(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(3)	? attempt github.com/mitchellh/go-homedir with 1 pkgs; at least 1 versions to try
(3)	    try github.com/mitchellh/go-homedir@master
(3)	✓ select github.com/mitchellh/go-homedir@master w/1 pkgs
(4)	? attempt gopkg.in/yaml.v2 with 1 pkgs; 1 versions to try
(4)	    try gopkg.in/yaml.v2@v2
(4)	✓ select gopkg.in/yaml.v2@v2 w/1 pkgs
(5)	? attempt github.com/codegangsta/cli with 1 pkgs; at least 1 versions to try
(5)	    try<EMAIL_ADDRESS>(5)	✓ select<EMAIL_ADDRESS>w/1 pkgs
  ✓ found solution with 5 packages from 5 projects

Solver wall times by segment:
           b-gmal: 1.832750336s
      b-list-pkgs: 1.383528239s
      select-root:   3.428211ms
          satisfy:    330.136µs
      select-atom:    318.279µs
         new-atom:    140.255µs
            other:     44.367µs
  b-source-exists:     11.541µs
  b-list-versions:      6.211µs
       b-pair-rev:        794ns

  TOTAL: 3.220558369s

OK so there is just NO apparent reason for that test windows test failure. Github is up...I don't know.
Either way, this is close enough, and has gone on way too long. It's time to merge. We can work out the rest incrementally 😄


feat(go): bootstrap go ingestion client

🧭 What and Why
Bootstrap the GO api client generation, with the ingestion API as a first test.
This is very basic for now, but it works good enough for the ingestion API, it's not ready for the other Algolia API yet.
There is no CI support for now, maybe in the next PR.
The go client is compatible with golang 1.13, like the current algoliasearch-client-go package.
Changes included:

Add GO to the docker image
Create the go-ingestion client
Create custom GO generator

🧪 Test
The CTS is being made in #1115.
You can try the playground by running yarn docker playground go ingestion.

No longer relevant


UI for the "Create Subscription" button on the "Jira Subscriptions" page is broken on v7.8.2.

UI for the "Create Subscription" button on the "Jira Subscriptions" page is broken on v7.8.2.

Steps to reproduce:

Run command /jira subscribe edit .
See the "Create Subscription" button.

Expected:
The "Create Subscription" button should be properly aligned with the texts vertically or it should be placed below the texts in centre.

@avas27JTG Thanks for calling this out. Curious if you are interested / planning on solving this issue
@matthewbirtch Thoughts on a low cost UI change we can make here?

@matthewbirtch Thoughts on a low cost UI change we can make here?

@mickmister does this appear in a full-screen modal? I see no reason why the button should be pushed up against the title so closely, but has it always been that way? For starters, I would suggest the following:

Add margin-left: 24px to the left of the button
Set the h2 title to have flex:1; text-align: left

Without testing this in a real environment, that's the best quick stab at it I can make, but can't promise it won't have a negative affect on anything else.

does this appear in a full-screen modal?

@matthewbirtch That's correct

has it always been that way?

I'm not sure, this could be a regression. IIRC the styling is slightly different between when you have 0 subscriptions versus 1 or more subscriptions, so this may be affecting one of those cases.

@avas27JTG Thanks for calling this out. Curious if you are interested / planning on solving this issue
@matthewbirtch Thoughts on a low cost UI change we can make here?

Yes, we are planning to work on it.


Own component for proposed messages in propose message

Multiple messages can be proposed and shown in one propose message.
For that we need a new componend thats included in the proposeMessage

no longer relevant


Fix typo

Hi!
I was just passing by and noticed what I think is a small typo, so why not push a small PR?? XD

Nice shot!, I should change the domain extension to .info as well.
It would be something like info.candotti.giphyPicker


Why cascade rcnn is not better than faster rcnn  much for object detection?

RT

There could be many reasons, and I did not look into this particular issue. All models are trained with the default settings from MMDetection, so better hyperparameters could give better performance.


Update CAS Protocol to include parameter info on validation format

CAS Protocol should be updated to include a new parameter for service ticket validation, which would indicate the output response type of the validation result. This would be a format parameter to the serviceValidate endpoint, that is optional, with values such as XML and JSON.

Glad we find some agreement. I think it must be discussed (at least shared) on the mailing list.

Sure. I'll publish a post, but given recent rate of activity and everyone's schedule, I am inclined to move on lazy consensus if there are no responses.

Sure.


macos gives fatal error: 'X11/Xlib.h' file not found

I tried to install dlib by python setup.py install on macos 10.14.6,  but it gives the following error. I wonder how to solve this or where can I set the path of X11/Xlib.h. I did install X11, and it is in /opt/X11. Thanks.
running install
running bdist_egg
running egg_info
writing tools/python/dlib.egg-info/PKG-INFO
writing dependency_links to tools/python/dlib.egg-info/dependency_links.txt
writing top-level names to tools/python/dlib.egg-info/top_level.txt
package init file 'tools/python/dlib/init.py' not found (or not a regular file)
reading manifest file 'tools/python/dlib.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'tools/python/build*'
writing manifest file 'tools/python/dlib.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.9-x86_64/egg
running install_lib
running build_py
running build_ext
Building extension for Python 3.8.8 (default, Apr 13 2021, 12:59:45)
Invoking CMake setup: 'cmake /Users/kroegera/Documents/myproj/dlib/tools/python -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/Users/kroegera/Documents/myproj/dlib/build/lib.macosx-10.9-x86_64-3.8 -DPYTHON_EXECUTABLE=/opt/anaconda3/bin/python -DCMAKE_BUILD_TYPE=Release'
-- pybind11 v2.2.4
-- Using CMake version: 3.17.2
-- Compiling dlib version: 19.22.99
-- SSE4 instructions can be executed by the host processor.
-- AVX instructions can be executed by the host processor.
^Cinterrupted
(base) qiangsiweideMacBook-Pro:dlib kroegera$ python setup.py install
running install
running bdist_egg
running egg_info
writing tools/python/dlib.egg-info/PKG-INFO
writing dependency_links to tools/python/dlib.egg-info/dependency_links.txt
writing top-level names to tools/python/dlib.egg-info/top_level.txt
package init file 'tools/python/dlib/init.py' not found (or not a regular file)
reading manifest file 'tools/python/dlib.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'tools/python/build*'
writing manifest file 'tools/python/dlib.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.9-x86_64/egg
running install_lib
running build_py
running build_ext
Building extension for Python 3.8.8 (default, Apr 13 2021, 12:59:45)
Invoking CMake setup: 'cmake /Users/kroegera/Documents/myproj/dlib/tools/python -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/Users/kroegera/Documents/myproj/dlib/build/lib.macosx-10.9-x86_64-3.8 -DPYTHON_EXECUTABLE=/opt/anaconda3/bin/python -DCMAKE_BUILD_TYPE=Release'
-- The C compiler identification is AppleClang <IP_ADDRESS>00020
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00020
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /opt/anaconda3/bin/python (found version "3.8.8")
-- Found PythonLibs: /opt/anaconda3/lib/libpython3.8.dylib
-- Performing Test HAS_CPP14_FLAG
-- Performing Test HAS_CPP14_FLAG - Success
-- pybind11 v2.2.4
-- Using CMake version: 3.17.2
-- Compiling dlib version: 19.22.99
-- SSE4 instructions can be executed by the host processor.
-- AVX instructions can be executed by the host processor.
-- Enabling AVX instructions
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found system copy of libpng: /usr/local/lib/libpng.dylib;/usr/lib/libz.dylib
-- System copy of libpng is broken.  Will build our own libpng and use that instead.
-- Searching for BLAS and LAPACK
-- Searching for BLAS and LAPACK
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.29.2")
-- Checking for module 'cblas'
--   No package 'cblas' found
-- Checking for module 'lapack'
--   No package 'lapack' found
-- Looking for cblas_ddot
-- Looking for cblas_ddot - not found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of void*
-- Check size of void* - done
-- Found LAPACK library
-- Found CBLAS library
-- Looking for cblas_ddot
-- Looking for cblas_ddot - found
-- Looking for sgesv
-- Looking for sgesv - found
-- Looking for sgesv_
-- Looking for sgesv_ - found
CUDA_TOOLKIT_ROOT_DIR not found or specified
-- Could NOT find CUDA (missing: CUDA_TOOLKIT_ROOT_DIR CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY) (Required is at least version "7.5")
-- Found CUDA, but CMake was unable to find the cuBLAS libraries that should be part of every basic CUDA install. Your CUDA install is somehow broken or incomplete. Since cuBLAS is required for dlib to use CUDA we won't use CUDA.
-- DID NOT FIND CUDA
-- Disabling CUDA support for dlib.  DLIB WILL NOT USE CUDA
-- Building a C++11 test project to see if your compiler supports C++11
-- C++11 activated.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/kroegera/Documents/myproj/dlib/build/temp.macosx-10.9-x86_64-3.8
Invoking CMake build: 'cmake --build . --config Release -- -j2'
Scanning dependencies of target dlib
[  1%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bigint/bigint_kernel_1.cpp.o
[  1%] Building CXX object dlib_build/CMakeFiles/dlib.dir/base64/base64_kernel_1.cpp.o
[  2%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bigint/bigint_kernel_2.cpp.o
[  3%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bit_stream/bit_stream_kernel_1.cpp.o
[  3%] Building CXX object dlib_build/CMakeFiles/dlib.dir/entropy_decoder/entropy_decoder_kernel_1.cpp.o
[  4%] Building CXX object dlib_build/CMakeFiles/dlib.dir/entropy_decoder/entropy_decoder_kernel_2.cpp.o
[  4%] Building CXX object dlib_build/CMakeFiles/dlib.dir/entropy_encoder/entropy_encoder_kernel_1.cpp.o
[  5%] Building CXX object dlib_build/CMakeFiles/dlib.dir/entropy_encoder/entropy_encoder_kernel_2.cpp.o
[  6%] Building CXX object dlib_build/CMakeFiles/dlib.dir/md5/md5_kernel_1.cpp.o
[  6%] Building CXX object dlib_build/CMakeFiles/dlib.dir/tokenizer/tokenizer_kernel_1.cpp.o
[  7%] Building CXX object dlib_build/CMakeFiles/dlib.dir/unicode/unicode.cpp.o
[  7%] Building CXX object dlib_build/CMakeFiles/dlib.dir/test_for_odr_violations.cpp.o
[  8%] Building CXX object dlib_build/CMakeFiles/dlib.dir/sockets/sockets_kernel_1.cpp.o
[  9%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bsp/bsp.cpp.o
[  9%] Building CXX object dlib_build/CMakeFiles/dlib.dir/dir_nav/dir_nav_kernel_1.cpp.o
[ 10%] Building CXX object dlib_build/CMakeFiles/dlib.dir/dir_nav/dir_nav_kernel_2.cpp.o
[ 10%] Building CXX object dlib_build/CMakeFiles/dlib.dir/dir_nav/dir_nav_extensions.cpp.o
[ 11%] Building CXX object dlib_build/CMakeFiles/dlib.dir/gui_widgets/fonts.cpp.o
[ 12%] Building CXX object dlib_build/CMakeFiles/dlib.dir/linker/linker_kernel_1.cpp.o
In file included from /Users/kroegera/Documents/myproj/dlib/dlib/gui_widgets/fonts.cpp:16:
/Users/kroegera/Documents/myproj/dlib/dlib/gui_widgets/nativefont.h:29:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
^~~~~~~~~~~~
1 error generated.
make[2]: *** [dlib_build/CMakeFiles/dlib.dir/gui_widgets/fonts.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [dlib_build/CMakeFiles/dlib.dir/all] Error 2
make: *** [all] Error 2
Traceback (most recent call last):
File "setup.py", line 222, in
setup(
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/init.py", line 153, in setup
return distutils.core.setup(**attrs)
File "/opt/anaconda3/lib/python3.8/distutils/core.py", line 148, in setup
dist.run_commands()
File "/opt/anaconda3/lib/python3.8/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/opt/anaconda3/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/command/install.py", line 67, in run
self.do_egg_install()
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/command/install.py", line 109, in do_egg_install
self.run_command('bdist_egg')
File "/opt/anaconda3/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/opt/anaconda3/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/command/bdist_egg.py", line 164, in run
cmd = self.call_command('install_lib', warn_dir=0)
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/command/bdist_egg.py", line 150, in call_command
self.run_command(cmdname)
File "/opt/anaconda3/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/opt/anaconda3/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/opt/anaconda3/lib/python3.8/site-packages/setuptools/command/install_lib.py", line 11, in run
self.build()
File "/opt/anaconda3/lib/python3.8/distutils/command/install_lib.py", line 107, in build
self.run_command('build_ext')
File "/opt/anaconda3/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/opt/anaconda3/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "setup.py", line 134, in run
self.build_extension(ext)
File "setup.py", line 174, in build_extension
subprocess.check_call(cmake_build, cwd=build_folder)
File "/opt/anaconda3/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--', '-j2']' returned non-zero exit status 2.

I've never used Mac OS, but I am guessing you need to install X11:
https://support.apple.com/kb/DL641?viewlocale=en_US&locale=en_US

I wager this is anaconda sticking a broken copy of X11 somewhere and cmake is finding it.  Apply this patch to your code and try it again and see what it prints:
--- a/dlib/CMakeLists.txt
+++ b/dlib/CMakeLists.txt
@@ -339,7 +339,7 @@ if (NOT TARGET dlib)
       elseif(APPLE) ############################################################################
          set(CMAKE_MACOSX_RPATH 1)
          if (NOT DLIB_NO_GUI_SUPPORT)
-            find_package(X11 QUIET)
+            find_package(X11)
             if (X11_FOUND)
                # If both X11 and anaconda are installed, it's possible for the
                # anaconda path to appear before /opt/X11, so we remove anaconda.
@@ -350,6 +350,7 @@ if (NOT TARGET dlib)
                endforeach(ITR)
                include_directories(${X11_INCLUDE_DIR})
                set (dlib_needed_libraries ${dlib_needed_libraries} ${X11_LIBRARIES})
+               message("  FOUND THIS X11 PATH: ${X11_INCLUDE_DIR} !!!!!!!!!!!!!!!!!!! 1")
             else()
                find_library(xlib X11)
                # Make sure X11 is in the include path.  Note that we look for
@@ -365,6 +366,8 @@ if (NOT TARGET dlib)
                   get_filename_component(x11_path ${xlib_path} PATH CACHE)
                   include_directories(${x11_path})
                   set(dlib_needed_libraries ${dlib_needed_libraries} ${xlib} )
+                  message("  FOUND THIS X11 PATH: ${x11_path} !!!!!!!!!!!!!!!!!!! 2")
+                  message("  FOUND THIS X11 PATH: ${xlib} !!!!!!!!!!!!!!!!!!! 3")
                   set(X11_FOUND 1)
                endif()
             endif()


Customer suggestion to improve article

[Enter feedback here]
Azure Active Directory Seamless Single Sign-On: Frequently asked questions
What sign-in methods do Seamless SSO work with
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-faq#what-sign-in-methods-do-seamless-sso-work-with
Seamless SSO can be combined with either the Password Hash Synchronization or Pass-through Authentication sign-in methods. However this feature cannot be used with Active Directory Federation Services (ADFS).
But imagine I have a tenancy for the Contoso University.
It has a campus in LA, and another in NY.
Contoso creates two domains in its tenancy(asuming these domains are top domains)
@la.contoso.edu
@ny.contoso.edu
They have on premises AD DS, and use Azure AD Connect.
Initially, they were both federated domains in the same tenancy.
LA wants to switch to managed domain. NY can't switch just yet.
Is it not the case that Contoso would enable seamless SSO in its tenancy, and @la.contoso.edu would switch to managed domain, while @ny.contoso.edu remains a federated domain?
Hence, the tenancy would use a federated domain/AD FS with seamless SSO?
customer suggestion:
If so, should that documentation be changed to...
Azure Active Directory Seamless Single Sign-On: Frequently asked questions
What sign-in methods do Seamless SSO work with
Seamless SSO can be combined with either the Password Hash Synchronization or Pass-through Authentication sign-in methods. Seamless SSO should not be used with Active Directory Federation Services, except in some circumstances;
•	your tenancy has multiple domains of which at least one is managed and you wish to use single sign on for non hybrid Azure AD joined devices
•	you have a federated domain, but are using Azure AD Connect: Cloud authentication via Staged Rollout - Microsoft Entra | Microsoft Learn

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

ID: 9eb97eff-d72e-ffa6-1365-5419e93ed82a
Version Independent ID: 5c8b677b-f4cd-0bb5-c7d6-9b1ef903dad4
Content: Azure AD Connect - Microsoft Entra
Content Source: articles/active-directory/hybrid/how-to-connect-sso-faq.yml
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@pmesen
Thanks for your feedback! We will investigate and update as appropriate.

@pmesen
Thanks for your feedback! We have assigned the issue to author who will provide further updates.

Thank you for submitting this issue.  Unfortunately, due to high volumes I was unable to respond to this in a timely manner.  At this point, I am going to close this due to it's age and the possibility that it may have been addressed.  If this is still a problem, please consider submitting a new issue.  Thank you.
#please-close


registered port is 0 when use server advertise option

I want to register a rpc server with specified ip and random port,
so I passed a server advertise option like this:
srv := micro.NewService(
	micro.Name("bdt.srv.env"),
	micro.RegisterTTL(time.Second*30),
	micro.RegisterInterval(time.Second*20),
	micro.Registry(config.GlobalConf.Registry),
	micro.Transport(tcp.NewTransport()))
if err := srv.Server().Init(server.Advertise("<IP_ADDRESS>")); err != nil {
	panic(fmt.Sprintf("service server int error : %s", err.Error()))
}

Then I got the registered Port 0, instead of  56012:
2019-07-16 10:31:40.752451 I | Transport [tcp] Listening on [::]:56012
2019-07-16 10:31:40.753427 I | Broker [http] Connected to [::]:56013
2019-07-16 10:31:40.753427 I | Registry [etcdv3] Registering node: bdt.srv.env-c45bd5f6-5c73-4bb2-b62a-83c8721397e1
&registry.Node{Id:"bdt.srv.env-c45bd5f6-5c73-4bb2-b62a-83c8721397e1", Address:"<IP_ADDRESS>", Port:0, Metadata:map[string]string{"broker":"http", "protocol":"mucp", "registry":"etcdv3", "server":"rpc", "transport":"tcp"}}

I noticed this:
In /micro/go-micro/server/rpc_server.go, port is default 0 when advertise does not contain port.
Shall we set the default port by s.opts.Address ?

We have no way of explicitly knowing if the transport used supports ports or not. When you specify advertise the assumption is that you know exactly what you want to advertise e.g a secure host:port behind a load balancer or some specific thing being exposed inside a container. In this case we expect dynamic ports not really to be used. If you are using nats or any other message bus the port is essentially irrelevant.
If you'd like to PR the internal changes to support setting port please feel free otherwise we expect you should be setting it. You should otherwise bind to <IP_ADDRESS>:0 which will also work.


Update example to current stable Rust.

Fixes #4.

Sorry, I seem to have totally missed this PR! Only noticed it again after merging #14... Thanks though :)


Add async/await example

Great idea, will do.

I wanted to make sure the async/await example actually worked, so I created a whole test project and added it to this project so everyone can clone it and play around with it. But I also added an async/await example straight to the readme.


Azure cli functionality

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az functionapp deployment
Errors:
cannot import name 'DefaultErrorResponseException' from 'azure.mgmt.web.models' (/usr/lib/python3/dist-packages/azure/mgmt/web/models.py)
Traceback (most recent call last):
python3/dist-packages/knack/cli.py, ln 233, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 584, in execute
    parsed_args = self.parser.parse_args(args)
python3/dist-packages/knack/parser.py, ln 262, in parse_args
    return super(CLICommandParser, self).parse_args(args)
...
cli/command_modules/appservice/custom.py, ln 39, in <module>
    from azure.mgmt.web.models import KeyInfo, DefaultErrorResponseException
ImportError: cannot import name 'DefaultErrorResponseException' from 'azure.mgmt.web.models' (/usr/lib/python3/dist-packages/azure/mgmt/web/models.py)

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az functionapp deployment

Expected Behavior
Environment Summary
Linux-5.10.0-3-amd64-x86_64-with-glibc2.31
Python 3.9.1+
Installer: PIP

azure-cli 2.18.0 *

Extensions:
interactive Unknown
azure-devops 0.19.0

Additional Context

functionapp

@gzuber could please help investigate?

@atanas-mavrov Please reopen if you need any assistance here.


Can't get materialize navbar with pushpin and scrollspy to work

I want a navbar in scrollspy style, and make it fixed using pushpin, how do I do this? I don't get the desired result at all
https://i.stack.imgur.com/WyrYV.png
Here is my code: http://codepen.io/said50/pen/JbGXgW
It does work in terms of clicking and scrolling to it
But it doesn't stay "pushpinned" (+ I don't know how to style it like on the materialdesign site)

Judging by your codepen, it looks like you are initializing pushpin on the wrong div

Check this one - http://codepen.io/kmmbvnr/pen/XNXVaY
You just need carefully follow the documentation,
The only inconsstence issue that navbar expects the class="active" on a <li> elements, but scrollspy set active class in <a> elements.
So you have to specify manually
a.active {
  background-color: #ea454b;
}

I've added a more in depth pushpin demo in 6c1aaaf

Ok got it fixed (accidentally deleted a div). But how can I style it so that it will get fixed at the middle right on the page (just like the materialize site). Got it to work with css but it didn't work well with the containers

Maybe close this issue?


Indicator/highlight not changing with changing tab

I have enabled the key binding for ctrl+tab to prompt Compass. However, when I do so, if I hit ctrl+tab repeatedly, I still cycle through my tabs without the compass indicator changing.

Can you try sublime.log_commands(True) in the console? I have a hunch that a keybinding on ctrl+tab is not triggering the move command. Maybe it is conflicting with your other keybinds.

>>> sublime.log_commands(True)
command: compass_show {"forward": true}
command: gs_draw_status_bar
command: next_view_in_stack
command: next_view_in_stack
command: next_view_in_stack
command: prev_view_in_stack
command: prev_view_in_stack

[
	{
        "keys": ["ctrl+tab"],
        "command": "compass_show",
        "args": {
            "forward": true
        },
        "context": [
            { "key": "overlay_visible", "operator": "equal", "operand": false },
            { "key": "compass" },
        ]
    },
	{
	        "keys": ["ctrl+shift+tab"],
	        "command": "compass_show",
	        "args": {
	            "forward": false
	        },
	        "context": [
	            { "key": "overlay_visible", "operator": "equal", "operand": false },
	            { "key": "compass" },
	        ]
	    },

]

Okay, I think that's working, but now I'm having a different issue, which I'll open a new issue for.


Kerberos

Hi, is kerberos a supported auth mechanism in the library ?
Thanks

@fatlazycat I believe it's handled the same as https://github.com/dakrone/clj-http/issues/329


what should be the dancetrack results folder structure while submitting to codalab for evaluation ?

I remember it should be something like:
trackers:
  - xxx.txt
  - ...


withStyles() results in exception due to _processStyle not returning a promise

When using withStyles(), an exception is raised:
ficusjs.js:259 Uncaught TypeError: Cannot read property 'then' of undefined
    at HTMLElement._injectStyles (ficusjs.js:259)
    at HTMLElement.created (ficusjs.js:249)
    at HTMLElement._init (ficusjs.js:60)
    at HTMLElement._checkInit (ficusjs.js:36)
    at HTMLElement.connectedCallback (ficusjs.js:24)
    at createComponent (ficusjs.js:16)
    at index.html?_ijt=docne8ki0eg2au6o94jl5r6ta5:22

The issue appears to be that _injectStyles expects _processStyle to return a promise:
          this._processStyle(styleItems)
            .then(cssToImport => this._createAndInjectStylesheet(cssToImport, { 'data-tag': this.componentTagName }))

If you accept pull requests, this seems to fix it: https://github.com/cblades-tc/ficusjs/commit/ec6bcad5da74fca963184052777c9f207be3e206

@cblades-tc thanks for letting us know, must have missed that one! A PR would be great, happy to accept if you want to submit a fix?

@cblades-tc I have fixed the issue and released v3.2.2


pull request for e2e test at 11/30/2016 21:26:05

:white_check_mark: Validation status: passed
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.


Touch tip: bad coordinates on trough

overview
It seems like non-circular wells are a problem for pipette.touch_tip fn.
Server version: 3.2.0-beta.1
Firmware version: edge-6168d32
current behavior
See comments in protocol code snippet:
from opentrons import labware, instruments, robot

tiprack = labware.load('tiprack-200ul', 7)
trough = labware.load('trough-12row', 2)

pipette_single = instruments.P300_Single(
    mount='left',
    tip_racks=[tiprack])

pipette_single.pick_up_tip()

# Bad: leaves the bounds of the well, and even leaves the slot
pipette_single.touch_tip(trough[0])

pipette_single.drop_tip()

I think this might also be an issue with other labware with non-circular wells but I only tested trough. (I couldn't find any definitions for square-well 96 plates, etc)
(Touch-tip with fixed-trash and trash-box also cause collisions, but that's outside the scope of this issue IMO since there's not a great reason to touch tip on the trash, but it is important to be able to touch tip on a trough.)
expected behavior
For the trough, I'd expect it to touch tip on each side of the rectangular well. But instead, it knocks the trough over and potentially crashes into a neighboring labware in another slot.
Also with a multi-channel in a well of a trough, I'm not sure if I'd expect it to touch-tip in the same way as I'd expect it to touch-tip with a single-channel. Maybe it would only move perpendicularly to the 8 tips. But it should touch-tip in some way that doesn't knock into or past the sides of the trough's wells, even with a multi-channel.

We believe this is limited to API v1 and will be addressed as part of API v2.


feat: add support to configure custom FHIR searches

coverage: 31.755% (+0.04%) from 31.719%
when pulling ddb61ec13b4e7c36614968ed4373182b1c68b46e on feature/fhir-configure-search
into 4855ce8ca0e3d111597ba04498b7da04c6a9f813 on main.


Storage node & protocol

We need to define the public API and the protocol to interact with a storage node.
This also plays into data availability (which might be started being spec'ed out in #2) as consensus participants (validators) that do not want to be storage nodes themselves will need to query them for data availability.
Quoting musalbas here:

So there should be an option to run:
a) validator that is also a storage node
b) storage node only
c) validator that just uses data availability proofs
d) light clients that use data availability proofs

c) validator that just uses data availability proofs

Question: this was still assuming that there is no state in the LL main chain? Wouldn't validators still verify validity of transactions while they could only use data availability proofs for the messages the transactions pay for (@musalbas)

I consider the LL token app to logically be an optimistic rollup sidechain. Therefore validators can just download the latest state root for it and accept state transition fraud proofs.

Update on the above: while you could still argue that the LL token app will be treated as an ORU chain in the sense that clients could accept state transition fraud proofs, this does not hold for validators who will download all Tx (and actually all block data) and hence do not need to care about state fraud proofs.


[Bug Report] FetchPickAndPlace-v2 does not yield reproducible results

Describe the bug
The gymnasium API allows users to seed the environment on each reset to yield reproducible results. Running the environment with the same seed should always give the exact same results. While the documentation recommends that users should seed reset only once, it does not forbid seeding multiple times.
FetchPickAndPlace-v2 does not yield reproducible results under these conditions. The reset observation is identical, but the observations start deviating at the first environment step using identical actions.
Code example
import gymnasium
import numpy as np

def test_reproducibility(env: gymnasium.Env, seed: int = 42):
    env.action_space.seed(seed)  # Reproducible actions
    action = env.action_space.sample()  # Same random action for both runs
    env.reset(seed=seed)
    obs_1, _, _, _, _ = env.step(action)
    env.reset(seed=seed)  # Same seed should produce the same observations
    obs_2, _, _, _, _ = env.step(action)  # Identical action
    if isinstance(obs_1, dict):
        for key in obs_1:
            assert np.all(obs_1[key] == obs_2[key])  # Assertion error: different observations
    else:
        assert np.all(obs_1 == obs_2)
    print(f"Reproducibility test passed for {env.unwrapped.spec.id}")

def main():
    test_reproducibility(gymnasium.make('CartPole-v1'))  # Works
    test_reproducibility(gymnasium.make("FetchPickAndPlace-v2"))  # Fails

if __name__ == '__main__':
    main()

Stack Trace:
Reproducibility test passed for CartPole-v1
Traceback (most recent call last):
  File "/home/amacati/repos/Gymnasium-Robotics/bug_report.py", line 26, in <module>
    main()
  File "/home/amacati/repos/Gymnasium-Robotics/bug_report.py", line 22, in main
    test_reproducibility(gymnasium.make("FetchPickAndPlace-v2"))  # Fails
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/amacati/repos/Gymnasium-Robotics/bug_report.py", line 14, in test_reproducibility
    assert np.all(obs_1[key] == obs_2[key])  # Assertion error: different observations
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

System Info

Clone the latest Gymnasium-Robotics commit (commit 50c801922273331c50956909f5bf3377a012233a)
New mamba environment with Python 3.11
Install Gymnasium-Robotics with pip install -e .
Ubuntu 22.04 Jammy
Python 3.11.7

Additional context
The differences are small, i.e. they sometimes pass a np.allclose assert. In the example above, the object rotation in observation 1 is
[-5.18150577e-08  7.97154734e-08 -1.37921664e-16]
and
[-5.18150577e-08  7.97154734e-08 -1.37780312e-16]
in observation 2. Note the difference in z rotation. In fact, all three rotations are not equal, but the differences are too small to be printed without additional precision.
The inconsistencies arise from the FetchPickAndPlace environment's use of mocap bodies. The position and quaternions of the mocap bodies are currently not reset properly.
Furthermore, the Mujoco integrator uses warmstarts and caches the last controls in mjData. In the current implementation, these are also not reset. Only if these four mjData fields are properly restored to their initial states, env.reset(seed=seed) yields reproducible results.
I will open up a pull request that fixes this.
Checklist

[x] I have checked that there is no similar issue in the repo (required)

I have opened up the PR https://github.com/Farama-Foundation/Gymnasium-Robotics/pull/208 that fixes this behaviour.

I can replicate the results on my machine, during test we use atol=0.00001
https://github.com/Farama-Foundation/Gymnasium/blob/72cfbc204beca309579681b1201990a3d706e070/gymnasium/utils/env_checker.py#LL57
I expanded the test to cover all robotics environments
import gymnasium
import numpy as np
import pytest
from gymnasium.utils.env_checker import data_equivalence

robotics_full_env_list = []
for env_id, spec in gymnasium.envs.registration.registry.items():
    if spec.entry_point.startswith("gymnasium_robotics"):
        robotics_full_env_list.append(env_id)

@pytest.mark.parametrize("env_id", robotics_full_env_list)
def test_reproducibility(env_id: str, seed: int = 42):
    env = gymnasium.make(env_id)
    env.action_space.seed(seed)  # Reproducible actions
    action = env.action_space.sample()  # Same random action for both runs
    env.reset(seed=seed)
    obs_1, _, _, _, _ = env.step(action)
    env.reset(seed=seed)  # Same seed should produce the same observations
    obs_2, _, _, _, _ = env.step(action)  # Identical action
    if isinstance(obs_1, dict):
        for key in obs_1:
            assert np.all(obs_1[key] == obs_2[key])  # Assertion error: different observations
    else:
        assert np.all(obs_1 == obs_2)
    assert data_equivalence(obs_1, obs_2)
    print(f"Reproducibility test passed for {env.unwrapped.spec.id}")

and other ones seem to fail

Yes, I already suspected that any environment that uses Mujoco and allows for solver warm starts might have this issue.
By the way, I am not sure about the performance impact of removing warm starts. If that is something you are worried about, it might be a solution to just reset the buffers if a seed is passed to env.reset.

Seems to affect all RobotEnv environments
FetchSlide-v1
FetchSlide-v2
FetchPickAndPlace-v1
FetchPickAndPlace-v2
FetchReach-v1
FetchReach-v2
FetchPush-v1
FetchPush-v2
HandReach-v0
HandReach-v1
FetchSlideDense-v1
FetchSlideDense-v2
FetchPickAndPlaceDense-v1
FetchPickAndPlaceDense-v2
FetchReachDense-v1
FetchReachDense-v2
FetchPushDense-v1
FetchPushDense-v2
HandReachDense-v0
HandReachDense-v1

Should I update my PR to fix all of them?

updating robotEnv should in theory fix all of them (all the mujoco based ones at least)

I pushed a new fix (https://github.com/Farama-Foundation/Gymnasium-Robotics/pull/208/commits/5e14ea14d1ac46c60aaed7a00edc4f997510e705) that includes both the mujoco and mujoco_py envs. It passes all tests on my side including the new reproducibility tests, feel free to have a look


get_artifacts_as_files improvements

get_artifacts_as_files should check if any of the files already exist, and if they do, don't download them. Probably should also check if the checksums are correct.

Implemented in https://github.com/simvue-io/client/commit/66a42a4b86c7e15635c353c9ce5074f8895c0e77


Cicero 0.21 Templates

Changes

Upgrade all templates for the new version of Cicero (0.21)

Flags

This is now ready for review
This does not rebuild archives (it does happen at deployment time though) mostly to make the changes easier to review
Deployment, including the new compiled archives seems to have worked

@irmerk Thanks for the review


Randomize service container name

Rename service container to random string to avoid conflicts after restarted hyperd.
cc @feiskyer

Agree. I have the same idea when I refactor the hyperd,  all determined name might be collision.

@resouer This will introduce problems on https://github.com/hyperhq/hyperd/blob/master/daemon/list.go#L107, maybe change filterPodContainers logic with suffix instead of name?

Do not merge! list will broke, I have noticed that.

lgtm


refactor: fund account tile

Try out this version of the Hiro Wallet - download extension builds.

This PR finishes up the fund account tile on the FundPage so we can release. The provider link to Hiro faq sends params for use later.
Details found here: https://github.com/hirosystems/stacks-wallet-web/issues/2251#issuecomment-1149888899

cc/ @kyranjamie @fbwoolf @beguene

Hoping to get an approval on this so can merge it today.


add --delete option for SFTP processor

Signed-off-by: nyaundi brian<EMAIL_ADDRESS>

@danleyb2 sftp_processor.py and ftp_processor.py look similar. What do you think of merging them?

@marcbelmont Sure, Have created https://github.com/parkpow/deep-license-plate-recognition/issues/97


Don't set EC2_LOCAL_IPV4 when network mode is V6 only

Description of the Change
FIXME: please add at least one sentence explaining why changes here are being made.

Please rebase against master to get buildkite fixes and fix conflicts.

@MyUmmaGumma please rebase

Closing in favor of #779


I need help

So whenever i put my token it is removed and i get a email from discord saying dont share your token with any one how do i fix this

@Aztra9 what are you trying to do?

@Aztra9 what are you trying to do?


Remove unused registers

https://trello.com/c/1WfFjjMD/397-remove-unused-terraforms

You can actually remove location as well as this register no longer exists


IIC 16 bit address pynq.lib.iic

Do you have a work around for IIC addresses larger than 8 bit as imx219 (RPI Cam V2) needs to be configured using 16bit addresses.
`OverflowError                             Traceback (most recent call last)
 in
----> 1 test.send(0x479B, 0x05, 8, 0)
/usr/local/share/pynq-venv/lib/python3.8/site-packages/pynq/lib/iic.py in send(self, address, data, length, option)
99
100         """
--> 101         sent = AxiIIC._lib.XIic_Send(
102             self._virtaddr, address, data, length, option)
103         if sent == 0:
OverflowError: integer 18331 does not fit 'unsigned char'
`

Hi @JackBonnellDevelopment
Can you please post your question on https://discuss.pynq.io/?


Deploy 4.20 release

[x] run unit tests in dev
[x] update version to "4.20" in setup.py and hxl/__init__.py
[x] check CHANGELOG
[x] install and test in clean virtualenv
[x] merge to test and push
[x] merge to master and push
[x] create libhxl PyPi release
[x] wait until the new release is visible on PyPi https://pypi.org/project/libhxl/4.20/
[x] add git tag "4.20"
[ ] create GitHub release

PyPi release: https://pypi.org/project/libhxl/4.20/
GitHub release: https://github.com/HXLStandard/libhxl-python/releases/tag/4.20
Note: used twine for PyPi release